Arşiv | Yazılım Geliştirme RSS feed for this section

Yazılım Geliştirme Süreci ve Güvenli Yazılım Geliştirme

14 Ara

Yazılımların hayatımızdaki yeri ve öneminin gün geçtikçe artması yazılımlara ilişkin çalışmaları hızlandırmakta, bu durum yeni yazılım geliştirme yöntemleri, programlama kuralları veya programlama dilleri ve araçları ortaya çıkarmaktadır. Tüm bu gelişmelere rağmen yazılım projelerinde tasarlanan zamanın gerisinde kalma, bütçeyi aşma, düşük kalite, sürekliliği ve güvenilirliği sağlayamama, kullanıcı taleplerinin karşılanmasında yetersizlik gibi problemlerle sıkça karşılaşılmaktadır. Gartner araştırmasına göre bilişim güvenliği ihlallerinin yazılım güvenliği problemlerinden kaynaklananlarının oranı %80’dir [1]. Genel olarak problemlerin çoğu, yazılım geliştirme sürecinin en başında gereksinim ve sistem analizlerinin doğru ve yeterli yapılmamasından kaynaklanmaktadır. Analiz konusunda yetersiz kalan yazılımlar güvenlik riski oluşturmakta, bu durum bilgiye yönelik tehditlerin ortaya çıkmasında önemli bir açıklık oluşturmaktadır.

Bilginin gizliliği, bütünlüğü ve erişilebilirliğini, kısaca bilgi güvenliğini hedefleyen tehditlerle mücadele için yazılımlarda bilgi güvenliğinin sağlanmış olması gerekmektedir. Bilgi güvenliği;  karşılaşılabilecek tehditlerin farkında olunması,  işlerin devamlılığını sağlama, yaşanabilecek her türlü problemlerde kayıpları en aza indirme, firmaların varlıklarının her koşulda gizliliği, erişebilirliği ve bütünlüğünü korunma amaçları taşımaktadır. Bu kapsamda ortaya çıkartılan ve sürekli geliştirilmekte olan bir süreç de “Bilgi Güvenliği Yönetim Sistemi (BGYS)” dir.

Yazılımlarda bilgilerin korunması yazılımın geliştirme sürecinin başından itibaren tüm aşamaların bilgi güvenliği kontrollerine uygun olarak gerçekleşmesine bağlıdır. Yazılımın geliştirme sürecinde bilgi güvenliği yönetim sisteminin sağlanmış olması, yazılımlardaki bilgilerin kullanıma hazır olduğunu, sadece yetkisi olanların erişebildiğini ve kullanılan bilginin doğru ve güncel olduğu anlamına gelmektedir.

Bu çalışmanın ikinci ve üçüncü bölümünde yazılım, yazılım geliştirme süreçleri ve güvenli yazılım geliştirmeye ilişkin bilgilere yer verilecektir. Dördüncü bölümde uluslararası bir standart olan “ISO/IEC 27001 Bilgi Teknolojileri- Güvenlik Teknikleri-Bilgi Güvenliği Yönetim Sistemi- Gereksinimler Standardı (ISO 27001)” ele alınacak, sonrasında ISO 27001’in yazılım geliştirme süreçleriyle ilişkili kontrol maddelerine ve sonuç bölümüne yer verilecektir.

Yazılım Geliştirme Süreçleri

Yazılım kelimesinin sözlük anlamına bakıldığında; yazılım, “bir bilgisayarda donanıma hayat veren ve bilgi işlemde kullanılan programlar, yordamlar, programlama dilleri ve belgelemelerin tümü” olarak ifade edilmektedir [2] . Yazılım ayrıca, mevcut bir problemi çözmek amacıyla değişik cihazların birbirleriyle haberleşebilmesini sağlayan ve görevlerini ya da kullanılabilirliklerini geliştirmeye yarayan bilgisayar dili kullanılarak oluşturulmuş anlamlı ifadeler bütünü olarak da nitelendirilebilir [3]. Yazılım ile ilgili bu tanımlamalar daha çok kod ile ilgilenirken yazılım geliştirme, bilinenin aksine sadece kodlama değildir. Birkaç tane kullanıcı ekranı tasarlayıp, bu ara yüzlerin arkasına kod yazarak ve veritabanı ilişkisi kurularak yazılım geliştirme süreci tamamlanamaz. Bu işlemler yazılım geliştirme sürecinin sadece bir bölümü olup, toplamda yazılım geliştirme süreci kodlama yapmaktan çok daha fazlasıdır [4]. Bu bakımdan yazılım geliştirme, yazılımın hem üretim hem de kullanım süreci boyunca geçirdiği tüm aşamalar olarak tanımlanabilir.

Geçmişte yazılım geliştirmede başvurulan iş akış şemaları gibi yöntemler günümüzde gereksinimleri karşılayamadıklarından etkinliklerini yitirmişlerdir. Bu yöntemler özellikle güvenlik odaklı olmadıklarından yetersiz kalmışlardır. Yazılımın her aşamasında güvenliğe ilişkin ortaya çıkabilecek problemleri gözeten etkin bir geliştirme süreci sonuç ürünün daha güvenilir olmasına önemli katkı sağlayacaktır.

Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar sürekli bir döngü biçiminde ele alınmaktadır. Böylece döngü içerisinde her hangi bir aşamada geriye dönmek ve tekrar ilerlemek söz konusudur [5]. Yazılım geliştirmede çok sayıda farklı model ve süreç değerlendirmelerinden söz etmek mümkündür. Bununla birlikte; yazılım mühendisliğindeki diğer modellere temel teşkil eden “Çağlayan Modeli (Waterfall Model)” yazılım yaşam döngüsünü analiz, tasarım, kodlama, test ve bakım olmak üzere beş aşamada ele almaktadır [6].

Analiz

Bir problemin çözümü olarak nitelediğimiz yazılımların ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama analiz aşamasıdır. Yazdığınız kod ancak isteneni doğru bir biçimde yerine getiriyorsa başarılı bir yazılımdır. Bu nedenle öncelikle yazılımdan ne istendiğinin doğru bir biçimde tanımlanması gerekir. Analiz aşaması personel, donanım ve sistem gereksinimlerinin belirlenmesi, sistemin fizibilite çalışmasının yapılması, kullanıcıların gereksinimlerinin analizi, sistemin ne yapıp ne yapmayacağının kısıtlamalar göz önüne alınarak belirlenmesi, bu bilginin kullanıcılar tarafından doğrulanması ve proje planı oluşturulması adımlarından oluşur.

Tasarım

Analiz aşaması sonucunda belirlenen gereksinimlere yanıt verecek yazılımın temel yapısının oluşturulduğu aşamadır. Yazılım tasarımı, bir bileşen veya sistemin nasıl gerçekleştirileceğini belirlemek için kullanılan teknikler, stratejiler, gösterimler ve desenlerle ilgilidir. Bu aşama yazılım bileşenleri arasındaki içsel ara yüzler, mimari tasarım, veri tasarımı, kullanıcı ara yüzü tasarımı, tasarım araçları ve tasarımın değerlendirilmesi alt süreçlerini de kapsamaktadır. Tasarım aşaması, yazılımın hem kullanıcı ara yüzünü hem de programın omurgasını ortaya koymaktadır. Yapılacak tasarım, yazılımın işlevsel gereksinimlere uygun olmasının yanı sıra kaynaklar, performans ve güvenlik gibi kavramları da göz önüne alınarak gerçekleştirilmelidir.

Kodlama

Kodlama aşaması, tasarım sürecinde ortaya konan veriler doğrultusunda yazılımın gerçekleştirilmesi aşamasıdır. Bu süreç programlama çalışmalarının yanı sıra yazılımın geliştirilmesi ve kullanıcıya ulaştırılması sürecindeki bütün çalışmaları kapsar. Tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışması olarak da nitelendirilebilir [5]. Yazılım geliştirme ortamı, programlama dili, veri tabanı yönetim sistemi, yazılım geliştirme araçları seçimi kodlama aşamasında gerçekleştirilir.

Test

