It's Friday, and I'm lying down looking out a window where there's a thunderstorm outside, so here are some thoughts on a framework for understanding the cornerstone (I'd argue) of security: host defense.
First, if there:s anything we know it's that no security can exist in our environments if our devices are sufficiently compromised by an attacker. All applications have to run somewhere, All data worked with somewhere. All networks connected. All done by individual devices.
Really, if we want we could break all attacker techniques down into 2 broad categories:
-Those that don't require getting malicious agents on the target's devices. (For eg. account compromises via weak/non-unique/phished credentials, finding open S3 buckets, etc)
-Those that do.
Though the first have, until perhaps recently, not been taken as seriously as attacks that get malware down on machines, in many ways they are preferable from an attacker's standpoint. (No on-target malware to buy or build and continuously evolve. Etc. )
Thus, from a defender's standpoint we can say that in many ways host compromise with malware is both perhaps the thing we're most worried about and the thing we want to force attackers to have to attain by blocking other routes.
Let me submit an attacker faces the following layers of inherent challenges in trying to attain their goals by putting malware on devices:

1. Getting malicious code to the device.
2. Attaining useful arbitrary code execution. (Usually outside of isolation/sandbox.)
[cont.]
3. Establishing an operational foothold on the device, to the extent needed. (For eg. doing local recon, getting C2 going, establishing persistence, escalating privileges, etc.)
4. Ascertaining what new resources are now directly available to that attacker from that device.
5. If necessary, doing recon from the device and finding a way to get malware on more/other devices in the environment that may have better access to resources. In other words, lateral movement.

6. Doing all that without being detected and crushed by security.
From a defender's standpoint, ideally we can stop an attacker at one of those first two stages. If malicious code can't even get to the box (for eg. a well-implemented air-gap is in place), or if an attacker can't gain any useful execution of it once there, we win immediately.
But, alas, rarely are things so simple. Air gaps and one-way networks are nice but usually not practical. Email sandboxes and such help but can be evaded.

On the host itself, exploitation hardness, sandboxing/isolation, and execution control are valuable but vary by platform.
Thus, we defenders have to play at the other four levels too:
- Disrupting the attacker's building of a foothold (via app control, firewalling of unnecessary outbound connections, etc).
-Making sure key resources aren't available on/from machines most likely to be compromised.
-Making finding a means of lateral movement off of the device that was initially compromised difficult, time-consuming, and noisy.

-Last but not least, detecting the device has been compromised and responding to contain and destroy the intrusion before it can spread.
You can follow @arekfurt.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.