As companies continue to invest in cloud transformation, the attack surface and exposure to new threats and unexplored risks can highlight gaps in knowledge and erode the confidence in workloads running in production.

This course highlights key areas of interest for security professionals, cloud engineers, and software developers, by providing a checklist of security best practices and personal recommendations, which can be leveraged to improve security posture while operating in the AWS cloud.

The AWS Security Checklist

In the modern digital world the demand for skilled security professionals is growing at an exponential rate. Every day there is a news story regarding the latest company who has fallen victim to a security breach, and companies are hiring across a wide variety of security positions to help protect themselves and their customers. To facilitate keeping businesses secure there are a plethora of different career paths for you to take, in this course we’ll look at some of the most common.

The Security Careers Guide

AWS Security Services

OWASP Top 10 Web Application Security Risks - 2021

OWASP Top 10:2025

I stumbled across an account on Twitter this weekend, which was sharing a misconfiguration they had found in a mobile application. The misconfiguration resulted in the private data of hundreds of thousands of vulnerable individuals being made publicly available for anyone to access.
We like to proclaim that security by obscurity is not acceptable, but when it comes to responsible disclosure I believe it’s of the utmost importance. What keeps the user's data safe in this situation is the integrity of the security researcher who found the misconfiguration, and what they choose to do with that information.
In this case they sent a couple of emails to the company in question, and after not receiving a response within 2 weeks, they posted it on Twitter for the world to see. The individual defended their position and the actions they took, but in my opinion this is unethical and unacceptable. There wasn’t any thought for the safety of the users, they were unfortunate pawns in a quest for online clout.
There are plenty of guides and official standards available online, and I’ll link to some below, which show detailed processes for declaring vulnerabilities, but I’ll share some thoughts of my own on how I believe these situations could be handled better. I’m not a security researcher, I haven’t gone through this process, these are just my opinions and I’m always happy to be educated further or proven wrong.
When a vulnerability in a system is discovered, the first place I would look is for a security.txt file on the company website. This is a reasonably well adopted and recommended standard, and it provides contact details for the people responsible for dealing with vulnerabilities within that company or organisation. In the case mentioned earlier, this file does not exist, but it’s only the first step of many I would take.
The next place I’m looking is for security personnel, software engineers, and senior staff members of the company in question on LinkedIn. For all it’s AI slop, LinkedIn is a fantastic platform for reaching out to people who work at specific companies. You can find members of the C-suite on there too, but I would start with more technical people first.
Sending emails is worthwhile, but it’s a less reliable option. Emails can end up in junk or spam folders, filtered out or quarantined by firewalls, or some people just have busy inboxes and it may slip through the net, especially if it’s from someone the recipient doesn’t know. Definitely give it a go, but don’t expect a response.
Send a generic message on social media; a lot of companies invest in support teams through platforms like Twitter. Don’t disclose any details, but use it as a tool to reach the right people with whom you can responsibly disclose your findings.
Reach out to other security professionals who have more experience with responsible vulnerability disclosure. The security community is full of brilliant people who may be able to put you in contact with someone through their network, or at least provide guidance on what you can do to reach the right people.
You can check with bug bounty platforms like HackerOne, for companies that have an active bug bounty programme where they will share relevant contact details.
If you’re hitting brick walls in your search for a contact, or you simply don’t have the time or patience to see it through, there are CERTs in almost every country who can help take on the responsibility.
There are suggested timeframes, such as 90 days, before some believe it’s acceptable to disclose publicly. Even after exhausting all options of contacting the company in question, I would much rather fallback on security by obscurity, especially in cases where the data being shared is in relation to vulnerable people.
We talk about white hat, grey hat, black hat, in security, but really it’s a spectrum, and my morals are on the opposite end of the spectrum to people who think it’s acceptable to expose vulnerabilities on Twitter for likes, while putting hundreds of thousands of people at risk.
I’m hopeful this trend isn’t one that grows, and we can promote good ethics when dealing with vulnerabilities. With a lower barrier to entry which comes with AI tools, and the intoxicating allure of social media likes, let’s promote good behaviours and challenge poor representatives of the security community.
<h2>Useful Resources</h2>
<ul>
 <li><a href="https://securitytxt.org/" target="_blank" rel="nofollow">security.txt</a></li>
 <li><a href="https://hackerone.com/directory/programs" target="_blank" rel="nofollow">HackerOne</a></li>
 <li><a href="https://certcc.github.io/CERT-Guide-to-CVD/topics/" target="_blank" rel="nofollow">CERT® Guide to Coordinated Vulnerability Disclosure</a></li>
 <li><a href="https://www.iso.org/standard/72311.html" target="_blank" rel="nofollow">ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure</a></li>
</ul>

I stumbled across an account on Twitter this weekend, which was sharing a misconfiguration they had found in a mobile application. The misconfiguration resulted in the private data of hundreds of thousands of vulnerable individuals being made publicly available for anyone to access.

Responsible disclosure matters in cybersecurity

