Security policies should be written to include the security assessment of your infrastructure. In this video, you’ll learn the best practices around baselining, reviewing code, performing design reviews, and completing architecture reviews.
<< Previous Video: Assessment TypesNext: Penetration Testing >>
An important technique for assessing the security in your environment is baseline reporting. You need to know where you are so that if you do have a breach or you’re considering adding on additional things to your network, you’ll have an idea of where you are today. So you want to determine what your risk is right now and be able to compare it should there be an event, should there be a new installation of an application, should there be new installation of patches, anything that we change so that we can compare it before and after.
We also need to think about what metrics and what type of statistics will be nice to monitor. It would be good if we got some feedback day to day on where security concerns might be. But the only way to do that is if we know what the security is today. How many people authenticate to the network at any particular time? How often do we see people authenticating and not putting in the right username and password?
We have to know what that is today so that if we see a large number of those, we’ll be able to determine, oh, that’s completely normal, or we might be able to determine that’s very very different. And then we can start researching further. You have to consider also this baseline may be appropriate today, but that baseline may change in the future. And of course, things happen in the normal course of doing business.
You may have a month end process that occurs. You may have a quarter end process or a year end process that occurs. And of course, equipment is moved in and out all the time. New applications are loaded all the time. You have new hardware that comes into the environment with new operating systems.
All of these things have to be considered. So you may end up having to create new baselines all the time. Another important security technique is to review the code that you’re using in your organization. This obviously is code that you would have access to. Not all applications will give you their source code.
You have to rely on the manufacturer of that application to be able to keep up with any security concerns and to make sure that their code is something that is secure. But for the code that you’re able to see internally, it’s things that you’ve written yourself, perhaps source code that you’ve downloaded from the internet and you’re using yourself, you’re able to go through it and see what is in that code specifically.
So you may need some development experts or people that are really familiar at understanding exactly this code. And they’re going to go through the code in a lot of detail. They’ll break it up into separate functions, into separate sections, and be able to go through it with a fine tooth comb and really give it a detailed overview of what’s in there. What they’re looking for is any part of the code that would open you up for a security vulnerability.
So you want to make sure that if there is any input into an application that you’re validating that input, that nobody can do any cross site scripting, that nobody can do any database injections. You want to be sure that any other type of input or output coming from this application is examined. And that’s where you really need to get somebody very familiar with the security concerns that we have today that also understand the application software and programming language that you’re using.
That’s a great combination, because they’ll be able to go through the code, validate everything that you have in there, and in certain situations, make sure that that code is not going to be susceptible to those types of security concerns. Usually when people are assessing the code, they also need to understand how your software work.
So there may be a design review of the software itself so that people understand exactly what this application is supposed to do. Everybody understands what the input might be for certain fields. They understand what the output is expected from this application. So you really have to go through how an end user is using this and how we’ve designed the software to work for that end user.
So many ways can a user input data? Does it have a lot of different fields that somebody might add information into? Every single one of those fields may need to be validated for the input that’s put in there. You have to think about the way that the bad guys would use this application against you and think about every possible attack vector, every single place a bad guy might use to get into your data.
All of these attack surfaces, whether they’re something it’s obvious, like a field, or something that’s behind the scenes like an API, needs to be considered. So part of your design review is really going to be looking at the details of this application. That’s why lot of people don’t want to add APIs or they don’t want to allow people API access, because that opens you up for security concerns there.
That’s why we want to keep that attack surface very small. If we’re able to limit what people are able to do in the application and the type of input that’s there, then we’re also limiting what the bad guys can do with that application. So your design review should look at the balance between the usability of that application and the security concerns that are associated with that usability.
Of course, an application isn’t just about the code itself. We have all these other systems that revolve around the application. There are web servers, there’s database servers, there’s application servers. There maybe middleware that talks to a mainframe. There’s so many different components to the way these applications work. So we also have to understand every step along the way.
We have to think about the security concerns for each one of these devices, for the database, for the web server, for our clients themselves in the application that’s used by our clients. If you look at the application and what we’re thinking about from a security perspective, it’s those very broad security requirements that we’ve talked about before. We need to think about confidentiality, we need to think about integrity, and we need to think about availability.
And we apply each one of those to every single component of the application. SQL is obviously a standard, but just because there is a standard in the way that we talked to the database engines themselves doesn’t mean that there aren’t different security concerns between the different database engines. A MySQL database interacts with the operating system and has different security concerns than for instance of Microsoft SQL Server.
Both of those use the same SQL language, so we have to not only think about the language that’s used into those databases, but do those databases have very specific vulnerabilities and things we need to think about from a security perspective. We also think about the end user as using a browser. But browsers are very different as well.
Internet Explorer is different than Firefox, is different than Safari. Each one of those browsers has different security concerns as well, and different vulnerabilities that people have found in those browsers. So don’t just look at your code for your applications. Think about all of the different components of your application and how they all work together so that you can get a very good idea of the security related to the entire architecture.