Secure Software Development Lifecycle

by Süleyman Petek 13. Temmuz 2015 23:00
Security should be a part of your DNA while building  a software system.

Security should be part of your DNA while building a software system. Here below a short list for acronyms.

Information Security Risks: The probability that a particular threat-source will exercise a particular information system vulnerability and the resulting impact if this should occur.

Software Security: A way to defend against software exploits by building software to be secure.

Application Security: A way to defend against software exploits  after deployment is complete.

Return Of Security Investment in Security (ROSI): The total amount of money that an organization is expected to save in a year by implementing a security control.

The core components of Secure SDLC process are:

  • Clear and detailed requirements of business
  • Security requirements 
  • Threat modelling (Early in the security design phase, threat modelling should be done in order to identify the potential threats that exist specific to the application.)
  • Design
  • A policy for secure coding
  • A framework for secure coding (OWASP may be a resource here)
  • Segregation of environments (Dev/Test/Staging/PreProd/Prod)
  • Static and Dynamic Analysis of the code
  • Change management
  • Release management

To mitigate the probability of writing insecure code, a few steps should be included in the SDLC. Since writing secure code is vital for minimizing the occurrence of vulnerabilities, it is worth elaborating on this topic for the benefit of executives. This step in development is too often misunderstood or deemed to be of secondary importance compared with production deadlines. It is worth to review the basic steps of writing secure code and at some point it may look as an attractive return on investment.

Secure coding needs some key factors:

  • Top level management buy-in
  • Security architect engagement
  • Segregation of duties
  • Backups
  • Monitoring and logging of events
  • Patch management
  • Password management (authentication-authorization)
  • Session management
  • Input validation
  • Output encoding
  • Exception management (Fail safely)
  • Developer training (Create awareness, educate)
As you see the cost of a bug during SDLC, the security issues should be considered and fixed as early as possible.



What can you lose if you don't ?
  • Reputation
  • Data
  • Money
  • Time
And never forget that risks are for managers, not for developers !


Tags: , ,

IT Security | Awareness | Secure Coding | Web Security | Web Attack | Web Defense

Yazılım Projelerini Yönetmek

by Süleyman Petek 3. Temmuz 2015 20:45
Yazılım projelerinde çok sıklıkla karşılaşılan, projenin tahmin edilen maliyetten daha yüksek m

Yazılım projelerinde çok sıklıkla karşılaşılan, 

projenin tahmin edilen maliyetten daha yüksek maliyete çıkması, 

proje bitiş tarihinin tahmini tarihe yetişmemesi ve 

finalde ortaya çıkan ürünün en başta tasarlanan prototipe nazaran daha az kaliteli ve daha az fonksiyonel olması durumu, 

hepimizin başına geliyordur ya da gelecektir. Burada asıl mesele, bu rutini yaşamadan başarılı olabilmektir. Bu rutin sorunla başa çıkabilmek için şu 4 adımın mutlaka uygulanması gerekmektedir:

1) Planlama ve Tahmin

2) Ölçme ve Kontrol

3) İletişim, Koordinasyon ve Liderlik

4) Riski yönetmek


Aslında bütün projeler aslında birbirine benzer (yönetim anlamında)

-Projeden beklentiler belirlenir

-Yapılacak aktiviteler planlanır

-Kaynaklar atanır

-Sorumlular belirlenir

-Yapılacak işler koordine edilir

-İşin ilerleyişi izlenir

-İletişim sağlanır

-Risk faktörleri belirlenir ve önlenmesi için yapılması gerekenler belirlenir

-Yanlışları düzeltici aksiyonlar alınır (gerekliyse)


fakat yazılım projelerini daha zor ve kompleksleştiren faktörler, yazılım projelerini diğer sektör projelerinden ayırt etmektedir ki bunlar :

-Yazılımın aslında doğasının kompleks oluşu

-Yazılımın değişkenliği

-ve Yazılımın görünmeyen aslında soyut bir ürün olması

Maalesef ki ülkemizde yazılım yöneticiliği yapanlar halen işe inşaat mantığıyla bakıyorlar, şöyle ki, geç kalmış bir inşaata takviye eleman ekleyerek bir miktar hızlandırabilirsiniz işi, ancak bu mantık yazılım projelerinde tam tersi etkiye neden oluyor genelde.(Bkz. The Mythical Man - Month , "Adding manpower to a late software project makes it later ."Bu olayın bir diğer güzel örneği de anne-doğum örneği, yani 1 anne 1 çocuğu 9 ayda doğuruyorsa, 9 anne 1 çocuğu 1 ayda doğuramaz, yazılım projeleri de aynen böyledir. Aslında inşaat için de bir yerden sonra aynı şey geçerlidir, hızlanması gereken bir inşaata gereğinden fazla takviye işçi sağlanırsa bu sefer işçilerin inşaata yaklaşamaması tehlikesi muhtemeldir.(İnsan kalabalığından kaynaklanan istenmeyen durum). 

Yazılım için bu adam eklemenin yarardan çok zarar getirmesini, PMI in da anlattığı gibi iletişim kanallarının her bireyle, logaritmik artması sebebiyle de destekleyebiliriz. PMI der ki iletişim kanalları=n(n+1)/2, n burada ekibin sayısını temsil eder. Bir de buna ekibe yeni katılan elemanların öğrenme eğrisinin de ters logaritmik artışını eklersek, sanırım olayın ciddiyeti daha da anlaşılır olur.

Peki ne yapmalıyız, neler yapılsa böyle olmaz dersek, aslında kesin bir çözüm olmamakla beraber, takımın ve şirketin yapısına göre farklı alternatifler denenebilir, bu aralar çok popüler olan çevik yöntemler buna bir örnek olabilir mesela. (Eğer yönetim desteği varsa ve ekip çok kalabalık değilse (5-8 kişi)).


Tags: , , , ,

Project Management

Calendar

<<  Temmuz 2018  >>
PztSalÇarPerCumCmtPaz
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

View posts in large calendar

RecentPosts