Your Cloud Is Just Someone Else’s Computer We Have To Secure
In a relatively short amount of time, Amazon went from an online marketplace for books to a global technology force. This was accomplished through its subsidiary AWS which provides one of the leading cloud computing platforms used today. By leveraging AWS services, companies could forego expensive infrastructure costs and utilize cloud services for compute, storage, content delivery and various other functionalities. At first, it was a scary thought to start moving your production services and workloads to “the cloud”. But as adoption of this technology grew, the veil was lifted and we began to understand the benefits cloud computing could provide us.
Throughout our Enova Innovation blog series, we’ve had several awesome posts written about the evolution of AWS at Enova and how technology teams across the company have adapted to this shift in infrastructure. As I see this topic relevant as well as educational, I’d like to detail the Enova Security Engineering team’s progression into the cloud.
The Beginnings
It’s early 2015. AWS was currently being used in limited fashion for a subset of services like developer/testing instances, file storage and messaging. The Enova security engineering team was not yet submersed in the cloud world and primarily focused on protecting our on-prem resources. This all changed with the launch of our analytics-as-a-service product, Enova Decisions, which would be our first product hosted entirely in AWS. Tasked with securing this environment, the idea was to extend the same security solutions used on-prem into the cloud. The investigation process included leveraging current solutions in place, using native AWS security services or possibly obtaining new 3rd party tools.
Security Policies
On-prem we enforce numerous security policies through access controls and various security solutions, but how can we tackle this issue in the cloud? The answer is “AWS Organizations” which allows us to centrally manage compliance and security policies across multiple AWS accounts. AWS Organizations allows us to restrict what services and actions are allowed in any of our accounts. For instance, with Organizations we can restrict the ability for users to disable logging, spin up resources in non-approved regions or terminate EC2 instances.
Compliance
There are a lot of 3rd party vendors out there that offer security compliance solutions for AWS. Initially there wasn’t a need for a robust solution as the ones provided by most of these companies, but we still needed to have something in place. We tested and ultimately started using “AWS Config” which enables us to assess, audit, and evaluate the configurations of our AWS resources. Using AWS Config rules, we can be alerted when S3 buckets are public, when access keys haven’t been rotated or when resources aren’t using encryption.
Identity and Access Management
Leveraging “AWS IAM” allowed us to seamlessly integrate with our corporate directory services while managing secure access to our AWS resources. IAM allows us to create groups for each service and apply least access privileges for this service to run. User access is configured with MFA and locked down to specific network ranges to prevent unauthorized connections.
Firewalls
After much testing with virtual instances of our on-prem firewall solution in AWS we determined for the Enova Decisions use case utilizing “AWS WAF” was the best choice. AWS WAF is a web application firewall that helps protect web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. It also provides our team the ability to create custom security rules or use managed rulesets provided by AWS security partners.
Intrusion Prevention System
Reviewing this technology, it made the most sense to utilize “AWS GuardDuty.” GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect our AWS accounts and workloads. Since this service obtains its information from various AWS logs, there was no need to spend a lengthy amount of configuration time spinning up inline devices to capture and analyze traffic flows.
Vulnerability Scanning
Assessing the security and compliance of our endpoints was another concern we needed to address. We looked at “AWS Inspector” which is a service that could be run on instances to check for potential security issues. It was determined that instead of pushing out the required agents to all endpoints, we could leverage our internal vulnerability scanners which could provide the same functionality with more detailed reporting regarding security issues.
Monitoring
One of the most important things in preventing security issues is the ability to capture and ensure you’re receiving all relevant data. On-prem we feed all security logs to our SIEM, but how are we going to handle this in AWS? Through the previously mentioned AWS Organizations, we have a policy for all AWS accounts to send Cloudtrail logs to a single destination. Cloudtrail logs provide us visibility into user activity by recording actions taken on any of our AWS accounts. With these logs we can then set up Cloudwatch rules to alert on critical events. We also utilize VPC flows logs which capture information about the IP traffic going to and from network interfaces in our VPCs. We have also started to investigate the usage of AWS Security Hub which can aggregate various logs and correlates this information into a variety of security metrics in a single place.
Terraform
One of the biggest challenges for the security engineering team was adapting to our infrastructure-as-code process. Most of our AWS infrastructure is provisioned using Terraform, so we needed to switch from configuring certain services in the AWS console and get our Terraform game on. It’s been a challenging journey which still continues, but support is always constant as we work closely with the Application Platform Infrastructure team here at Enova which manages AWS. They do an awesome job of providing Terraform guidance and training to technology departments across the company. From a security perspective, infrastructure as code provides another layer of protection through consistent/stable configurations, version control and minimizing risk due to human error through automation.
Final Thoughts
As stated at the beginning of this blog, the idea for securing our AWS infrastructure was to look at the tools and concepts we have on-prem and apply the same protections in the cloud. As you can see, sometimes we leveraged current solutions and other times utilized native AWS security services. We’ve yet to bring in a 3rd party tool, but investigation has begun on some vendor solutions to help streamline our security monitoring and visibility across AWS. Another important task we constantly are faced with is continual reviews of current and future security services offered by AWS. It’s no secret that AWS is security-focused shown by their frequent updates to existing security services as well as new security services launched each year. It’s our responsibility to assess technology gaps, review these products and determine if they’re relevant to implement within our not-so-scary cloud infrastructure.