Proactive Security Strategy

Security testing is always very thankful, many defects, many examples for the trainer of a course. Sir Wilfred Grenfell once said:

“Real joy comes not from ease or riches or from the praise of men, but from doing something worthwhile.”

He mentioned this quote while he was helping others with medical support. But this quotation is also true for me if I’m executing a security test. Because the vulnerabilities you find can often create danger for the owner of the data. Because these vulnerabilities (defect) affect for example the availability.

In this post I want to describe how the combination of some defects can lead to huge problems for the owner of the application. The defects have an effect on the confidentiality, integrity and availability of the application.

Sometimes finding security defects is very easy. Maybe you can imagine an “SQL Syntax Error message” like this one:

If you’re not aware of security this error message is not more than a jammer for you. But if you realize that this message is created by only a single ‘ in a search field you find a great entry point for a SQL-injection! What happens is that this single ‘ make the syntax of the statement at the background corrupt. In other words this happens if there is a conjunction between the data and the logic. These two must be separated, but are combined into one statement. Instead of executing the statement with date will he execute the data like it is a statement.

This single defect is not a threat on its own, but if you combine this with other statements you can, for example, make a copy of the database or just enter the commando ; DROP  database (don’t try this at work).

Examples
The next 4 defects show you how a combination of data and logic can lead to a real threat. Imagine for example an electricity provider with a web portal for its end users. To login you need to fill your region code, username and password. 4 defects we found:

1. When you “Right click” in the login page, the “show source” option will give you the source code of this page. Sometimes you’ll find //comments in the code. These comments are often interesting but they are more interesting if they describe that there is a default region code in case a user leaves this field empty. You first defect is: It’s possible to get a third part of the login code, the region code.
2. The next test you execute is; how many times can I log in with an incorrect combination of username and password? If this is ten times or more, you’re quite sure the account will not lock after 100 times. Your second defect is: It’s possible to brute force the combination of username and password.
3. While you’re browsing through the application you see only a short URL like “www.myelectricityprovider.net”. If you right click you can see the settings of this button. Within these settings you’ll find the direct URL. Copy and paste this URL and now you see an ID. Change this ID into an ID of someone else you can sometimes enter that specific account. The defect you found is a big one, because no one can trace this ’normal‘ use.
4. If you go with the account, that isn’t yours, to the account setting page, you can see the personal settings. If you can see the password in text here, like “Welcome01” you have another defect. For security reasons it’s not a good choice to save the passwords non-hashed in the database.

This combination of defects has his impact at the confidentiality, integrity and availability.

• You can lock all accounts with changing the passwords; nobody can enter his account at this moment. The application is threaten at the availability.
• Hacking the account of someone else affect also the confidentiality. Because you as the account owner are not the only one that can see your personal data.
• The integrity can be damaged by changing the personal data.

A hacker will step by step gather information and attack deeper and deeper into the application. Also these defects on their own create a risk, but the combination of these gives a lot of features to those that haven’t the permissions to use YOUR account.

Use your imagination to make these combinations and you’ll see you’re doing something that’s worthwhile.

J.D. Meier heeft op zijn blog Shaping Software een draft gepubliceerd van hun Cloud Security Frame. Dit zijn de eerste verkenningen voor het patterns & practices Cloud Security Project.

The frame is simply a collection of Hot Spots. Each Hot Spot represents an actionable category for information.

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.