Dynamic Security Assessment: The Process and Functions

As we wind down the year, let’s get back into some forward looking research and get back into a concept we know will be more important in 2017. As described in the first post of the Dynamic Security Assessment series, there are clear limitations to the current means of security testing. But before we start talking about solutions, we should lay out the requirements for our vision of dynamic security assessment.

1. Ongoing: Infrastructure is dynamic and therefore a point in time testing isn’t going to be sufficient. That’s one of the key issues with traditional vulnerability testing, in that a point in time assessment can be obsolete before the report hits your inbox.
2. Current: Every organization also faces fast moving and innovative adversaries leveraging ever changing attack tactics and techniques. Thus to provide relevant and actionable findings, the testing environment must be up to date and factor in these new tactics.
3. Non-disruptive: The old security testing adage of Do no harm still holds. Any kind of assessment function cannot take down systems or impact operations in any way.
4. Automated: No security organization (that we know of anyway) has enough people to begin with, so expecting them to constantly assess the environment isn’t realistic. So in order to make assessment feasible as a sustainable capability, it needs to be mostly automated.
5. Evaluate alternatives: When a potential attack is identified, you’ll need to validate and then fix/remediate it. You shouldn’t be shooting in the dark, so it’s important to be able to see the impact of potential changes/workarounds to first figure out if the fix would stop the attack, and then figure out the best option if there are multiple.

Dynamic Security Assessment Process

Per usual, we start our research by focusing on process, as opposed to shiny technology widgets. The process here is pretty straight forward.

1. Deployment: The first step is to deploy the assessment devices. You could refer to them as agents or sensors or anything really. The fact is you’ll need some kind of presence both inside and outside the network to launch attacks and track the results.
2. Define Mission: Once deployed, you’ll need to figure out what a typical attacker would want to access in your environment. This could be a formal threat modeling process, or you could start with asking the simple question of “What could be compromised that would cost the CEO/CFO/CIO/CISO his/her job? Everything is important when you ask someone responsible for it, but to truly define the adversary’s most likely target, look at what will most drastically impact your business negatively.
3. Baseline/Triage: Next you need to get an initial sense about the vulnerability and exploitability of the environment by using a library of attacks to achieve the mission. Usually there are critical issues identified that require all hands on deck immediately. Once you get through that initial triage/remediation of the potential attacks, then you’ll have your initial baseline of activity.
4. Ongoing Assessment: Then you start assessing the environment on an ongoing basis. The automated feed of new attack tactics and targets are used to ensure you are looking for the latest attacks being seen in the wild. When the assessment engine finds something, administrators are alerted to successful attack paths/patterns for validation and then an determination of the criticality of the potential attack. This process needs to go on continuously since things change in your environment. From minute to minute.
5. Fix: This tends to be a step performed by the operations team and is somewhat opaque to the assessment process. But here the critical issues are fixed/remediated.
6. Verify Fixes: The final step in the process is to validate the issues were actually fixed. The job is not completed until you can verify that the fix is operational and effective.

Yes, it seems a lot like every other security assessment methodology you’ve seen. What needs to happen hasn’t really changed, since you need to figure out your exposures, understand the criticality, fix them, and then make sure they are fixed. What’s different is the technology that will be used for the assessment. This is where the industry has made significant strides to improve the accuracy and usefulness of the assessment.

Assessment Engine

The centerpiece of DSA is what we’ll call assessment engine. It’s really about understanding what is possible in the environment to determine the universe of possible attacks and then figure out which would be most damaging. This effectively reduces the detection window, since you don’t know if the attack has even been used on you, and helps you to prioritize remediation efforts by focusing on what could really work against your defenses.

You feed the assessment engine with the topology of the network since the attackers need to gain presence in the network and then move laterally to achieve their mission. Once equipped with a map of the network, existing security controls are factored in, so the engine knows if the devices are vulnerable to specific attacks. For instance, you’ll want to define the access control points (firewalls) and threat detection (intrusion prevention) points in the network and what kinds of controls run on the endpoints. This is a critical point because attacks almost always involve both network and endpoint attacks. So your assessment engine must be able to simulate both types of attacks.

