Author: Team Solvo

On February 23, 2023 Shira Shamban and Vandana Verma gave a session about popular challenges in cloud security, and successful mitigation strategies.

If you’ve missed the session and wish to watch it, visit EliteCISO’s Youtube channel here. The event was followed by a Q&A session. Due to high participation we couldn’t answer all questions live, so we’ve decided to share this blog with answers to the questions we didn’t have time to answer. The Blog has 3 sections, to make it easier for you to focus on what matters to you:

1.    Security processes
2.    IAM Permissions, Shared Responsibility Model and Liability
3.    Solvo

Security Processes

Q: Some of the challenges discussed are covered by documentation, the real challenge is implementation and validation. What do you think?

A: Proper documentation can help prevent misconfigurations and docs are updated as part of the process. ISO mandates all changes to be recorded.

Like in many other security processes, documentation is an important part but not the only important part. Documentation is important for knowledge and best practices sharing, along with understanding of our application, processes and procedures.
It’s important because one of those days we will ask ourselves

Q: “why did we do it this way?” or “how did the team do it before?”.

A: The documentation will help us to create relevant tests and validations, to make sure our data and secrets are protected, that our authentication mechanisms work as expected and allowed actions are ran by allowed entities.

Changes in security IAM policies are good to document for a few reasons:

1.    Know when a certain change was made
2.    Know what change specifically was made
3.    Be able to revert if necessary
4.    Have a log to investigate in case of a potential incident

Logging of policy changes can be done in your ticketing system (like Jira), in a document or in Solvo’s timeline.

Q: Companies harden the external security landscape, but forget about internal security, one lope hole and threat actor go wild doing lateral movement. How do you suggest handling this?

A: This is very true and unfortunately many security practitioners don’t put enough attention on this. Security strategy is based on layers, because we always assume that at some point, one of the layers will get cracked and exploited.

We can create the best and tallest fences on the external perimeter, but it’s enough for one engineer to fall for a phishing campaign to get an attacker in your cloud account. And then what? If you don’t take good control of the permissions and access controls from within the cloud account and application, it’s game over.

That’s why we need to understand the architecture of the application, and the places where we should put controls and guardrails, based on the risks and crown jewels.
For example, if you have an instance with full access to all of your S3 Buckets, while it only needs a specific read permission from one S3 Bucket, by allowing the full access you’re creating a huge attack surface.

That is why you need to create a specific IAM policy, allowing that instance the specific access it needs, to the specific resource.

Solvo is generating applications-aware IAM policies, for all cloud components, automatically. Making it very easy to become least-privileged and compliant and maintain that status all year long.

Q: How do I solve the IAM issues if I have deployments spread globally and I am using a hybrid-cloud-architecture? How do I handle local regulatory requirements?

A: Compliance regulations change from one geography to another. Even though that means we need to become familiar with unique requirements, sometimes a process we did for one framework helps us with other, similar frameworks.

For example, the CPRA regulation that came into effect January 1st, 2023 is all about privacy of the residents of California, but it has some similarities to the GDPR. If you did a GDPR readiness process, the CPRA process will be fairly quick and easy.
Solvo has a compliance module that is based on the OPA project.

This open-source enables you to easily create guardrails, based on compliance regulations or crazy ideas that you came up with. The rich ecosystem around it provides more rules that were written by other contributors, and supported by other security vendors.

This way, you can create one repository of compliance rules and implement it in different products.

IAM Permissions, Shared Responsibility Model and Liability:

Q: Can you shed some light on the security responsibility – where’s the line between the cloud user and the Cloud provider? Can you elaborate about the shared responsibility model including the indemnity and legal liability?

A: The shared responsibility model is an important principle to understand when using the cloud. I’ve heard people say “I put this data in the cloud and therefore it’s secured”. But this is the wrong approach.

Cloud vendors are responsible for certain things, while we, the users, are responsible for others. It is up to us to configure the infrastructure correctly and make sure our code is secure. It’s worth mentioning that in December 2021 AWS had a security issue where the Support Service Role was granted with S3:GetObject permissions.

While according to AWS, it was impossible to exploit that permission, we need to understand that when using AWS managed policies, such things can happen. That is why using AWS managed policies is not a best practice.

What you should actually do is customize the IAM permissions based on the needs of your organization and application. This requires time, deep understanding of application logic and continuous maintenance.

Solvo’s policy manager capability was created to do all the heavy lifting for you. By analyzing the behavior of the application, Solvo is able to understand what exact permissions are required, create them in IaC or CLI formats and ship them to the ticketing system of your choice for enforcement.

We make the process of understanding the app, building the policy and the maintenance automated and easy.

Q: I am a cyber risk insurance consultant and not a cyber risk professional. What are the best practices we need to adopt for IAM?

A: Thank you for creating awareness for cloud and data security in the risk insurance industry. There are some practices that are extremely easy to implement for you as a consultant, and that would help your customers to improve their security posture and resilience:

1. 1.    List ALL data resources (even the ones that are called “test” or “research” and people think for some reason that are not important). We should assume all data resources are at risk to contain sensitive information.
   2.    Know ALL admin and high privilege users and make sure they actually need those permissions.
   3.    Create user groups and use them to grant permissions.
   4.    Run a scan to see which resources have direct or indirect internet access.

This short list of tests is the very basic checks I think you can and should run when meeting a customer. It doesn’t require deep DevOps capabilities and it will give you and your customer a good idea about their security posture. The next step is to encourage them to monitor changes and drifts from what we know, and put guardrails for specific violations.

Solvo is used by auditors and professional services companies to run periodic audits for their customers. In our Compliance Manager module, the auditor creates a bundle of rules that is relevant for his client, they can present the gaps, suggest remediations and even offer a monitoring service to make sure the good compliance posture we have is maintained and improved over time.

Very few of us do a continuous post-implementation review as part of SDLC. Either because we don’t have the right tools or don’t have enough bandwidth. Oftentimes, changes are made without a change approval process and these create gaps.

So from a policy documentation point of view we may have everything as expected but implementation fails. What is your best practice?

Q: How can we check suggested changes before applying them and before a possible security issue occurs?

Injecting Security Awareness is a cultural change and takes a long time.

A:There’s a tension between writing documents and protocols vs. implementing them and measuring their impact. What you’re saying is that you might write the best protocol or policy, but if it’s not implemented correctly we’re going to lose.

We like to stay that security is first and foremost an issue of culture, and making changes to culture is nearly impossible. If people don’t have security at mind they will not truly embrace the great protocol you wrote. That’s why we use security tools that hopefully will integrate well with our existing flows and will help us to achieve the missing parts.

