Cory at Matasano has a new blog post explaining “Ninja threat modeling.” Ninja threat modeling is Matasano’s approach to threat modeling as part of a penetration test. I’m really happy that they’ve given their approach a name. A few years back, we would just talk about “threat modeling” and it got confusing. With that said, Adam here, and I wanted to offer up our perspective. I’ll do that by first comparing and contrasting the SDL and ninja approaches, and then respond to on some Cory’s impressions of the STRIDE-per-Element approach to threat modeling which we’re using in the SDL.
There’s a lot to be said for giving your approach a cool name, and we love cool names too, like “The SDL Threat Modeling Tool.” How cool is that? Ok, ninja is much cooler. It seems from Cory’s post that Matasano’s customers are coming to them for security at the end of their process, rather than at the start. I think we all agree that threat modeling late produces less value. Here at Microsoft, we’ve invested in making it possible for any software engineer to threat model at the start of development. We’ve made enough progress in this that Forrester has said “Many application architects and developers don’t know enough about developing secure applications… Microsoft’s SDL Threat Modeling Tool is a unique new tool that helps developers identify and mitigate security risks to make applications more secure from the get-go.” (“Use Threat Modeling To Develop More-Secure Applications,” March, 2009.)
I do think that we can map between the current SDL approach and the Ninja approach:
Stage
STRIDE/Element
Ninja
Model
DFD
App overview, data flow
Identify Threats
Assumptions, deadly sins
Mitigate
Redesign/standard/custom/accepted
?
Validate
Check model, all threats have bugs
Test plan
For a summary of their process, I looked at the boxed text “Ninja threat modeling at a glance.” I wish Cory had explained the approach a bit more: what’s the difference between an app overview and a data flow? Why are there 2 threat enumeration checklists (assumptions, deadly sins)? I think it might be interesting to combine the two threat enumerations. I also think that the risk management step could be formalized a bit more.
So I’m glad that Matasano has a way to help you if you haven’t threat modeled. Our experience and observations over many, many years has shown that most people don’t want (or haven’t budgeted for) ninjas to drop into their process and slice up their design at the last minute. That’s why we’ve been sharing the SDL optimization model, building out the SDL Pro Network and sharing our approaches. We think that most people want to engineer a good and secure product from the start. We all need to work to make that easier, more predictable, and more effective. I also recognize that many organizations are not building security into their development processes yet. So it’s great to see Matasano think through what a threat model at the end of the dev process should look like, and share that thinking.
I wanted to reply to one thing that Cory said:
“It has spawned not just one, but two, Visio-driven toolsets from Microsoft and countless data-flow diagrams, attack trees, consulting engagements, and perplexed developers. When performed by a skilled and experienced team member, the model can be used to identify architectural weaknesses, guide default application behavior, and outline functional requirements for the product.”
Cory’s right. We have two tools, and it’s confusing. We’ll be making that much clearer soon. Additionally, we’ve presented a lot of information about our many approaches over the years.Today, we have one authoritative site at microsoft.com/sdl which presents the most current guidance. We no longer use attack trees. We’re working hard to speak clearly. Is it working for you? Let us know what’s not clear. Yes, there are a lot of books and what-have-you that can’t be updated, but we aim to publish and maintain guidance on the SDL portal that is authoritative, current, and understandable. Kicking attack trees is sort of like commenting on the security of Win98: we’ve learned a lot since then.
One of the most important things we’ve learned is that we needed to simplify the model, the approach, and the training, and we’ve done all three of those things. Having done those things, we’ve seen non-experts pick up the tool and create good threat models. We’ve heard from partners who are using the tool successfully, and we’ve received great feedback from analysts about efforts. None of which means we’re perfect. We’re still continuing to innovate with the aim of making the process better, and seeking the feedback from anyone who’s downloaded and applied our free tools and guidance. We’ve got some tricks up our sleeve, and while we don’t want to play them too close to the chest, we’re going to continue to innovate, and are glad to see a profusion of ideas for making things better. Finally, we work to share our experience.
We’ve seen the STRIDE-per-element approach work for non-experts. We suggest you give it a try. But far more important than which approach you try is when you try it. Start early. Take a look at the optimization model. If you want some consulting help, go to one of our Pro Network partners or even to Matasano. If you have a few hours, experiment with both approaches and see which fits. But start early and find a threat modeling approach that helps you deliver more secure software.
Pirates and script kiddies would prefer you just fuzzed.
10/20/2009: Updated with correct CVE - thanks to Matthieu Suiche for pointing this out to me.
Hi, Michael here.
When I wrote the first analysis of why the SDL had missed a security vulnerability, I made a comment that I would continue to write these posts, but only for bugs that interested me. To be honest, all security bugs interest me, but this one really got me to sit up because it’s in new code.
For reference, the security update that fixes this is MS09-050, and the bug is CVE-2009-3103.
What makes the bug of concern is it’s in networking code; thankfully, there are some mitigations available, such as the Windows Firewall, that reduce exposure to attacks.
First, let’s take a look at the vulnerable code. Can you spot the bug?
#define Smb2GetWorkItem( WI ) ((PSMB2_WORK_ITEM)(WI->ProviderWorkItem))
...
typedef struct _SRV_WORK_ITEM
{
//
// This is the Receive Buffer for the incoming request
PSRVBUFFER ReceiveBuffer;
PSRVBUFFER ResponseBuffer;
} SRV_WORK_ITEM, *PSRV_WORK_ITEM;
NTSTATUS
Smb2ValidateProviderCallback( PSRV_WORK_ITEM WorkItem )
PSMB2_HEADER pHeader = (PSMB2_HEADER)WorkItem->ReceiveBuffer->Buffer;
PSMB2_WORK_ITEM pWI = Smb2GetWorkItem( WorkItem );
PSMB2_CONNECTION pC = Smb2GetConnection( WorkItem->Connection );
NTSTATUS status;
pWI->ParentWorkItem = WorkItem;
pWI->AsyncId = RFSTABLE64_INVALID_ITEM;
WorkItem->ProviderWorkItemCleanupRoutine = Smb2CleanupWorkItem;
if( pHeader->ProtocolId != SMB2_PROTOCOL_ID )
if( pHeader->ProtocolId == SMB_PROTOCOL_ID &&
pC->Dialect == 0xFFFF )
// Handle downlevel multi-negotiate
pWI->Command = SMB2_0_COMMAND_NEGOTIATE;
goto process_packet;
}
else
WorkItem->DisconnectConnection = TRUE;
return STATUS_INVALID_PARAMETER;
pWI->Command = pHeader->Command;
process_packet:
if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )
Smb2OutputWorkItemRequest( WorkItem );
if( ValidateRoutines[pHeader->Command ] == NULL )
return Smb2ValidateNotImplemented( WorkItem );
return (ValidateRoutines[pHeader->Command])( WorkItem );
If you can’t see the bug, here’s the fix:
if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) ) { Smb2OutputWorkItemRequest( WorkItem ); } if( ValidateRoutines[pWI->Command] == NULL ) { return Smb2ValidateNotImplemented( WorkItem ); } else { return (ValidateRoutines[pWI->Command])( WorkItem ); } }
Look at the two array references to ValidateRoutines[] near the end, the array index to both is the wrong variable: pHeader->Command should be pWI->Command.
So why did the SDL miss this bug?
There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing. In fact we did find it very late in the Windows 7 development process through network fuzzing and that is why post-RC versions of Windows 7 do not have this bug.
Right now there is no static analysis tool I know of that would point out the developer used the wrong variable, and our analysis tools didn’t spot the potential array bounds problem in part because it’s hard to do so with generate a very large quantity of false positives. With that said, we’re looking deeper into the latter challenge now.
The only other method that could find this kind of bug is very slow and painstaking code review. This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all.
Some years ago I created a “How to review code for Security Bugs” class and toward the end I explain that code reviewers need to question all coding logic assumptions when the code deals with untrusted data; I will add a new bullet point: are the correct variables used?
I’ve mentioned this before, but it’s worth mentioning again. I think we’re getting to a stage at Microsoft where the SDL has whittled away most of the ‘low-hanging’ bugs. Of course, I might be proven wrong, but looking at all the bugs over the last year in Windows, the only pattern I can spot is there is no pattern! The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing. But fuzz testing is hardly perfect, because the malformed data might not hit the vulnerable code path or trigger a failure in the code.
I would say that this is a great argument for software developers spending more time on defenses against unknown vulnerabilities, as well as trying to prevent or remove vulnerabilities. The SDL mantra of “Reduce the number of vulnerabilities and reduce the severity of the bugs you miss” is very consistent with this belief.
- Michael
luv u kim x
Hi everyone, Bryan here. Peleus Uhley, Senior Security Researcher at Adobe, has written a guest post for the BlueHat blog on potential security issues with cross-domain access permissions for web sites. I’d like to encourage you to read Peleus’ post and also to expand on it a little to talk about the SDL requirements around cross-domain access.
Normally, the Same Origin Policy prevents web pages from interacting with resources hosted on domains other than the one they were loaded from. This is done for security reasons; without the SOP it would be trivial for malicious sites to steal or alter data on other sites. However, there are so many great legitimate uses for cross-domain access (like creating client-side mashups) that several technologies have been developed to allow it under limited, opt-in circumstances. These technologies include:
· Flash’s crossdomain.xml policy file, also used by Silverlight
· Silverlight’s clientaccesspolicy.xml policy file
· IE8 XDomainRequest object
· XMLHttpRequest Level 2 Access-Control headers
· JavaScript document.domain property redefinition
Now, there’s nothing inherently wrong with any of these (although I have argued in the past that cross-domain XMLHttpRequest would destroy the internet). The problem with using these is that it’s easy to inadvertently expose data to sites you don’t intend to expose data to. Using wildcard domains when determining which domains have access permissions exacerbates this problem. The canonical example of this (no pun intended) is the crossdomain.xml setting
<allow-access-from domain="*"/>
This setting basically opens the web site up to cross-domain access from the entire internet.
To help prevent sites from unintentionally exposing data to malicious external domains, the SDL requires any site with authenticated access to enumerate the specific domains it is allowing access to – no wildcards allowed. Otherwise, the site is free to make its cross-domain access as permissive as desired.
The original draft of the SDL cross-domain requirement was slightly different. Initially, the requirement included restrictions on the use of wildcards based on the depth of the wildcard (i.e. two-dots vs. one-dot vs. no-dots) and whether or not the site provided a “private API”. If a site contained only completely public resources, then it was allowed to use wildcards at the two-dots level or greater; for example, *.live.com would be allowed (two dots) but *.com would not (one dot). If a site had any resources only accessible by authenticated users, then no wildcards were allowed; all domains with cross-domain privileges had to be explicitly enumerated in the appropriate policy file or header.
However, we later realized that this requirement draft was both overly complicated and overly restrictive. If a site is completely public – no authenticated access, no private or sensitive data – then there’s really no reason to restrict its access at all. The reason for this is that cross-domain attacks are luring attacks. To succeed, the attacker needs to lure a victim into performing some action on the attacker’s behalf. For example, a cross-domain attack against a stock trading web site might cause the victim to send the attacker the complete details of his stock portfolio, or might cause the victim to make unintended trades. But in a completely public site, there’s no personal data to steal and no possible authenticated actions to forge. There’s no reason for an attacker to perform a luring attack – they already have the same access to the same data that everyone else has.
When we realized that our requirement was too restrictive, we changed it to its current form. However, let’s re-examine the requirement in light of Peleus’ research on cross-domain access chaining. (To give an extremely brief summary for those who haven’t read it yet: cross-domain permissions are transitive. If site A grants privileges to site B, and site B grants privileges to site C, then site A is implicitly and perhaps unknowingly granting privileges to site C.) For the completely public site the potential of privilege chaining is a non-issue in terms of SDL requirements; we’ve already said it’s acceptable to grant global access if desired. However, the situation is more complicated for the site with authenticated actions.
It is true that even with wildcard domains being prohibited, there is still the possibility that one of an authenticated site’s allowed domains could chain access to a potentially malicious third site. Unfortunately, short of banning cross-domain access entirely, there is no way to completely prevent this possibility. In most situations it would be impossible to map out a list of 3rd and 4th and nth order chained domains at development time, and furthermore it would be pointless since the list could change at any time even after the app has been deployed.
In light of this research, we will be evaluating ways in which we can adapt the cross-domain requirement to continue to prevent unintended access from third-party domains. However, the requirement as it stands now remains useful and relevant. It raises the bar for attackers while imposing minimal design constraints and minimal time investments on the part of the development team.
Hi everyone, this is Eleanor Saitta with iSEC Partners, with a brief post about return on investment and structured security.
A few weeks ago, Microsoft and iSEC Partners published a joint whitepaper titled, “Microsoft SDL: Return On Investment”, and I'd like to highlight a contradiction the paper discusses between what return on investment numbers show and common industry practice. In many cases, we see companies spending most of their security budget on gatekeeper-style security projects — right before the product is released, a security team gets called in to try to find vulnerabilities. This is more expensive and less effective than building security in from the start of a project and throughout the project’s development. Vulnerabilities are missed with the gatekeeper approach because in any large and complex system there's rarely time to look at every line of code and every function. That's not the worst of it, though — the cost of fixing the vulnerabilities found by the team can end up being huge because fixing security problems found late in the game may require a product be pushed back several stages in the development cycle and then retested to make sure no regressions are introduced and that the intended functionality didn't change.
This type of late-development churn is inefficient. In fact, the difference in cost between finding and fixing vulnerabilities early and fixing them once an application is about to deploy can be a factor of 30 or more (per a 2002 NIST study — see the whitepaper for more details) For example, if you're writing a web application and you perform an architectural security review, protecting against Cross-Site Scripting can be built-into the software as a functional requirement, and you can ensure that the application is designed so all output is correctly encoded. Putting in a point-fix at the right place in the framework and verifying that developers used the routine correctly is much easier and cheaper than trying to hunt down widely scattered cross-site scripting issues just as your ship deadline is approaching. Similar platform-level mitigations can solve a wide range of what are commonly considered low-level issues. Application platform vulnerabilities like Cross-Site Scripting or Cross-Site Request Forgery are what penetration testing is best at finding, but solving them up front with architectural review and secure design is still easier, cheaper, and more reliable than finding them in a gatekeeper-style penetration test and patching them.
In comparison, higher-level vulnerabilities in business rules, authentication, authorization or similar design issues can be both difficult to find and extremely time-consuming to fix if you only look for them once development has finished. Developers may have to change the core architecture of the system, leading to cascading code changes and regressions. On the other hand, a high-level security analysis (via threat modeling, security design review and related techniques) can be very effective at finding these types of issues. You can do this analysis even before development starts, preventing expensive architecture changes.