Test aşaması, yazılım kodlanması sürecinin ardından gerçekleştirilen sınama ve doğrulama aşamasıdır. Elde edilen uygulama yazılımının hem belirlenen gereksinimleri sağlayıp sağlamadığı hem de gerçekleştirimin beklentilere uygun olup olmadığını kontrol etmek için statik ve dinamik sınama tekniklerinden yararlanır. Statik teknikler, yazılımın tüm yaşam döngüsü boyunca elde edilen gösterimlerin analizi ve kontrolüyle ilgilenirken, dinamik teknikler sadece gerçekleştirilmiş sistemi içerir. Yazılım üretiminde ilk testler genelde geliştirme sürecinde programcı tarafından yapılır. Bununla birlikte, asıl hata ayıklama ve geribildirim hizmeti test ekipleri tarafından yapılır. Testler ve geribildirim müşteri yazılımı kullandığı sürece devam eder. Test sürecinde en faydalı geribildirimler son kullanıcı test gruplarından gelir.

Bakım

Yazılımın tesliminden sonra hata giderme ve yeni eklentiler yapma aşamasıdır. Yazılımın kullanıma başlanmasından sonra yazılımın desteklenmesi sürecini kapsar. Yazılımın eksiklerinin giderilmesi, iyileştirilmesi gibi alt aşamaları içeren aşamadır.

Güvenli Yazılım Geliştirme

Yazılımların yaygın olarak kullanılmaya başlandığı ilk yıllarda kaliteli ve olgun yazılım üretmek, son yıllarda ise özellikle güvenli yazılım geliştirmek için çok sayıda model ve çerçeve üzerinde çalışılmıştır. Bu durumun en büyük tetikleyicisi son yıllarda güvenlik açıklıklarının artmasıdır [7]. Artan bu güvenlik tehditleri Şekil 1’de görüldüğü üzere hiç hesaba katılmayan sürpriz maliyetleri de beraberinde getirmektedir. Yazılım geliştirmede erken bir süreçte farkına varılan yazılım açıklıklarının düzeltilmesinin daha ileri süreçlerde farkına varılan açıklıklara göre daha az maliyetli olacağı yazılım endüstrisince yaygın olarak kabul edilen bir ilkedir [8]. Bu ilke yazılım geliştirme sürecinin güvenli olmasının maliyet açısından da ne denli önemli olduğunun göstergesidir.

ekil_1.jpg

Şekil 1 – Yazılım Geliştirme Süreçlerinde Yazılım Açıkları Giderme Maliyeti [8]

Yazılım güvenliği kavramı ile ilgili yapılan en önemli yanlış güvenliği sadece kodun güvenliği ve ek olarak da yetkilendirme güvenliği ile sınırlandırmaktır. Halbuki yazılım güvenliği kavramını “güvenilir bilişim” (trusted computing) kavramı ile yakından ilişkilendirmek gerekmektedir. “Trusted Computing Group” tarafından konmuş olan güvenilir bilişim kavramı gizlilik, bütünlük, erişebilirlik, ve kurtarılabilirlik olmak üzere dört temel kavram üzerinde durmaktadır [9].

Güvenli yazılım geliştirme süreçlerinde ayrıca değişiklik ve konfigürasyon yönetimi, geliştirme, test ve üretim ortamı ayrışımı, geliştirme ortamında gerçek verilerin kullanılmaması, üretim ortamına almadan önce kod incelemesi, güvenli programlama teknikleri kullanımı, uygulama güvenlik duvarı kullanımı ya da kaynak kod inceleme hizmeti alınması gibi çalışmaların yapılması da güvenliğe ayrıca katkı sağlayacaktır [1].

Güvenli yazılım geliştirme sürecinde ele alınması gereken temel olarak dokuz ana güvenlik konusu vardır [10]:

1.Girdi Geçerleme (Input Validation):

Günümüzde bilinen ve gelecekte de muhtemel tehditlerin çoğu kötü niyetli girdi ile başlamaktadır. Bununla birlikte; basit girdi geçerleme yöntemleri ile büyük güvenlik tehditlerinin önlenmesi mümkündür.

Girdi geçerleme yöntemlerini “beyaz kutu” ve “kara kutu” olmak üzere ikiye ayırmak mümkündür. Beyaz kutu yönteminde bilinen bir şablon girdi olarak kullanılmakta, bu şablonun dışındaki tüm girdiler kötü niyetli olarak kabul edilmektedir. Şablonun kontrolü çok kolay olduğundan bu yöntem oldukça etkili bir yöntemdir. Kara kutu yöntemi ise daha az etkili olmasına rağmen daha çok tercih edilen bir yöntemdir. Bu yöntemde kullanılan belirli bir şablon yoktur, sadece bilinen saldırıların bir listesi mevcuttur. Eğer girdi bilinen bir saldırıya benziyor ise o zaman girdi reddedilecek, onun dışındaki tüm girdiler ise kabul edilecektir. Bugün bile tüm atak çeşitlerini belirlemek zor iken gelecekteki atakları bilip filtrelemek daha da zor olacağından bu yöntemin etkinliğinin az olduğu açıktır. Dolayısıyla veri yapıları, mümkün olduğunca belli bir şablona uygun tasarlanarak geçerleme daha güçlü kılınmalıdır.

İstemci-sunucu uygulamalarında geçerleme hem istemci hem de sunucu tarafında yapılabilmektedir. Bununla birlikte; bir saldırgan istemci tarafındaki geçerleme kontrolünü kolay aşabileceğinden istemci tarafındaki geçerleme hiçbir zaman yeterli bir güvenlik önlemi olarak ele alınmamalıdır. Bunun yerine daha çok sunucu tarafında geçerleme kontrolü yapılarak güvenlik seviyesi arttırılmalıdır. Kısaca güvenilir olmayan bir kaynaktan (örneğin kullanıcıdan) gelen veri mutlaka onaylanmalıdır.

2.Kimlik Doğrulama (Authentication):

Kimlik doğrulama,  varlıkların (kullanıcı, cihaz veya bir uygulama) kimlik kontrolünden geçmesi işlemidir ve farklı kimlik doğrulama yöntemleri bulunmaktadır.

Genellikle yazılımlar önceleri sadece kullanıcı adı ve şifre kullanması şeklinde zayıf doğrulama yöntemleri kullanılmakta idi. Eğer bir “domain” yapısı varsa, kullanıcılar “Active Directory” kullanılarak doğrulanmakta, “domain” dışında ise kimlik yönetimine ilişkin veritabanı uygulanmaktadır. Daha güçlü doğrulama yöntemleri olarak da biometrik metotlar veya akıllı kartlar kullanılmaktadır. Bir diğer doğrulama yöntemi ise üçüncü bir tarafın doğrulama işini yapması ve bu üçüncü tarafa güven duyulması şeklindedir.

3.Yetkilendirme (Authorization):

Kullanıcıların tanımlanması aşaması olan kimlik doğrulamadan sonra kullanıcının kimliği doğrultusunda erişim haklarının belirlendiği ve kontrolünün gerçekleştiği aşama yetkilendirmedir. Hangi yetkilerle işlem yapılacağını belirlemek için bir çok yöntem bulunmaktadır.

4.Konfigürasyon Yönetimi  (Configuration Management):

Konfigürasyon, uygulama ile ilgili hassas bilgileri içermektedir. Örnek vermek gerekirse veri tabanına erişim için gerekli bağlantı bilgilerini içeren dosyalar bu kapsamdadır. Konfigürasyona müdahale uygulamanın işleyişini değiştirebilir veya çalışmamasına sebep olabilir. Konfigürasyon dosyalarının sunucularda saklanıyor olması yeterli güvenlik önlemlerinin alındığı anlamına gelmemektedir. Konfigürasyon dosyaları hassas bilgi olarak nitelendirilmeli, şifrelenmiş bir şekilde tutulmalı ve bu dosyalara erişim kayıt altında tutulmalıdır.

5.Hassas Bilgi (Sensitive Information):

Hassas bilginin ne olduğunun belirlenebilmesi için uygulamanın ve işin bir arada ele alınması gerekir. Uygulama geliştirici işin niteliğini tam olarak bilemediğinden, diğer yandan işin sahibi de uygulamanın teknik altyapısı hakkında sınırlı bilgiye sahip olacağından bu iki taraf tek başlarına hassas bilgi için yeterli tanımlama yapamayacaklardır. İki tarafın bir araya gelmesiyle hassas bilgileri içeren bir liste oluşturulmalı ve bu listeyi koruyacak bir politika oluşturulmalıdır.