When we started to build Solvo we knew we’re creating a security tool that has to work well with several types of users – security executives who want to get an overall picture, security engineers and DevOps who need to handle specific security issues and make infrastructure-related decisions, and developers who might need to enforce security policies in a way that fits their application.

We know we have to build a product that will not make the developers work very hard, but quite the opposite – will be super easy to onboard, will create the fix they need to enforce, and codify it for easy enforcement. Software should work for us and not the other way around.

One of the capabilities in Solvo it to test the suggested security policy, this way the DevOps of security engineers can gain the confidence they’re making the right decision.

Most of the cloud breaches are due to a misconfiguration. We need to ensure secure configuration and also have processes (Automated & Manual) to identify gaps in configuration. What are the best practices? Gap analysis is key.

Agreed. It’s not enough to run an assessment before your SOC2 audit, because the day after you might realize that one of your team members forgot a sensitive S3 Bucket available from the internet. You need a continuous process that will check for violations and drifts, prioritize them based on the risks and blast radius they have in the account and hopefully suggest a remediation plan.

Solvo’s Posture Manager is doing just that. It continuously checks for violations, misconfigurations and vulnerabilities, correlates that with other risk factors to understand the potential impact on the cloud account, prioritizes findings so you know what’s critical, and also creates the remediation plan.

About Solvo:

Q: How is Solvo different from tools like Azure Sentinel? What additional features does it have?

Cloud vendors have some built-in security features. Each vendor has slightly different capabilities that compliment their infrastructure. Some products have configuration analysis (do you have any wildcards or open ports), some have vulnerability analysis (with an agent or by taking a snapshot and scanning it).

Solvo’s unique value is by analyzing both the infrastructure, and the application behaviour! This way, we’re able to identify misconfigurations, and to create new configurations based on the unique needs of the application.

Q: What should I use CASB, CWPP, CSPM, CIEM,CNAPP?

A: Those categories can get very confusing when looking at cloud security solutions. There are some overlaps and similarities between the categories, and one product might fit several categories.

Solvo is analyzing the cloud infrastructure configuration, the application behaviour, outputs from other security products you might be using and out of that produces the remediation. One thing Solvo doesn’t do is install an agent, or take snapshots of your resources. This is more secure and also cost effective.

Q: How is Solvo licensed?

A: Solvo is a SaaS offering, and pricing is tiered by the number of compute and data resources you have in your account. To get a price estimate, you can start a free trial here.

Q: In your experience, who owns Solvo in an org? Security team or SRE/Cloud team? If it’s the security team, it will act as a consulting engagement. Or SRE/cloud team, where security teams keep chasing them for patching issues. If it’s the SRE/cloud team, can Solvo be integrated within their workflow so they feel accountable for cloud security issues and it gets solved at earliest?

A: Solvo can accommodate several different use cases and help different teams, that all depends on the company structure and processes:

Security team – this team is usually responsible for the overall security posture, sometimes also compliance, and in recent years also data security. As Solvo users, the security team will observe the trends of security and compliance violations, get notified for critical vulnerabilities, misconfigurations and risks and also be able to create guardrails and standards that once in place, will let you change the security into developer-friendly ones.

Solvo’s graphs make it easy to have a fruitful conversation between security and other teams and partners, when everyone sees the components, applications and actual use on one screen.

SRE / Cloud team – this team is responsible for the overall infrastructure availability, stability and scalability. They will need to resolve misconfiguration issues that were found by any security product that you use.

Solvo is generating the remediation for these findings, as IaC or CLI command. That’s why, integrating Solvo with the existing CI/CD processes to resolve them quickly and efficiently. With Solvo the team can see the existing security configuration, the suggested / ideal configuration, and a test capability to check the suggestion.

R&D team – this team is not only responsible for writing and shipping code, today writing a cloud application includes making changes to the infrastructure. When a security issue is detected, the app owner will decide how to handle it, with the help of the security and DevOps team.

By using Solvo, the team can understand who’s the app owner, prove which components are in the blast radius of the security issue, and get the remediation that will fix the problem and not break the app.

Q: I wanted to ask can Solvo be useful in the Indian Public Sector, which is still hesitant to go to the Cloud?

A: Many organizations still struggle with cloud adoption. Some need to migrate existing applications, while others wish to write new cloud-native applications but lack the knowledge of how to do it most efficiently.
For the migration use case, Solvo helps by saving hundreds of hours of redesigning the new security configuration the migrated application would require. Solvo analyzes the bahviour of the application and creates the new security configuration, thus helping to migrate easily and securely, while trusting the cloud.

For the cloud-native application, Solvo helps all teams to build a healthy security culture, holding users accountable while equipping them with the tools to help them make smart decisions faster.

Q: What are Solvo’s benefits compared to other CSPM tools?

A: The differences are below. If we look of the core differences, these would be the application analysis provided by Solvo, along with the accurate remediation that saves time and reduces risks.

New Year’s resolutions aren’t the only thing you should be preparing for this time of year. January 1st, 2023, CCPA will come into effect. The CCPA (California Consumer Privacy Act) is, in a way, California’s version of the EU’s GDPR regulation with the purpose of protecting PII / customer data.

While there are some differences between the two regulations (for example, CCPA protects ‘consumers’ while GDPR protects ‘data subjects’), their goals are similar – protecting the data that could identify people and holding businesses accountable when storing it or using it.

After some delays, CCPA is almost here, so you better start preparing. Even if your business is not located in California, but you’re doing business there, CCPA applies. If you own, are owned by, or share branding with a company that the CCPA applies for, it might be applicable to you too.

For your business to comply with CCPA (or other similar regulations), you should have a good understanding of the type of data that you store, how it is stored, and who has access to it – should a customer ask to know more about it or ask to delete it.

While controlling data in large organizations is known to be a tough task, for organizations in the cloud it gets a little tougher. Usually, because there are more people with access to the infrastructure and the loss of control over some workflows. For example, you could find dumps of your data in non-production environments because developers ran some tests and left them there.

The security team doesn’t know it’s there, and therefore cannot guarantee that it’s well protected. If you don’t know it you can’t protect it and therefore might violate the regulatory requirements.

Some people believe that if they are using the public cloud (AWS / Azure / GCP or others) they are protected and compliant, but this is far from the truth. By now you’ve probably heard about the Shared Responsibility Model.

It means that there are some things the cloud vendors are responsible for, like the hardware and the software that is used to run it. But you are responsible for how to use it and what it is used for.

