How SIEM systems can help safeguard your company’s cloud infrastructure from security threats

Enterprises facing security threats often require holistic and in-depth visibility into security and log events across all their resources. Security Incident and Event Monitoring (SIEM) platforms are designed to aggregate security events in real-time and provide actionable intelligence to operations teams. This comprehensive visibility enables organisations to analyse security events in real-time and respond effectively.

Customers undergoing an AWS cloud transformation journey often migrate existing workloads to the cloud and connect their AWS cloud to their on-premises (in-house) environment. As part of their operations and incident response strategies, these customers need to implement Security Incident and Event Monitoring (SIEM) holistically across both their cloud and on-premises environments. Holistic enterprise security involves establishing a robust Security Operations Center (SOC) structure and implementing layered security best practices. Implementing Security Incident and Event Management on the AWS cloud involves multiple steps.

With the ever-increasing threat landscape, it is a known fact that even the most securely protected and controlled environments are prone to information security incidents. and Every organaisation may have experienced this crisis at some point. The information systems and processing facilities must be monitered constantly to achieve resilience against security incidents. Appropriate controls should be established to ensure quick, effective, consistent, and orderly management of information security incidents, including communication about security events and weaknesses.

Indicators of compromise (IoC) indicate potential threat to the system that can be used to identify, root cause and remediate the potential attacks. Some of the common IoC are listed below –

• Sudden spike in network traffic
• Repeated login failures
• Increased traffic from specific geo location
• Sudden increase in file downloads
• Increased size of the HTML response
• Increased database read activity
• Anomalies in the user activities

Setting up a Security Operation and Controls (SOC) team is essential for an effective incident management and detection and response to the ever growing threat landscape.
SOC cannot be treated as business enhancer but as a business enabler and the use case revolving around implementation of SOC inside an organisation can be summarised as below: -

• Protecting Crown jewels: - SOC offers an eagle -eye view of the organaisation’s crown jewels to the business leaders and top management, enabling them to adopt a centralised approach for threat detection and incident response.
• Preventing Data exfiltration: - SOC enables an organisation to detect suspicious activities through its capability to correlate and analyse events from different devices.
• Real time alerts and notifications: - SOC enables an organisation to detect and respond to alerts on a real time basis.
• Threat Hunting: - SOC tools allows an organisation to receive threat feeds from third party sources to enable protection against latest threat actors and vulnerabilities.
• Proactive monitoring instead of Reactive monitoring: - Setting up a real time SOC allows an organisation to react on proactively.

Benefits of implementing SOC: -

• Centralised log Management: - Implementing a SIEM solution allows you to aggregate and normalise logs from various systems, including servers, firewalls, IPS, IDS and applications. SIEM provides centralised view of events. It generates real-time alerts for potential security incidents as a result of use cases triggered due to correlation between the events.
• Threat detection and response: - SIEM uses predefined security rules, behavior profiling and statistical analysis to identify potential attacks such as unauthorised access attempts, malware infections, data breaches, or suspicious user behavior.
• Incident response and remediation: -When SIEM detects a security incident, it triggers alerts to the analysts to quickly investigate, assess the severity and initiate appropriate response measures to mitigate the treat after assessing the severity. It aids in incident response and remediation by providing relevant contextual information and helps identify the affected systems.
• Threat Intelligence integration: - Capability to integrate with external threat intelligence sources, such as security vendors, industry forums and threat feeds. It enriches the SIEM’s capability to correlate and leveraging IOC (Indicators of Compromise) through the threat feeds via third party integrations.

However, security is an ongoing process and it requires continuous monitoring, assessment and improvement. It requires regular review and update your security measures as the threat landscape is also evolving with the advancements in technological landscapes.

SIEM platform aggregates the security events from various sources (such as server logs, application logs, audit logs) and correlates all the events to create real-time actionable alert for incident analysis and remediation.

Given below are the common use cases of SIEM -

• Correlation analysis of the Network - Use source IP address from a GuardDuty finding as a key and retrieve relevant events from GuardDuty, CloudTrail, VPC Flow Logs, server web/SSH access logs, sort network logs by timestamp and analyse
• Malicious activity detection: Use EC2 Instance ID from a GuardDuty finding as a key and retrieve relevant events from GuardDuty, CloudTrail, Inspector, Config/Config Rules to compare infrastructure changes and malicious activity on the timeline
• Log visualisation with dashboards Visualisation of CloudTrail logs: aggregation of API calls, real-time statistics, real-time correlation, visualisation on timeline and on world map by source IP address
• Parsing and enrichment of security log data (such as data classification, compliance mapping, vulnerability mapping and such) to identify the security events.
• Workflow engine for managing the security events.

