CYBER SECURITY

Where and how are they…

[ad_1]

Security experts discussed the often overlooked area of ​​cloud security and provided guidance to companies working to strengthen their security posture.

RSA Conference 2021-The adoption of enterprise cloud technology has brought countless benefits, risks, challenges and opportunities to target companies and organizations. Even long-term users of cloud infrastructure and services can still learn one or two things about enhancing security.

(Picture taken from Adobe Stock)

Considering the year before this year’s full virtual RSA conference, during which companies increasingly rely on cloud services and strive to protect completely remote teams, cloud security has become a hot topic during the COVID-19 pandemic. Not surprising. The speaker explored the often overlooked gaps and provided practical guidance on how to reduce risks.

Palo Alto Networks Public Cloud Chief Security Officer Matthew Chiodi said in his RSAC speech on the subject that one of these blind spots is identity and access management (IAM) in the cloud. A general cloud account may have two roles and six strategies, but in most cases, determining what someone can and cannot do is very complicated and challenging.

He said that in most production accounts, Chiodi sees “usually hundreds of roles, or even thousands of strategies.” “It’s hard to understand what we mean by net effective licenses.” As organizations use more cloud accounts , The problem is magnified.

To better understand the severity of the problem, Palo Alto Network collected a “mass data set” of publicly available Github data: 283,751 files and 145,623 repositories, from which they were able to extract 68,361 character names and 32,987 potential cloud accounts. The researchers took the 500 most common role names and a list of verified cloud accounts, and used different combinations to spot potential misconfigurations.

He said that after discovering these configuration errors, they can access thousands of EC2 snapshots, hundreds of S3 buckets, and a large number of KMS keys and RDS snapshots.

Chiodi said: “When you have a compromised cloud account due to one of these types of misconfigurations, it is almost always much worse than a compromised cloud host.”

An attacker who can compromise a single host may be able to take advantage of errors and access data, but if network segmentation is done, they are usually restricted. For these findings, patches and multi-factor authentication are irrelevant because “[an attacker] When you encounter identity-based misconfigurations at the CSP level, you can interweave all these things together. ”

Infrastructure as code risk
Chiodi said that Infrastructure as Code (IaC) is a way to manage and configure infrastructure through code rather than manual processes. “For most organizations, it is indeed booming.” Although it brings security teams Benefits, but this strategy also comes with risks.

Palo Alto Networks surveyed nearly one million IaC templates found on Github. They learned that 42% of AWS CloudFormation template users have at least one insecure configuration, and more than three-quarters of cloud workloads expose SSH. 60% of users disabled cloud storage logging. Among organizations that configure cloud-native databases through IaC, 43% of organizations completely disable encryption at the database layer.

He said: “We found that when organizations rely on infrastructure as code to create their internal and even internal security boundaries, they expose sensitive ports such as SSH to the Internet 76% of the time.”

For Terraform, it allows organizations to use multi-cloud IaC templates in all major cloud service providers. Although the number is small, “consistent inconsistencies” still exist. More than 20% of Terraform configuration files have at least one unsafe configuration. In 67% of users, S3 bucket access logging is disabled; more than half of users have disabled object versioning.

Leak secrets in the cloud
Although most security practitioners know that accidental data breaches are a common cloud security problem, many people don’t know when they happen. This is the key to the conversation between Splunk’s chief security researcher Jose Hernandez and chief security research engineer Rod Soto, who both discussed the way company secrets are disclosed in public repositories.

In today’s environment, credentials are everywhere: SSH key pairs, Slack tokens, IAM secrets, SAML tokens, API keys for AWS, GCP and Azure, and many other keys. A common risk situation is that credentials are not properly secured and exposed, usually in public repositories – Bitbucket, Gitlabs, Github, Amazon S3, and Open DB are the main public repositories for software.

Soto said: “If you are an attacker and are trying to find someone, regardless of negligence or negligence, these embedded credentials can be reused, which will be the source of your leaked credentials.” Heyun.

Splunk researchers found that there are 276,165 companies leaking secrets in Github. The most leaked is the GCP service account token, which is visible in 34% of the cases, followed by “URL password” (30%) and AWS API key (12.7%). Hernandez said that when they saw the leaked secret, it took an average of 52 days to remove the secret from the Github project.

