The complexity of modern cloud environments and the speed of development have made continuous security and effective incident response non-negotiable. For many organizations, the challenge lies in reconciling rigid compliance requirements with practical, continuous security implementation, all while managing diverse stakeholders and the disruptive potential of Generative AI.
We spoke with Jan Hertzens, Senior Security Consultant at AWS, about his pragmatic approach to these conflicts, the evolution of his security philosophy, and the practical application of new technologies in cloud defense.
You can read the complete transcript of the epiosde here >
How Do Compliance Requirements Conflict with Continuous Security?
Security programs often struggle because they are driven by the conflicting agendas of different internal stakeholders.
The Three Personas and Their Drivers
- App Builders (Developers): Their primary driver is “not to get pwned” and releasing the product on time.
- Compliance Teams (Auditors): Their drive is to “check some boxes” because compliance (e.g., PCI) is mandatory, and failure means legal consequences.
- Management: Their focus is to “make the line go down”—reducing the number of reported vulnerabilities on a graph.
The Conflict of Priorities
These drivers are often in conflict, creating ineffective security efforts.
- Misguided Focus: An organization might focus heavily on “making the line go down” by patching 14,000 vulnerabilities on EC2 instances. However, this is “silly” if the instances are in auto-scaling groups (meaning they have to be re-patched constantly) or if the operating system is no longer supported, which just leads to new vulnerabilities.
- Missing the Critical Issues: Patching low-impact vulnerabilities (the “ingrown toenails”) distracts from more critical, high-risk architectural failures like developers having admin access in production or keeping keys on their laptops.
The Problem with Unthinking Compliance
Jan warns that rigid, unthinking adherence to compliance rules can actively hurt security and create unnecessary work.
- Excessive Alerting: CIS hardening guides might mandate a CloudWatch alert for every security group change, firing off emails every time a change is made. This volume of emails simply creates more noise and spam, leading to security managers ignoring them (e.g., if they have three or four digits of unread emails). In 2024, alerts should go to a central SIEM, Splunk, or Slack, not email.
- Creating Problems: Compliance might mandate Multi-Factor Authentication (MFA) and password rotation on the AWS root account. However, if an organization uses API-based creation of AWS accounts and never creates the root account, the correct security practice is not to create the root account just to satisfy a checklist, as this creates a problem that didn’t previously exist.
The solution is always to ask “why” a control is needed and determine if a compensating control (e.g., automated account creation) already satisfies the compliance requirement.
How Can Organizations Achieve Balance and Drive Security Culture?
Achieving balance requires a central governing body that can triage risk and speak the language of each persona.
The Center of Excellence (CoE)
- Central Governance: The most indicative sign of success is having a well-supported center of excellence for cloud security that manages the process centrally and sets the rules.
- Risk Triage: The CoE must explain that not all vulnerabilities are equal. They must run a triage process, prioritizing high-level threats (like possible liver cancer) over low-impact issues (ingrown toenails). The focus must be on setting high-level policy first, rather than frantically patching old systems.
- Tailored Communication: The CoE must tailor its message:
- Management: Needs reports with nice primary colors and graphs to show the line. Reports should be done per team so managers know who is running behind.
- Developers: Need easy how-to’s and scripts (e.g., “Here’s a script that will deploy it”). They do not have time to learn 14 new concepts but need their product released.
Collaboration for Continuous Security
Jan strongly advocates for collaboration with application developers to embed security into the application delivery process itself.
- Application Manifests: Security works best if you make security rules part of the application delivery manifest. The developer should define:
- What kind of data is on the app (e.g., PHI data).
- What database it connects to.
- What port it listens on.
- What URLs it needs to access.
- Automated Validation: By using this manifest, you can automate testing in the QA environment. If the app tries to access a URL not on the approved list (e.g., www.microsoft.com), it automatically fails there before it ever reaches production.
How Should Security Professionals Approach GenAI?
The approach to securing and utilizing GenAI should be based on basic, pragmatic security—“doing the standard kick first”.
Securing the AI Model
- Focus on Basics: Ninety-nine percent of securing a GenAI instance is the same as securing any regular application: ensuring data is encrypted, applying access control, managing networking, and using minimal privilege.
- Don’t Trust the Input/Output: Pragmatically, security professionals should not trust the model with critical stuff. Look at the model as a black box and apply security to the inputs and outputs (e.g., managing the personas that have access).
- AI-Specific Attacks: Attacks like “ChatGPT jailbreak” which make the model reveal data it shouldn’t, are handled by focusing on output validation and ensuring the data given to the model (in RAG systems) is not overly sensitive.
Leveraging AI for Incident Response
GenAI tools should be used as a fast assistant, not as an immediate, trusted solution.
- Start with Managed Services: Organizations should start with managed services that have AI/ML inside, such as GuardDuty for detecting non-normal behavior.
- GenAI as Assistant: GenAI can be used to
- Code Generation (Left Shift): Ask the model, “How do I securely create a new S3 bucket in company XYZ?”. This is integrated into the IDE for a quick win.
- Data Analysis: Use it to help analyze large amounts of data from a security lake, looking for patterns and consolidating findings.
- Remediation Code: Generate code to remediate a finding (e.g., generate an AWS CLI command for a NACL rule to block a specific port). The incident responder can then validate and copy-paste the suggested code quickly.
- Trust, but Verify: The generated code should never be trusted immediately. Build systems that automatically test the remediation code against positive and negative test cases to validate the fix before deployment.
What Are the Core Principles of Cloud Incident Response?
Cloud incident response (IR) differs fundamentally from on-premise IR because the physical limitations are removed, enabling automation.
The Incident Response Lifecycle
- Preparation (The Biggest Part): Must limit the blast zone through micro-segmentation and proper architecture (e.g., immutable instances).
- Identification: Having logging and monitoring fire off when bad activity occurs.
- Containment: Limiting what the bad asset can do (e.g., through automated API-driven isolation, rather than running to pull cables).
- Remediation and Fix: Running scripts to fix things. The ability to automate remediation puts the security team on equal footing with the attacker.
- Lessons Learned: Analyzing what happened and how to fix it for the future.
Key Cloud Practices for Incident Response
- Immutable Infrastructure: Embrace the “cattle versus pets” philosophy. Make images once and never allow them to change (immutable instances). If something goes wrong, “shoot it in the head” (terminate the instance) and replace it, or snapshot the image for forensics.
- Micro-Segmentation: Pre-build narrow network rules so that an asset can only talk to its approved load balancer or database.
Testing and Teamwork
- Tabletop Exercises: These are essential for finding gaps (e.g., does anyone know how to contact marketing for a downtime message? Does legal need to approve the response?).
- Hands-On Jams: Use AWS Jams (Capture the Flag without the music) in groups to simulate real-life environments. This promotes teamwork and meta-learning between Ops, Network, and App teams, showing them how to communicate securely when systems are compromised.
Final Conclusion: The Continuous Security Imperative
Jan Hertzens’s strategy for continuous security is defined by pragmatism and automation. Success hinges on reconciling the conflicting agendas of developers, compliance teams, and management through a centralized Center of Excellence (CoE) that prioritizes risk triage and custom-tailored communication.
In practice, this means establishing security not through compliance checklists, but by embedding it in the application manifest, ensuring developers define the security requirements, and automating validation in QA environments. As the threat landscape is increasingly dominated by AI, security teams must treat GenAI as a powerful but untrustworthy assistant, leveraging its power to automate remediation and analysis, but always adhering to the core principle: validate everything before execution. The ultimate goal is to remove friction and automate the fix, putting security on equal footing with the speed of the attacker.
