Why aren’t we stopping all the malware???
The term “APT” has become the boogey man of cyber security. :-)
You don’t need to know squat about writing malware in order to launch malware
- Malware rentals
- Malware as a Service (swipe CC, pay bitcoin)
Why aren’t we stopping all the malware?
- To solve the malware problem is to follow a very involved, multi-step process. Not every step can be automated; humans are needed (analysis, triage, more). This makes the process expensive, too.
- There’s no silver bullet
Product does not solve the issue. Process is required, too. Ideally, good process backed by good product.
If you knew you were going to be compromised, would you do security differently? — Marty Roesch, Cheif Architect, Cisco Security, founder of Sourcefire
Do security different:
- Plan A – Prevention: shore up the environment; dig a bigger moat, build thicker walls
- Plan B – Retrospection: track system behaviors without regard for disposition (ie, do this for everything, not just known malware but also “known good” and “unknown”)
- 1-to-1 signatures: like anti-virus; also hashes; AV vendors only enable 8-10% of their rules; AMP cloud runs all sigs all the time; admin can also set their own signatures in the console (create and deploy your own sigs when you need them)
- Fuzzy fingerprinting: ETHOS engine in AMP; looks at structural properties of the sample; captializes on how malware writers reuse code; AMP cloud scales up the fuzzy fingerpinting database by analyzing 100s of thousands of samples a day
- Machine learning: SPERO engine in AMP; software which can detect malware that’s never been seen before; machine learning requires a huge amount of data to train the algorithm (clean and malicious samples);
- Device Flow Correlation (DFC): constant reading of the telemetry of a host; network activity, browser URLs loaded, file I/O, versions of executables, file paths, more; all this done without regard for disposition; IP reputation blocking, custom white/black lists
- Advanced analytics: analyzing data in the AMP cloud that’s received from DFC, across all endpoints globally; examine dropped file relationship; vulnerabilities (identify hosts that are likely to be compromised based on information about software running on that endpoint); prevelance (call out binaries that are only running on very few endpoints in the endvironment; why would 1 person in the environment be running a binary that others are not when they’re running the same PC software image?)
- Dynamic analysis: AMP ThreatGid; sandbox environment that allows monitoring the sample from outside the sandbox; interact with the malware (bypass CAPTCHA); video recording of the entire sandbox run
All of the above, Plan A, is point in time. It happens “right now” and that’s that. If it got it wrong at that point in time, there’s no going back.
Prevention eventually fails
- Retrospection (looking back in time; looking continuously)
- Multiple components…
- “Retrospective Queue” – the AMP cloud remembers which endpoint/IPS asked about a particular file, IP, URL, etc. If the cloud changes its mind about one of those (goes from good/unknown to bad), the cloud tells all of those AMP agents “hey, I changed my mind”. From that point on, the agent can take action. Endpoint agent can snipe down the process, block further file I/O and so on. Network agent can block the file now in transit.
AMP agents exist on:
- Endpoints: Windows, OS X, Android. No Apple iOS (API restrictions)
- Network: FirePOWER
- Content security: Cisco Email Security Appliance and Web Security Appliance
Q: How does AMP for Networks (FirePOWER) deal with large files? A: you set a limit on how big of a file you want AMP to deal with. Default is pretty small but that’s the typical size of malware.
Q: If AMP for Networks is checking a large file, does it prevent the file transfer to the cleitn while it’s doing the checking? A: No, the file is transferred to the client but AMP will hold onto the very last packet and only release it once the AMP work is done.
Q: Is there a monitor only mode for AMP? A: Yes, called audit only mode.
Q: Does the AMP web console data get pulled into FireSIGHT? A: yes, some of the data. There’s a ton of data in the cloud so can’t pull it all. It pulls the detection data, the data about what’s bad.
Q: Do I have to be in the console to see when something bad is going on? A: No! You can set alerts and get notified when bad stuff is detected.
AMP for endpoints agent is SMALL. About 20MB. All the processing is done in the cloud so CPU usage on the endpoint is really, really low. Really.
Indicators of Compromise (IOCs)
- A method for describing indicators that very highly indicate that a host is compromised
- AMP has cloud IOCs that run in the cloud and look at the DFC data
- AMP for endpoint also has endpoint based IOCs which run on the endpiont; these IOCs are CPU/memory heavy so would only typically be used when there’s high suspicion of a compromise and you don’t mind using CPU/memory to go after it.