6.Kriptografi (Cryptograhy):

Veriyi korumanın yollarından biri de şifrelemedir. Bugün şifreleme çalışmaları oldukça ilerlemiş, bilgisayarlar oldukça gelişmiştir. Fakat bu durum saldırganlar için de geçerlidir. Hassas bilgiler bilinen ve test edilmiş şifreleme yöntemleri ile saklanmalıdır. Ayrıca daha önce kırılması uzun zaman alan algoritmalar günümüzde daha kısa zamanda çözülebilmektedir. Dolayısıyla uygulama içindeki algoritmalar zamanla gözden geçirilmeli ve güncellenmelidir.

7.Parametre Manipülasyonu (Parameter Manipulations):

Dağıtık algoritmalar modüller arasında parametre gönderirler. Eğer bu parametreler arada değiştirilirse, saldırı gerçekleştirilmiş olur. 1 dolara satın alınan Ferrari bu duruma bir örnektir. Borcun belirlenmesi için web formu kullanan uygulama bu formdaki rakamın http proxy kullanılarak manipüle edilmesi sonucu değer 1 dolara olarak değiştirilmiştir.

8.Hata Yönetimi (Exception Management):

Bazı teknolojiler hataları kullanarak hata yönetimi gerçekleştirmektedirler. Hatalar geliştiriciler ve sistem yöneticileri için uygulama ile ilgili birçok önemli bilgi ihtiva ettiği için çok önemlidirler. Bununla birlikte; geliştirici için bu derece önemli olan bilgi kullanıcı açısından problem oluşturabilmektedir. Her ne kadar kullanıcılar bu hataların ne demek olduğunu anlamasalar da saldırganlar için büyük ipuçları, yazılımla ilgili önemli bilgiler içermektedir. Bundan dolayı sadece genel bir hata mesajının dönmesi, hataların kayıt altında tutulması ve gerçek hataya sadece yöneticiler ulaşmasını sağlayacak sürecin oluşturulması gerekmektedir.

9.Kayıt Tutma ve Denetim (Logging and Auditing):

Uygulama veya uygulamanın yöneticileri saldırı altında olduklarını anlamalıdır. Bu durum aslında neyin normal neyin anormal olduğunun belirlenmesi ile sağlanır. Bir uygulamaya ilişkin normal süreç ve şablon tanımlanmalı ve bunu dışında bir olay olduğunda saldırı ihtimali ele alınmalıdır. Örneğin, normal senaryoda bir uygulamaya dakikada ortalama beş kişinin erişmesi beklenirken bu sayı bine ulaşıyorsa muhtemelen bir “Servis Dışı” bırakma atağı söz konusudur.

Yukarıdaki ve bunlara benzer onlarca tehdit güvenilir uygulamalar geliştirmek için yazılım geliştirme sürecinin güvenliğinin yönetilmesinin büyük önem arz etmekte olduğunu gözler önüne sermektedir.

ISO 27001 Bilgi Güvenliği Yönetim Sistemi

Bilgi güvenliği, yazılı, sözlü, elektronik ortam gibi farklı ortamlardaki bilginin gizlilik, bütünlük ve erişebilirlik bakımından güvence altına alınması ve bu güvence durumunun sürekliliğinin sağlanmasıdır.

Bilgi sistemlerinin hayata geçmesiyle ortaya çıkan depolama ve işleme imkânlarının artması, izinsiz erişimler, bilginin yetkisiz imhası, yetkisiz değiştirilmesi veya yetkisiz görülmesi ihtimallerinin artması gibi hususlar nedeniyle bilgi güvenliği kavramı gündeme gelmektedir.

Bilgi hangi biçime girerse girsin veya ne tür araçlarla paylaşılır veya depolanır olursa olsun, her zaman uygun bir şekilde korunmalıdır. Bilgi sistemlerinin çoğu, bilgi saklanırken, paylaşılırken, gönderilirken güvenlik kaygıları düşünülerek tasarlanmamıştır. Kurumların sahip oldukları bilgi doğru tasarlanmamış sistemler nedeniyle pek çok çeşitli tehditlere karşı açık durumdadır.

Bilgi güvenliği ihlali ve buradan doğacak kayıpların riskini minimize etmek kurulan sistemlerin en başında BGYS gelmektedir. BGYS, bilgi güvenliğini kurmak, işletmek, izlemek ve geliştirmek için iş riski yaklaşımına dayalı, dokümante edilmiş, işlerliği ve sürekliliği garanti altına alınmış bir yönetim sistemidir.

BGYS kurumunuzdaki tüm bilgi varlıklarının değerlendirilmesi ve bu varlıkların sahip oldukları zayıflıkları ve karşı karşıya oldukları tehditleri göz önüne alan bir risk analizi yapılmasını gerektirir [11].

BGYS, bağımsız kuruluşların ya da tarafların ihtiyaçlarına göre özelleştirilmiş güvenlik kontrollerinin gerçekleştirilmesi için gereksinimleri belirtir. BGYS’nin ihtiyaç duyduğu gereksinimlere cevap vermek için çok sayıda standart vardır. Bunların en önde geleni ISO 27001 standardıdır.

PUKÖ Modeli

ISO 27001 kurumların bilgi güvenliği yönetim sistemi kurmaları için gereklilikleri tanımlayan tek denetlenebilir BGYS standardıdır. ISO 27001 ülkelere göre özel tanımlar içermeyen, genel tanımların bulunduğu uluslararası standardıdır. ISO 27001 standardı; kuruluşların kendi bilgi güvenlik sistemlerini sağlamasını mümkün kılan teknoloji tarafsız, satıcı tarafsız yönetim sistemleri için bir çerçeve sağlar.

ISO 27001, kuruma uygun politikalar, prosedürler ve kılavuzlar oluşturmaya yol gösteren uluslararası kabul görmüş yapısal bir metodoloji sunar. ISO 27001 sertifikası, kurumların güvenlik seviyesine ve kurumun konuya ciddi yaklaşımına ilişkin bir göstergedir.

Bilgi güvenliği yönetimi konusunda ilk standart British Standard Institute (BSI) tarafından geliştirilen BS 7799’dur. BS 7799  “Pratik Kurallar” ve “BGYS Gerekleri” başlıklı iki kısımdan oluşmaktaydı. BS 7799 birinci kısım daha sonra ISO tarafından 2000 yılında “ISO 17799” olarak kabul edilmiştir. 2002’de BSI; BS 7799-2’yi çıkartmıştır. ISO, 2005 yılında ISO/IEC 1799:2005’i ve BS 7799-2’nin yeni hali olan ISO/IEC 27001:2005’i yayınlamıştır. ISO 27001, 2005 yılında yayınlanmasıyla yürürlüğe girmiş ve ISO/IEC 27000 standart serisi altında yerini almıştır. Söz konusu bu standart 2006 yılında Türk Standardı olarak kabul edilerek, ”TS ISO/IEC 27001 Bilgi Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenliği Yönetim Sistemleri – Gereksinimleri” adıyla yayınlanmıştır [12].

ISO 27001 yaşayan, dolayısı ile tehdit ve saldırılara reaksiyon gösteren ve kendini yenileyen bir bilgi güvenliği sisteminde yer alması gereken öğeleri tanımlamaktadır [13]. ISO 27001, BGYS’yi kurmak, işletmek, izlemek, gözden geçirmek, sürdürmek ve iyileştirmek için standart proses yaklaşımını benimsemiştir. Bu proses yaklaşımı güvenlik önlemlerinin belirlenip kurulması, uygulanması, etkinliğinin gözden geçirilmesi ve iyileştirilmesi süreçlerini ve bu süreçlerin sürekli olarak tekrarlanmasını içerir. Bu süreçler Planla, Uygula, Kontrol et, Önlem al (PUKÖ) döngüsünden oluşan bir model olarak da ortaya konmuştur.

