Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
SHOWDOWN:
Threat Stack
vs.
RedHat AuditD
By Jen Andre, Co-Founder Threat Stack
We like magic.
But since magic isn’t real, we have to come up with the next
best thing to make our agent the best in its class.
Savvy operations and security
people that use our service are
blown away by the types of
information the Threat Stack agen...
“I’ve tried to do this with (Red Hat) audits with little to no success
…how do you guys do it?” they say.
The Linux audit subsystem is a
very powerful way to collect
information about system calls
and other security-relevant
act...
The best part…
No kernel module is required
to enable this detailed level of auditing
since it’s built right into Linux!
You can write a log anytime a particular system call
happens, whether that be unlink or getpid.
And since the auditing operates
at such a low level, the granularity
of information is incredibly useful.
Traditionally, people have used the user land
daemon ‘auditd’ built by some good Red
Hat folks to collect and consume this...
However, there are a couple of problems with
traditional open source auditd and auditd libraries
that we’ve had to deal wi...
…especially when trying to run it on performance
sensitive systems and make sense of the obtuse
data that traditional audi...
To that effect, we’ve written a custom audit listener
from the ground up for the Threat Stack agent
(tsauditd)
This is what makes Threat Stack’s
audit listener special…
1. Performance Enhancements
Many people have tried to use traditional Red Hat audits
in production to do very detailed aud...
We’ve ensured that our agent is
responsible with resource utilization
through our unique parsing model.
While benchmarking a web server,
we saw auditd consume 120% of
the CPU!
Threat Stack’s agent CPU
consumption
was only 10%!
2. Output Enhancements
This Linux audit system will output many different
lines across disparate events into syscall, which...
The key-value format is also
cumbersome to parse,
and values are often
encoded into hex randomly…
We’ve decided that all related events should
be grouped together and have conveniently
parsed everything correctly for you.
We then transformed that into a
JSON output format that is much
simpler to read and parse.
3. Network tooling (“src/dst port”)
Tracking network connections across multiple
hosts can be a manual and painful process...
To make it easier, our agent adds metadata
to network connection events to
determine where the connection is
originating f...
Our backend then correlates these network events to
determine the originating process and potential user activity
that cau...
This is especially useful for
tracking SSH sessions
across your environment and debugging
what servers are speaking to one...
4. User Activity Auditing
Digging around the server logs to see where a user on
your system went is not an easy job.
You’d need to manually find the agent and session that a user
connected to, yet all the kernel gives us is a nasty hex
enco...
On top of that, most of the information
logged by auditd is not really relevant, and
hard for the human eye to parse.
To correct that…
We’ve designed Threat Stack to keep storage of events,
activity, and commands associated with a logged in...
Stay tuned for more engineering feats we are
accomplishing at Threat Stack…
To learn more about Threat Stack
or to sign up, visit
	 	 	 	 	 	 	 	 	 	 	 threatstack.com 	 	 	 	 	 	 	
		 	 	 	 	 	 	 	...
Prochain SlideShare
Chargement dans…5
×

SHOWDOWN: Threat Stack vs. Red Hat AuditD

881 vues

Publié le

Traditionally, people have used the userland daemon ‘auditd’ built by some good Red Hat folks to collect and consume this data. However, there are a couple of problems with traditional open source auditd and auditd libraries that we’ve had to deal with ourselves, especially when trying to run it on performance sensitive systems and make sense of the sometimes obtuse data that traditional auditd spits out. To that effect, we’ve written a custom audit listener from the ground up for the Threat Stack agent (tsauditd).

Publié dans : Ingénierie
  • Soyez le premier à commenter

SHOWDOWN: Threat Stack vs. Red Hat AuditD

  1. 1. SHOWDOWN: Threat Stack vs. RedHat AuditD By Jen Andre, Co-Founder Threat Stack
  2. 2. We like magic.
  3. 3. But since magic isn’t real, we have to come up with the next best thing to make our agent the best in its class.
  4. 4. Savvy operations and security people that use our service are blown away by the types of information the Threat Stack agent can collect, correlate, and analyze from Linux servers.
  5. 5. “I’ve tried to do this with (Red Hat) audits with little to no success …how do you guys do it?” they say.
  6. 6. The Linux audit subsystem is a very powerful way to collect information about system calls and other security-relevant activity.
  7. 7. The best part… No kernel module is required to enable this detailed level of auditing since it’s built right into Linux!
  8. 8. You can write a log anytime a particular system call happens, whether that be unlink or getpid.
  9. 9. And since the auditing operates at such a low level, the granularity of information is incredibly useful.
  10. 10. Traditionally, people have used the user land daemon ‘auditd’ built by some good Red Hat folks to collect and consume this data.
  11. 11. However, there are a couple of problems with traditional open source auditd and auditd libraries that we’ve had to deal with ourselves…
  12. 12. …especially when trying to run it on performance sensitive systems and make sense of the obtuse data that traditional auditd spits out.
  13. 13. To that effect, we’ve written a custom audit listener from the ground up for the Threat Stack agent (tsauditd)
  14. 14. This is what makes Threat Stack’s audit listener special…
  15. 15. 1. Performance Enhancements Many people have tried to use traditional Red Hat audits in production to do very detailed auditing of user, process, and network syscall activity, but have failed due to the performance impact.
  16. 16. We’ve ensured that our agent is responsible with resource utilization through our unique parsing model.
  17. 17. While benchmarking a web server, we saw auditd consume 120% of the CPU! Threat Stack’s agent CPU consumption was only 10%!
  18. 18. 2. Output Enhancements This Linux audit system will output many different lines across disparate events into syscall, which you then have to correlate later via your ingestion engine or your log management system…
  19. 19. The key-value format is also cumbersome to parse, and values are often encoded into hex randomly…
  20. 20. We’ve decided that all related events should be grouped together and have conveniently parsed everything correctly for you.
  21. 21. We then transformed that into a JSON output format that is much simpler to read and parse.
  22. 22. 3. Network tooling (“src/dst port”) Tracking network connections across multiple hosts can be a manual and painful process when trying to connect across boxes.
  23. 23. To make it easier, our agent adds metadata to network connection events to determine where the connection is originating from and where it is going.
  24. 24. Our backend then correlates these network events to determine the originating process and potential user activity that caused that network event, so long as the agent lives on both the source and destination server.
  25. 25. This is especially useful for tracking SSH sessions across your environment and debugging what servers are speaking to one another and why.
  26. 26. 4. User Activity Auditing Digging around the server logs to see where a user on your system went is not an easy job.
  27. 27. You’d need to manually find the agent and session that a user connected to, yet all the kernel gives us is a nasty hex encoding string representing the connection address in the traditional auditd logs!
  28. 28. On top of that, most of the information logged by auditd is not really relevant, and hard for the human eye to parse.
  29. 29. To correct that… We’ve designed Threat Stack to keep storage of events, activity, and commands associated with a logged in user, and automatically reconstruct this information into a clean, compact, and readable timeline.
  30. 30. Stay tuned for more engineering feats we are accomplishing at Threat Stack…
  31. 31. To learn more about Threat Stack or to sign up, visit threatstack.com

×