Threat modeling applies equally well to both development projects and design/implementation projects for existing software products. 

If you already know about threat modeling, then skip to the section titled, “In the Wild.”

What is Threat Modeling?

As I mentioned, threat modeling helps you uncover potential insecure design issues in a system. The process of building a threat model is straightforward, and involves identifying the core elements of the system such as the processes, the data storage systems, how the data flows through the system and the external entities that interact with the system. Once this is known, the list of potential threats is automatically determined using the STRIDE mnemonic. The elements of STRIDE are:

S – Spoofing. The ability to pose as someone or something else.

T – Tampering. The unauthorized ability to change something.

R – Repudiation. The ability to disavow a transaction.

I – Information Disclosure. The unauthorized ability to view something.

D – Denial of service. The ability to degrade service.

E – Elevation of privilege. The ability to elevate capabilities.

Think of STRIDE as CIA (Confidentiality, Integrity and Availability) but more fine-grained, and from an attacker’s viewpoint.

Elements in the application diagram are subject to various STRIDE categories. For example a data flow between two processes (think: web browser to web server, or web server to database server) is subject to T, I & D. The next step is to determine which of these threats are a real risk. For example, do you care if an attacker can view (Information Disclosure) the data on the wire that flows from the web server to the web browser? If the answer is ‘Yes’ then that threat must be mitigated, and the way ‘I’ threats are mitigated is with confidentiality techniques such as access control policies or encryption. At this point, the appropriate mitigation is selected. This often requires using defenses and mitigations specified in the enterprise architecture.

This process continues until all STRIDE elements for each application diagram element are addressed.

In the Wild

The last nine months or so has seen me spend most of my time with our customers, and in every engagement we have built one or more threat models. I thought it would be worthwhile to explain some of the things I’ve learned from building threat models outside of Microsoft product groups.

Observation One: You WILL find Vulnerabilities

In every engagement, bar none, we have found insecure design issues that could render a system vulnerable to attack and compromise.

For example, when building a threat model for a law enforcement organization last year, the client said, “We know we have an issue, let’s see if the threat modeling process can find it.” The issue was uncovered in 20 minutes in the threat modeling session, and we found three more issues!

In another example, we uncovered a very serious vulnerability. This customer had a system that used devices to monitor critical infrastructure. The data flow between their monitoring system and the remote devices was subject to tampering (T) and information disclosure (I) threats, but those threats were addressed using cryptographic means. The remote devices are subject to all the STRIDE threats because processes are subject to S, T, R, I, D and E threats. Let’s look at ‘S’ – spoofing. The devices can be spoofed. In other words an attacker could replace a valid device with a rogue device, and the rogue device could continue to send back “System Nominal” signals to the central monitoring system while the critical infrastructure being monitored is attacked. You have probably seen scenarios like this in the movies! Clearly this is a real threat that must be mitigated. But there was no good mitigation being used by the system. Spoofing threats are mitigated with authentication, but there was no device authentication whatsoever in this system. The channel was encrypted between the two end-points, so the monitoring system had private communication with, well, something!

I have plenty more stories like this!                                                                       

Observation Two: Threat Modeling is Easy

Every customer I have worked with falls into one of two camps: the first has never used or heard of threat modeling, the second has built one or more threat models, and found it too hard. The good news is threat modeling is easy! If it’s hard, you’re doing it wrong.

A customer I am working with told me they had abandoned threat modeling because it was a waste of time owing to the investment involved. It was too complex, too time-consuming and provided little benefit. When I looked at what they were doing, they were drilling down to a FUNCTION CALL level! Remember, threat modeling is a design-phase task, not an implementation-phase task. You don’t need to go to a function call depth

After a little re-education, we spent a mere 45 minutes building a threat model for a critical application, and we uncovered three unmitigated issues. The customer is now a believer, and they now require threat models for all new applications.

Observation Three: Everyone is messing up SSL/TLS!