So configurations, encryption and even patching the OS are some of your responsibilities. The basic principles of being compliant in the cloud are not very different from the on-prem. We just need to make some adjustments as to how we become and remain compliant in the cloud.

Here’s a list of a few things you should check and ask, to feel more confident when CCPA comes into effect:

1. Where are my data resources? Where is my data stored?

“In the cloud” is not the correct answer. You’re probably managing several cloud accounts, with different users having access to various accounts, some are production while some are not.

So where did you say the data was? Most cloud users don’t even know how many blob storage components they have.
To have a good answer to this question, you need to have an understanding and control of your inventory. Data resources included.

How Solvo helps:

In the Solvo console, you can get a list of your data resources by type and per account. This way you can control any data resource one of your team members spun up.

 

If you want a general overview of the number of resources you own in the cloud and data resources being a part of that, you can check out Solvo’s dashboard and look at the inventory section.

 

2. How is this data protected? Is it encrypted?

There are several best practices for data protection. Encryption is probably the most basic and most useful one. If you have a data resource, use encryption. There is no reason not to do it since this technology is practically baked into any data service you wish to use.

Often R&D teams think “it’s just a tiny dump” or “I’ll just test with this data set and then delete it” but they fail to realize and understand the sensitivity of the data at hand. Due to this, you must enforce the encryption policy at all times. In the first section, you discovered your data resources, and now you need to make sure that all of them are encrypted.

How Solvo helps:

Solvo’s Compliance Manager is a powerful tool that helps you validate your compliance status for different regulations out of the box, or create your own rules you wish your organization would comply with, using the popular OPA open-source project and their useful Rego language.

This way it is easy to see which data resources are not encrypted. Even if all your data resources are encrypted at this very moment, we never know what tomorrow will bring – maybe someone will expose an S3 bucket to the internet (by mistake of course), while it contains unencrypted data? The Compliance Manager will notify you of a new violation of the compliance rule that you have enabled.

Below is an example of a Rego policy that checks if S3 Buckets are encrypted. By activating it, you will get a list of all unencrypted buckets, and will be notified if new buckets are created without adding encryption. In a similar way, you can create or use out-of-the-box compliance rules easily.

If you’d like to create your own rules, that’s very easy to do using Solvo’s Compliance Manager.

And then track the violations in the Compliance Manager screen, like this:

3. Who has access to this data?

So now you know where your data resources are, and that they are encrypted the right way. Now let’s check who has access to them, and what kind of access they have. By “who” it means you need to check which users have access to the data, and also which other cloud components have access to it.

Other cloud components could be compute resources, but also users and 3rd party’s external cloud accounts. It’s important because malicious activity can be done not only by users directly, but also by users who can trigger other cloud components to run activities for them (like making a lambda function read an entire DB and write it in another DB for which they have access).

Now that you know who has access, you should check what kind of access they have. You probably heard about the least-privileges principle. That means we should grant only the necessary privileges to the ones who need them.

Therefore, if you have a container that only needs to read an item out of a specific DynamoDB, there is no need to grant it full read/write permission, just let them do what they need to do.

How Solvo helps?

To better understand who has access to your data, and what kind of access they have, Solvo created the IAMagnifier. This powerful tool shows you a graph of your inventory, including the permission model, that’s enabling access of any kind.

The IAMagnifier is turning the complicated permission model into a clear and actionable graph. Using the IAMagnifier you can inspect your crown jewels, create notifications, should a new permission be added, and be confident that once you’ve reached compliance things will remain this way.

The IAMagnifier shows you not only the existing permission model but also which permissions are excessive. Having excessive permissions hurts your compliance and is making your application exploitable. With the IAMagnifier you can safely remove excessive permissions, as they are unnecessary for the functionality of the application and could be used for malicious purposes.

 

4.  What should be the right-sized permissions?

Cloud applications are dynamic and change frequently. This means that to remain least-privileged, the security permissions should change and adapt to the application in the same cadence.

You need to verify that your permissions are just what the application needs. Having too few permissions would cause denied actions, and having too many permissions create an attack surface.

So check the IAM policies, who has them, and who uses them, remove unused roles and look for “surprises” in your IaC files. Try not to use wildcards, there are rarely any real use cases to do that. Also, try not to use the security policies created by the cloud vendors since they are generic and very broad.

How Solvo helps?

Solvo can right-size permissions for you, from the data resource standpoint (S3 resource based policy for example) and also from the compute resource standpoint (Identity IAM policy for your Lambda function’s role for example).

This happens automatically and continuously. Should anything change in the application that would require a change in the security policy, Solvo’s Policy Manager will detect it and send a suggested IAM policy for your approval.

Below we have two examples for the two policy types mentioned:
S3 resource based policy for a bucket (in this case, a bucket that stores CloudTrail logs), making sure only the necessary actions can be executed.

Below is an example of an IAM policy of a lambda function that needs to read out of the CloudTrail S3 Bucket. Solvo generated it automatically and based on its specific applicative needs. The access is granular and gives the specific actions the Lambda needs to perform, on the specific resources.

 

5. What’s changed? Do we have any drifts?

Once you successfully pass the security audit you can forget about data security until next year. NOT! You actually need to maintain this great accomplishment until next year’s audit, and also in general because it’s the right thing to do.

Therefore you need to make sure that you are aware of any drifts from the existing status, either in existing cloud assets or in new ones that will be spun. You should also make sure to fix vulnerable and misconfigured cloud assets within a reasonable period of time. The longer it takes, the bigger the chances are that someone will exploit the situation, and you will have to pay $$$ in fines.

How Solvo helps?

The new Data Posture Manager is here to help you. This feature shows a prioritized list of your security, risk, and compliance findings. It will point you to where your attention is needed the most, and provide you with actionable insights and remediation options for the specific finding.

The prioritization is based on our dynamic risk scoring algorithm and brings into consideration misconfigurations, vulnerabilities, connectivity to other cloud components (and their vulnerabilities), paths to sensitive data resources and business impact. Your cloud application is dynamic, and so should the prioritization you’re working by.

When combining Solvo’s Compliance Manager with the Policy Manager you get a powerful capability to detect drifts from current status or best practice, along with a clear remediation you can easily enforce as part of your CI/CD process or change management process.

Consume Solvo’s findings and least-privilege security policies through the ticketing system, IM, or other workflow management system of your choice.

Below is a prioritized list of findings, all related to the data resources in the account and have an impact on our crown-jewels, even if not stored there directly. Always consider the blast radius and how attackers can make their way from the internet to your data.

 