BGYS’de kurum kendine bir risk yönetimi metodu seçmeli ve risk işleme için bir plan hazırlamalıdır. Risk işleme için standardda öngörülen kontrol hedefleri ve kontrollerden seçimler yapılmalı ve uygulanmalıdır. Şekil 2’de gösterilen PUKÖ Modeli uyarınca risk yönetimi faaliyetlerini yürütmeli ve varlığın risk seviyesi kabul edilebilir bir seviyeye geriletilene kadar çalışmayı sürdürmelidir [11].

ekil_2.jpg

Şekil 2- BGYS’nin PUKÖ Modeli [13]

PUKÖ Model’inin süreçleri aşağıdaki gibidir:

Planla: BGYS’nin kurulması

Sonuçları kuruluşun genel politikaları ve amaçlarına göre dağıtmak için, risklerin yönetimi ve bilgi güvenliğinin geliştirilmesiyle ilgili BGYS politikası, amaçlar, hedefler, prosesler ve prosedürlerin kurulması.

Uygula: BGYS’nin gerçekleştirilmesi ve işletilmesi

BGYS politikası, kontroller, prosesler ve prosedürlerin gerçekleştirilip işletilmesi.

Kontrol Et: BGYS’nin izlenmesi ve gözden geçirilmesi

BGYS politikası, amaçlar ve kullanım deneyimlerine göre proses performansının değerlendirilmesi ve uygulanabilen yerlerde ölçülmesi ve sonuçların gözden geçirilmek üzere yönetime rapor edilmesi.

Önlem Al: BGYS’nin sürekliliğinin sağlanması ve iyileştirilmesi

BGYS’nin sürekli iyileştirilmesini sağlamak için yönetimin gözden geçirme sonuçlarına dayalı olarak, düzeltici ve önleyici faaliyetlerin gerçekleştirilmesi [12].

ISO 27000 Ailesi

Bilgi güvenliği ile ilgili olarak ISO 27000 serisi güvenlik standartları, (Şekil 3) kullanıcıların bilinçlenmesi, güvenlik risklerinin azaltılması ve de güvenlik açıklarıyla karşılaşıldığında alınacak önlemlerin belirlenmesinde temel bir başvuru kaynağıdır. Bu standartlar temel ISO’nun 9000 kalite ve 14000 çevresel yönetim standartlarıyla da ilgilidir [12].

ISO 27000 standardı, ISO 27000 standartlar ailesi ile ilgili kavramların açıklanmasını sağlayan ve bilgi güvenliği yönetimine yönelik temel bilgileri içeren bir standarttır. ISO 27000 standartlarının büyük bir çoğunluğu bilenen, diğerleri ise basım aşamasında olan standartlar olarak verilebilir.

ISO/IEC 27000 standart serisi altında yer alan ve ISO 27001 için gereken güvenlik kontrollerini içeren standart; ISO/IEC 27002:2005 – Bilişim Teknolojisi – Güvenlik Teknikleri – Bilgi Güvenlik Yönetimi için Uygulama Kılavuzu’dur. Bu standardın önceki adı ISO/IEC 17799:2005’dir. 1 Temmuz 2007 tarihinde, ISO tarafından yapılan teknik bir düzenlemeyle ISO/IEC 17799:2005 standardının adı, ISO/IEC 27002:2005 (ISO 27002) olarak değiştirilmiştir [14].

ekil_3.jpg

Şekil 3- ISO 27000 Standart Ailesi [15]

Güvenlik Kontrol Alanları

ISO 27001’de BGYS oluşturmada güvenlik için gereken 11 kontrol alanı, 39 kontrol hedefi ve 133 kontrolü tanımlayan bir uygulama kılavuzudur. Bu kontrol alanları aşağıda kısaca açıklanmaktadır [16]:

  1. Güvenlik Politikası: Bilgi güvenliği için yönetimin desteğini ve katılımını sağlamak, bilgi güvenliğinin önemini vurgulamak
  2. Bilgi Güvenliği Organizasyonu:  Bilgi güvenliğinin koordinasyonu ve yönetimi için bir yönetim çerçevesi geliştirmek, bilgi güvenliği için sorumlulukları tahsis etmek
  3. Varlık Yönetimi: Tüm kritik veya hassas varlıklar için uygun bir koruma düzeyi belirlemek
  4. İnsan Kaynakları Güvenliği: Kullanıcı eğitimini ve bilincini teşvik ederek hırsızlık, dolandırıcılık veya bilgisayar kaynaklarının kötüye kullanılma riskini azaltmak
  5. Fiziksel ve Çevresel Güvenlik: Kuruluşun tesislerindeki bilgi işlem olanaklarına yetkisiz erişimi önlemek ve bilgilerin zarar görmesini engellemek
  6. Haberleşme ve İşletim Yönetimi: Bilgi işlem tesislerinin uygun ve güvenli kullanımını sağlamak ve olay müdahale prosedürleri geliştirerek riski ve sonuçlarını azaltmak
  7. Erişim Kontrolü: Yetkisiz erişimlerin tespiti ve ağ sistemlerinin korunması için gerekli kontrol faaliyetlerini sağlamak
  8. Bilgi Sistemleri Edinim, Geliştirme ve Bakımı: İşletim sistemleri ve uygulama yazılımlarını bilgi kaybına karşı güncellemek ve kayıpları engellemek
  9. Bilgi Güvenliği İhlal Olayı Yönetimi: Etkin bir bilgi güvenliği sağlamak için olayların zamanında tespit etmek ve gerekli önlemleri almak
  10. İş Sürekliliği Yönetimi: Kritik arızalar, olaylar, doğal afetler, felaketlerden kaynaklanan kesintilere karşı hızla müdahale edilebilmek için kapasite geliştirme faaliyetleri gerçekleştirmek
  11. Uyum: Mevcut güvenlik politikalarının tüm yasalara ve yönetmeliklere uygun olduğundan ve üst yönetim onayından geçtiğinden emin olmak

Yazılım Geliştirme Süreçleri ve ISO 27001

ISO 27001, gerek yazılım geliştirme süreçleriyle doğrudan ya da dolaylı ilişki içerisinde olan birçok kontrol içermektedir. Bu kontroller ve kontrol kapsamında yazılım geliştirme süreci aşamalarında gerçekleştirilmesi gereken hususlar aşağıdaki gibidir.

Analiz Aşamasına İlişkin Kontroller

Yazılım geliştirme sürecinin en önemli aşamasıdır. Bu aşamada yapılacak yanlışlıklar yazılım projesinin başarısını en yüksek düzeyde etkilemektedir.

Bu aşamada kurumun mevcut bilgi teknolojileri, varsa sistem veri tabanı yapısı, sistem veri yapıları tanımlanmalıdır. Kullanıcı uygulama ihtiyaçları doğrultusunda yazılım ihtiyaç tanımları, veri yapılarını güncelleyen giriş bilgileri, uygulama yazılım ara yüz tanımları, yazılımın üreteceği çıktı bilgileri, yazılım için istenen sorgular gibi tanımlar belirlemelidir.

Yapılacak analiz, uygulama servislerinin performans ya da kısıtlamalar yönünden zorlanması ve doğru hizmet vermelerini engelleme girişimlerini de hesaba katmalıdır. Sunucu tarafındaki konfigürasyonların güvenli şekilde yapılması gerekir.

Yazılım için devreye alınacak yeni bilgi sistemleri için iş gereksinimleri bildirgeleri ya da mevcut bilgi sistemlerine yapılan iyileştirmeler güvenlik kontrolleri için gereksinimleri belirlemelidir. (A.12.1.1 – Güvenlik gereksinimleri analizi ve belirtimi) Yeni bilgi işleme tesisleri için, bir yönetim yetki prosesi tanımlanmalı ve gerçekleştirilmelidir. (A.6.1.4 – Bilgi işleme tesisleri için yetki prosesi)

Yetkilendirilmiş kullanıcıların sistemde neler yapabileceği uygun şekilde belirtilmelidir, aksi durumlarda başka kullanıcı haklarını kullanma, yetkisiz olduğu halde verilere erişebilme gibi sakıncalar doğabilir. Kuruluş içinden ya da dışından sağlanmış olsun tüm ağ hizmetlerinin güvenlik özellikleri, hizmet seviyeleri ve yönetim gereksinimleri tanımlanmalıdır. (A.10.6.2 – Ağ hizmetleri güvenliği)