Given below are some of the insights gathered from log analytics -

• Is infrastructure operating normally?
• What are latency and error rates?
• What caused application issues?

• Were there attempts of unauthorised login?
• What data was accessed from a specific IP address?
• Which domains and user agents are involved?
• Which access key is compromised?
• Which authorisation method was used?
• Are there any privilege escalations?
• Are there any breaches?

AWS recommends setting up landing zone during the start of the cloud migration journey. The landing zone construct provides a secured, best practices based multi-account structure. We create a centralized “log archive” account with an AWS S3 bucket. The logs of various resources such as Amazon GuardDuty logs, Load Balancer logs, VPC flow logs, application logs etc. from all accounts are sent to the centralized log bucket segregated into various folders.

AWS Control Tower, so when the landing zone (platform) is set up 2 core accounts are created:

• Log Archive account: This account is dedicated to collecting all logs centrally, including logs for all other accounts provisioned under AWS Control Tower. These log files allow administrators and auditors to review actions and events that have occurred in the AWS Accounts
• Audit Account: This account is designed to give the security and compliance teams read and write access to all accounts in the landing zone. From the audit account, programmatic access to review accounts, by means of a role that is granted to Lambda functions is possible. The audit account does not allow a user to log in to other accounts manually.

These accounts are central to the logging and monitoring of the landing zone implemented by AWS Control Tower.

AWS Control Tower sets up the majority of the baseline needed for such monitoring by creating a centralized logging account and auto-configuring every created account to send CloudTrail and CloudWatch logs to that centralized account. Logging of actions and events in AWS Control Tower is accomplished automatically through its integration with CloudWatch. All actions are logged, including actions from the AWS Control Tower management account and from the member accounts. Management account actions and events are viewable on the Activities page in the console. Member account actions and events are viewable in log archive files while within the member account they can be viewed using CloudWatch Logs.

Given below are the key features of AWS Control Tower:

• Creates AWS Config aggregation authorizations in the Audit account
• Enables CloudTrail in all available AWS Regions
• Enables AWS Config in all available AWS Regions
• Ensures that AWS Config records resource configurations in a consistent manner
• Sets a retention policy of 365 days on the logs in the Log Archive account
• Real-time analysis of activity data by sending CloudTrail events to CloudWatch Logs in each member account
• Enables S3 Server access logging for the central logging bucket to monitor all requests to the logs S3 bucket.

In addition to the default baseline logging provided by AWS Control Tower, the following logs will continue to be collected on top of what AWS Control Tower already provides:

• VPC Flow Logs to be enabled at the “VPC” level with additional metadata, and logged to a centralized S3 bucket in the Log Archive account. VPC Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC
• GuardDuty findings from the GuardDuty Administrator (Information Security account) and logged to a centralized S3 bucket in the Log Archive account.
• S3 Server Access Logs for these 2 buckets to be enabled in the Log Archive account in AWS Singapore Region S3 bucket

Figure 1 captures the logs centralization design for the organization’s landing zone (platform):

We can setup preventive guardrails and detective guardrails in landing zone. Preventive guardrails restrict the sensitive operations at the AWS account level and detective guardrails continuously monitor the security configuration in real-time.

To enable a robust security posture, we need to enable preventive guardrails to block the sensitive actions. Some of the sample preventive guardrails are as follows -

• Prevent deletion of Amazon S3 buckets created by AWS Control Tower in the Log Archive account
• Disallow changes to the AWS Config aggregation settings
• Disallow Deletion of Log Archive.
• Disallow Configuration Changes to AWS Config
• Disallow any policy changes from occurring in the Log Archive account.

The list of strongly recommended guardrails is detailed at AWS Control Tower[7].

1. SIEM on AWS

In this section we have elaborated various methods for building the SIEM natively on AWS and for integrating the AWS with on-prem SIEM platform. We primarily detail three principal categories – building cloud native SIEM on AWS, integrating with AWS SIEM and subscribing to the marketplace SIEM products. In each of these categories, we shall look at methods and patterns for SIEM solutions. We shall also look at the best practices and anti-patterns while building and integrating SIEM products.

We have detailed the main ways to build, deploy and integrate SIEM on AWS in this section.

The key challenges faced while analysing enterprise security data are as follows -

