Ortak Kriterler (ISO/IEC 15408) BT Güvenlik Sertifikasyon Sürecinde UML, OCL ve Formel Metotların Kullanımı Engin Deveci 1, M. Ufuk Çağlayan 1 1 Boğaziçi Üniversitesi, Bilgisayar Mühendisliği Bölümü, İstanbul engin.deveci@boun.edu.tr, caglayan@boun.edu.tr Özet: BT ürünlerinin güvenlik özellikleri firmaların en önemli satın alma kriterlerinden birisidir. Eğer BT ürünü, ilgili özellikler için bir güvenlik sertifikasına sahipse firmanın satın alma kararı vermesi daha kolaydır. Ortak Kriterler (ISO/IEC 15408), BT ürünlerinin güvenlik incelemesi ve sertifikasyonu için iyi bilinen uluslararası bir standarttır. Ortak Kriterler in Türkiye dahil on yedi ülkede sertifika yetkili üyesi bulunmaktadır. BT ürünleri, bu ülkelerde, lisanslı bağımsız laboratuvarlarda, seçilen güvenlik özellikleri için incelenmekte ve sertifikalandırılmaktadır. Ortak Kriterler de yedi farklı sertifika teminat seviyesi (EAL) vardır. EAL 7, güvenlik incelemesi için formel metotları kullanmaktadır ve bu nedenle ulaşması en zor olan teminat seviyesidir. Bu bildiride, Ortak Kriterler sertifikasyonu için hazırlık ve inceleme süreçlerini kolaylaştıracak bir yöntem önermekteyiz. Bu yeni yöntemde, BT ürününün işlevsel özellikler tasarımı ve güvenlik poliçelerinin modellenmesi için UML ve OCL kullanılmaktadır. Daha sonra, bu güvenlik poliçelerinin BT ürününün tasarım modeli üzerinde SPIN aracı kullanılarak formel olarak doğrulanması sağlanmaktadır. Anahtar Sözcükler: Güvenli Yazılım Tasarımı, Güvenlik, Ortak Kriterler, BT Güvenliği, Güvenlik Açıkları, Güvenlik Tehditleri, UML, OCL, Güvenlik Sertifikaları, Biçimsel Yöntemler Abstract: Security aspect of the IT products is one of the most important buying criteria for the enterprises. It s easier for the enterprise to decide if the IT product has a security certification for the particular security properties. The Common Criteria (The CC, ISO/IEC 15408) is a well known international standard for IT product security evaluation and certification. The CC has certificate authorizing members in seventeen countries including Turkey. Products are evaluated in the independent licensed laboratories to determine the fulfillment of particular security properties. There are seven evaluation assurance levels (EALs) in the CC and EAL 7 is the most difficult one to achieve due to its requirements on formal modelling and formal verification of the security features. This is why, there are only a few certified products on EAL 7 level. In this study, we re proposing a new methodology to ease the preparation and evaluation processes for the CC certification. In this new methodology, we use UML and OCL to model the functional specification and security policies of the IT product. And later on, we formally verify the security policies on the functional specification using the SPIN model checker.
1. Giriş BT ürünleri firmaların günlük operasyonlarının ayrılmaz bir parçası haline gelmiştir. Bu ürünlerdeki güvenlik açıkları, firmaların veri, zaman ve para kaybına neden olabilmektedir. Bu nedenle firmalar BT ürünü satın alma süreçlerinde ürünlerin güvenlik özelliklerine ve güvenlik sertifikalarına dikkat etmektedirler. Aşağıdaki Şekil 1 de firmaların güvenlik sertifikasından beklentileri anlatılmaktadır. bulunmaktadır. Ortak Kriterler yedi farklı sertifika teminat seviyesi (EAL) sunmaktadır. Teminat seviyesi yükseldikçe, kontrol noktaları sayısı ve güvenlik gereksinimleri de artmaktadır. EAL6 ve EAL7 teminat seviyelerinde BT ürün tasarımları ve güvenlik poliçeleri için formel modeller istenmekte ve hatta EAL7 teminat seviyesinde formel metotlar ile güvenlik özelliklerinin doğrulanması beklenmektedir. Bu bildiride Ortak Kriterler in EAL7 teminat seviyesini ve gerekliliklerini incelemekte ve sertifikasyon hazırlık sürecini ve inceleme sürecini kolaylaştıracak bir yöntem önermekteyiz. Bu yeni yöntemde, BT ürününün işlevsel özellikler tasarımı ve güvenlik poliçelerinin modellenmesi için UML ve OCL kullanılmaktadır. Daha sonra, bu güvenlik poliçelerinin BT ürününün tasarım modeli üzerinde SPIN [4] aracı kullanılarak formel olarak doğrulanması sağlanmaktadır. Şekil 1. Güvenlik Sertifikasyonunun Amacı Firmaların varlıkları, kullandıkları BT ürünleri ile ilgili güvenlik tehditleri nedeniyle risk altındadır. BT ürün sağlayıcı firmalar, tasarım, geliştirme ve test süreçlerinde bu güvenlik tehditlerine karşı gerekli ve yeterli savunma mekanizmalarını ve güvenlik özelliklerini ürünlerine eklemekle yükümlüdürler. BT ürünlerini satın alacak olan firmalar da ürün sağlayıcı firmanın gerekli ve yeterli savunma mekanizmalarını ve güvenlik özelliklerini ürünlerine eklediğine itimat etmek isterler. Bu güveni sağlamanın yolu da ürünün güvenlik özelliklerinin bağımsız bir güvenlik sertifikasyon yetkilisi tarafından incelenmesi ve doğrulanması ile mümkündür. Günümüzde yaygın olarak kullanılan BT ürün güvenlik sertifika standartlarından birisi Ortak Kriterler dir (ISO/IEC 15408) [1,2,3]. Bu standartta sertifikasyon on yedi ülkede bulunan bağımsız laboratuvarlarda yapılmaktadır. Türkiye de de bir sertifika yetkili laboratuvarı 2. Temel Bilgiler Ortak Kriterler (ISO/IEC 15408) ve Teminat Süreci Ortak Kriterler sertifikasyonunda kullanılması için bir güvenlik hedefi (Security Target) dokümanı hazırlanır. Bu dokümanın içeriği aşağıdaki Şekil 2 de açıklanmıştır. Güvenlik hedefi dokümanının bu çalışma için en önemli içerikleri aşağıdaki gibidir: Güvenlik problemi tanımı: Bu bölümde BT ürünü ile ilgili güvenlik tehditleri, operasyonel güvenlik poliçeleri ve varsayımlar listelenir. Güvenlik amaçları: Bu bölümde güvenlik tehditlerine karşı alınacak tedbirler ana başlıkları ile listelenir. Güvenlik gereksinimleri: Bu bölümde güvenlik amaçlarına ulaşmak için BT ürününün sağlaması gereken detaylı güvenlik gereksinimleri listelenir.
Şekil 2. Güvenlik Hedefi Dokümantasyon İçeriği Ortak Kriterler teminat modelinde BT ürünü iki farklı açıdan incelenir: Güvenlik İhtiyaçları: Bu bölümde, güvenlik hedefinde listelenen güvenlik tehditlerinin, tedbirlerinin ve gereksinimlerinin doğru ve eksiksiz olarak belirlenip belirlenmediği incelenir. Eğer güvenlik gereksinimleri eksik ise, geliştirilen ürünün güvenlik özellikleri de yetersiz olacaktır. Tasarım ve Geliştirme: Bu bölümde ürünün tasarım ve geliştirme süreçlerinde güvenlik hedefinde belirtilen tüm tedbirleri ve güvenlik gereksinimlerini göz önünde bulundurup bulundurmadığı incelenir. Bu inceleme sonucunda aşağıdaki nedenlerle oluşabilecek güvenlik açıkları tespit edilebilir: o Hatalı tasarım kararları o Güvenlik ihtiyacının eksik veya yanlış yorumlanması o Hatalı veya eksik geliştirme süreci Ortak Kriterler sertifikasyonunda temel olarak aşağıdaki incelemeler yapılır: Süreç ve prosedürlerin analiz ve kontrolü Süreç ve prosedürlerin uygulanıp uygulanmadığı Ürünün farklı seviye tasarım gösterimlerinin birbiri ile uyuşmasının kontrolü Ürünün tasarım modelinin gereksinimleri karşılayıp karşılamadığının analizi Sunulan ispatların doğrulanması Dokümantasyonun analizi Fonksiyonel testlerin ve sonuçlarının analizi Bağımsız fonksiyonel testler Güvenlik açıklarının analizi Penetrasyon testleri UML (Unified Modeling Language) ve UML Profilleri UML [5], nesneye dayalı tasarımların modellenmesi için kullanılan bir dildir. Sistemlerin mimarilerini, bileşenlerini, aktivitelerini, entegrasyon detaylarını, kullanım senaryolarını, etkileşimlerini ve daha birçok statik ve dinamik özelliklerini modellemek için yazılım analistleri, tasarımcıları, geliştiricileri ve test ekipleri tarafından yoğun bir şekilde kullanılmaktadır. Gerektiği durumlarda UML, güvenlik, güvenilirlik, vb. farklı alanlar için genişletilebilmekte ve özelleştirilebilmektedir. İki farklı genişletme mekanizması bulunmaktadır: UML profillerinin kullanılması [6] Yeni meta-sınıflar ve meta-ilişkiler kullanılarak yeni bir UML lehçesinin oluşturulması OCL (Object Constraint Language) OCL [7], UML modelleri üzerinde koşturulabilecek olan sorguları ve yine aynı modeller üzerinde uygulanabilecek kısıtlama ve kontrolleri formel olarak tanımlayabilmek için geliştirilmiş bir dildir. OCL tanımları komut ve ifadeler olarak yazılırlar. Örnek bir OCL ifadesi aşağıda gösterildiği gibidir:
3. Önceki Çalışmalar Ortak Kriterler ve yazılım mühendisliği konusunda en detaylı çalışmalarda biri Mellado ve arkadaşlarına aittir [8]. Mellado ve arkadaşları Ortak Kriterler kapsamında güvenlik gereksinimleri mühendisliği için yeni bir süreç önermişlerdir. Makalelerinde teorik bilgileri anlatmış ama yaklaşımlarını destekleyecek araçlar önermemişlerdir. Ware ve arkadaşları [9], yazılım geliştirme sürecinde tasarım aşamasında güvenlik gereksinimlerinin ele alınması için farklı bir yöntem önermişlerdir. Bu yeni yöntemde, kullanım senaryolarından güvenlik gereksinimlerini elde etmek için Ortak Kriterleri kullanmışlardır. Kullanım senaryolarında aktör profillerinden faydalanmış, bunlardan güvenlik tehditlerini türetmiş, bu tehditleri güvenlik hedeflerine çevirmiş ve daha sonra da güvenlik gereksinimlerine ayrıştırmışlardır. Saeki ve arkadaşları [10] güvenlik gereksinimlerini türetmek için Ortak Kriterler bazlı benzer bir yöntem önermişlerdir. Morimoto ve Cheng [11] Ortak Kriterler için daha önceden sertifikalanmış olan koruma profilleri üzerinde çalışmışlardır. Bu araştırmacılar, koruma profillerini UML kullanarak modellemeyi ve bu profil modellerinin yazılım tasarımlarında kullanılmasını önermişlerdir. Ayrıca koruma profillerinin Z ile önerme ispatı yöntemi kullanarak doğrulanabileceğini belirtmişlerdir. UML ve OCL yazılım geliştirme süreçlerinde çok yoğun olarak kullanılan dillerdir. Son yıllarda güvenli yazılım geliştirme süreçlerinin de bir parçası haline gelmişlerdir. UML in yazılımların güvenlik ihtiyaçlarının ve özelliklerinin modellenmesinde kullanılması amacıyla çok çeşitli profil önerileri bulunmaktadır. Bu önerilerin en önde gideni Jurjens in önerdiği UMLsec tir [12]. Peralta ve arkadaşları da [13] UML i çeşitli güvenlik ile alakalı şablonlar kullanarak genişletmişler ve bu yeni gösterimi UML modellerinden otomatik olarak test vakaları üretmek için kullanmışlardır. Guadalo ve Seret [14] ise bilgi sistemleri güvenliği üzerinde çalışmış, UML i gizlilik, güven ve rol tabanlı erişim kontrolü şablonları ile genişletmişlerdir. Villarroel ve arkadaşları [15] veri ambarlarında veri gizliliği problemleri üzerinde incelemeler yapmış ve Secure Data Warehouses (SECDW) adında yeni bir UML profili önermişlerdir. Ayrıca bu çalışmada OCL i de yeni veri tipleri ile genişletmiş ve aktif olarak kullanmışlardır. Sohr ve arkadaşları [16] rol bazlı erişim kontrolü için UML/OCL tabanlı bir yetki motoru ve doğrulama çerçevesi geliştirmiş ve bunu web servislerinin güvenlik poliçeleri için kullanmışlardır. Pavlich ve arkadaşları [17] UML in erişim kontrolü için biçimsel olarak yeterli olmadığını belirtmiş ve rol bazlı, isteğe bağlı ve zorunlu erişim kontrolleri için yeni şemalar önermişlerdir. Lodderstedt ve arkadaşları [18] de erişim kontrolü amacıyla yeni bir UML profili (secureuml) önermişlerdir. Poniszewska Maranda [19] rol bazlı erişim kontrolü konusuna farklı bir açıdan yaklaşmış, yeni bir UML profili kullanmadan güvenlik kısıtlarının standart UML modeli üzerinde gösterimi üzerine çalışmıştır. Poniszewska Maranda bu çalışmada UML ile birlikte OCL de kullanmıştır. Fernandez Medina ve arkadaşları da [20] OCL kullanan araştırmacılardandır. OCL i genişleterek yeni bir dil (Object Security Constraint Language - OSCL) önermiş ve bunu güvenli veri tabanı tasarımı konusunda kullanmışlardır. Mehr ve Schreirer [21] servis odaklı mimarilerde güvenlik ihtiyaçları konusunda çalışmışlar ve mevcut yaklaşımların tasarım sırasında mesaj güvenliği konusunun ele alınmasında yeterli olmadığını düşünmüşlerdir. Bu amaçla UML profillerini, UML şablonlarını ve OCL i incelemişler ve sonuçta mesaj güvenlik ihtiyaçları için modelden ayırdıkları bir mesaj gü-
venlik poliçesi dosyası önermişlerdir. Bu poliçeyi de modele genişletilmiş OCL kullanarak entegre etmişlerdir. Buchholtz ve arkadaşları [22], UML şemalarını process calculus e çevirme amacıyla bir UML profili (For-LySa) yaratmışlardır. Daha sonra bu veriyi otomatik kimlik doğrulaması analizi için kullanmışlardır. Peterson ve arkadaşları [23] UML sınıf şemalarının içine güvenlik ihtiyaçlarını gömmek amacıyla yeni bir UML profili önermişlerdir. Breu ve arkadaşları [24] ve Alam ve arkadaşları da [25] servis odaklı mimarilerde güvenlik ihtiyaçlarının modellenmesi için SECTET ve SECTET-PL UML profillerini önermişlerdir. 4. Sertifikasyon Sürecinde UML, OCL ve Formel Metotlar Ortak Kriterler sertifikasyon sürecinde farklı aşamalarda farklı teminatlar aranmaktadır. Şekil 3 bu teminat noktalarını ve teminat gereksinimlerini anlatmaktadır. fonksiyonel özellikler, yazılım tasarımı, yazılım kodu ve bunların birbirleri ile uyumu için teminatları göstermelidir. Ortak Kriterler de teminat seviyesi yükseldikçe kontrol edilmesi gereken teminat gereksinimlerinin de seviyesi artar. EAL7 teminat seviyesinde aşağıdaki ana gereksinimler beklenmektedir: ADV_FSP.6: Yazılım geliştirici, yazılımın fonksiyonel özelliklerini formel bir şekilde göstermelidir, ayrıca fonksiyonel özelliklerin güvenlik gereksinimleri ile ilişkisini belirtmelidir. ADV_SPM.1: Yazılım geliştirici, formel güvenlik poliçe modeli sunmalıdır, ayrıca her bir poliçenin hangi güvenlik gereksinimlerini karşıladığını göstermelidir. Güvenlik poliçesi ve yazılımın fonksiyonel özellikleri arasındaki uyumluluğu göstermeli ve formel olarak ispat etmelidir. ADV_TDS.6: Yazılım geliştirici, ürünün formel tasarımını sunmalıdır, ayrıca, bu tasarım ile ürünün fonksiyonel özellikleri arasındaki uyumluluğu formel olarak ispat etmelidir. EAL7 seviyesinde sertifikasyon sürecini kolaylaştırmak amacıyla aşağıdaki metotları önermekteyiz: Şekil 3. Ortak Kriterler Teminat Noktaları Ürün sağlayıcı firma, güvenlik problemi, güvenlik amaçları, güvenlik gereksinimleri, 1. UML analiz modeli üzerinden güvenlik tehditlerinin belirlenmesi 2. Belirlenen güvenlik tehditlerinden güvenlik amaçlarının türetilmesi 3. Güvenlik amaçlarından güvenlik gereksinimlerinin türetilmesi 4. Güvenlik gereksinimlerini sağlayan fonksiyonel tasarımın UML ile hazırlanması 5. Güvenlik poliçe modelinin OCL ile hazırlanması 6. Güvenlik poliçe modelinin fonksiyonel tasarım üzerinde formel olarak doğrulanması 7. Uygulama tasarımının UML ile hazırlanması
8. Uygulama tasarımı ve fonksiyonel tasarım arasındaki uyumluluğun OCL ile gösterilmesi Bu bildiride 4, 5 ve 6. adımlara odaklanılmakta ve örnekler üzerinde UML ve OCL kullanımı ve formel metotlar ile doğrulamanın nasıl yapıldığı anlatılmaktadır. 4. Örnek Çalışma Bu örnekte, bir yazılım kütüphanesinin aşağıdaki Ortak Kriterler güvenlik gereksinimlerine uyumluluğu incelenmektedir: FAU_GEN.1.1: Uygulama, aşağıdaki denetlenebilir etkinlikler için bir denetim kaydı oluşturabilmelidir: o Denetim fonksiyonlarının o başlangıç ve bitişlerinde Minimum denetim seviyesi için tüm denetlenebilir etkinliklerde FAU_SAA.1.1: Uygulama, denetlenen etkinlikler üzerinde bir kurallar kümesi koşturabilmeli ve bu kurallara göre güvenlik gereksinimlerine aykırı potansiyel ihlalleri belirleyebilmelidir. FAU_ARP.1.1: Uygulama, potansiyel güvenlik ihlale belirlendiğinde alarm vermelidir. UML ile Fonksiyonel Tasarım Uygulamanın fonksiyonel tasarımı UML kullanım senaryosu modeli ile gösterilmektedir. Bu örnek modelde aşağıdaki temel fonksiyonlar modellenmiştir: Log: Uygulamanın denetim fonksiyonlarına ve denetlenebilir fonksiyonlarına ait etkinliklerin kayıt altına alınmasını sağlar. ConfigureAudit: Denetim mekanizmasının ayarlarının değiştirilmesini sağlayan denetim fonksiyonudur. Register: Yeni kullanıcı kaydı yaratılmasını sağlayan denetlenebilir fonksiyondur. Şekil 4. Fonksiyonel Tasarım Modelin anlamlandırılması için aşağıdaki UML şablonları kullanılmıştır: <<AuditFunction>>: Denetim fonksiyonlarını gösterir <<AuditableEvent>>: Denetlenebilir fonksiyonları gösterir <<AuditLogFunction>>: Denetim kaydını yapan fonksiyonu gösterir <<PotentialViolationAnalysis>>: Potansiyel ihlal analizi yapan fonksiyonu gösterir Bu şablonların anlatıldığı UML profili aşağıdaki şekilde sunulmuştur. Şekil 5. UML Profili - Bölüm 1 ConfigureAudit fonksiyonuna ait aktivite modeli aşağıdaki şekilde anlatılmıştır.
eventtype adında bir etiketli değeri vardır. Bu etikette kayıt edilecek etkinliğin tipi belirtilmektedir. Log fonksiyonuna ait aktivite modeli aşağıdaki şekilde anlatılmıştır. Şekil 6. ConfigureAudit Aktivite Modeli Aktivite modelinde ilk ve son aktiviteler denetim kaydı oluşturma fonksiyonunu çağırmaktadır (CallBehaviourAction). Bu aktiviteler <<LogEvent>> UML şablonu ile işaretlenmiştir. <<LogEvent>> UML şablonu aşağıdaki şekilde anlatılmıştır. Şekil 8. Log Aktivite Modeli Aktivite modelindeki aktivitelerden üçüncüsü güvenlik ihlal analizi yapan fonksiyonu çağırmaktadır (CallBehaviourAction). Bu aktivite <<AnalyseLog>> UML şablonu ile işaretlenmiştir. OCL ile Güvenlik Poliçesi Uygulamanın sağlaması gereken güvenlik gereksinimleri FAU_GEN.1.1, FAU_SAA.1.1, FAU_ARP.1.1 için bir güvenlik poliçesi oluşturulması ve bu poliçenin fonksiyonel tasarım ile uyumluluğunun kontrol edilmesi gerekmektedir. Güvenlik poliçesi OCL kullanılarak oluşturulmaktadır. Şekil 7. UML Profili - Bölüm 2 <<LogEvent>> UML şablonunun FAU_GEN.1.1 gereksinimini kontrol eden OCL ifadeleri aşağıda verilmiştir.
Şekil 9. OCL İfadesi Bölüm 1 Yukarıdaki OCL ifadesi, fonksiyonel tasarım modeli üzerinde, her bir denetim fonksiyonunun denetim kayıt fonksiyonunu çağırıp çağırmadığını kontrol eder. Şekil 10. OCL İfadesi Bölüm 2 Yukarıdaki OCL ifadesi, fonksiyonel tasarım modeli üzerinde, her bir denetim fonksiyonu kullanım senaryosu için bir aktivite modeli olup olmadığını kontrol eder. Şekil 11. OCL İfadesi - Bölüm 4 Yukarıdaki OCL ifadesi, fonksiyonel tasarım modeli üzerinde, her bir denetim fonksiyonu aktivite modeli için, fonksiyon başlangıcı ve bitişi etkinliklerinin denetim kaydının oluşturulup oluşturulmadığını kontrol eder. Denetim fonksiyonları için hazırlanan bu OCL poliçelerinin benzerleri, denetlenebilir fonksiyonlar için de hazırlanmıştır. Formel Model Doğrulama Bazı güvenlik gereksinimleri statik olarak kontrol edilememektedir. Örneğin FAU_SAA.1.1, güvenlik ihlallerinin denetim kayıtları üzerinden belirli kurallara göre tespit edilmesini beklemektedir. Aşağıdaki UML aktivite modelinde güvenlik ihlali tespiti için bir kural verilmiştir. Şekil 12. Güvenlik İhlali Tespiti İçin Örnek Kural Bu kural 3 kere üst üste LoginEvent hatası alındığında potansiyel ihlal alarmı üretmektedir (FAU_ARP.1.1). Ancak, aktivite modelinde gösterilen bu kuralın belirtildiği gibi çalışıp çalışmadığı, aktivite geçişlerindeki koşulların doğru tanımlanıp tanımlanmadığı detaylı inceleme yapılmadan anlaşılamamaktadır. Aktivite geçişleri uygulama davranışı ile ilgili kurallar içerdiği için de statik olarak OCL ifadeleri ile kontrol işe yaramamaktadır. Uygulama davranışı ile ilgili güvenlik gereksinimlerinde, UML modelini PROMELA ya çevirip güvenlik poliçesini LTL (Linear Temporal Logic) ifadesi olarak yazmakta ve SPIN aracı kullanarak model doğrulaması önermekteyiz. LTL ile yazılmış örnek bir güvenlik poliçesi aşağıda gösterilmiştir: [] ((eventcount==3) -> (state==sendpotentialviolationevent)) SPIN, verilen PROMELA modeli üzerindeki tüm durum uzayına bakarak, eventcount değeri 3 olduğunda, uygulamanın istenmeyen bir durumda olup olamayacağını inceler ve sonuçları raporlar. 7. İleri Çalışmalar ve Öneriler Bu bildiride, Ortak Değerler güvenlik sertifikasyon sürecinde hazırlanması beklenen fonksiyonel tasarım ve güvenlik poliçesinin UML ve OCL ile nasıl hazırlanabileceği gösterilmiştir. Hazırlanan fonksiyonel modelin güvenlik poliçesindeki güvenlik gereksinimlerine uyumluğunun kontrol edilebilmesi için statik
ve dinamik metotlar önerilmiştir. Yapılan çalışmada Ortak Kriterler de bahsedilen güvenlik kriterlerinin küçük bir alt kümesi üzerinde çalışılmış ve gelecekte bu kapsamın genişletilmesi planlanmıştır. Kaynaklar [1] CCRA, Common Criteria Part 1: Introduction and General Model, http://www.commoncriteriaportal.org/thecc.html. [2] CCRA, Common Criteria Part 2: Security Functional Requirements, http://www.commoncriteriaportal.org/thecc.html. [3] CCRA, Common Criteria Part 3: Security Assurance Requirements, http://www.commoncriteriaportal.org/thecc.html. [4] Ben-Ari, M., Principles of the Spin Model Checker, Springer, 2008. [5] OMG UML Specifications, http://www.omg.org/spec/uml/. [6] UML Profile Diagrams, http://www.uml-diagrams.org/profile-diagrams.html. [7] OMG OCL Specifications, http://www.omg.org/spec/ocl/. [8] Mellado, D., E. Fernandez-Medina and M. Piattini, A Common Criteria based Security Requirements Engineering Process for The Development of Secure Information Systems, Computer Standards and Interfaces,, No. 29, pp. 244 253, 2007. [9] Ware, M. S., J. B. Bowles and C. M. Eastman, Using the Common Criteria to Elicit Security Requirements with Use Cases, Proceedings of IEEE, pp. 273 278, March 2005. [10] Saeki, M. and H. Kaiya, Using Common Criteria as Reusable Knowledge in Se- curity Requirements Elicitation, Modeling Security Workshop, Models 08, 2008. [11] Morimoto, S. and J. Cheng, Patterning Protection Profiles by UML for Security Specifications, Proceedings of the 2005 International Conference on Computa- tional Intelligence for Modeling, 2005. [12] Jurjens, J., UMLsec: Extending UML for secure systems development, UML 2002 - The Unified Modeling Language, Vol. 2460, pp. 412 425, Springer, 2002. [13] Peralta, K. P., A. M. Orozco, A. F. Zorzo and F. M. Oliveira, Specifying Security Aspects in UML Models, Proceedings of the Workshop on Modeling Security, 2008. [14] Goudalo, W. and D. Seret, Toward the Engineering of Security of Information Systems (ESIS): UML and the IS Confidentiality, The Second International Con- ference on Emerging Security Information, Systems and Technologies, 2008. [15] Villarroel, R., E. Fernandez-Medina, M. Piattini and J. Trujillo, A UML 2.0/OCL Extension for Designing Secure Data Warehouses, Journal of Research and Prac- tice in Information Technology, Vol. 38, No. 1, February 2006. [16] Sohr, K., T. Mustafa, X. Bao and G. J. Ahn, Enforcing Role-Based Access Control Policies in Web Services with UML and OCL, Annual Computer Security Applications Conference, 2008. [17] Pavlich-Mariscal, J., L. Michel and S. Demurjian, Enhancing UML to Model Custom Security Aspects, Proceedings of Aspect Oriented Modeling, 2007. [18] Lodderstedt, T., D. Basin and J. Doser, SecureUML: A UML-Based Modeling Language for Model-Driven Security, Lecture notes in computer science, 2002. [19] Poniszewska-Maranda, A., Security Constraints in Access Control of Information
System Using UML Language, Proceedings of the 15th IEEE International Work- shops on Enabling Technologies:Infrastructure for Collaborative Enterprises, 2006. [20] Fernandez-Medina, E., M. Piattini and M. A. Serrano, Specification of Security Constraint in UML, IEEE 35th International Carnahan Conference on Security Technology, pp. 163 171, 2001. [21] Mehr, F. and U. Schreirer, Modelling of Message Security Concerns with UML, 9th International Conference on Enterprise Information Systems, 2007. [22] Buchholtz, M., C. Montangero, L. Perrone and S. Semprini, For-LySa: UML for Authentication Analysis, Global Computing: IST/FET International Workshop, 2004. [23] Peterson, M. J., J. B. Bowles and J. M. Eastman, UMLpac: An Approach for Integrating Security into UML Class Design, Proceedings of IEEE, pp. 267 272, March 2005. [24] Alam, M., M. Hafner and R. Breu, A constraint based role based access control in the SECTET a model-driven approach, Proceedings of the 2006 International Conference on Privacy, Security and Trust: Bridge the Gap Between PST Tech- nologies and Business Services, 2006. [25] Breu, R., M. Hafner, F. Innerhofer-Oberperfler and F. Wozak, Model-Driven Security Engineering of Service Oriented Systems, Information Systems and ebusiness Technologies, Vol. 5, pp. 59 71, 2008.