İletişimin bütün türlerinin kullanımıyla ve bilgi değişimini korumak için resmi değişim politikaları, prosedürleri ve kontrolleri oluşturulmalıdır. (A.10.8.1 – Bilgi değişim politikaları ve prosedürleri)

Yazılımda kullanılacak harici materyaller için fikri mülkiyet haklarına göre materyallerin kullanımı ve patentli yazılım ürünlerinin kullanımı üzerindeki yasal, düzenleyici ve anlaşmalarla doğan gereksinimlere uyum sağlanmalıdır. (A.15.1.2 – Fikri mülkiyet hakları (IPR))

Kuruluşun dış taraflarla yapacağı bilgi ve yazılım değişimi için anlaşmalar yapılması gerekir, bu gereksinim analiz aşamasında karşılanmalıdır. (A.10.8.2 – Değişim anlaşmaları)

Tasarım Aşamasına İlişkin Kontroller

Tasarım aşamasında, uygulanacak geliştirme safhaları, her safha için girdiler, çıktılar ve kontrol metotları, iş zaman planları, uygulama planlarının yanı sıra yapılacak işlerin neler olduğu, bu işler için gerekli zaman ve kaynak ihtiyaçlarının tespiti, ilerlemenin izlenmesi için kullanılacak metotlar belirlenmelidir.

Tüm yazılım kullanıcıları için her türlü yazılım sistemine erişim kullanıcı isimleri ve şifreler ile sağlanmalı, bu şifre ve kullanıcı isimleri her kullanıcı için tek ve benzersiz olacak şekilde tasarlanmalıdır. Tasarımda kullanıcılar işlevlerine ve sorumluluk alanlarına göre gruplandırılmalı, grup bazında programlara ve veri tabanlarına erişim hakları verilerek yetkisiz kişilerin sistemi kullanmasına imkân verilmemelidir. Uygulama içinde çalışmalar her zaman menüler yardımıyla olmalı, kullanıcı programları kullanırken hiçbir zaman uygulamanın sağladığı komutlar dışına çıkma olanağı bulmamalıdır.

Bilgi sistemlerinin birbirine bağlantısı ile ilişkili bilgiyi korumak için politikalar ve prosedürler geliştirilmeli ve gerçekleştirilmeli, bilgi sızması fırsatları önlenmelidir. (A.10.8.5 – İş bilgi sistemleri, A.12.5.4 – Bilgi sızması ) Bu kapsamda tasarım aşamasında yüksek riskli uygulamalara ek güvenlik sağlamak için bağlantı sürelerinde sınırlandırmalar kullanılması gerektiği hesaba katılmalıdır. (A.11.5.6 – Bağlantı süresinin sınırlandırılması)

Tehditlerden korunmak için ve iletilmekte olan bilgi dâhil ağı kullanan sistemler ve uygulamalar için güvenliği sağlamak amacıyla ağlar uygun şekilde yönetilmeli ve kontrol edilmelidir. (A.10.6.1 – Ağ kontrolleri) Kullanıcılar ve destek personeli tarafından bilgi ve uygulama sistem işlevlerine erişim, oluşturulması önerilen tanımlanmış erişim kontrol politikasına uygun olarak kısıtlanmalıdır. (A.11.6.1 – Bilgi erişim kısıtlaması)

Kodlama Aşamasına İlişkin Kontroller

Yazılımlarda kodlamalar yapılırken güvenli yazılım kodlama teknikleri kullanılmalıdır.

Yazılımlar, modüler planlanmalı, modüler arası ilişkilerde yapısallık göz önünde bulundurulmalı ve programcı müdahalesi asgari seviyede olacak şekilde parametrik hazırlanmalıdır. Sisteme yeni modülerin ilavesi, modüllerin değiştirilmesi ya da silinmesi durumda sistemin bütünü etkilenmemelidir. Yazılımlarda kullanılacak menü, dosya, alan, değişken, tablo gibi her türlü isim anlamlı olarak seçilmelidir.

Aynı veri veya bilginin farklı veritabanı tabloları için ayrı ayrı girilmesine engel olunmalıdır (Normalizasyon). Tutarsız kod ve verilerin girişine engel olacak tedbirler alınmalı, veri tipleri ile kullanıcıların giriş yaptıkları alanların birbirleri ile tutarlı olma durumu kod içinde yapılan düzenlemeler ile giriş anında kontrol edilmelidir. Hata yapma olasılığı yüksek verilerin girildiği alanlar için liste veya seçenek kutuları kullanılmalıdır.

Özellikle web yazılımının kullanıcı bilgisayarında bir atak aracı olarak kullanılan çapraz site betiklerine (Cross side scripting) ve kontrolü ele almak üzere tamponların taşırılması gibi tehditlerden doğabilecek hatalar uygun bir şekilde kontrol edilmelidir. Kontrol edilmeyen hatalar dış dünyaya sistem ile ilgili bilgiler verebilir ve yeni açıklara zemin hazırlayabilmektedir.

Yazılımların karşılaştığı en önemli tehditlerden biri uygulamalarda gerçekleşen veri giriş-çıkışında kontrollerin tam ve sağlıklı olarak yapılmadan işleme alınması ya da çıktı olarak verilmesidir.  Uygulamalara gerçekleşen veri girişinin, bu verinin doğruluğunun ve uygunluğunun geçerlenmesi gerekmektedir. Yazılımda girdi parametreleri yazılım dışından verilebilir olmamalıdır. Kayıt olanakları ve kayıt bilgisi kurcalanma ve yetkisiz erişime karşı korunmalıdır. (A.10.10.3 – Kayıt bilgisinin korunması) Böyle bir koruma olmaması durumunda SQL (Structed Query Language) enjekte etme ve komut enjekte etme gibi yöntemlerle sistemlere girebilecek kodlar büyük zararlar verebilir. (A.12.2.1 – Giriş verisi geçerleme) Giriş verisi kadar çıkış verisi de önemlidir. Yazılımda çıkış verisi sistemimiz hakkında bilgi vermemeli veri sızıntısına açıklık bırakmamalıdır. Bir uygulamadan gerçekleşecek veri çıktısı, depolanan bilginin işlenmesinin koşullara göre doğruluğunun ve uygunluğunun sağlanması için geçerlenmelidir. (A.12.2.4 – Çıkış verisi geçerleme) Veri işleme hataları veya kasıtlı eylemler nedeniyle herhangi bir bilgi bozulmasını saptamak için geçerleme kontrolleri uygulamalar içine dâhil edilmelidir. (A.12.2.2 – İç işleme kontrolü)Uygulamalarda verinin kimliğinin doğruluğunu sağlama ve mesaj bütünlüğünü koruma gereksinimleri tanımlanmalı bunlarla ilgili uygun kontroller tanımlanmalı ve gerçekleştirilmelidir. (A.12.2.3 – Mesaj bütünlüğü)

Kötü niyetli koda karşı korunmak için saptama, önleme ve kurtarma kontrolleri ve uygun kullanıcı farkındalığı prosedürleri gerçekleştirilmeli, elektronik mesajlaşmadaki bilgi uygun şekilde korunmalıdır. Benzer bir biçimde mobil kod kullanımı yetkilendirildiğinde, konfigürasyon yetkilendirilmiş mobil kodun açıkça tanımlanmış bir güvenlik politikasına göre işletilmesini sağlamalı ve yetkilendirilmemiş mobil kodun yürütülmesi önlenmelidir. (A.10.4.1 – Kötü niyetli koda karşı kontroller, A.10.8.4 – Elektronik mesajlaşma, A.10.4.2 – Mobil koda karşı kontroller)

Kriptografi teknikleri yazılımlarda güvenliği sağlamada faydalanılan önemli tekniklerdir. Bilginin korunması için kriptografik kontrollerin kullanımına ilişkin bir politika geliştirilmeli ve gerçekleştirilmelidir. (A.12.3.1 – Kriptografik kontrollerin kullanımına ilişkin politika) Kriptografi için yeterli rastgeleliği sağlayan kriptografik tekniklerin kullanım desteklenmeli ve anahtar yönetimi bulunmalıdır. (A.12.3.2 – Anahtar yönetimi)

