Proactive Security Strategy

Net gelezen, het Software Assurance Maturity Model (SAMM) heeft een uitbreiding gekregen. Nick Coblentz heeft een interview template ontwikkeld waarmee het huidig Maturity model voor een organisatie bepaald kan worden. De eerste versie is nu verkrijgbaar.

Bekijk hem hier (html format) online, of download hem hier (xls format).

PaSS (Proactive Security Strategy) is een Sogeti-breed initiatief met als doel applicatiebeveiliging een bewust deel van het ontwikkelproces te maken waar vanaf het begin rekening mee gehouden wordt.
Met de kennis vanuit PaSS levert Sogeti een gestandaardiseerde aanpak voor het ontwikkelen van softwareapplicaties volgens een Secure Development Proces (SDP). Sogeti kent en ondersteunt de verschillende bekende SDP’s, zoals de SDL van Microsoft, de Touchpoints van Gary McGraw en CLASP van OWASP. SDP’s zijn complementair aan een standaard ontwikkel proces en beschrijven de taken mbt tot applicatie beveiliging binnen het ontwikkel proces. Zo wordt voor elk project de beste aanpak gekozen die het project maximaal ondersteunt.

Security Touchpoint (Gary McGraw)

Touchpoints

Op basis van de Touchpoints beschrijven we hier de link tussen requirements development en een SDP. In elk development lifecycle is een fase waarin de eisen aan de software worden vastgelegd, vergelijkbaar met de “Requirements and use cases”-fase uit de Touchpoints. Voor elke SDP geldt dat we de beveiligingseisen van de applicatie in deze fase vastleggen. De methode van vastleggen kan anders zijn, maar de algemene gedachte is dezelfde.
In de Touchpoints benoemen we requirements en ook security requirements expliciet. Het is meteen duidelijk waar de requirementsanalist zich mee bezig moet houden in de deze SDP. Er worden ook technieken meegegeven voor het vastleggen van de security requirements: In de touchpoints worden hiervoor zowel use cases als ab-use cases gebruikt. Use cases beschrijven dan functionele veiligheidseisen zoals het gebruik van encryptie. Een ab-use case is een beschrijving van de complete interactie tussen een systeem en een of meer actors, waarbij de uitkomst van de interactie schadelijk is voor het systeem, een actor of een of meer stakeholders van het systeem.
In het ontwikkel traject zullen ab-use cases niet dezelfde rol spelen als use-cases. Ze beschrijven immers functionaliteit die niet mogelijk moet zijn.Het doel van ab-use cases is het leren denken als een hacker en misbruik in kaart brengen. Ab-use cases maken het begrijpen van de mogelijke beveiligingsissues voor gebruikers zonder beveiligingskennis makkelijker en laten de applicatie zien vanuit het oogpunt van een hacker. Een ab-use case geeft een beeld van een range van verschillende mogelijke beveiligingsissues. Hoe deze worden opgezet wordt onder andere uitgelegd in whitepaper “Testen van applicatiebeveiliging op basis van Tmap” door PaSS-SC.

Via de volgende stappen stellen we een ab-use case op:

• Gebruik een use case als basis;
• Voeg de hacker toe;
• Voeg mogelijk misbruik op de (reeds bestaande) functionaliteit toe;
• Voeg eventuele oplossingen toe.

Security requirements

Het is goed denkbaar dat we in sommige gevallen duidelijk moeten aangeven dat het systeem bepaalde acties niet ondersteunt: bijvoorbeeld de eis dat SQL statements in een login- of wachtwoordveld niet worden uitgevoerd. De gedachtegang hierachter is dat als je alleen beschrijft wat je wilt, je soms impliciet ongewenste functionaliteit meekrijgt. Het alleen stellen dat de applicatie beveiligd moet worden met een login en wachtwoord sluit niet uit dat SQL statements gebruikt kunnen worden om het systeem alsnog te hacken.

De analist kan COPAFIJTHES, ISO9126 of de T-map kwaliteitsatributen gebruiken gebruiken om non-functional security requirements te beschrijven. Daarnaast kunnen we het voorschrijven van bepaalde security maatregelen zoals encryptie beschouwen als functional security requirements Voor het ontwikkelen van veilige software is het dus noodzakelijk dat de analist een stap verder kijkt. Naast wat het systeem moet kunnen voor de stakeholders moet daarom ook beschreven worden wat niet mogelijk moet zijn- om zo het systeem te beschermen tegen aanvallen van buitenaf.

Voor de requirementsanalist betekent dit een andere manier van denken. In plaats van alleen te kijken wat het systeem of de oplossing moet kunnen wordt er ook gekeken wat er absoluut niet moet kunnen, welke functionaliteit nadelige gevolgen heeft voor de applicatie. Hierbij valt te denken aan ongeautoriseerde toegang maar ook aanvallen gericht op het platleggen van applicatie.

De analist krijgt ook te maken met een extra stake holder, de security officer. De security officer is de gene die weet hoe het bedrijf vorm geeft aan alle security richtlijken. Hij zal ondersteuning moeten bieden bij het vertalen van security richtlijnen van het bedrijf naar specifieke security requirements die door de analist kunnen worden vast gelegd.
Ook moet de analist threat models kunnen lezen en begrijpen. Hieruit kan worden afgeleid wat de prioriteit van de verschillende security requirements is.

