Monday, February 12, 2007

A Few Corrections and Some Comments on ESARR 6 - Software in ATM Systems

A FEW CORRECTIONS and SOME COMMENTS
ON EUROCONTROL’s Safety Regulation Requirement
ESARR 6 – Software in ATM Systems


CORRECTIONS

I - Mandatory Provisions, 1. General safety Requirements, item 1.2
a) The software requirements correctly state what is required by the software, in order to meet safety objectives and requirements, as identified by the risk assessment and mitigation process;

should rather be

a) The software requirements correctly state what is required from the software,

II - Requirements applying to the software safety assurance system, item 2.4,
b) the assurances corresponding to each software assurance level shall give sufficient confidence that the ATM software can be operated tolerably safely.

The term tolerably safe is not explained in the document, safety is defined as “freedom from unacceptable risk”,

Should rather be
… can be operated with acceptable risk
or
… can be operated with safety. (the flexibility in the definition itself suffices)

III – Item 2.6,
… developmental and non-developmental are unnecessary new words which do not contribute to the jargon more than the overhead they create.

IV. Requirements applying to the software assurance level, item 3.2

… the architectural and/or procedural defences identified

defences should be precautions or precaution systems if you like. (would be nice if it were football;-)

IV – Appendix A

Accuracy: The required precision of the computed results.

Accuracy and precision and the relation between them should be clearly defined. Some university books define precision as the “repeatibility of results” regardless of their accuracy. Accuracy is only the correctness of a measurement nothing else… …

V - Resource usage: The amount of resources within the computer system that can be used by the application software.

Should be

by a specific application in the software

VI - The definition for the word ‘risk’ is a little bit cumbersome but perfact in meaning…

VII – Safety: Freedom from unacceptable risk

implies that freedom includes acceptable risk which is quiet clever… And after this, safety is referred to in‘acceptable or tolerable safety’, which means ‘acceptable or tolerable acceptable risk situation’ according to the definition of ‘safety.’

acceptable or tolerable safety

Should be either

Safety

Or
Acceptable or tolerable risk (situation)…

VIII – The term ‘Software Timing Performances’ may have been used to bring in meaning flexibility for future developments and it is also out of any jargon that I have heard of… The definition given points at exactly the term ‘response time’. It does not sound ‘just’ to do things like this unless they are done unintentionally.

COMMENTS

I - This is a difficult document to write. Many who are involved with ATC rather closely would choose not to write it at all…

II -The document has to set a framework so that assigned authorities, service providers etc. should be gently leaded to a more formal way of doing things and maybe doing them better as a natural result. The document is good in this respect.

III - On the other hand, the document misses conscientious aspect of software development and maintenance in ATC in the thick cloud of gentle politics, interest balancing etc. Bluntly, there is nothing in the document which ensures the identification of who has done which software change or development item. ESARRs have conscientiously protected anonymity of engineers who may have caused involuntary harm to the air traffic. ESARR 6 falls short of adressing the individual responsibility in retrograde of this.

should be

6.4 A person who has done an error in the ATM software should be easily identifiable through the use of Configuration management.

IV – Testing should have been mentioned explicitly

VII – Software inspection by peers and group leaders should have been mentioned explicitly

The last two items are no less important or relevant than traceability in software requirements.

APPENDIX

TURKISH TRANSLATION OF ESARR 6
WORK IN PROGRESS 20070221ARSver0.1.1
By Ali R+ SARAL

EUROCONTROL
Hava Seyrüseferi Güvenliği için Avrupa Kuruluşu
(EUROCONTROL-European Organisation for the Safety of Air Navigation)

EUROCONTROL Güvenlik Düzenleyici Şartnamesi
(ESARR–EUROCONTROL Safety Regulatory Requirement)

ESARR 6

Hava Trafik Yönetim Sistemlerindeki Yazılımlar
(Software in ATM Systems)

F.2 BELGE ÖZELLİKLERİ

ESARR6 yazılım güvenliği güvence sistemlerinin hayata geçirilmesi ile ilgilenir. Bu sistemler güvenlik ile ilgili yeryüzüne-konumlandırılmış ATM sistemlerindeki yazılımların kullanılmasına ilişkin risklerin hoş görülebilecek bir seviyeye indirilmesini güvenceye alır.

ESARR6 yazılım için herhangi bir destekleyici uyum yöntemi kullanılmasını öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Dolayısıyla, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.

Bu şartnamenin amacı ATM güvenlik düzenleyici kuruluşları ve ATM hizmet sunucularına ATM sistemlerinde yazılım kullanımı için kendi içinde bütünlük ve uyum taşıyan bir grup güvenlik düzenlemesi koşulu sağlamaktır.



F.6 YÖNETİMSEL ÖZET

