Amazon Web Services, the ubiquitous cloud infrastructure provider, has made it increasingly easy for businesses to move to the cloud and take advantage of the scalability, flexibility, and cost savings this approach offers. For some businesses that are contemplating the move to AWS, you may be wondering whether it’s necessary to have a team of developers who can help to ensure that you are capable of running securely on AWS.
The short answer is: You don’t need to start from scratch when it comes to security, and you don’t need to have extensive coding resources in-house to run securely on AWS. With the right tools at your disposal, you can quickly measure compliance with your unique security policy and adapt to changes in your environment as needed.
Here’s what you need to know to run securely on AWS, with or without a legion of development resources at your disposal.
Focus on Best Practices
AWS has been been a leader in proactively developing and communicating best practices for running securely in the cloud. It’s a big part of the reason why so many organizations choose AWS. The Shared Responsibility Model lays out what AWS is responsible for vs. their customers, and is a good place to start when it comes to wrapping your head around your own organization’s security needs in the cloud. Beyond this, AWS has also released a helpful white paper covering cloud security best practices. (Note: We cover several related topics in our best practices blog content, if you’d like to get more insight.)
So the good news is that cloud security best practices have already been pretty clearly outlined. However, not all organizations are meeting them today. In fact, considering the fact that 73% of companies have critical AWS security misconfigurations, it’s a good idea to revisit whether your own environment is indeed meeting best practices. Understanding what the industry views as the best way to handle configurations and doing what you can to achieve this is the best way to lay a strong foundation for your own security posture. (P.S. Our recently released Configuration Auditing feature is designed to solve just this challenge.)
When you move to the cloud, you don’t necessarily lose visibility. You just need to pay attention to different signals. In the cloud, continuous security monitoring can empower your organization to detect suspicious or anomalous behaviors right when they happen. This is the visibility that really matters, because it allows you to put a stop to attacks before it’s too late.
In the cloud, host-based monitoring will give you an inside-out look at all activity happening on your network. Your monitoring solution should be able to alert you the moment anomalous activity is detected at the host level anywhere across your cloud environment. This granular visibility into user activity, processes, network connections, and more will allow you to gain the same level of visibility — if not more — that you had on-premise. A platform like Threat Stack Cloud Security Platform® can make this critical aspect of your security posture much easier to achieve, and it doesn’t require any coding on your organization’s part.
Balance Compliance and Security
By now, we’re a bit of a broken record on the subject, but it does bear repeating that security does not equal compliance and vice versa. That said, if you are in a regulated industry or otherwise have compliance responsibilities, when you are constructing the policies that will govern your cloud infrastructure, you want to make sure that you take both security and compliance requirements into account. We recently released a new feature, Compliance Rule Sets, that may be helpful as you address your own needs. These give you the ability to map to many common compliance frameworks without the need for code.
Choose Out-of-the-Box Solutions
Not every organization has the time or resources to research AWS documentation, assemble AWS native tools, and code their own rules. Instead, look for out-of-the-box security capabilities such as Threat Stack’s Guided Rules Editor and CloudTrail alerting feature, which are both part of Threat Stack Configuration Auditing. (In addition to rules that we provide out-of-the-box to catch common risky or suspicious behaviours, Guided Rules Editor allows you to write rules quickly and easily, without investing a bunch of time in researching API documentation or coding.)
With Threat Stack’s Guided Rules Editor, users can make small changes to existing rules (e.g., requiring a longer password) and create new rules whenever necessary. Users can simply select the services that need to be monitored, pick the relevant resource type, and define evaluation statements to suit their parameters. It’s basically a GUI for security rules, and it takes the manual labor (i.e., coding) out of running secure in the cloud.
Bottom Line: You Can Go Your Own Way
No two organizations have exactly the same security requirements, so it’s vital to be able to make adjustments quickly and simply whenever the need arises. Your organization should be able to create and enforce its own unique security (and compliance) policies, without being restricted by the coding resources at hand.
With a feature like Threat Stack’s Guided Rules Editor, you don’t need to know the AWS API structure inside-out and backward, you don’t need to write code, and you don’t have to worry about debugging. New rules can be created in seconds, and you can maintain complete visibility into your entire cloud infrastructure, allowing you to meet both security and compliance standards at all times.