File Integrity Monitoring with OSSEC in AWS EC2

PCI-DSS is a set of security standards for businesses to protect cardholder data in card data storing, processes and transmission. According to PCI DSS 10.5.5, 10.8 and 11.5, the payment transaction service provider is required to implement a File integrity monitoring (FIM) system in the server’s operating system to detect and report the file corruption or other unintended changes (e.g., Log tampering) to alert the unauthorized modification of critical files (e.g., logs, system audit files, configuration files). The FIM is added to the PCI DSS compliance framework as an additional security layer and plays a critical role in system monitoring and anomalous alerts. However, I searched the AWS service document and didn’t find a cloud-native solution for file integrity monitoring in the EC2. The main goal of this article is to help the people who seek an FIM solution on AWS to meet the?compliance requirement of PCI-DSS. Today, I will introduce how to design and implement an FIM solution on AWS to meet those requirements.

What is a File integrity monitoring (FIM) system? How does it work?

File integrity monitoring (FIM) is an application that verifies the integrity of operating system and application software files using a verification method between the current file state and a known, good baseline via checksum. If FIM detects that files have been altered, updated, or compromised, FIM can generate alerts to ensure further investigation and if necessary, remediation takes place. FIM works in two patterns, agented and agentless. Some FIM solution performs as one part of the Host-based IDS (HIDS) which can detect threats in areas other than files, such as system memory (RAM) or I/O.

Why do we need a third-party FIM solution in EC2?

AWS provide the log file integrity validation for CloudTrail and S3 via the industry standard algorithms: SHA-256 for hashing and checksum, but AWS doesn’t provide the cloud-native solution for FIM in EC2. Based on the AWS Well-architected framework which is used to review and measure the architecture against best practices on AWS, we need to follow the best design principles in this framework to enable traceability to monitor, alert, and audit actions and changes to our environment in real-time. We also need to apply security at all layers, including the operating system. To align with the best practices in cybersecurity design, we should use additional third-party FIM solutions to design a secure cybersecurity architecture in the cloud.

What kind of solutions we can use for File integrity monitoring (FIM) in EC2?

1) Use the syscheck feature in the OSSEC.?

2) Use the file_event feature in the osquery.

3) Use the Linux Audit system to track the changes to files, that’s also the recommended solution by AWS.

What kind of system files do I need to monitor?

Before implementing the OSSEC solution, we must select the appropriate monitoring scope. The extensive scope will cause many alerts which will degrade the FIM performance. We should choose only the critical files for our system and applications and only monitor the unintended file changes when we plan the scope. The main types of logs we care about are sensitive system files, config files, log files and critical application files. You can refer to the list of recommended items to monitor in Linux and Windows.

FIM cloud architecture with OSSEC

The FIM architecture is in the client-server pattern which consists of the following assets, one OSSEC server (manager) and multiple OSSEC clients. We have several application accounts and one centralized log account that hosts the SIEM system under the AWS organization. The complete architecture diagram is the following.

1. In the Application Account

The application AWS account is the account which hosts the SAAS application.

OSSEC Server

The OSSEC server is the central component of the OSSEC architecture, which stores file integrity checking database, logs, events and system auditing entries. All the rules, decoders, and major configuration options are stored centrally in the manager, making it easy to administer even a large number of agents. The OSSEC server also creates alerts via email when it detects the gap between the checksums of the clients' log files and the baseline checksums stored in the file integrity checking database.

The communication port/protocol from agents on the server is 1514/UDP. We need to allow this port/protocol in the outbound rule of the security group of the client EC2 instance and the inbound rule of the security group of the server EC2 instance.

OSSEC Agent Client

The Agent clients are installed on the EC2 instance you’d like to monitor. The agent collects logs and file checksums from the instances and delivers them to the centralized OSSEC server for analysis and alarms. Some information is collected in real-time, others periodically. The agents are available for both the Linux and Windows operating systems. The CPU&&Memory usage of the agent is very little overhead and won’t influence the instance performance.

2. In the Centralized Log Account

In the OSSEC server of the application account, we install the CloudWatch agent in it to collect the logs from the OSSEC clients. Then those logs are sent through the CloudWatch agent to the centralized log account. You can refer to the link to configure the role_arn parameter in the CloudWatch agent configuration file, the IAM policy of the sending account and the target account to send logs across different accounts. The logs and alarms are sent to the log account’s CloudWatch log group you specify in the CloudWatch agent configuration file. This cross-account delivery is to store the logs for incident monitoring in the SIEM of a centralized account.

Security information and event management (SIEM) is a security and compliance management solution that helps organizations recognize security incidents through the collection and analysis of security events, as well as a wide variety of other events and data sources. We choose LogPoint as our SIEM solution which is hosted in an EC2 in the individual centralized log account. The SIEM server fetches the log files from the CloudWatch log groups and S3 via fetchers. You also can use the LogPoint pre-defined alert rules or custom alert rules to notify your Cyber Security Incident Response Team (CSIRT) of security incidents. The alert functionality of the FIM and SIEM overlaps, so we can choose either one of them as our alert system but not both of them. In this way, we can query the logs and report the threat alerts in a single platform to reduce operational overhead.

OSSEC solution Implementation steps

Cloud Provider: AWS

OS: Amazon Linux 2

1. Manager installation

?# Add the Atomic Repo

?wget -q -O - https://updates.atomicorp.com/installers/atomic

?# Install the OSSEC Server

yum install -y ossec-hids-server?

?# Add the Agent && Generate the Agent Key:

?/var/ossec/bin/manage_agents????

# Add the Following Context to the Conf File to Set up the Client IP Scope

<remote>

?<connection>syslog</connection>

?<allowed-ips>Prefix/Mask</allowed-ips>

</remote>

<remote>

?<connection>secure</connection>

</remote>

2. If the OS requires the CIS Benchmark baseline

?# Modify iptables

?iptables -A INPUT -p udp --dport 1514 -m state --state NEW,ESTABLISHED -j

3. Client Installation

# Install the OSSECT Client Agent

yum install -y ossec-hids-agent????

# Add the Second Line into the ar.conf to Configure Active Response

vim /var/ossec/etc/shared/ar.conf

restart-ossec0 - restart-ossec.sh - 0????????

# Replace the default IP with the Manager IP

vim /var/ossec/etc/ossec.conf

<client>

<server-ip>SERVER IP</server-ip>

</client>????

# Import the Key to the Agent Exported from the Server

/var/ossec/bin/manage_agent

AWS doesn't provide cloud-native service for FIM and SIEM, and we need to seek third-party solutions to secure our system from attacks to meet the compliance requirement of PCI-DSS. This post introduces how to use the OSSEC to meet PCI requirements. I hope my post can help you design and implement the FIM solution on AWS following the well-architected framework. I will keep posting more articles about the cybersecurity architecture design with best practices, such as SIEM log collections, outbound URL/IP restrictions with proxy, SSL offload with AWS CloudHSM, and so on and so forth. Thank you for your support!