In the complex, fast-moving world of hybrid and multi-cloud environments, establishing a robust security posture goes beyond simply checking compliance boxes. It requires building solid foundations, defining clear boundaries, and fostering a culture of continuous security improvement. This framework, rooted in a cloud-first, cloud-native approach, is essential for large-scale organizations.
We spoke with Kushagra Sarma, Senior Platform Security Engineer at Booking.com, who shared his journey from DevOps to core Cloud Security and detailed his strategies for architecting security at scale.
This article explores the core concepts of security baselines and boundaries, detailing how they are combined to build a strong security foundation in a large cloud environment like AWS.
You can read the complete transcript of the epiosde here >
What Are Security Boundaries and Security Baselines in the Cloud?
Practitioners often use the terms “boundary” and “baseline” interchangeably, but they represent distinct, though related, concepts in cloud security.
Security Boundary (The Maximum Limit)
A security boundary defines the maximum permissible permissions. It acts as a perimeter or parameter, establishing a logical separation to define the maximum limit of permissions a user can attain.
- Examples: This can be a network boundary (network-level permissions) or an IAM boundary (on the permission side of things). AWS IAM Permission Boundaries are a specific example of this concept.
Security Baseline (The Bare Minimum Standard)
A security baseline is a benchmark or standard that represents the bare minimum controls that must exist, no matter what.
- Goal: To safeguard resources, for example, by ensuring no public exposure.
- Relationship: The security boundary is a subset of the overall baseline. The baseline is the top-level concept.
How Do Baselines and Boundaries Create a Strong Security Foundation?
A strong security foundation is created by utilizing the baseline as a layered approach, where boundaries and other preventative controls are combined with monitoring and early feedback mechanisms.
The Three Layers of a Baseline
Kushagra structures the baseline into different subsections, which together form the security foundation:
- Preventative Control Baseline: This includes controls that prevent certain actions, such as enforcing IAM permission boundaries or ensuring the public access block is not turned off in AWS. These are often the non-negotiable controls.
- Monitoring Baseline: This involves mechanisms to monitor the effectiveness of the preventative controls and track what is being prevented.
- Shift Left Controls: These controls flag potential security issues early in the development cycle (e.g., checks in the CI/CD pipeline).
Beyond the Checkbox
A common misconception is that simply checking a set of compliance boxes means the baseline is ready. To avoid this, organizations must focus on:
- Enforcement: How the controls are applied.
- Monitoring: How the effectiveness of controls is tracked to enable improvement.
- Feedback: How developers receive feedback early in the cycle.
How is Threat Intelligence Used for Continuous Baseline Improvement?
Defining the baseline is a never-ending process that requires constant iteration and refinement. Threat intelligence is critical for keeping the baseline current and proactive.
The Refinement Cycle
The continuous loop of baseline refinement involves multiple internal and external feeds:
- Review the IAM Namespace: Since most foundational controls fall on the IAM side, security teams must constantly review the IAM namespace for new services or new features added to existing services. Reviewing the whole list of actions and permission sets shows what a new service is capable of.
- Internal Threat Feeds: Preventative baselines are often a reaction to intelligence from threat detection and response teams that flag an action (e.g., IAM Passwords abuse) as being currently abused.
- External Audits: Regular internal and external audits are essential for a reality check. External audits provide fresh eyes and a different perspective to validate the baseline and identify potential gaps.
How Can Security Teams Avoid Becoming a Roadblock to Business Velocity?
Security must find a balance between stringent controls and development velocity to avoid becoming a roadblock for the core business.
The Inclusion-Based Approach (Safelist)
To handle the constant rollout of new cloud services, Kushagra recommends a safelist approach
- Principle: Permit only a list of approved services to be used (e.g., in a production environment) rather than attempting to deny a list of services and allowing the rest.
- Benefit: This approach prevents new services from being deployed without first passing through the security review cycle and threat handling. It gives the organization granular control over what is deployed.
Dynamic Controls and Flexibility
Security should deploy dynamic controls to provide developers with flexibility and enable rapid experimentation.
- Hard No (SCPs): Use Service Control Policies (SCPs) for non-negotiable controls where deviation or exception is never anticipated.
- Flexibility (Permission Boundaries): Use IAM Permission Boundaries where flexibility is needed or where exceptions are anticipated.
- Dynamic Generation: Implement “flavored permission boundaries” that can be built on the fly for a specific account (e.g., a pre-product dev environment). Developers can request access via Infrastructure as Code (IaC), removing the “grey area” where security manually tweaks permissions.
- Dynamic SCPs: Some practitioners are also building dynamic SCPs that are attached at a per-account level, managed through a UI and request flow.
- Infrastructure as Code Checks: For controls where policies lack granular condition key or constraint support, leverage IaC checks in the deployment pipeline. Flag these as warnings in sandbox environments, but enforce them as a hard no in production.
Is a One-Size-Fits-All Security Baseline Possible?
A single, one-size-fits-all security baseline for every single account in a large organization is not maintainable (e.g., managing 10 different versions of a baseline across 1,000 accounts). However, a layered approach and a one-size-fits-all boilerplate are crucial for maintaining standards and scale.
The Layered Architecture
The security baseline should be implemented in layers:
- Global Baseline (Non-Negotiable): This is the top layer consisting of non-negotiable controls (e.g., encryption by default, MFA for users, monitoring) that apply to every account in the organization, no matter what. SCPs are often used for this layer.
- Context-Specific Layered Boundaries: The permission boundary template is a one-size-fits-all boilerplate. This template dynamically generates a specific permission boundary based on the context (e.g., sandbox, QA, production, PCI scope, or legacy environment).
This layered approach ensures you don’t break developer productivity by having overly restrictive controls where flexibility is needed.
How Can Organizations Promote a Strong Security Culture?
Building a security culture requires bridging the gap between security and engineering, ensuring security is not an afterthought.
- Early Engagement: Involve security teams as early as possible, even in architecture reviews and design phases. Waiting until a feature is ready to roll out creates the perception of security as a roadblock.
- Openness and Awareness: Security should not be a grey area or a black box. Publish all the controls and checks (per service, per cloud) that apply to a developer’s environment. This knowledge transfer moves the culture towards shift left, as developers understand the underlying issue and are less likely to repeat the mistake.
What Strategies Work for Cloud Migrations and Multi-Cloud Setups?
Legacy Migration
When migrating from an on-premise or legacy cloud environment, flexibility in the permission boundary is key.
- Flexible Boundary: Use a different, more relaxed flavored permission boundary for the legacy environment during the migration.
- Flexible Boundary: Use a different, more relaxed flavored permission boundary for the legacy environment during the migration.
- Refactoring: Ideally, organizations should refactor their environment to leverage cloud-native managed services rather than simply doing a “lift and shift,” though business requirements sometimes demand the latter.
- Core Foundation: Before starting any large-scale security implementation, the core foundation must be in place, including having centralized deployment mechanisms to deploy controls to thousands of accounts at scale.
Multi-Cloud Architecture
For security across multiple cloud providers (e.g., AWS and GCP), use the layered approach to distinguish requirements.
- Cloud Agnostic Requirements (Common): Generic, non-negotiable requirements (like encryption by default) must be mapped out and enforced everywhere.
- Cloud Specific Requirements: The implementation of a requirement will differ (e.g., IAM terminologies). Specific controls targeting cloud-unique services and features must be designed for each provider.
- Visibility is Core: Before any implementation, have a very good asset inventory (asset management) of your entire cloud footprint to query every asset and know its configuration. Visibility is the core component that allows security teams to reverse engineer controls based on deployed, insecure resources.
Recommendations for Growing Startups
For growing companies, it is vital to start small and implement foundational controls from the get-go to avoid breaking production workflows later.
- Use Benchmarks: Don’t reinvent the wheel. Start with standards like NIST and CIS benchmarks.
- Cloud Agnostic Standards: List requirements in a generic, cloud-agnostic way (e.g., encryption at default, MFA for users) so controls aren’t limited to a specific cloud provider.
- Iterative Implementation: Start by listing the standards that will go into the non-negotiable control set. This becomes Version 0.1 of the baseline. It’s an ever-going iteration where you start small (e.g., 10 controls) and become more granular over time (e.g., 200 controls).
Conclusion: The Path to a Self-Securing Cloud Environment
Kushagra Sarma’s framework for cloud security underscores a fundamental truth: in environments scaled to thousands of accounts, manual security is impossible. The path to resilience lies in adopting a cloud-first, cloud-native mindset built on two pillars: proactive foundations and flexible boundaries.
By using a layered baseline and a one-size-fits-all boilerplate approach, organizations can achieve standardization while still allowing the necessary contextual flexibility for sandbox, QA, and production accounts. Critically, security must move beyond being a “black box” and empower developers by collaborating early, using IaC, and designing systems where the insecure path is the hardest one to take. Ultimately, continuous refinement driven by threat intelligence and a relentless focus on visibility is the only way to keep pace with the hyper-accelerated evolution of the public cloud.
