The intense conversations around Cloud security are growing louder and passionate. Although the industry has been working continuously to develop higher security standards and best practices, the paranoia that an enterprise is only as strong as its weakest link, persists. Often that link is a careless lapse by an employee. Sometimes it could be a significant lack of governance or policy structure.

Security by Design (SbD) is not a new concept but it has gained currency in the wake of new challenges brought about by cloud deployment and the connected world. Nishant Sharma, CTO of Umbrella explains how Security by Design is enabling higher security for enterprise customers.

What is AWS Security by Design?

AWS Security by Design is a conscious effort to incorporate security approaches while designing IT architecture. Security is not an afterthought but must be incorporated from inception at every layer of the AWS architecture—from the perimeter, the host, application, database and the data itself. It comprises policies, best practices and governance structures using AWS services that not only automate the monitoring processes but also prevents attacks and leaks by sending alerts and auto-correction. Automation is a key hallmark of AWS SbD.

Why is Security by Design more relevant in the context of Cloud deployment?

Cloud deployment gives rise to new complexities—deployments in the public network gives rise to unique set of challenges, more vulnerabilities. For example, in a traditional datacentre, securing the perimeter pretty much secured the environment as application usage could be restricted within the enterprise.

However as applications move away from the enterprises, it is exposed to more risks in the public network. Therefore security has to become an intrinsic part of cloud deployment, woven into the fabric of the cloud journey as a basic ingredient. This means security should come into play while designing the architecture and at every decision making point—what kind of architecture; which services to provision at which layers; how to interconnect services; allowing permissions; provisioning alerts and alarms; accessing and transporting data securely; encrypting data at rest;  back-up and fail-over strategies.

As cloud-based applications and infrastructure become more prolific, the need for governance, automated monitoring and best practices at every layer of the IT infrastructure become more pertinent. Today, SbD is not an option but is something we breathe and think in all cloud deployments.

What are the guiding principles of AWS Security by Design approach?

AWS offers a range of services and customers have the flexibility to choose a combination. The flip side of this flexibility is the increased complexity customers have to deal with while implementing services in a secure manner.

But if we adhere to the basic principles of SbD we can mitigate many risk factors by eliminating manual processes, optimizing audit ratification processes by automation.

We have successfully deployed AWS Infrastructure for many customers by following SbD principles. If you examine our deployments, every decision is based on enhancing security and availability of data.

At Umbrella we believe that security must be built at every layer. For example, we recommend the use of a WAF in front of the load balancer to filter web traffic. Next, web server is placed behind a firewall and access to the web application is only through ports 443 and 80. The database layer is placed within a private subnet and can be accessed only from the web server. So we have effectively ensured that every layer is well defined, and segregated with different levels of security layer.

While designing a deployment we always design for failure and availability strategies. For example, we encourage customers to deploy database and servers in multi-AZ mode and use auto-scaling for web servers. Another important aspect related to security is data storage and usage itself for which different options are available. For example, businesses must identify sensitive data and always encrypt sensitive data at rest and in transit. We recommend storing sensitive data in RDS and S3 where encryption services are available. Turning on versioning in S3 and enabling MFA for deletion rights provide added layers of security for sensitive data.

How can one implement Security by Design on AWS?

Umbrella recommends four-phased approach to implement SbD:

Understand your requirements:  Outline your policies, document the controls you inherit from AWS, document the controls you own and operate in the AWS environment and decide what security rules you want to operate in the AWS environment.  

Build a secure environment: Build a secure environment aligned with your requirements and goals, defining appropriate configurations—including encryption requirements, providing permissions, authorizing compute images, enforcing logging and Cloud Trail services. Umbrella also recommend using Cloud Formation Templates which provide comprehensive rules sets and can be enforced.

Enforce the use of templates: Enable Service Catalog and enforce the use of templates in the catalog. For example, we used Cloud Formation for an ecommerce customer for fast deployment and traceability since the business required continuous development. This ensure that when new environments are created, it is secure and adhered to compliance.

Perform validation activities: Perform validation activities through audit automation processes. If you have designed the AWS deployment correctly using Service Catalog and secure environment templates, you will have an audit-ready environment. Using Lambda and Cloud Config allows you to perform validation activity.

What are the benefits of Security by Design?

SbD architecture automates the customer’s assurance, governance and compliance capabilities and creates an enforceable environment. SbD architecture creates functions that cannot be overridden by users; establishes reliable operations controls; enables continuous, real-time auditing; and programmatically manages the governance policy.