Decision tree for adopting an AWS security service
The following image shows a decision tree that you can use to evaluate whether your organization should adopt an AWS security service. The decision tree is divided into two sections: Company context and AWS security service evaluation. The first section, Company context, is designed to evaluate your current control or solution, if it exists. You proceed to the second section, AWS security service evaluation, if you don't have a current solution or if your current control or solution doesn't meet your business or technical requirements. In the AWS security service evaluation section, you determine whether the AWS service meets those requirements.
Company context for evaluating a current security control or solution
In this section, you evaluate your current control or solution to make sure that it meets your organization's business and technical requirements. If you don't have a control or solution in place, you should evaluate the AWS security service and skip directly to the AWS security service evaluation section.
1.1 Is a compliance, security, or privacy mandate not attended?
Organizations are under the scope of laws and regulations regarding data security and privacy. Any violations of these mandates can result in severe consequences. If your company is unable to meet a compliance, security, or privacy requirement, you should evaluate the AWS security service.
1.2 Do you have a high risk that is not addressed?
Organizations need to identify and manage significant security risks in their environment. A high risk could involve potential data breaches, system vulnerabilities, operational disruptions, or other critical security concerns. If your current solution (or absence of it) is not adequately mitigating these high risks, proceed with evaluating the AWS security service.
1.3 Do you have a manual or error-prone solution?
Solutions that require manual steps or human interaction are more error prone. Inconsistency, low data reliability, noncompliant assets, and lack of scalability are common in these scenarios. Automated controls are fundamentally important for IT systems and workloads. If your current solution does not support full automation, consider evaluating the AWS security service.
1.4 Do you face management, agility, or scalability issues?
It is important to map any problem related to management. The following are some examples: Lack of compatibility managing different assets, the solution does not cover all devices, errors and disruptions during updates, and negative performance impact in production. The solution must offer agility so that teams can innovate from a strong security posture. You must support scalability to achieve exponential business growth. If you have any management, availability, or scaling issues, you should evaluate the AWS security service.
1.5 Do you have a high total cost of ownership?
Evaluate the total cost of ownership (TCO) for your current security solution by comparing costs against industry benchmarks and internal metrics. Generally, organizations invest 6–14% of their IT budget in cybersecurity, and 10% is the average. Consider factors such as licensing, implementation, maintenance, support, and operational costs for protecting your assets. You can include your internal tools that cover the same number of assets to be protected. An unbalanced security budget for tools can also indicate a high TCO, such as if 60% of the budget is directed to a single tool. If your TCO is higher than these benchmarks, proceed with evaluating the AWS security service.
AWS security service evaluation
A proof of technology (POT) is similar to a proof of concept. The goal of a POT is to determine whether a potential solution to a technical problem is viable. For example, you might use a POT to prove that a specific configuration can achieve a certain outcome. In this section, you use a POT to evaluate and demonstrate whether a given AWS security service meets your business and technical requirements.
The AWS Security Reference Architecture (AWS SRA) provides prescriptive guidance for deploying the full complement of AWS security services in a multi-account environment. This architecture can help you plan and execute your POT evaluation.
This decision guide applies to all AWS security services, including the latest
offerings. For an up-to-date list of services and current best practices, see AWS Cloud Security
2.1 Does the AWS security service address your compliance, security, or privacy mandates?
The AWS security service must address any compliance, security, and privacy mandates that the current solution does not address. You can find AWS certifications and reports for security and compliance in AWS Artifact. In addition, you can use the AWS service documentation for coverage validation.
2.2 Does the AWS security service help mitigate risk?
Risk management is a key factor to help protect companies against many threats. The decision to adopt a service might be directly connected with mitigating one or more high risks in your organization. The AWS security service must mitigate the risk to an acceptable level, based on your risk appetite and business context.
2.3 Does the POT show effectiveness of the security service?
The effectiveness of the AWS security service must be demonstrated through a POT, according to different metrics of each security service. For example, the POT might validate that the service can detect and respond to security threats quickly through a threat intelligence algorithm. You might evaluate success by confirming that threats where detected within minutes and that automated notifications and remediations ran successfully. For a vulnerability management service, you might evaluate effectiveness based on the following:
-
How many vulnerabilities were detected?
-
What is the success rate of applying patches and updates?
-
For web protection, were cross-site scripting (XSS) and SQL-injection attacks performed by the offensive security team (also known as the red team) immediately blocked?
AWS Professional
Services
2.4 Is the TCO lower than the current control or solution?
Lower TCO can help you optimize costs in your organization. Some common metrics
used in these comparisons are: acquisition and implementation costs, fixed and
variable expenses, operation costs, maintenance and support costs, expansion and
reliability costs, and training costs. There are other cost measurements and
comparisons that you can perform based on your specific use case. The AWS Pricing Calculator
2.5 Trade-off decision
The trade-off decision requires balancing multiple factors, particularly service effectiveness and TCO considerations. When exact calculations or clear-cut determinations aren't possible, evaluate the overall balance of benefits and limitations.
A positive balance might emerge even when factors seem to conflict. For example, a service might increase costs but provide enhanced scalability. This represents a positive balance where the improved effectiveness justifies the additional costs. Conversely, a reduction in capabilities might not be acceptable even if a service offers significant cost savings.
You should balance all available information to determine an overall positive or negative outcome. Based on this analysis, you can make your trade-off decision.
