paint-brush
AWS for the CISO — What you always wanted to ask but were too afraid ofby@hpant81
1,034 reads
1,034 reads

AWS for the CISO — What you always wanted to ask but were too afraid of

by Himanshu PantNovember 10th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

If you loved technology at one point of time but now are unable to be up to speed on account of management responsibilities -
featured image - AWS for the CISO — What you always wanted to ask but were too afraid of
Himanshu Pant HackerNoon profile picture

We live in a world that has walls and those walls need to be guarded by men with guns. — Aaron Sorkin

If you loved technology at one point of time but now are unable to be up to speed on account of management responsibilities -

If the word “Cloud” (strictly in reference to computing) gives you bouts of paranoia around aspects of security -

If you are evaluating cloud proposals but with a lingering tinge of doubt around the security implications -

Then

Keep calm and read on

During the course of my employment wherein, I am involved in the assessment of cloud migration proposals from solution vendors for a global banking giant, I have noticed that there is still a tinge of insecurity amongst the senior executive around cloud computing. First things first, cloud computing is nothing fundamentally new from the way computing has been done in the past. As per NIST —

Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Five major attributes define a cloud based system viz-

a) On Demand self service

b) Broad network access

c) Resource pooling

d) Rapid elasticity

e) Measurement of service

So as we can see from the above widely accepted definition, there is nothing technically different in cloud computing which differentiates it fundamentally from its predecessor, on-premises computing. In other words, cloud computing is not something as fundamentally different as say quantum computing. So the natural question is — Should we worry more for security, in case of workloads hosted on public cloud ( like AWS) vs on-prem hosted workloads? Like all such questions, the response is also pretty standard — It depends. The reason it depends is that even though the underlying technology has not changed much but the toolchain in use is pretty new, the impact area ( though not due to cloud) is pretty large. This coupled with the fact that any outage to business is now magnified many times in the age of social media and high outreach makes security all the more important now. And as always its easy to pick on the new kid on the block. However, on the other hand providers like AWS have dedicated security teams who are highly specialised in InfoSec. So as a cloud services user, you are not alone.

Before we go further onto AWS stack, let us get a few concepts off the table.

Shared responsibility model

I provide the resources , you do the job !!!

AWS follows a concept called “Shared Responsibility Principle” with respects to security which in essence demarcates the ownership of responsibilities between AWS and the customer. In essence it means -

We ( AWS) are responsible for security OF the cloud.

You(customer) are responsible for security ON the cloud.

A natural extension to the above philosophy is that the higher a customer goes in AWS stack towards managed services , more of security aspects will fall on the plate of AWS ( obviously with more cost implications). So in case of IaaS offering ( EC2 for example) , the user will be responsible for OS upgradation , security patching whereas for FaaS( Lambda for example) , he need not worry about these bits.

Levels of management in AWS

In all scenarios , there is a bare minimum set of security which lies with AWS at all times. This includes aspects like physical security of the underlying AWS managed infrastructure from threats like natural calamities , man made incidents , technical failures . Right from site selection of data centre( read region/Availability Zone) to staff access is controlled by AWS with well defined policies.

Principle of Least privilege

One important tenet of security is giving the least possible privilege required to do the given task to any user/process/task .

AWS implements this principle in a very elegant manner by way of Identity and Access Management( IAM)service .

Detective Controls

These controls are used to identify various vulnerabilities in the architecture. It involves inventory management of all active / dormant assets in the account. Some common mechanisms used are — log analysis , integrating audit controls with day to day workflows. AWS provides a range of services for detecting potential security weaknesses in the architecture. AWS also provides guidelines to customer for a focussed audit.

Defence in depth

Defence in depth as the name implies is an IT security concept wherein multiple layers of security are deployed to protect the asset.

Penetration testing

AWS allows customers to carry out penetration testing. However it expects a prior notice to be given so as to ensure no inadvertent impact to their other customers who may be sharing the resources. The request for the same can be raised by logging in via root account.

Encryption

As per wikipedia

Encryption is the process of encoding a message or information in such a way that only authorised parties can access it and those who are not authorised cannot. Encryption does not itself prevent interference, but denies the intelligible content to a would-be interceptor. In an encryption scheme, the intended information or message, referred to as plaintext, is encrypted using an encryption algorithm — a cipher — generating ciphertext that can be read only if decrypted.

With so much of data passing and stored in cloud , the importance of encryption can not be emphasised any more.

These are a few of my favourite things…