Yazılım geliştirme hizmetinin kuruluş dışından sağlanması durumunda, hizmeti sunan şirketin hareketleri ve yaptığı işler denetlenmeli ve izlenmelidir. (A.12.5.5 – Dışarıdan sağlanan yazılım geliştirme) Yazılım geliştiricilerce gerçekleştirilen ve revizyon kontrolü yapılmayan yazılım değişiklikleri karmaşaya ve çeşitli sorunlara neden olabilmektedir. Yazılım değişikliklerin gerçekleştirilmesinde resmi değişim kontrol prosedürlerinin kullanılması bu karmaşayı ortadan kaldıracaktır.(A.12.5.1 – Değişim kontrol prosedürleri)

Test Aşamasına İlişkin Kontroller

Kodlama aşamasından sonra gerçekleştirilecek test aşamasında yazılım uygulaması modüllerinin nitelik ve nicelik testleri yapılır. Geliştirme, test ve işletim olanakları, işletilen sisteme yetkisiz erişim veya değişiklik risklerini azaltmak için ayrılmalıdır. (A.10.1.4 – Geliştirme, test ve işletim olanaklarının ayrımı)

Bu aşamada bir test planı oluşturulmalı bu planda; test senaryoları, veri çeşitleri ve veri örnekleri ve test tasarım tanımlamaları ayrıntılı olarak belirtilmelidir. Test,   proje yöneticisi ve kullanıcı yetkilileri tarafından koordine ile programcı ve tasarımcılarla, gerçek kullanıcılar tarafından yapılmalıdır. Sistemin bütünü göz önünde bulundurularak modüllerin amaçlanan fonksiyonları tam ve etkin olarak yerine getirip getirmediği, birbiri ile entegre çalışıp çalışmadığı, veri alışverişi (varsa) yapıp yapmadığı kontrol edilmelidir.

Veri tabanının büyüklüğü ve listelenen, sorgulanan kayıt sayısı ile sistemin performans ilişkisi kontrol edilmelidir.  (A.12.2.1 – Giriş verisi geçerleme, A.12.2.4 – Çıkış verisi geçerleme, A.12.2.2 – İç işleme kontrolü) Test verisi dikkatlice seçilmeli, korunmalı ve kontrol edilmelidir. (A.12.4.2 – Sistem test verisinin korunması)

Yazılım ürünlerinin,   sistemin ve alt sistemlerin modül,   fonksiyon,   entegrasyon ve performans testlerinden sonra testlerde ortaya çıkan değerlere uygun olarak gerçek bilgi ve verilerle, gerçek kullanıcı donanım ve işletim ortamında tüm ihtiyaçların karşılandığı kontrol edilmelidir.

Revizyon istekleri göz önüne alınarak gerekli düzeltme ve düzenleme işlemleri yapılır. Entegrasyon, performans ve revizyon testleri tamamlandıktan sonra başlar. Test süresi tüm ihtiyaçların tamamlandığı ve kontrolü yapıldıktan sonra biter.

Test aşaması bitip uygulama devreye alınırken tüm çalışanlar, yükleniciler ve üçüncü taraf kullanıcıların bilgi ve bilgi işleme olanaklarına olan erişim hakları, istihdam, sözleşme veya anlaşmalarının sonlandırılmasıyla birlikte kaldırılmalı ya da değiştirilmesiyle birlikte ayarlanmalıdır. (A.8.3.3 – Erişim haklarının kaldırılması)

Bakım Aşamasına İlişkin Kontroller

Yazılım geliştirme sürencin son aşaması, bakım aşamasında da alınması gereken bir takım güvenlik önlemlerinden söz etmek mümkündür.

Yazılım paketlerine yapılacak değişiklikler, belirli bir incelemeden geçirilmeli, gerek duyulanlar gerçekleştirilmeli, bunun dışındakiler önlenmelidir. Tüm değişiklikler sıkı bir biçimde kontrol edilmelidir. (A.12.5.3 – Yazılım paketlerindeki değişikliklerdeki kısıtlamalar) Benzer bir biçimde kullanıcıların erişim hakları da resmi bir proses kullanarak düzenli aralıklarda gözden geçirmelidir. (A.11.2.4 – Kullanıcı erişim haklarının gözden geçirilmesi)

Yazılım Kaynak kodlarının bozulma riskini azaltmak ve bilgi kaybından korumak amacı ile kaynak kodları yazılım uzmanlarının işletim sistemleri içinde değil sunucu terminal üzerinde bulunmalıdır. Program kaynak koduna erişim kısıtlı olmalıdır. (A.12.4.3 – Program kaynak koduna erişim kontrolü) Söz konusu ortama erişim yalnızca ilgili yazılım uzmanı tarafından sağlanmalıdır.

Donanım arızaları, yazılım hataları, insandan kaynaklanan nedenler ve doğal afetler yazılımlarda bilgi kayıplarının ana sebepleridir.  Sebep her ne olursa yedekleme yazılımlarda hatalardan ve problemlerden geri dönüş için son derece önemlidir. Yedekleme için kurtarılabilir veri saklama yöntemleri uygulanmalı, bilgi ve yazılımlara ait yedekleme kopyaları düzenli olarak alınmalı ve alınan yedekler belirlenecek bir politikaya göre uygun şekilde düzenli olarak test edilmelidir. (A.10.5.1 – Bilgi yedekleme)

Belirlenmiş bir ön yetkilendirme olmaksızın teçhizat, bilgi veya yazılım bulunduğu yerden çıkarılmamalıdır. (A.9.2.7 – Mülkiyet çıkarımı) Eğer yetkilendirme varsa ve bilgi içeren ortamın, kuruluşun fiziksel sınırları ötesinde taşınması söz konusu ise taşıma esnasında, bilgiler yetkisiz erişime, kötüye kullanıma ya da bozulmalara karşı korunmalıdır. (A.10.8.3 – Aktarılan fiziksel ortam)

Bilgisayar donanımlarının depolama ortamı içeren tüm parçaları, elden çıkarılmadan önce, herhangi bir hassas veri ve lisanslı yazılım varsa kaldırılmasını veya güvenli şekilde üzerine yazılmasını sağlanmalıdır. (A.9.2.6 – Teçhizatın güvenli olarak elden çıkarılması ya da tekrar kullanımı)

Kurumların ve şirketlerin operasyonel sistemlerindeki yazılımların kurulmasını kontrol etmek için prosedürler bulunmalıdır.(A.12.4.1 – Operasyonel yazılımın kontrolü)

Zayıf parolalar ve şifreler bilişim sistemleri açısından önemli açıklıklar ortaya çıkarmaktadır. Kullanıcılardan, parolaların seçiminde ve kullanımında iyi güvenlik uygulamalarını izlemeleri istenmelidir. Bu ve bunun gibi hususlar için bilinçlendirme çalışmaları yapılmalı eğitimler verilmelidir. (A.11.3.1 – Parola kullanımı)

İşletim sistemleri değiştirildiğinde, kurumsal işlemlere ya da güvenliğe hiçbir kötü etkisi olmamasını sağlamak amacıyla iş için kritik uygulamalar gözden geçirilmeli ve test edilmelidir. (A.12.5.2 – İşletim sistemindeki değişikliklerden sonra teknik gözden geçirme)

Sonuç

Kurumların güvenli bir ortamda faaliyet gösterebilmeleri için dokümante edilmiş bir BGYS’yi hayata geçirmeleri gerekmektedir. Bu kapsamda ISO 27001 standardı tüm dünyada kabul görmüş ve en iyi uygulamaları bir araya getiren bir modeldir. Standart bu yönetim sistemini oluştururken ele aldığı önemli alanlardan biri de yazılım geliştirme süreçlerinde güvenliğinin sağlanması ve buna ilişkin olarak yazılım geliştirme politikasının oluşturulmasıdır. Yazılım geliştirme süreçlerinde standardın belirttiği gizlilik, bütünlük ve erişebilirlik kavramları mutlaka dikkate alınmalıdır. Bu kapsamda, yazılım geliştirmenin her aşamasında belirli bir güvenlik politikasının uygulanması kritik önem taşımaktadır. Kurumsal güvenlik için öncelikle yazılı olarak kurallar belirlenmelidir. Etkin bir BGYS kurmaya çalışan ve bunu ISO 27001 standardına uyumlu yapmak isteyen tüm kurumların oluşturacağı bu politikada belli kontrol maddeleri asgari olarak yer almalıdır.

