Author: Team Solvo

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.

Who has access to my sensitive S3 bucket?
Who can create new IAM users in our account?
Who can read data off of my DynamoDB?

These are questions we often hear from security teams that are looking to enhance their governance and visibility into their cloud security posture. We also hear those questions from security auditors, who issue SOC2, ISO and other certifications.

Answering these questions should be fairly straightforward. The only problem is that the native cloud providers did not create an easy interface to help you answer the questions.

How can you analyze your IAM permissions on a graphDB?

One option is to inspect everything asset by asset, look into the security permissions and try to read between the (JSON) lines. In that case, even if you manage to find a security issue – how would you fix it?

Do you know what the least-privileged permissions are? Can you write a new policy by yourself? If so, good for you! Now go ahead and do it to the other 999 assets in your account.

Another option would be to use Solvo’s IAMagnifier. As they say: a picture of your security permissions is worth a thousand hours. Using the analyzer you can ask your questions and get the exact answer.

Who has access to your Bucket? Here’s a map of users and resources who can dig into your data. Who is at risk of being exploited for privilege escalation (Hi SolarWinds)? Here’s the treasure map.

The Magnifier’s map will show you a shortcut for least-privileged permissions, should you need one. On the map, excessive permissions are highlighted, and an alternative security permission is suggested.

The suggestion is based on the real behavior of your application, so there’s no worry of breaking the functionality of the app. All you have to do is enforce the new permissions and finally feel relieved.

Let’s take a look at at a few of the popular queries are users are running:

(1) It’s best practice to restrict the entities that can create new AWS users to specific Admin users. You’d be surprised to see who can create such users in your account. In Solvo’s IAMagnifier screen, you can easily ask the question, like this:

 …and see for yourself who can create new IAM users.

In this case, we see that other than the Administrator, there are several other cloud entities who can create a user.

So if they get compromised, a malicious insider could take advantage of this, create a user for themselves and have persistence in your account.

The red and green icons on the role node, mark the severity of the finding, and by clicking on the node, you will find the new policy Solvo’s engine had created for that entity.

(2) S3 Bucket is the most popular cloud service in the world. It’s quick to spin, easy to use and available to just about anyone with internet access.

When used to store sensitive data, PII or anything else you find valuable, you must make sure only relevant entities are entitled to successfully run the S3:GetObject action.

Solvo IAMagnifier can help by showing you who can run this action on any or all your buckets, and recommend the least-privileged security policy that fits your scenario.

On the IAMagnifier screen you can ask your check and see if unnecessary entities can read your sensitive data.

This is what the result might look like:

In this example, we see that 5 different cloud assets can put an object into the bucket, but only one is well-configured and least-privileged. We can also see that there are different paths to get to the bucket, using different roles and policies.

These paths are not easy to track, but the IAMagnifier makes it easy and comprehensible. By clicking each misconfigured role, Solvo helps you to enforce a newly created and least-privileged policy, that would make all the excessive permissions go away.

These are just a few examples out of the endless queries Solvo’s IAM Magnifier can run.

If you would like to know who (user or asset) has access to one of your cloud resources, and to reduce that number with just a click, schedule a demo below.

With the rise of cloud-native technologies more responsibility falls in the hands of developers. Beside the application source code developers are now writing containers code, orchestrators code and also defining their infrastructure and cloud resources using infrastructure-as-code (IaC).

Using the correct IaC configuration is a real challenge and leaving your infrastructure misconfigured will create an attack vector on your application once it gets deployed.

One of the main challenges is creating the cloud resources with the least-privileged security policy. What happens in most cases, developers simply use the default/previously used definition/AWS managed policy which means that you will grant excessive permissions that will provide attackers with the needed attack surface into the cloud crown-jewels and resources.

Using a pre-configured security policy, regardless of who wrote it (AWS or your DevOps team), means that it is never the customized and least-privileged, because whoever created it, put some degrees of freedom in it. Be it the S3 bucket’s name or the specific action you wanted to run on your KMS.

KICS by Checkmarx is an open-source project which scans and finds misconfigurations and potential vulnerabilities in infrastructure code. You can implement it anywhere in your lifecycle and it takes less than 3 minutes to get to your first IaC scanning KICS finds security vulnerabilities, compliance issues, and infrastructure misconfigurations in the following Infrastructure as