Bu EUROCONTROL Güvenlik Düzenleyici Şartnamesi(ESARR) Güvenlik Düzenleyici Komisyon tarafından hazırlanmıştır.

ESARR6 yeryüzüne-konumlandırılmış ATM güvenlik sistemlerindeki yazılımların kullanım risklerinin hoş görülebilecek bir seviyeye indirilmesinden emin olmak için yazılım güvencesi sisteminin hayata geçirilmesi ile ilgilenir.

Bu yüzden, bu ESARR’ın amacı ATM sistemlerinde yazılım kullanımı için bir grup uyumlu güvenlik düzenleyici koşul sağlamaktır. Hiçbir yazılım güvencesi standardını kendi zorunlu koşullarını karşılamak için kabul edilebilir bir uyum yöntemi olarak belirlemez. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.

Bu ESARR’ın koşulları EUROCONTROL Daimi Komisyonu tarafından onaylandıktan sonra 3 yıl içinde uygulamaya girecektir.



TANITICI MALZEME

Bu kısımdaki koşullar zorunlu değildir.

A. KAPSAM

i. ESARR 6, sivil hava trafiğine ATM hizmetleri sağlamak için kullanılan, güvenlik ile ilgili, yeryüzüne konumlandırılmış ATM(hava trafik yönetimi) sistemlerinde yazılım kullanımıyla (cutover / hot swapping gibi tüm işletimsel yazılım değiştirme işlemleri dahil) ilişkilidir.
ii. ESARR 6’nın kapsamı ATM hizmet-sağlayıcının idari kontrolü altındaki yeryüzüne konumlandırılmış CNS gibi destek hizmetleri dahil, ATM’in yeryüzü bileşeni ile sınırlıdır. Değiştirilmediği ve uygun bir şekilde yeniden gözden geçirilmediği takdirde ESARR6 gökte ya da uzayda uçan ATM sistemi bileşenleri için uygulanamaz.

iii. Bu güvenlik düzenleyici şartnamenin koşulları, yazılım tarafından icra edilen ATM işlevleri dahil ATM’in tüm sahalarının gereğince değerlendirilmesinden emin olmak için, a priori, önkoşul olarak, etkin risk değerlendirme ve uygun bir seviyeye risk azaltması çalışması yapılması temelinde geliştirilmiştir.
iv. ESARR 6 yazılım için herhangi bir destekleyici uyum yöntemi öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.

B. GEREKÇE

i. SRC’nin 6/8/5 kararı SRC İş Programı içinde yazılım temelli ATM sistemleri için bir EUROCONTROL Güvenlik Düzenleyici Şartnamesi geliştirilmesini içermeyi onayladı. Aynı zamanda, ICAO standartları ve tavsiye edilen ICAO uygulamalarında ilk örnek teşkil edecek hiçbir şeyin var olmadığı olgusu da kabul edildi.
ii. ESARR 3(Güvenlik Yönetim Sistemlerinin ATM hizmet sağlayıcıları tarafından kullanımı) ATM sistemine yapılan değişikliklerin önemlerine göre değerlendirilmesini ve ATM sistem işlevlerinin ciddiyetlerine göre sınıflandırılmasını güvenceye almak için güvenlik yönetim sistemlerinin Risk Değerlendirme ve Azaltma içermelerini şart koşar.
iii. ESARR 4 (Hava Trafik Yönetiminde Risk Değerlendirme ve Azaltma – Risk Assessment and Mitigation in ATM) Risk Değerlendirme ve Azaltma üzerinde ESARR3’ün şartlarını genişletir ve Hava Trafik Yönetimi sistemini insanlar, işlemler ve cihazlar (yazılım ve donanım) açısından ve onların ATM sisteminde değişiklik yapmaları / tasarlamaları açısından ele almak için her yönden kapsayıcı bir işlemler dizisi sağlar.
iv. ESARR 6 bu güvenlik düzenleyici geliştirme sürecinin devamıdır ce ATM sistemlerinin yazılım yanına ilişkin olarak ESARR 4’ü genişletir. Donanım yanı için tamamlayıcı güvenlik düzenleyici şartname değerlendirme altındadır.
v. Güvenlik ATM sistemlerinin temel bir özelliğidir. İşletimsel etkinlik üzerinde ağırlıklı bir çarpıcı etkiye sahiptir. Yığınsal ve sistemli yazılım kullanımı, daha önce elle icra edilen işletimsel işlevlerin otomasyonu ve sürekli büyüyen tümleşik ortamlarda önemli etkileşimler içeren ATM sistemleri güvenlik elde edilmesinde daha resmi-formal yaklaşımlar talep etmektedir.
vi. Bu ESARR’ın amacı ATM sistemlerinin kullanımı için ATM güvenlik kuruluşları ve ATM hizmet sunucularına bütünsel ve uyumlu bir grup güvenlik düzenleyici şart sağlamaktır.