I contemplate posting something during this period each year about my experiences with my own mental health, but I’ve never published any of them. I'm going to write this directly into the editor and hit publish, so there may be some errors.
I’ve always battled with depression and anxiety, from a very young age. I wouldn’t go to primary school, through overwhelming fear, and I still remember the feeling of battling anxiety every morning before heading off to high school.
I wasn’t the smartest kid in school; I got good grades, but I had no idea what I wanted to do after school. I completed an Electronics BTEC and a Mechanical Engineering BTEC, all while climbing the ranks in the catering industry. Although catering is a difficult industry due to low pay and long hours, I was often held back by what was perceived as a lack of passion, but really I was just a shy, quiet, and anxious young man. I would still produce despite that.
I later went back to college and on to university, before getting into the tech industry. I worked as a frontend developer, backend developer, devops engineer, platform engineer, and found my way into security, which has been a passion I have held throughout my tech career. I followed the things I enjoyed, and I did them to the best of my ability. Through each career change I would suffer with imposter syndrome, and I still do now sometimes with over a decade of experience. I better understand this phenomenon now, but earlier in my career I would burn the candle at both ends trying to learn as much as possible.
Throughout most of my life there has been a constant battle. I still have days of severe anxiety, where simply going to the shop for milk seems like an impossible task. I also suffer from depression which hits its peak when I’m isolated for long periods. I’m too scared to do the thing, but I’m sad I can’t do the thing, it’s exhausting sometimes.
As I got older and met my lovely wife Kylie, she would give me the confidence to push past some of my anxieties, which would result in a happier Chris. And as I became a father I would force myself into situations I would usually avoid on my own, so that they are not held back by my shortcomings. I’ll never let my fears stand in the way of my children experiencing everything they want in life, they will have no idea they even exist, unless they come to me with their own anxieties and I’ll let them know that it’s all OK.
I used to pester my bosses about flexible working, and maybe having the opportunity to work from home occasionally. I was always met with strong resistance and paranoid justifications for why that wouldn’t be possible. Of course everyone worked remotely, and the business I was working for peaked, during the unfortunate events of the COVID pandemic. Since then I’ve been lucky enough to work from home at each subsequent place of employment.
With my family around me, and a work environment that supports me working from where I feel most comfortable, I’ve been able to thrive both personally and professionally.
I’ve spent a lot of time maturing into my position as a security engineer, and I’ve reflected on what my strengths and weaknesses are. A clear weakness is my in person public speaking abilities, the anxiety will likely always win, but that anxiety isn’t the same working remotely. I can still be a leader in my field within the right environment, you just might never see me on the big stage.
Strong relationships at home and work have been massive for me, but it’s also important to have something outside of that where you can forget about all your day to day stresses. For me that escape came through starting Brazilian JiuJitsu, it’s helped me build resilience, learn something cool, and meet some amazing people - I’d also become a bit of a potato working at a desk the past decade, and I’m starting to feel a lot healthier through actually doing something physical.
I’ve tried to not go into too much detail, because it can be a dark topic and some points were really low points in my life which I've now moved on from, but if you can relate to anything I’ve written about here then feel free to reach out. I’m happy to chat about anything you like, or simply be someone who will listen. Look after yourself.
I thought I'd also share links to a few charities close to my heart if you’re interested:
<ul>
 <li><a href="https://www.mind.org.uk/" target="_blank" rel="nofollow">https://www.mind.org.uk/</a></li>
 <li><a href="https://www.barnabus.org/" target="_blank" rel="nofollow">https://www.barnabus.org/</a></li>
 <li><a href="https://andysmanclub.co.uk/" target="_blank" rel="nofollow">https://andysmanclub.co.uk/</a></li>
</ul>

Strong relationships at home and work have been massive for me, but it’s also important to have something outside of that where you can forget about all your day to day stresses. For me that escape came through starting Brazilian JiuJitsu, it’s helped me build resilience, learn something cool, and meet some amazing people - I’d also become a bit of a potato working at a desk the past decade, and I’m starting to feel a lot healthier through actually doing something physical.

Men's Mental Health Awareness Month

If you’re building services in AWS, and want to ensure you have a robust backup and disaster recovery plan, then you’re likely going to explore using the AWS Backup service. It covers a wide array of AWS services, and can also be used for on premise solutions outside of the cloud, but there is a lot to account for, especially as you move beyond the basics. This post will highlight some of the things to be aware of, and help you get set up in a multi-account AWS Organization.
<h2>Delegate Administrator Account</h2>
There are 2 parts to be aware of when creating a delegate administrator, one is straightforward and the other is a little more complicated.
We’ll want to give an AWS account, outside of the management account, delegate administrator privileges for the AWS Backup service. This will provide a global view of the service across the AWS Organization, so that you don’t need to log into each account to observe what is happening with your backups, and therefore avoid accessing the management account directly, which is best practice.
<img src="https://media.chrisdunne.com/img/content/original/aws-backup-delegate-admin.webp" alt="A section of the dashboard in the AWS Backup service, which is used for setting up a delegate administrator account from the management account"/>
To achieve this all we need to do is turn on cross account monitoring, then we can select an account to be registered as a delegate administrator. As you can see from the image above, you can have up to 5 delegate administrators for the AWS Backup service, but you’re only likely going to use 1. These settings can also be configured using infrastructure as code or Control Tower settings if you’re using those to manage your AWS estate.
When using AWS Backup we can use a Backup Policy to configure what happens with backups across our accounts or Organizational Units (OUs), and these policies are pushed out the AWS Organizations service and not AWS Backup itself. This means we also need a resource policy setting up in our Management account, to facilitate the delegate administration of the backup policies. Backup policies allow for managing backups across multi-account setups, if you’re deploying to a single account you can simply deploy individual plans direct to your account.
Here’s an example resource policy that can be deployed within the Management account, which will then facilitate deploying backup policies through our secondary account. I will refrain from making a recommendation on which account you should use as your delegate administrator account, as it depends on your setup, but the following is an example of how we might achieve the desired result.
<pre><code>{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "AllowOrganizationsRead",
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::12345678910:root"
 },
 "Action": [
 "organizations:List*",
 "organizations:Describe*"
 ],
 "Resource": "*"
 },
 {
 "Sid": "AllowBackupPolicyModification",
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::12345678910:root"
 },
 "Action": [
 "organizations:CreatePolicy",
 "organizations:UpdatePolicy",
 "organizations:DescribePolicy",
 "organizations:DeletePolicy"
 ],
 "Resource": "arn:aws:organizations::10987654321:policy/*/backup_policy/*",
 "Condition": {
 "StringEquals": {
 "organizations:PolicyType": "BACKUP_POLICY"
 }
 }
 },
 {
 "Sid": "AllowBackupPolicyAttachmentAndDetachment",
 "Effect": "Allow",
 "Principal": {
 "AWS": "arn:aws:iam::12345678910:root"
 },
 "Action": [
 "organizations:AttachPolicy",
 "organizations:DetachPolicy"
 ],
 "Resource": [
 "arn:aws:organizations::10987654321:ou/*",
 "arn:aws:organizations::10987654321:account/*",
 "arn:aws:organizations::10987654321:root/*"
 ],
 "Condition": {
 "StringEquals": {
 "organizations:PolicyType": "BACKUP_POLICY"
 }
 }
 }
 ]
}</code></pre>
In the above example 10987654321 is the Management account, and 12345678910 is the account we’re providing delegate administrator access to manage backup policies within our AWS Organization.
The 3 statements contained within the example resource policy are:
<ul>
 <li>AllowOrganizationsRead - Allows the delegate administrator to read the policies within the organization.</li>
 <li>AllowBackupPolicyModification - Provides Create, Read, Update, and Delete (CRUD) operations for backup policies within the organization.</li>
 <li>AllowBackupPolicyAttachmentAndDetachment - Allows the delegate administrator to attach and detach backup policies from the root OU, child OUs, and specific accounts.</li>