Code solutions: Terraform, Kubernetes, Docker, AWS CloudFormation, Ansible, Microsoft ARM. 2000+ queries are available.

But that’s not the end of it. Because once you find those misconfigurations, you probably want to get them fixed too. Crafting a security policy from scratch requires deep knowledge in your app’s logic, in your architecture and in the IAM mechanism. And now multiply that by the number of cloud assets you actually have. It’s going to take “some time” to fix.

Solvo is a platform that automatically creates least-privileged security policies, based on the unique requirements of every application. It integrates early in the development process and creates secured policies from Dev to Prod.

By leveraging both KICS and Solvo together developers can easily understand the misconfigurations they currently have around least-privileged security policies by first scanning with KICS, finding the misconfigurations and then leveraging Solvo to generate the tailor-made least-privileged for those.

How does it work?

We prepared a short but commonly used scenario for you today, using the popular AWS storage service, the S3 Bucket! Very often we store in the bucket different items that our application / customers / partners / 3rd party applications would need access to.

In that case, most of the users would grant a full-access to the bucket, while not taking into consideration the consequences of that. In general, we always want to make sure we grant the minimum permissions (or as we know it: the least-privilege principle).

For our example today, we look at a scenario where an entity outside of our cloud account needs access to our S3 Bucket. It is done using a cross account permission, and we will use KICS and Solvo to make sure the bucket is well configured.

We will now explain how to use KICS to detect the misconfiguration in the Bucket, and how to use Solvo to create an alternative S3 Bucket policy that is least-privileged and fits our scenario.

You start by running a KICS scan on your IaC repo. Running KICS is very simple. You start by pulling the latest KICS container from DockerHub:

docker pull checkmarx/kics:latest

Now you need to trigger a scan:

docker run -v {​​​​path_to_host_folder_to_scan}​​​​:/path checkmarx/kics:latest scan -p “/path” -o “/path/”

Replace the {path_to_host_folder_to_scan} with your IaC repo and that’s it. For more details on how to effectively run KICS see: https://docs.kics.io/latest/commands/

In this example we are scanning a Terraform file which grants full permissions in an IAM policy.

In the example above we are executing the docker container of KICS and generating an HTML report.

And now let’s take a look at the KICS results:

KICS points out that main.tf has a misconfigured S3 bucket policy which grants access for anonymous users.

As you recall, we need to make sure a specific outsider can access the bucket, but we don’t want to use anonymous access to do that.

Main.tf file:

In line 21 we used a wildcard (“*”) for the principal, meaning we did not restrict the resources that can access the bucket and execute one or more of the actions in line 22.

OK, so now we understand that we used an over-privileged permission, and we would like to replace it with a well-configured permission that fits our use-case.

Moving to the Solvo console:

As seen in the console, we have 3 critical findings that are based on the fact that we used a wildcard as the “Principal”. Solvo also notified us that there are some permissions that were never in use and therefore can be removed as well.

To make our work easier, we have a map view where we can see the S3 bucket, and the entities that have access to it.

Now that we know what we did wrong, we can either create a new security policy manually, or better yet, get Solvo to create one for us automatically.

By clicking the “Remediate” button, we get this new policy. It is very granular, specific, and least-privileged, since it was custom made for this specific bucket and application.

With KICS and Solvo, creating and maintaining a least-privileged cloud environment was never easier. Don’t wait for the security audit or the next hack, scan your TF files and make your cloud infrastructure great again.

Winter is coming, so let’s talk about clouds with leaking buckets.

As you may know, AWS is the market share leader in the public cloud services space, with 31% of the revenue pie (or 33% of a smaller revenue pie), and as uncle Ben preached to the young Peter Parker: “With great market share comes more probability that assets hosted on this infrastructure would get hacked” (yes, many people don’t know that Peter started his superhero career as the friendly neighborhood IT-man, but was overwhelmed with the number of people forgetting their passwords and opening support tickets, so he switched to a career in web development).

Anyways, a lot of companies use AWS, which means a lot of developers use AWS, and since practically every AWS customer utilizes S3 in some way – S3 is probably the most used cloud service in the world.

