Sam Bisbee, CTO of Threat Stack, argues that host-based intrusion detection systems (IDS) are better suited for cloud environments due to the software-defined nature of workloads, which require context for effective security monitoring. He highlights the limitations of traditional network-based IDS, including hidden costs associated with bandwidth and issues related to proxy complexities, suggesting that host-based monitoring provides clearer insights without compromising performance. Ultimately, the document advocates for reevaluating IDS approaches to focus on host-based solutions that align with modern cloud infrastructure.

1. WHY THE HOST RULES
CLOUD IDS
By Sam Bisbee, CTO of Threat Stack

2. Introductions
Sam Bisbee
CTO of Threat Stack
As the Chief Technology Officer at Threat Stack, Sam is
responsible for leading the Company's strategic technology
roadmap for its continuous security monitoring service, purpose-
built for cloud environments. Sam brings highly-relevant
experience in distributed systems in public, private, and hybrid
cloud environments, as well as proven success scaling SaaS
startups. Sam was most recently the CXO at Cloudant (acquired
by IBM in Feb. 2014), a leader in the Database-as-a-Service
space, where he played a senior technical and product role.

3. Intrusion detection systems (IDS) have
traditionally been deployed as network
hardware devices enabled by access to
the network infrastructure.

4. Today, intrusion detection
systems are struggling to find
relevance in a world where the
traditional network boundary
no longer exists.

5. This software shift has forced innovation in
how organizations collect data from their
Cloud environments and analyze that data
for threat indicators.

6. Some organizations began to work on this
problem before the Cloud became
pervasive.
Now everyone who wants to run their
workload in the Cloud must contend with
IDS in a software-only environment.

7. The opportunity can be taken
now to reevaluate whether it
makes sense to collect data
from and about the network
or the host.

8. How you answer this question directly impacts
the complexity of your solution and defines the
types of questions you will be able to answer
about your environment.

9. Three core reasons why we at Threat Stack
believe that host-based intrusion detection
is best suited to the Cloud and software-
defined environments…

10. 1. The Workload Holds The Truth

11. If everything is software, then
it’s critical to include it in the
way we do security monitoring.

12. This means that net flows by themselves are
no longer sufficiently valuable; they must be
contextualized with the users and processes
that participated in the communication.

13. For example, is it useful to know that an SSH
connection left your environment if you cannot
trivially associate it with a system user?
This context is critical for forensics and basic
alerting, but let’s push it further…

14. Role-based deployments of infrastructure
became increasingly popular in the Cloud
because it is so trivial to provision and
manage many small instances.

15. Each unit should perform one discrete
function, meaning that if a server alters its
workload, its operators should be notified of a
potential breach or misconfiguration.

16. This is one reason why at Threat Stack
we recommend grouping your
policies based on roles that match
your environment.
This allows us to detect new
processes, network activity, and file
system changes across a whole set
of servers.

17. Put another way…
All your web servers should look and act
the same, and your IDS should notify you
if this is not the case.

18. While a network-based approach may
notice a change in the amount or type of
traffic being emitted from your server, it will
not be able to tell you the source in your
workload that caused the abnormality.

19. This means that it is up to you, the operator, to
correlate host and network information, which
meaningfully impacts your mean time to root cause.

20. There is also no guarantee that the network
sensor would have even appreciated the
workload change.
It certainly could not have told you that a non-
system user was accessing your database
instead of your authorized workload.

21. 2. The Hidden Cost of Network IDS

22. Another fascinating side effect of Cloud
computing is that network, or bandwidth, is
the last finite resource in our environments.

23. Theoretically, there is an infinite amount of compute
and storage that can be provisioned. Companies like
Amazon and Google are incentivized to make as
much of these resources available to you as they can.

24. We have yet to see the same sorts of gains in
Cloud service providers’ (CSP) networks though…

25. When combined with the aforementioned ease
of provisioning many smaller instances, it is no
wonder that the benefits of parallelization
have outpaced the rate at which per-core
speeds have increased.