</ul>
<h2>What is a backup policy?</h2>
Now we know how we can deploy a backup policy via a delegate administrator, let’s take a look at what a backup policy is and how it’s used. We can deploy multiple back policies, and they can be attached to an AWS account, the root OU, or a child OU within your AWS Organization.
Backup policies allow you to define robust configuration for backups across your multi-account cloud estate, instead of having to individually deploy them to each account - although you can do that too where it makes sense. These policies cannot be amended by accounts they are deployed to outside of the Management and delegate administrator accounts, which makes them a great tool to be leveraged for compliance requirements.
A backup policy consists of the usual name and description, with an array of backup plans, which will all be made available and applied where appropriate within the accounts of OUs you attach the backup policy to.
<h2>What is a backup plan?</h2>
The backup plan is where you define the rules for your backups, they contain the following configuration options:
<ul>
 <li>Target backup vault name - where the backup will be sent to once it has completed, within the same account.</li>
 <li>Scheduled expression - for backups that run on a schedule these will be defined through a CRON command.</li>
 <li>Start backup window minutes - defines the maximum window before the backup should begin.</li>
 <li>Complete backup window minutes - the maximum amount of time a backup can run for before timing out.</li>
 <li>Enable continuous backup - a boolean option for point in time backups, which can be used for point in time recovery, instead of snapshot backups.</li>
 <li>Lifecycle - how long you want to keep the backups for, and whether they are sent to cold storage.</li>
 <li>Copy actions - define a secondary backup location, where backups are copied to a vault in another account for a more robust backup setup. This is useful if you want to use a cloud version of the 3-2-1-1-0 strategy for backups.</li>
 <li>Regions - define the regions in which the backup plan is applicable, you may want different configuration based on regulatory requirements within specific regions.</li>
 <li>Selections - an optional setting, which allows the enrollment of a resource into the backup plan via tags, or you can specify the type of resources the backup plan is applicable to.</li>