I know this isn’t a true threat modeling topic, but the answer to many people’s threats seems to be “we use SSL/TLS” which unfortunately is rarely the correct mitigation for many threats. The problems arise when developers build a system and use SSL/TLS programmatically. SSL/TLS isn’t simple, there are many details programmers must bake into their code to check that SSL/TLS and the certificate used by the server and potentially the client are correct to fully mitigate threats such as information disclosure and spoofing.

Getting SSL/TLS wrong in code may not seem like a big deal, but it really is, especially if you want to design a robust and secure system.

So What Should You Do?

If you want to learn more about threat modeling, take a look at the design section of the SDL web site. If you want learn EVEN MORE please feel free to leave a note below and we can get in touch.

Michael Howard,

Principal Cybersecurity Architect

The post Threat Modeling from the Front Lines appeared first on Microsoft Security Blog.

The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.

I think the first lesson from this attack is this:

If you have a Web server (doesn’t matter what type), and it’s hooked up to a database (doesn’t matter what type) you need to go in and review your code that performs the database work.

So now that you’ve determined the database access code, now what? The SDL is very specific about what do here, there are three requirements – they are requirements not recommendations, which means you must do the following coding requirements and defenses

• Use SQL Parameterized Queries
• Use Stored Procedures
• Use SQL Execute-only Permission

Use SQL Parameterized Queries

From the SDL documentation:

“Applications accessing a database must do so only using parameterized queries.

Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.

Combining the use of parameterized queries and stored procedures helps to mitigate the risk of successful exploitation of user input which is not correctly verified.”

This defense has been known about forever; heck, David and I discussed this in detail in the first edition of Writing Secure Code in 2002:

From page 320, “Another way to perform this kind of processing is to use placeholders which are often referred to as parameterized commands.”

Just about every database access technology supports parameterized queries; work out what they are for your DB technology and use them: the defense for a PHP/MySQL combo will not be the same as a C#/SQL Server combo.

The most likely cause of these recent compromises is using string concatenation to build SQL statements. Just don’t do it, even if you think you’re safe, just don’t use string concatenation to build SQL statements! There are some very specialized cases where string concatenation is valid, but they are rare, especially for Web apps. In my opinion, any use of string concatenation in a Web application is a high-priority bug.

Use Stored Procedures

From the SDL documentation:

“Applications accessing databases should do so only using stored procedures. ”

-and-

“Do not use “exec @sql” construct in your stored procedures.

Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints the stored procedures will throw an exception. In the vast majority of the cases, this should be properly handled within the application.

However, if the stored procedures perform string manipulation in their code and then execute that query using the “exec @sql” construct incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer.”

Note the words “help mitigate,” by themselves stored procedures do not remove SQL injection vulnerabilities; they just raise the bar on the attacker by hiding much of the underlying database schema from the attacker.

Use SQL Execute-only Permission

This next defense is interesting in that it is a defense in depth method; in this case it assumes the attacker has successfully found a SQL injection bug in your code. Now what? Thankfully, this defense will stop most every attack dead in its tracks.

From the SDL documentation:

“Only grant ‘execute’ permission on all stored procedures, and grant that permission only for the application domain group.

Ensure that this group is granted execute permissions only on your stored procedures. Do not grant any other permission on your database to any other user or group.”

This is a great defense, because if the attacker attempts to access any other database object other than through a stored procedure (you can use views also), the underlying database permissions model prevents the attack by denying access to the attacker.

It’s interesting that the SDL offers three SQL injection requirements; only one actually remedies the problem (secure by design) and the other two offer mores defenses assuming failure (secure by default.)

Of course, a simple set of rules is not a substitute for careful design, implementation, and test. The SDL is a holistic process that covers the software lifecycle end-to-end, so don’t mistake these simple rules as a guarantee that you will avoid SQL injection problems. You need to understand the situations in which the rules apply. You may find, for example, that string concatenation is the best – or perhaps only – solution to a particular problem and these rules may not guard against SQL injection in those situations. Follow secure development practice throughout the lifecycle of your project – including things we left out of this blog, like testing and security response, for best results.

The post Giving SQL Injection the Respect it Deserves appeared first on Microsoft Security Blog.