Word geen Nova artikel

 
23 april 2009

Vorige week ben ik als bezoeker naar de J-Spring conferentie geweest en heb hier verschillende interessante sessies bijgewoond. Waaronder Security in Software Design and Architecture door Steven van der Baan van Sogeti. Deze sessie haakte in op een recent krantenartikel over de diefstal van en fraude met creditcard gegevens.

Tijdens deze sessie werd een analogie gemaakt tussen het bouwen van een kasteel en een (groot) software product. Er werd gesteld dat bij de bouw van kastelen overal van tevoren over nagedacht wordt; hoe hoog maken we de muren? Hoe zorgen we voor drinkwater tijdens een belegering? Terwijl bij een software project vaak pas naderhand de veiligheid gerealiseerd wordt door het toevoegen van encryptie, rollen en andere ‘beveliging’.

Misschien is het goed om eerst even te definiëren wat veiligheid nou precies is, als we praten over software. Veiligheid is in principe een combinatie van verschillende factoren, van der Baan zet dit uiteen in de volgende termen:

  • Confidentiality: Blijft de data ‘geheim’?
  • Integrity: Is de partij waarmee gecommuniceerd wordt ook daadwerkelijk diegene die hij/zij beweert te zijn?
  • Availability: Is de software beschikbaar?

Daarnaast moet je jezelf tijdens het ontwerpen van software constant afvragen: Wie? Met welke rol? Met welke rechten? Mag wat doen? Mag waar iets doen? Mag welk proces beïnvloeden?

Uit onderzoek is gebleken dat het toevoegen van veiligheid in een later stadium dan tijdens het ontwerp stadium, de kosten voor het toevoegen van de beveiliging exponentieel laat groeien. Kortom, eerder rekening houden met de veiligheid is beter, makkelijker en uiteindelijk goedkoper.

Om dit te bewerkstelligen draagt van der Baan de volgende methodes en tools aan, die kunnen helpen bij het ontwerpen met het oog op de veiligheid:

  • Het opnemen van veiligheid in de requirements en use cases.
  • Standaard patronen gebruiken om standaard problemen op te lossen, zoals de problemen uit de OWASP top 10.
  • Een Attack Tree opstellen
  • Data flow diagrammen: Ook de grenzen van vertrouwen aangeven

Daarnaast is het makkelijk om in het Kruchten 4 + 1 model veiligheid te verweven in verschillende lagen in het ontwerp:

  • Top view: Voeg naast de use cases ook ‘abuse’ cases toe.
  • Logical view: Security patronen opnemen in de UML diagrammen. Hiervoor kan Secure UML of UML Sec gebruikt worden.
  • Proces view: Voeg ook restricties toe in de state charts.
  • Deploy: Teken niet alleen het ‘standaard’ plaatje met een applicatie server, database server en firewall. Geef ook aan hoe load balancing en eventueel network sniffing toegepast worden.

Samenvattend, zegt van der Baan; het is aan te raden om software ontwikkeling te beginnen met een compleet model voor de software waarin ook rekening is gehouden met de veiligheid. met daarin de grenzen en de data. Het gebruik maken van standaard oplossingen en patronen voor bekende veiligheids risico’s reduceert ook de kans op software lekken en daarmee de kans dat je eindigt als Nova artikel.

Wanneer begin jij rekening te houden met de ‘veiligheid’ van je applicatie?


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development, Java (EE)

Tags: , , , , , , , , , ,