Prepare yourself for the CCPA today! See your environment through the IAMagnifier, understand your risks with the Data Posture Manager, and fix them with the Policy Manager.

Start a free trial, check us out on the AWS marketplace or watch our CCPR webinar to learn more.

Redmart Data Breach

In September 2020, Singapore-based online grocery store, Redmart, experienced a data breach that exposed the personally identifiable information (PII) of over 890,000 of its customers.

The breach, which occurred due to a misconfigured AWS cloud resource, resulted in the exposure of customer names, passwords, and partial credit card numbers.

According to an article, the Redmart internet-facing web server was connected to a storage server that was neither encrypted nor password protected. All ran with an AWS account with high privileges.

The consequences of this breach were significant for Redmart and its customers. In addition to potential identity theft and other forms of fraud, the company faced significant reputational damage and financial losses.

As a result, the company was required to notify the affected customers and regulatory authorities and implement additional security measures to prevent similar incidents from occurring in the future.

One of the key compliance implications of this breach is the potential for regulatory fines and penalties. In Singapore, the Personal Data Protection Commission (PDPC) has the authority to levy fines for data breaches that involve the unauthorized disclosure of PII.

In this case, Redmart was fined S$72,000 (a little over $50,000) for violating the Personal Data Protection Act (PDPA).

In addition to regulatory fines, Redmart risks legal action from affected customers. In cases where companies fail to adequately protect customer PII, they can be sued for damages, such as the cost of credit monitoring or identity theft protection services.

The Redmart data breach serves as a cautionary tale for businesses of all sizes that use the cloud and store sensitive data.

It highlights the importance of properly configuring and securing cloud storage systems, controlling access to the account and the resources, as well as the need for robust incident response plans in the event of a breach.

Ultimately, companies must prioritize the security and protection of customer PII in order to avoid regulatory fines, legal action, and reputational damage.

This means implementing strong security controls and regularly reviewing and updating them to ensure compliance with relevant laws and regulations.

To learn more about the risks and mitigations in the cloud for the retail industry take a look at Solvo’s use case.

In addition, it’s not too late to prepare yourselves for the CCPA regulation adjustments. Join Solvo’s webinar and learn what you need to do here.

Cloud data security is a hot topic these days. According to a Cloud Security Alliance report, 67% of organizations host sensitive data or workloads in the public cloud.

This leads me to believe that the other 33% don’t actually know that they are storing sensitive data in the cloud.

Data security becomes a major concern when it is not handled and protected in the appropriate manner which leads to the possibility of your data being stolen, encrypted and held for ransom, and published online. All of these might lead to business disruption, money loss and fines to be paid.

In the cloud, it’s important to understand that protecting a specific data resource or blocking its internet access is simply not enough. Based on the security configuration of the cloud components (users, cloud resources), gaining access to a data resource from the internet, whether from an external cloud account or via another misconfigured entity, is still possible.

So, how do you get a hold of the security posture of cloud resources and the risk they impose on data resources? Solvo is thrilled to announce the release of Data Posture Manager (or DPM)!

We know that security products create excess noise and stress when producing various alerts and notifications thus adding to the existing alert fatigue and creating more anxiety.

This is why the DPM is equipped with an advanced scoring algorithm, prioritizing the findings based on: vulnerabilities, IAM permissions of the data resource, the connected resources (depending on how accurate or excessive they are) and, direct and indirect network access, blast radius, and business impact.

This unique scoring mechanism is different from what you’re used to using in other products. Instead of a static and predefined score per violation, the DPM’s scoring algorithm is dynamic and takes into consideration different parameters to provide the most relevant findings first.

These prioritizations allow the security team to focus and spend their time on specific issues that will have the most impact on the overall security posture.

When taking a closer look at one of the findings, we can see the specific risk factors the Solvo algorithm brought into consideration when creating the scoring.

 

In the finding above we can see an EC2 instance with a risk score of ‘High’. The risk factors that impacted this score are: ‘Too broad permissions to a data resource’, ‘Publicly exposed’, ‘Can read from all S3 Buckets’ and ‘High severity CVE’. If you’re wondering how we get to that, you can see below the permissions graph, generated by the IAMagnifier.

The attack surface starts from the public internet, with specific Security Groups enabling access to the EC2. We then follow the graph toward the left side, and see that this EC2 has a security policy called

“AmazonS3ReadOnlyAccess”, that contains a wildcard and enables access to all the S3 Buckets in the account. This broad access is marked as a wildcard (*) on the right side of the graph. Note that the IAMagnifier marks this access in orange, and lets us know that it is excessive and can be reduced.

It’s easy to see how different components are taking part in the (in)security of the data stored in the cloud. In order to protect this data resource we need to make sure that no other resource or identity is directly or indirectly connected to it and therefore  does not pose a threat.

When we want to understand the blast radius, we must understand that a single cloud resource probably has access to dozens of data resources due to the fact that we reuse security permissions, use wildcards, and attach managed policies (managed by AWS or even by the security team).

Thus creating a security policy that is generic to a certain extent and has some degree of freedom. Ideally, we would like to have a custom-made security policy for every cloud component, making it least-privileged.

In the image below we can see that the EC2 machine has access to 42 data resources, and Solvo even points out the sensitive data resources (with the orange exclamation mark), because some of your data resources create a different (and higher) kind of risk.

 

The divine ideal of customized security policies based on the needs of each component is not a dream. Solvo provides it as part of our Policy Manager capability.

In the example we are going through, we saw an EC2 machine that has read access to S3 using an AWS managed policy. This is the security policy you can see on the left side of the image below.

 

Using AWS managed security policies is a common practice, but since this security policy is generic, it always contains a high volume of excessive permissions.

In our example, the “AmazonS3ReadOnlyAccess” allows the EC2 to read data from ALL S3 buckets, without any limitation, while based on the application’s needs, this EC2 machine only needs to read data from  a specific bucket.

On the right side of the screen we can see Solvo’s suggested IAM policy. The policy was generated after analyzing the application’s behavior and understanding its context.

We can see it generated a least-privileged security policy. This policy allows to perform the “GetObject” action from a specific bucket and even points at the specific partition in the bucket (path), where the relevant objects are.

To complete the process, Solvo helps you to remediate these security findings at scale by integrating with your IM, ticketing, and security orchestration tools, where you can get notifications about new security findings and their correlating remediations. Prevention, detection and remediation were never easier.

To learn more about what YOUR cloud application looks like, its top risks and vulnerabilities, click here and get started!

