So we talked about white boxes and how white box tests occur. These tests are going to be performed with the knowledge of the I.T. security staff as we said. We usually have physical proximity access, usernames and passwords. Black box, that's unannounced. We really don't know anything about the task. Nobody is told ahead of time, and we're going to go in and just see how far we can get and what we can do. When we think about penetration testing, there Is a methodology that we will often use, and you could see the five phases of the penetration test methodology on the screen in front of you. We have the preparation phase, phase one, information gathering, phase two, information evaluation and risk analysis, phase three, active penetration in phase four. Notice we don't actually go and attempt to execute any sort of attack or probe or compromise against the system until the almost end of the whole penetration testing cycle. The first three phases, three-fifths, 60 percent of what we do is all about gathering information, preparing, strategizing, and positioning ourselves to then be able to go out and actively execute on the information we've discovered and utilize whatever information intelligence we may have to see how far we can get into the system. And then in phase five, we gather all that information up and ultimately, we analyze, figure out what went right, what went wrong, what could we have done differently, what do we think is there even though we may not have gotten to it, and then we generate a report of some kind that helps us to understand, and not just for ourselves, but most importantly for our customer. Give them a true sense of the things that we were able to do and walk through with them, help them to understand the information so we can help them to prioritize and target where they need to spend time and resources fixing things, and where they're already good at doing things and they should continue because those things are yielding good results. They're yielding protection of the network and resources are being used wisely, vulnerabilities are being addressed, and systems are secure. So let's take a look at each phase. A little more depth. Let's just go through and quickly discuss what it is we accomplish or do in each of the phases. In phase one, preparation. We're going to go in, and without defined goals, obviously, it's very hard for us to figure out what to do. So we're going to start scoping out what it is we want to achieve. We're going to go ahead and we're going to be meeting with the customer. They're going to tell us this is what we'd like you to be doing. These are the things that are going to be either depending on the nature of the test, available to you or not. Even if it's a black box test, we'll still be told "Hey, this is the deal. You can go as far as you want in these areas but there may be certain systems that are off-limits. They're in production, they're sensitive, we can't have you messing around with them. So anything that's in this IP range, you stay away from." Or maybe a totally open test. They just may say, "Here's the computer information that you'll need in order to start working. In other words, here's basically the name of the company. Here's maybe, again, the IP range for our gateway devices that it would potentially allow you to connect, and we'll see you in two weeks." It could depend, but in preparation phase, we're going to have that setup, meaning we're going to understand the scope, in effect, what's in, what's out. We're going to be given some basic guidance. We're going to agree with the customer what we're going to do, what the scope and focus is going to be, also includes what are the telltale signs, the signatures we will leave behind to validate that we touched the system. Are we planting a text file on the desktop of the compromised server? Are we taking a screenshot to validate we were there? We'll want to agree on that stuff ahead of time so that way there's no question about whether we were successful but there's also no potential that we can inadvertently compromise the system or do something to it that may ultimately result in a confidentiality, integrity, or equally important availability concern. So we're going to set all of that up ahead of time and figure out what it is we want to do and make sure we're choosing the appropriate tools for the testing environment based on the discussions based on the requirements the customer has laid out. When we think about going through and looking for information, gathering intelligence as to what may be there, preparing, in other words, to approach this, we're going to take a look at information that could be derived publicly. We'll take a look at LinkedIn most likely. We'll take a look at Facebook. We'll take a look at Google. We'll take a look at publicly available reports on the company, figure out who the officers of the company are. We'll then go ahead and search them, find out more about them. We may do some competitive intelligence research on the company. What do they do? Do they have customers they deal with that are strategic? Do they have suppliers they deal with that are strategic? Can we backdoor through one of those relationships and gain access to a system from there? That company may be easier to hack than this company. So if we know there's a connection there, maybe we can socially engineer our way into the system. Is there some sort of a service that they will outsource that maybe we can piggyback on or somehow compromise and gain access into the system? There's all these different things we, as pen testers, would want to think about, would want to know, indeed do know, about approaches that we can use to paint a picture and gather all the different points on the map and create an intelligence picture of the potential approaches, potential avenues or vectors that we may use to strategize about how to connect. And so you can see, we'll go through and we'll take a look for these things. Obviously, as we continue our discussion just looking at the additional items on the list here, I talked about some of the things already, but possible vulnerabilities, overall vulnerability ratings, things of that nature. If we begin to understand, for instance, that they are using Microsoft technology versus Linux technology, maybe SUSE, Red Hat, Debian, and if we can get a sense, "Hey, they have web servers. Well, what kind of web servers? Looks like they're running Apache Web servers with a certain build." We're going to be able to look for possible vulnerabilities. There are databases out there that will tell us what these vulnerabilities may be. There are hacking sites that will tell us how to exploit those vulnerabilities. So we can begin to gather that intelligence, piece together those pictures. And in our preparation phase, start to figure out what the borders. What the areas and the concerns will be that we'll focus on? What are the areas that are out of focus that only have a good, clear information there? What are the areas that are coming into focus? We're going to focus in on web services, focus in on these areas, these vulnerabilities. This looks promising. These are the kind of things we're going to be looking for. In phase two, we're now going to take that information and start probing. We're going to say, "We think we have this kind of infrastructure. Let's do some recon. Let's do some network mapping. Let's go out and really validate that. Let's make sure that that's there." So, we're going to send some information packets into the system and see what we get back. We're going to use automated scanners that are designed to look for certain systems and will then generate information that will validate that that system is there or will validate that we're not dealing with that system. We thought it was, going to be IIS version 7.5, find out it's something different and we now have a different set of assumptions we have to operate on. Want to find out what the extent of the network is. How many IPs are in use? What subnets are in use? Are we using VLANs? If so, how many? What type? Are we using secure protocols? If so, what kind? Are we tunneling? Are we encrypting? These are things we need to know because the more we know, more likely it is we'll be able to start to figure out not just the complete picture and build a map, but we'll figure out where the weaknesses are, where the white spaces that we can get into and we can operate within and we can start to exploit. So we're going to probe around the edges. We're going to do this, though, and this is one of the things to be aware of. We're going to do this, hopefully, we're good at it, without getting caught because the idea is that we're sneaking around and we're probing, pushing, prodding here and there, examining. Somebody figures out we're doing that, obviously the alarms and whistles and bells go off, people start to pay attention, and the cover is blown. They know we're doing this and now they're going to be on their guard so it will be almost impossible for us to get in. We have to be stealthy in networks, right? And so we have to move quickly but move quietly. We have to move with purpose. We have to examine things without being seen or seeming to want to do that. So we have to come up with ways to act slyly and use mechanisms, tools, and techniques that are going to be stealthy. They fly under the radar. We don't throw everything we have at the front end of the network with a real noisy scan, run up, knock on the door so everybody knows we're there. We stealthily probe. We may scan but we'll scan quietly. We'll scan slowly. We'll scan methodically. And over time, we'll build that picture.