I Want to Detect and Respond to Intruders But I Don't Know Where to Start!
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.
Comments
Excellent advice, but I have to say, this can go quite badly for some. As an incident responder, I shudder when I'm on-site and one of my fellow responders makes a couple of assumptions about what happened prior to us showing up and says, "..if I were the hacker, I would do..."...this very often leads down rabbit holes and can chew up a lot of time if not managed properly.
I think your advice presupposes some level of threat intel being available. At the recent DC3 event in Atlanta, I attended several presentations that had "APT" in the title, where the presenters talked about "lateral movement" and "persistence in your network"...and I heard the attendees asking, "what does that mean?" and "how do they do 'lateral movement'?"
You can't realistically simulate adversary actions if you don't understand what can and is being done. By that, I'm not referring the breadth of all possible actions an adversary could take...instead, I'm referring to what's already been observed.
Unfortunately, there really isn't much in the way of good, solid threat intel available that folks could use to perform these simulations, without paying a hefty fee to a consulting organization to come in and run it for them.
Again, I like the advice. I've used these techniques myself, running mock incidents for customers. However, engaging with folks at a number of conferences recently, what I'm seeing is that there's a lack of good, solid, real-world information from which to run a realistic tabletop exercise.
An example of this is asking the following:
1. What is the company trying to defend?
2. What are the different known avenues of accessing this data?
3. What do we have in place from a control perspective? (monitoring, preventitive, etc..)
At this point the company can seek out a reputable firm to conduct a "advesary simulation". During this time frame the internal responders can better understand their own limitations, successes, and get professional feedback on these areas. An action plan can be created to learn from the knowledge gained.
These activities do not require explicit expertise in threat intell to implement. Rather they require explicit expertise in the business of your company.