Launched in 2006, it is also one of AWS’ oldest services, and as versions, features and abilities were upgraded or replaced, some of S3’s modules – including permissions – turned very complicated and time-consuming to use.

S3 Buckets and Cloud Security

To the uninitiated – “Buckets” are AWS’ basic containers, which hold the objects that are being stored and retrieved by processes running on the cloud.

A company’s service running on AWS could be using hundreds of buckets, each containing hundreds or even millions of objects. AWS calls them “buckets” because you can simply drop things into them.

Google Cloud also calls them buckets. Microsoft Azure calls them “blobs” because Microsoft.

All these buckets – like any digital object, actually – need to have their access privileges configured, so that only the relevant users and processes would be able to pull and push data from and into them.

The privileged few many

AWS’ services’ access privileges are managed by multiple complex mechanisms inside IAM.

The S3 service is a privileged (pun intended) service, in the sense that it supports “Resource-based policies”, in which the user can configure each resource and decide which actions by applications communicating with this resource are allowed or blocked.

What was supposed to enable better management of access, turned into a data leakage nightmare, as S3 buckets left misconfigured enabled anyone to get their hands on companies’ customer data, healthcare records, dating apps’ user data, exposure of a secret government data scraping mechanism, municipal data breach and other infamous and embarrassing incidents.

Why are these buckets misconfigured? Well, my neighbor told me yesterday that he heard from a very authoritative source (his aunt), that it is definitely maybe probably caused by the Covid-19 vaccination, but we believe there’s a simpler, less conspiratory explanation for that: It is soooooo easy to use wildcards (*) and it takes time and knowledge to craft the right least privilege policy.

You’re a pretty worthless access-configuration wizard, Harry!

It’s not just laziness (sorry, “passion for work and not for admin tasks”) – The reasons for providing higher-than-needed access to these components vary – temporarily adding an expert developer from another team to your crew to deal with a specific issue they can assist with, or maybe opening up a channel for a team working for another company that is co-developing the solution with you – in any case, these doors are left open after the invited guests had concluded their visit, so now even uninvited guests can enter through them.

AWS is obviously aware of this problem, and has recently began offering its users a wizard-like configuration tool, to ease the process of defining IAM policies.

However, the outcome itself is just a template, so the users need to complete the policy manually by themselves.  Even if the tool is used to produce an IAM policy, it fits that moment in time and will remain the same even as the user changes the actual structure and usage patterns within the bucket. Oh, and it doesn’t even support S3 bucket policies…

What’s needed is not only a flexible way to adapt the configuration to the actual and specific workflows the user is using, but one which is dynamic:  constantly checking if there is a change in assets, relationships, access, outcomes, etc.; discovering gaps between current access privilege level and needed privilege level; alert on such gaps and suggest configuration changes; and even remediate the situation by automatically update the relevant configurations itself.

Look, we get this. The reason we started Solvo was to enable developers to do what they love and do best – code – and not spend time on managing access to their components, buckets and blurbs (or whatever they call the inhabitants of planet Azure).

Working on your relationships… and bucket configurations

Here’s the good news: We’re making it less boring, and much more secure, by making it semi-automatic or fully automatic to initially and constantly check the S3 buckets’ configurations, discover misconfiguration gaps, suggest changes and/or remediate the situation automatically.

Furthermore, the “access relationships” (i.e what can access what within a bucket and across buckets) are presented as a visual.

The user can see which component can perform which action on which resource, and on top of it we provide some insights and advice on how to tweak the access configuration in order to make it more secure yet still frictionless from a workflow point of view.

This visual representation is also a great way to discover redundant or unused privileges, such as a service that was granted access to an object, but never actually accessed that object – which would raise the question: does that service really need that privilege?

But our claim to fame is the automatically tailored access configuration process, where we understand the relationship between the components and how they utilize each other to perform the job to be done, then configure the access level of each of these components individually so that it will allow the process to take place but not offer higher access level than needed to perform the relevant tasks.

Let’s say you’re using AWS Simple Email Service (SES) component to receive inbound emails, and store these emails on Amazon S3 for further processing or archiving.