Cloud Security just got more colorful

Understanding your IAM permissions model is hard as is. Let alone when you need to manage production applications with hundreds of components and thousands of entitlements.

As a result, Solvo created a visualization tool called IAMagnifier.

We know that visualizing components and permissions is only the first step in creating a least-privileged security configuration, so we’re happy to introduce our color-coded permissions map!

On this map, as before, you can see your cloud components (storage, compute assets, network assets, external accounts and users), along with the IAM roles and policies that enabled access between them.

Starting now, the access arches connecting those components will be highlighted in a color that describes their necessity, or how excessive this connection is.

As you recall, IAM permissions are not a yes / no kind of access. You can state specific resources and sub-resources, specify the necessary actions (read, write, delete, etc.) and even add conditions.

These permissions should be as granular and specific as possible to limit a blast radius should your account, credentials, components or users get compromised. The more granular – the better!

When highlighted in red –  this connection is completely excessive. It was not used for a long time, or even never at all. Your application doesn’t need it in order to perform the actions you wanted it to perform. Go ahead and remove it.

When highlighted in green – you’re all set! This policy is well configured and only allows the necessary actions.

When highlighted in gray -More information is needed in order to provide a recommendation. You should be aware that in theory, an action between these connected components is possible, and if you think it shouldn’t be there, make the adjustments. It might also be that you can terminate these assets.

When highlighted in orange – this connection is necessary, but is too broad and can be fine-tuned and specified.

You’re probably wondering how to reduce this connection and make it less-privileged. But this is actually very easy. Just visit our Policy Manager page, and get the new IAM policy your component needs, in your favorite format (raw, Terraform, CloudFormation or CLI command).

Want to get your copy of a green-looking IAM map? Start a free trial, fix your misconfigured IAM policies and be the CISO’s hero!

The recent Okta security incident made us think about the dangerous combination of two equally cruel to exploit vectors – the 3rd party (or supply chain) along with the identity provider. This is a dangerous combination!

Identity and access management (IAM) is a cybersecurity framework with a predefined set of policies, processes, and tools for defining and executing individual network roles and access privileges to various cloud and on-premises apps.

An IAM solution or tool is crucial in connecting and integrating your business with different people and resources. It is a must-have solution (as a part of a greater plan) to prevent data breaches and maintain the integrity of your business data. Thus, the IAM market will likely rise from more than $20 billion by 2024.

The data hacking incident on IAM tools like Okta, NVIDIA, and Microsoft is alarming for businesses.

On March 22, a series of screenshots were published online on Telegram from a system used by one of Okta’s third-party customer support engineers. 2.5% or 366 of Okta’s customers got impacted by this incident.

Okta is a popular authentication service used by thousands of governments and organizations globally as a single sign-on provider. It enables employees to securely access the company’s internal network and resources like apps, calendars, and email accounts.

The Lapsus$ hackers’ group claimed that it had breached the identity management platform Okta by infiltrating one of its customers, Sitel, back in January. A report further revealed that LAPSUS$ used tools like Mimikatz to extract passwords to gain more access to Sitel’s systems.

The extortion hacking group has previously targeted customer support companies having weaker cybersecurity defenses. Microsoft, NVIDIA, and Roblox have also experienced similar data compromise of customer support agents’ accounts that led to access to their internal systems.

At first, Okta dismissed the news about the attack and associated it with an attempt by hackers in January to compromise a third-party support engineer’s account. But later, Okta has admitted that it made a mistake by not telling customers about the security breach in January.

Okta’s Chief Security Officer David Bradbury in a statement, said that:

“We concluded that a small percentage of customers, approximately 2.5%, have been impacted and whose data may have been viewed or acted upon.”

He further added; ”We have identified those customers and directly contacted them. If you are an Okta customer and have been impacted, we have already reached out directly via email.

We are sharing this interim update, consistent with our values of customer success, integrity, and transparency.”

Okta is facing a considerable amount of backlash and criticism from the security community for its poor handling of the compromise and the months-long delay in informing the customers.

A Timeline of What Happened in the Okta Attack?

After accepting the data breach incident, the Okta CISO wrote a blog on their website. This blog highlighted the events that led to the attack in chronological order. According to the blog, here’s what happened:

• • 1. On January 20th, 2022, a third-party customer support engineer working for Okta had their account compromised by Lapsus$.
    2. The Lapsus$ hacking group looked for information on Okta customers and not Okta directly.
    3. The hackers breached information from up to 366 Okta customers. Per Okta, the data accessible in this breach was limited. But it was worth mentioning that Lapsus$ denied this statement, claiming the ability to reset MFA factors and passwords.
    4. The incident was mitigated within a few hours of the initial compromise and remained no longer a security risk per Okta.
    5. On March 22, 2022, Lapsus$ leaked and posted screenshots of the compromise on Telegram.

Choose the Right Solution

Whether you are an Okta customer or not, we encourage you to take the following steps to protect your data and business:

1. 1. 1. Review policies and procedures with any organizations involved within your supply chain.
      2. Review the logs in your Okta tenant from January to March 2022 and identify suspicious activities, including MFA and password resets.
      3. Use suitable DevOps tools.
      4. Enhance your security by using cloud providers or identity and access management platforms like Solvo.

Solvo automatically manages identity and access management for users and cloud assets, ensuring you’re always the least privileged.

Solvo has introduced the IAMagnifier feature that checks and views any unnecessary entities that can read your sensitive data.

This approach reduces the attack surface and potential blast radius.

Start a free trial now, or book a demo.

By 2030, the cloud computing market is reaching $1,554.94 billion. As the industry grows, the risk for identity fraud and theft also rises within an environment where the data is shared with multiple users. Thus it has become crucial to undergo a cloud audit.

Cloud computing audits are becoming increasingly important. The primary purpose of the audit is to keep a check and balance on the available data and improve the overall security and performance as ensured by the cloud service provider.

Prime Objectives for Cloud Computing Audits

The prime purpose of cloud computing audits is to ensure that data integrity is maintained. This way, businesses can prevent unexpected incidents or cybercrimes that might target the cloud environment and what’s in it.

Moreover, companies can look over their processes and systems and ensure they remain updated by auditing the cloud on a periodic or ongoing basis.

Some other objectives or reasons for performing cloud audits are as follows:

• • 1. Risk Management: Management should document those risks that don’t comply with the company or the regulator’s objectives. These risks include security vulnerabilities and violations of any law.
    2. Identify Vendor Management Security Controls: As cloud-based companies rely on other vendors like AWS, Azure or GCP to host their cloud infrastructure, they need to identify the risks that can affect the sensitive information.
    3. Define IT Processes and Relationships – To create processed documents and a standardized and stable IT environment. Businesses need to implement policies that include organization structure, responsibilities, risk management, incident response, and recovery plan.

Pitfalls During Cloud Computing Audits

Cloud computing audits have been around for a few years, but many companies are only now moving their data to the cloud and are learning how to perform audits on their cloud environments.

You might not be aware of this, but some pitfalls actually occur during the audits that can risk the business and data.

Thus, it’s essential that you remain aware of the mistakes and avoid them in the future by creating simple preventative mechanisms.

1.     Neglecting Encryption

The most significant mistake while performing cloud audits by neglecting encryption.

When the data is not encrypted on the cloud, or if the encryption keys are not kept secure, it is easy for hackers to access the information stored on the cloud.

Encryption is a must. It is the only way to guarantee that your data is safe. Cloud audits should ensure that all data is encrypted while in transit and at rest.

You should also ensure using an encryption algorithm approved by the National Institute of Standards and Technology (NIST). Don’t forget that encryption keys should be kept properly too.

We’ve seen them kept in plain text in the past and that’s far from best practice.

2.     Misunderstanding of the shared responsibility model

There is an agreement between the cloud infrastructure providers and the users, that basically says that the first ones are responsible for the bare metal and its availability, while the second are responsible for what’s kept on it, and its configuration.

This trust relationship is crucial, but it should not be taken for granted. Back in December 2021 AWS made a mistake in one of its managed S3 Bucket policies, theoretically exposing the data of countless buckets for 8 hours.

Despite all the concerns, organizations can tackle this issue easily. By using Solvo’s Policy Manager, you can be assured as it will create and enforce least-privileged policies across all assets.

Also, the SecurityGenie provides insight on the severity of security issues and possible attack vectors targeting your cloud data.

3.     Lack of Visibility

It’s not uncommon to outsource some of the IT or security management. As a result, the app owner finds it difficult to get a detailed view at their infrastructure, potential risks and compliance status.

In hybrid environments it gets even more complicated. Lack of cloud visibility affects the overall performance tracking, security, and costs.

Cloud-based organizations can maintain high visibility by trusting a reliable cloud management platform like Solvo that provides comprehensive infrastructure visibility.

Solvo’s IAMagnifier feature takes control of your cloud security and risk visibility. It shows you which entities should be restricted (for example, if they can create a new AWS user while they shouldn’t).

Also, on the IAMagnifier screen, you can ask for your check and view any unnecessary entities that can read your sensitive data.

Moreover, when Solvo is integrated into the cloud infrastructure, it analyzes all the assets in the cloud and flags them for review.

4.     Maintaining Compliance

Another major pitfall during cloud audit, and in between audits, is maintaining regulatory compliance and practicing the best cloud security practices. SOC2, HIPPA, ISO, CIS, and NIST are the compliance standards that almost every organization follows at least one of them.

In the past organizations would just prepare for an annual audit, but as incidents and data leakage are becoming unfortunately popular, you should consider implementing a continuous and automated solution.

By choosing suitable cloud management platforms like Solvo, you can automatically maintain cloud compliance.

With Solvo’s Compliance Manager, compliance is not a separate task; it’s built into how you secure your cloud-based infrastructure and entitlements.

It can help you get the proof of regulatory compliance and data hygiene with verification that relevant assets can be accessed only from specific areas in the application.

How Can Solvo Help You?

Cloud compliance audits have become an industry standard as companies are now aware of the risks imposed on their data when hosted with a third party.

Users and customers are requesting cloud audits and proof of compliance to gain assurance and reduce the chances of their data getting into the wrong hands.

Discovering your cloud assets and protecting them has never been easier. At Solvo, we continuously audit your AWS security posture and make sure the higher risks are handled first.

We have introduced the IAMagnifier permission map to see all your assets and recommend the least-privilege security policy that fits your scenario.

In addition, Solvo has recently introduced the Compliance Manager feature. You don’t have to wait for the security auditor to detect any security glitches.

We have set compliance rules, so checking the relevant boxes you comply with the industry’s regulations.

Ready to forget about cloud security? Start a free trial or request a demo with Solvo!

As companies and organizations engage in digital and remote working practices, cloud compliance becomes more critical than before.

Cloud compliance is a term given to the need of an organization and cloud computing providers to check if they comply with the laws and regulations that apply to use of the cloud established via regional, national, and international law.

As the cybersecurity regulations keep increasing, compliance managers struggle to manage and report the complicated and un-optimized software services to meet compliance and privacy requirements.

This post takes a deeper look into cloud compliance and why it matters, along with best practices organizations should take to prevent cloud security issues and putting their business data at risk.

Cloud Compliance and Why It Matters

With 92% of organizations hosting some of their data in the cloud, most businesses today have experienced some kind of breach.

Organizations should ensure that compliance and security are the utmost priority for them as they continue to migrate and operate within the cloud environment.

When the company moves into the hybrid cloud environment, they need to pay attention to how the cloud provider helps them comply with the industry’s regulations. Some common regulatory requirements include:

• 1. General Data Protection Regulations (GDPR)
  2. Health Insurance Portability and Accountability Act (HIPAA)
  3. Payment Card Industry Data Security Standard (PCI DSS)

These laws implement guidelines, policies, and practices to protect people’s sensitive data and improve data privacy.

Compliance can have various positive impacts on your organization’s reputation. One prime benefit to adhering to cloud compliance standards is a boost in cloud security.

These standards are not based on random choices but are carefully developed to protect data in the event of data breaches and leaks.

Non-compliance can result in lawsuits, reputational damage, regulatory fines, and disrupted operations. Thus, it is in your best interest to deploy practices to ensure compliance with standards required for your company.

Four Ways to Achieve Cloud Compliance

As the threat landscape grows, non-compliance has become a severe issue. It can’t be overlooked or neglected.

All you need is to practice establishing a cloud compliance framework that provides the necessary guidelines to maintain a high level of security for your customers.

Here are the four best ways to achieve cloud compliance and verify your commitments to data protection and privacy:

1. Asset Discovery and Visibility 

The first step to achieving cloud compliance is asset discovery and visibility. This means keeping a record of all the active and inactive assets of a network.

On the other hand, visibility refers to detecting and understanding the security and compliance risks that threaten your organization.

This involves taking stock of the cloud services and data and then defining all configurations to prevent vulnerability.

