Every organization has critical assets that are essential to their business. Unauthorized changes to these assets, whether accidental or malicious, can have devastating consequences. The Unauthorized Change Protection control aims to restrict and prevent any unauthorized additions, removals, updates or other changes to an organization's critical assets.
Where did this come from?
This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full Cloud Controls Matrix here.
The CSA Cloud Controls Matrix provides a comprehensive set of security controls that are specifically designed for cloud computing environments. It was inspired by the need for a standardized approach to securing cloud infrastructure and applications.
For more background, check out this overview of the CSA Cloud Controls Matrix.
Who should care?
This control is relevant to:
- Security engineers responsible for protecting critical assets
- IT operations teams who manage infrastructure changes
- Compliance officers who need to ensure adherence to security policies
- Business owners whose assets are at risk of unauthorized changes
What is the risk?
Unauthorized changes to critical assets can lead to:
- System outages and downtime
- Data loss, corruption or exfiltration
- Introduction of security vulnerabilities
- Non-compliance with regulatory requirements
The impact of these adverse events can range from minor inconveniences to major disasters depending on the asset and extent of the unauthorized change. Having proper controls in place can significantly reduce the likelihood and severity of unauthorized change incidents.
What's the care factor?
For any organization that values the integrity, availability and confidentiality of their assets, unauthorized change protection should be a top priority. The consequences of not having adequate controls can be severe - from reputational damage to financial losses to legal liabilities.
The level of care and investment should be proportional to the criticality of the assets. Mission-critical systems warrant stringent change management processes, while lower priority assets may only need baseline protections.
When is it relevant?
Unauthorized change protection is relevant in situations where:
- Assets are exposed to a large number of users/roles
- Assets store or process sensitive data
- Assets are subject to strict regulatory requirements
- Assets are critical to business operations
It may be less relevant for:
- Isolated dev/test environments
- Disposable, frequently-recycled assets
- Low-risk, non-sensitive workloads
What are the trade-offs?
Implementing unauthorized change protection comes with some costs and considerations:
- Additional time and effort to define change management processes
- Reduced agility and longer lead times for legitimate changes
- Productivity impact of access control restrictions
- Increased complexity of permission management
- Potential user frustration with security controls
Organizations need to find the right balance between security and efficiency based on their risk tolerance and operational needs.
How to make it happen?
Here are some key steps to implement unauthorized change protection:
- Inventory your critical assets
- Identify and classify assets based on risk level
- Document baseline configurations
- Define change management policies
- Specify requirements for change requests, approvals, testing, etc.
- Assign roles and responsibilities
- Implement logical access controls
- Set up IAM policies to restrict access to change-related actions
- Use least privilege principle and segregation of duties
- Example IAM policy to deny untrusted entities from making changes:
- {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"ec2:RunInstances",
"ec2:StopInstances",
"ec2:StartInstances"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::123456789012:user/admin",
"arn:aws:iam::123456789012:role/change-manager"
]
}
}
}
]
} - Leverage detective controls
- Enable detailed logging of all changes (CloudTrail, AWS Config, etc.)
- Set up automated alerts for unauthorized changes
- Perform regular audits and reviews of changes
- Harden environments
- Limit network exposure of assets
- Patch known vulnerabilities
- Use hardened baseline configurations
- Test and improve
- Conduct penetration tests to identify gaps
- Incorporate learnings into policies and procedures
- Continuously monitor and optimize controls
What are some gotchas?
- Ensure IAM policies grant necessary permissions to change manager roles
- ec2:TerminateInstances, ec2:RunInstances, etc.
- iam:CreatePolicy, iam:AttachRolePolicy, etc.
- Be mindful of potential privilege escalation paths
- Consider emergency "break glass" procedures for urgent situations
- Don't forget to protect the protectors (e.g. secure the audit logs)
See the AWS IAM Documentation for more details on permission policies.
What are the alternatives?
Some alternative approaches to preventing unauthorized changes include:
- Compensating detective controls (e.g. CloudTrail alerts)
- Strictly defined and gated change windows
- Approval workflows built into deployment pipelines
- Immutable infrastructure paradigms
However, these alternatives may not provide the same level of preventative control as rigorous access management policies.
Explore further
- CIS AWS Foundations Benchmark - Recommendations for configuring AWS accounts
- AWS Change Management Guide - Best practices for cloud change management
The most closely related CIS Controls to this CCM Control are:
- CIS Control 5: Secure Configuration for Hardware and Software
- CIS Control 16: Account Monitoring and Control
These CIS Controls provide additional guidance on hardening systems and controlling access to prevent unauthorized changes.
?