Dr. İzzet Gökhan Özbilgin, Sermaye Piyasası Kurulu; Mustafa Özlü, Türk Patent Enstitüsü

Kaynak: https://www.bilgiguvenligi.gov.tr/yazilim-guvenligi/yazilim-gelistirme-surecleri-ve-iso-27001-bilgi-guvenligi-yonetim-sistemi.html

Reklamlar

Lessons Learned in Software Development

21 Nis

Development

1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.

I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.”

2. Change one thing at a time. When you develop, and some tests fail, or a feature stops working, it’s much easier to find the problem if you only changed one thing. In other words, use short iterations. Do one thing, make sure it works, repeat. This applies down to the level of commits. If you have to refactor the code before you add a new feature, commit the refactoring first, then (in a new commit) add the new feature.

3. Add logging and error handling early. When developing a new system, one of the first things I do is adding logging and error handling, because both are useful from the very beginning. For all systems that are bigger than a handful of lines of code, you need some way of knowing what happens in the program. Perhaps not when it is working as expected, but as soon as it doesn’t, you must be able to see what’s happening. The same goes for error handling – errors and exceptions happen in the beginning too, so the sooner you handle them in a systematic way, the better.

4. All new lines must be executed at least once. Before you are done with a feature, you have to test it. Otherwise, how do you know that it does what it is supposed to do? Often, the best way is by automatic tests, but not always. But no matter what, every new line of code has to be executed at least once.

Sometimes it can be hard to trigger the right conditions. Fortunately, it’s easy to cheat a bit. For example, the error handling on a database call can be checked by temporarily misspelling a column name. Or, an if-statement can be temporarily inverted (“if error” becomes “if not error”) in order to trigger something that rarely happens, just to make sure that code is run and does what it should.

Sometimes I see bugs that show that a certain line of code can never have been run by the developer. It can look fine when reviewed, but still not work. You avoid embarrassment if your policy is to always execute every new line you write.

5. Test the parts before the whole. Well-tested parts save time. Often there are problems with integrating different parts, for example from mismatched or misunderstood interfaces between modules. If you can trust that the parts work as expected, it becomes much easier to track down the integration problems.

6. Everything takes longer than you think. Especially in programming. It is hard to estimate how much time a feature will take even if everything goes smoothly. But when developing software, it is quite common to run in to unexpected problems: a simple merge turns out to cause a subtle bug, an upgrade of a framework means some functions must be changed or an API call doesn’t work as promised.

I think there is a lot of truth in Hofstadter Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

7. First understand the existing code. Most coding requires changing existing code in some way. Even if it is a new feature, it needs to fit into the existing program. And before you can fit the new stuff in, you need to understand the current solution. Otherwise you may accidentally break some of the existing functionality. This is means that reading code is a skill that is as necessary as writing code. It is also part of the reason why seemingly small changes can still take a long time – you must understand the context in which you make the change.

8. Read and run. Fortunately, there are two complementary methods for understanding code. You can read the code, and you can run the code. Running the code can be a great help when figuring out what it does. Be sure to make use of both methods.

Troubleshooting

9. There will always be bugs. I don’t like approaches to software development that claim to “get it right the first time”. No matter how much effort you put in, there will always be bugs (the definition of a bug pretty much is: “we didn’t think of that”). A much better approach is to have a system in place that lets you quickly troubleshoot problems, fix the bugs and deploy the fixes.

10. Solve trouble reports. Every developer should spend a portion of their time handling trouble reports from customers and fixing bugs. It gives you a much better understanding of what the customers are trying to do, how the system is used, how easy or hard it is to troubleshoot and how well the system is designed. It’s also a great way of taking responsibility for what you develop. Don’t miss out on all these benefits.

11. Reproduce the problem. The first step when fixing a bug is to reproduce the problem. Then you make sure that when the fix is added, the problem is gone. This simple rule makes sure you are not assuming something is a problem when it isn’t, and makes sure the solution actually does what you think it does.

12. Fix the known errors, then see what’s left. Sometimes there are several problems present that you know about. The different bugs can interact with each other and cause strange things to happen. Instead of trying to work out what happens in those cases, fix all the know problems and then see what symptoms remain.

13. Assume no coincidences. When testing and troubleshooting, never believe in coincidences. You changed a timer value, and now the system restarts more often. Not a coincidence. A new feature was added, and an unrelated feature becomes slower? Not a coincidence. Instead, investigate.

14. Correlate with timestamps. When troubleshooting, use the timestamp of events as a help. Look for even increments. For example, if the system restarted, and a request was sent out around 3000 milliseconds before, maybe a timer triggered the action that lead to the restart.

Cooperation

15. Face to face has the highest bandwidth. When discussing how to solve a problem, being face to face beats video, call, chat and email. I am often amazed at how much better the solutions are after discussing them in person with colleagues.

16. Rubber ducking. Whenever you are stuck, go to a colleague and explain the problem to them. Many times, as you talk, you realize what the problem is, even if your colleague doesn’t say a word. Sounds like magic, but works surprisingly often.

17. Ask. Reading and running the code is often great for figuring out what it does and how it works. But if you have the possibility to ask someone knowledgeable (perhaps the original author), use that option too. Being able to ask specific questions, and follow-up questions to those, can give you information in minutes that would otherwise take days to get.

18. Share credit. Make sure to give credit where credit is due. Say: “Marcus came up with the idea to try…” (if he did), instead of “we tried …”. Go out of your way to mention who else helped or contributed.

Miscellaneous

19. Try it. If you are unsure of how a certain language feature works, it is easy to write a little program that shows how it works. The same applies when testing the system you are developing. What happens if I set this parameter to -1? What happens if this service is down when I reboot the system? Explore how it works – fiddling around often reveals bugs, and at the same time it deepens your understanding of how the system works.

20. Sleep on it. If you are working on a difficult problem, try to get in a night’s sleep before you decide. Then your subconscious mind works on the problem even when you aren’t actively thinking about it. As a result, the solution can seem obvious the next day.

21. Change. Don’t be afraid to change roles of jobs every once in a while. It is stimulating to work with different people, on a different product or in a different company. In my view, too many people just passively stay at the same job year after year, only changing if they are forced to.

22. Keep learning. One of the great things with software development is that there is always room to learn and know more. Try out different programming languages and tools, read books on software development, take MOOC courses. Small improvements soon add up to make a real difference in your knowledge and abilities.

Kaynak: http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/

Yazılım Projeleri Yönetiminde 10 Temel Sorun

11 Şub

Yazılım Proje Yönetiminde 10 Temel Sorun

  1. Yazılım, soyut ve kolay değiştirilebilir bir üründür. Yazılım kaynak kodlari text metinler şeklinde yazılır . Birçok durumda yazılım geliştirme takımları paylaşılan dokümanları (gereksinimler, tasarım özellikleri, kodlar ve test planları) oluşturur ve revize eder.
  2. Yazılım Geliştirme proje süresince öğrenme sürecinde sıklıkla kazanılan bilgi ve oluşturulan bilgi olarak nitelendirilir.
  3. Yazılım projelerini zorlaştran anahtar nitelikler: proje ve ürünün karmaşıkligi, lineer olceklenemeyen kaynaklar, proje ve ürünün ölçümü, başlangıçta proje kapsamının kesinleşmemiş oluşu ve projenin gelişimiyle kazanılan bilgidir.
  4. Yazılım gereksinimleri proje süresince kazanılan bilgi, projenin aciliyeti ve projenin kapsamına göre değişir.
  5. Yeni ve değişiklik yapılan yazılım için gereksinimler çoğu kez organizasyonların iş süreçleri ve personelin iş akış süreçlerinden etkilenir ve etkilenmiş olur.
  6. Yazılım takımları ve proje Paydaşları arasında sıkça iletişim ve koordinasyon eksikliği net bir şekilde görülür.Yazılım Mühendisliğinde iletişim ve koordinasyou geliştirmeye yönelik birçok araç ve teknik kullanılmaktadır.
  7. Yazılım projeleri için başlangıçtaki planlama ve tahminleme zorluktur çünkü bu aktiviteler Uygulanamaz veya çoğu eksik geçmişe ait verinin bir bölümü veya çoğu kesin gereksinimlere bağlıdır. Doğru tahminlerin hazırlığı da zorludur çünkü yazılım geliştiricilerinin etkililik ve efektifligi derin bir değişkendir.
  8. Yazılım Geliştirmede sıkça farklı Ürün tedarikçileri ve diğer yazılımlar için arayüz geliştirme edinilmesi gerektiğinden entegrasyon ve performans sorunu ortaya çıkabilir.
  9. Yazılım kalitesinin ölçümü ve hedefin niteliği zordur çünkü yazılımın doğası soyuttur çalıştırılabilir yazılım tek başına bir ürün değildir. o işleyen donanımda çalışır ve çeşitli donanımlardan oluşan sistemin, diğer yazılımların ve manüel prosedürlerin bileşenidir.
  10. Platform teknolojileri, altyapı yazılımları ve tedarikçi destekli yazılımlar sıklıkla değişir veya güncellenir bu o platformlarda geliştirilmiş olunan yazılımda değişiklikler gerektirir.

