windows security development lifecycle

Windows Security Development Lifecycle

Table of Contents

Complexity and Security ................................................................................................................. 2

Windows Security Development Lifecycle (SDL) ............................................................................ 4

SDL Steps ......................................................................................................................................... 6

Threat Models ................................................................................................................................. 8

Code Scanning Tools ..................................................................................................................... 15

Code Review and Security Testing ................................................................................................ 17

Notices .......................................................................................................................................... 20

of 20

Complexity and Security

22

Complexity and Security

Modern applications and operating systems are very complex.• They try to be all things for all people.• The more complex it is the more likely it is to have flaws.• More complex means harder to secure.• Many efforts work together to increase the security.

Security Development Lifecycle is one link in the security chain.

**022 Windows security development lifecycle, anyone heard any estimates for how many lines of code are in a Windows operating system such as Vista, or XP, or Windows 7? They don't disclose that information. I want to say they. Microsoft does not disclose that information. But there are estimates out there. I'll use the estimate that I remember from Windows Vista. And it said there were fifty million lines of code in Windows Vista. All right? And if there's fifty million in Vista, there's probably some similar number in Windows 7 and Server 2012, and so on. Fifty million lines of code, wow.

of 20

Why so much? Just out of curiosity, why do the-- why is there so much code? Because these operating systems do so many different things. All right? They're very complex. They're very functional. They're very capable. I can use this operating system to allow me to control my SCADA system. I can use the operating system to allow me to control a robot in a warehouse to go pick my goods off the shelf. I can use it to do financial management. I can use this operating system to do desktop publishing. The OS gives everybody pretty much the capabilities to do whatever they want to do, very complex. And because of that complexity, you have to realize that complexity is the enemy of security. Fifty million lines of code, I don't know about you, but think about just slides. How many of you have ever created some slide presentation before such as this? A standard deck of, say, thirty slides. How many errors are you going to have in just thirty slides? At least, two? Yeah. If it's me, it's probably at least fifty. Who knows? Every slide's going to have one or more errors on it. It's hard to find these things. And so, when we think about getting control of these complex applications, there has to be a process in place. You guys remember the software development lifecycle? Well, the security development lifecycle is

of 20

basically a software development lifecycle with security features and functionality added into it.

Windows Security Development Lifecycle (SDL)

23

Windows Security Development Lifecycle (SDL)

Security begins in the development process.

Microsoft utilizes a framework to ensure security and privacy concerns are addressed throughout development.

SDL consists of• Threat models• Code scanning tools• Code review and Security testing

**023 Some of the security feature and functionality is this idea of threat modeling. Threat modeling, we'll talk about some of the tools that are available that help us with this. But the threat modeling is basically asking the question what if. What if a bad guy tries this thing? How is the system going to behave? So, we'll take a look at that. Security code scanning tools, there are some calls, there are some

of 20

functions, there are some libraries that are more secure than others. Code scanning tools might go through and say you've used this-- if you're talking about the C language, or family, you've used this strcpy. That doesn't have any bounds as far as how much input can be provided. How about if instead we change that to a strncpy where now we have some sort of boundary checking going on? Right? So, there are code scanning tools looking for those common problems. And there's also we'll talk about peer review as an element of code scanning. All right? And we'll also get into testing. Scanning it and looking it over, if you will, and saying it looks good to me is not enough. We actually have to verify that those bad things can't happen. To give you an example of the difference, I could walk around a house and look and see all the doors are closed, all the windows are closed. So, that looks good. The house looks secure to me. But I actually have to go up to the doors and jiggle the knobs. Is it locked? Here is an unlocked door that now will open up. And that's what the security testing's going to be. It looks good from the outside. We're going to jiggle the knob and see if we can find any problems with it.

of 20

SDL Steps

24

SDL Steps

Every step of the development process involves one or more security related functions.

http://msdn.microsoft.com/en-us/library/windows/desktop/cc307406.aspx

**024 So, here are the steps. And we don't care about memorizing the steps. The key point, as I mentioned, every step of the developmental cycle has one or more security functions. What I like to key in on first, though, is before we start off, there's some core security training that goes on. How many of you guys are programmers? Have done some programming in the past? Yeah. How many of you have went to school for- - to learn how to do programming? A little bit here, a little bit there. How many of you remember when you were going to school taking courses on secure coding, secure software development? Not too many people.

of 20

Now, the paradigm is shifting. Many organizations, many of the universities are starting to add some secure coding concepts and secure software development concepts into their curriculum. But the reality is, most of the people that are programming today, it seems that most of those people have no earthly concept of what security is. So, that's where that core security training starts. We get them into classes. We start to explain to them what the dangers are, how bad people can use their software in bad ways. And once they have an understanding of what is CIA, confidentiality, integrity, and availability, how does an application impact, either positively or negatively, the three core tenets of security, confidentiality, integrity, and availability, once they start to have these understandings, then they can start figuring out how can I add confidentiality into my application, or integrity, or what have you, into the application. Right? So, Microsoft has developed the security development lifecycle. And, again, every step along the way has one or more security feature and functionality. Many organizations, many other organizations today, have developed or adopted a similar type of developmental lifecycle for their in house coding that they're going to be doing.

