In recent years cloud technology has exploded into the mainstream, big players such as Microsoft with Azure and Amazon with their AWS platform have made it easier than ever for IT departments and infrastructure specialists to provision environments at the click of a button.
Gone are the days when support specialists had to physically install hardware to upgrade a server’s memory or hard drive capacity. Servers can now be upgraded by amending configuration settings through web interfaces with almost immediate effect. Environments can scale on-demand to deal with surges in website traffic or database growth.
It’s easy to see the benefits of cloud computing but there are still some security concerns that might be holding you back from enjoying the full range of advantages that it brings. In this article, aimed at infrastructure and support professionals, we detail 10 security tips that you can apply to make your Amazon Web Services implementation more secure.
For reference, here are the 10 tips we’ll be discussing:
- Secure your root account and credentials
- Create Restrictive Firewall Policies
- Monitor Your Instances
- Encrypt Sensitive Data
- Multi-Factor Authentication
- Keep patches up-to-date
- Host Based Intrusion Prevention Systems
- Conduct Vulnerability Assessments
- Penetration Testing
- Extra Tips!
Tip #1 Secure your root account and credentials
It goes without saying that one of the biggest concerns in a cloud environment (and for most IT systems for that matter) is the safe of login and root credentials. A hacker that obtains access to shared access tokens or credentials can take control of your entire cloud infrastructure and bring your business to a halt. Using your credentials, hackers can delete or steal your data, run or install malicious software such as a virus, they could even configure their own cloud infrastructure on your account!
With the upsurge in cryptocurrency, hackers are looking for cloud servers to compromise and install software that performs the required number crunching to mines for currencies such as Bitcoin – effectively stealing CPU cycles!
To mitigate the possibility of such things happening you can delete root account keys for everyone except key business users and create Identity and Access Management (IAM) admin users instead. You can also look towards enabling multi-factor authentication (MFA) to further protect your accounts.
Other points to consider:
- Use a strong password of more than 10 characters for the root account
- Enable strong password policies with password expiration for IAM users
- Do not create AWS access keys unless needed
- Never hard-code access keys in code which can end up being committed to public repositories
- Never send AWS credentials over email
Tip#2 Create Restrictive Firewall Policies
A firewall should be one of your basic lines of defense when it comes to securing your AWS infrastructure. In the context of Amazon Web Services, the firewall is implemented outside of the instance and is controlled using your AWS credentials.
The ensures that you have a basic firewall policy in place even if the operating system instance is hacked or compromised.
In Amazon Web Services, Security Groups act as a mandatory whitelisting firewall. These allow you to control the flow of incoming and outgoing traffic which helps secure your infrastructure from hackers.
Try to restrict access and allow only certain network ranges, ports and protocols when possible. It’s also important to monitor and delete security groups that you’re not using and remember to audit them periodically.
In addition to filtering by IP address of protocol such as www, SSH and so on, AWS allows you to open a port to another Security Group in the same AWS Region.
Download Our Project Specification Template
This allows you to create layered tiers of protection that map to your application tiers. For example, web servers generally need ports 80/443 open for incoming traffic whereas the rest of your application tiers only need to be externally available for support staff to connect/troubleshoot issues on.
If you have remote employees, you may decide to open further ports for VPN access from home offices or networks. Implementing layered firewall policies will make your application significantly more secure.
Tip#3 Monitor Your Instances
So far, we’ve looked at locking down root credentials and implementing layered firewall policies and whilst applications running on your AWS instances will be more resilient to attack from malicious software and users, there is more you can do we need to turn our attention to the instances themselves.
It’s imperative that you have an ongoing monitoring activity as part of your overall AWS implementation strategy. Monitoring each of your instances ensure that you are alerted to potential intrusions that have made it past your firewall.
Amazon Web Services ships with a component called Cloud Watch, with Cloud Watch, you can configure thresholds to detect abnormal network activity, threat indicators, outages and more. Cloud Watch can then alert you when these thresholds have been met thereby allowing you to be proactive as opposed to reactive.
Log Files and Flow Logs
Statistics and alerts are only one piece of the jigsaw. It’s just as important to examine any log files that you’re AWS instances are generating. Monitoring log files can give you deeper insight into the activities that are taking place within each instance, network or even subnet. The information can contain source and destination ports, number of packets, bytes, duration and whether or not the network traffic was accepted or rejected.
Some log files that you’ll want to consider monitoring may include but are not limited to:
- Operating system logs
- Application logs
- Security logs
- Web server logs
AWS CloudTrail logs every event that takes place within each of your instances. The data presented in these types of logfile can be very detailed and includes events that get raised from the command line or SDKs. With this in mind, you may want to consider getting a 3rd party product or tool that allows you to easily visualize the content!
Tip#4 Encrypt Sensitive Data
Businesses run on data and one of the biggest worries users and the IT community can have is regarding data breaches. Businesses and users are noticing the benefits of moving data to the Cloud, almost endless storage, easily scalable infrastructure to name a few but it’s not without its concerns (understandably) over data security.
Classify Your Data
One of the first things you should do is classify your data. This will help you to understand the types of data you have, what it’s worth to your business and customers and where it’s stored.
When you have a list of the types of data you’re storing, you should assign a priority to each dataset and ask yourself – how valuable is this data to my business or customers and how much of a headache would it cause if this data was lost or compromised?
When you have completed list of all datasets that are deemed “priority” that move around your business, the next thing to do help you decide which areas to focus on next for these datasets is to consider:
- How is the dataset stored?
- Where does this dataset get processed?
Protecting Your Data
Protecting your data really depends on where you store it. If your data is stored on a file server, S3 for example, you might opt to use S3 server-side encryption. Alternatively, maybe your data is stored in a database so you might want to encrypt the entire database or encrypt discrete fields within each database record.
One thing to also consider when deciding on your data encryption mechanism is the performance of your applications or infrastructure. Adopting the most complex encryption algorithms may have an adverse effect on your application so it’s important to test whichever implementation you choose with data at scale.
So, by now you’ve classified your data and it’s encrypted when being stored in your applications or network. The next thing to consider is how to protect your data when its “in transit” or being sent over the internet or other such communications channels.
From an internet perspective, use HTTPS with a valid certificate from a trusted 3rd party such as Verizon or DigiCert. Or, from an FTP perspective, opt to use SFTP (Secure File Transfer Protocol).
Encrypting your data can seem like an overwhelming task but if you follow these steps and work through each dataset, in turn, you’ll be able to greatly increase the security of your data as it sits within your network and when it’s transmitted.
Tip#5 Multi-Factor Authentication
We touched on password policies earlier on and the value-add of implementing strong passwords is clear but another important security method that’s worth considering and helps strengthen passwords is multi-factor authentication or MFA.
What exactly is MFA?
MFA is basically the use of more than one authentication factor that gets used to verify who a user is. Often banks will issue accounts holders with a physical keypad and authentication card that, when used together, generates a secret code that can be used to access a personal or business banking account.
Amazon Web Services MFA is no different, you can opt to purchase a hardware device that will generate unique hardware tokens that refresh every few seconds or you may want to use a “soft” token which can be installed on your smartphone.
The unique tokens generated by either are then entered whilst you supply your username and password credentials to AWS Management Console. Tokens are refreshed every few seconds to ensure the user must have the device with them upon sign in.
The first time you configure a user account to use MFA you’re effectively synchronizing the number generator on your hardware or software token which subsequently lets AWS the types of number to expect.
Setting up your AWS account to assign MFA tokens for privileged accounts only takes a few minutes and is relatively straightforward so there’s really no reason not to configure it. Doing so further increases the security for your AWS implementation and further reduces the possibilities of malicious hackers compromising your infrastructure.
Tip#6 Keep patches up-to-date
Amazon Web Services have written and published several papers on best practices and risks and compliance. Both papers are excellent resources and if you’re responsible for looking after your businesses AWS implementation you might want to check them out as they have many recommendations that could help save you a few headaches in the future.
Read How We Helped a Marketing Company to Build a Back-Office Custom Ads Dashboard
The key recommendations in each paper can be distilled into the following points:
- use recommended security settings for OS and AWS services
- keep your software patches up-to-date
The majority of operating systems and software providers publish advisory guidelines and suggested security configurations. Do your best to read through these guidelines and checklists and work from a place of “least privilege”, that is, only enable a service or setting if you really need to. The less you have running on your infrastructure means less opportunity for unscrupulous hackers to try and find open ports!
This brings us onto patching. Software patching is something IT professionals are used to hearing and let’s face it, it can be a nuisance having to apply update regular update patches. They often need to be tested by various departments, for example, a new security patch may update cryptography dlls on your AWS infrastructure but your bespoke software product may be a few versions behind. You might find that after the operating system patch had been applied, your bespoke software product no longer works.
With this in mind, it makes sense to deploy newly patched AWS instances into a test environment, run through any BAU activities that would generally occur on the instance and apply some tests. After a successful test run, you can then schedule a migration to your production environment.
Testing and Automation
Introducing automated testing of your AWS instances is also something to consider, and there’s no real reason why you can’t automate instance tests.
You can introduce automated tests that check current deployment statuses, security and web application availability and much more. You can also decide to create automated tests that take advisory guidelines into account too.
If you’re new to AWS and looking to introduce some patch and test automation, start off with simple tests such is Server 1 blocked from communication with Server2 and so on. You can then lock these tests down further by testing specific port availability.
Factor in security advisory guidelines to your testing processes, and coupled with keeping your patches up to date, will ensure that you’re AWS instance security is vastly improved.
Tip#7 Host-Based Intrusion Prevention Systems
By following the prior steps in this article, you will have locked down credentials, secured your firewall to block potentially harmful requests, have your data control and have your AWS instances running the latest security patches. These steps act as your first lines of defense from the outside world but now it’s time to add an extra layer of protection to your application using a host-based intrusion prevention system or IPS.
Your AWS instances firewall may be configured to allow incoming traffic on ports 80 and 433 (HTTP and https) to serve websites. There are still vulnerabilities that can be passed through these ports that can compromise your instances or crash applications. An IPS is a great way to reduce the chance of this happening!
What do IPS’s do?
An IPS is like the gatekeeper for your AWS instances network traffic. The IPS will monitor the content of traffic and attempt to actively block intrusions it identifies. It does this by examining the content of things such as:
- is the packet well-formed?
- Is the packet in sequence?
- does the packet contain the typical structure of known attacks?
Consider web server traffic, there are many security compromises that can occur over port 80 or 433, SQL injections, cross-site-scripting to name a few, if the IPS detects these types of attacks are present, the network traffic is dropped immediately thereby preventing the security breach from ever being executed.
Whilst the firewall grants or denies access to specific ports at an “external” level, you can think of the IPS as a component that sits beneath the firewall, one which guarantees the content of the data being processed on your network.
Tip#8 Conduct Vulnerability Assessments
Assessing your Infrastructure
One thing to consider is performing a vulnerability assessment of your existing AWS infrastructure. Such an assessment involves identifying and prioritizing vulnerabilities in all areas of your system and to start this process off, you document all identifiable vulnerabilities.
You can do this either by manually evaluating your instance configurations or use 3rd party tools and products to do this for you.
After going through the analysis phase, you can then prioritize each vulnerability and figure out the best approach to mitigate any risks you’ve identified.
When conducting vulnerability assessments on your AWS instances you’ll want to undertake some type of network scanning. A network scan will check for vulnerabilities or open ports and log these for you then to take corrective action.
Be aware however that you can’t just launch a network scan against your AWS infrastructure, you need to complete am AWS Vulnerability / Pen Test Request form. Completing this form lets Amazon know that you’re conducting a network scan on your own instances and ensures your connectivity won’t get disruption.
You can find the Vulnerability / Pen Test form here.
Tip#9 Penetration Testing
The Penetration Test or PenTest for short is an active test of your existing line of defenses. You should consider hiring a reputable 3rd party to attack your infrastructure to help identify vulnerabilities. In theory, it’s better to have someone working with you on this before a hacker from the outside world exploits any holes in your AWS infrastructure!
Whilst you may have the skills in your existing team to perform the pen-test, using someone external to your company removes any possibility of bias in terms of which components of your AWS to focus on.
Performing the Test
When performing your first pen-test, you might be tempted to let your team and various security departments know exactly when the test is to occur. If everyone knows the exact time of the test, they may try to prepare in advance so try to resist this! In a real-world security breach, a hacker isn’t going to give your prior notice!
After your pen-test has been completed buy your “hacker” you might have found a few holes but don’t fret, this is the rationale behind the pen-test. It’s far better to be proactive with this stuff than to be reactive when it happens for real.
Your “hacker” will provide you with results that may include the following:
- types of vulnerabilities that were identified
- how far into your AWS infrastructure they could reach
- some suggestions as to how best prevent these risks
After you’ve worked through the report and closed out any open vulnerabilities your AWS infrastructure will be even more secure!
Tip#10 Extra Tips!
We’ve reached tip #10. Here we have a collection of additional security tips you might also want to consider!
Protect AWS instances against accidental termination
When you deploy a new instance, it can be terminated via the console. A good practice to adopt is to enable “Termination Protection”. This will prevent accidental terminations that have been known to happen.
Use Virtual Private Cloud (VPC)
A VPC is a virtual network that runs in your AWS account. This virtual network provides some key advantages from a security point of view:
- the network is isolated from other resources
- it is not routable to the Internet by default, and
- you can apply security groups and access control lists to reduce surface attacks
Too many privileges
User access controls are fundamental to your AWS instances security, it can be tempting to give developers admin rights to undertake certain tasks but granting such permissions may cause more headaches for you further down the line.
Consider introducing Policies and to handle permission situations as they arise and try not to make your security policies so broad that they lose their effectiveness by granting everyone permission to everything!
So, there you have it, some tips and practices to consider when implementing AWS in your business, we hope you’ve found it insightful and it’s given you some ideas to consider when it comes to improving the security of your AWS instances!
Download Our Project Specification Template
Latest posts by Jamie Maguire (see all)
- SAAS (Software as a Service) Platform Architecture - June 19, 2018
- Marketing Dashboards: How to Build Own Template? - April 28, 2018
- Microservices vs SOA and API Comparison - April 20, 2018