Solvo analyzes the process and relationships between the SES and the S3 bucket, and then reconfigures the access level of the S3 bucket to the least-privileged access level needed in order for this process to continue its course without friction.

You work, we secure. Assessing AWS security breach potential.

How do we do it? For each bucket, Solvo initially analyzes the current configuration definitions, then assesses the severity of its breach potential by how permissive they are in providing access to objects housed within that bucket.

For example, if the said configuration allows an unauthenticated entity to change the bucket’s own access configuration – Solvo treats this as a very anomalous privilege, and raises a flag.

Solvo is also integrated with AWS’ CloudTrail service, which tracks user activity and API usage, and uses the CloudTrail logs to analyze the relationships between the identities and objects within the S3 bucket, and comes up with suggested configuration changes, that will secure the work environment – without affecting automatic or manual workflow.

The result is an ongoing automatic process that takes the burden of configuring and maintaining access rights to S3 buckets from the development teams, allowing them to focus on actually developing, yet keeping the development (and later, production) environment secure.

Yes, we’re your friendly neighborhood cloud-security gender-agnostic person (we’re still working on our costume. And theme song)

Want to take Solvo out for a test drive? Just click here and get the party started.

Stay Safe!

When it comes to writing security policies in AWS, it pays to be specific.

Misconfigured policies can lead to unfortunate data leaks or even breaches, so locking down your AWS environments is a must for every organization. 

In order for us to write and manage policies securely, we need to have full visibility over what our tools are capable of and how to use them properly. Getting this right depends heavily on the providers of our tools giving us the full picture in their documentation.

Unfortunately, the information in the official documentation can sometimes be unclear and leave us unknowingly exposed to additional risk. 

AWS’s Simple Notification Service (AWS SNS) is a prime example where a few missing details can substantially expand your exposure. 

Thankfully, there are some easy best practices that we have included on how to protect yourself here. 

Sending Messages with AWS SNS

AWS wanted to make it easier for their users to send out messages through their system, so they created SNS. 

They describe SNS as:

“a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication.

The A2A pub/sub functionality provides topics for high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications. 

Using Amazon SNS topics, your publisher systems can fanout messages to a large number of subscriber systems including Amazon SQS queues, AWS Lambda functions and HTTPS endpoints, for parallel processing, and Amazon Kinesis Data Firehose. The A2P functionality enables you to send messages to users at scale via SMS, mobile push, and email.

Looking at this description, we can see that the way to send out messages through the SNS system is with topics.

Moving through the table on resource types that SNS allows us to send to, our options here are either topics or basically just left blank. 

Given these details from the documentation, one might assume that topics are the sole way to send messages through SNS. 

However, if we dig through some of the diagrams presented on the product page — not the documentation — then we see that there might be another way. 

Looking carefully, we see that there is an arrow pointing out to users and endpoints that does not go through the topics. 

From a productivity perspective, it is good to know that we do not have to go through the extra step of registering all of our contacts into topics in order to send them out. Great, time saved.

But while this discrepancy is annoying, why is it important for a security POV?

Security Implications for SNS Misconfigurations

Our challenge here stems from the apparent miscommunication about where SNS can send its messages to.

If we assume that messages are only being sent to the entries registered in our topics, then we will probably only seek to define our policies around those topics. 

But we now know that SNS will send out not only topics but basically any phone number, email, whichever that is stored in our system. In practice, this means that it could be sending messages to many more people and endpoints than we otherwise would have been aware of or likely wanted to be sending to. 

Herein lies our security problem. Chances are that we have not been writing our policies specifically enough and are unnecessarily exposed because of it.

In most cases, a lot of folks have probably been writing their topic statements like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sns:Publish",
            "Resource": "*"
        }
    ]
}

Notice how we used an * that denotes that SNS should send to everything?

This is too expansive.

We only want to send messages to phone numbers, but not to topics. 

In order to correct our policy to meet our goal, we should be write it like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sns:Publish",
            "NotResource": "arn:aws:sns:*:*:*"
        }
    ]
}

In this way, we have limited the scope of where we are telling SNS to send to, allowing only sending to the topics that we have defined. Now we are going to send only to phone numbers through SMS. By creating allow and block lists, we should be able to keep messages from going out to other numbers/emails that are packed away in our various resources. 

