Our Promise: You will scale AWS cloud security in your organization if you use 4 of these 6 pillars.

Pillar 1: Empower

Help them do what they can’t

The most important part of improvement program success is increasing the ability of individual engineers to build more secure systems. But it is unrealistic to expect engineers to write great policies or assess access correctly on their own. 

Empower them with:

• Simplified interfaces to AWS security that help them make good decisions with the knowledge in their head
• Productized components that generate secure policies and report access in language they understand
• Training on how to use the security components and execute the control process
• Safe ways to practice using what they’ve learned
• Support configuring components and security advice
• Good documentation, examples, and how-to guides.

Let your engineers practice how to use tools safely and correctly by integrating them into your reference and training applications. Notice what people don’t understand and where they make mistakes to help improve tools so engineers can remediate fast. Then they can try with their own applications. This knowledge and experience is essential for them to operate independently. 

Pillar 2: Support

Provide assistance

Engineers will have questions, and need “permission” to change security controls. Create an environment that encourages adopters to ask questions and get good answers, delivered with a smile. Otherwise your security issues will remain “undiscovered” and unaddressed.

Consider creating a Security Guild in an open group chat channel that develops, supports and encourages your security practices. 

Benefits of a Guild:

• scale the support load
• surface problems with the process, training, and components in an informal way
• identify and document frequently asked questions
• identify topics that need a deeper discussion
• develop & share best practices within your organization
• let people demonstrate the knowledge they’ve gained and lessons they’ve learned
• engineers can get help from people with both formal and informal security responsibilities. 

Once you’ve established a guild, lift relevant private conversations into the guild’s view. This shows everyone the normal day-to-day experience with the process and opens it to improvement.

Pillar 3: Reorganize

Change their space

Security should be every engineer’s job. Make security capabilities available to engineers on-demand by integrating security into their existing workflows and information sources.

Some ways to accomplish this:

• Let engineers pull routine security work to them through normal product delivery processes instead of through special projects.
• Provide libraries that generate secure policies for their infrastructure code and delivery process.
• Display access control information in their existing monitoring dashboard.

Do not force each team’s engineers to figure out how to integrate security on their own. This leads to inconsistent security and wasted effort.

Pillar 4: Reframe

Help them love what they hate

Application and Cloud engineers may not like repeatedly reviewing or improving access at first. The experience is painful because security policies are difficult to write and nearly impossible to validate without breaking something. Therefore, security is often deferred until ‘later’ (like after a breach). It’s essential to motivate individuals to secure access and actually complete the loop.

Here’s How:

• Allow for choice. Completing this security loop is likely a medium-priority task. Agree upon and clearly communicate the priority of this task throughout your organization. If a team isn’t able to complete the task, ask what led to them trading off this security task for something else? Were they overloaded? Was there a problem with a component? Listen to the problems being encountered, then check if this is happening elsewhere.
• Create direct experiences that show the risk of excess permissions in a “game day” exercise. Configure a test environment with a copy of a team’s application. Give participants a set of actions they can execute to exfiltrate or destroy their application’s data. Then let them do it.
• Make it a game. Implementing least privilege can be extremely challenging and you can use this to your advantage. People like challenges, especially engineers. Use a tool to analyze, then score each principal’s access to APIs and data. More points for more access and a multiplier for critical APIs like IAM and data sources. Lowest access scores win, just like golf. Engineers will be shooting for par in no time.

Pillar 5: Advocate

Provide encouragement

Ridicule and praise from our peers and organizational leaders can do more to affect change efforts than any other source. 

This is tough work.

Ensure the right people lead with encouragement, coaching, and accountability.

Praise people’s effort to adopt your improved security processes. Sympathize with their struggles. Encourage their peers to help. Admit when a component is not working well and capture feedback for improvement.

Conversely, sanction negative behaviors that affect the program’s adoption. Call out unhelpful feedback as toxic to the organization and its customers.

Sometimes all you need is a respected individual or team to adopt your change and show securing AWS is possible. Pick your early adopters carefully and help them succeed, then promote that trailblazer’s success to their peers- they will likely model the same change.

Pillar 6: Reward

Change their economy

Security efforts pay off for your company. Reward your team for operating safely and effectively. Treat security improvements as product improvements and recognize the importance of that work. Integrate security into your organization’s economy of measurements and incentives. 

Ensure that positive and negative incentives aren’t undermining security. Both generally and in the operation of your critical control loops.

• Remove disincentives for integrating security into daily work. 
• Reduce friction for getting help and using tools properly.
• Incentivize sparingly. Don’t over-justify security work with special bonuses.
• After finding a security issue, don’t blame or penalize well-intentioned engineers. Instead, show them a better way to complete that task when resolving the issue.
• Create an issue for each team to review their access controls each month. 

If you gamified least privilege, publish a leader board and include the number of completed reviews and improvements.

Report security metrics in your organization’s ‘Ops Reviews’ alongside other key metrics.

A note on accountability:

You can successfully change the way you do security by holding teams accountable to organization-wide standards for delivering work according to its priority.

• Hold security process and component providers accountable. 
• Gather feedback on the process and remove friction. 
• Improve components with weak capabilities or poor usability. 

This makes the process easier to use over time and shows component providers have skin in the game.

Better systems, better outcomes

Go straight to Ch 7, Secure AWS Continuously to learn more about how to scale AWS cloud security in your organization in less than 30 minutes.