Then the assessment engine can start figuring out what can be attacked and how. The best practices of attackers are distilled into algorithms to simulate how an attack could happen across multiple networks and devices. To illuminate the concept a bit, think the attack lifecycle/kill chain. The simulation does reconnaissance from both inside and outside the network to see what is visible and where to move next in search of its target.

It’s important to have presence and gather data from both inside and outside the network, since attackers will use both. Sometimes they get lucky and are invited in by unsuspecting employees, but other times they look for weaknesses in the perimeter defenses and applications. Everything is fair game and should be subject to DSA.

Then the simulation should deliver the attack to see what would compromise the specific device. With an idea of the controls on the device, you know what attacks will work. Using what is learned from recon activities, an attack path can be inferred from the entry point to the target. These paths represent lateral movement within the environment and the magic of the dynamic assessment is to figure out how the attacker would move within the environment, without hurting anything.

Finally, you’ll want to assess the ability of the attacker to exfiltrate the data, so the assessment environment will try to get past the egress filters with the payload.

To be clear, it’s not possible to really mimic what a human attacker can and would do when presented with specific and changing defenses. Your red team/pen testing activities play that role. Obviously you can’t pen test everything at all times, so the dynamic security assessment capability allows you to identify areas of concern and then use a human to validate and determine the most appropriate work around.

But this isn’t an either/or proposition. The answer is really both. The DSA algorithms provide a probabilistic view of your attack surface and help understand the most likely paths an attacker would use to access the target information and exfiltrate the data. To use a software testing analogy, this function is akin to increasing the code coverage of the application test. Humans can’t factor and try every path and attack every device, but the machine can and does.

Threat Intelligence

If we refer back to the requirements, the simulation/analytics engine takes care of most of what needs to be done. It provides ongoing, non-disruptive, automated assessment of your entire environment. The only thing missing is keeping the tool current, and that’s where threat intelligence (TI) comes into play.

Integration of new attacks into the assessment engine allows these new tactics and targets to factor into the assessment. If you are facing a sophisticated adversary, you know what they’ll be throwing at you, based on what other organizations are seeing. Basically you feed the assessment engine with new methods and let it crank the numbers. If a new attack would be successful, you’ll know about it – optimally before it is successful in your environment.

Keep in mind that automation is critical to a sustainable and useful assessment function. You don’t have time to keep the tool updated and manually run the new tests. And you’ve got more leeway with assessment, since you wouldn’t disrupt the environment with a faulty update. You may get some false positives (which would be annoying), but you wouldn’t lose half your network as when an endpoint or network security control update goes awry.

Visualization

Finally, once you have an attack that could potentially be successful, you’ll want to be able to dig into the specifics. The modern way of doing that is through visualization. You’ll want to be able to see the path of the attacker and which devices could be compromised. Drilling down into the specific devices and what the assessment engine showed were possible attacks can be instructive to identify both faulty controls or weak configurations.

The visualization is key to weighing alternative fixes to figure out which would be most efficient. By assessing how different controls would impact the simulated attack, you can identify quickly which remediation path is best.

If it seems that a dynamic security assessment capability sounds like what vulnerability management tolls should have evolved into, you’d be right. As opposed to looking at devices individually and providing summary data/dashboards about how quickly you are fixing vulnerabilities, the DSA engine puts those vulnerabilities into context. It’s not just about what can be attack, but how the attack would be part of a campaign to access the target and steal the information.

We’ll wrap up the series by applying these techniques to a realistic attack scenario. Since we’ve found defining requirements and discussing tech is fun and all, but the concepts resonate much better when used within a specific situation that you may see. Or more likely have already seen.

- Mike Rothman (0) Comments Subscribe to our daily email digest

from Dynamic Security Assessment: The Process and Functions