26. That is to say, horizontal scaling can
produce greater processing power
and efficiency than vertical scaling.

27. Why does this matter when discussing
host versus network monitoring?
Solutions that tap a network interface and send
carbon copies of packets to an off-host analysis
tool effectively cut your potential bandwidth in half.

28. This might be okay if the analysis is
of a high value, but the vast majority
of that net flow data will not be
valuable, which means that you are
spending through the nose on a
finite resource for little return.

29. This is especially costly if you are one of
the many companies out there like
Threat Stack working with large data
sets, which would require you to disable
network monitoring for those clusters.

30. Most databases are already replicating data
between hosts and many modern databases
are performing these transactions inline
across more than one host.

31. Replaying those streams and
doubling network traffic on your
database servers is costly for
both system performance and
your CSP bill.
Yet it is hard to imagine that you
would not want your IDS
protecting your databases…

32. This was not as much of a problem previously
for network-based analysis because a vendor
would sell you a piece of hardware that you
would feed traffic to with port mirroring,
allowing you to drastically decrease the impact
on network performance.

33. (I think it’s unnecessary for me to point out
that this will not work in the Cloud as there is
no loading dock address or remote hands…)

34. Sadly, many vendors are attempting to
replicate this model with “virtual
appliances” and network-based solutions
instead of embracing workload focused
analysis at the host layer.

35. “Cloud washing” network analysis is
simply untenable given the way we think
about and build our systems today.

36. 3. Concerns with Proxy Availability,
Complexity & Security

37. Let us assume that you are okay paying the price
to stream all or most of your traffic twice…
One common technique to decrease the per-
host penalty is to proxy all host-to-host
network traffic through a set of servers that are
running the network monitor or tap.

38. This set up heavily penalizes east-
west network traffic (server-to-
server), especially if you can imagine
introducing an extra network hop to
each RPC call.

39. But only proxying north-south network traffic
(external-to-internal) does not give you sufficient
visibility since you must understand how your
workloads interact with one another.
(Plus, as all of those articles from the 1990s and 2000s taught us,
perimeter detection alone is not sufficient and you must deploy
monitoring with a “defense in depth” mindset.)

40. However you arrange your proxies, you
really only get insight into the traffic if you
can decrypt it to inspect the payload.

41. Your north-south network traffic is almost
certainly encrypted and I have seen more
companies encrypt east-west network traffic
on principal due to fear stemming from high
profile disclosures.

42. However, decrypting that traffic costs
compute and likely introduces more latency
into the proxy’s network hop…

43. Not only does this put you in a position of
managing many proxy servers to sustain high
availability and throughput, but you also have
to deploy certificates and private keys onto the
proxies to decrypt the traffic.

44. This could be a very risky proposition
depending on where the proxy sits in your
network architecture.
This is especially true if you are decrypting
north-south traffic on a NAT host, because
now your private keys and certificates sit on a
WAN routable host.

45. Host-based monitoring does not introduce
any of these complexities.

46. We go so far as to never inspect
your network packets at Threat
Stack, instead only monitoring the
network connection table and
associating those connections
with processes in your system.

47. This way we can tell you who or what your
workload is talking to, and likely why, without
having to penalize network performance,
introduce new availability concerns, or
potentially put private keys at risk.

48. From our and our customers’ experiences,
the deployment of a host-based IDS is far
simpler than a network-based IDS, which is
itself a security feature.

49. A Few Final Thoughts…

50. You’ve likely noticed through this presentation that
the majority of our comparison has been from the
architectural and infrastructure point of view.

51. This must be the starting point for new security
products looking to secure Cloud deployments,
as we have seen in other software verticals.

52. Forklifting on-premises assets
or Cloud washing concepts
for off-premises deployments
leads to confused or less
impactful value.

53. Focusing on the workload and understanding
the new architectural behaviors in the Cloud,
such as the lack of network control and
bandwidth availability, naturally leads to host-
based intrusion detection systems.

54. See how host-based IDS
can work for you.
Give Threat Stack a Try!
threatstack.com