Gevolgen voor de requirementsanalist

Voor de requirementsanalist betekent dit een andere manier van denken. In plaats van alleen te kijken wat het systeem of de oplossing moet kunnen wordt er ook gekeken wat er absoluut niet moet kunnen, welke functionaliteit nadelige gevolgen heeft voor de applicatie. Hierbij valt te denken aan ongeautoriseerde toegang maar ook aanvallen gericht op het platleggen van applicatie.

De analist krijgt ook te maken met een extra stake holder, de security officer. De security officer is de gene die weet hoe het bedrijf vorm geeft aan alle security richtlijken. Hij zal ondersteuning moeten bieden bij het vertalen van security richtlijnen van het bedrijf naar specifieke security requirements die door de analist kunnen worden vast gelegd.

Ook moet de analist threat models kunnen lezen en begrijpen. Hieruit kan worden afgeleid wat de prioriteit van de verschillende security requirements is.

Security requirements betekenen een extra toevoeging aan de requirementsadministratie. Alle kwaliteits attributen die van toepassing zijn in het kader van security moet expliciet vastgelegd worden in de requirements administratie.

De analist zal meer als een hacker moeten denken om potentiële lekken, achterdeuren en kwetsbaarheden te ontdekken die een gevolg kunnen zijn van de requirements die zijn geuit door de stakeholders. Hij wordt hierbij wel geassisteerd door de security officer. Samen met de security officer moet de analist de andere stakeholders bewust maken van mogelijke security consequenties van de andere requiremenst die ze hebben geformuleerd. Samen met de security officer zullen er requirements opgesteld moeten worden voor de tegen maatregelenen, voor de security issues als gevolg van de andere requirements.

In een secure development traject zal de analist gedurende alle stappen van het requirements developmentproces ook bezig zijn met de security requirements.

After reading a toolsmith article I’d written on PTA: Practical Threat Analysis, Frank Simorja>, a local ISSA chapter member, friend, and co-worker reached out to a peer team in the Microsoft Solutions Accelerators (SA) group and suggested the prospect of something similar to be added to the SA roster.
After meeting with the SA Security & Compliance team, and a couple months of excellent collaborative effort with the likes of SDL expert Adam Shostack, group PM Kelly Hengesteg, editor Steve Wacker, and contributor Jeff Sigman, I authored the IT Infrastructure Threat Modeling Guide, now released in beta on the Connect site.
Sign up for the beta program here, then bookmark this.

Threat modeling has been well applied during the software development process, but there has been a noteworthy, Internet-wide lack of documentation and guidance with regard to applying threat modeling methodology to infrastructure. While many people and organizations threat model infrastructure in some form or fashion, we believed it was time to create a unified process that anyone from a small, one person IT shop, to a major enterprise could follow, and thus improve their security posture.

The IT Infrastructure Threat Modeling Guide provides an easy-to-understand method that enables you to develop threat models for your environments and prioritize your investments in IT infrastructure security. This guide describes and considers the existing Microsoft Software Development Lifecycle (SDL) threat modeling process and uses it to establish a threat modeling process for IT infrastructure.

Please feel free to give it a close look and submit feedback, we really do welcome it.

It is the intent and hope of this guidance that the benefits of choosing to develop a threat model for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

Er zijn genoeg modellen om veilige software te bouwen. Microsoft heeft de SDL, OWASP heeft CLASP en Cigital heeft Touchpoints. Toch is het hebben van zo’n model geen garantie dat het werkt. Het vergt ook iets van de organisatie om met het model goed om te gaan.

Brian Chess, Garry McGraw en Sammy Migues hebben bij negen bedrijven bestudeerd welke onderdelen gemeenschappelijk zijn in de modellen. Deze gemeenschappelijkheden zijn samen gevoegd in, wat ze noemen, het Secure Software Framework. Dit framework is de basis voor het maturity model.

Het model verdeelt beveiliging op in twaalf categorieen, inclusief training, code review en software testen nadat het geschreven is. Elke categorie bevat een aantal activiteiten die kunnen helpen met het maken van veiligere software, zoals het baseren van trainings sessies op bestaande beveiligings incidenten en niet op theoretische. Het is bedoelt  voor het hoofd van de IT afdeling en kan vrij gedownload worden.

Artikel over “Why the new SDL threat modeling approach works”. Met daarin een duidelijke aanwijzing waarom deze methode werkt.

Artikel over “The future of secure development at Microsoft” op SD Times. (Jesse bedankt voor het doorsturen).

Windows Vista is gebouwd volgens het SDL pricipe.
Het bouwen en compileren van Vista werd vergeleken met dat van XP. Ook werd besproken hoe problemen in de source code werden opgespoord en aangepakt. De teamleider van het Vista penetration test team in Engeland, Alex Lucas, wist ons te vertellen dat, vergeleken met eerdere Windows versies, het compileren van Vista “a walk in the park” was. Dit kwam doordat men gebruik maakte van allerlei ‘code opschoon’-technieken waaronder SDL.
Bewust maken, opleiden, afdwingen van gebruik, testen.
verder veel tips over zaken zoals annotations.