C. GÜVENLİK HEDEFİ

Yazılım içeren ATM sistemlerinin sağlaması gereken birincil yazılım güvenlik amacı
ATM yazılımı kullanımı ile ilişkilendirilmiş risklerin hoş görülebilir bir seviyeye indirilmesinden emin olunmasıdır.





ZORUNLU KOŞULLAR

1. GENEL GÜVENLİK ŞARTLARI

1.1 Güvenlik Yönetim Sistemi yapısı içinde ve risk değerlendirme - azaltma faaliyetlerinin bir parçası olarak, ATM hizmet-sağlayıcısı sorunun yazılım ile ilgili yanlarını ele almak için (cutover/hot swapping gibi bütün kullanım sırasındaki işletimsel yazılım değişiklikleri dahil) bir Yazılım Güvencesi Sistemini uygulamaya koymalıdır.

1.2 ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminde, en azından, şunlardan emin olmalıdır;

a) Yazılım şartnamesi, risk değerlendirme – azaltma sürecinde belirlendiği şekilde, güvenlik amaçlarını ve şartlarını sağlamak için yazılımın(?) yapması gereken şeyleri doğrulukla belirtir.
b) İzsürülebilirlik–traceability bütün yazılım şartları açısından ele alınmış;
c) Yazılım gerçekleştirliş şekli güvenliği olumsuz etkileyecek hiçbir işlev içermez;
d) ATM kendi yazılım şartnamesini yazılımın hayatiyeti ile tutarlı bir güvenlik seviyesi yüksekliğinde sağlar;
e) Yukarıdaki Genel Güvenlik Şartnamesi’nin sağlandığına ilişkin güvencelerin ve gereken güvencelerin sağlandığına ilişkin tartışmaların her zaman aşağıdakilere dayandırılması;

i. yazılımın belirli bir icra edilebilir sürümü
ii. bir dizi yapısal-kurulum–configuration verisi
iii. belirli bir grup yazılım ürünü ve o sürümün üretilişinde kullanılmış tanımlar(tarifnameler dahil).

1.3 ATM hizmet-sağlayıcısı Atanmış Otoriteye, yukarıda bölüm 1.2’deki şartların sağlandığına ilişkin gerekli güvenceleri sağlamalıdır.

2. YAZILIM GÜVENLİK GÜVENCESİ SİSTEMİNE UYGULANAN ŞARTLAR

ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminin en azından şunları sağladığından emin olmalıdır;

2.1 Belgelenmiş olmalı, özellikle genel Risk Değerlenirme – Azaltma Belgeleme Sisteminin parçası olarak.

2.2 Bütün işletimsel ATM yazılım yazılım güvence seviyeleri ataması.

2.3 Aşağıdakilerin güvencelerine sahiptir;
a) Yazılım şartları geçerliliği–software requirements validity
b) yazılım geçerliliğini doğrulama–software verification
c) yazılım yapısal-kurulum yönetimi–software configuration management
d) yazılım şartnamesi izsürülebilirliği – software requirements traceability

2.4 Güvencelerin hangi azim ve ısrar ile gerçekleştirildiğini belirler. Azim ve ısrar her yazılım güvencesi seviyesi için tanımlanmalı ve yazılımın hayatiyeti ile doğru orantılı artmalıdır. Bu amaçla;
a) Her yazılım güvencesi seviyesi başına güvence azim ve ısrarındaki değişim aşağıdaki kriterleri içermelidir:
i. bağımsız olarak başarılması gerekir
ii. başarılması gerekir
iii. şart değil.
b) Her yazılım güvence seviyesine denk düşen güvenceler ATM yazılımının hoş görülebilir(?) şekilde güvenli işletilebileceğine yeterli güven vermelidir.

2.5 Yazılı Güvenlik Güvencesi Sisteminin ve güvence seviyelerinin atamasının uygun ve geçerli olduğunun doğrulanması için ATM yazılım tecrübesinden geri dönerek faydalanır. Bu amaçla, ESARR 2’ye göre raporlanmış ATM işletimsel tecrübesinden herhangi bir hata veya yazılım arızası sonucu etkiler ESARR 4 yapısı bağlamında değerlendirilmelidir.

2.6 Atanmış Otorite tarafından seçilmiş ve kabul edilmiş herhangi bir yöntem ile, eşit yazılım güvencesi seviyelerindeki, geliştirilmiş ya da hazır alınmış ATM yazılımları için(COTS vb.), eşit güvenlik seviyesi sağlar.