</ul>
You can read more about the various options here: <a href="https://docs.aws.amazon.com/aws-backup/latest/devguide/plan-options-and-configuration.html" target="_blank" rel="nofollow">https://docs.aws.amazon.com/aws-backup/latest/devguide/plan-options-and-configuration.html</a>
<h2>Example backup policy with a backup plan</h2>
Let’s take a look at a simple example backup policy with a single backup plan inside, which takes a backup of S3 Buckets every night at midnight in the eu-west-1 region.
<pre><code>{
 "plans": {
 "S3_Backup_Plan": {
 "regions": {
 "@@assign": [
 "eu-west-1"
 ]
 },
 "rules": {
 "NightlyBackupRule": {
 "schedule_expression": {
 "@@assign": "cron(0 0 * * ? *)"
 },
 "start_backup_window_minutes": {
 "@@assign": "480"
 },
 "complete_backup_window_minutes": {
 "@@assign": "10080"
 },
 "lifecycle": {
 "delete_after_days": {
 "@@assign": "90"
 },
 "opt_in_to_archive_for_supported_resources": {
 "@@assign": "false"
 }
 },
 "target_backup_vault_name": {
 "@@assign": "BackupMcBackupFace"
 }
 }
 },
 "selections": {
 "resources": {
 "resource_types": {
 "iam_role_arn": {
 "@@assign": "arn:aws:iam::$account:role/BackupRole"
 },
 "resource_types": {
 "@@assign": [
 "S3"
 ]
 }
 }
 }
 }
 }
 }
}</code></pre>
This can be assigned to an OU and distributed through AWS Organizations, which allows for a single policy to be applied across multiple accounts. In a single account architecture we would only need to push the backup plan itself to the individual account, but backup policies come into their own in multi-account organizations.
<h2>Permissions required by the AWS Backup service</h2>
In order for the AWS Backup service to carry out backups, it needs the relevant permissions to do so. If you are configuring AWS Backup manually through ClickOps then a default AWS Managed service role is created for you to use within each account. However, when it comes to deploying your resources through infrastructure as code, the service role does not exist for your initial deployment, so you’ll have to create it yourself either through the AWS CLI or by creating your own custom IAM Role.
The default service role which is created for you is called AWSBackupDefaultServiceRole, and it has 2 policies attached, AWSBackupServiceRolePolicyForBackup and AWSBackupServiceRolePolicyForRestore.
For whatever reason, these policies do not include permissions for S3, you will need to manually add AWSBackupServiceRolePolicyForS3Backup and AWSBackupServiceRolePolicyForS3Restore which are the AWS Managed policies for S3 backup permissions.
<h2>Additional permissions for Copy Actions</h2>
Copy Actions are an optional feature of backup plans, which allow you to generate a copy of the backup to be stored in a secondary location. This is usually a separate account, often one dedicated to centralising backups in a more locked down account.
This is where IAM permissions get a little more complicated, especially when the secondary backup location is in another account, as the KMS key used to encrypt backups within the secondary account needs to be made accessible to the IAM role used by the AWS Backup service within the source account.
When using infrastructure as code it’s simply a list of principals to add to the KMS key policy for the secondary backup vault encryption key, but through ClickOps it would soon get too complicated to manage.
You will also need to add a resource policy to the secondary backup vault, which allows the backup role from your other account to copy backups across.
<h2>Not all services are fully managed</h2>
One of the main pain points I’ve found working with AWS Backup is that there isn’t native support for all AWS resources, in fact there are only a handful which are classed as fully-managed. For those few resources which are fully-managed the level of configuration to get up and running is minimal and it’s a great experience working with AWS Backup, but for the rest it can be quite cumbersome to setup and maintain across a large organization. You really need to incorporate infrastructure as code and a simple deployment strategy to build a successful backup process for your business.
Here you can find a full list of what features of AWS Backup are supported by each AWS service: <a href="https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html" target="_blank" rel="nofollow">https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html</a>
When it comes to onboarding data sources and getting engineering teams using AWS Backup, start with the fully-managed service types as a self-service option, and work closely with teams to build exemplars for the other resource types. As there is a barrier to entry, you need to provide a level of support upfront, but once the necessary configuration is in place for the other resource types it can become a fully self-service platform for backups.
<h2>Using KMS CMKs for non-fully managed services</h2>
If you require cross-account backups, then you will have to use KMS CMKs. There is a limitation for non-fully-managed services, where AWS managed KMS keys cannot be used for cross account copy jobs within a backup plan. This is because AWS managed KMS keys are immutable, and so we cannot update the key policy to allow cross-account actions.
When using fully-managed resource types this is taken care of by the AWS Backup service, but for everything else we need to use KMS CMKs and manage those ourselves.
To allow for cross-account backups through Copy Actions we need to give the backup role access to the KMS CMK within the secondary account, which may look something like this:
<pre><code>{
 "Version": "2012-10-17",
 "Id": "Example KMS CMK key policy for cross-account copy actions using AWS Backup",
 "Statement": [
 {
 "Sid": "Allow use of the key",
 "Effect": "Allow",
 "Principal": {
 "AWS": [
 "arn:aws:iam::123456789012:role/BackupRole",
 ]
 },
 "Action": [
 "kms:Encrypt",
 "kms:Decrypt",
 "kms:ReEncrypt*",
 "kms:GenerateDataKey*",
 "kms:DescribeKey"
 ],
 "Resource": "*"
 }
 ]
}</code></pre>
There will be other statements within your key policy, but the one in the example above account number 12345678910 is the account where the backups are taken, and it can now access the KMS CMK key used by the secondary backup vault for encryption during Copy Actions.
<h2>Recovering from a backup</h2>
There are plenty of options for automated testing of backups, and restoring a resource based on triggers, and I’ll probably write another post centered around that topic. For now recovery from a backup can be performed really simply through ClickOps.
Within the account where the backups are taken or a secondary backup vault, there is a button to restore a backup. There will be some configuration depending on the resource type, but AWS will take care of the rest. The duration a restore takes is dependent on the size and type of resource.
<h2>Multi-account view of backups and copy actions</h2>
Once you have some backups up and running, you can navigate to the AWS Backup service within your delegate administrator account and view what’s happening across your accounts.
<img src="https://media.chrisdunne.com/img/content/original/aws-backup-backup-jobs.webp" alt="A section of the dashboard in the AWS Backup service, where you can view all backup jobs across the organization"/>
In the Cross-account Monitoring section you will find a table with 3 sections for the Backups, Restores, and Copy Jobs which have been performed. You’ll be able to see the status of each, and setup alerting for when a backup task fails or even to provide notification of a backup succeeding.
<img src="https://media.chrisdunne.com/img/content/original/aws-backup-copy-jobs.webp" alt="A section of the dashboard in the AWS Backup service, where you can view all copy jobs across the organization"/>
This dashboard is great for providing an overview of usage across your accounts, and how they’re performing, especially if you operate a self-service approach.
<h2>Vault Locks</h2>
A feature of AWS Backup vaults that’s worth mentioning specifically is the capability to add a vault lock.
<img src="https://media.chrisdunne.com/img/content/original/aws-backup-vault-lock.webp" alt="A section of the dashboard in the AWS Backup service, where you can view vault locks within the account"/>
The management account is the key to the kingdom in AWS, and if the management account were to be compromised, then simply deleting the backups would undo all our good work. That’s where vault locks come in. They allow us to configure a period of immutability for our backups, so even if there was full account takeover, your backups would survive.
The two vault lock options are:
<ul>
 <li>Governance Lock: any backups are immutable once created for the defined lifecycle of that backup, but the lock itself can be removed.</li>
 <li>Compliance Lock: any backups are immutable once created for the defined lifecycle of that backup, and after a grace period the compliance lock can never be removed. I wrote about the potential pitfalls of such a policy here: <a href="https://chrisdunne.com/post/using-aws-backup-vault-lock-as-an-immutable-denial-of-wallet-attack" target="_blank" rel="nofollow">https://chrisdunne.com/post/using-aws-backup-vault-lock-as-an-immutable-denial-of-wallet-attack</a></li>
</ul>
<h2>Final thoughts</h2>
The AWS Backup service, for all but the most simple of backup tasks, is not a service that can be used without investing time and effort in learning about all the little quirks and complexities with configuring the service. There are possibly much easier third-party platforms you can leverage for backups of your AWS resource, especially if you only care about having something to spin up in the event of a disaster.
That being said, it’s quite a robust service, and can account for whatever your unique use case may be. It allows you to adhere to the 3-2-1-1-0 model, and has integrations for automating most tasks, it just requires a little time and knowledge to get there.
The capability to define your backup policies and plans as code, have them peer reviewed, and go through the same quality gates as the rest of your code makes it a developer friendly tool. The option for teams to then self-serve through tagging their resources is awesome.
You could have data classification tags on your resources, which map to pre-configured backup plans, which adhere to whatever your regulatory and compliance requirements are.
If all resource types were to become fully-managed within AWS Backup it would be a no-brainer to adopt within your organization, until then try and understand what’s required for your setup and whether it’s worth the time investment.
<h2>Reference Documents</h2>
<a href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html" target="_blank" rel="nofollow">https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html</a>

