Cloud Security Use Cases and Threat Stack Base Rule Set

Follow

 

Security in the Cloud and Threat Stack Rules

Our security engineers routinely help our customers with understanding their cloud environments, identify use cases and help with cookie cutter alerts to get alerted on those use cases.

There is a lot of commonality among the use cases that we help out with customers, they usually fall into four categories :

  1. Data Loss identification and alerting
  2. Early identification of Advanced Persistent Threats
  3. Identify Operational Issues
  4. Compliance Issues

 

The following are the use cases in each of the above categories. In all the cases, Threat Stack can detect the malicious activity with a single rule deployed across their entire environment.

Use Case Category - Data Loss Prevention: Copy of customer data, configuration secrets and intellectual property from production environments.

Copy of data falls into three categories - copy of customer data, copy of configuration and encryption secrets, copy of intellectual property.

Questions from the Customer

  • How do I get informed and alerted of customer personal and financial data getting copied from your production environments ?
  • How do you know that the keys to the kingdom (operations secrets and configurations) are not ferried out of production environments ?

 

Use Case DLP.1: Copy of customer data, personal information

Our customers have critical personal data such as patient records that exist in files or data bases on specific machines. They have observed internal actors such as developers un-intentionally copying the files out of prod and want to get alerted when such activity happens by internal or worse, external actors.

Use Case DLP.2: Copy of internal configuration , passwords, certs and keys.

Keys to the kingdom such as SSL certs and PEM files are on each machine, they can be read by applications but cannot be copied or modified.

Use Case DLP.3: Copy of Intellectual Property

Files such as architecture diagrams of products or technology code base reside in prod and our customers want to get alerted when those files get opened by users.

Threat Stack Rule:

Our customers deploy a simple rule such as below to detect data loss :

(command = "scp" or command = "wget") and type = "start" and syscall = "execve"

 

Use Case Category - Advanced Persistent Threats

Question to Cloud Customers

  • Do you know when attackers use zero-day exploit to escalate privileges on servers ?
  • Do you know when new un-authorized process gets installed on production machines ?
  • Do you know when that process makes connections to command and control servers ?
  • Do you know when the attackers achieve their action on objectives - steal intellectual property or financial information - and preferably catch them before they get to their action on objectives ?

 

Use Case APT.1: Reconnaissance of Attackers through Wide Open Security Groups

Our customers that don't know they have wide open security groups are often surprised when we point them out, specifically which machines are deployed in a security group with security groups with inadvertently opened ports.

Threat Stack Rule:

Whenever there is a wide open security group, machines in AWS will get hit with NMap scans from the Internet. One of the ports that will absolutely get scanned is SSH (port 22) and HTTP (port 80) . Our customers deploy rule to detect any accept connections on SSHD and put a count of 60 to reduce false positives.

command = "sshd" and type = "accept" threshold= 60 window_seconds= 3600 severity= 2 (Medium Severity)

 

Use Case APT.2: Abnormal login attempts and login failures

After finding an open port, the attackers will use dictionary attack to access the servers.

Threat Stack Rule:

group = "authentication-failed" 

group like "failed"  will catch broader set of login failure types

 

Use Case APT.3: Privilege escalation by processes

APTs use zero day exploits to enter into the environment and the next thing they do is to escalate privileges, either to install new programs to listen for command and control or add new users etc.

Threat Stack Rule:

Threat stack rule to detect privilege escalations

(command = "sudo") and user != "root" and type = "start" and syscall = "execve"

 

Use Case APT.4: New Processes, Kernel Modules.

Once the attacker escalates privileges, a new process gets installed on the servers that can receive commands from the attacker. Since the attacker wants the process to get started even after the machine reboots, the attacker uses kernel modules and /etc/init scripts to run the process.

Threat Stack Rule:

(command = "insmod" or command = "rmmod") and type = "start" and syscall = "execve" and arguments != null

 

Use Case APT.5: External Connections for Command and Control

The child process then connects to a command and control IP address. Since outbound connections are generally allowed, such behavior is hard to detect using traditional tools.

Threat Stack Rule:

type="connect" and connection.addr != null and connection.addr != "127.0.0.1"

 

with suppressions not to alert on internal IP connects

(ip starts with "10." or ip starts with "172." or ip starts_with "192.")

 

with suppressions not to alert on various data collection tools and AWS 

user = "dd-agent" or user = "scoutd" or user = "deploy" or user = "deployer" or user = "automata" or user = "master_deployer"or user = "syslog" or user = "rabbitmq" or user ="tomcat" or user = "tomcat7" or user = "apache2" or user = "sensu" or user = "consul" or user = "nagios" or user = "nessusd" or user = "sumologic" or user = "jenkins" or user = "scout" or user = "www-data" or user = "logstash" or user = "aws"

  