We would rather avoid a situation where someone can potentially send themselves data from the server that they should not have legitimate and intentional access to. 

Remember that it is always easier to add to our allowlist than backtrack on an overly permissive access policy.

As an added tip in following best practices, we want to avoid including endpoints as possible recipients. Instead, we should define the apps that are related to the endpoints and connect to them for sending our messages.

Visibility is Key

In walking through this use case of the potential exposure that we can encounter with SNS, it highlights the wider value in gaining visibility into how our security policies can grant unintentional access to our resources.

Operating in the cloud allows us to gain unprecedented connectivity with resources, assets, and identities –– both human and machines. With this great power comes great responsibility to make sure that we are aware of what we are allowing these resources to communicate with. 

As we have seen here, AWS and other cloud infrastructures can obscure –– even unintentionally –– where we are making calls to and granting access or rights to. In order to lock these down and maintain control, we need to have optimal visibility.

This is where Solvo is able to step in and shine a light on what your cloud infrastructure is allowing folks access to, helping you to adjust your policies as needed.

Solvo’s technology tracks the metadata from calls in your infrastructure using runtime testing tools, providing unprecedented visibility into all of the activities going on under the hood. 

It then offers data-driven recommendations for how to adjust your security policies to meet the Principle of Least Privilege, permitting the access necessary while limiting overly permissive exposure. There is even a one-click auto pilot tool that fixes policies without requiring additional manual input, simplifying the process of ensuring better security.

Start securing your cloud infrastructure with a free threat assessment from our Security Genie tool and limit unintentional risk. 

And other tips for avoiding infrastructure security policy misconfigurations

The SolarWinds hack is the story that keeps on giving.

Three months following the December announcement that the company had their Orion update server compromised, new details continue to trickle out.

Some of these have been fascinating like how the adversaries apparently used a very complex Golden SAML attack that undermined the otherwise strong protections on the server that left a lot of folks not-so-quietly applauding a pretty solid bit of hacking tradecraft.

Other tidbits like the more recent news that the company was using the less than bulletproof “solarwinds123” password for their update server are more embarrassing. The company then proceeded to make a bad situation even worse by blaming an intern for the oversight, claiming that the intern “violated their password policies” in their statement during congressional testimony.

To be clear, this mistake, even if it was done by an intern, was phenomenally bad. Please do not use passwords that even remotely resemble this one. Use a password manager to make long, unpronounceable, and unguessable passwords.

But despite the embarrassment and punchline-like attitude that many have taken to this gross oversight, we should be reminded of a valuable and painful point.

Errare humanum est — To err is human.

People in organizations make all kinds of mistakes all the time. Like really, really bad ones that can lead to a breach if a hacker comes across it.

In most cases, the cause behind these potentially critical mistakes is that people are not security minded by nature. The vast majority of folks who don’t work in security are simply not going to have security at front of mind.

Developers want to develop, DevOps wants to deploy, and so on.

Getting the job done comes first and security is often in the back seat. This is far from ideal but it is our reality.

Let’s look at a couple of common examples where basic mistakes can lead to plenty of grief.

Common Infrastructure Misconfiguration Mistakes

From our experience, we can break down most security issues on the infrastructure side of the operation on people creating bad policies and not reigning in access controls.

1. 1. Lack of Specificity

One of the most common security policy mistakes comes from not being specific enough in which resources should be allowed access or say write privileges to.

All of us at some point have probably thrown in that * to include everything, leaving way more exposed than should be in our policy.

1. 2. Using Admin Policy

Having to dole out access rights to each specific resource on a granular level can be a time suck and add more than a little friction into the relationship between your team and the good folks over at IT who get inundated with requests.

Why not just give everyone on the team admin privileges and call it a day?

Unfortunately this isn’t the most feasible of options. Granting admin privileges too widely expands the threat surface and makes it harder to manage your risk. The Principle of Least Privilege lays this out pretty well, stating that we only want to give people or machines the privileges that they need in order to do their job. Once we move past that line, we are taking unnecessary risk.

1. 3. Using AWS Managed Policy

