Security Fundamentals for the Cloud

Security is the practice of protecting valuable assets. When we talk about information security, cyber security is actually just a subset of this discipline. Cybersecurity is focused on protecting digital related devices – like networks, systems and digital information. Focus on stopping unauthorised access, malicious actions like theft, destruction or alteration or simply disrupting the service.

One of the most popular models for thinking about information security is the CIA triad.

Confidentiality, Integrity and Availability. 

Threats can come in many different forms. The tables below provide some a variety and most interestingly also explore what part of the Triad is impacted.   

So, working with the security lifecycle model we can determine what actions we can take at each stage to deliver a robust security infrastructure within our organisation. 

• Prevention
• Identify assets – what devices are you using? Are they contemporary? Can you flash newer firmware on them, is it still supported for software updates?
• Assess vulnerabilities – is your firewall stateless? What ports are open that shouldn’t be? Why does no one lock the backdoor?
• Implement countermeasures – in the context of the cloud, this will be about improving protections across layers.
  
  
• Detection
• Monitor your service – unprecedented traffic? Too many password attempts? 
• Detect issues – CPU’s and network running slow, is it potentially running a botnet or a trojan miner?
  
  
• Response
• Respond to issues - use DevOps principles.
• Restore operations – vital to business resilience and continuity.
  
  
• Analysis
• Analyse issues – what do we need to learn to stop a further occurrence?
• Update policies and procedures – establish best practice, build pro-active culture in your organisation.

A further layer within the security lifecycle are security controls. These are  categorised above – between physical, technical and administrative tools. This is a tool to further break down our thinking about necessary security processes.

We will be taking a look at each stage of the security lifecycle, starting with prevention. We start with preventative measures as they are the most pro-active stage, they are what stops threats before they occur. 

There are three main tasks undertaken during the prevention phase of the security lifecycle;

• Identify assets to be protected.

In AWS we can use a tool called the AWS Systems Manager to provide a catalogue of our resources. However, in a traditional IT architecture we would want to have an inventory of all assets in our system, such as network devices, networks, servers and software.

• Assess asset vulnerability.

What software needs to be updated for security fixes? What are the end dates for security fixes for your operating system? What are the weaknesses in your network? What hardware is available for members of the public to tamper with (USB ports on laptops/desktops?). Keep up to date with common types of threat using industry recognised websites such as US Govt funded Common Vulnerabilities and Exposures (CVE) website.

• Implement countermeasures.

Current industry best practice is to use a use a layered security prevention strategy. This means tightening up security at every layer possible. Below you can see the AWS model and the Zero-Trust Microsoft model. As we’re working with an AWS curriculum and AWS, we will discuss their model, however it’s still useful to be aware of  major competitor’s model.

An effective security prevention strategy provides protection through multiple layers, which implement the following:

• Network hardening measures

Network hardening means bring to bear configurations and an architectural posture with work towards preventative measures to secure the integrity of our network infrastructure. These are to minimise threats even if an attack hasn’t taken place. Threats can be anything that exposes, alters our network or gains unauthorised access into our network.

The first step an attacker will take is try to discover as much as possible about our network. This will use network mapping, port scanning and traffic sniffing. Tools used by malicious actors typically involved ping, traceroute along with software like Nmap and Wireshark to uncover our networks.

Small steps we can take is turn off ICMP or SNMP protocol rules on our severs, at least to the outside internet! (ie. we’d still be able to ping them from within our VPC!). Encrypt any data transited outside our network and ensuring things like promiscuous mode is turned off on our NICs. Luckily Amazon has its own built-in tool to advise of any potential vulnerabilities called Amazon Inspector, assigning severity levels depending on current network rules.  

We can however still harden our network still by using subnets with NACLs and adding intrusion prevention systems with network firewalls. Firewalls in a traditional infrastructure would operate in the transport and application layers, whilst in AWS this takes place in subnet network ACL’s and the VPC security groups. 

• System hardening measures

Every decision must also be balanced with the usability of the system, however you must still make things robust enough that your configuration rules can prevent any malicious tampering of your system. Establish a security baseline, ensure your OS is up to date and push updates across your network with urgency. Remove bloat or unused software or services as they can poise a potential security risk with no purpose. System hardening refers to the host level and so means laptops/desktops, servers and anything that runs services, applications or store data. We also therefore need to apply system hardening to our mobile devices, with the expectation being to use a Mobile device management (MDM) to also imbed your own organisations corporate and security policies. Due to the vulnerability of social engineering (phishing being the most widely commonplace) driving cultural change within an organisation is often one of the biggest determining factors of the success of a security policy.

• Data security controls

Encryption protects the confidentiality of data. It is vital for data at rest or in motion, not to be left as cleartext (without the need to be decrypted with a cipher) whenever possible to ensure security. Data can be in several different states.

Because data can be in different states, it’s also sensible to apply different kinds of encryption depending on the data state. For data at rest we might use BitLocker or for data in motion, we might use Kerberos.

Encryption broadly has three types: symmetric, asymmetric, and hybrid. Hybrid is widely used in internet communication protocols such as the TLS/SSL protocol. But even within these protocols, when data is exchanged explicitly, TLS and SSL will use symmetric encryption. To further establish the security triad, it is encouraged to make use the hashing function to check the integrity of our data.

Building again on the principle of least privilege, we need to think about permissions. Permissions determine how and who can access a resource – be it data or an application. We will now look briefly into two of the major models of how this operates;

User Access (Access Control Lists, ACL)

The ACL is simply a list. The ACL can be a list of users, or a list of groups with users within. With this list, the ACL determines what resources and operations each user/group can access on the list. AWS uses the AWS Identity and Access Management (IAM) service to control access to resources in this format.