of 20

Threat Models

25

Threat Models

Describe various failures and attacks that the software may be vulnerable to

• What are the threats?• What is the probability?• What is the impact?

Developers, once aware of the possibilities, can address these issues during the development process.

**025 All right. So, somewhere within that developmental lifecycle, usually early on in the developmental lifecycle, is where we're going to do threat modeling. So, threat modeling is asking the question, as I mentioned, what if. So, we're saying what are the threats. Let's make sure we understand the term threat. A threat is the potential for harm, that bad thing out there that can cause us harm. So, what are the potential threats? Mark Williams: Yeah, it's basically decision making. So, we put a list together of here are all the possible

of 20

threats. And then we start to look at which ones are probable. And we say these are things that are likely to happen to us. And so, then we start to figure out how can I minimize the impact of those threats. There are-- there's this category of threats that are possible, but they're not likely to happen. Very good example, non-computer related, is a meteor strike. Right? We say a possible thing that could harm my business is a meteor strike. But that is so far out of the realm of probability, that we're not going to do anything to address it on a day- to-day basis. Over here, we say in our software, this thing is probable. Not only is it possible for somebody to feed us bad input, but they will feed us bad input. And they will do it multiple times a day. So, if there's a possibility and a likelihood they will feed us bad input, now what's going to happen if they do feed us bad input? So, for example, my application, we have a field on my application says I want a phone number. So, phone numbers are exactly that, numbers. So, we're going to ask the question what are the chances that somebody feeds us letters or special characters. Probably pretty good. So, what's the bad thing that could happen if they feed us letters or special characters where we expect numbers? And once we figure out the impact, then we can decide what kind of constraints we want to put into our

of 20

application we're building. Right? So, we've got to look at all the possibilities, at least so we're aware of them. And then we can address them appropriately. You guys, as security minded professionals, we should be part of that group, that software development group, that is starting to look at some of these threats that are out there. Right? We should be guiding this process along, or helping to guide this process along. Yes? Student: That's a tough problem to get through because normally projects, software development projects, are not measured on security. They're measured on the functionality delivered in a certain timeframe. And then they talk about cost. And then they just talk about quality. But that's about it. They test it until they're-- they test until it's doing what they want. Then after that, they don't worry about it. So, and then also to get management to invest in training upfront, that doesn't add to their core capabilities. So, that's another obstacle to actually fall in that security development lifecycle. Mark Williams: Absolutely. And, along that line, the old way of doing business was we had a software development lifecycle, or a system development lifecycle, whatever term you want to use, and security was not part of the process. And often times what happened is right before

of 20

the system was about to be deployed, then the security guys go wind of it and said wait a minute. Let us take a look at it. And that's why we were always seen as a stumbling block to productivity because we would say wait a minute. You didn't do this right. You didn't do that right. And you've got to go back and fix it. And not only did we say-- were we seen as a stumbling block to productivity in that regard, we were also seen as causing the code to expand in an uncontrolled way. We seen-- efficiencies, we were seen as an impediment to efficiency of the code, as well, because we're now adding stuff in after the fact. The Microsoft security development lifecycle says we're going to get out of that paradigm. We're going to get to the point where the security people are represented at the very beginning. And they're staying engaged throughout the entire process. And, if we do it that way-- and it is a paradigm shift. The business does have to make this mental transition. We should be a catalyst for making a better product. We should not be a stumbling block. We should not be a red line item on the budget. When I say we, I'm talking about security, should not be a red line item on our budget. Security should be the catalyst to make a better product. And a better product, obviously, is going to be much more profitable for us. So, that's the issue.

of 20

Student: Also, another thing is companies are not held accountable for security of their products. So, I mean it's not important to them. That's the way it is. Mark Williams: And that is a very real possibility. I would say, from Microsoft's standpoint, it is important to them. It was important enough that they did change the paradigm. Is it perfect? Are they going to deliver a perfect product with error free code? It's not going to happen. Fifty million lines of code, that big, that complex, changes-- all the time we're having new features and functionality added. We're trying to accommodate newer technologies. Instead of writing to a traditional magnetic drive, now we're using solid-state drives. Well, if I go from a magnetic drive to a solid-state drive, that changes how my OS communicates to that device. So, there's always going to be changes to keep up. And there are always going to be issues that we run into. Is it going to be perfect? No. But if we use these threat modeling, hopefully we will minimize, not only the number of issues, but also the impact that each one of those issues has when they occur. Yes? Student: One more question, I mean you have these software and security development lifecycles, and the new way is agile development. So, now if you're doing rapid iterations, you've got a lot more things moving. So, it's harder to go and put-- to test security and all that

of 20

