Okay, so we're ready to move along to secure software design, and we'll start off by talking about the design process. So we're looking at the design of an application there. Several things that we want to consider
a big buzzword lately or buzz phrase has been all about reducing the attack surface. Three idea. There is making sure that
you only have the modules that are necessary because the more med modules that are installed that air used the large, earthy attack surface threat modeling. Let's play the what if game. What happens if this threat materializes, or how Mike this threat materialize?
Then we think about risks in the design process. Then we also we're gonna look at our controls and determine if those are gonna be sufficient. So let's talk about reducing the attack surface. And whenever I hear this phrase, I think a lot about some of the changes made to the Windows operating systems.
And historically, what Microsoft has been very good at
is bringing computing to the masses, and I don't think many people will disagree with that. Microsoft has taken a product and put it in the hands off millions and millions and millions of people,
many people that would have been intimidated by other operating systems like UNIX and Lennox and some of the others out there. Microsoft made it easy.
the way Microsoft has has traditionally made things easy is everything is there. You know that idea off you turn it on and everything you would ever need is right there. And I take a look at maybe going back to Windows Network operating systems. And I think about like, for instance, with Windows 2000
Man, when you had installed Windows 2000 server that came with everything, including the kitchen sink. I mean, it had d. N s running in a d h cp. It had the Web service I I s. And if you really think about that, this is the same product I would use to create the main controller,
and it comes with II s automatically installed and running in. The whole purpose of a Web server is to share
the domain controller contains a whole lot of information I would not like to share. So the fact that they included this software up and running already installed really was ridiculous. From a security standpoint, But from an ease of use perspective, it was very, very good because people had everything they ever wanted right there and running
well. The problem is,
most users don't make purchasing decisions based on security. They make it based on ease of use, you know, home users or the same way as business users. I want something that I can put in the hands of my employees, that they'll be able to do what they need to do.
You know this idea of reducing the attack surface mains? And you know, we've seen this in later versions of Windows. Let's not have everything installed. Let's put the impetus on the users to install the tools they need.
We're gonna come just a bare bones operating system installation, and its users need other modules, other piece of functionality they can add those on. So we go from a huge attack surface of Windows 2000 that has everything installed to a tighter, smaller attack surface with 2008
and with Server 2012
even a smaller tax surface. The other thing that I think that's interesting that Microsoft has done with their later versions of network operating systems is they've included an installation called Server Core. And what server core is is a strictly command line based operating system.
I mean, it is straight looks like dolls, as a matter of fact.
So what they've done is they've taken away that gooey, no more point and click and server core installations. Why? Because the more code that's there, the more vulnerability the more surface there is to attack. So when I am thinking about designing a product, I want to give it a very small attack surface.
I want to make sure that we limit, for instance, how many user input fields anytime we allow the public to input information that always brings in a vulnerability. I wanna limit those user input fields as much as possible. I wanna force users to use drop down boxes
or check boxes or things that are already pre formatted
as much as possible, because we want to limit the potential off user entering damaging information into the input fields
Protocol Service's interfaces processes. If you don't need them, get rid of them now, one of the things later we're gonna talk about configuration management. We don't just decide arbitrarily in and of ourselves. Hey, we're not using I p Version six. So let's terminate the I P six support.
We don't make those sorts of changes on our own, and that could have devastating consequences
to a system or to the network is a hole. But what we do think about is we really have to take a look and say all of these elements that are included are they really important for the function of this software? You know, if I have to interface is on a server, and we're only using one of those network cards.
Get rid of the other interface.
It's just a potential point of vulnerability.
You know, back in early 2000 we might have many different protocols on the network. You know, we might have I p access PX for Novell back and server. We might have T c P I P. We might have apple talk to communicate with their apple based systems, you know. Today, though, most of us are using
and specifically we're using I P version four.
If there are other protocols installed and bound to your network card, there needs to be an examination of whether or not there really necessary our whole idea behind reducing the attack service, whether it's with pipes and sockets or resource files. You know the bottom line is,
if it's not necessary, disabled
or get rid of it. Guest accounts access control this configuration
accessible items does not matter. If you're not using it, get rid of it. As a matter of fact, that really is the first and most preferred step
to hardening system.
Reduce on. I'm sorry. Remove unnecessary service's or elements to the system.