Like anything that requires strength and skill, cloud security takes focus, discipline, and a keen understanding of the actions that get you the best results. We recently hosted a webinar bootcamp reviewing the top eleven AWS best practices to get CloudFit. Many of the best activities we reviewed are very easy to implement, but often ignored which creates problems when hackers discover your vulnerabilities.
We had a great discussion and wanted to provide a post-webinar recap of some of the questions from our audience that we ran out of time to answer. In this blog, Marco Genovese, Solutions Architect at Evident.io will answer those questions and coach us through how these security practices are designed to improve your cloud’s overall security and fitness in the shortest time possible.
Q: “Regarding MFA, I agree the password complexity is not the right solution, the MFA solution is better, but for our CIS Benchmark we are required to have complex password that expire, how should be go about handling the CIS compliancy then?”
[Marco Genovese] You’re correct, password complexity is not the right solution, not even when it comes to compliance standards. Even in the CIS Amazon Web Services Foundations Benchmark v1.1.0 – 11-09-2016 they recommend using MFA vs. password complexity as well. Frequently changing passwords can cause people to write them down or forget them and cause negative productivity impact – time wasted requesting passwords and reissuing access. Using MFA allows for security and usability at the same time without interruptions.
Q: “In the example where an EC2 instance has access to an S3 bucket, what are the guidelines for which tool to use for S3 bucket/object policies vs IAM roles?”
[Marco Genovese] Imagine if a policy with administrative privilege was attached. The result could have been significant damage caused, not just on the intended S3 bucket, but on all AWS Services and Resources. With this in mind, what’s an example of a strong policy? Let’s go back to the example application above. Perhaps all our application really needs, is to make the following calls: S3 GetObject, S3 PutObject, SQS ReceiveMessage, SQS SendMessage, SNS Publish. That’s only five service API calls, or five actions in IAM Policy document language. Let’s say we were given the ARNs of the Bucket, SQS Queue and SNS Topic that are the intended resources. We can now use the awesome “AWS Policy Generator” tool to create a policy document that can be applied to the IAM Role that is associated with our application’s EC2 instance.
Q: “Regarding Rotating Keys: Using Evident.io’s ESP showed us that we had issues with Key Rotation so we set up a script that will now “Auto-Delete” keys that are over 90 days old. This is in our sandbox environment and users are informed when they sign up for account.”
[Marco Genovese] This is great for a couple of reasons! One, this example proves that visibility is key to understanding your security posture. With so many people accessing and making changes within your cloud, it can be hard to operate securely without locking it tight which can really slow things down. We love to see our customers’ confidence grow as they implement and customize the ESP signatures. Following this best practice enables them to provide their teams with more trust and autonomy to get things done fast. And two, this is exactly how you should operate to keep track of rotating API access keys within your teams and with third-party vendors. Communication is key to the success of any organization especially when it comes to security.
Q: “Regarding S3 Bucket Policies: Can Evident.io ESP help identify EC2 specific misconfigurations and/or missing vulnerability patches or do we need a 3rd-party tool for this?”
[Marco Genovese] Evident.io ESP can help with EC2 misconfigurations; for example, if an EC2 instance IAM role is not enabled or an EC2 instance does not appear to be redundant. Evident can also tell you if you are nearing limits of on-demand EC2 instance. We can also let you know if a POODLE vulnerability or the likes was discovered in your infrastructure. That being said, Evident.io ESP does not have access into the host layer for security reasons and cannot check for file patch levels at the OS level.
Q: “Regarding Logging and Encryption: One of the challenges with logging is information overload, what are some best practices for simplifying visibility? Can CloudTrail logs be fed into the Evident.io ESP?”
[Marco Genovese] Yes, CloudTrail logs can be fed into ESP. We have several out-of-the-box signatures that simplify logging and increase visibility with CloudTrail and CloudWatch integration. In addition to capturing CloudTrail logs within a specified S3 bucket for long term analysis, real time analysis can be performed by configuring CloudTrail to send logs to CloudWatch Logs. For example, an ESP trail that is enabled in all regions in an account, CloudTrail sends log files from all those regions to a CloudWatch Logs log group. The intent of this signature is to ensure AWS account activity is being captured, monitored, and appropriately alarmed on. CloudWatch Logs are a native way to accomplish this using AWS services but does not preclude the use of an alternate solution. Sending CloudTrail logs to CloudWatch Logs will facilitate real-time and historic activity logging based on user, API, resource, and IP address, and provides opportunity to establish alarms and notifications for anomalous or sensitive account activity. This is where our user attribution capability comes in. When a misconfiguration or vulnerability is detected ESP is able to provide you with a near-real-time snapshot of who did what, when and from where down to IP address. ESP’s User Attribution feature helps to quickly identify whether you are dealing with an internal vs external threat. And good news, AWS recently announced that the new default setting for CloudTrail is on!
Q: Lastly, we had a couple of questions regarding which compliance standards that ESP supports.
[Marco Genovese] Simply put, ESP comes with the CIS AWS Foundations Benchmark out of the box for free. Our standards for HIPAA, PCI, SOC 2, ISO, NIST 800-53 and NIST 800-171 are additional modules that can be activated inside your account once you are a customer.
To find out more about how our technology can help you and your team strengthen your AWS security best practices and get CloudFit, visit our website. ESP provides a single pane of glass view of all of your AWS accounts, regions and services in one easy to customize dashboard. By consuming all of Amazon’s APIs, ESP can detect and reveal vulnerabilities and alert your team to configuration changes and policy violation and provide a path to remediation.