For many organizations that might lack the knowledge about how to set up their Identity Access Management (IAM) policies, AWS provides a managed policy that can help them get started. These managed policies are based on common use cases and are maintained and updated by AWS.

Organizations should view these managed policies as a stop gap measure. They are better than nothing at all, but in general are more permissive than you should want for your organization.

No two organizations are exactly alike and your policies should reflect the specificities of your team’s IAM policies and needs.

1. 4. 3rd Party Access Controls

We depend on a wide range of 3rd party services and tools to support our work. But in order for them to be effective, we have to grant them access to our resources.

In general, giving this access to approved 3rd party tools is pretty run of the mill practice. The challenge though is in ensuring that we limit this access only to the services that we are actually still using.

Far too often, we simply leave access open to 3rd parties after we have ceased using them instead of revoking access like we should.

Given how common these mistakes are, it is worth taking a look at a number of steps that we can take to reduce our chances of making them ourselves.

Good Security Starts Early

The earlier that we can catch risky security configurations, the better chance we have of preventing bigger issues down the line when making a fix becomes significantly more complicated.

This is the driving concept behind the “Shift Left” movement that advocates testing and fixing issues as early as possible in a product’s lifecycle. Given the scale of modern infrastructure, we use automation tools to seek out issues like misconfigurations in security policies.

Automation is a key component of a successful security policy enforcement strategy not only because of the speed and scale aspects. It also helps to fill in the knowledge gaps for members of your organization that may not know how to properly make secure configurations. Automated tooling can catch those mistakes and even help them correct them in real-time without the need to involve the added friction of the Security team’s reviews.

So how can we try to prevent some of these misconfigurations? Here are a few of our favorite tips and tricks.

1. Utilize Automated Scanning

Automated scans can seek out risky configurations during the design and CI/CD process stages, identifying misconfigurations like excessive permissions or that pesky * that can leave you exposed.

2. Put Guardrails in Place

Enforce policies with automated guardrails that ensure that misconfigured policies are not allowed to make it into later stages of the product development. Let alone being deployed.

In some cases, it can mean even failing a build if that’s what it takes to make sure that every configuration leaving the shop is up to your standards.

3. Automate Security Policy Creation

Like we’ve said before, writing effective security policies is not a skill that everyone from Dev to DevOps and beyond is likely to have.

That’s why it helps to use tools that can analyze your policy and make the necessary corrections either fully automatically or with a single click. Using a run-time analysis, these tools can understand how your product is supposed to operate, figure out what the Least Privilege policy should look like and then write that policy for you.

Basically, this takes the work out of writing security policies and lets your people get back to doing what they are there to do, namely writing and pushing out your products.

Create an Environment Where People Can Succeed at Security

It is unclear why the leadership at SolarWinds decided to throw the blame at an intern for making a dumb mistake.

Even if the intern did something totally terrible, they were operating in the environment that the leadership had created.

If we want our people to work more securely, we can take a couple of steps. These can include training them on best practices, which is always a good thing to be aware of.

But it is still on us to create an environment where it is downright difficult to make serious security misconfigurations that can put the company and its customers at risk. Ideally at the earlier stages where we can still work to prevent mistakes from becoming way more serious challenges later.

One step that organizations can take to start improving their ability to handle issues early is by knowing where they stand now. Solvo can help make this discovery and assessment process a little bit easier with SecurityGenie, a free health check report that will give your team some much needed visibility.

You can get your free SecurityGenie report by following this link and take your first step to a more secure policy environment.

Tel Aviv, Israel  –  March 29 , 2021  – Solvo announced today the general availability of its developer-centric cloud security solution designed to solve cybersecurity challenges that both developers and security teams are experiencing today. The solution integrates with existing workflows versus trying to change them, and addresses growing security challenges by creating and maintaining a least-privilege security policy for cloud native applications.

As the AWS collaborative development grows, the need to manage security across all partners increases. The Solvo Security Genie runs a complementary health check for AWS accounts; users receive a consolidated health check report highlighting:

1. 1. Major misconfigurations that they have in the cloud for IAM postures
   2. Excessive permissions
   3. Full access, admin privileges
   4. Third parties with access to the user account

