HOW DEVOPS AND MODELS ENHANCE BEHAVIORAL
DETECTION
Aaron Botsis, Threat Stack Product Manager
contents !
• What are models? • How to integrate security into DevOps processes • How behavior models work together in the
bigger picture
def·i·ni·tion Models detect changes in system behavior with algorithms and math.
!
!
Threat Stack’s Cloud Sight security product builds several types of these models.
What are models?
The Best Part: !
Models don’t need to be complicated!
WHY?
If you have any data science friends…
1. They’ll tell you that more data beats a better algorithm
2. Wait…data scientists have friends?!
So what can we do with MORE data?
Start with “processes with network activity”
1. For any group of servers, Cloud Sight builds a list of processes that are talking on the network.
!
2. Once it’s finished learning, it starts monitoring for new processes
This is a simple but extremely effective technique to identify behavior variations.
It’s SO effective that in a 28M event sample set of accept(2) and connect(2) system calls, we saw just 321 unique executable names across our customer base! !
!
We can apply similar techniques for other data such as process owner, parent process name, etc.
Why this is good.
It was difficult to ensure a group of systems that were functionally similar actually behaved in a consistent and similar way.
Back in the dark ages…
Thanks to DevOps and configuration management, system behavior is now a fairly consistent (and measurable) thing. !
!
Web servers that are all configured the same actually do the exact same thing, the exact same way.
…but then there was light
This is an epic win for security, my hipster brethren!
….Epic win?
Imagine these models can be created, destroyed and tested programmatically, alongside your existing development processes… !
!
• We can start by training these models during our continuous integration tests
!
• Why not train our models which behavior is “good” while we are at it? !
• It’s like a self-generating, infrastructure-wide whitelist!
Yes! Here’s why:
Anything that deviates from what we tested is likely an intrusion. !
!
If it’s not, it could inform us of imperfections in the system: !
• Maybe we forgot to test something… !
• Maybe there’s a corner case that only affects production, for some reason… !
• Maybe something’s running away because of an unidentified failure elsewhere in the system, consuming precious elastic resources…
We can apply these behaviors to systems we deploy for production.
When a system deviates from it’s expected behavior, quarantine and replace it automatically!
Once we’ve iterated and ironed everything out, we can add automated chaos-monkey style remediation to the mix.
Bringing it all together.
The number of interaction points between applications was minimal and easy to grok
Deploy used to mean “run make install”
However…
Today’s infrastructures are more complex than ever, and DevOps is showing huge value in quick iteration!
Thanks to configuration management: !
• Applications and the infrastructure supporting them are more consistent than ever
!
• It only makes sense to leverage behavioral monitoring to iterate quickly (without forgetting lessons learned from the past) while protecting the infrastructure at the same time.
