Programma's ontwerpen: Veiligheid als principe

“But who does hawk at eagles with a dove?”
                                                            - C. Herbert

Veiligheidslekken zijn aan de orde van de dag en bedrijfsoplossingen zijn geen uitzondering op de regel. Maar wat verstaan we onder veiligheid als het aankomt op industriële oplossingen? En nog belangrijker; hoe nemen we beveiliging mee in het ontwerp?

Er zijn 4 facetten van veiligheid in de software ontwikkeling:

-       integriteit van informatie

-       zichtbaarheid van informatie

-       structurele mechanismen en hun robuustheid

-       omgeving en ecologische omstandigheden.

Wanneer we met informatie werken, willen we dat deze informatie niet corrupteerd. Dat wil zeggen dat gegevens niet onbeheersbaar aangepast zouden mogen worden, vooral wanneer er privacy gevoelige informatie gebruikt wordt door de oplossing. Wanneer de database bijvoorbeeld niet goed wordt afgeschermd kan het drastische gevolgen hebben, zoals diefstal en/of verlies van gegevens.

Ook willen we niet dat informatie kan worden ‘afgeluisterd’ dan de bestemde kanalen. De transmissie van gegevens kan misbruikt worden door relatief eenvoudige methoden, maar ook de informatie die in bestanden worden opgeslagen zijn een veiligheidsgevaar.

Soms zijn er briljante oplossingen met technische mechanismen, die niet getest worden op misbruik; per ongeluk ontdekt men opeens dat ongewenste resultaten mogelijk zijn met desastreuze gevolgen van dien. De robuustheid van de oplossing valt van een degelijk en goed product neer op de harde bodem van onbetrouwbaar.

Als laatste aspect zijn er van allerlei adders in het gras waar je als ontwerper geen controle over hebt: het systeem en platform waar de oplossing zich in bevind. Een slecht afgebakend systeem is als een programma vol veiligheidslekken, en omdat je oplossing werkt als een subproces op dat systeem, betekent dat het moederproces hogere toegangsrechten kent dan de eigen oplossing.

Nu is informatiebeveiliging een vak op zichzelf, maar zou iedere ontwerper vanaf het begin af aan een aantal principes moeten toepassen. Naast het inlichtingen inwinnen van een deskundige, is het goud waard om het Sam Rain Security Principe ten harte te nemen.

Het Sam Rain Security Principe

1.     als je het systeem niet vertrouwd, is je applicatie ook niet te vertrouwen. (iedere ‘hacker’ wilt de hoogste systeemprivileges, voor totale controle)

2.     vertrouw geen enkele  invoer van een gebruiker dat informatie is voor de database en met name speciale symbolen. (databases hebben een eigen programmeeromgeving en doen geen speciale controles op aanvragen en commando’s)

3.     gebruik gegevensversleuteling (encryptie) voor het versturen en ontvangen van gevoelige informatie, zoals inlogprocedures (informatie over een netwerk vliegt in het rond en kan opgevangen worden)

4.     laat een oplossing gestress-test worden door een deskundige. (laat niets aan toeval over, een productie oplossing is moeilijk stil te leggen voor een plakband en nietjes oplossing)

5.     vertrouw geen enkele gebruiker, alleen een beheerder voor onderhoud geniet hoge privileges, werk met rollen en verantwoordelijkheden (directeuren en managers zijn zelden techneuten, maar altijd mensen).

Om een boekje open te doen: de meeste industriële software die ik ‘ontworpen’ heb zien worden sloegen óf deze punten over óf namen deze niet serieus óf schoven deze zover vooruit dat het te moeilijk was om alsnog te realiseren. *kuch* banken, *kuch* overheden, *kuch*’specialisten’.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Veiligheid