A big difference in the way on-premises infrastructures and cloud infrastructures are implemented centers on the way that user permissions are assigned. As you move towards software-defined everything, where data and systems are far more connected (generally a good thing), you need to pay special attention to the roles and permissions you grant to ensure that users are only given as much access as they absolutely need. No more, no less. Even for teams like Threat Stack, who embrace continuous delivery and deployment methodologies, identity and access management (IAM) is critical. It ensures that our developers and support teams can get the level of access they need to continuously create and deploy updates and new features, but in a controlled and secure way.
Assigning Roles on AWS
AWS makes this really easy using their Identity Access and Management features. IAM allows you to easily assign fine-tuned access control among users and groups of users, giving you a single pane of glass view into who has access to what and why. It even allows you to add specific conditions, such as the time of day a user can be granted access to a system (a great feature for on-call rotation schedules).
Although IAM makes managing individual user permissions a straightforward process, as your team scales, you can create IAM groups where a collection of users can be given a set of permissions if they have the same role. For example, your entire support team may need read-only access to EC2, but they should be restricted from terminating anything within EC2. IAM groups let you set this level of permission for all these users at once instead of one-by-one. Simply put, it’s a big time saver.
How Threat Stack Uses IAM Users and Groups
IAM is a critical AWS security function we use at Threat Stack. We appreciate the fact that AWS default settings are deny-only so that we can plan for who has access to what from the first day a new user account is created. Additionally, because the IAM service comes with Amazon’s rich APIs, the automation of managing access becomes a critical component of your security strategy. As team members need access, whether due to a change in role or for on-call access, we can easily manage access to provide access necessary to do the job.
Using IAM, we can not only control who has access to our EC2 instances; we can also break down exactly who can do what, where, and when. At Threat Stack, our engineers have an on-call rotation schedule that runs 24/7/365, so we translated that schedule into IAM and use automation to ensure that access is granted only when necessary.
What we love about this is that it gives our engineers the flexibility they need to do their jobs without the red tape, yet limits their access in a way that helps us not only uphold our user access control policies but have peace of mind knowing at all times who is on our systems and accessing data. That way, if a breach ever does happen and we review our IAM rules, we can quickly determine if an account was breached or if we’re looking at an internal threat.
This is where Threat Stack’s user audit trails for AWS come in.
Verifying User Activity With Audit Trails
At Threat Stack, we eat our own dogfood. That means we practice what we preach (case in point: this blog post), and we use our own technology internally. With IAM users and groups in place, we know we’ve already significantly reduced the potential attack landscape of our AWS environment.
But we operate on a “trust but verify” mindset, meaning that even with IAM in place, we want a second layer of security that verifies user activity. So if Threat Stack alerts us that James is making rogue production changes at 3 a.m. (when he was only supposed to have access until 2 a.m.), we first know exactly whose account to disable and can then investigate if his account was hacked or if we’re looking at an internal threat (or just a mistake).
Because Threat Stack alerts come packed with context about exactly what happened, we can usually make this determination in minutes, not hours or days.
Or, let’s say multiple password failure alerts come in at 11 a.m. for Rick’s account. Knowing that Rick’s rotation schedule begins at 11 a.m., we can likely assume that he’s having issues remembering his password. Using our Slack integration, our team lead can just pop into Slack to ping him and ask if that’s the case. If he confirms, we can help him get back up and running. If he isn’t aware of the login attempts, then it may be a brute force attack at play and we can jump into action immediately.
Wrapping up . . .
AWS has many incredibly powerful tools like IAM that help companies like us manage the security of data, systems, and users in a flexible and manageable way. Because no protection can absolutely guarantee that an attack won’t get in, it’s wise to employ layers of security, including audit trails and alerting. Doing so at Threat Stack gives us a lot more peace of mind and significantly lessens our threat landscape.