1. 1. 1. Assign ownership of assets
      2. Manage the addition of new instances via change control processes.
      3. Monitor your cloud accounts through the provider’s management console.

The dilemma for the IT department is to have good asset discovery and visibility of the software being used and their threat to an organization and find the right balance between keeping employees happy and remaining secure.

2. Data Encryption

Data encryption is vital even if you think that you don’t have anything to hide. There are three fundamental reasons for data encryption — security, compliance, and cost.

Over the past few years, the government has realized the need to have regulations to protect people’s sensitive information when in the hands of businesses.

With the overall number of data compromises being up more than 68% compared to 2020, it has become imperative to encrypt your data and lessen the number of data breaches.

This is the process of changing your data into a scrambled and unreadable form, so it becomes impossible for outsiders to invade your privacy and access your data or sensitive information.

Your business needs to consider the penalties and lawsuits they might receive for breaking federal and state laws.

If any unencrypted GDPR, SOX, PHI are exposed, it is a violation of HIPAA, and it might not cause you to pay hefty fines but also affect your reputation in the market.

Encryption is an affordable and the most secure way to achieve cloud compliance. It’s important to avoid risk by encrypting your files in the cloud.

3. Access Control

Most of the time, the flexibility of the cloud environment makes access control difficult, and this inadequate access control often results in cloud misconfiguration.

To achieve compliance, organizations need to ensure that only authorized people access sensitive data relevant to their work.

The best way for implementing access control is to practice identity and access management habits (IAM). It can prevent abuse of privileged user accounts by offering advanced management of user roles and privileges.

When you deploy IAM solutions, you can define who can use the cloud resources, when, and how. Moreover, you can also monitor any unusual behavior and send warnings to prevent data breaches.

Here are some IAM tips to achieve compliance:

1. 1. 1. Setting strong passwords
      2. Biometric authentication
      3. Multi-factor authentication
      4. Security Assertion Markup Language
      5. IAMagnifier tool

Besides this, you can even disable a dormant account and establish credentials and key management policies.

4. Develop Controls and Policies 

Having cloud security controls and policies is another significant step to achieving cloud compliance.

When you have established the risks you assume, you need to ensure to place controls around these risks.

Similarly, when you have a policy in place, you can determine what kind of cloud application can provide you with the best result that fits your requirements.

While choosing a cloud provider, organizations should understand how they want to maintain their assets and the internal controls they intend to apply to the information.

In addition, cloud security compliance needs to overview the processes and policies for deleting the stored data.

Deleting the data from the cloud environment is somehow related to the record retention policies that your cloud provider has in place.

Make the Right Choice

Need to figure out how to ensure your cloud environment is compliant with your policies and legal regulations? Contact Solvo.

At Solvo, we enable you to view, control, and protect your cloud infrastructure, security posture, and rising cloud security risks.

With Solvo, compliance isn’t a problem or a separate task now. It’s built into the way you secure your cloud-based data processing.

Also, Solvo automates the remediation process, allowing users to easily right-size permissions to ensure that every asset meets best practices standards.

We provide comprehensive visibility into all of your infrastructures while also providing the fine-grained controls you require to manage your assets responsibly.

We scan your cloud infrastructure for misconfigurations that could open the door for exploitation.

As IAM is taking its place as the main security mechanism in the cloud, we hear about more security issues related to it. Often, they are related to a wrong use of this mechanism (IAM).

Using generic permissions, too broad permissions or an overly-trusting cloud provider can leave our infrastructure and data vulnerable to unwanted actions and leakage.

The trivial example would be using the Admin permissions. In accounts protected by Solvo, scans show that 89% of Admin permissions are used with no real need, and can easily be replaced with a well-configured permission, enabling access to only the necessary assets and actions.

AWS Security and Permission Audits

If you want to do a good audit or clean-up of your security permissions, don’t settle for removing only admin permission. There are plenty of other, less trivial but just as risky permissions that are often granted in AWS accounts.

Here are a few examples of those permissions, why they are risky and how to check if they are granted unintentionally in your account.

To do that, we used Solvo’s IAMagnifier. You can use the free version of the tool right here and audit your account the same way we did.

sts:AssumeRole

AssumeRole is one of the core ideas behind the IAM mechanism. It lets identities inside or outside our organization use Roles to access different resources.

It saves us from managing long lists of users and identities, setting their usernames and passwords, invoking or revoking them, and keeping track of dynamic changes like new team members, new 3rd parties we’re using etc.

AssumeRole enables us to give access, and hopefully restrict or remove it easily. This action belongs to STS – the Security Token Service, from which we ask for these temporary credentials.

We obviously want to be aware and restrict who can assume a role, and thus to prevent the impersonation (or imassetation, pretending to be a specific asset with different permission).

By using Solvo we can tell there are two external accounts (starting with 01 and 91) that can assume a role in this account. For this example, let’s look at the account starting with 01.

It has a Developer role that has an Administrator policy attached. This means that while the external account can assume the Developer role, this IAM architecture enables it to assume any other role, while it’s under the Developer role. One of the reasons why IAM is so difficult to understand, is those hidden permissions.

In a similar way we can identify other cloud assets with different roles and policies, enabling them to assume roles freely.

iam:PassRole

This powerful permission means that whoever has it, can assign permissions to other entities in the account. This is actually a “Best Practice” for offensive hackers, for privilege escalation.

We should use it to make sure principals are only granting specific permissions, and also to make sure that high privileges are denied from attachment.

In this Solvo assessment, we can see that several AWS services in our Demo account can pass role, by using AWS managed policies.

Generally speaking, using a service-linked role is a good practice, but we need to make sure what’s inside and who got assigned with it.

In this example, the inner two service-linked roles can actually pass the “iam:*” which is quite risky. The top and bottom roles are not connected to the “iam:*” node, but instead are connected directly to the relevant role, and this proves a more tight security configuration, just the way we like it to be. Let’s look at another example:

In this example, you can see that several lambda functions can pass roles. On the top side of the map, there are 8 Lambda functions connected through different service-roles to the DynamoDBFullAccess managed policy, followed by an “iam:*” node.

That means that by using this AWS managed permission, you are actually enabling the sensitive action in your account. Managed policies are like a box of chocolate.

Both AWS managed policies we see on the screen (AdministratorAccess and AmazonDynamoDBFullAccess) lead us to a node that shows “iam:*” which means that by using these policies, we have enabled, under certain conditions, to passRole.

s3:PutBucketPolicy

