Security monitoring and alerting is a critical control that involves identifying and monitoring security events within applications and infrastructure, and generating alerts to the right people when issues arise. By establishing thresholds for risk indicators, categorizing risks based on business impact, and reporting on application security status, organizations can maintain visibility and respond quickly to potential security incidents.

Where did this come from?

This security control comes from the CSA Cloud Controls Matrix v4.0.10 published on 2023-09-26. You can download the full CCM document here.

The CCM provides a controls framework for cloud computing aligned with industry-accepted security standards, regulations, and control frameworks like ISO 27001/27002, ISACA COBIT, PCI DSS, and NIST.

For more background on security monitoring in AWS environments specifically, check out:

• Monitoring and Logging in AWS
• CloudWatch Documentation

Who should care?

Several roles should be concerned with making sure adequate security monitoring is in place:

• Security analysts responsible for detecting and responding to security incidents
• DevOps engineers who need to configure monitoring and alerting for the apps and infrastructure they manage
• Compliance officers that must ensure the organization adheres to relevant security standards
• Business leaders/executives who are accountable for security risks to the business

What is the risk?

Without effective security monitoring and alerting, organizations may:

• Fail to detect malicious activity and data breaches in a timely manner, increasing incident impact
• Be unable to investigate and reconstruct a complete timeline after security incidents occur
• Lack visibility into overall security posture and compliance with standards/regulations
• Get overwhelmed by false positive alerts while true positives go unnoticed

While monitoring itself doesn't prevent incidents, it is essential for fast detection and response which can significantly limit damage. LOG-03 provides guidelines to implement monitoring in a risk-prioritized way.

What's the care factor?

For most organizations, security monitoring should be a high priority, as evidenced by inclusion in virtually all security standards. The risks of poor monitoring are high impact - major data breaches often go undetected for months and incur huge costs.

However, the right level of monitoring is context-dependent. A small business with a simple web app likely needs a basic level of monitoring, while a financial firm or hospital with sensitive data requires 24/7 advanced monitoring.

When is it relevant?

Security monitoring is relevant for nearly all organizations, with a few exceptions:

Monitoring makes sense when:

• You have production workloads and data that is sensitive or business critical
• You are subject to security standards like PCI DSS, HIPAA etc. that require it
• Your environment is complex with many components that could be attacked

Monitoring may be lower priority if:

• Everything you have is low-risk public information
• You are in very early development stages with no production systems

What are the trade offs?

Implementing security monitoring does come with costs to consider:

• Monitoring systems like a SIEM are expensive to license and run
• Configuring monitoring across many disparate systems takes significant upfront effort
• Too many alerts can overwhelm teams, requiring time to tune thresholds
• Storing large volumes of logging data long-term for forensics incurs storage costs
• Some monitoring relies on agents which consume host/application resources

The key is to weigh these costs against the benefits and risk reduction monitoring provides. Start with critical assets and expand coverage over time as you learn what works.

How to make it happen?

To implement LOG-03 in an AWS environment:

1. Identify the most critical resources to monitor first (e.g. production EC2 instances, S3 buckets with sensitive data, security groups, IAM)
2. Turn on AWS CloudTrail to log all AWS API activity in the account
3. Configure logging on individual resources (e.g. S3 access logging, VPC flow logs, EC2 OS-level logging)
4. Ingest the logs into a central analysis system (CloudWatch, third-party SIEM)
5. Define metrics that indicate risk for the resources monitored (e.g. S3 bucket configuration changes, spikes in denied traffic, unusual login locations for IAM users)
6. Create alarms in CloudWatch that trigger when metrics exceed thresholds, sending notifications to an SNS topic
7. Subscribe the appropriate teams to the SNS alert topics to receive notifications
8. Configure a CloudWatch dashboard showing overall status of key security metrics
9. Regularly review the logs, metrics and alerts to identify opportunities for tuning
10. Expand the monitoring coverage to more resources over time as your environment grows

What are some gotchas?

A few things to watch out for when implementing security monitoring in AWS:

• Monitoring systems need permissions to access logs and metrics - e.g. a CloudWatch metric alarm needs cloudwatch:PutMetricAlarm and cloudwatch:DescribeAlarms permissions (reference)
• If you use a third-party SIEM or monitoring tool, you'll need to configure AWS to allow it to ingest the logs it needs, e.g. via cross-account IAM roles.
• Some AWS logging features are not on by default and incur extra costs when enabled (e.g. CloudTrail data events, S3 access logging)
• Log storage costs in CloudWatch Logs can get expensive over time - consider archiving older logs to cheaper storage like S3
• Too many alarms can lead to alert fatigue - aim for high signal alerts and continually prune those that aren't actionable

What are the alternatives?

While LOG-03 focuses on monitoring within applications and infrastructure, there are complementary security monitoring approaches:

• Endpoint detection and response (EDR) tools monitor employee laptops/desktops
• Network intrusion detection systems (NIDS) monitor for attacks at the network perimeter
• External vulnerability scanning checks for exploitable misconfigurations from the outside

Used together, these provide defense-in-depth. But application/infra monitoring is still essential since it is closest to sensitive systems and data.

Explore further

For more details on security monitoring in the cloud, check out:

• NIST SP 800-137 - Information Security Continuous Monitoring for Federal Information Systems and Organizations
• CIS AWS Foundations Benchmark - Logging and Monitoring
• AWS Security Blog - Monitoring AWS Account Configuration with AWS Config

‍