Discretionary Access Control (DAC)

This is an identity-based model and permissions are granted by the owner of the resources. Resources have owners and users, it’s the owner who has the discretion to grant read or write access to these resources. 

 • Identity management

Public key infrastructure (PKI) is what outlines the principles and mechanisms that we use when we protect resources using keys and digital certificates. A certificate authority (CA) will issue a digital certificate with serves as an electronic credential that verifies the online identity of many kinds of online entity, they can be an individual, organisation or a computer. The CA signs these off, however if you wanted to issue certificates for usage within an intranet system, we can also self-sign a certificate. 

• Secure Sockets Layer (SSL)/ Transport Layer Security (TLS): SSL/TLS certificates are used to achieve a secure client/server connection over the internet. The CA issues the SSL cert and this cert uses a key pair (public and private) unique to the entity which has had the certificate issued.

• Code signing: This uses digital certificates to ensure that the source of any data is legitimate by having it been signed by a private key. The then public key and verify the identity of the source by using the certificate’s public key.

Identity management is one of the most vital areas of security. Good identity management means that the CIA triad is fulfilled. It is also fundamental to ensuring security whilst allowing the availability organisations require. 

Authentication factors diagram:

Best practice in an identity management solution will encourage strict password controls, use of password managers, single sign-on functionality with federated identity management (single login for several services).

The AWS IAM is a service used to control access to AWS resources. We’re able to access IAM with e-mail/password, access and secret access keys, MFA and key pairs. Within IAM we can also have users and groups, with the ability to assign roles. These assigned roles dictate what permissions they can action.

IAM definitions we need to know;

• Entities, can be user, group, role or even an AWS service.

• Principal, any entity that has been given a policy (permissions).

• Role, this is an identity which can be used by entities. 

We also need to know how permissions operate. Along with being determined using JSON (diagram below), it’s permissions work on a DENY ALLOW DENY basis. This means if a IAM is assigned a policy which is linked to permissions;

DENY - If no permissions are outlined, it automatically denies the permission.

ALLOW – If access is explicitly indicated, it will allow access.

DENY – If permission is explicitly declined, it will deny access and take priority over the allow rule.

Now we move onto the detection part of our Security Domain. As expected, we rely on Antivirus software to help prevent, remove and find malware on computer systems. The way Antivirus software does this is by using known malware signatures to locate threats on a computer memory or file system. Malware is simply an application with malicious intent, it will be used to taper with any one of the CIA triad elements: confidentiality, integrity, or availability. 

Malware can infect a system in various different ways, the infographic below shows a few: 

It is now common place for organisations to use an intrusion detection system (IDS). IDS will detect attacks with two approaches: 

AWS Cloud uses a service called GuardDuty to continuously monitor your AWS account, below you can see their infographic showing how this service broadly works.

CloudTrail is a further AWS service with a security focus, below you can see their infographic showing how this service broadly works.

AWS Config is an AWS service which takes cares of a lot of the accounting function of security. AWS Config will track resource configuration changes, show compliance, spot and troubleshoot security vulnerabilities.

What’s very cool is you can set up the AWS Simple Notification Service (SNS) and receive communication whenever any resource is created, modified, or deleted.

Planning for disaster is crucial for business. This means having business continuity plan (BCP) and disaster recovery plan (DRP) in place for when the worst happens.

It also helps for us to further understand the distinctions between recovery time objective (RTO) and recovery point objective (RPO).

The main focus of the recovery point objective (RPO) is data.

• How much data can the business lose before the business suffers?
• How much time between data backups can elapse without causing severe harm if an incident occurs?

This is a balance dependent on how much time can pass between each data backup.  

Whilst the recovery time objective (RTO) represents the period of time a business can sustain downtime before affecting business continuity. The sooner a business must be up and running, the more expensive it will be to restart.

Security analysis allows organisations to ultimately improve their security conditions. This means that accounting, testing and monitoring all build towards a more information perspective on our security poster. Using Root Cause Analysis (RCA) allows us to be identity the origin of breaches in the system and provides insights to where things can be improved. RCA will often be informed by documents such as post-mortem incident reports which is completed by involved individuals. 

Best practice also dictates that organisations should have a well-defined monitoring policy. This means a clear policy on what, who, when, and how monitoring will be performed.

Now for an AWS blurb on monitoring services + AWS Trusted Advisor:

• Amazon CloudWatch monitors resources and applications in the AWS Cloud and on-premises. 
• AWS Config records and evaluates configurations of your AWS resources.
• Amazon Managed Service for Prometheus provides highly available, secure, and managed monitoring for your containers.
• Amazon GuardDuty protects your AWS accounts with intelligent threat detection.
• Amazon Macie is a fully managed data security and data privacy service

Trusted Advisor is an online tool that provides real-time recommendations to help you provision, optimize, and secure your resources by following AWS best practices. 

Examples of Trusted Advisor security checks and advice include the following: 

• Making sure that security groups do not keep ports open with unrestricted access
• Checking for your use of IAM permissions to control access to AWS resources
• Checking the root account and warning if MFA is not activated
• Checking that S3 buckets do not have open access permissions

AWS promotes best practice around ensuring that the AWS account root user is well protected as it has full administrator access. Never give the root user credentials to anyone and always delete the AWS account’s root user access keys after login. Use AWS IAM to make accounts for each individual in your organisation, always secure with MFA and make use of AWS CloudTrail to collect usage and resource cost in your AWS account.

We also need to think about compliance. Compliance of the cloud is the responsibility of AWS, however within the Cloud it’s the organisations responsibility. Because of this spilt responsibility, cloud services are often considered a shared responsibility model as demonstrated in the diagrams below. AWS supports over 140 different security and compliance standards globally.