Kaynak: PMBOK 5 Software Extension

SOAP Nedir?

17 Kas

SOAP (Simple Object Access Protocol – Basit Nesne Erişim Protokolü), Service-oriented Architecture felsefesini pratiğe uyarlayan iki interface’den biridir. Üzerinde bulunanUniversal Description Discovery and Integration (UDDI) ile birlikte hizmet yönelimli mimarinin pratikte kullanılmasını mümkün kılar.

SOAP Nedir?

SOAP (Basit Nesne Erişim Protokolü) dağıtık uygulamalarda ve web servislerinin haberleşmesinde kullanılmak üzere tasarlanan, RPC (Remote Procedure Call) modelini kullanan, istemci/sunucu mantığına dayalı bir protokoldür. Daha genel olarak SOAP, web üzerinden fonksiyonları kullanmak için geliştirilmiş bir sistemin XML tabanlı kurallar topluluğudur. SOAP ile ilgili bütün mesajlar XML formatında iletilir ve temel olarak bir SOAP mesajı 3 şekilde oluşabilir:Metod ÇağırımıCevap MesajıHata Mesajı

Bir SOAP mesajının yapısı

Envelope

Bütün SOAP mesajlarının içinde olduğu elemandır. SOAP mesajına ilişkin XML belgesinin root elemanı olmak zorundadır. Envelope elemanı içinde Body veya Header gibi elemanlar bulunur. Envelope elemanının içinde her zaman bir Body elemanı vardır fakat Header elemanı olmak zorunda değildir. SOAP mimarisine göre eğer Envelope elemanı içinde Header elemanı varsa bu eleman Envelope elemanının içindeki ilk eleman olmalıdır. Soap kullanan mimarilerde kesinlikle erişim protokolü olarark TCP kullanılmalıdır

Header

SOAP mesajlarındaki Header elemanını HTML standartlarında bulunan etiketlerine benzetebiliriz. Header bölümü metot çağrımı ile doğrudan ilişkili değildir. Header bölümü ile meta-data dediğimizi bilgiler gönderilir.

Body

Body elemanı SOAP mesajının en önemli kısmını oluşturur. Body bölümünde web metodunun adı ve metodun parametrik bilgileri XML formatında gönderilir. Cevap mesajında ise metodun geri dönüş değeri Body bölgesine eklenir. Metodun parametrik yapısının bu şekilde XML formatında yazılmasına SOAP Serialization denir. Son olarak hata mesajlarında ise Body bölümünde hatanın adı ve tanımı gibi bilgiler bulunur.

Kaynak: Sefer ALGAN, http://tr.m.wikipedia.org/wiki/SOAP

Process Mining ( Süreç Madenciliği )

16 Ara

Süreç madenciliği, Hesaba Dayalı Zeka ve Veri Madenciliği arasında yer alan nispeten genç bir araştırma disiplini diğer taraftan süreç modelleme ve analiz etme işidir.
Süreç Madenciliği fikri, günümüzdeki uygun (bilgi ) sistemlerle gerekli bilgiyi olay kayıtlarından ayıklayarak, gerçek süreci(Örn: Gerçekte Varolan Süreçler) geliştirmeyi ve izlemeyi hedeflemektedir.

Process Mining’in detaylı anlatıldığı sunum dökümanı için emrealic@live.com adresine mail gönderiniz.

Matlab ile Karar Ağacı Uygulaması

24 Kas


Uygulama Kodları:
load carsmall Verileri yükleniyor ,matlab üzerinde bulunan bir dataset (ver kümesi)
**Tahmin parametreleri ve hedef sınıfı yapılandırılıyor
vars = {‘MPG’ ‘Cylinders’ ‘Horsepower’ ‘Model_Year’}; Düğümler için değerler tanımlanıyor
x = [MPG Cylinders Horsepower Model_Year]; Düğüm ifadeleri giriliyor
y = strcat(Origin,{}); Origin ile {} birleştiriliyor.
**Karar Ağacı sınıflandırma çalışması yapılıyor
t = classregtree(x, y, ‘method’,’classification’, ‘names’,vars, … ‘categorical’, [2 4], prune’,’off’); classregtree Matlab ağaç çizim fonksiyonu ile ağaç çiziliyor, budama yapılmadan
view(t) Ağaç Görüntüleniyor

**Test ediliyor
yPredicted = eval(t, x); Tahmin değerleri üretiliyor
cm = confusionmat(y,yPredicted); Matrix’e mevcut değerler alınıyor
N = sum(cm(:));  Matris Sütunları toplamı alınıyor
err = ( N-sum(diag(cm)) ) / N; Test Hatası çapraz matris ile alınıyor
**Budanan ağaçta overfitting önleniyor
tt = prune(t, ‘level’,2);  ağaç 2.seviyede budanıyor
view(tt) Budanmış ağaç görüntüleniyor

**görünmeyen yeni olay tahmin ediliyor
inst = [33 4 78 NaN]; Tahmin için yeni değerler giriliyor
prediction = eval(tt, inst) Ağacın vereceği sonuç tahmin olarak alınıyor

Optimizasyona Dayalı Sınıflandırma Modelleri

26 May

Veri Madenciliğinde kullanılan Optimizasyona dayalı sınıflandırma modelleri incelenmiştir.

Emre ALIÇ- 105112012

25.05.2011


İçindekiler
Destek Vektör Makinesi 3
Doğrusal olarak ayrılabilme durumu 3
Primal Çözüm 6
Lagrange Çarpanları 6
Karush-Kuhn-Tucker Koşulları 7
Dual Çözüm 8
Verilerin Doğrusal Olarak Ayrılamama Durumu 12
Doğrusal Olmayan Sınıflandırıcılar 16
Doğrusal Olmayan Özellik Uzayı 16
Çekirdek Fonksiyonlar 17
Destek Vektör Makinası ve Çekirdek Fonksiyonlar 18
Kaynakça 22

Destek Vektör Makinesi
Destek Vektör Makinesi (Support Vector Machine = SVM) veri madenciliğinde sınıflama problemlerinde kullanılan bir yöntemdir.Bu yöntem, sınıflandırmayı bir doğrusal yada doğrusal olmayan bir fonksiyon yardımıyla yerine getirir.Destek vektör makinesi yöntemi,veriyi birbirinden ayırmak için en uygun fonksiyonun tahmin edilmesi esasına dayanır.Daha çok makine öğrenmesi yöntemleri arasında yer alan bu yöntem günümüzde veri madenciliği alanında da tercih edilmeye başlanmıştır.
Doğrusal olarak ayrılabilme durumu
D veri kümesinin (X1,y1),(X2,Y2)…(Xn,Yn) biçiminde olduğunu varsayalım. Burada n veri kümesinin eleman sayısıdır ve y , {+1,-1} kümesinin elemanı olarak kabul edilir.[1]…
.
.
.

Optimizasyona Dayalı Sınıflandırma Modelleri Dökümanı Tıkla !