now, the last thing that we want to look at in relation to secure software design is we want to make sure that we're using secure technologies as they're available to us and make sure that we're considering all the elements in which our software could be compromised.
One of the things that we would think about first would be authentication and identity management, and this is very, very
big today, especially because we're because we're looking at sharing this authentication information across boundaries, and we'll talk about a little bit later. We'll talk about Federated Trusts, and service is now when we talk about identification, we've already said that's making a claim. So I claim to be Kelly Hander. Hand
authentication gives me a way of supporting that, whether to password a smart card, some sort of biometric means, whatever that is.
So when we talk about identity and access management, what we're looking at here, all the service is that policies and procedures of ways that we use to manage a digital identity. So how that account gets created, how that account gets managed, how we allow,
elements that control to be monitored, an updated or or that identity.
Then we also have to think about the security controls that we put on Ah, and that we used to manage our digital identities, you know, especially to make sure that we're under legal compliance. Sarbanes Oxley socks, which I mentioned earlier, is very accountability oriented, very heavy young auditing,
so verifying that identity is very, very important in relation to socks.
We think about credential management.
Uh, earlier, we discussed things like cross site scripting and see surf attacks and specifically, the sea surf, which again stands for cross night requests for forgery takes advantage of my pre established session and the fact that that session information might be stored as a cookie on my system
and it might be stored in plain text.
So we want to make sure that any credentials that I have in any sort of whether their passwords or session ideas or any type of information along those lines, we want to make sure that that information is protected. We want to make sure that we have proper authorization and the privilege escalation doesn't happen.
We want to have good, strong authentication mechanisms in place so that we don't allow unauthorized access
uh, in any time we talk about, you know, strong authenticity, we think about multi factor authentication, the use of certificates. We may talk about using biometrics. We might talk about using smart cards, any of those other elements, and then this idea of single sign on,
uh, which is what allows me to log on to the domain with a single set of credentials, my user name and password frequently.
And that allows me access to all Resource is in the domain Now. The problem with that is the idea of keys to the kingdom. If I just need one password to access everything in the domain,
all in attacker needs is that one password to access everything in the domain. And what we're moving towards today is a night is an idea of super sign on, not just single sign on but super sign on and what we're seeing more and Maura's. I provide one set of credentials like, for instance,
my social media credentials, whether it's Facebook or Twitter, whatever that might be.
And those credentials allow me access to many different resource is whether it's the Washington Post, whether it's Pandora radio, whether or not it's uh, you know, renting a car through hurts or whatever brand I would use. So the idea is,
and being able to forward this authentication information across Federated Trusts really expands the idea of identity and access management, but also credential management as well.
Other things about implementing in a secure mechanism we have to think about controlling the flow of traffic. We have to think about elements on our network we can use to provide additional security. Whether that's through the use of proxy servers and firewalls that provide inspection of traffic,
middleware can be good or bad. Ideally, what middle where is is it's that in between interface that does Theo inspection of request from an untrusted entity trying to access trusted back in resource is so that middle wears there in the middle,
providing inspection of that request.
Ah, the other thing that I'll point out here. Well, I'll point out the others logging. It's essential that we track activities and logging.
You know, we have to determine what needs to be logged and what doesn't because logging can be very resource intensive, but it can also provide us with lots of information that would be valuable to us, especially in the realm of security
data loss prevention, DLP systems. What the's systems look for is that of loss, and we talk about data loss. We're not talking about it being exposed. We're talking about it being ex fil traded from the network.
Many large organizations, whether its target or Home Depot, or some of the other organizations that we've heard about over the years have seen loss of credit card numbers or personally identifiable information or personal financial information.
And what's happening is thes. Millions of card numbers in these millions of
user accounts are being siphoned off the network.
Now there's gotta be a mechanism in place that says, Wait a minute, We seem to see the export of 72 million credit card numbers
seems odd, and that's exactly what a DLP system is designed to do. It's designed specifically to look for certain sensitive types of information, leaving the network and ideally decisions that these systems are installed. And if they're configured
and that's always an important element,
then they should be able to detect the ex filtration of sensitive data.
Virtual ization. Virtual ization has been around for a long time, and is very, very valuable to us. What it allows us to do is it allows us to go from many physical servers down to a smaller number of physical servers, and we run virtual servers within the physical machine.
So back in the day when we had to create multiple physical service is
I'm sorry, multiple physical servers because maybe we had applications that conflicted with each other. Now we can use virtual ization to solve that problem.
We have to be careful, though, because when we cut down on the number of physical servers we have, we're limiting or we're We're cutting back on the number of servers that need to be compromised from a denial of service perspective. So it's good that we're using fewer physical servers,
but it could also be a negative as well.
But virtual ization helps us in a lot of ways, and it helps us provide isolation from applications that would not normally work well together. Applications that don't play nicely with each other need to be isolated, and virtual ization is one of the ways that we do that,
um, the idea of trusted computing and understanding that we have elements on our system. That should be beyond reproach. These air, the elements of our system, that air part of what we call the trusted computer base. So we think that our memory our operating system, Colonel,
when we think about our system bias
and many other elements, those should be trusted and should absolutely enforce the security policy off the system.
So two main elements of the TCBY we talked about these earlier the reference monitor in the security Colonel,
the reference monitor. Those were the rules
governing how a subject can access an object.
The security colonel is the actual software coding or even hardware mechanisms that enforce the rules off the reference monitor. So if you think of the reference monitor like the laws and if you think the security colonel like the police, the police enforce the laws of security. Colonel
enforces the reference monster.
Other elements of trusted computing. Many systems now are built with a chip on board called the T P M chip, a trusted platform module. And that's a chip to store the encryption key for your hard drive
so that if your hard drive is removed, maybe someone steals your hard drive to put it in your home, their home computer.
That hard drive will not function because the key to unlock the hard drive is on the T. P M chip on your motherboard.
If you're familiar with bit locker bit locker technology was created to take advantage of gpm.
Okay, other issues then that revolve around trusted computing. Um, when we talked about security models, I talked about Debra. I talked about Bella Padula. I talked about the Clark Wilson security model. One of the security models that I didn't talk about was one called the Secure State model.
And what the secure state model says
is that if a system starts securely
and if a system provides all of its functions securely
and if the system shuts down even in failure securely,
then we have a secure system,
and I know that doesn't sound like rocket science. There is pretty straightforward, But what's important to understand is that if a system doesn't function securely in any of those states, then it's not a secure system at all.
So I don't care how many secure mechanisms you put into the operating system. If I can compliment your if I can compromise your system bios and we never even hit your OS. Then none of those security mechanisms matter. And as a matter of fact, the hardest time to secure a system isn't start up
because the security mechanisms haven't yet been loaded.
And this is one of the ways that root kits get installed on systems is by loading very, very early in the process before the security mechanisms air loaded. Therefore, kind of bypassing the normal strategy is a matter of fact. There was there was a virus that was very successful. I can't remember the name of the virus, but basically
it was created to have a V X T extension,
which that extension is for virtual device drivers and virtual device drivers get loaded very early on. They get loaded with the operating system kernel. So because of the fact that this virus that loaded so very early on and got kind of up there and integrated with
the operating system kernel, it was very, very difficult to eradicate and that's the cape was case with root kits.
You know, root kits become integrated with the operating system kernel, and they're not a whole lot of mechanisms that scan the colonel for security vulnerabilities. More and more software's getting capable to detect and possibly even to remove root kits.
But traditionally, work kids have just been nasty, nasty, nasty elements.
Uh, so when you do get a root kit on your system, generally what's gonna happen is you're gonna have to wipe out the system, reinstall the operating system and then restore the data from backup because of the death
of the installation that route.
Other things to think about. We think about privilege management, making sure that we follow that idea of principle of least privilege and then with database integrity. We've already talked about that a little bit. We've talked about Intuit validation. We've talked about,
uh, code injection. We've talked about Polly and Stan. She ation in some of those ways that we guarantee integrity databases.
So ultimately, we're gonna wrap the section for secure design. We're gonna wrap that section up, and our next element will move into implementing. So what we've done to this point in time is we've talked about some of the concepts that were concerned with with secure software development.
We've talked about secure software design.
Now we're gonna move on to our Actually, we talked about secure, uh, concepts. We talked about getting secure requirements than secure design. Our next element will move into in just a few minutes, is gonna be creating secure code, so actually coding
based on the principles that we've talked about up to this stage.