because what you tested out yesterday could change. So, how does the agile development methods mesh with the security development lifecycle? Mark Williams: I think the big thing is an organization that's going to develop or implement a secure development lifecycle, they're probably going to utilize a-- I'll call it a steering committee for lack of a better term, a group of security professionals that are going to be embedded with the developers. So, even in that agile environment where we have rapid changes and rapid modifications, we still have-- it's not just the programmers. And it's not just the program managers that are part of that steering off course. But there's-- along the way, there's a security person, security representation that goes with them. And as they want to make those course corrections, the security guy or girl is going to analyze, do a risk assessment, of each one of those course corrections. It's probably the best way of getting it done. Rather than having a central security group that only weighs in occasionally. Now, because we're embedded with the actual developmental process, it's a little bit more agile. Yeah? Student: Microsoft's-- their Visual Studio suite, the new one, implements the basic security code in

of 20

like that enable structure subscription handling, address randomization, so the tools are there already for them in the Visual Studio suites and stuff. Mark Williams: Yeah that makes it- - that does make it a lot easier. Microsoft is now starting to say we're going to take a lot of the pitfalls that traditional developers run into, we're take that out. They're off the table. You don't even have the option of making this stupid mistake because we're now going to control it within the OS and within the tools that we provide. Yeah, that's a good point.

of 20

Code Scanning Tools

26

Code Scanning Tools

Security tools designed to find SECURITY bugs in the source code

• Static analysis tools – effective at finding coding errors that lead to vulnerabilities like buffer overflows

• Fuzz-testing tools – designed to deliberately inject random data into the application to “see what happens”

Together these techniques help to identify a larger number of coding bugs.

**026 Code scanning tools. I would say there's two different types of code scanning tools. There's the static tools that I kind of eluded to earlier that's going to go through each line of your code and look at the functions and the calls and so forth, and maybe even the logic to some degree, to try to figure out are there mistakes that have been made there. But that is very static. It's not going to catch everything. Then we have fuzzing tools. Fuzzing tools are going to be the tools that do the, "what if." So, you're expecting this type of data, we feed you this other type of data. And we analyze

of 20

and figure out what the outcome is going to be from this fuzzing tool. So, those are just tools. And Microsoft provides a whole bunch of development tools that you can download. Some of them come with the frameworks that they provide. Some of them are stand alone third party tool-- I say third party, stand alone tools provided by Microsoft. And then there are yet other third party tools throughout there that you can use for code review and fuzzing-- fuzz testing. All right? But just using a tool is not enough. You guys know that there's no replacement for the human eyes. So, that's where we have peer review.

of 20

Code Review and Security Testing

27

Code Review and Security Testing

Code review• Tools alone are not enough.• Human eyes are a necessary component.

Security Testing• Designed to test the security functionality

— Does it properly Identify and Authenticate users?— Does it properly restrict privileges based upon policy?— How is security affected when there is a system failure?— etc…

**027 Other programmers that are looking over the shoulder and saying here's an issue that we found. Here's another issue we found. And if it's beyond peer review, security testing, vulnerability assessments, penetration testing, those types of things. All right? So, we think about security testing, does this particular code allow average everyday users to run the code? If it does, now the question becomes is that acceptable for this particular application. What about how does it compare to my policy? We should be able to look at any organizational security policy and

of 20

compare that policy to what's actually happening within the computer system and what's happening within the code. And so, that's why we have security testing, as well. When I say compare policy to what's happening in the code, I'll give you simple example, password policy. Let's say we have an organizational password policy requirement that says our passwords have to be no greater than twelve-- I'm sorry, no less than twelve characters. Right? When we get into the code, we realize wait a minute. This particular snippet of code here will allow for somebody to put in a ten character password. So, now I have to modify that in order to get up with our policy. Right? So, security testing, there's no substitute for it. But how much is enough? I mean we could test and test and test. Will we ever get it one hundred percent correct? Probably not. By the time we get it one hundred percent correct, the system- - the product will be obsolete. We will never have gotten it to market. So, we have to, from a business standpoint, weigh the pros and cons. And that's beyond the scope of where we need to go for the course. All right? But that is a decision that Microsoft had to make. For example, when I make-- when Microsoft makes a new operating system, when they make a new application, when make a new

of 20

framework for any tool that they make, how much coding do they do? How much testing do they do? At what point do they say it's good enough, and they roll it out into production, and they make it available to the end users? All right? That's a business decision. That's outside of what is here. Because of the security development lifecycle, they're doing a much better job. I'll give you an example, sometimes I had to do this, but I remember NT4. I hate to do it because it's kind of dating myself. Remember NT4, and all of the security issues that we would run into with NT4? And also, NT4 itself wasn't quite so bad, but then when we had service pack one, if my memory is correct, we, in our organization, started having a whole bunch of-- you guys remember that blue screen of death thing that occurs on occasion? Right? When we had service pack one, we had a whole bunch of BSOD issues. What the heck's going on with this? Why is this happening? When we got service pack two, started fixing some of those issues. Well, I've been running Windows 7 on my machine for over a year now. I cannot tell you-- well, I can tell you. I did not have yet one blue screen of death. Right? Now, I don't know if everyone can say that, but they've done a much better job because of their model. Because of their process, they've done a much better job at Windows 7.

of 20

I don't use Windows 8 enough to really say whether you're going to have many BSOD type of incidents. But the quality of the OS is a direct result of their testing and their code review.

Notices

2

Notices© 2014 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

of 20

windows security development lifecycle

Documents