🎶🎶🎶 Controlled security groups, sensible IAM use. MFA on root account and CloudTrail logging — These are a few of my favourite things 🎶🎶🎶

Playing on the generic security concepts mentioned above , the next natural question is — how are these implemented in AWS ? Well the answer, like all things tech , is quite comprehensive. AWS has a gamut of services which can be used to ensure security and compliance. Below is a brief run down of few of them and the role they play in securing your architecture. Given the way cloud computing is innovating at a rapid pace , more and better services in future are inevitable.

AWS console has a dedicated section for security and compliance. However there are some services marked under other heads which particularly intrigue me for security handling.

Security services umbrella of AWS

IAM (Identity and access management)

This service is used to create users , groups , policies and roles via which access can be given to the AWS account. On account opening , there is an all-powerful root user account which as a best practice should not be used for day to day purposes. With this constraint , how do we have more users access the account on-need basis ? Well IAM is your man(or woman) for the job. The users created out of IAM can be given fine grained access controls to the various AWS services on need basis. Users can be aggregated into groups based on common attributes. This eases the administration of access rights. User defined policies can be created to create fine tuned specific policies.Roles is a unique IAM entity which is used to grant access to other AWS entities. For example if an EC2 instance requires access to S3 , then the EC2 instance can be invoked mapped to the specific role which has S3 access. Role can also be used to provide cross-account access. Existing on-premises credentials can also be used by way of federation.

VPC (Virtual Private Cloud)

Though tagged under networking head in all AWS reference literature, VPC (and its associated features) act as a very powerful way to control access to the estate. By way of efficient subnetting one can demarcate his IT resources based on the sensitivity of their processing. Not only does VPC cover preventive aspects of security but it also covers the detective measures by way of flow logs. Flow logs are used to capture any incoming/outgoing traffic of the VPC. Security groups are used to control access to the resources at a level of protocol , port and source IP. These are just a few of the security aspects which VPC provides. No wonder this is one the most frequently used service for securing the estate.

CloudFormation

CloudFormation is AWS’s interpretation of Infrastructure as a Code. Critics may say that this comes under the umbrella of management tools but a well made secure template is a sure hit recipe for a replicable safe architecture. An automated version controlled environment also has a less chance of having vulnerabilities due to manual oversight.

Web Application Firewall ( WAF) and Shield

Security group was mentioned previously as a feature to control access to the system. Security group however does not do any packet inspection. So a security group would let a malicious data packet enter the system as long as it originating from a permitted IP address and coming in via an accepted protocol. WAF provides the next level of security ( Defence in depth anyone) wherein it inspects the incoming package for malicious content. It provides protection on various aspects like source IP , packet content ( SQL injection, cross site scripting) to name a few.

Shield is used to protect the account from DDoS attacks. There are two variants of AWS Shield — Standard and Advanced. Standard version is offered to all customers by default. Advanced variant can be invoked on demand.

CloudHSM

Organisations with strict security need driven by either business or regulators use hardware security module to manage their cryptographic keys. Hardware security modules as the name implies are dedicated hardware which is used to provide extra security. Since it is a dedicated piece of hardware , it handles security related aspects to a very high grade of efficiency.CloudHSM provides the same facility for users operating in AWS plane. Users with less stringent security needs can opt in for KMS ( Key Management Service) which is multi-tenant.

Trusted Advisor

AWS provides a resource which can be used to run tests over the AWS account to measure up the account against the heads of cost optimisation, performance, security, fault tolerance and service limits. These tests look up for common issues and informs the customer of the same.

CloudTrail and CloudWatch

CloudTrail is used to monitor all API calls so that any suspicious invocation can be flagged off. The logging which is done by this service can be used for audit/compliance purposes.

Any logging of activity becomes all the more useful when accompanied with a robust notification system. CloudWatch fulfils this role with aplomb by giving user access to dashboards, billing alarms , logs and metrics for his entire AWS account.

Config

Config allows to keep a track of the configuration of all resources in a given AWS account. It also allows any changes in the account to be tracked. By way of AWS Lambda ( serverless service) any change in configuration can be checked against compliance needs to ensure they are in order.

To summarise, AWS has a wide range of services aimed at providing security to its clients. The above mentioned list is just a small list out of the same. The computing paradigm is evolving and so are the services ( its feature sets and prices). Rather than standing in the sidelines and panicking ad-infinitum, customers should take small measure steps to get the immense benefit of cloud.