I Want to Detect and Respond to Intruders But I Don't Know Where to Start!

"I want to detect and respond to intruders but I don't know where to start!" This is a common question. Maybe you have a new security role in an organization, or a new service or business in your current organization, or some other situation where you want to find and stop attackers. However, you have no idea where to begin. Do you have the data you need? If not, what should you add? What do intrusions look like in the data you collect?

These questions can be tough to answer from a purely theoretical perspective. I propose the following approach.

First, conduct a tabletop exercise where you simulate adversary actions. At each stage of the imagined attack, consider what evidence an intruder might create while taking actions against your systems. For example, if you are trying to determine how to detect and respond to an attack against a Web server, you're almost certainly going to need Web server logs. If you don't currently have access to those logs, you've just identified a gap that needs to be addressed. I recommend this sort of tabletop exercise first because you will likely identify deficiencies at low cost. Addressing them might be expensive though.

Second, conduct a technical exercise where a third party simulates adversary actions. This is not exactly a pen test but it is the sort of work a red team conducts. Ask the red team to carry out the attacks you previously imagined to determine if you can detect and respond to their activity. This should be a controlled action, not an "anything goes" event. You will see whether the evidence and processes you identified in the first step help you detect and respond to the red team activity. This step is more expensive than the previous because you are paying for red team attention, and again fixes could be expensive.

Third, you may consider re-engaging the red team to carry out a less restrictive, more imaginative adversary simulation. In this exercise the red team isn't bound by the script you devised previously. See if your improved data and processes are sufficient. If not, work with the red team to devise better detection and response so that you can handle their attacks.

At this point you should have the data and processes to deal with the majority of real-world attacks. Of course some intruders are smart and creative, but you have a chance against them now given the work you just performed.

Tweet

Read More

Analog Penetration Testing

While watching the evening news I saw the story Investigation: U.S. borders perilously porous -- Federal investigators easily pass border checks using fake identification. On Wednesday the Government Accountability Office (yes, they changed their name) will release a report on an analog penetration test performed against the US border. What do I mean by that?

[GAO] agents successfully entered the United States using fictitious driver's licenses and other bogus documentation through nine land ports of entry on the northern and southern borders. CBP [Customs and Border Protection] officers never questioned the authenticity of the counterfeit documents presented at any of the nine crossings.

On three occasions -- in California, Texas, and Arizona -- agents crossed the border on foot. At two of these locations -- Texas and Arizona -- CBP allowed the agents entry into the United States without asking for or inspecting any identification documents.

This excerpt is from a draft report (.pdf) which will be delivered by GAO to the US Senate on Wednesday. Initial reports indicate lawmakers are really upset by these findings, because the situation has not improved since the last test in 2003.

What does this tell me? Apparently, decision-makers listen when findings are presented in a simple manner. If CBP fails to prevent people with forged IDs from entering the country, then it's clear they are not fulfilling their mandate. Simulating threat activity and discovering that attacks succeed 100% of the time is a damning critique of one's security measures. When presented in this manner, it's easy to see what works and what doesn't.

This is why I advocate penetration tests as a means to assess security. If it takes me five minutes to gain access to information you expect to keep private, that's a clear indication your organization has serious security problems. It's performance-based security measurement. Just how well do your people, products, and processes handle a real event?

This sort of thinking is second nature to anyone with military, law enforcement, or fire fighting backgrounds. (I'm sure there are others -- feel free to name them as comments.) These organizations assess their capability to perform their missions by exercising. Sure, you should take inventories, theorize, and so on, but the proof lies in how well you can execute in a near-real-world environment. (Executing in the real world is obviously the best test, but you don't want to put people's lives on the line unnecessarily.)

Do you want to know how well your airport screeners detect weapons in luggage? Don't measure your training budget, the education level of the personnel, or the number of steps in their checklist. Run fake weapons through X-ray machines and see who catches them.

How well is border security inspecting IDs? Don't count increases in the numbers of agents, measure their salaries, or inspect their guidebooks. Send agents across the border with fake IDs and see if CBP stops them.

How well does your enterprise protect sensitive information from unauthorized access? Don't pretend to assess threats, assign fake risk values, and count the number of packets blocked by your firewall. Hire a pen tester to steal your information.

Repeat the process in 6 months and see if it's more difficult. If yes, your security has improved. If no, your security has degraded. It's really as simple as that. Be careful to ensure the second pen tester is as skilled as, or superior to, the first pen tester.

Read More

Brief Thoughts on MJR Pen Testing Post

I learned of this post by Marcus Ranum through commentary by Dave Goldsmith. In brief, I agree with much of what MJR says. However, I think pen testers perform a valuable service. I do not think that it is possible for some modern enterprise code to be fully comprehended by any individual or team of developers or security engineers.

If the code cannot be fully understood statically, it must be tested dynamically. A live test will reveal how the system acts when working, and may reveal unanticipated interactions or vulnerabilities. In light of this fact, I think pen testers who unearth these flaws perform a valuable service. If it's not tested, it's not a service.

Update: Thanks to Tom's comment below, I changed the attribution to fellow Matasano poster Dave Goldsmith.

Read More