Above all other security advice for enterprises working with Amazon Web Services (AWS), there is one resounding war cry: “Go to WAR.” WAR is an acronym meaning Well-Architected Review. It’s a powerful and proactive way to mitigate real risk with the AWS team and its partners. If you’re using AWS (or thinking about it) consider adding WAR to your security arsenal. It’s a well-kept secret starting to proliferate in the cloud industry for reasons you will find obvious after reading this article.
When it comes to cloud environments, a common term that is often heard and used across all cloud service providers (CSPs) is “shared responsibility model.” This model most often dictates terms of Master Service Agreement with any potential CSP, be it a Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) model. The goal is to clearly identify and establish the security responsibilities that are shared between a CSP and cloud consumer.
As security experts, Wallarm advocates for the shared responsibility model. It is impossible for a cloud provider to provide 100% security for you, like in securing your customer’s data and access (you can see this in the AWS shared security model below). There are also enormous benefits to application and API security to having both the CSP and cloud consumer putting up a strong defense. All customers on AWS and other cloud infrastructures should be proactive agents in their cloud security. (See Securing Apps on AWS with Wallarm.)
This visual image depicts how shared responsibility is distributed:
AWS Developed the Well-Architected Framework to help cloud architects build secure, high-performing, resilient and efficient infrastructure for their applications. Based on five pillars—operational excellence, security, reliability, performance efficiency and cost optimization—the framework provides a consistent approach for customers and partners to evaluate architectures and implement designs that will scale over time.
AWS’s Well-Architected Framework approach is built on the shared responsibility model that helps consumers and providers truly understand their portion of responsibilities, as outlined in the figure below.
The framework was intended to be far more than an architected tool for AWS. It was designed as a sort of way of life and method of looking at your architecture to ensure resilient and consistent outcomes.
The Well-Architected Framework is a living set of best practices that AWS continuously updates. Every time you think about starting something new or changing something, use the five pillars to evaluate what you are proposing. This is where WAR comes in.
The WAR is a systematic approach to review your architecture—whether already in AWS, on-prem or even in other cloud providers. WAR is currently a set of 46 questions, which could shift in number since this is a living methodology. It is aligned to the five pillars mentioned:
Answering WAR questions helps identify which areas fall into three categories:
Critical issues should be remediated immediately. These are things such as not using multi-factor for your accounts or exposing data to the public. Need Improvement items should be looked at over a three to six month time period.
AWS recommends that you perform these reviews periodically (at least every six to 12 months) on each critical workload. Even items that are deemed Well-Architected today can change due to changes in your environment or new options that replace the way you are doing things today.
There are two key factors that must be considered before you think about conducting WAR on AWS:
We are going to look at some example cases on what combination of factors should encourage you to wage WAR, or not.
Case 1: Highly complex architecture and expert skill set.
If you have a highly complex architecture and an expert skill set, a hybrid approach is recommended.
Meeting with an AWS representative at least once can be very helpful to pinpoint small, important things that are easily overlooked. For example, a focus on the business logic based infrastructure might obscure your view of a Critical Issue.
After the initial WAR exercise and importing the results within the AWS console, you could get away with repeating the same process internally with your highly skilled staff. Frequency of WARs depend on what you discover and the amount of resources available to you internally.
Case 2: Highly complex architecture and novice skill set.
When you are handling a highly complex architecture and do not have the bandwidth to understand the different pillars of the Well-Architected Framework, look for external help. Negotiating a good price with an AWS partner, is the best approach.
Cost concerns shouldn’t stop you from a WAR. The cost savings coming from a Well-Architected Review may justify the additional costs involved in engaging with an AWS partner consultant.
Case 3: Less complex architecture and novice skill set.
If you are fairly new to AWS and the complexity of your architecture is not too high, it is recommended to engage directly with AWS team. A WAR will help you understand how to handle disaster recovery, redundancy, failovers, etc. that are usually not taken into account with new teams.
Case 4: Less complex architecture and expert skill set.
The only case when a do-it-yourself (DIY) approach is viable (yet optional) is when you have a low level or architectural complexity and expert level skill.
For a DIY WAR, you can use the AWS Well-Architected Tool, released in November of 2018, along with a user guide. Review the Well Architected Framework whitepaper and refer to the questions and best practices to conduct the review yourself.
The Well-Architected Tool is already part of your AWS Console. It’s incredibly easy to use. There are great instructions and videos for each question.
Getting to know all the pillars by navigating the AWS resources is highly recommended.
The process of WAR is simple and not as tedious as you may worry. It starts with a questionnaire-based review. The review usually takes a couple of hours and is relatively painless. Whether you do it yourself, appoint an AWS partner or engage directly with the AWS team of experts, you will use the Well-Architected Tool to go through the 46 questions. At the end of the initial session, you can expect to gain a decent understanding of your current architecture and a very detailed report breaking down the Critical Issues and Need Improvement areas into actionable steps for improvement. Outside a DIY approach, you are likely to receive a detailed report identifying the gaps in all five pillars of WAR.
Amazon is known for its fundamental principle of customer delight. This philosophy really comes alive with WAR as AWS representatives work with customers to help mitigate findings after a WAR. Often times, companies can obtain credit from AWS to fix critical issues identified during WAR. War can be done in multiple iterations, especially if several critical workloads are identified and taken into the scope of WAR.
Each customer knows their business and what’s critical to their operations. That might be your customer portal processing all your orders. It might be the supply chain system driving your manufacturing processes. It might be your case management system used to ensure client work gets completed on time. The critical workload is what you identify as most critical to your operations for running, changing or growing your business.
AWS means it when they say “put on various lenses.” The WAR process is an ever-evolving process. AWS has expanded the WAR for some very specific use cases. AWS calls these “lenses”:
Each lens area is changing quickly and has different architecture best practices. This is a strong reason why relying exclusively on a CSP for cloud security is never a good idea. A constantly evolving threat landscape makes it critical to understand the necessity of shared responsibilities and what is at stake.
For the sake of understanding, let’s focus on one of the lenses: serverless.
Serverless computing assumes the provider runs the code provided by the customer while completely taking care of the infrastructure and the environment itself. Serverless providers offer what is known as function as a service (FaaS) platforms. FaaS platforms execute code for the application logic, but remain completely stateless themselves, meaning they do not store data. AWS Lambda is the oldest and the most popular public cloud infrastructure serverless computing offering.
Serverless lens reduces the attack surface. Because AWS takes the infrastructure concerns on itself in their entirety, there is no need to harden EC2 operating systems and configuring container. Also, because there are no data or state exposure to the data, compromise is limited.
What still need securing are the APIs to and from the functional computing and access control, including authentication. To secure these vulnerable areas, runtime tools—such as Wallarm’s AI-powered solutions—can enable serverless API security and apply the well-known Defense in Depth strategy.
To augment WAR process with actionable application security steps and strong granular authentication practices, we recommend:
DAST: Dynamic Application Security Testing. DEV: Developer.
WAF: Web Application Firewall. SEC: Security.
FAST: Framework for Application Security Testing. OPS: Operations.
CI/CD: Continuous Integration/Continuous Testing.
The AWS Well-Architected Framework will provide strategies to help you compare your workload against the best practices recommended in this article. It can also help you get guidance on producing stable and efficient systems, so you can focus on functional requirements and overall business.
Start learning about WAR by downloading the AWS Well-Architected Framework whitepaper. If there is one thing you must do to best understand and operationalize your shared responsibility with your CSP, is to perform a WAR.
Everyone knew HashiCorp was attempting to find a buyer. Few suspected it would be IBM.
Embrace revealed today it is adding support for open source OpenTelemetry agent software to its software development kits (SDKs) that…
The data used to train AI models needs to reflect the production environments where applications are deployed.
Looking for a DevOps job? Look at these openings at NBC Universal, BAE, UBS, and other companies with three-letter abbreviations.
Tricentis is adding AI assistants to make it simpler for DevOps teams to create tests.