If you’re building services in AWS, and want to ensure you have a robust backup and disaster recovery plan, then you’re likely going to explore using the AWS Backup service. It covers a wide array of AWS services, and can also be used for on premise solutions outside of the cloud, but there is a lot to account for, especially as you move beyond the basics. This post will highlight some of the things to be aware of, and help you get set up in a multi-account AWS Organization.

How to leverage AWS Backup for resilience in a multi-account AWS Organization

Recently I spent some time exploring the available configuration options for AWS Backup Vault Locks, to ensure backups and restore points are immutable, which could be leveraged to help protect data stored in AWS from malicious actors and ransomware attacks.
There are 2 options for vault lock policies within the AWS Backup service:
<ul>
 <li>Governance Lock: Locks are applied to a backup vault, but they can be removed or changed at a later date. Items that the governance lock was applied to before being deleted remain locked for the specified duration of the lock.</li>
 <li>Compliance Lock: Locks are applied to the backup vault, with a cooldown period of a minimum of 3 days. Once the cooldown period has expired there is no way to remove the vault lock.</li>
</ul>
<blockquote>“There is no way for AWS or any other user to alter or remove it.”</blockquote>
<blockquote>“A vault lock in Compliance mode cannot be altered or deleted by any user or by AWS.”</blockquote>
<h2>What might an immutable denial of wallet attack look like?</h2>
With traditional denial of wallet attacks, it’s a little primitive and chaotic. The tactics are usually centred around creating as many expensive resources as possible before the account owner notices, resulting in potentially significant financial loss. Whereas with AWS Backup Vault Locks, we can assume from the AWS docs that there is no way to rectify an attack targeting immutable backups, besides potentially nuking the account and everything in it.
The compliance lock option sounds like a great opportunity for a malicious actor, who manages to gain unauthorised access to an AWS account, to inflict an immutable denial of wallet attack.
Due to the minimum cooldown required of a compliance lock, it makes sense to start by creating this within the account. It needs to be associated with an AWS Backup vault, and you get one out of the box with the service, so there is no need to risk detection creating your own. Simply use the default.
Once the cooldown has expired, and if the compliance lock hasn’t been detected, you can start to add resources and a backup policy which triggers frequently, or find the biggest resources which already exist in the account to avoid setting off any alarms.
The best options are probably large S3 Buckets, because they are a fully-managed resource type in AWS Backup, which means there is very minimal configuration required beyond ensuring versioning is enabled, and they can contain huge amounts of data, to rack up the costs of the immutable backups you’ll be creating.
You could even make this recursive, by backing up a CloudTrail S3 Bucket which then stores the backup events for each object within the S3 backup.
<h2>How realistic is the threat?</h2>
I performed a quick search and couldn’t find any resources discussing this, so maybe it’s something and maybe it’s nothing.
If an AWS account is compromised, this is not the lowest hanging fruit, and so an attacker probably wouldn’t focus their attention here. It is an interesting idea though, and maybe someone smarter than me could make it a worthwhile option.
In reading through the docs all suggestions from AWS point towards not being able to remove a compliance lock. In reality, I would guess that AWS say they can’t remove a compliance lock to prevent the support tickets which might come off the back of people making ill informed decisions. But, in the event of an attack like this I’m sure they would quietly find a way to shut it down.
On the scale of potential outcomes it probably falls closer to an inconvenience than causing bankruptcy, but who knows, and I’m not willing to put it to the test.
Maybe it’s not a legitimate threat, but it can’t hurt to monitor and alert on this kind of anomalous activity, and maybe GuardDuty has a rule for it - although I couldn’t find one. Also, I couldn't find management events in CloudTrail for actions taken in regards to AWS Backup Vault Locks.&nbsp;
I’ll try to remember to return to this post at a later date and provide mitigations. It does seem like there’s a missing MFA delete style option for Vault Locks, which might make more sense than the all or nothing compliance lock option.
<h2>Reference Documents</h2>
<a href="https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html" target="_blank" rel="nofollow">https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html</a>

With traditional denial of wallet attacks, it’s a little primitive and chaotic. The tactics are usually centred around creating as many expensive resources as possible before the account owner notices, resulting in potentially significant financial loss. Whereas with AWS Backup Vault Locks, we can assume from the AWS docs that there is no way to rectify an attack targeting immutable backups, besides potentially nuking the account and everything in it.

Using AWS Backup Vault Lock as an immutable denial of wallet attack

I was fortunate enough, in a previous role, to work with some excellent engineers with a Site Reliability Engineering (SRE) focus. I became familiar with the benefits of the relationship between Service Level Agreements (SLA’s), Service Level Indicators (SLI’s), and Service Level Objectives (SLO’s).
<ul>
 <li>SLA - A contractual agreement between a business and their customers, if a business falls short of this agreement there could be financial consequences.</li>
 <li>SLI - These are metrics that can be captured to determine how a service is performing, common examples are error rates, response time, and uptime.</li>
 <li>SLO - The target values, which can be used as the basis for SLA’s and leverages SLI’s to track and monitor performance against metrics.</li>
</ul>
SLO’s provide engineers with an Error Budget, and through monitoring SLO’s engineering teams know when to focus on improving the reliability of their systems as a priority.
<h3>Example</h3>
We’ll use Amazon S3 as an example use case, and what that might look like within the AWS team.
<ul>
 <li>SLA - Guarantee of 99.9% uptime each month</li>
 <li>SLI - Uptime metrics for the service</li>
 <li>SLO - Tracks uptime metrics to measure against uptime requirements</li>
 <li>Error budget - Approximately 40 minutes of downtime each month</li>
