Solving the 10 AWS security blunders automatically with bots
Recently, Fahmida Y. Rashid wrote a great piece on InfoWorld, titled “10 AWS Security Blunders and how to avoid them.” While not an exhaustive list, it is a very useful guide towards a security-centric approach to using cloud computing platforms.
These are extremely common mistakes that we see everyday working with customers, and mistakes that many customers aren’t even aware that they are making. That lack of awareness is a real concern. That’s why solutions like BotFactory that automatically find these vulnerabilities in customer environments, and can automatically correct them, are so valuable.
I’ve mapped out BotFactory’s capabilities for 9 of the 10 blunders Fahmida highlighted in her article. The first item in the list, “Who’s in charge of security,” is more about awareness. The other 9 items are specific security issues where we can apply automation Bots to ensure compliance.
1. Who’s in charge of security?
First and foremost, understanding the shared responsibility model is a must. Realize that AWS is responsible for the security “of” the platform, and you, as a customer, are responsible for keeping your company safe “in” the cloud. That leads to the obvious follow up question:
In your company, WHO is responsible for security?
This may be an individual, such as a Chief Information Security Officer (CISO), or it could be a team. But without the understanding of who owns security, no one does. This is an organizational challenge, not a technical one. As such, there is no bot for this one.
2. Forgetting about logs
As the article points out, having complete logging on your account is important for many reasons:
CloudTrail can be used for security analysis, resource management, change tracking, and compliance audits.
When AWS accounts are compromised, CloudTrail is typically the first thing that a hacker will disable. This allows the hacker to cover their tracks, and obscure their actions on your account. A thread on Quora about a hacked account validates this approach.
BotFactory includes a bot to identify AWS accounts that have CloudTrail disabled. The user can choose a response, including options such as a push notification or generating a report.
3. Giving away too many privileges
Organizations need to separate user permissions from application permissions. Often, in their daily work, people run into misconfigurations and it’s very tempting to just open permissions to everything to let people get stuff done. However, this is a critical security vulnerability.
BotFactory includes a bot called “Cloud User Policy Audit”. This allows the company to find and fix these problems in near real-time.
4. Having powerful users and broad roles
The challenges of policies and role-based permission schemes for many companies is that they are confusing. They can be assigned to user accounts, service accounts, or directly to resources like EC2 instances and S3 buckets.
So while this often does require planning and thought, BotFactory provides multiple bots to ensure security on resources. For example, there are bots to ensure that an S3 bucket does not have global permissions, and to ensure that user accounts don’t have privileged policies.
5. Relying heavily on passwords
Passwords are a common source of vulnerabilities on any IT system, from a single laptop to the most complex multi-tier applications. AWS, and other cloud platforms, typically provide tools to help companies manage them. However, keeping in mind the shared responsibility model, it’s then up to the company to use that. BotFactory provides multiple bots to help companies manage this process. Two examples bots are:
- Clouds with weak password policy: lets the company define and enforce length and complexity requirements
- Ensure MFA is enabled on user accounts: ensures that accounts not using two-factor authentication (2FA or MFA) are identified in real-time.
6. Exposed secrets and keys
A cloud best practice is to create IAM accounts for services and applications. And then these keys need to be managed, and rotated regularly. A useful bot here is “Cloud User API Key Audit”. This allows companies to target service accounts by key age, and enforce proper key rotation. Multiple copies can made for various environments, such as test/dev versus production, or various needs, such as service accounts versus user accounts.
7. Not taking root seriously
Repeat after us – DISABLE ROOT now. Unsurprisingly, the bot to find and disable root is called “Clouds with active root account”. In under 10 seconds, companies can find and take action on the accounts that have root enabled.
8. Putting everything in one VPC or account
While a single account makes management easier, it is a potential security risk. DivvyCloud’s bots make the cross-account management easy for customers. All bots can be applied to individual accounts, multiple accounts, or all accounts, with just a few clicks. There’s no need to shy away from spreading resources out or isolating applications and data to provide for enhanced security. BotFactory applies automation policy compliance consistently across clouds and cloud accounts.
9. Leaving wide open connections
This is one of the most common problems across all clouds, not only AWS. For ease of use, and for public web service consumption, many companies just open to the whole Internet, namely 0.0.0.0/0. The BotFactory “Audit Security Group” Bot lets companies define targeted ports that should never be open to the the world.
The power of this bot is that it goes beyond simply finding these open ports, and closes them. Customers can choose additional actions like logging to an audit trail, generating notifications or integrating into third-party tools via API.
10. Skimping on encryption
Last but not least, what are you storing in the cloud? And shouldn’t you protect it? DivvyCloud provides bots for verifying and enforcing encryption on EBS, RDS and RedShift.