Tools: Budget Friendly Iso27001/soc2 Compliant Environments For Aws

Compliance frameworks are transitioning from a "good to have" to an absolute need to do business with corporate clients.

Fortunately compliance evidence gathering has been automated with countless tools and services. Opensource tools such as Prowler, CISO Assistant or vendors such as Scrut Automation, Sprinto or Vanta have made evidence collection highly accesible.

However, as stated by Databank , achieving compliance in public cloud environments requires substantially more effort, tools, and ongoing management than many organizations initially anticipate. This explains why 83% of enterprise CIOs surveyed by Barclays plan to move at least some public cloud workloads back to private cloud or on-premises infrastructure.

While AWS is both ISO27001 and SOC 2 certified, building the logging, access reviews, and data governance required on top of it becomes operationally expensive without documented procedures and tools. Many companies rely on manual checks and configurations to be compliant, however this creates technical debt that increases manpower costs on remediations as the company and the team grows.

Furthermore for a small company like us, it is unfeasible to pay for enterprise offerings that guarantee AWS compliance. To get both ISO27001 and SOC 2 certified and to align with our value proposal of offering Safe and Compliant Cloud Platforms to our clients, we have developed a budget friendly compliant AWS environment with the following methods and strategies.

Unused VPCs and regions are where attackers usually hide in an AWS account, since they are not as rigorously controlled as production ones. This brings the needs of isolating or removing unused resources, so they can't be used as an attack vector.

If the company is able to do so, the easiest approach to do this is removing the default vpcs all together.

If for some reason this is not possible in the account it can also be achieves by having all default subnets to block all traffic using its NACLs and remove default Security Groups rules.

Quick and dirty with bash or boto3 scripts: This is the easiest one but lacks traceability therefore lays risks when implementing in existing accounts. A simple script can iterate through all subnets and security groups to implement the change.

CloudFormation StackSets: This is the most AWS native approach, creating a CloudFormation stackset that will deploy the stack on all regions enforcing the change. If the company is using AWS Organizations, Stacksets

Source: Dev.to