</ul>
The SLO in this example can be used for monitoring and alerting, and when Amazon S3 hits 20 minutes of downtime for the month an AWS engineer might take a look at what’s causing the degraded service and choose to take action. It’s also a good predictor of the health of a system over time, and whether downtime is at an acceptable level. The agreement when using Amazon S3 as a customer, is that it may be down for 40 minutes a month.
It’s worth pointing out I know nothing of the inner workings of AWS, but simply used S3 to illustrate how SLO’s might work in practice.
<h2>What can we take from this approach?</h2>
We don’t need to reinvent the wheel, we can simply leverage the great work SRE has done with SLO’s. Here’s how we might slightly extend the scope, and start using them for security:
<ul>
 <li>SLA - Contractual agreement between a business and their customers, if a business falls short of this agreement there could be financial consequences.</li>
 <li>SLI - Service performance aligns with availability in the CIA triad, but we can go further with security vulnerabilities, misconfigurations, network exposure, etc</li>
 <li>SLO - A target based on risk tolerance and regulatory requirements, which can be used as the basis for SLA’s and leverages SLI’s to track and monitor performance against metrics.</li>
</ul>
As you can see it’s not too dissimilar to the original description I provided for SLA’s, SLI’s, and SLO’s, SLA’s are exactly the same as before.
<h3>Example</h3>
Let’s envision a team within a business, which owns the checkout process on an e-commerce website. There are strict regulatory requirements due to payment processing, but also customer requirements to ensure they can make payments securely.
<ul>
 <li>SLA - Guarantee of 0 critical vulnerabilities 99% of the time each month</li>
 <li>SLI - vulnerability metrics from our CNAPP for the checkout application</li>
 <li>SLO - Tracks vulnerability metrics to measure against critical vulnerability requirements within the checkout application</li>
 <li>Error budget - Critical vulnerabilities must be remediated within 7 hours</li>
</ul>
<h2>Conclusion</h2>
SLO’s feel like the perfect tool for measuring the security posture of our applications, while taking into account the various contexts and risk profiles of different services and applications. We don’t need a high level security score which covers everything, and we don’t need to apply the same rules across all applications. We can create SLO’s for the smallest applications or for our biggest systems, and engineering teams can manage and track their own risk appetite and codify their risk tolerance through error budgets.

SLO’s feel like the perfect tool for measuring the security posture of our applications, while taking into account the various contexts and risk profiles of different services and applications. We don’t need a high level security score which covers everything, and we don’t need to apply the same rules across all applications.

What can Security teams learn from Site Reliability Engineering and Service Level Objectives?