3. YAZILIM GÜVENCESİ SEVİYESİNE UYGULANAN ŞARTLAR

ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:

3.1 Yazılım güvencesi seviyesi, yazılım güvencelerinin azim ve ısrarını ATM yazılımının hayatiyetine, ESARR 4 ciddiyet sınıflama şeması ile belirli bir olumsuz etkinin oluşması olasılığını birleştirerek, ilişkilendirir. 1. yazılım güvencesi seviyesi en hayati seviyeyi belirtmek üzere, en az 4 yazılım güvencesi seviyesi tanımlanmalıdır.

3.2 Ayrılmış bir yazılım güvencesi seviyesi ESARR 4’e göre yazılım arızaları ve hatalarının neden olabileceği en olumsuz etki ile denk düşmelidir. Bu, yazılım arızaları ve hataları ile ilişkili riskleri ve belirlenmiş yapısal ve/veya işlem-dizisel-procedural savunmaları(?-tedbirleri demek istiyor-ARS) hesaba katmalıdır.

3.3 Birbirlerinden bağımsız oldukları gösterilemeyen ATM yazılım unsurları bağımlı unsurlar arasındaki en hayati yazılım güvencesi seviyesine ayrılmalıdır.

4. YAZILIM ŞARTNAMESİ GEÇERLİLİK GÜVENCELERİNE UYGULANAN ŞARTLAR

ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından yazılım şartlarının:

4.1 ATM yazılımının (normal ve geriseviyelendirilmiş-downgraded çalışma türlerinde) işlevsel davranışını, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness
ve aşırı yüklenmeye dayanıklılık, uygun şekilde belirlemesi.

4.2 Tam ve doğru olmaları ve sistem güvenlik şartnamesi koşullarına uymaları gerekir.

5. YAZILIM GEÇERLİLİĞİ DOĞRULAMA GÜVENCELERİNE UYGULANAN ŞARTLAR

ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:

5.1 ATM yazılımının işlevsel davranışının, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness ve aşırı yüklenmeye dayanıklılığının yazılım şartnamesi koşullarını sağlar.

5.2 ATM yazılımının geçerliliği, Atanmış Otorite ile mutabakata varıldığı gibi, analiz ve/veya deneme ve/veya eşdeğer yöntemlerle uygun bir şekilde doğrulanır.

5.3 ATM yazılımının geçerliliği doğru ve tamdır.


6. YAZILIM KURULUM-YAPISI(configuration) YÖNETİMİ GÜVENCELERİNE UYGULANAN ŞARTLAR

ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:

6.1 Yapısal-kurulum–configuration belirlemesi, iz-sürülebilirlik ve durum takibi-status accounting vardır öyle ki, ATM yazılım yaşam-döngüsü-lifecycle boyunca yazılım yaşam-döngüsü verilerinin yapısal-kurulum kontrolü altında olduğu gösterilebilir.

6.2 Sorun raporlama, takip ve düzeltici eylemler vardır öyle ki yazılıma ilişkin güvenlik ile ilgili sorunların azaltıldığı gösterilebilir.

6.3 Öyle yeniden ele alma ve hizmete sunma eylem dizileri-procedure vardır ki ATM yazılım yaşam-döngüsü sırasında yazılım yaşam-döngüsü verileri yeniden canlandırılabilir ve teslim edilebilir.

7. YAZILIM ŞARTNAMESİ İZSÜRÜLEBİLİRLİK GÜVENCELERİNE UYGULANAN ŞARTLAR

ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:

7.1 Sağlandığı gösterilmiş olan her tasarım seviyesine her bir yazılım şartının izi-sürülebilir.

7.2 Tasarımdaki her seviyede, sağlandığı gösterilmiş olan her bir yazılım şartının bir sistem şartına kadar izi-sürülebilir.


8. UYGULANABİLİRLİK

8.1 Bu güvenlik şartnamesi idari kontrolleri altındaki, yeryüzüne-konuşlandırılmış ATM sistemleri ve destek hizmetleri (CNS gibi)’nden sorumlu olan sivil ve askeri ATM hizmet sağlayıcıları için geçerlidir.

8.2 Askeri ATM kuruluşunun doğrudan idari kontrolü altındaki ATM sistemlerinin zaten var olan yazılım güvencesi sistemi, ESARR 6’nın zorunlu koşulları ile denk düşmek şartı ile geçerli kabul edilebilir.

8.3 Bu ESARR’ın zorunlu koşulları milli güvenlik düzenleyici şartnamelerin asgari koşulu olacaktır.


9. GERÇEKLEŞTİRME

9.1 ESARR 6’nın koşulları EUROCONTROL komisyonu tarafından onaylandığı tarihten itibaren 3 yıl içinde etkin olacaktır.




APPENDIX