• Various services and resources send the metrics and logs in different formats.
• The data volume from various sources is very high.
• The log format from AWS services such as AWS CloudTrail, Amazon S3, AWS Lambda are in different format that needs to be normalized for efficient analysis.

Amazon Security lake is an OCSF compliant highly scalable security log repository consolidate wide variety of logs from resources such as AWS CloudTrail VPC flow logs, Amazon EC2 logs, Amazon Route 53 logs and such. Amazon Security Lake provides a centralized, scalable and secure data management while eliminating the duplicates. Amazon Security Lake saves the storage cost and helps in faster query execution.
Open Cybersecurity Schema Framework (OCSF) is an open standard that simplifies the security data normalization. OCSF provides open standards-based security data taxonomy that can be consumed by various security platforms.

We have depicted the Amazon Security Lake in Figure 2. Native AWS services such as Amazon Lambda, Amazon S3, AWS CloudTrail, AWS security Hub can send the logs. Third party security, analytics solutions can also send the data to the Amazon Security Lake. All the data will be converted and stored in OCSF standard format. As the data from diverse resources will be stored in standard format, the AWS native services (such as AWS Athena, AWS OpenSearch, Amazon SageMaker) or third-party platforms (such as third party SIEM platforms, analytics platforms, security platforms) can consume the data in the OCSF format.

Amazon security lake centralizes the security data by consuming the security events from various sources and optimizes the security data storage. Customers can consolidate the security data from cloud, on-prem and other security platforms into Amazon Security Lake. The security data is normalized and stored in OCSF open data format. Customers can use Amazon Athena to query the data from Amazon Security Lake or they can analyse the security data using the preferred analytics tool. Given below are the key advantages of Amazon security lake -

• Centralize massive volumes of security data.
• Normalize the data in OCSF open standard format so that we can analyse the data quickly and integrate with multiple analytics tools.
• Seamlessly integrate with AWS and third-party analytics platforms.

We can build a native SIEM solution on AWS using the AWS services. We have depicted the native SIEM solution in Figure 3.

The detailed flow of the native SIEM solution on AWS is as follows –

1. Account 1 sends the logs from various AWS services such as CloudTrail, GuardDuty, EC2 to centralized S3 bucket in log archived account.
2. Other accounts such as Account 2 sends the log to centralized S3 bucket in log archived account.
3. The Lambda processes the log files by normalizing the schema across various logs (converting logs with different schemas so that fields with same meaning have same key name to improve search efficiency by allowing to reference to all log types with same schema).
4. SIEM on OpenSearch Service conforms to Elastic Common Schema. Elastic Common Schema is extended with fields that are often used in AWS, such as EC2 Instance ID, IAM Access Key ID and others.
5. The Amazon OpenSearch
6. The key events that match the specific pattern are sent to Amazon SNS
7. The SNS sends the email to the subscribers such as security analysts
8. The OpenSearch findings can be fed into Amazon Security Lake for further analysis and query.

We have specified various metrics that can be logged and monitored in Appendix 1 and Appendix 2 for reference.
We can also query the log bucket using Amazon Athena. We can query the unauthorized attempts, rejected TCP connections, IP based filtering as detailed in the blog.

References

1. IBM Qradar reference - https://community.ibm.com/community/user/security/blogs/patrick-routh/2019/10/01/ibm-qradar-and-aws-best-practices-vpc-iam-security
2. SIEM on Amazon OpenSearch Service Workshop - https://security-log-analysis-platform.workshop.aws/en/01-introduction.html
3. SIEM on OpenSearch Service - https://github.com/aws-samples/siem-on-amazon-opensearch-service/
4. Management and Governance Lens - https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-lens/management-and-governance-lens.html
5. Observability - https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-lens/observability.html
6. Operational Intelligence - https://aws.amazon.com/marketplace/solutions/control-tower/operational-intelligence
7. AWS Control Tower User Guide - https://docs.aws.amazon.com/controltower/latest/userguide/controltower-ug.pdf
8. Best practices for monitoring https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring_best_practices.html
9. IBM QRadar SIEM & XDR Connect add support for Amazon Security Lake & AWS Verified Access https://community.ibm.com/community/user/security/blogs/gaurav-sharma/2022/11/10/ibm-qradar-and-aws-announcement
10. Mandatory Controls https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html

Footnote
We acknowledge and sincerely thank Mr. Ratan Jyoti, CISO, Ujjivan SFB for his inputs to "Drivers for Security Operation and controls (SOC) and SIEM" and "Core Events for SIEM platform" sections of the blog.