I took a day out from the grind this week and attended the first day of the DTX Manchester conference. It was my first time attending this particular conference, despite having the opportunity to attend in the past. The venue is one I’ve been to many times, mostly for music concerts back in the day - although it’s now called Manchester Central, it will always be the G-Mex to me. I was excited for the day ahead, the weather was glorious, and hopefully Northern Rail wouldn’t spoil the occasion.
<h2>What I got up to</h2>
I arrived while the keynote was taking place; no disrespect to Dame Laura Kenny, who I have watched dominate track cycling for over a decade, but my primary focus for the day was all the cybersecurity things, and it gave me the opportunity to navigate the vendors stalls without too much foot traffic.
I stopped and chatted with many of the vendors, especially the ones who had offerings I’m currently focusing on exploring further. I’m naturally shy and introverted, but I was able to maintain my extrovert façade long enough to pick up a ThreatLocker t-shirt and a water bottle from the Sky stand - I also got a picture with the Ryder Cup (it wasn’t very flattering, so I’ll share the one without me in it).
<img src="https://media.chrisdunne.com/img/content/original/dtx-2025-ryder-cup.webp" alt="Photograph of the Ryder Cup" />
I also picked up a free drinks token from one of the vendors, but unfortunately lost it as I moved between stalls. It was slightly awkward trying to find it before resigning myself to paying for my own drink - a first world problem I know. I probably should have kept it in a secure place 🤦‍♂️
Once I’d at least observed every stall, and my social energy was diminishing, I set about revising my list of talks I’d prepared the night before to go and watch.
<h2>Identity Security in a Borderless Digital World</h2>
<img src="https://media.chrisdunne.com/img/content/original/dtx-2025-identity-security-in-a-borderless-digital-world.webp" alt="Photograph of Ray Manash talk slides on the big screen at DTX, showing the various forms of identity that businesses have to manage" />
First up was Ray Manash from ManageEngine, he focused on the challenges that modern businesses are having with managing identities. With a brief history of identity, and how we’ve evolved into the position we find ourselves today, Ray describes it as an “identity crisis”, and I tend to agree with all of his observations.
It was an engaging talk, and although there were multiple technical issues, Ray navigated all the hurdles to make me a keen observer of the ManageEngine platform and how it will develop in the future. The free coffee token was much appreciated too, which I exchanged for a trendy flat white at the front entrance (I didn’t lose this one).
<h2>Breaking free from SIEM: The future of AI-driven security operations</h2>
<img src="https://media.chrisdunne.com/img/content/original/dtx-2025-breaking-free-from-siem-the-future-of-ai-driven-security-operations.webp" alt="Photograph of Brad Freeman and his slides on the big screen at DTX, the slide shows a meme relating to SIEM tooling choices, and how we're lured in by freebies"/>
Next up was Brad Freeman from SenseOn, and his talk focused on the common plight of exponential growth in log data and how that correlates with the cost of SIEMs tools which operate a data volume pricing model. His talk was full of informative data alongside the best memes of the day. He did a great job of presenting the very real pains of the SIEM, SOAR, managed SOC option, and of selling the benefits of the SenseOn platform. I went away wanting to give the platform a spin, hopefully it’s something I can gain exposure to in the future.
<h2>The CISO's guide to the galaxy: Cyber leadership in a mad, mad world</h2>
This talk was presented by Stuart Caulson from the University of Manchester, and I unfortunately forgot to take any pictures. The Hitchhiker's Guide to the Galaxy and Terry Pratchett references went over my head completely, but it was nice to sit and listen to something a little different to the usual tech talks I seek out. I’ll be honest I chose this talk as the others at this time were “fireside chats”, and I’m not really a fan of that format.
My key takeaways were the role of the CISO being centred around an accessible security culture, and to have the business acumen to talk with executives about the security program in language they understand. Tell a story in the language the audience speaks. It wasn’t lost on me that I didn’t speak the language of the referenced literature, but despite me being uncultured it was a really engaging talk and an insight into the disconnect between the tech department and the business, and how effective communication is essential.
<h2>Closing the security visibility gap: Tackling blind spots and unknown threats</h2>
<img src="https://media.chrisdunne.com/img/content/original/dtx-2025-closing-the-security-visibility-gap-tackling-blind-spots-and-unknown-threats.webp" alt="A photograph of the ThreatAware slides on the screen at DTX, with Jon and Andy discussing the benefits of the ThreatAware platform"/>
This talk was presented by the owner of ThreatAware Jon Abbott and a customer representative from THG Andy Jackson. Although it was a sales pitch for the ThreatAware product, I gained some interesting insights into how ThreatAware can detect and remediate the misconfiguration of endpoint security tools. It also sounds like a great product for companies that have a large number of acquisitions, as you can simply point your existing configuration at a different EDR tool and it works, without the need for reconfiguration or migration to a single tenant.
<h2>GenAI in cybersecurity: Practical applications for smarter threat detection and defence</h2>
<img src="https://media.chrisdunne.com/img/content/original/dtx-2025-genai-in-cybersecurity-practical-applications-for-smarter-threat-detection-and-defence.webp" alt="Photograph of Graham Thomson and one of his slides on the big screen at DTX, where he is discussing the different types of AI"/>
This was my favourite talk of the day. Graham Thomson from Irwin Mitchell provided insight into the AI landscape and how we can leverage AI to make improvements across all pillars of security. It was an added bonus that he was the only talk of the day who wasn’t trying to sell anything, he just wanted to share all the cool things and I enjoyed every minute.
I’m not ashamed to say I’ve been late to the party with AI, it was a conscious choice I made to not invest too early in a field which was quickly adapting. I feel the right time for me to jump in and start my own journey with AI is now, and this talk was filled with gems that had ideas popping into my head long after the talk had concluded, and I can’t wait to get started.
Expect some AI related blog posts in the future!
<h2>Summary of my time at DTX Manchester</h2>
There were a few talks I missed that I had planned on going to, and a couple that were maybes that I actually went to watch. But, conferences won’t always follow your careful plan, especially when you didn’t plan to eat or drink at any point during the day. I have also omitted a few talks I did attend which I simply got no value from, I didn’t think it would be fair to include them.
Overall I really enjoyed my time at DTX Manchester, I also managed to catch up with a good friend afterwards and went for a drink before the train ride home. I didn’t return for day two, as I’d already got everything I needed from the event, but it’s definitely worth a visit next year if Manchester is easily accessible and you have an interest in Cloud, DevOps, Cybersecurity, or just want a new wardrobe and a bunch of cool branded gadgets.
Thank you <a href="https://www.linkedin.com/in/gary-henshall-86362a5a/" target="_blank" rel="nofollow">Gary Henshall</a> from <a href="https://ghdesigns.co.uk/" target="_blank" rel="nofollow">GH Designs</a> for letting me pinch his photograph for this post.

I took a day out from the grind this week and attended the first day of the DTX Manchester conference. It was my first time attending this particular conference, despite having the opportunity to attend in the past. The venue is one I’ve been to many times, mostly for music concerts back in the day - although it’s now called Manchester Central, it will always be the G-Mex to me. I was excited for the day ahead, the weather was glorious, and hopefully Northern Rail wouldn’t spoil the occasion.

My trip to the DTX Manchester 2025 conference

