AWS Security Guardian: Some Realistic Hurdles to Go Through

Note: Views in this article are my own and do not represent those of my employer or affiliates.

As skill shortages continue in the area of cybersecurity, especially for those who are cloud (native) technology savvy, AWS recently shared their practices of leveraging "Security Guardian", a program that has proven its efficacy in improving delivery velocity while ensuring a greater level of confidence in security risk management.

On its own, many people in the security community may find Security Guardian similar to another long-standing arrangement of "Security Champion". By unveiling the rationale, structure, and implementation of Security Guardian, this article tells a good story about what has evolved at Amazon to improve the scalability of security-related decision-making and covers other good points about high-level life cycles of security engagement including threat modelling and testing. It is worth a read.

Before the existence of the notion of Security Guardian, I previously led the effort to embed Application Security (AppSec) function in the delivery squads. From that experience, there are three key considerations that I would like to share with those who plan to practice Security Guardian in their digital projects. In some circumstances, these things could become the hurdle that prevents your structure from functioning. A thorough understanding and well-prepared plan will be of great value.

1. Having a Security Guardian does not mean that more tools are required, but rather leads to better use of the tools

More often than not, your Security Guardian has a warm engineering heart, passionate about turning on various tools relating to application security. For example, AWS Code Guru for code review; Inspector for vulnerability management; Config for configuration drift detection; Security Hub for security posture management. Then, all the findings from them flood your issue management system, such as Jira or ServiceNow. Receiving all those findings without a proper strategy to triage, classify and prioritise issues will be a nightmare for delivery squads, going the wrong way in improving the velocity. Why? It is simple: These are all great tools but without efforts in tuning the findings, they produce a great number of false positives that flood an already-squeezed delivery sprint.

My advice: turn on a new tool only after you have the right process to harness all findings, those of real values to your team; something your Security Guardian should be able to help.

2. A Security Guardian does not automatically remove your Cyber assurance's presence. It is about continuous confidence-building with full transparency

After appointing Security Guardians to your squads, some project leads may think, "Hooray! No more security reviews from Cyber". Unfortunately, that is untrue. Cyber assurance is irreplaceable in identifying threats, defining security testing, and more importantly the final evaluation of your program's risk posture. The outcome of Cyber's assurance becomes the input to business sign-off: whether or not a product or service is safe to be released. Having well-functioning Security Guardians should mitigate residual risks during delivery, and accelerate risk reduction activities, all leading to greater confidence from your Cyber Team. Security Guardians are not replacements for your Cyber Team. Instead, they make your Cyber Team more comfortable in gateway procedures. As the confidence level increases from Cyber, you will find things become easier.

My advice: make all data points available to your Cyber team, whether it be the dashboard or summary of security findings and remediations, treating them with full transparency to aim at an increased level of confidence.

3. A Security Guardian should feel comfortable with advising "How to" instead of "Not to"

Security Guardians are more useful when they can provide concrete action plans to fix an issue. Traditionally, many cyber practitioners suffer a reputation for not holding a "can-do" attitude. Engineers complain about Cyber not being able to be constructive about how to implement changes to make things more secure. This is not necessarily Cyber's fault. How do you expect someone who has not written application or infrastructure code to tell you specific things to do, at a code or service configuration level? Security Guardians should not have the same issue. They inherit the real-life experiences of a technical practitioner: an application developer, a DevOps engineer, or a test automation engineer.

My advice: let your Security Guardians wear their engineering hats when it comes to fixing things. Ask them to stop telling you "No", and start saying "Yes, but...".