SIAC

SIAC is a SIEM In A Can. It's pronounced like "sigh-ack." SIAC can run in the cloud, on bare metal, or a hybrid environment.

Background

As the name implies, SIAC is a SIEM. The purpose of this project is not to provide an off-the-shelf security monitoring and alerting solution, but rather to demonstrate how organizations and individuals can use free and open-source tools to build out modern information security capabilities. SIAC is capable of scaling to N nodes and handling tens of thousands of events per second (EPS). This work is based on CityBase's security engineering R&D.

The SIAC project documentation has been released for a few reasons:

• More and more organizations are eager to build out their own toolchain, but aren't sure where to start. We hope that this documentation can change that.

• Security budget is a scarce commodity and defenders are often being asked to implement enterprise solutions without an enterprise budget.

• Sharing security knowledge is good, and makes our industry better.

Disclaimers

These are very important and contain information required to operate SIAC securely in production.

• This project presents a dramatically scaled down version of a SIEM and it has not been subjected to any kind of performance testing.

• This example stack does not implement any encryption for data in transit. Certificate and key management policies can vary greatly between organizations and their environments. When implementing any or all of this stack, it is your responsibility to implement encryption in a way that is congruent with the security policies of your organization. All components have support for network-level encryption. Specific to elasticsearch, please investigate options such as X-pack, Search Guard, and Nginx as a reverse proxy.

• This example stack does not implement any authentication. The policies and procedures for managing secrets can vary greatly between organizations and their environments. When implementing any or all of this stack, it is your responsibility to implement authentication in a way that is congruent with the security policies of your organization. All components have support for client/server authentication and there are also plugins that can help, but to keep it simple, we don't implement any of these in the documentation.

• For the sake of simplicity, all server-side components live on one machine. All documented components support a distributed and clustered architecture. When implementing any or all of this stack, it is important to determine how these components are broken out, secured, and scaled for your organization.

• All configuration files represent the bare minimum requirements for getting services up and running, and client components shipping event data. Please consult the full reference configuration files and documentation, where applicable.

Design

Before digging into the rest of the documentation and standing up a SIAC, it might be helpful to understand what this project does and what drove certain design choices.

• We wanted it to have as little custom code as possible and to work with automation tools such as Salt and Terraform. This speeds up deployment, disaster recovery, and provisioning which are usually bottlenecks in traditional SIEM architecture.

• It had to support modern Linux operating systems, and run in the cloud. Traditional SIEMs don't do modern or cloud very well.

• It needed to help us maintain PCI compliance, and provide a good actionable view of data for our auditors which mapped directly to certain controls outlined in the PCI-DSS. This should help any organization cruise through their ROC and evidence collection.

• Horizontal scalability. Searching and indexing need to be fast. Adding speed and capacity should be as simple as N+1.

• Modular architecture. There's always new tools in the security space and we wanted to be able to add and remove components without too much complexity.

• Security and event data correlation should be transparent. Black boxes are old and busted. This should be hot and new.

Capability Overview

According to Wikipedia, there are 7 key capabilities a SIEM should implement:

• Data aggregation
• Correlation
• Alerting
• Dashboards
• Compliance
• Retention
• Forensic analysis

SIAC does all of these.

PCI Compliance

A lot of the dashboarding functionality we'll be looking at is backed by the Wazuh Kibana app.

As mentioned earlier, one of the core requirements for our stack was functionality that would support us in maintaining our PCI compliance, and communicating this information to our auditors. The fact that Wazuh maps rules/alerts to specific sections of the PCI-DSS, and provides a PCI-specific dashboard has helped immensely. Please refer to the annotated images for additional context. Please see the Wazuh documentation relating to PCI compliance for additional details.

PCI Dashboard

PCI Dashboard Continued

Wazuh is a fork of the very popular OSSEC software package which provides a lot of additional functionality such as agent management/registration, centralized configuration management, file integrity monitoring, and host-based intrusion detection capabilities. Similar to the PCI dashboards above, the Wazuh Kibana app also provides ready-to-use visualizations for FIM, HIDS, CIS benchmarks, and much more.

Another helpful application component is the Wazuh management functionality which is part of the Kibana app. This component allows for agent grouping, monitoring, error reporting, configuration review, and more.

Wazuh Manager UI

Additional screenshots of Wazuh app can be found in the official documentaiton.

Visualizations

One of the most powerful features of building off of ELK is the visualization capabilities. We've included the kbn_network plugin with this stack since we found it so useful for visualizating relationships between indexed field data. In this example, we use data from the packetbeat index to visualize the source/destination relationships of 25 distinct source/destination nodes.

kbn_network Plugin Visualization

While that's interesting to look at, it's a little too broad to be practical. If we add an additional search constraint based on source IP, we can view the unique hosts that the source IP has talked to over an arbitrary time period.

kbn_network Plugin Visualization

This type of relationship mapping can be applied to any indexed data such as DNS lookups, host executable activity, and probably a lot of other interesting things we haven't gotten around to just yet.

Raw Search

Elasticsearch and the Lucene query syntax are extremely powerful for searching very large volumes of indexed data. A detailed tutorial on using ELK to search data is beyond the scope of this documentation, but once SIAC is up and running, you can experiment with searching data in the filebeat, packetbeat, and wazuh-alerts, indexes.

Flexibility

Beyond the inherent flexibility that exists when working with open-source software, all of the visual components can be customized to your needs. This means that if there's a saved search, visualization, or dashboard that you want to modify and save, it's very easy to do.

Yes, it's a real SIEM

At this point it should be clear that while SIAC may be small in this documented build, the sum of its components are more than capable of supporting an enterprise security program both in terms of scale and functionality. Following the documentation, it should take no more than 30 minutes to have a SIAC instance up and running.

Building it out

Server: Installation and Configuration

The backend stack uses Elasticsearch as the primary data store, which holds event data generated by client systems. This data is fed to the backend from the clients using Beats. We make sense of this data using Kibana, Wazuh, and various custom dashboards.

The following installation and configuration steps should be considered "quick start" in order to get the system operational, have a rough understanding of how the components work together, and start searching some simple dashboards and event data.

Requirements: 64-bit Ubuntu Desktop 16.04 LTS, 4GB RAM, 1 CPU core. Why desktop? It made copying and pasting easier in VMware.

The following commands will set up the repositories for Wazuh, Java, Node, and Elastic, install the appropriate packages, generate a SSL certificate for the Wazuh auth daemon, and start the authorization service.

apt-get update
apt-get install curl apt-transport-https lsb-release 
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
echo "deb https://packages.wazuh.com/3.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list
apt-get update
apt-get install auditd
apt-get install wazuh-manager=3.2.0-1
openssl req -x509 -batch -nodes -days 365 -newkey rsa:2048 -keyout /var/ossec/etc/sslmanager.key -out /var/ossec/etc/sslmanager.cert
/var