Phishing is a legitimate risk to companies of all sizes, whether the method used is an advanced spear phishing attack or a low quality bulk phishing attack, malicious actors will target individuals and organisations to extract sensitive information.
As a direct result of the global threat to businesses, a phishing simulation industry which is valued at over $100 billion annually now exists. With powerful players and a huge amount of money changing hands, it’s no wonder clever marketing strategies are convincing Information Security leadership teams that phishing simulation is the right approach to mitigating phishing attacks.
Unfortunately, throwing money at the problem and trying to simulate a phishing attack doesn’t solve any of your problems, it might actually make them worse. People will click links, people will look at attachments, it’s the responsibility of security professionals to ensure their people have all the information they need to make smart decisions, and that you have the technical capabilities in place to ensure any mistakes have minimal impact.
<h2>Security Culture</h2>
I write a lot about security culture, and that’s because it’s so important. As a security professional working in a modern technology focused company, it’s impossible to micromanage and gatekeep security while having successful outcomes. People are often perceived as the biggest threat, but people can be your strongest asset in the fight against threats to a business.
Introducing a mechanism that tricks your employees into making a mistake, and then punishing them for it, is a recipe for a toxic security culture. What do you think will happen in a scenario where an employee is accidentally duped by a legitimate phishing scam? Will they be inclined to report it, knowing they’ll be punished? Will they even know? Will you, the security team, even know?
We should be encouraging people to learn about security, making security as accessible as possible, by teaching people that they will be targeted and how they can report that to the correct people.
Clicking links and looking at files in emails is a part of legitimate business activity, for example it’s expected for hiring managers to look at the CV of potential candidates for a vacancy within the company.
If someone clicking a link in an email is a huge risk to your business, the problem is your security department, not the unsuspecting employee who clicked the link. Phishing simulation is often a bandaid to cover up the lax security controls that are in place.
<h2>Technical Controls</h2>
This is where having the right security professionals has the most impact, as they can introduce sufficient technical controls to reduce the perceived risk enough that the phishing simulation sales pitches become less desirable.
Here are some simple technical controls you can implement to protect against phishing attacks:
<ul>
 <li>Email filtering - Proofpoint and Mimecast are two popular managed email filtering services. If you’re using the Microsoft Office suite then a more robust alternative might be Defender. These services allow suspicious emails to be filtered to a quarantined environment based on a number of security based filters.</li>
 <li>Multi-Factor Authentication (MFA) - If a user’s credentials are compromised through a phishing attack MFA can prevent unauthorized access by requiring an extra factor during login. Use a strong second factor like an authenticator app or hardware token, email or SMS codes are not as secure.</li>
 <li>URL scanning - The same vendors who provide email filtering usually have an option to replace the URLs within an email with a vendor specific service that scans the link you click on before redirecting you to the intended target. This greatly reduces the risk associated with clicking malicious links. Microsoft Defender for O365 provides a service called Safe Links, which integrates with email, Microsoft Teams, and Microsoft Office apps.</li>
 <li>Browser extension - Extensions like Malwarebytes provide protection against a plethora of security threats while accessing the internet through your web browser, and it works on most modern browsers. Real-time protection can help prevent phishing attacks by blocking malicious websites and scam links.</li>
 <li>DomainKeys Identified Mail (DKIM) - DKIM is a way to sign emails with asymmetric cryptography so the recipient can validate that an email came from a legitimate sender, helping to prevent spoofing.</li>
 <li>Sender Policy Framework (SPF) - SPF allows you to list all the servers in which you will send emails from, a mail server can then validate an email came from a legitimate source to help prevent spoofing.</li>
 <li>Domain-based Message Authentication, Reporting, and Conformance (DMARC) - DMARC is configured on your mail server to decide what happens when DKIM or SPF checks fail in relation to incoming emails. It’s a valuable tool in preventing spoofing.</li>
 <li>Patching - By ensuring your system is up to date with security patches it can help to mitigate some phishing attacks which look to exploit vulnerabilities in out of date browsers and applications.</li>
 <li>Advanced threat detection - In the case of a successful phishing attack, threat detection solutions can help discover anomalies and actions that are indicators of compromise. Automation can help to quarantine that user’s account and limit their access, reducing the blast radius of any successful phishing attack.</li>
 <li>Principle of least privilege (PoLP) - Ensure people only have the minimum required level of access by default, provide a way for users to request additional privileges to carry out tasks in a just-in-time way. Leverage automation to balance security risk mitigation and prevent the introduction of unnecessary bottlenecks.</li>
 <li>Privilege escalation monitoring - Audit any deviations from the minimal viable permissions defined by PoLP, monitor any changes, and alert on anomalies or potential suspicious activity. Consider introducing automation to isolate and restrict permissions where necessary, before findings can be verified by an analyst or engineer.</li>
 <li>Reporting mechanism - Provide a simple user friendly mechanism for people to report suspicious communication, and encourage people to use it. Leverage automation to filter out false positives where possible.</li>
</ul>
<h2>Administrative Controls</h2>
It’s not enough to introduce technical controls, we also need to think about administrative controls and how we operate as a business. These changes will feed into fostering a security culture which will turn your people into assets in the fight against external threats to the business.
Here are some simple administrative controls you can implement to protect against phishing attacks:
<ul>
 <li>Education - A well educated workforce in regards to security will mitigate more threats than any phishing simulation programme. Spend the money you budgeted for phishing simulation in levelling up your workforce, and I’m positive you will see a better return on investment.</li>
 <li>Policy - As a security engineer policy documents can often be seen as the boring side of security, however, some simple well defined rules against sharing credentials or sensitive data via email may help to limit exposure.</li>
 <li>Principle of least privilege (PoLP) - I mentioned PoLP under technical controls, but it’s also a change to ways of working. You can have all the tooling in the world, but we as individuals need to ensure we leverage them and adhere to the principle. As security professionals we should be leading by example.</li>
 <li>Incident response plans - Ensure there are robust multi-layered incident response plans in place, with runbooks and well documented processes to follow.</li>
 <li>Reporting process - When potential phishing emails are reported, make sure to have a well defined process for analysis and creating actions to remediate any issues and mitigate other or future occurrences.</li>
</ul>
<h2>Final Thoughts</h2>
The security controls listed above are not an exhaustive list, but they provide enough examples of areas you should be prioritising over phishing simulation.
It’s important to invest in your people, and when I mentioned security education I’m not referring to an annual compliance training video that can be skipped over, that’s simply another tick box exercise. Put in real time, effort, and resources into upskilling your workforce, make it accessible, fun, and rewarding.
Education likely won’t provide the same level of quantitative data for the metrics which executives like to see go up or down on a report, but your company will be better equipped to deal with phishing attacks in the real world.
Although I’ve targeted phishing simulation in a negative way throughout this post, my real intention is to try and recalibrate its priority in delivering a robust security programme. I believe there is still a time and a place for phishing simulation, but most businesses are simply not ready.
Once the business is in a position where there are robust defences in place, and there is an excellent security culture, it might make sense to introduce phishing simulation as another layer of defence with an opportunity to educate. When the stakes are low, phishing simulation becomes a much more powerful tool.
If your security posture is immature, I would avoid investing in phishing simulation, it should be near the bottom of your list of priorities.

Unfortunately, throwing money at the problem and trying to simulate a phishing attack doesn’t solve any of your problems, it might actually make them worse. People will click links, people will look at attachments, it’s the responsibility of security professionals to ensure their people have all the information they need to make smart decisions, and that you have the technical capabilities in place to ensure any mistakes have minimal impact.

chrisdunne.com

Cyber security articles, AWS security courses, and practical learning resources

Latest Cyber Security Articles