Solvo’s freemium product analyzes cloud assets and creates a new, least-privilege and granular security policy. Solvo does it automatically, dynamically and continuously, addressing future changes and new applications’ component deployments. It provides three levels of the security configuration alerts and automatic updates.

“We are very pleased with the way Solvo integrates with new, emerging technologies. From a security perspective, they deliver on the promise of improving the relationships between developers and security teams, helping them work together and be more productive,” said Daniel Neto, head of cybersecurity at Ame Digital. “By using data collected during the development and staging phases, we can make sure that we’re allowing necessary roles and privileges in our applications.”

“As a security professional, I understand the challenges that developers and security teams have when working together. We want them both to be successful and our mission at Solvo is to create a success platform for everybody in cloud security,” said Shira Shamban, co-founder and CEO of Solvo. “We think that the future is supporting safe R&D processes in an easy and seamless way.  Our adapted security configurations are based on each unique application’s needs, and within a quick and easy onboarding process, you’ll have your application and data protected, from CI to production.”

About Solvo

Solvo allows security teams to empower software developers and accelerate their cloud delivery. The developer-centric security platform creates and maintains a least-privilege security policy for cloud native applications. It adapts the security configuration to every environment, creates it from scratch and monitors for changes, integrating with existing workflows seamlessly and automatically. To find out more about Solvo, visit our website or follow us on social media on LinkedIn and Twitter.

There is that special time in every company’s life, when you’re just extremely happy and excited and can’t wait for it to start – the security audit. Be it SOC2 or ISO, you know that will require a lot of work to uncover the current situation and then fix the findings and prove them to be so.

Passing compliance audits in the cloud doesn’t have to be this way. Solvo helps companies and organizations show a proof of their data and infrastructure security status, while maintaining it compliant.

Read our article on Helpnetsecurity Magazine and don’t forget to request a demo if you want to pass your next compliance audit easily.

Company wins in Best Startup in Security Cloud/SaaS, Best Cybersecurity Startup, AWS Cloud Security, Cloud Identity Governance, Application Security, and Cloud Infrastructure Entitlements Management (CIEM)

Tel Aviv  –  March 3, 2021  – Solvo announced today that the company won six awards in two well-known cybersecurity award competitions. The company was recognized by information security community members globally and took gold in four categories of the 6th Annual Cybersecurity Excellence Awards contest: Best Cybersecurity Startup – Middle East, AWS Cloud Security – Middle East, Cloud Identity Governance – Middle East, and Application Security – North America, and silver in Cloud Infrastructure Entitlements Management (CIEM) – Middle East. Solvo was also a winner in a different security contest, the 17th Annual 2021 Cybersecurity Global Excellence Awards®,  in the Security Cloud/SaaS category; more than 45 judges from around the world participated in the judging process.

Solvo was chosen a winner based on the strength of its nominations and the popular vote by members of the information security community. The company launched last year a cloud security solution that is empowering developers and security teams who want to migrate to the cloud or build cloud-native applications at scale.

“Congratulations to Solvo for impressing the judges and the community with its innovation and real-world problem solving,”  said Holger Schulze, CEO of Cybersecurity Insiders and founder of the 500,000-member Information Security Community on LinkedIn which organizes the 6th annual Cybersecurity Excellence Awards. “To win in five cybersecurity and cloud categories in a contest with more than 600 entries is quite impressive. We are looking forward to following the company on its journey of solving ongoing challenges that both security and developer teams face today.”

“I am glad to see that industry experts, who judged hundreds of entries in both award competitions, recognized the benefits of our dynamic technology for cloud identity governance, which accelerates the cloud development process while maintaining top security protocols,” said Shira Shamban, co-founder and CEO of Solvo. “As every security officer knows, there is an ongoing tension between R&D and security.  Solvo delivers an optimized yet secure solution that enables organizations to move forward fast.”

About Solvo
Solvo allows security teams to empower software developers and accelerate their cloud delivery. The developer-centric security platform creates and maintains a least-privileged security policy for cloud native applications. It adapts the security configuration to every environment, creates it from scratch and monitors for changes, integrating with existing workflows seamlessly and automatically. To find out more about Solvo, visit our website or follow us on social media on LinkedIn and Twitter.