In recent days, new information about the Lapsus$ cybercrime group has emerged, providing new insights into the actual practices of cybersecurity adversaries. While it is unclear exactly who they are (the mastermind behind this group is reported to be could be a teenager!), or the extent of their achievements: Cloud security professionals can already learn a lot about best practices that reduce the threat of groups like Lapsus$.
You can read a lot about Lapsus$ activity elsewhere (in particular, we recommend Microsoft security blog post and the KerbsOnSecurity’s post) and the detailed response from Okta CSO about your incident, so what we will try to do here is summarize some quick and effective lessons/action items you can take from this incident to improve the security posture of your cloud environment.
The following recommendations aren’t new or sensational, but if ever there was a time to take advantage of the news cycle to boost your security, now is it.
The front line will be breached
What really stands out about Lapsus$ is its efforts to gain access using humans, whether it’s manipulating people, tricking cell phone providers (with SIM swapping), or even directly bribing employees to betray the trust of their employers and provide access to their resources.
This vividly highlights the fact that if humans work for you, you are vulnerable to social engineering. No one should be treated as incorruptible. But even if a person IS incorruptible, they may still be vulnerable to some of the other techniques the group has used, such as “implement Redline malicious password stealer to obtain passwords and session tokens”. The immediate implication for cloud resources is that you need to reduce the access permissions that people have to the minimum that they really need to do their jobs. Because the cloud often stores highly sensitive resources, giving excessive permissions to anyone who can be breached (virtually everyone!) can cause unwarranted exposure to the organization’s crown jewels.
You can adjust the size of access by limiting the permissions granted and placing security barriers on access to sensitive resources (this capability is granted by some of the major cloud providers). Providing the correct permissions in cloud infrastructure environments is technically difficult. On top of that, anyone who has ever tried to impose security restrictions on a development organization knows that it can also be a political challenge. It’s also important to define organizational roles and cloud entitlements so that no one person can cause too much harm.
In the specific case of the Okta incident, the breach (according to their statement) occurred because the malicious actor accessed a machine used by a support engineering contractor via RDP. As we all know, third-party personnel are legally and technically more difficult to manage, and therefore the principle of least privilege must be applied much more rigorously to the identities they access.
In addition to enforcing least privilege, you must prepare to handle a violation properly once it occurs. First of all, you need to have an effective logging solution that you are trained to use, so that when an investigation is required you can proceed quickly without having to start solving it at the worst possible time. Second, you must have a proper framework for reviewing and analyzing logs so that you can detect unusual activity, whether using a cloud provider’s native tool or a third-party solution.
Finally, prepare for a breach with an incident response manual that is well defined, accepted throughout the organization, and regularly tested. It is crucial to verify that all the necessary procedures and tools to handle a violation are only available and that the staff in your organization know how to use them. CISOs are often fired not because a breach occurred, but because the incident was mishandled, so their job may depend on it.
Stop using static credentials!
Sorry about the capitalization, but this is a very important lesson that we keep coming back to (for example, see our response to the log4j vulnerability) and it cannot be stressed enough how important this is.
As reported by Microsoft, as part of its kill chain, Lapsus$ are: “Search code repositories and collaboration platforms for exposed credentials and secrets”.
Finding static credentials stored in plain text is such an easy task for malicious attackers that, most of the time, its use could be considered negligent. For some APIs and SaaS interfaces, there is no alternative way to access them without generating static credentials, and then all you can do is rotate them frequently and store them only with secure encrypted tools that are designed for sensitive strings.
However, when it comes to cloud environments, there is almost always a good alternative to using static credentials and they should be avoided. It is especially critical NOT TO PROVIDE THEM TO THIRD PARTIES! We are going to hold a workshop on this very topic in a few weeks. Pay attention!
Track your inventory
Another interesting tidbit from the Microsoft report is that the group used asset sourcing as a key link in their campaigns, for example:
“leverage access to cloud assets to create new virtual machines within the target’s cloud environment, which they use as actor-controlled infrastructure to perform further attacks across the target organization”
While this is another great example of why you should always employ the principle of least privilege to prevent abuse and allow monitoring for anomalous behavior, it’s also a good reminder to keep a close eye on your inventory. Any computer resource can be used against you. Having a reliable and (at least almost) real-time inventory management solution is not only important for asset management, but also for security.
Your identity provider is not bulletproof
Finally, even if the eventual consequences of the attack on Okta are limited, in the wake of this event, many people were confronted for the first time with the idea that their identity provider is, in fact, susceptible to cyberattacks, just like any software or infrastructure.
When you federate your identity provider to your cloud environment, you delegate the ability to provide access to cloud resources to the identity provider (using the permissions you configure, of course). The identity provider will also be responsible for things like MFA enforcement for login or password complexity. Therefore, if the identity provider is breached, and in turn, user identities can be breached, it could have serious consequences.
Many businesses don’t realize that when they use an external IdP, they transfer much of the responsibility for setting up identity and access management to the cloud (which, under the shared responsibility model, belongs to you rather than the service provider). the cloud) to a SaaS platform. that’s not bulletproof.
Besides that, like we have shown in the case of AWS, an identity provider’s user federation can make it quite difficult for you to investigate each user’s activity separately.
For these reasons, enforcing the principle of least privilege for identity provider federated identities is especially crucial, and implementing a logging platform that makes it easy for you to investigate and audit each federated user’s activity separately should be an important part. of your security framework. .
If there’s one thing we can take away from the reports of this cybercrime group, it’s that it probably doesn’t take a nation state to break into big corporations. No organization should take these kinds of threats lightly.
If you’re managing an enterprise cloud security strategy, such a high-profile event can be a great opportunity to raise awareness (and perhaps some budget) to implement the lessons outlined here. Make sure you make the most of it!
The charge Lessons Learned in Cloud Security from Lapsus$ Surfacing first appeared in hermetic.
*** This is a syndicated Security Bloggers Network blog from hermetic written by Ermetic Team. Read the original post at: https://ermetic.com/blog/cloud/lessons-learned-in-cloud-security-from-lapsus-surfacing/