If you want to get access to an S3 Bucket, and you’re not a Root user (hopefully you’re not), you need the PutBucketPolicy permission. Since S3 bucket is a very popular storage service for PII and other crown jewels, you probably don’t want different entities in your account to be able to make changes to bucket policies, and by that exposing them to data leakage or manipulation.

In this Solvo query, we looked for entities that can run the S3:PutBucketPolicy action. We can see an external account, an ECS and a Lambda function have permissions for PutBucketPolicy coming from admin policies attached to their roles.

If this is good or bad, it’s up for the application owner to say if these entities need such a permission, but the IAMagnifier makes it easy to review and look for this kind of action, and easily detect the unnecessary actions.

One other thing we learn from the map is that there’s an Anonymous entity that has access to a specific bucket.

If the Anonymous node scares you, that’s only because it means that the principal that has access to the Bucket is actually “*” everyone. So you are right to be scared.

CloudTrail:PutEventSelectors

CloudTrail is the API logging service of AWS. We also look at it as a mandatory security tool. Enabling us to monitor, detect anomalies and investigate different events.

You should also know that it is a hacking best practice to meddle, manipulate and delete logs of different monitoring and security products, to make the life of the security and IR engineers a little harder.

Of course, as a hacker you don’t want to stop logging altogether because that might set some alarms, but taking out specific logs that have to do with the nasty stuff that you’re doing might be a “better” idea. This is exactly what the PutEvenSelectors permission lets us do. And you don’t want to enable that.

In this Solvo query we see that a Lambda Function and an ECS task have admin access using an AWS managed policy. In addition to that, another account is entitled to the PutEventSelectors action through two different paths. One is a Developer role, that has a customer managed policy that contains “Resource:*”, in addition to an Administrator role, that has an AWS managed Admin policy attached (needless to say it has the “Resource:*”).

So in this case, both the AWS managed policy and the customer managed one, enabled us to run a risky action and that’s why we can add event selectors on CloudTrail and help hackers cover their traces.

ssm:GetParameters

The SSM, or the AWS System Manager, enables you to query and modify different aspects of your infrastructure. The GetParameters action allows you to retrieve different pieces of information about our cloud infrastructure and configuration, and this information may contain API keys and other secrets that are stored as parameters. Again, a classic reconnaissance action.

In this Solvo query above we can actually see a very interesting scenario. There are 4 Lambda functions that have access to 5 different parameters. Note that two of the Lambdas (in the highlighted paths below) have access to ssm:*, which contains those 5 parameters (and all other parameters we have).

That excessive permissions was granted by AWS managed policy and by an inline policy that were not least-privileged.

On the other hand, see below another highlighted route from the same query, showing a Lambda function using a Solvo policy.

You can see how it looks, when the policy is well configured, and grants access only to the necessary parameters.

To sum up, we always aspire for a least-privileged cloud account, but some excessive actions are riskier than others. In this blog we described a few of the actions that are sometimes necessary to run, but always with the right IAM policy, that will make sure it’s only used for what you intended.

If you want to check your account, and easily detect risky actions and which assets are at risk, get FREE IAMagnifier access right here.

On January 21, 2021 Ubiquiti Networks, an American technology vendor of cloud Internet of Things (IoT), disclosed that it had suffered a data breach. Ubiqiti sent out emails to its customers asking them to change their passwords and enable 2FA for their accounts.

At the time of the disclosure, the company announced that it had discovered unauthorized access to some of its systems managed by a third-party cloud provider.

It also added it was not aware of any access to any databases that contained user data. After the publication of these materials, Ubiquiti’s share price fell by 20% in just a day, and the company lost $3.9 billion in market capitalization.

Now new information has emerged from the investigation. According to an indictment unsealed by the US Department of Justice (DOJ), a former Ubiquiti developer was arrested and charged with stealing data and trying to extort his employer while pretending to be a whistleblower.

While the DOJ didn’t name Nicolas Sharp’s employer in the press release or the indictment, all the details perfectly align with previous info on the Ubiquiti breach.

What Really Happened at Ubiquiti and Lessons Learned the Security Hack

The indictment reports that Sharp used administrative access to download confidential data, using a VPN to hide his IP address while he pulled from the company’s AWS and GitHub databases.

The investigation found out that it was possible to associate unauthorized downloads with Sharpe, since during the download his connection was interrupted several times, which disrupted the VPN connection and revealed his IP address.

Sharp is alleged to have downloaded an admin key which gave him “access to other credentials within Company-1’s infrastructure” from Ubiquiti’s AWS servers.

Later, that same key was used to make the AWS API call GetCallerIdentity from an IP address linked to VPN provider Surfshark, to which Sharp was a subscriber.

The AWS API call GetCallerIdentity returns the account and IAM principal (IAM user or assumed role) of the credentials used to call it. “No permissions are required to perform this operation.

If an administrator adds a policy to your IAM user or role that explicitly denies access to the sts:GetCallerIdentity action, you can still perform this operation.

Permissions are not required because the same information is returned when an IAM user or role is denied access.” IAM User Guide.

However, you can monitor it as an abnormal behavior. For example, an attacker may attempt to verify their current identity with the credentials they hold.

This could both be to verify that the credentials they hold are valid, and to get more information on their current identity for reconnaissance purposes.

According to the prosecution, he is alleged to have set AWS logs to a one day retention policy, effectively masking his presence.

For this reason the AWS recommendation is to centralize your CloudTrail logs in a dedicated restricted AWS account. This prevents an attacker or insider from disturbing them.

Unfortunately, it’s not possible to prevent this issue completely. On the bright side, with Solvo you can be sure that you are doing everything in your power to prevent this from happening to you by:

• • Restricting permissions to services that should be editable only by specifics.
  • Keep your permissions up to date with the usage of the proper identity and checks for behavior anomalies.
  • Restrict and monitor sensitive actions on crucial changes of your cloud properties. For example, monitor for unexpected usage of your AWS access keys.

As seen in the image below, Solvo can be used to check who is allowed to make changes to your retention policy.

This way, you can easily discover over-privileged or misconfigured entitlements and make the necessary adjustments as recommended by Solvo.

You can ensure the security of your logs by checking not just your policy retention but also whether your logs bucket is fully secure and restricted.

With Solvo’s IAMagnifier, security and DevOps engineers in your organization can easily understand the misconfigurations they currently have, monitor changes in your infrastructure, search for sensitive business processes and set rules for any violation in your permissions boundary.

If you would like to learn more on how Solvo ensures cloud security, reach out to our team for an IAMagnifier demo request and explore all the capabilities of your Solvo solution.

We are ready to lead you to the future of secure cloud operations.