Grip op Secure Software Development/Structuur beveiligingseisen
Versie 3.0 van deze Thema-uitwerking van 20 juli 2020 wordt namelijk op dit moment voor het eerst opgevoerd.
Versie 3.0 maar ook versie 2.0 in PDF-formaat is op de website CIP-overheid/producten gepubliceerd.
Alle hoofdstukken bij Grip op Secure Software Development:
| ||||||||||
ISO/IEC 25010:2011 is dé standaard voor softwarekwaliteit en definieert beveiliging op een technologie-onafhankelijke manier. Het is de basis van het SIG beveiligingsmodel1 volgens welke de SSD beveiligingseisen zijn gestructureerd. Dit model harmoniseert bestaande standaarden in een uniform en logisch overzicht van verantwoordelijkheden, zodat duidelijk is wat geregeld moet worden bij het maken van afspraken, bij implementatie en bij toetsing.
In ISO/IEC 25010 bestaat beveiliging uit vijf kenmerken:
- Vertrouwelijkheid: gegevens zijn alleen toegankelijk voor geautoriseerden.
- Integriteit: aanpassing van computerprogramma's of gegevens alleen voor geautoriseerden.
- Onweerlegbaarheid: er kan worden bewezen dat acties of gebeurtenissen hebben plaatsgevonden.
- Verantwoording: acties van een entiteit kunnen uniek worden getraceerd.
- Authenticiteit: de identiteit van een onderwerp of bron kan worden aangetoond als degene die wordt geclaimd.
De vijf kenmerken zijn door middel van onderstaand model elk gerelateerd aan een aantal verantwoordelijkheden voor software-ontwikkeling en -beheer.
Merk op dat 'beschikbaarheid' (availability) in twee delen is gesplitst in ISO/IEC 25010:
- een deel dat valt onder de softwarekwaliteit 'betrouwbaarheid' (door maatregelen voornamelijk buiten de software: anti-ddos, dubbele uitvoering, etc.), en
- een deel dat valt onder 'Integriteit' (zoals verificatie van invoer en uitvoer om 'denial of service' te voorkomen).
Hoe de verantwoordelijkheden een rol spelen in veilige software
Een applicatie zorgt dat functies en gegevens alleen toegankelijk zijn voor diegenen die daarvoor goedkeuring hebben op de manier dat de applicatie bedoeld is. Voordat het systeem aan de vragen van gebruikers voldoet, voert het eerst Toegangscontrole uit.
Dit bestaat uit:
- Authenticatie: zekerheid dat een identificatie deugt en
- Autorisatie: controle per actie dat die geoorloofd is voor die specifieke gebruiker.
- Sessiebeheer: sessies voorkomen dat een gebruiker zich voor elke actie opnieuw moet identificeren. Sessies vertegenwoordigen de identiteit van de gebruiker en dit moet dan ook deugdelijk verlopen.
In elk systeem vinden logische stappen plaats van gegevens die in- en uitvloeien. In die logische verwerking hoort het systeem alle invoer en uitvoer te controleren: dit is het domein van Invoer- en uitvoer validatie. Om uiteindelijk deugdelijke werking te kunnen aantonen (tijdens en achteraf), is Logging nodig.
Voor en na verwerking van gegevens worden die gegevens getransporteerd en opgeslagen. De communicatie tussen gebruiker en systeem en met andere systemen hoort beschermd te zijn zodat er niet met de communicatie geknoeid kan worden. Het systeem forceert daarvoor veilige Datacommunicatie. Ook (tijdelijk) bewaarde gegevens horen weerstand te bieden tegen onderschepping of wijziging met veilige Dataopslag.
Rondom het systeem bestaat een 'operatieschil', grofweg te scheiden in techniek (Infrastructuur) en proces (Gebruikersbeheer, Externe componenten etc.).
Tot slot is er een aantal architectuurprincipes die bijdragen aan een veilige applicatie.
De structuur van de verantwoordelijkheden helpt om te bepalen op welk moment een bepaalde eis van toepassing is; afhankelijk van het type ontwikkelwerk of testactiviteit. Op deze manier hoeven alleen de van toepassing zijnde SSD normen per moment worden meegenomen. Hiervoor zijn per SSD-eis zogenaamde triggers gespecificeerd: een omschrijving van de situatie waarin de eis van toepassing is.
- ↑ Oorspronkelijke wetenschappelijke publicatie: https://zenodo.org/record/3592336#.XgH_kNZKjUI, ‘A Practical Model For Rating Software Security’