Threat Stack Agent & Event Stream Data Overview
This article is designed to help you understand the extensive capabilities of the event stream data collected by the Threat Stack Agent. The examples in this article can help you understand how to better monitor and alert on a few common cloud security use cases.
These are the fundamental ideas for how Threat Stack designed our security monitoring:
- Event Processing - the Threat Stack Agent collects events around system, process, and user actions and streams them to the backend application.
- Rule Based Identification - to isolate signal from noise, events are processed against system and user-defined Rule Sets to identify critical events of interest.
- Alert Notification - identified issues generate alerts which generate notifications.
- Alert Management - dismissing or suppressing alerts.
The Threat Stack Agents collects events around user activities, process, host and network events. Our application backend correlates the event stream data to provide a context for common security use cases.
Use Case (1) Events of interest for any user and group modifications (Add/Remove/Modify) on production systems.
Use Case (2) Events for any user privilege escalations, a typical scenario is for customers to have an approved list of sudo users and wants alerting and log trail for any violations.
Use Case (3) Detect unauthorized changes on production system. Only the configuration management agent (Chef, Puppet, Ansible, Salt) is authorized for deploys/file copy/install; track any user violations for change operations.
Use Case (4) Generate detailed events and an audit trail for all users' TTY sessions for activity monitoring.
Use Case (5) Monitoring for any privileged application user accounts usage.
Use Case (6) Abnormal user login/access attempts (rate or login/brute forcing/password attacks).
Use Case (1) An unauthorized system kernel module or package is loaded or initialized on production systems (indicators of rootkit, APT type malware).
Use Case (2) Detect for deviations for any changes in authorized Ports/Services (Process binds/open).
Use Case (3) Events for any new process connection states. Typically new ACCEPT/CONNECT, this indicates possible intrusion or command-and-control type of activities for unauthorized connectivity.
Use Case (4) Track any unauthorized or abnormal process Start events by user or processes.
Use Case (5) Audit trail activity for any critical file system changes/reads/transfers and permissions changes.
Use Case (1) Monitoring critical credential file access/modifications for misuse/abuse typically indicates insider threat activities.
Use Case (2) Monitor Critical system directories (/boot/, /lib , /usr/lib , /bin/ , /sbin, /etc) for new executables or binary replacement/modification typical indicates intrusion or command-and-control activities.
Use Case (3) Monitor unauthorized modifications to system and application configuration files (e.g: sshd.conf, ntp.conf, resolv.conf Apache, MySQL, etc).
Use Case (4) Monitor for any data exfiltration type of activities on critical identified files (OPEN, COPY, TRANSFER) - Insider threat scenarios typically related to stolen credential files, SSH Keys, certificates.
Use Case (1) Monitoring for any critical system services changes (NTP, DNS, Syslog) daemon re-configuration/port/destination or source changes.
Use Case (2) Monitoring for any System Application Service changes (Apache, DB Server Binds, Proxy, Application Services).
Use Case (3) Monitoring for insecure protocol usage for System access (Telnet, FTP).
As an example, enter dst_port = 23 or dst_port = 21 in the event search field.