101 AWS Security Tips & Quotes, Part 3: Best Practices for Using Security Groups in AWS
Here’s the third blog post in our 4-part series of AWS Security Tips and Quotes, which is designed to help you evolve and strengthen your organization’s security, building on a proactive, comprehensive security strategy.
So far we’ve covered:
Today the spotlight falls on Best Practices for Using Security Groups in AWS, (and in the final installment, Part 4, we’ll deal with AWS Security Best Practices).
Best Practices for Using Security Groups in AWS
1. Security groups are the central component of AWS firewalls.
“Amazon offers a virtual firewall facility for filtering the traffic that crosses your cloud network segment; but the way that AWS firewalls are managed differs slightly from the approach used by traditional firewalls. The central component of AWS firewalls is the “security group,” which is essentially what other firewall vendors would call a policy (i.e., a collection of rules). However, there are key differences between security groups and traditional firewall policies that need to be understood.
“First, in AWS, there is no ‘action’ in the rule stating whether the traffic is allowed or dropped. This is because all rules in AWS are positive and always allow the specified traffic — unlike traditional firewall rules.
“Second, AWS rules let you specify the traffic source, or the traffic destination — but not both on the same rule. For Inbound rules, there is a source that states where the traffic comes from, but no destination telling it where to go. For Outbound rules, it the other way around: you can specify the destination but not the source. The reason for this is that the AWS security group always sets the unspecified side (source or destination, as the case may be) as the instance to which the security group is applied.
“AWS is flexible in how it allows you to apply these rules. Single security groups can be applied to multiple instances, in the same way that you can apply a traditional security policy to multiple firewalls. AWS also allows you to do the reverse: apply multiple security groups to a single instance, meaning that the instance inherits the rules from all the security groups that are associated with it. This is one of the unique features of the Amazon offering, allowing you to create security groups for specific functions or operating systems, and then mix and match them to suit your business’ needs.”
— Avishai Wool, A Guide to AWS Security, Infosec Island; Twitter: @InfosecIsland
2. Enable and configure AWS PVC Flow Logs.
“Enable AWS VPC Flow Logs for your VPC or Subnet or ENI level. AWS VPC flow logs can be configured to capture both accept and reject entries flowing through the ENI and Security groups of the EC2, ELB, and some additional services. These VPC Flow log entries can be scanned to detect attack patterns, alert abnormal activities and information flow inside the VPC, and provide valuable insights to the SOC/MS team operations.”
— Harish Ganesan, 27 Best Practice Tips on Amazon Web Services Security Groups, 8K Miles; Twitter: @8KMiles
3. Use current managed policies.
“Earlier, only Identity-based (IAM) inline policies were available.
Managed policies came later. So not all old AWS cloud best practices that existed during the inline policies era might hold good in the present day. So, it is recommended that you use managed policies that is available now. With managed policies you can manage permissions from a central place rather than having it attached directly to users. It also enables you to properly categorize policies and reuse them. Updating permissions also becomes easier when a single managed policy is attached to multiple users. Plus, in managed policies you can add up to 10 managed policies to a user, role, or group. The size of each managed policy, however, cannot exceed 5,120 characters.”
— Jayashree Hegde, AWS Cloud Security Think Tank: 5 Reasons Why You Should Question Your Old Practices, Botmetric; Twitter: @BotmetricHQ
4. Look at all the security groups associated with each instance for a complete picture of what touches regulated data.
“AWS is clearly set up to enable you to look at each security group in turn and review it, so that you can look over the rules, compare them to your corporate policies and regulatory requirements to see if they match. As such, this is an easy and resource-efficient option.
However, it comes with two caveats. First, you don’t have any context if you look at an individual security group on its own. You don’t even know if each security group has any instances associated with it — it might be ‘free floating’ — which is perfectly possible in AWS.
“Second, AWS security groups can be mixed and matched, so you can have multiple security groups associated with individual instances or servers. To truly understand your security posture, you need to look at all of the security groups that are associated with each instance. Otherwise you will only have a partial view of what traffic is allowed into or out of instances that touch regulated data.”
— Avishai Wool, Tips for auditing your AWS security policies, the right way, AlgoSec; Twitter: @AlgoSec
5. Categorize your security groups.
“It is good to categorize your security groups. For example all DB and web server connection ports in one security group, all the media connection ports under one security group, all the third-party connection ports in one security group, and all the office-specific ports under one security group. Categorization helps you manage your different sets of connections efficiently so you do not mess up your security groups whenever you need to change some things for a specific port.”
— Chandan Mishra, 10 Tips to secure your EC2 instance on AWS using Security Groups, LinkedIn
6. Minimize the number of discrete security groups.
“Account compromise can come from a variety of sources, one of which is misconfiguration of a security group. By minimizing the number of discrete security groups, enterprises can reduce the risk of misconfiguring an account.”
— Sekhar Sarukkai, Locking-in the Cloud: Seven Best Practices for AWS, Cloud Security Alliance; Twitter: @cloudsa
7. Use proper naming conventions for your security groups.
“Have proper naming conventions for the Amazon Web Services security group. The naming convention should follow enterprise standards. For example it can follow the notation: ‘AWS Region+ Environment Code+ OS Type+ Tier+ Application Code’
“We have been using Amazon Web Services from 2008 and found over the years managing the security groups in multiple environments is itself a huge task. Proper naming conventions from beginning is a simple practice, but will make your AWS journey manageable.”
— Harish Ganesan, AWS Security Groups – 27 Best Practice Tips, LinkedIn
8. Attach policies to groups, rather than individual users.
“As a best practice, attach policies to groups instead of to individual users. If an individual user has a policy, make sure you understand why that user needs the policy.”
— AWS Security Audit Guidelines, AWS; Twitter: @awscloud
9. Don’t open ports for 0.0.0.0/0 unless specifically required.
“Allowing incoming access by opening up ports for 0.0.0.0/0 in security groups is the most common mistake made by professionals when provisioning resources. Users end up opening their cloud networks and exposing their cloud resources and data to outside threats.”
— Eyal Posener, Amazon Security Groups – 5 Important Best Practices for Your To-Do List, Stratoscale; Twitter: @Stratoscale
10. Grant access from specific Amazon EC2 security groups or particular IP addresses for any security group rule.
“Amazon Relational Database Service (Amazon RDS) has security group configurations which are examined explicitly, and a warning is released if a rule for security group grants or is probable to grant excessive access to your database. For any security group rule, it is recommended that access from only certain Amazon Elastic Compute Cloud (Amazon EC2) security groups or from a particular IP address should be granted.”
— Monali Ghosh, AWS Security Audit and Best Practices, Centilytics; Twitter: @centilytics
11. Create a default security group for new instances.
“When you create a new instance through Salt, it requires that you specify a default security group. In order to avoid any security breach, create a default group that only allows SSH.”
— AWS Security groups best practices, TrackIt; Twitter: @TrackItCloud
12. Restrict access to EC2 security groups.
“This will prevent DoS, brute-force, and man-in-the-middle attacks. Additionally, assign your identity and access management (IAM) policies and permissions to specific roles/groups instead of specific users.”
— Sekhar Sarukkai, 10 ways to secure sensitive information on AWS, CyberScoop; Twitter: @CyberScoopNews
13. Create individual IAM users, then assign them to groups, and then attach policies to groups.
“You should always create individual IAM users, add them to IAM groups and attach IAM policies to these groups. Policies define group’s permissions allowing or denying access to AWS resources. When attached to groups (rather than users) they make it easy to fine-tune a policy to affect a group and all relevant users at once.”
— Evgeny Goldin, AWS IAM Best Practices, MinOps; Twitter: @MinOpsInc
14. Set up security groups around access points rather than specific AWS resources.
“Where possible, set up security groups focused around access points rather than specific AWS resources. In other words, create a security group for the IP addresses associated with Company Branch A, Company Branch B, etc. rather than a security group specifying which IP addresses can access EC2_A, EC2_B, etc. That way, you only have to update your traffic rules in one place (for example, if the IP address of Company Branch A changed, you only have to update the Company Branch A security group instead of searching every EC2_A, EC2_B, etc. security group and updating the traffic rules in every place where Company Branch A’s info appears).”
— Julia Stefan, Best Practices, Tips & Tricks for Managing Your Security Architecture, DiamondStream; Twitter: @DiamondStream1
15. Be cautious when using multiple security groups.
“Use caution with multiple security groups. You can apply multiple security groups to a single EC2 instance or apply a single security group to multiple EC2 instances. System administrators often make changes to the state of the ports; however, when multiple security groups are applied to one instance, there is a higher chance of overlapping security rules. For example, security group A opened port 80 to the entire Internet. Meanwhile, security group B opened port 80 to one IP address. If you assign these two security groups to an EC2 instance and modify either, issues may occur. If you remove port 80 rules from security group A, security group B still has port 80 open. It’s easier to find these mistakes when there is a small number of EC2 instance or security groups. A larger number makes finding mistakes more difficult.”
— Ruihai Fang, Stand Your Cloud: A Series on Securing AWS, Bishop Fox; Twitter: @bishopfox
16. Use IAM to control permissions for creating and managing security groups, network ACLs, and flow logs.
“You can use AWS Identity and Access Management to control who in your organization has permission to create and manage security groups, network ACLs, and flow logs. For example, you can give only your network administrators that permission, but not personnel who only need to launch instances. For more information, see Controlling Access to Amazon VPC Resources.
“Amazon security groups and network ACLs don’t filter traffic to or from link-local addresses (169.254.0.0/16) or AWS-reserved IPv4 addresses — these are the first four IPv4 addresses of the subnet (including the Amazon DNS server address for the VPC). Similarly, flow logs do not capture IP traffic to or from these addresses. These addresses support the services: Domain Name Services (DNS), Dynamic Host Configuration Protocol (DHCP), Amazon EC2 instance metadata, Key Management Server (KMS — license management for Windows instances), and routing in the subnet. You can implement additional firewall solutions in your instances to block network communication with link-local addresses.”
— Security, AWS; Twitter: @awscloud
17. Create a security group for databases opening at port 3306, but don’t allow access to the internet at large.
“You’ll want to create an AWS security group for databases which opens port 3306, but don’t allow access to the internet at large. Only to your AWS defined webserver security group. You may also decide to use a single box and security group which allows port 22 (ssh) from the internet at large. All ssh connections will then come in through that box, and internal security groups (database & webserver groups) should only allow port 22 connections from that security group.
“When you setup replication, you’ll be creating users and granting privileges. You’ll need to grant to the wildcard ‘%’ hostname designation as your internal and external IPs will change each time a server dies. This is safe since you expose your database server port 3306 only to other AWS security groups, and no internet hosts.
“You may also decide to use an encrypted filesystem for your database mount point, your database backups, and/or your entire filesystem. Be particularly careful of your most sensitive data. If compliance requirements dictate, choose to store very sensitive data outside of the cloud and secure network connections to incorporate it into application pages.”
— Sean Hull, Deploying MySQL on Amazon EC2 – 8 Best Practices, Scalable Startups; Twitter: @hullsean
18. Keep your naming conventions under wraps.
“For security in depth, make sure your Amazon Web Services security groups naming convention is not self explanatory and also make sure your naming standards stay internal. Example: AWS security group named UbuntuWebCRMProd is self explanatory for hackers that it is a Production CRM web tier running on ubuntu OS. Have an automated program detecting AWS security groups with Regex Pattern scanning of AWS SG assets periodically for information revealing names and alert the SOC/Managed service teams.”
— Harish Ganesan, 27 Best Practice Tips on Amazon Web Services Security Groups, Cloud, Big Data, and Mobile; Twitter: @harish11g
19. Close unnecessary system ports.
“EC2 instances can be secured with ‘Security Groups.’ This is a basic firewall that allows you to open and block network access to your EC2 server.
“Security Groups let you limit inbound and outbound connections for specified protocols (UDP and TCP) for common system services (HTTP, DNS, IMAP, POP, MYSQL, etc.) limited by IP ranges, your IP, or anywhere.
“On Linux Servers, some of the most common services are SSH, HTTP, HTTPS, and MySQL. Let’s see how we can secure access to those services using EC2 Security Groups.
“From the AWS Management console, we can add and edit Security Group filtering rules. Let’s see how to do it:
- Login to AWS Management Console.
- Click on your left menu: Security Groups.
- Click on your instance security group.
- Click on Edit to add new rules or customize existing ones.”
— Chris Ueland, How to secure your EC2 virtual servers, ScaleScale; Twitter: @scalescalehq
20. Regularly revisit your security groups to optimize rules.
“Many organizations begin their cloud journey to AWS by moving a few applications to demonstrate the power and flexibility of AWS. This initial application architecture includes building security groups that control the network ports, protocols, and IP addresses that govern access and traffic to their AWS Virtual Private Cloud (VPC). When the architecture process is complete and an application is fully functional, some organizations forget to revisit their security groups to optimize rules and help ensure the appropriate level of governance and compliance. Not optimizing security groups can create less-than-optimal security, with ports open that may not be needed or source IP ranges set that are broader than required.”
— Guy Denney, How to Visualize and Refine Your Network’s Security by Adding Security Group IDs to Your VPC Flow Logs, AWS; Twitter: @awscloud
21. Periodically audit security groups to identify those not following the established naming conventions.
“Periodically detect, alert, or delete AWS Security groups not following the organization naming standards strictly. Also have an automated program doing this as part of your SOC/Managed service operations. Once you have this stricter control implemented, then things will fall in line automatically.”
— Harish Ganesan, 27 Best Practice Tips on Amazon Web Services Security Groups, 8K Miles; Twitter: @8KMiles
*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Bob Allin. Read the original post at: https://www.threatstack.com/blog/101-aws-security-tips-quotes-part-3-best-practices-for-using-security-groups-in-aws