More organizations have “converged boundaries”, and he uses this term to define environments where the assets of these environments are both behind the Internet gateway (such as DevOps and ITOps) and in the cloud. In these environments, there are several attackers’ tactics, techniques, and procedures (TTP) that need attention.

One is to create temporary or permanent keys. “For example, we have seen a situation where developers have root keys on the AWS environment, which is terrible,” Soto said. He added: “Never give the root key; the principle of separation of duties and least privilege must be enforced… Once you have the root key, you can do whatever you want and take over it.”

Researchers say that other TTPs include creating trust policies and attaching policies to roles in AWS, and hijacking temporary tokens such as OAuth2 in GCP. Azure users should pay attention to creating new federated domains and service principals. He added that companies that own Active Directory Federation Services, Azure and AWS should watch out for fake SAML assertions.

Attack detection and defense strategy
Alfie Champion, a cyber defense consultant from F-Secure Consulting, said in a speech on attack detection at RSAC that it is more difficult to detect malicious activities in the cloud. This is not a secret. This is partly due to the uncertainty of bad behavior. Less movement in the cloud is obviously bad.

Champion said: “In terms of cloud inspection, context is becoming more and more important.” “As many of these API interactions progress, understanding the action, the intent behind the action and its context is critical to building high-fidelity inspection.”

A common mistake that organizations make when moving to the cloud is to aggregate contextless telemetry. There is no way to know which account the log belongs to, and there is no way for analysts to access the account to understand what they were doing when they were investigating. He said: “The disadvantages of one account may be beneficial to another account, and you need this to figure this out.”

Many people ignore the authentication log (the interface between the internal and the cloud and the management interface). He added that large organizations may manage various cloud accounts and may adopt a federated approach. These logs will provide meaningful correlations to the events they see.

It is worth noting that logging and threat detection look different for each major cloud provider, and administrators may need to take additional steps to ensure that they are receiving the required data. Brandon Evans, a senior security engineer at Zoom Video Communications, pointed out in his RSAC presentation that flow log records can indicate where the traffic came from, where it went, and how much data was transmitted, which may indicate potentially malicious activity but not enabled.

He said: “None of the three major cloud providers enable flow logging by default,” he pointed out that customers must explicitly opt-in and define log retention policies. He said that AWS, Azure and GCP all have different delays between triggering logs and receiving logs, and there are differences in the maximum log retention period, command line support and blocked ingress traffic logs.

Evans urges companies to ensure that cloud APIs and network flow logs are captured for each cloud provider they use. In the long run, when they discover weaknesses in the cloud infrastructure and configuration, they should work with the engineering department to strengthen permissions and use the principle of least privilege.

He said: “If we can completely prevent attacks, we absolutely should do so.” “However, monitoring and alerting are always needed to discover weaknesses that we have not yet discovered and fixed.”

For enterprises, it is very convenient to design a “cloud detection stack”, which can help extract the correct logs and display them in the correct way. F-Secure’s senior security consultant Nick Jones pointed out in a conversation with the champion that although the industry likes to talk about “a piece of glass” for this approach, he thinks it is “useful, but perhaps not necessary.” .

He said: “The real key is that attacks rarely occur in a single environment alone.” “Attackers are likely to try to rotate or move your local assets into the cloud, or vice versa, or between two environments. between.”

He went on to say that in light of this, analysts will need to look at logs from one data source and move on to the next data source. Although there are many data sources available, Jones recommends prioritizing control plane audit logs (such as CloudTrail and audit logs) to view all management operations. Service-specific logs such as storage access logs, function execution and KMS key access are also important because they show the access and usage of specific resources and services.

The champion said that it is never too early to threaten models and test offensive scenarios. How will an attacker target one of your assets? How will you subvert your security control measures? He suggested determining the organization’s key data, considering the attacker’s goal and starting point, and determining the priority of the attack path accordingly. What is their ultimate goal?

Kelly Sheridan (Kelly Sheridan) is a contributing editor of “Dark Reading”, focusing on cybersecurity news and analysis. She is a business technology news reporter. She previously reported on her in InformationWeek, where she reported on Microsoft, and reported on finance and economics in Insurance&Technology.

Recommended reading:

More insights

Related Articles

Back to top button