24 May How IT Staff Can Make a Professional Internal Penetration Test —Part 1
Pretend I’m doing some sort of introduction here with statistics from like the FBI and friends about internal threats.
Good, you just made the first step toward penetration testing—you imagined something. With a few tips you’re ready to do your own internal penetration test.
In this 2-part series you’ll get the know-how that lets any IT staff person make an internal penetration test. And yes, you’ll have to come back to get the punchlines of all the jokes.
From IT Pro to Penetration Tester
Penetration testing isn’t just for hackers and security professionals. If you know how your infrastructure technology works to a protocol level then you can test it fairly properly.
You may have read that penetration testing requires “thinking like the enemy.” It doesn’t. Most penetration testers can’t think like a criminal hacker either and nearly none of them can actually think like “the enemy” (whatever that means). Most of them don’t even know networking to the same level of detail as you do. No, most penetration testers just look for some key areas as to where they’d expect to find a hole or vulnerability. That’s not magic. It’s not even talent. It’s pretty much just this:
- Preparation from Door to Core
Your internal penetration test is about figuring out how a threat originating inside the company can cause you trouble. What is an internal threat? It’s everything. Well, it’s everything that can hurt the company or cost it money. That’s the thing about internal threats, they can literally be everywhere and anything. It’s like what head lice is to fourth graders.
So your scope is going to be everything from front door to server core. That’s all your internal systems and devices as well as all the people. You’re going to be checking for security gaps on everything telephony, wirelessy, desktopy, gadgety, and peopley. So pretty much everything at any time because criminal hackers don’t have rules. Well, except physics. But the mass media doesn’t seem to want you to think that physics applies to criminal hackers. But it mostly does.
After you define the scope of what you’re going to test you need to make a plan but not like you’re used to. You know how when you do any kind of roll-outs or upgrades you first get your crap together and get organized. Then you plan it out on a calendar and notify everyone. Well, you do that for your internal penetration test but only up until the notification point. You don’t do that. Get organized and plan but keep it to yourself. In testing terms that’s known as operational testing but in the real world it’s known as being mysterious. And that’s sexy. So do it.
After your planning you’ll need a few things. Go buy a pack of gum, a coffee table book on great Renaissance artists, a clipboard, and good-quality handcuffs.
- Threats Are Accidents Waiting to Happen
You know all those awesome IT tools you have that let you check on protocols, configure routers, remotely configure systems and troubleshoot? Well penetration testers use those too but yours are probably better. Use these tools to locate all the desktops, laptops, servers, wireless devices, and gadgets. Take a look at the network traffic and see what’s flying across the wire and in the air. Look for what’s not encrypted but should be. Look all day and all week and make sure you think about whether something should be happening at the hour it’s happening.
This is going to take a while so break out your book on Renaissance artists. Why? Because no IT Professional has ever been reprimanded for reading a coffee table book about Renaissance Art while working. And so what are the odds that you would be the first? Exactly.
When it’s all done, if you find anything from protocols to services to systems to devices to people you didn’t know about then you have just added your first threats to your report. For penetration testers, all the unknowns, unused, and superfluous anything are a security problem. It needs to be controlled or else it has to go.
- Security Is All About Vector
When you’re securing anything you pick the place where the attacker is going to be coming from. That’s the attack vector. Of course, the internal threat can come from anywhere so you need to test all vectors. You will test from DMZ to Internal. You will test from internal to internal. You will test from wireless to wired. You will test from host to host. Because if you can lock down the vector of an attack then no attack can come from there.
But what do penetration testers test when they test these different vectors? They’re looking at Visibility, Access, and Trust. It’s known as reducing your Attack Surface. This is detailed in the OSSTMM which you can and should read eventually. Seriously.
But for now, to move things along, what you want to know is what you can “see” from any particular vector. The police refer to this as opportunity. A criminal attacks what they think is there. From a security point of view, as many of those things as you can make disappear from the vector you’re probing from is a good thing. Put on your report everything you can see from each vector.
Anything you can log into or interact with from a vector is attackable and leave it at that. You can guess threats and vulnerabilities like penetration testers do some other day—when your imagination has improved. For now, put on your report anything that shouldn’t be reachable from this vector. And by anything I mean really everything that’s not vital to actually be connected to at this vector, even most file shares and printers. Security isn’t about “nice to have,” so all those desktops that connect to non-vital systems in the same office or department are in violation of that. Remember, it only takes one malware-laden USB key stuck in a computer to bring it all down. So it’s better if that malware can’t reach anywhere else isn’t it? So write it up.
That should give you plenty to get started. In Part 2 we’ll cover the testing of trust, controls, the more invasive “penetration” part of penetration testing, and the final report.
The opinions expressed in this contributor article are solely those of the author, and do not necessarily reflect those of Fortscale.