Addressing the rise in credential and session compromise
In my last post, I wrote about AWS Service Control Policies that can be leveraged to create organization-wide policies.
These types of policies, when leveraged properly can reduce the chance of privilege escalation and limit the blast radius in the event of session or credential compromise.
Reducing the Risk of Privilege Escalation
In my next post, I’m going make some changes to prevent the types of privilege escalation I wrote about in these two posts — which are applicable to any environment by the way (on-premises, any cloud, any SAAS provider, with the ability to create users and any IAAS provider that offers the ability to assign permissions to a compute resource.)
Backdoors and Privilege Escalation Via Cloud Account UsersPrivilege Escalation Via a Cloud Compute Resource
We can architect permissions and roles in our organization so that compromise of a single set of credentials does not mean access to all of the resources in a cloud account (directly or indirectly).
MFA Enforcement for Development and DevOps
Before I go on to implementing service control policies, I’m going to reiterate that I’m requiring all my roles to use MFA while I’m developing this framework. These roles are not used for running applications at the moment. They are emulating different people in an organization doing their jobs in a cloud environment.
There are methods to ensure developers use MFA when they leverage permissions in your cloud environment. As discussed, different methods come with different risks.
The Yubikey CLI and AWS MFAAWS CLI for an SSO User
I am choosing to use an AWS developer key with an authenticator app on a separate phone than the one I use for surfing the web at the moment. The fact that AWS developer tokens are still found in source control, including recently in 57 PyPi packages, is a problem, but less so if they cannot be used without MFA and the tokens are rotated frequently. I haven’t addressed rotation, but for now we do have MFA.
It’s not really a big deal to me to enter an MFA code while running a script. But some people seem to think this is a major hassle and burden on their ability to get their jobs done.
I’m not sure why. It just takes a minute to enter the token when assuming a role to use with the AWS CLI and your session can last for a reasonable amount of time.
If you need to refresh your session I wrote about how to do that here with Python, for example:
Refreshing AWS credentials with Python
Security just gets in the way
If you think that submitting a second factor before carrying out an action or accessing some data is annoying, then would you like AWS to just remove the login screen from the AWS console as well? Because it takes time to enter a user name and password.
Maybe you could just get a link that you go to in order to access your particular account. Never mind that anyone who gets that link can also get into your account. And they will simply by sniffing your web traffic since you also don’t want to use a VPN. They can also easily get to the link because network security is a hassle too.
Let’s think about other ways to make life easier. We could stop scanning bags at the airport or checking IDs and let anyone walk right up to the counter where the plane is loading at the airport, too.
Most people understand the trade-off’s at the airport. They don’t want a bomb on their plane or some hijackers, so they are willing to let TSA scan their bags in the United States. It’s kind of a hassle — especially when you are late — but everyone can understand and relate to why that security control exists.
Cost of a Data Breach vs. Inconvenience
Well, perhaps we need to explain why MFA exists again so people understand. It’s not just implemented to inconvenience people within an organization. It is there to prevent real threats that lead to data breaches and cost companies thousands or millions of dollars — and possibly even people’s jobs.
Why 31% of data breaches lead to employees getting fired
At the very least it will hamper some of those nifty new projects you want to implement while the organization is dealing with the aftermath of the data breach. If you are working in the US, the cost of the average data breach is over twice the global average at $9.44M.
If you find it a hassle to pick up your phone and enter a few numbers off an authenticator application or push a button on a hardware key or take a few extra steps, is that hassle worth $9.44M?
The cost of controlling — everything
Here’s another inconvenience developers don’t like: They want to control everything in the name of DevOps. I don’t really agree with that version of DevOps. It’s not that you are not smart enough to do all the things you want to do. You most certainly are! And so are the attackers that are trying to steal your credentials to do their dirty work.
My version of DevOps is what I’m explaining and writing about in this blog series — automate everything with a solid security architecture. That architecture includes IAM, segregation of duties, MFA, encryption, networking, operating system and container security, and application security, among other things.
At the same time, we want to make it easy for people to do their jobs. I haven’t gotten to that part yet. Stay tuned.
Here’s the reality. Your all-powerful credentials may lead to a compromise like the Oktapus breach I wrote about. Excessive permissions and access ultimately let attackers who compromised Twilio to access Signal accounts.
Alternatively, consider the recent Circle CI breach where malware got onto a developer’s machine. Access to that developer’s machine and credentials with excessive permissions and access led to a compromise of customer credentials. That in turn, resulted in additional work for AWS and all the Circle CI customers that were affected.
Customers had to rotate credentials and investigate their accounts to determine if those credentials had been used maliciously within their cloud environments — say to create a backdoor like the one I wrote about in my post at the top of the article.
I wouldn’t be surprised if some companies pull back on using Circle CI after this breach. They could lose business as a result. I haven’t personally evaluated the company so I cannot make a recommendation.
After the breach, Circle CI had to implement the type of controls that segregate duties or at least require extra steps to take sensitive actions. Those credentials had access that was too broad without restrictions in their environment. I can definitely recommend that you take the time to implement this type of architecture and process — before you have a breach.
CircleCI incident report for January 4, 2023 security incident
Sure, it’s a hassle to have to go through a few extra steps to get your job done. I understand that developers like to work fast — I am a developer. But I’m a security-conscious developer with an understanding of how attackers can breach systems and how my actions and credentials could contribute. Therefore I’m willing to take a couple of extra steps on my part to prevent a data breach.
Security and Governance Team Responsibilities
As for the security team — it’s a hassle to take the time to stop and explain the details to developers who don’t want to follow your policies. But this extra time is an important part or your job. If people don’t understand the reason for the controls, they may complain to upper management and get the controls removed. I’ve seen this happen more than once.
Or they may simply circumvent or ignore your controls — a topic in my book and other posts on this blog. I’ve seen that too, at the executive, DevOps, and developer level — and even by different security team members within a large organization. Everyone was just trying to get their job done — or, as one person told me, get on stage at re:Invent to present some open source software that promoted insecure networks in the name of progress.
It’s important for security teams to understand how developers and other individuals within the organizations do their jobs to reduce friction — without compromising on governance. The goal of my framework is to balance the two.
Changes to our framework in the upcoming posts
My goal in the upcoming posts is to reduce the possibility of the type of compromises in the blogs at the top of this post and the Oktapus and Circle CI breaches.
Things we have already implemented:
Requiring MFA to assume roles to perform actions will make exposed credentials less risky.Limiting software installed on developer workstations limits what malware installed on the host can do.Limiting use of the AWS CLI to a private cloud network limits access to developer credentials, sandboxes malware, and reduces the chance of an abused session.
Additional steps:
Require multiple people for risky actions that could lead to account takeover or significant damage.Deny use of risky privileges unless they are absolutely required.Leverage a multi-account structure to limit certain services, users, and actions to a single account for easier management.Leverage SCPs for governance — by a governance team.
If we can move automation of organizational policies to a central team who manages that particular automation, then perhaps we can have true governance, instead of finger wagging and ineffective documents.
While we are architecting these security policies and frameworks, we need to ensure that the process is streamlined enough for people to get their jobs done as efficiently as possible. What they should not do is denied. At the same time they can still do what they need to do.
That’s not how our organization works…
These changes mean that some people within your organization might have to give up some control and they might not want to do that. I hear this all the time: “Well, that’s not how our organization works.” or “We are trying to ensure security does not get in the way of developers doing their jobs” which translates to “developers can do whatever they want and the security team operates in a reactionary mode when things go wrong to clean up the mess.” If that’s the case, then your job is really hard. Perhaps, impossible.
I would like to propose a way to make security and governance easier, while still allowing everyone in the organization to do their jobs. But we may have to take the time to explain to the people working in the cloud environment — and the executives — why the changes are needed. That was the purpose and topic of my book: Cybersecurity for Executives in the Age of Cloud.
We may need to remove some permissions from people in order to limit the damage in the event of a security incident or data breach. And we may have to ask them to contribute to security by entering an MFA code or taking a few extra steps to carry out a process — like collaborating with another team — to reduce the risk.
Follow for updates.
Teri Radichel
If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me 🙂
Medium: Teri Radichel
Email List: Teri Radichel
Twitter: @teriradichel
Twitter (company): @2ndSightLab
Mastodon: @[email protected]
Post: @teriradichel
Facebook: 2nd Sight Lab
Slideshare: Presentations by Teri Radichel
Speakerdeck: Presentations by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Buy me a coffee: Teri Radichel
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Request services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2023
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Would You Accept an Inconvenience To Prevent a Data Breach? was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