Use Case APT.5: Suspicious commands, attacker trying to find his way

Attackers use several commands to find their way into the environment. Such tactics include :

  • Attackers run find to find locations of important files
  • Attackers run tcpdump to capture and understand topologies
  • Attackers delte log files
  • Attacker change permissions on files.

 

Threat Stack Rule Set:

One shot command to detect suspicious activity

(command = "tcpdump" or command = "chown" or command = "nc" or command = "cat" or command = "vim" or command = "vi" or command = "rm") and type="start" and tty starts_with "pts"

 

Use Case APT.6: Generic Exploit Patterns

Command Run Out of Tmp`

event_type="audit" and type = "start" and exe starts_with "/tmp/"

 

Network Traffic Out of Tmp

event_type="audit" and (type = "connect" or type="accept") and exe starts_with "/tmp/"

 

Web users running user commands

(user="www-data" or user="nginx") and (command = "sh" or command = "chown")

 

Use Case Category - Operations:

Questions to Cloud Customer

  • How do you get informed of hand edits of configuration files on production machines ?
  • How do you get informed of hand installed packages in production environments?
  • When bad things happen in production environment do you have the visibility to know which user has executed what commands on which servers and when?

 

Use Case OPS.1: Un-authorized Install of Packages

Our customers pre-built AMIs and packages and do not want any installations of new packages or upgrades of existing packages.

Threat Stack Rule

(command = "apt-get" or command = "yum") and type="start" and tty starts_with "pts"

 

Use Case OPS.2 New users added / deleted

Our customers pre configure users on servers and new user additions on servers is a serious security concern

Threat Stack Rule:

host_signatures = "New user added to the system"

 

Use Case OPS.4 Process stops

Many of our customers use our tool to get alerted on process stops by a user.

command = “rsyslogd” and type = “stop” and tty starts_with “pts”

Use Case OPS.5 Hand Edits of configuration files

Operations folks want to get alerted on when admin interfaces of services gets accessed in prod of configuration files
of those services gets edited manually (other than by configuration management tools). The following are examples of threat stack rules for such scenarios:

Service

Use Case

Threat Stack Rule

  • Mongo : Alert for connections on Admin port  - Audit alerts on connections to admin port 28017, 27017, 27019
  • Cassandra : Alert for changes to Cassandra Configuration File - File alert on /etc/security/limits.d/cassandra.conf
  • Cassandra: Alert for changes to Cassandra Admin ports - Audit alerts on connections on opscenter admin and monitor ports 8888, 61620, 61621
  • Elastic Search: Alert for changes to ES Admin ports - Audit alerts on connections on opscenter admin and monitor ports 9200, 9300 (white list based on observations)
  • ElasticSearch: Alert for changes to ES Configuration File- File alert on /etc/elasticsearch/elasticsearch.yml
  • Redis: Alert for changes to Redis Configuration File - File alert on /etc/redis.conf
  • Haproxy: Alert for changes to Haproxy Configuration File - File alerts on /etc/haproxy/haproxy.cfg

For many of these files, we usually put a suppression for chef-client, chef-solo, puppet, awx so the files can be modified by configuration scripts.

Use Case Category: Compliance

Compliance such as HIPAA, PCI, SOX ask you keep track of key files on the system, review user activity of certain users, use of insecure ports and protocols

Questions to Cloud Customers

  • Can you get alerted on modifications to track of key files and do that in such a way that it has minimal impact on compute resources on your servers
  • Can you provide an audit of alert review to the auditor ?
  • Can you track and review root and privilege escalation activity ?

 

Use Case COM.1: File Tracking

 

COM 1.1 Monitor  Changes to Configuration Files: Cloud operations teams can monitor changes to the configuration files of applications, databases etc.  

 

Threat Stack Rule: Alert on Modify for configuration files

 

 

COM 1.2: Alert on Modification and Open of secret files: Cloud operations teams can monitor changes and opens to the secret files of configuration tools and applications.

 

Threat Stack Rule :

 

COM 1.3: Alert on Modifications to System Directories: Cloud operations teams can monitor changes to system directories such as /sbin/, /bin, /lib

 

Threat Stack Rule:

 

 

 

COM 1.4: Monitor changes to System User Authentication Files: Cloud operations teams can monitor changes to system directories such as /sbin/, /bin, /lib

 

Threat Stack Rule:

 

 

The file alerts are suppressed when configuration tools such as chef makes additions

Use Case COM.2: Review of Root User Activity

Threat Stack Rule

The following rule will capture all root activity :

user = "root" and type = "start" and syscall="execve"

 

Use Case COM.3: Alert and get notified when insecure ports and protocols get used in the environment.

Threat Stack Rule

The following rule will capture use of insecure protocols such as FTP or Telnet or HTTP :

port = 21 or port = 80 or port = 22

 

 

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.