Tag Archives: cloud security

Cloud Pentesting, Pt. 3: The Impact of Ecosystem Maturity

2022-04-04 Eric Mortaro

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/04/04/cloud-pentesting-pt-3-the-impact-of-ecosystem-maturity/

Cloud Pentesting, Pt. 3: The Impact of Ecosystem Maturity

Now that we’ve covered the basics of cloud pentesting and the style in which a cloud environment could be attacked, let’s turn our attention to the entirety of this ecosystem. This environment isn’t too different from the on-premise ecosystem that traditional penetration testing is performed on. Who doesn’t want to gain internal access to the client’s environment from an external perspective? Recently, one consultant obtained firewall access due to default credentials never being changed, and the management interface was being publicly exposed. Or how about gaining a shell on a web server because of misconfigurations?

Typically, a client who has a bit more maturity beyond just a vulnerability management program will shift gears to doing multiple pentests against their environments, which are external, internal, web app, mobile app, wireless, and potentially more. By doing these types of pentests, clients can better understand which aspects of their ecosystem are failing and which are doing fine. This is no different than when their infrastructure is deployed in the cloud.

Cloud implementation maturity

There’s an old saying that one must learn how to crawl before walking and how to walk before running. That same adage runs true for pentesting. Pentesting a network before ever having some sort of vulnerability management program can certainly show the weaknesses within the network, but it may not show the true depth of the issue.

The same holds true with Red Teams. You wouldn’t want to immediately jump on the Red Team pentesting bandwagon without having gone through multiple iterations of pentesting to true up gaps within the environment. Cloud pentesting should be treated in the same manner.

The maturity of a company’s cloud implementation will help determine the depth in which a cloud pentest can occur, if it can occur at all! To peel this orange back a bit, let’s say a company wants a cloud ecosystem pentest. Discovery calls to scope the project will certainly help uncover how a customer implements their cloud environment, but what if it’s a basic approach? As in, there is no use of cloud-native deployments, all user accounts have root access, tagging of assets within the environment is not implemented, and so on. Where does this leave a pentest?

In this particular case, an ecosystem pentest is not feasible at this juncture. The more basic approaches, such as vulnerability management or scanning of built-in cloud vendor-specific checks, would most certainly be ideal. Again, crawl before you walk, and walk before you run.This would look more like a traditional pentest, where an external and an internal test are performed.

What if the client is very mature in their implementation of cloud? Now we’re talking! User accounts are not root, IAM roles are leveraged instead of users, departments have separate permission profiles, the environment utilizes cloud native deployments as much as possible, and there’s separation of department environments by means of accounts, access control lists (ACLs), or virtual private clouds (VPCs). This now becomes the cloud ecosystem pentest that will show gaps within the environment — with the understanding that the customer has implemented, to the best of their abilities, controls that are baked into the cloud platform.

Maturity example

I’ve had the absolute pleasure of chatting with a ton of potential customers that are interested in performing a cloud ecosystem pentest. This not only helps to understand how the customer needs their pentest to be structured, but it also helps me to understand how we can improve our offering at Rapid7. There’s one particular case that stood out to me, which helped me understand that some customers are simply not ready to move into a cloud-native deployment.

In discussing Rapid7’s approach to cloud ecosystem pentesting, we typically ask what types of services the customer uses with their respective cloud vendor. In this discussion with this particular customer, we discovered they were using Kubernetes (K8s) quite extensively. After we asked a few more questions, it turned out that the customer wasn’t using K8s from a cloud-native perspective — rather, they had installed Kubernetes on their own virtual machines and were administering it from there. The reason behind this was that they just weren’t ready yet to fully transition to a cloud vendor running other parts of their infrastructure.

Now, this is a bit of a head-scratcher, because in this type of scenario, they’re taking on more of the support than is necessary. Who am I to argue, though? The customer and I had a very fruitful conversation, which actually led us both to a deeper understanding of not only their business approach but also their IT infrastructure strategy.

So, in this particular instance, if we were to pentest K8s that this customer deployed onto their virtual machines, how far could we go? Well, since they own the entire stack — from the operating system, to the software, to the actual containers — we can go as far as we can go. If, however, this had been deployed from a cloud-native perspective, we would have restrictions due to the cloud vendor’s terms of services.

One major restriction is container escapes, which are out of scope. This goes back to the shared environment that has made cloud so successful. If Rapid7 were capable of performing a container escape, not only would this have been severely out of scope, but Rapid7 would most certainly be reporting the exploit to the cloud vendor themselves. These are the dreams of a white hat hacker, who signed up to perform a bug bounty and get paid out potentially tens of thousands of dollars!

But while that isn’t exactly how all cloud pentests turn out, they can still be done just as effectively as traditional on-premise pentests. It just requires a clear understanding of how the customer has deployed their cloud ecosystem, how mature their implementation is, and what is in and out of scope for a pentest based on those factors.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Cloud Pentesting, Pt. 2: Testing Across Different Deployments

2022-03-29 Eric Mortaro

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/03/29/cloud-pentesting-pt-2-testing-across-different-deployments/

Cloud Pentesting, Pt. 2: Testing Across Different Deployments

In part one of this series, we broke down the various types of cloud deployments. So, pentesting in the cloud is just like on-prem, right? (Who asks these loaded questions!?)

The answer is yes and no. It depends on how a customer has set up their cloud deployment. Let’s cover a few basics first, because this will really clear things up.

Each cloud vendor has their own unique restrictions on what can and cannot be attacked, due to the nature of how the cloud is architected. Most have very similar restrictions — however, these rules must be followed, or one could quickly find themselves outside of scope. The next sections will outline which parts of the “as-a-service” components are out of scope for testing, and which are in scope.

Infrastructure as a service

This, in my experience, is how most clients have come to set up their cloud deployment. This as-a-service model could have simply been the quickest way to appease a C-level person, asking their Directors and Managers to go all-in with cloud. This is that direct lift from on-premise to the cloud that we discussed in the last post.

When it comes to testing this type of deployment, the scope is the largest it could be, with very few exceptions to what is out of scope. Getting dropped directly into a virtual private cloud (VPC) is likely the scenario that will work as an “assumed breach” approach. The client would then deploy a virtual machine, which will then be allowed specific access inbound from a tester’s IP address, along with gaining that access via an SSH keypair.

Some exceptions to this testing that are OUT of scope include:

Auto-scaling functions and network address translation (NAT) gateways
Exploiting the software that was used to deploy compute instances, or changing NAT

Some items that are IN scope for this deployment model include:

Attacking the operating system and attempting exploitation against outdated versions
Exploiting the software or applications installed on the operating system

Platform as a service

You’ve heard of bring your own device (BYOD) — think of this as BYOS, or bring your own software. Platform as a service (PaaS) brings us up a level in terms of support requirements. With this approach, clients can utilize a cloud provider’s products that allow a client to bring their own code for things like web applications. A client no longer has to work on keeping their operating system up to date. The code is typically deployed on something like a container, which could cost the client much less than that of having to deploy a virtual machine, licensing for an operating system, vulnerability management of the operating system, and staffing considerations. There are again exceptions, however, to what can and can’t be tested.

In this example, the following would be considered OUT of scope:

The host itself and/or containers hosting the application
Attempting to escape containers where the application is hosted

The items which are IN scope for this deployment model include:

Attempting to exploit the application that is installed on the operating system itself

Software as a service

At last, the greatest reduction in liability: software as a service (SaaS). Microsoft’s Office 365 is perhaps the most common example of a very widely used SaaS deployment. Click a few buttons in a cloud provider’s dashboard, input some user credentials, upload some data, and you’re done! Easy like Sunday morning!

Now, the only thing to worry about is the data within the application and the users themselves. Everything else — including virtual machine deployment, operating system installation and upkeep, patch management of the operation system and the software installed on it, and the code base, to name a few — is completely removed from worry. Imagine how much overhead you can now dedicate to other parts of the business. Windows Admins, web app developers, infosec staff, and even IT staff now have less to worry about. However, if you’re looking to have a pentest in this kind of environment, just know that there is not a whole lot that can actually be done.

Application exploits, for example, are OUT of scope. The items that are IN scope for this deployment model are the following:

Leveraging privileges and attempting to acquire data
Adding user accounts or elevating privileges

That’s it! The only thing that can be attacked is the users themselves, via password attacks, or the data that is held within the application — but that’s only if authentication is bypassed.

Those above examples are not made up from Rapid7’s perspective either. These are industry-wide standards that cloud providers have created. These types of deployments are specifically designed to help reduce liability and to increase not only the capabilities of an organization but also its speed. These are known as a “shared platform” model.

As-a-service example

Recently, we had a discussion with a client who needed a pentest performed on their web application. Their web app was deployed from a third-party cloud provider, which ended up using Google Cloud Platform on their back end. After a consultant discovered that this client had deployed their web application via the SaaS model, I explained that, due to the SaaS deployment, application exploitation was out of scope, and the only attempts that could be made would be password attacks and to go after the data.

Now, obviously, education needs to happen all around, but again, the cloud isn’t new. After about an hour of discussing how their deployment looked, the client then asked a very interesting question: “How can I get to the point where we make the application available to fully attempt exploitation against it?” I was befuddled, and quite simply, the answer was, “Why would you want to do that?” You see, by using SaaS, you remove liability from worrying about this sort of issue, which the organization may not have the capacity or budget to address. SaaS is click-and-go, and the software provider is now at risk of not providing a secured platform for content delivery.

After I had explained this to the client, they quickly understood that SaaS is the way to go, and transforming into a PaaS deployment model would have actually required that they now hire additional headcount, including a web app developer.

It is this maturity that needs to happen throughout the industry to continue to maintain security within not just small companies, but large enterprises, too.

Digging deeper

Externally

There’ve been numerous breaches of customer data, and there’s typically a common culprit: a misconfigured S3 bucket, or discovered credentials to a cloud vendor’s platform dashboard. These all seem like very easy things to remedy, but performing an external pentest where the targets are the assets hosted by a cloud vendor will certainly show if there are misconfigurations or accidental access being provided. This can be treated like any normal external pentest, but with the sole focus on knowing these assets live within a cloud environment.

Internally

There are multiple considerations when discussing what is “internal” to a cloud environment. Here, we’ll dig into the differences between platform and infrastructure.

Platform vs. infrastructure

In order to move or create assets within a cloud environment, one must first set up an account with the cloud vendor of choice. A username and password are created, then a user logs into the web application dashboard of the cloud vendor, and finally, assets are created and deployed to provide the functionality that is needed. The platform that the user is logged into is one aspect of an “internal” pentest against a cloud environment.

Platform pentest example

There I was, doing a thick client pentest against an executable. I installed the application on my Windows VM, started up a few more apps to hook into the running processes, and off to the races I went.

One of the more basic steps in the process is to check the installation files. Within the directory, I find an .INI file. I opened this file with a text editor, and I was greeted with an Amazon AWS Access Key ID and SecretAccessKey! Wow, did I get lucky. I fired up aws cli, punched in the access key ID and SecretAccessKey, along with the target IP address, and bam! I was in like Flynn.

Now, kudos go out to the client that didn’t provide this user with root access. However, I was still able to gain a ton of access with additional information. I stopped from there though, because this quickly turned into a cloud-style pentest. I called the client up right away and informed them of this information, and they were happy (not happy) that this was discovered.

Internal platform pentest

A platform pentest is like being given a domain account, in an assumed-breached scenario, on an internal pentest. It’s a “hey, if you can’t get creds, here’s a low-priv account to see what you can do with it” approach.

On a cloud platform pentest, we’re being given this account to attempt additional attacks, such as privilege escalation, launching of additional virtual machines, or using a function to inject code into containers that auto-deploy and dial back to a listening server each time. A virtual machine, preferably Kali Linux, will need to be deployed within the VPC, so you can perform your internal pentest from it.

Internal infrastructure pentest

This pentest is much easier to construct. It looks very similar to an internal, on-premise pentest. The client sets up a virtual machine inside of the VPC they want tested, then the consultant creates that public/private SSH keypair and provides the SSH public key to the client. The client allows specific source IPs to SSH into that VM, and the pentest begins.

In my experience, a lot of clients only have one VPC, so that makes life a bit easier. However, as more and more people gain experience and knowledge with how to set up their cloud environments, VPC separation is becoming more prevalent. As an example, perhaps a customer utilizes functions to auto-deploy new “sites” each time one of their customers signs on to use their services. This function automatically creates a brand-new VPC, with separation from other VPCs (which are their other clients), virtual machines, databases, network connectivity, access into the VPC for their clients administration, user accounts, authentication, SSO, and more. In this scenario, we’d ask the client to create multiple VPCs and drop us into at least one of them. This way, we can then perform a tenant-to-tenant-style pentest, to see if it’s possible to break out of one segment to access another.

In part three, we’ll take a look at how the maturity of the client’s cloud implementation can impact the way pentests are carried out. Stay tuned!

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Rapid7 Recognized as Top Ranked in Current Offering Category in Forrester Wave™ for Cloud Workload Security

2022-03-23 Ben Austin

Post Syndicated from Ben Austin original https://blog.rapid7.com/2022/03/23/rapid7-recognized-as-top-ranked-in-current-offering-category-in-forrester-wave-for-cloud-workload-security/

Rapid7 Recognized as Top Ranked in Current Offering Category in Forrester Wave™ for Cloud Workload Security

The widespread growth in cloud adoption in recent years has given businesses across all industries the ability to transform and scale in ways never before possible. But the speed of those changes, combined with the increased volume and complexity of resources in cloud environments, often forces organizations to choose between slowing the pace of innovation or taking on massive amounts of unmanaged risk.

Because of this, cloud misconfigurations have become a leading attack vector for malicious breaches. Organizations are now scrambling to evolve their cloud security programs to properly secure their most sensitive and valuable data — before it falls into the hands of an adversary.

This requires going beyond the siloed toolsets and manual efforts of increasingly hard-to-find cloud security professionals. Instead, businesses need to leverage comprehensive cloud workload security solutions that allow their teams to get a broad set of capabilities in a single platform in order to move more efficiently and effectively.

But in the still-emerging and rapidly evolving cloud security space, narrowing down a shortlist of vendors can be challenging and confusing.

To help buyers select the right vendor for their needs among the industry’s many players, Forrester Research evaluated the top 12 cloud security providers to equip evaluators with necessary context on each provider’s current offering and strategy. We’re excited to share that Rapid7 has been included among these top vendors and recognized as a Strong Performer in the Forrester Wave™: Cloud Workload Security, Q1 2022.

Most notably, Forrester’s report showed Rapid7 as the top-ranked solution in the Current Offering category.

This is the first time the Forrester Wave™ for Cloud Workload Security has been published since Rapid7’s acquisition of DivvyCloud and Alcide, which culminated in the launch of InsightCloudSec in July 2021. We believe the results of this Forrester Wave™ show that Rapid7’s strategy and execution following those acquisitions has already positioned us well against other vendors in the highly competitive cloud security market.

Get the Full Report

Download Now

A closer look at the results

“In its current CWS offering, the vendor provides excellent setup, configuration, and data integration solution features; identity and access management and CSPM is strong. Runtime and container orchestration platform protection is also strong and easy to use.”

The Forrester report gave Rapid7 the highest possible scores in the criteria of cloud security posture management (CSPM), infrastructure as code (IaC), identity and access management (IAM), and container protection, which to us emphasizes the breadth and depth of our current solution in both posture management and workload protection.

Rapid7 also received the highest possible score in the Setup, Configuration, and Data Integration criterion. When combined with the highest possible score in the Integration category, we believe this leads to faster time to value and more efficient ongoing cloud security operations compared to other vendors.

Within the Strategy category, Forrester gave Rapid7 the highest possible scores in the Cloud Workload Protection (CWP) Plans and Container Protection Plans criteria. According to the report, “In its CWS strategy, [Rapid7] has differentiated CWP and container protection plans.”

“The vendor plans to implement runtime analysis using machine learning (ML) to establish a baseline profile of activity and identify anomalous behaviors and unknown threats, simplifying runtime rules and detections,“ the report explains.

From our standpoint, this combination of current market-leading CSPM and shift-left capabilities, alongside a highly differentiated CWP and Container Protection roadmap, is evidence of the significant value Rapid7 is bringing to our customers by enabling organizations to innovate and accelerate their business strategies with secure adoption of cloud technologies.

Learn more

You can download The Forrester Wave™: Cloud Workload Security, Q1 2022 from our website here.

Interested in hearing more about Rapid7’s cloud security solution, and how we’re providing value to our current customers? Join us on Tuesday, March 29 for our third-annual Cloud Security Summit to hear from our leadership, customers, and partners about how Rapid7 is driving cloud security forward.

Join our 2022 Cloud Security Summit

Additional reading:

Cloud Pentesting, Pt. 1: Breaking Down the Basics

2022-03-21 Eric Mortaro

Post Syndicated from Eric Mortaro original https://blog.rapid7.com/2022/03/21/cloud-pentesting-pt-1-breaking-down-the-basics/

Cloud Pentesting, Pt. 1: Breaking Down the Basics

The concept of cloud computing has been around for awhile, but it seems like as of late — at least in the penetration testing field — more and more customers are looking to get a pentest done in their cloud deployment. What does that mean? How does that look? What can be tested, and what’s out of scope? Why would I want a pentest in the cloud? Let’s start with the basics here, to hopefully shed some light on what this is all about, and then we’ll get into the thick of it.

Cloud computing is the idea of using software and services that run on the internet as a way for an organization to deploy their once on-premise systems. This isn’t a new concept — in fact, the major vendors, such as Amazon’s AWS, Microsoft’s Azure, and Google’s Cloud Platform, have all been around for about 15 years. Still, cloud sometimes seems like it’s being talked about as if it was invented just yesterday, but we’ll get into that a bit more later.

So, cloud computing means using someone else’s computer, in a figurative or quite literal sense. Simple enough, right?

Wrong! There are various ways that companies have started to utilize cloud providers, and these all impact how pentests are carried out in cloud environments. Let’s take a closer look at the three primary cloud configurations.

Traditional cloud usage

Some companies have simply lifted infrastructure and services straight from their own on-premise data centers and moved them into the cloud. This looks a whole lot like setting up one virtual private cloud (VPC), with numerous virtual machines, a flat network, and that’s it! While this might not seem like a company is using their cloud vendor to its fullest potential, they’re still reaping the benefits of never having to manage uptime of physical hardware, calling their ISP late at night because of an outage, or worrying about power outages or cooling.

But one inherent problem remains: The company still requires significant staff to maintain the virtual machines and perform operating system updates, software versioning, cipher suite usage, code base fixes, and more. This starts to look a lot like the typical vulnerability management (VM) program, where IT and security continue to own and maintain infrastructure. They work to patch and harden endpoints in the cloud and are still in line for changes to be committed to the cloud infrastructure.

Cloud-native usage

The other side of cloud adoption is a more mature approach, where a company has devoted time and effort toward transitioning their once on-premise infrastructure to a fully utilized cloud deployment. While this could very well include the use of the typical VPC, network stack, virtual machines, and more, the more mature organization will utilize cloud-native deployments. These could include storage services such as S3, function services, or even cloud-native Kubernetes.

Cloud-native users shift the priorities and responsibilities of IT and security teams so that they no longer act as gatekeepers to prevent the scaling up or out of infrastructure utilized by product teams. In most of these environments, the product teams own the ability to make commitments in the cloud without IT and security input. Meanwhile, IT and security focus on proper controls and configurations to prevent security incidents. Patching is exchanged for rebuilds, and network alerting and physical server isolation are handled through automated responses, such as an alert with AWS Config that automatically changes the security group for a resource in the cloud and isolates it for further investigation.

These types of deployments start to more fully utilize the capabilities of the cloud, such as automated deployment through infrastructure-as-code solutions like AWS Cloud Formation. Gone are the days when an organization would deploy Kubernetes on top of a virtual machine to deploy containers. Now, cloud-native vendors provide this service with AWS’s Elastic Kubernetes Services, Microsoft’s Azure Kubernetes Services, and for obvious reasons, Google’s Kubernetes Engine. These and other types of cloud native deployments really help to ease the burden on the organization.

Hybrid cloud

Then there’s hybrid cloud. This is where a customer can set up their on-premise environment to also tie into their cloud environment, or visa versa. One common theme we see is with Microsoft Azure, where the Azure AD Connect sync is used to synchronize on-premise Active Directory to Azure AD. This can be very beneficial when the company is using other Software-as-a-Service (SaaS) components, such as Microsoft Office 365.

There are various benefits to utilizing hybrid cloud deployments. Maybe there are specific components that a customer wants to keep in house and support on their own infrastructure. Or perhaps the customer doesn’t yet have experience with how to maintain Kubernetes but is utilizing Google Cloud Platform. The ability to deploy your own services is the key to flexibility, and the cloud helps provide that.

In part two, we’ll take a closer look at how these different cloud deployments impact pentesting in the cloud.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

3 Reasons to Join Rapid7’s Cloud Security Summit

2022-03-09 Ben Austin

Post Syndicated from Ben Austin original https://blog.rapid7.com/2022/03/09/3-reasons-to-join-rapid7s-cloud-security-summit/

3 Reasons to Join Rapid7’s Cloud Security Summit

The world of the cloud never stops moving — so neither can cloud security. In the face of rapidly evolving technology and a constantly changing threat landscape, keeping up with all the latest developments, trends, and best practices in this emerging practice is more vital than ever.

Enter Rapid7’s third annual Cloud Security Summit, which we’ll be hosting this year on Tuesday, March 29. This one-day virtual event is dedicated to cloud security best practices and will feature industry experts from Rapid7, as well as Amazon Web Services (AWS), Snyk, and more.

While the event is fully virtual and free, we know that the time commitment can be the most challenging part of attending a multi-hour event during the workday. With that in mind, we’ve compiled a short list of the top reasons you’ll definitely want to register, clear your calendar, and attend this event.

Reason 1: Get a sneak peak at some original cloud security research

During the opening session of this year’s summit, two members of Rapid7’s award-winning security research team will be presenting some never-before-published research on the current state of cloud security operations, the most common misconfigurations in 2021, Log4j, and more.

Along with being genuinely interesting data, this research will also give you some insights and benchmarks that will help you evaluate your own cloud security program, and prioritize the most commonly exploited risks in your organization’s environment.

Reason 2: Learn from industry experts, and get CPE credits

Along with a handful of team member’s from Rapid7’s own cloud security practice, this year’s summit includes a host of subject matter experts from across the industry. You can look forward to hearing from Merritt Baer, Principal in the Office of the CISO at Amazon Web Services; Anthony Seto, Field Director for Cloud Native Application Security at Snyk; Keith Hoodlet, Code Security Architect at GitHub; and more. And that doesn’t even include the InsightCloudSec customers who will be joining to share their expert perspectives as well.

While learning and knowledge gain are clearly the most important aspects here, it’s always great to have something extra to show for the time you devoted to an event like this. To help make the case to your management that this event is more than worth the time you’ll put in, we’ve arranged for all attendees to earn 3.5 continuing professional education (CPE) credits to go toward maintaining or upgrading security certifications, such as CISSP, CISM, and more.

Reason 3: Be the first to hear exciting Rapid7 announcements

Last but not least, while the event is primarily focused on cloud security research, strategies, and thought leadership, we are also planning to pepper in some exciting news related to InsightCloudSec, Rapid7’s cloud-native security platform.

We’ll end the day with a demonstration of the product, so you can see some of our newest capabilities in action. Whether you’re already an InsightCloudSec customer, or considering a new solution for uncovering misconfigurations, automating cloud security workflows, shifting left, and more, this is the best way to get a live look at one of the top solutions available in the market today.

So what are you waiting for? Come join us, and let’s dive into the latest and greatest in cloud security together.

Join our 2022 Cloud Security Summit

Additional reading

Let’s Architect! Architecting for Security

2022-02-23 Luca Mezzalira

Post Syndicated from Luca Mezzalira original https://aws.amazon.com/blogs/architecture/lets-architect-architecting-for-security/

At AWS, security is “job zero” for every employee—it’s even more important than any number one priority. In this Let’s Architect! post, we’ve collected security content to help you protect data, manage access, protect networks and applications, detect and monitor threats, and ensure privacy and compliance.

Managing temporary elevated access to your AWS environment

One challenge many organizations face is maintaining a solid security governance across AWS accounts.

This Security Blog post provides a practical approach to temporarily elevate access for specific users. For example, imagine a developer wants to access a resource in the production environment. With elevated access, you won’t have to provide them an account that has access to the production environment. You would just elevate their access for a short period of time. The following diagram shows the few steps needed to temporarily elevate access to a user.

This diagram shows the few steps needed to temporarily elevate access to a user

This diagram shows the few steps needed for to temporarily elevate access to a user

Security should start left: The problem with shift left

You already know security is job zero at AWS. But it’s not just a technology challenge. The gaps between security, operations, and development cycles are widening. To close these gaps, teams must have real-time visibility and control over their tools, processes, and practices to prevent security breaches.

This re:Invent session shows how establishing relationships, empathy, and understanding between development and operations teams early in the development process helps you maintain the visibility and control you need to keep your applications secure.

Empowering developers means shifting security left and presenting security issues as early as possible in your process

AWS Security Reference Architecture: Visualize your security

Securing a workload in the cloud can be tough; almost every workload is unique and has different requirements. This re:Invent video shows you how AWS can simplify the security of your workloads, no matter their complexity.

You’ll learn how various services work together and how you can deploy them to meet your security needs. You’ll also see how the AWS Security Reference Architecture can automate common security tasks and expand your security practices for the future. The following diagram shows how AWS Security Reference Architecture provides guidelines for securing your workloads in multiple AWS Regions and accounts.

The AWS Security Reference Architecture provides guidelines for securing your workloads in multiple AWS Regions and accounts

Network security for serverless workloads

Serverless technologies can improve your security posture. You can build layers of control and security with AWS managed and abstracted services, meaning that you don’t have to do as much security work and can focus on building your system.

This video from re:Invent provides serverless strategies to consider to gain greater control of networking security. You will learn patterns to implement security at the edge, as well as options for controlling an AWS Lambda function’s network traffic. These strategies are designed to securely access resources (for example, databases) placed in a virtual private cloud (VPC), as well as resources outside of a VPC. The following screenshot shows how
Lambda functions can run in a VPC and connect to services like Amazon DynamoDB using VPC gateway endpoints.

Lambda functions can run in a VPC and connect to services like Amazon DynamoDB using VPC gateway endpoints

See you next time!

Thanks for reading! If you’re looking for more ways to architect your workload for security, check out Best Practices for Security, Identity, & Compliance in the AWS Architecture Center.

See you in a couple of weeks when we discuss the best tools offered by AWS for software architects!

Cloud Security and Compliance: The Ultimate Frenemies of Financial Services

2022-02-17 Ben Austin

Post Syndicated from Ben Austin original https://blog.rapid7.com/2022/02/17/cloud-security-and-compliance-the-ultimate-frenemies-of-financial-services/

Cloud Security and Compliance: The Ultimate Frenemies of Financial Services

Meeting compliance standards as a financial services (finserv) company can be incredibly time-consuming and expensive. Finserv has some of the highest regulatory bars to clear out of any industry — with the exception, perhaps, of healthcare.

That said, these regulations exist for good reason. Even beyond being requirements to operate, meeting compliance standards helps financial services companies gain customer trust, avoid reputational damage, and protect themselves from unnecessary or unprofitable risk.

But as I’m sure just about everyone reading this will agree, meeting regulatory compliance standards does not necessarily mean your organization is fully secure. Often, it’s difficult for government agencies and legislators to keep up with the pace of changing technologies, so regulations tend to lag behind the state of tech. This is often particularly true with emerging technologies, such as hybrid and multi-cloud environments.

On top of all of that, the cost of not having a well-rounded security portfolio is particularly massive here — the average cost of a data breach in financial services is second highest of all industries (only healthcare is more expensive).

Needless to say, financial services organizations have a complex relationship with compliance, particularly as it relates to business-driven cloud migration and innovation.

Here are four ways finserv companies can embrace the love-hate relationship with cloud security and compliance while effectively navigating the need to maintain pace with today’s rapid rate of change.

1. Implement continuous monitoring

Change seems to be the only constant when it comes to multi-cloud environments. And there’s virtually no limit to where these changes can occur — all clouds and regions are fair game. In addition, new compliance regulations are continuously taking shape as cloud security best practices continue to progress. Lawmakers around the globe are tasked with implementing these new and updated rules to protect data in every industry to effectively address the rapidly changing vulnerabilities.

A key component to remain compliant with these rules and regulations is knowing who is responsible for making changes and maintaining compliance. To do this, you’ll need visibility to distinguish between normal changes to infrastructure, applications, or access made by your development team and the changes that occur at the hands of a threat actor.

But the reality is that many data points can make distinguishing threats difficult for security professionals. After all, financial services organizations are an irresistible target for those with malicious intent because there’s a direct line to the dollar value.

Clearly, information security statutes provide necessary oversight. Since assessing data in real time is essential for success in this industry, continuous monitoring can help you stay compliant at every stage of development. This can also be useful during an audit to show your organization has taken a proactive approach to compliance.

2. Automate security processes

Many regulations require organizations to act fast in the wake of a security breach. The European Union (EU)’s General Data Protection Regulation (GDPR), which is setting the standard for privacy and security laws globally, requires supervisory authorities (and at times individuals) to be notified within 72 hours of becoming aware of a data breach. And these correspondences must provide extensive information about the breach, such as how many individuals were impacted, the consequences of the breach, and perhaps most importantly, what the next steps are for containment and mitigation.

While not every jurisdiction has laws that are as strict as the EU’s GDPR, many countries are using GDPR as a baseline for their own guidance in how they hold organizations responsible and accountable for protecting consumer information. Industry regulations and cloud governance frameworks, such as PCI DSS, SOC 2, ISO 27001, and Gramm-Leach-Bliley Act, are just a few of the many standards with which finserv organizations need to ensure compliance. Organizations that do business globally not only need to be aware of these guidelines but also how they impact the way they do business. For example, if a consumer lives in a country protected by GDPR, their data is protected by GDPR guidelines. This is necessary even if the organization doesn’t operate directly in that country.

The best-case scenario is to catch misconfigurations before they go live and cause a breach, so you can safeguard customer data and avoid going through the lengthy disclosure process and the ensuing loss of customer trust. That’s exactly what automation helps you do.

Relying on manual efforts from your team to ensure that owners of noncompliant resources are notified and remediation takes place can be a time-consuming and involved process. Plus, it’s too easy for potential threats to fall between the cracks. By automating continuous auditing of resources, misconfiguration notification, and remediation, organizations can address noncompliance before issues escalate.

Large teams that leverage multiple platforms can commonly experience information breakdowns. After all, not everyone can understand security jargon. When misunderstandings occur, it can often lead to an unintentional lapse in compliance among employees. Implementing a simplified reporting structure can help security professionals communicate more effectively with resource owners and other immediate stakeholders. Isolated data points from multiple threat alarms can make it confusing and time-consuming for cloud resource owners to understand what happened and what to do next.

Finding a platform that empowers product and engineering teams to take responsibility for their own security, while also providing thorough context about the violation and the necessary remediation steps is essential. This can help set a standard by challenging teams to measure security compliance daily, while minimizing a lot of the friction and guesswork that comes from shifting security earlier in the development lifecycle.

Not only does this help with compliance legalities, but showing these ongoing, team-wide security compliance checks can also satisfy squeamish boards. Gartner predicts that security concerns will continue to be a top priority for board members in the wake of sensational security breaches that are occurring with startling regularity. Ransomware, for example, has gone mainstream, and boards have taken notice. Cybersecurity is seen as a potentially major vulnerability, which means the expectations placed on CISOs are mounting.

Though a lot of focus goes into updating frameworks and systems, corporate culture is the third piece of a powerful security strategy. It must not be overlooked.

4. Gain greater visibility

Robust, multi-cloud environments can make visibility challenging. Enterprises need to govern their clouds using Identity and Access Management (IAM) and adopt a least-privileged access security model across cloud and container environments. But that’s not enough. They also need a strategy that enables them to see vulnerabilities across multiple environments and devices. This is especially important as more insiders gain access to the cloud who also have the ability to make changes and add assets — and do all of this at a startling pace.

This visibility is a significant part of remaining compliant because rapid changes can have unintended results that can be missed without an overarching view of the cloud environment. What might look like harmless or anonymized data could still cause privacy and compliance concerns. For example, knowing simply gender, zip code, and birth date is enough information to identify 87% of Americans. To protect consumers, legislation such as the California Consumer Privacy Act (CCPA) stipulates that toxic data combinations, or data that can be viewed as a whole to reveal personal identities, must be avoided.

In order to remain compliant, organizations must have a system in place to spot toxic data combinations that could run afoul of regulators. This is especially important as data-sharing agreements become more commonplace.

Next steps: Embracing the complex relationship

Finserv organizations must embrace the complex relationship with cloud security and compliance. It is, realistically, the only way to survive and thrive in a world where the cloud is the go-to method of innovation.

Taking steps for improvement in each of the four areas outlined above can feel overwhelming, so we suggest getting started by focusing on these three key actions:

Innovate quickly. Innovation is crucial in today’s finserv landscape. Organizations in financial services are competing for attention, which requires continuous digital transformation. The cloud allows these innovations to happen fast, but CISOs must ensure a secure environment for advancements to effectively take place. Is your organization striking the right balance between innovation and safety?
Automate aggressively. There are too many data points in today’s multi-cloud environments for security teams to track successfully without automation. Ongoing hygiene practices and internal audits are made possible using automation best practices. Do you have the right controls in place to launch an automation strategy that supports — and enhances — your security processes?
Transform culture. Never forget that people are at the center of your security and compliance strategy. Improving communication, education and consistency across teams can upgrade your organization’s compliance strategy. And remember: Your compliance strategy will be under increased scrutiny from executives and boards in the coming years. Does your team understand the “why” behind the security best practices you’re asking them to support?

Let’s navigate the future of cloud security for finserv together. Learn more here.

Additional reading:

The Future of Finserv Security: Cloud Expert and Former CISO Anthony Johnson Weighs In

2022-02-16 Rapid7

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/02/16/the-future-of-finserv-security-cloud-expert-and-former-ciso-anthony-johnson-weighs-in/

The Future of Finserv Security: Cloud Expert and Former CISO Anthony Johnson Weighs In

In today’s increasingly mobile, fast-paced world, it’s no surprise that financial services (finserv) organizations have a massive bullseye on their backs. The amount of personal data they access daily makes them an attractive target for those with malicious intent. In fact, the average cost of a data breach in the financial services sector is $18.9 million, according to data from IBM. With so much at stake, finserv security professionals need to remain vigilant and up-to-date on evolving trends and best practices occurring throughout the sector.

That’s where Anthony Johnson comes in. Johnson is a cloud security expert who has experienced almost every facet of cybersecurity. From being a hands-on red team technician to serving as a Global Chief Information Security Officer (CISO) at JP Morgan Chase, Johnson has seen it all.

We caught up with Johnson to get his take on the latest developments in cloudsec and how these developments are being received within the financial services sector.

What unique challenges or pain points did you/do you encounter as a CISO in finserv?

When I think about the challenges I faced as a CISO in this space, all roads lead back to innovation and the need to move quickly. Business units in financial services are generally expected to move at the speed of consumer demand.

And this need to innovate is different from other industries, adding even more pressure. Consumers demand the latest and greatest technology for convenience and ease of use. They place financial institutions under intense pressure to continuously improve. Financial services organizations will always strive for the latest innovation because they need to in order to compete for consumer attention.

How has finserv security evolved over the last few years as it relates to the cloud?

Many financial services organizations have started utilizing the cloud because it allows them to innovate quickly. But another component of cloud adoption, and specifically cloud security, is managing technical debt.

If you think about the myriad of mergers and acquisitions that have happened in the finserv industry over the past few decades, it’s easy to see how so many organizations have inherited disparate technologies that aren’t fully integrated. There could be some systems that you quite literally cannot turn off without major risk to the entire economy, considering how much financial information flows through those systems on a regular basis. The stakes are high. It’s essential that technology upgrades and security advancements be handled with care.

Despite this, there is still a high volume of outdated technology and many legacy systems still operating – although it’s worth noting that this is different for post-2010 companies that have built everything to truly be ephemeral.

How would you describe the general maturity level with cloud security?

Financial services organizations have to defend every business practice; they can’t just identify one area to go big and win. People want the shiny, new thing that will give them an advantage in the market, so development and innovation have been a high priority over the last year. (See? I mentioned innovation again.)

A major upcoming challenge for finserv organizations and cloud security will be the specific tools they are required to use, and how to leverage them in a way that enables them to still move fast while remaining compliant with industry regulations.

What advice would you give to other CISOs in the finserv industry about cloud security?

I think CISOs in the finserv industry truly need to understand why cloud security is so important. It’s not just about remaining compliant — the scale and speed of the cloud is what makes it so great, but also so dangerous. When you have an automated system, what might at first appear to be a minor disruption can quickly compound. And the cloud makes everything way faster. That’s why hygiene practices are essential. You need to have your house in order.

The best strategy for this is tight asset management. Most organizations don’t actually see their assets expanding. Asset creep is a real problem, especially now. Business users are increasingly technical and can spin up new sets of instances that put the company at risk (think shadow IT). This is quite different from the data centers of the past when unauthorized users weren’t even allowed in the building to plug something in. Bottom line: Security teams need visibility.

How can CISOs mitigate these risks with cloud security going forward?

CISOs who are looking to mature their security strategy will want to start by making distinctions between roles of the security leaders. There are some CISOs who have a governance risk background and others who have technical experience. Understanding your unique skill set is a major part of knowing how to approach the role and hire the right staff for your success. And this extends to identifying and using the best platforms, as well.

Your “supporting cast” of security team members can help you gain big-picture visibility into the cloud. Leaning on their expertise can be invaluable, especially considering that many security leaders do a lot of coaching for regulators to keep them educated in the constant evolution of cloud security. Similar to the need for innovation, it’s worth noting that this need for security knowledge in financial services also differs greatly from the expectations of leaders within retail, hospitality, or manufacturing industries. For example, in those industries, they don’t need to train a regulator on how autoscaling is applicable to cyberspace.

There’s a different expectation in financial services and leaders in this industry need to be aware of that when strategizing growth.

What are your predictions for the future of cloud security?

Right now, organizations in financial services are facing the challenge of having too many tools. Having a larger security budget than other sectors usually means you get one of everything; it’s a real mixed blessing. Finserv has been driving a big integration story about how the tools really work together, so I anticipate we’ll see more large security vendors starting to shift to an integrated approach.

Another trend that’s unique to this industry is the fact that financial services also have investment arms, and we’re seeing these shift the strategy of security leaders, as well. Basically, when a financial services organization invests in a product, it tends to have a trickle-down effect, and the IT security team can find themselves being asked to adopt those new technologies. I think we’ll see more of this over the next year, and IT security teams are going to need to determine how to best implement new solutions in a seamless and effective way.

Security and cloud leaders in financial services need to watch for true innovation in the space and examine how competitors are embracing digital transformation. What does it look like, and what could it mean for you?

Let’s navigate the future of cloud security for finserv together. Learn more here.

Additional reading:

Why Security in Kubernetes Isn’t the Same as in Linux: Part 2

2022-02-07 Sagi Rosenthal

Post Syndicated from Sagi Rosenthal original https://blog.rapid7.com/2022/02/07/why-security-in-kubernetes-isnt-the-same-as-in-linux-part-2/

Why Security in Kubernetes Isn't the Same as in Linux: Part 2

Security for Kubernetes might not be quite the same as what you’re used to. In our previous article, we covered why security is so important in both Linux on-premises servers and cloud Kubernetes clusters. We also talked about 3 major aspects of Linux server security — processes, network, and file system — and how they correspond to Kubernetes. So today, we’ll talk more about the security concerns unique to Kubernetes.

Configurations

When trying to secure your infrastructure, you have to start by configuring it well. For example, this might mean disabling all unused features or using allow-policies wherever you can to keep your files, executables, or network available only to the intended entity. Both Linux servers and Kubernetes clusters have known vulnerabilities and recommendations.

One of the famous among these is the Center for Internet Security (CIS) recommendations, which are often used for compliance for insurance. Having a cloud security platform that can help implement these recommendations can be a major boon to your security.

API server

The Kubernetes API server is the admin panel, so to speak, of your cluster. In most deployments, this HTTP server is exposed to the internet. This means that a hacker that finds their way to the API server can have full control over your cluster.

Using the most strict authentication and authorization settings is highly recommended to prevent this. If you can set your cluster to private, with access only allowed from an internal network, you can sleep well at night. And just as with with configurations, you should be aware at all times of who (and what) can have access to which resources and operations in your cluster.

Audit log and other Kubernetes logs

In Kubernetes, there are additional attack vectors using the Kubernetes control plane itself that don’t exist in Linux server security. For example, an attack could call the Kubernetes API to load a new pod you didn’t want.

Kubernetes and cloud providers invest a lot of effort in preventing unauthorized users and machines from doing this. But there is always a chance that one of your employees gets hacked or a badly configured service account has too much power. Kubernetes logs all requests to its audit log so they can be investigated later in case of a breach. Additional logs include the kube-API log or etcd (resources DB) log.

Why Security in Kubernetes Isn't the Same as in Linux: Part 2

Container runtime

Container runtime is also a unique aspect of Kubernetes security. In Kubernetes, each node is actually a virtual Linux server running a container runtime daemon. A container runtime is responsible for managing the images and running and monitoring the containers, their storage and network provisioning, and more. You might be familiar with Docker as a container runtime. In reality, Docker is a company developing multiple container tools, and their container runtime is named containerd. Other container runtimes for Kubernetes include CRI-O, Rocket, and more.

Apart from a whole Linux server or virtual machine that uses its own single operating system, multiple containers are usually running over multiple operating systems that share the same host kernel. Although the operating systems of the containers are minimal, they may still have security holes. And the more holes the merrier for the attacker! Monitoring the container runtime activity can also yield a lot of information about what is going on in the node — what processes are running inside the container, any internal communication that might escape from network monitoring, the data being collected and created, and so on.

Right tools, lower risks

The unique interfaces and engines of Kubernetes can be an additional exposed surface in terms of security, especially when considering the complexity of the system. However, don’t forget that distribution and containerization add to security and help isolate potential malware.

Kubernetes may come with a few new risks to watch out for, but that’s no reason to be scared off. As long as you know what to look for, security for your Kubernetes clusters doesn’t have to be any harder than it was for your Linux servers. And there’s no need to go it alone — not when you can have handy tools like InsightCloudSec, Rapid7’s cloud-native security platform, at your side.

Additional reading

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

How to configure rotation and rotation windows for secrets stored in AWS Secrets Manager

2022-02-02 Fatima Ahmed

Post Syndicated from Fatima Ahmed original https://aws.amazon.com/blogs/security/how-to-configure-rotation-windows-for-secrets-stored-in-aws-secrets-manager/

November 21, 2022: We updated this post to reflect the fact that AWS Secrets Manager now supports rotating secrets as often as every four hours.

AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, API keys, and other secrets throughout their lifecycles. You can specify a rotation window for your secrets, allowing you to rotate secrets during non-critical business hours or scheduled maintenance windows for your application. Secrets Manager now supports rotation of secrets as often as every four hours, on a predefined schedule you can configure to conform to your existing maintenance windows. Previously, you could only specify the rotation interval in days. AWS Secrets Manager would then rotate the secret within the last 24 hours of the scheduled rotation interval. You can rotate your secrets using an AWS Lambda rotation function provided by AWS, or create a custom Lambda rotation function.

With this release, you can now use Secrets Manager to automate the rotation of credentials and access tokens that must be refreshed more than once per day. This enables greater flexibility for common developer workflows through a single managed service. Additionally, you can continue to use integrations with AWS Config and AWS CloudTrail to manage and monitor your secret rotation configurations in accordance with your organization’s security and compliance requirements. Support for secrets rotation as often as every four hours is provided at no additional cost.

Why might you want to rotate secrets more than once a day? Rotating secrets more frequently can provide a number of benefits, including: discouraging the use of hard-coded credentials in your applications, reducing the scope of impact of a stolen credential, or helping you meet organizational requirements around secret rotation.

Hard-coding application secrets is not recommended, because it can increase the risk of credentials being written in logs, or accidentally exposed in code repositories. Using short-lived secrets limits your ability to hard-code credentials in your application. Short-lived secrets are rotated on a frequent basis: for example, every four hours – meaning even a hard-coded credential can only be used for a short period of time before it needs to be refreshed. This also means that if a credential is compromised, the impact is much smaller — the secret is only valid for a short period of time before the secret is rotated.

Secrets Manager supports familiar cron and rate expressions to specify rotation frequency and rotation windows. In this blog post, we will demonstrate how you can configure a secret to be rotated every four hours, how to specify a custom rotation window for your secret using a cron expression, and how you can set up a custom rotation window for existing secrets. This post describes the following processes:

Create a new secret and configure it to rotate every four hours using the schedule expression builder
Set up rotation window by directly specifying a cron expression
Enabling a custom rotation window for an existing secret

Use case 1: Create a new secret and configure it to rotate every four hours using the schedule expression builder

Let’s assume that your organization has a requirement to rotate GitHub credentials every four hours. To meet this requirement, we will create a new secret in Secrets Manager to store the GitHub credentials, and use the schedule expression builder to configure rotation of the secret at a four-hour interval.

The schedule expression builder enables you to configure your rotation window to help you meet your organization’s specific requirements, without requiring knowledge of cron expressions. AWS Secrets Manager also supports directly entering a cron expression to configure the rotation window, which we will demonstrate later in this post.

To create a new secret and configure a four-hour secret rotation schedule

Sign in to the AWS Management Console, and navigate to the Secrets Manager service.
Choose Store a new secret.

Figure 1: Store a secret in AWS Secrets Manager
In the Secret type section, choose Other type of secret.

Figure 2: Choose a secret type in Secrets Manager
In the Key/value pairs section, enter the GitHub credentials that you wish to store.
Select your preferred encryption key to protect the secret, and then choose Next. In this example, we are using an AWS managed key.

Note: Find more information to help you decide what encryption key is right for you.
Enter a secret name of your choice in the Secret name field. You can optionally provide a Description of the secret, create tags, and add resource permissions to the secret. If desired, you can also replicate the secret to another region to help you meet your organization’s disaster recovery requirements by following the procedure in this blog post.
Choose Next.

Figure 3:Create a secret to store your Git credentials
Turn on Automatic rotation to enable rotation for the secret.
Under Rotation schedule, choose Schedule expression builder.
1. For Time unit, choose Hours, then enter a value of 4.
2. Leave the Window duration field blank as the secret is to be rotated every 4 hours.
3. For this example, keep the Rotate immediately when the secret is stored check box selected to rotate the secret immediately after creation
  
  Figure 4: Enable automatic rotation using the schedule expression builder
4. Under Rotation function, choose your Lambda rotation function from the drop down menu.
5. Choose Next.
6. On the Secret review page, you are provided with an overview of the secret. Review the secret and scroll down to the Rotation schedule section.
7. Confirm the Rotation schedule and Next rotation date meet your requirements.
  
  Figure 5: Rotation schedule with a summary of the configured custom rotation window
8. Choose Store secret.
9. To view the Rotation configuration for the secret, select the secret you created.
10. On the Secrets details page, scroll down to the Rotation configuration section. The Rotation status is Enabled and the Rotation schedule is rate(4 hours). The name of your Lambda function being used for rotation is displayed.
  
  Figure 6: Rotation configuration of your secret

You have now successfully stored a secret using the interactive schedule expression builder. This option provides a simple mechanism to configure rotation windows, and does not require expertise with cron expressions.

In the next example, we will be using the schedule expression option to directly enter a cron expression, to achieve a more complex rotation interval.

Use case 2: Set up a custom rotation window using a cron expression

The procedures described in the next two sections of this blog post require that you complete the following prerequisites:

Configure an Amazon Relational Database Service (Amazon RDS) DB instance, including creating a database user.
Sign in to the AWS Management Console using a role that has SecretsManagerReadWrite permission.
Configure the Lambda function to connect with the Amazon RDS database and Secrets Manager by following the procedure in this blog post.

Configuring complicated rotation windows for secrets may be more effective using the schedule expression option, rather than the schedule expression builder. The schedule expression option allows you to directly enter a cron expression using a string of six inputs. Directly entering cron expressions provides more flexibility when defining a rotation schedule that is more complex.

Let’s suppose you have another secret in your organization which does not need to be rotated as frequently as others. Consequently, you’ve been asked to set up rotation for every last Sunday of the quarter and during the off-peak hours of 1:00 AM to 4:00 AM UTC to avoid application downtime. Due to the complex nature of the requirements, you will need to use the schedule expression option to write a cron job to achieve your use case.

Cron expressions consist of the following 6 required fields which are separated by a white space; Minutes, Hours, Day of month, Month, Day of week, and Year. Each required field has the following values using the syntax cron(fields).

Fields	Values	Wildcards
Minutes	Must be 0	None
Hours	0-23	/
Day-of-month	1 – 31	, – * ? / L
Month	1-12 or JAN-DEC	, – * /
Day-of-week	1-7 or SUN-SAT	, – * ? L #
Year	*	accepts * only

Table 1: Secrets Manager supported cron expression fields and corresponding values

Wildcard	Description
,	The , (comma) wildcard includes additional values. In the Month field, JAN,FEB,MAR would include January, February, and March.
–	The – (dash) wildcard specifies ranges. In the Day field, 1-15 would include days 1 through 15 of the specified month.
*	The * (asterisk) wildcard includes all values in the field. In the Month field, * would include every month.
/	The / (forward slash) wildcard specifies increments In the Month field, you could enter 1/3 to specify every 3rd month, starting from January. So 1/3 specifies the January, April, July, Oct.
?	The ? (question mark) wildcard specifies one or another. In the day-of-month field you could enter 7 and then enter ? in the day-of-week field since the 7th of a month could be any day of a given week.
L	The L wildcard in the Day-of-month or Day-of-week fields specifies the last day of the month or week. For example, in the week Sun-Sat, you can state 5L to specify the last Thursday in the month.
#	The # wildcard in the Day-of-week field specifies a certain instance of the specified day of the week within a month. For example, 3#2 would be the second Tuesday of the month: the 3 refers to Tuesday because it is the third day of each week, and the 2 refers to the second day of that type within the month.

Table 2: Description of supported wilds cards for cron expression

As the use case is to setup a custom rotation window for the last Sunday of the quarter from 1:00 AM to 4:00 AM UTC, you’ll need to carry out the following steps:

To deploy the solution

To store a new secret in Secrets Manager repeat steps 1-6 above.
Once you’re on the Secret Rotation section of the Store a new secret screen, click on Automatic rotation to enable rotation for the secret.
Under Rotation schedule, choose Schedule expression.

In the Schedule expression field box, enter cron(0 1 ? 3/3 1L *).

Fields	Values	Explanation
Minutes	0	The use case does not have a specific minute requirement
Hours	1	Ensures the rotation window starts from 1am UTC
Day-of-month	?	The use case does not require rotation to occur on a specific date in the month
Month	3/3	Sets rotation to occur on the last month in a quarter
Day-of-week	1L	Ensures rotation occurs on the last Sunday of the month
Year	*	Allows the rotation window pattern to be repeated yearly

Table 3: Using cron expressions to achieve your rotation requirements

Figure 7: Enable automatic rotation using the schedule expression

On the Rotation function section choose your Lambda rotation function from the drop down menu.
Choose Next.
On the Secret review page, review the secret and scroll down to the Rotation schedule section. Confirm the Rotation schedule and Next rotation date meets your requirements.

Figure 8: Rotation schedule with a summary of your custom rotation window
Choose Store.
To view the Rotation configuration for this secret, select it from the Secrets page.
On the Secrets details page, scroll down to the Rotation configuration section. The Rotation status is Enabled, the Rotation schedule is cron(0 1 ? 3/3 1L *) and the name of your Lambda function being used for your custom rotation is displayed.

Figure 9: Rotation configuration section with a rotation status of Enabled

Use case 3: Enabling a custom rotation window for an existing secret

If you already use AWS Secrets Manager as a way to store and rotate secrets for your Organization, you might want to take advantage of custom scheduled rotation on existing secrets. For this use case, to meet your business needs the secret must be rotated bi-weekly, every Saturday from 12am to 5am.

To deploy the solution

On the Secrets page of the Secrets Manager console, chose the existing secret you want to configure rotation for.
Scroll down to the Rotation configuration section of the Secret details page, choose Edit rotation.

Figure 10: Rotation configuration section with a rotation status of Disabled
On the Edit rotation configuration pop-up window, turn on Automatic rotation to enable rotation for the secret.
Under Rotation Schedule choose Schedule expression builder, optionally you can use the Schedule expression to create the custom rotation window.
1. For the Time Unit choose Weeks, then enter a value of 2.
2. For the Day of week choose Saturday from the drop-down menu.
3. In the Start time field type 00. This ensures rotation does not start until 00:00 AM UTC.
4. In the Window duration field type 5h. This provides Secrets Manager with a 5hr period to rotate the secret.
5. For this example, keep the check box marked to rotate the secret immediately.
  
  Figure 11: Edit rotation configuration pop-up window
6. Under Rotation function, choose the Lambda function which will be used to rotate the secret.
7. Choose Save.
8. On the Secrets details page, scroll down to the Rotation configuration section. The Rotation status is Enabled, the Rotation schedule is cron(0 00 ? * 7#2,7#4 *) and the name of the custom rotation Lambda function is visible.
  
  Figure 12:Rotation configuration section with a rotation status of Enabled

Summary

Regular rotation of secrets is a Secrets Manager best practice that helps you to meet compliance requirements, for example for PCI DSS, which mandates the rotation of application secrets every 90 days, and to improve your security posture for databases and credentials. The ability to rotate secrets as often as every four hours helps you rotate secrets more frequently, and the rotation window feature helps you adhere to rotation best practices while still having the flexibility to choose a rotation window that suits your organizational needs. This allows you to use AWS Secrets Manager as a centralized location to store, retrieve, and rotate your secrets regardless of their lifespan, providing a uniform approach for secrets management. At the same time, the custom rotation window feature alleviates the need for applications to continuously refresh secret caches and manage retries for secrets that were rotated, as rotation will occur during your specified window when the application usage is low.

In this blog post, we showed you how to create a secret and configure the secret to be rotated every four hours using the schedule expression builder. The use case examples show how each feature can be used to achieve different rotation requirements within an organization, including using the schedule expression builder option to create your cron expression, as well as using the schedule expression feature to help meet more specific rotation requirements.

You can start using this feature through the AWS Secrets Manager console, AWS Command Line Interface (AWS CLI), AWS SDK, or AWS CloudFormation. To learn more about this feature, see the AWS Secrets Manager documentation. If you have feedback about this blog post, submit comments in the Comments section below. If you have questions about this blog post, start a new thread on AWS Secrets Manager re:Post or contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Why Security in Kubernetes Isn’t the Same as in Linux: Part 1

2022-01-27 Sagi Rosenthal

Post Syndicated from Sagi Rosenthal original https://blog.rapid7.com/2022/01/27/why-security-in-kubernetes-isnt-the-same-as-in-linux-part-1/

Why Security in Kubernetes Isn't the Same as in Linux: Part 1

Kubernetes was first presented in 2014, and it almost entirely changed the way technological and even non-tech companies use infrastructure for running their applications. The Kubernetes platform still feels new and exciting — it has awesome features and can fit most use cases.

But hackers find the combination of new technology and user inexperience that’s just right for their malicious activity. Deploying your product on a Kubernetes cluster has a different security cost than on a traditional Linux server.

What are the risks of using Kubernetes?

The risks of a Kubernetes (K8s) deployment are actually the same as in traditional Linux servers. Most of them can be summed up to these 3 targets:

Denial of Service (DoS): These kinds of attacks want your service down. They can be caused in many different ways, including distributed denial of service (DDoS) attacks or SQL injections that erase your databases. As there is no direct profit to the attacker, these attacks are of most interest to malicious groups who disagree with your company values or products, or to your competitors.

Why Security in Kubernetes Isn't the Same as in Linux: Part 1

Information exfiltration: Another type of attack targets the information you hold. These attacks can collect your information, like your profits, source codes, names of employees, and so on. Or they can collect private data about your customers and users — who they are, their credit card numbers, health state, financial assets, and everything you know about them. None of this is data you want to be known outside the company.
Hardware hijack: A hardware hijack is any type of attack that runs a malicious code on your compute resources and causes them to operate in a way that you did not program or intend them to run. Most of these attacks are related to cryptocurrency. They typically either turn your CPU/GPU to Bitcoin miner or conduct a ransomware attack by encrypting your file system and requesting you to pay ransom (usually in Bitcoin) to unencrypt it. As the important point here for attackers is profit, not the identity of the victim, these attacks usually originate from bots or automatic scripts, rather than with dedicated special operations of malicious groups or individuals.

How can you defend yourself?

Securing deployments and identifying malicious activity on Kubernetes clusters is similar to how it’s done on traditional Linux servers. Most of the differences are in the implementation itself. But there are some distinctions worth mentioning. Let’s focus in on the operating system aspects of security.

Processes and system calls

“The system call is the fundamental interface between an application and the Linux kernel.” —Linux manual page

Linux has over 400 different system calls. These can be used for requesting to read a file, executing another program, sending a network message, and more. As you’ve probably guessed, these operations can be risky when used by unwanted programs.

The Linux Kernel has security mechanisms against malware, but it isn’t fully protected. So system calls may seem legitimate even when they aren’t. Tracking these system calls can give good insight on what a process does. In native Linux, it can be easy to track these down from a single point on the server. However, in K8s Linux nodes, the distribution, dynamics, and containerization makes this mission a very complex task.

Network security

The internet connection is your face for the customers, but it’s also the entry point for various malicious software into your infrastructure. Luckily, the big cloud providers and most of the internet-facing frameworks are well-protected against these attacks. But nothing is 100% safe. Moreover, some of the images you are using may contain security holes themselves. These can cause a malicious program to initiate from inside your cluster.

Tracking the network from the inside out can give you a lot of information on malicious activity. But you also have to consider the “east-to-west” traffic inside your infrastructure — the internal communication. In traditional Linux servers and VMs, you know exactly which microservices exist and define firewall services accordingly. However, in Kubernetes, the dynamic nature of the pods and resources makes it hard to track this traffic, so it can be difficult to find the network holes.

File system

It may seem easy to detect new files and file changes in order to determine unwanted changes, but tracking and analyzing your whole file system can be a large, complex task in Linux servers. They can have terabytes of storage, and reading them — especially from a magnetic hard disk — isn’t fast enough to detect malicious activity when it happens. However, the containerization concept of Kubernetes can be to our advantage here, as container images are usually small, lightweight, and repetitive. Looking inside the containers files should have highly expected results.

More to come

This is one of two articles covering the detective resources that can help us identify unwanted activity in your Kubernetes clusters. In this first part, we saw that both Kubernetes and traditional Linux servers have vulnerabilities that originate in the processes, network, or file system. However, there are differences in how to monitor malicious activity in Kubernetes versus Linux. Some vulnerabilities may seem harder to defend in Kubernetes, but most of them are actually easier.

InsightCloudSec, Rapid7’s cloud-native security platform, covers these differences and ensures your on-premises server farm is secured.

The next article will explain further about the unique aspects of Kubernetes security that do not exist in traditional Linux servers. Stay tuned!

Additional reading

Kubernetes Guardrails: Bringing DevOps and Security Together on Cloud

Stay Ahead of Threats With Cloud Workload Protection

Make Room for Cloud Security in Your 2022 Budget

Time to Act: Bridging the Gap in Cloud Automation Adoption

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Stay Ahead of Threats With Cloud Workload Protection

2021-12-10 Alon Berger

Post Syndicated from Alon Berger original https://blog.rapid7.com/2021/12/10/stay-ahead-of-threats-with-cloud-workload-protection/

Stay Ahead of Threats With Cloud Workload Protection

When it comes to cloud-native applications, optimal security requires a modern, integrated, and automated approach that starts in development and extends to runtime protection. Cloud workload protection (CWP) helps make that goal possible by bringing major structural changes to software development and enhancing security across all processes.

Assessing workload risk in the cloud

Both the rise of cloud proliferation and the high speed of deployments can make distilling down the necessary cloud security controls an overwhelming challenge. Add to the mix the ever-evolving threat landscape, and the measures you take can literally make or break your cloud deployments, including the security of your workloads.

The increasing distribution and complexity of cloud-native applications across VMs, hosts, Kubernetes, and multiple vendors requires an end-to-end, consistent workload protection platform that unifies both CSPM and CWPP functionalities, thus enabling a holistic approach for protecting valuable assets in the cloud.

How Rapid7 is changing cloud workload protection

In order to get unmanaged risk under control, Rapid7 is on a mission to help drive cloud security forward, both within individual organizations and as an entire industry.

This is why Rapid7 recently introduced InsightCloudSec, an entire division dedicated solely to cloud security and all it encompasses.

In its most recent launch, InsightCloudSec brings forward a series of functionalities that bolsters our ability to help our customers protect their cloud workloads and deployments by providing a fully integrated, cloud-native security solution at scale. These improvements include:

Enhancing risk assessment of Kubernetes and containers
Enabling developers to scan code from the CLI on their machines
Expanding automation based on event-driven detections in multi-cloud environments
Providing unified visibility and robust context across multi-cloud environments
Automating workflows so organizations can gain maximum efficiency

3 keys to consolidating cloud risk assessment

In an effort to help this emerging market become more mainstream and easier to operationalize, we believe there are 3 main things that organizations need to be able to do when it comes to cloud security.

1. Shift left

Prevent problems before they happen by providing a single, consistent set of security checks throughout the CI/CD pipeline to uncover misconfigurations and policy violations without delaying deployment. Not only does this help solve issues at their root cause and prevent them from happening over and over again, but it also makes for a better working relationship between the security team and the DevOps organization that is trying to move fast and innovate. By shifting left, organizations save money, and security teams are able to give developers the information and tools they need to make the right decisions as early as possible, avoiding delays later in the deployment or operationalizing stages of the CI/CD pipeline.

2. Reduce noise

Security teams need more context and simpler insights so they can actually understand the top risks in their environment. By unifying visibility across the entire cloud footprint, normalizing the terminology across each different cloud environment, and then providing rich context about interconnected assets, security teams can vastly simplify risk assessment and decision-making across even the most complex cloud and container environments.

3. Automate workflows

Finally, the ephemeral nature and speed of change in cloud environments has outstripped the human capability to manage and remediate issues manually. This means organizations need to automate DevSecOps best practices by leveraging precise automation that speeds up remediation, reduces busywork, and allows the security team to focus on the bigger picture.

By bringing together enhanced risk assessment of Kubernetes and containers, shifting further left with a CLI integration, and expanding event-based detections into the cloud-native security platform, Rapid7 is making it easier for teams to consolidate visibility and maintain consistent controls across even the most complex cloud environments.

Stay ahead of security in the modern threat landscape by ensuring cloud security as an ongoing process, and reduce your attack surface by building the necessary security measures early in an application’s life cycle.

Want to learn more?

Watch the on-demand webinar on InsightCloudSec and its Kubernetes protection

Snaring the Bad Folks

2021-12-08 Netflix Technology Blog

Post Syndicated from Netflix Technology Blog original https://netflixtechblog.com/snaring-the-bad-folks-66726a1f4c80

Project by Netflix’s Cloud Infrastructure Security team (Alex Bainbridge, Mike Grima, Nick Siow)

Cloud security is a hard problem, but an even harder one is cloud security at scale. In recent years we’ve seen several cloud focused data breaches and evidence shows that threat actors are becoming more advanced with their techniques, goals, and tooling. With 2021 set to be a new high for the number of data breaches, it was plainly evident that we needed to evolve how we approach our cloud infrastructure security strategy.

In 2020, we decided to reinvent how we handle cloud security findings by redefining how we write and respond to cloud detections. We knew that given our scale, we needed to rely heavily on automations and that we needed to build our solutions using battle tested scalable infrastructure.

Introducing Snare

Snare is our Detection, Enrichment, and Response platform for handling cloud security related findings at Netflix. Snare is responsible for receiving millions of records a minute, analyzing, alerting, and responding to them. Snare also provides a space for our security engineers to track what’s going on, drill down into various findings, follow their investigation flow, and ensure that findings are reaching their proper resolution. Snare can be broken down into the following parts: Detection, Enrichment, Reporting & Management, and Remediation.

Overview

Snare was built from the ground up to be scalable to manage Netflix’s massive scale. We currently process tens of millions of log records every minute and analyze these events to perform in-house custom detections. We collect findings from a number of sources, which includes AWS Security Hub, AWS Config Rules, and our own in-house custom detections. Once ingested, findings are then enriched and processed with additional metadata collected from Netflix’s internal data sources. Finally, findings are checked against suppression rules and routed to our control plane for triaging and remediation.

Where We Are Today

We’ve developed, deployed, and operated Snare for almost a year, and since then, we’ve seen tremendous improvements while handling our cloud security findings. A number of findings are auto remediated, others utilize slack alerts to loop in the oncall to triage via the Snare UI. One major improvement was a direct time savings for our detection squad. Utilizing Snare, we were able to perform more granular tuning and aggregation of findings leading to an average of 73.5% reduction in our false positive finding volume across our ingestion streams. With this additional time, we were able to focus on new detections and new features for Snare.

Speaking of new detections, we’ve more than doubled the number of our in-house detections, and onboarded several detection solutions from security vendors. The Snare framework enables us to write detections quickly and efficiently with all of the plumbing and configurations abstracted away from us. Detection authors only need to be concerned with their actual detection logic, and everything else is handled for them.

As for security vendors, we’ve most notably worked with AWS to ensure that services like GuardDuty and Security Hub are first class citizens when it comes to detection sources. Integration with Security Hub was a critical design decision from the start due to the high amount of leverage we get from receiving all of the AWS Security findings in a normalized format and in a centralized location. Security Hub has played an integral role in our platform, and made evaluations of AWS security services and new features easy to try out and adopt. Our plumbing between Security Hub and Snare is managed through AWS Organizations as well as EventBridge rules deployed in every region and account to aid in aggregating all findings into our centralized Snare platform.

Example AWS Security Finding from our testing/sandbox account In Snare UI

One area that we are investing heavily is our automated remediation potential. We’ve explored a few different options ranging from fully automated remediations, manually triggered remediations, as well as automated playbooks for additional data gathering during incident triage. We decided to employ AWS Step Functions to be our execution environment due to the unique DAGs we could build and the simplistic “wait”/”task token” functionality, which allows us to involve humans when necessary for approval/input.

Building on top of step functions, we created a 4 step remediation process: pre-processing, decision, remediation, and post-processing. Pre/post processing can be used for managing out-of-band resource checks, or any work that needs to be done in order to ensure a successful remediation. The decision step is used to perform a final pre-flight check before remediation. This can involve a human reachout, verifying the resource is still around, etc. The remediation step is where we perform our actual remediation. We’ve been able to use this to a great deal of success with infrastructure-wide misconfigured resources being automatically fixed near real time, and enabling the creation of new fully automated incident response playbooks. We’re still exploring new ways we might be able to use this, and are excited for how we might evolve our approach in the near future.

Step Function DAG for S3 Public Access Block Remediation

Diagram from a remediation to enable S3’s public access block on a non-compliant bucket. Each choice stage allows for dynamic routing to a variety of different stages based on the output of the previous function. Wait stages are used when human intervention/approval is needed.

Extensible Learnings

We’ve come a long way in our journey, and we’ve had numerous learning opportunities that we wanted to collect and share. Hopefully, we’ve made the mistakes and learned from those experiences.

Information is Key

Home grown context and metadata streams are invaluable for a detection and response program. By uniting detections and context, you’re able to unlock a new world of possibilities for reducing false positives, creating new detections that rely on business specific context, and help better tailor your severities and automated remediation decisions based on your desired risk appetite. A common theme we’ve often encountered is the need to bring additional context throughout various stages of our pipeline, so make sure to plan for that from the get-go.

Step Functions for Remediations

Step functions provide a highly extensible and unique platform to create remediations. Utilizing the AWS CDK, we were able to build a platform to enable us to easily roll out new remediations. While creating our remediation platform, we explored SSM Automation Runbooks. While SSM Automation Runbooks have great potential for remediating simple issues, we found they weren’t flexible enough to cover a wide spread of our needs, nor did they offer some of the more advanced features we were looking for such as reaching out to humans. Step functions gave us the right amount of flexibility, control, and ease of use in order to be a great asset for the Snare platform.

Closing Thoughts

We’ve come a long way in a year, and we still have a number of interesting things on the horizon. We’re looking at continuing to create new, more advanced features and detections for Snare to reduce cloud security risks in order to keep up with all of the exciting things happening here at Netflix. Make sure to check out some of our other recent blog posts!

Special Thanks

Special thanks to everyone who helped to contribute and provide feedback during the design and implementation of Snare. Notably Shannon Morrison, Sapna Solanki, Jason Schroth from our partner team Detection Engineering, as well as some of the folks from AWS — Prateek Sharma & Ely Kahn. Additional thanks to the rest of our Cloud Infrastructure Security team (Hee Won Kim, Joseph Kjar, Steven Reiling, Patrick Sanders, Srinath Kuruvadi) for their support and help with Snare features, processes, and design decisions!

Snaring the Bad Folks was originally published in Netflix TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kubernetes Guardrails: Bringing DevOps and Security Together on Cloud

2021-12-06 Alon Berger

Post Syndicated from Alon Berger original https://blog.rapid7.com/2021/12/06/kubernetes-guardrails-bringing-devops-and-security-together-on-cloud/

Kubernetes Guardrails: Bringing DevOps and Security Together on Cloud

Cloud and container technologies are being increasingly embraced by organizations around the globe because of the efficiency, superior visibility, and control they provide to DevOps and IT teams.

While DevOps teams see the benefits of cloud and container solutions, these tools create a learning curve for their security colleagues. Because of this, security teams often want to slow down adoption while they figure out a strategy for maintaining security and compliance in these new fast-moving environments.

Container and Kubernetes (K8s) environments are already fairly complex as it is, and layering multiple additional security tools into the mix makes it even more challenging from a management perspective. Organizations need to find a way to enable their DevOps teams to move quickly and take advantage of the benefits of containers and K8s, while staying within the parameters the security team needs to maintain compliance with organizational policy.

This challenge goes beyond technology. These teams need to find a solution that allows them to work together well, doesn’t over-complicate their working relationship, and lets both sides get what they want with minimal overhead.

A holistic approach to Kubernetes security

As an open-source container orchestration system for automating deployment, scaling, and management of containerized applications, Kubernetes is extremely powerful. However, organizations must carefully balance their eagerness to embrace the dynamic, self-service nature of Kubernetes with the real-life need to manage and mitigate security and compliance risk.

Rapid7’s recent introduction of InsightCloudSec intelligently unifies both CSPM and CWPP functionalities, thus enabling a holistic approach for protecting valuable assets in the cloud — one that includes Kubernetes and workload security.

Learn more about InsightCloudSec here

Built for DevOps, trusted by security

In retrospect, 2020 was a tipping point for the Kubernetes community, with a massive increase in adoption across the globe. Many companies, seeking an efficient, cost-effective way to make this huge shift to the cloud, turned to Kubernetes. But this in turn created a growing need to remove Kubernetes security blind spots. For this reason, we’ve introduced Kubernetes Guardrails.

With Kubernetes Security Guardrails, organizations are equipped with a multi-cluster vulnerability scanner that covers rich Kubernetes security best practices and compliance policies, such as CIS Benchmarks. As part of Rapid7’s InsightCloudSec solution, this new capability introduces a platform-based and easy-to-maintain solution for Kubernetes security that is deployed in minutes and is fully streamlined in the Kubernetes pipeline.

Securing Kubernetes with InsightCloudSec

Kubernetes Security Guardrails is the most comprehensive solution for all relevant Kubernetes security requirements, designed from a DevOps perspective with in-depth visibility for security teams.

InsightCloudSec is designed to be an agentless state machine, seamlessly applied to any computing environment — public cloud or private software-defined infrastructure.

InsightCloudSec continually interacts with the APIs to gather information about the state of the hosts and the Kubernetes clusters of interest. These hosts can be GCP, AWS, Azure, or a private data center that can expose infrastructure information via an API.

Integrated within minutes, the Kubernetes Guardrails functionality simplifies the security assessment for the entire Kubernetes environment and the CI/CD pipeline, while also creating baseline profiles for each cluster, and highlighting and scoring security risks, misconfigurations, and hygiene drifts.

Both DevOps and Security teams enjoy the continuous and dynamic analysis of their Kubernetes deployments, all while seamlessly complying with regulatory requirements for Kubernetes.

With Kubernetes Guardrails, Dev teams are able to create a snapshot of cluster risks, delivered with a detailed list of misconfigurations, while detecting real-time hygiene and conformance drifts for deployments running on any cloud environment. Some of the most common use cases include:

Kubernetes vulnerability scanning
Hunting misplaced secrets and excessive secret access
Workload hardening (from pod security to network policies)
Istio security and configuration best practices
Ingress controllers security
Kubernetes API server access privileges
Kubernetes operators best practices
RBAC controls and misconfigurations

Ready to drive cloud security forward?

Rapid7 is proud to introduce a Kubernetes security solution that encapsulates all-in-one capabilities and unmatched coverage for all things Kubernetes.

With a security-first approach and strict compliance adherence, Kubernetes Guardrails enable a better understanding and control over distributed projects, and help organizations maintain smooth business operations.

Want to learn more? Watch the on-demand webinar on InsightCloudSec and its Kubernetes protection.

InsightCloudSec Supports 12 New AWS Services Announced at re:Invent

2021-12-06 Chris DeRamus

Post Syndicated from Chris DeRamus original https://blog.rapid7.com/2021/12/06/insightcloudsec-supports-12-new-aws-services-announced-at-re-invent/

InsightCloudSec Supports 12 New AWS Services Announced at re:Invent

In case you didn’t hear, Amazon hosted AWS re:Invent in Las Vegas last week. As has come to be expected at the annual mega-event, Amazon made a number of huge announcements and launched a significant number of improvements and brand-new services and settings to enhance their public cloud platform, including an improved version of Amazon Inspector, S3 Object Ownership, Recycle Bin, EBS Archive Mode, and more.

Along with these announcements comes plenty of excitement and fanfare from the developer community who gets to take advantage of the new functionality. And that excitement is warranted. But these announcements also usually come with a hint of hesitation from their colleagues in security, who are responsible for analyzing all of these new services and settings to ensure that they are used properly and don’t introduce unintended consequences to their AWS environment. Yes, security is a factor here, but those unintended consequences also include costs associated with rolling out these new services. Rightfully so: It can often take weeks or months for organizations to vet these services, define governance policies, and actually start taking advantage of them.

But in order to help extinguish some of that announcement-induced anxiety and allow our customers to start taking advantage of these services as quickly as possible, the InsightCloudSec team has worked day and night for the last week to deliver support for a dozen of the new services that AWS rolled out last week.

In all of these cases, InsightCloudSec gathers the data related to these services across all AWS accounts and regions and consolidates it, giving security teams a single place to see all of the information across the entire AWS footprint. In many cases, the support also enhances the services provided by Amazon by providing additional context about the service or the resources associated with it.

Rather than choosing between slowing down innovation or taking on unmitigated risk, our customers will have the ability to take full advantage of each of these services as soon as they are available.

The list of newly supported AWS services and services includes:

Let’s take a look at a few of the most critical services and what they mean for DevOps and Security teams.

The new AWS Inspector

Amazon Inspector is a vulnerability management service that continually scans AWS workloads for software vulnerabilities and unintended network exposure. As an AWS-built service, Amazon Inspector is designed to exchange data and interact with other core AWS services not only to identify potential security findings, but also to automate addressing those findings.

By joining insights from both AWS Inspector and Rapid7, customers benefit from immediate value in the form of multiple enhancements across the board. These include enhanced risk assessment of containers and workloads, unified visibility and control, and robust context across AWS environments.

By consolidating AWS’s vulnerability management solutions with Rapid7’s cloud security capabilities, organizations are enabled with a highly scalable service, equipped with optimized security controls to better handle their most valuable assets.

InsightCloudSec seamlessly complements the new and improved AWS Inspector, allowing customers to leverage enhanced capabilities including:

Identify regions, accounts, and compute instances where AWS Inspector is not enabled, along with a new bot action to turn on the capability across EC2/ECR
Identify compute resources by risk score and/or specific findings
Identify accounts and regions with the highest overall risk
Add Inspector as an agent type so customers can switch to the “Vulnerability View,” which provides a single pane of glass to view and naturally sort assets by risk/severity findings across their entire fleet of accounts
Use Inspector data to enrich existing Insights such as resources on a public subnet, resources with an IAM role attached, etc. to build new Insights (e.g., EC2 instance on a public subnet with a security group exposing SSH that has been identified as high-risk by Inspector)

VPC Network Access Analyzer

Another great new service that Amazon rolled out is the Amazon VPC Network Access Analyzer, which helps their customers identify network configurations that lead to unintended network access. The tool essentially allows you to create a scope or query — for example, you could create a scope to find all web apps that do not use a firewall to access internet resources — then analyze your AWS account against that scope. It then serves up a list of the unexpected network paths between resources defined in the scope.

InsightCloudSec supports this new network analyzer by consuming all findings from the analyses our customers run in their entire AWS environment. This gives cloud security teams a single place to see all results, rather than having to jump from account to account to gather all the information across the entire AWS footprint. It also enriches the data provided by that network analysis with additional context about the resources, such as whether they have misconfigurations or overly permissive IAM policies attached to them, helping the user see the bigger picture and more effectively prioritize their work. Finally, the automation capabilities in InsightCloudSec allow our users to automatically schedule these network scans on a regular basis across target accounts, eliminating all manual effort.

S3 Object Ownership

The sheer scale of S3 makes access management a blind spot for a number of organizations. For years, customers who use S3 have had the ability to set object-level permissions, effectively superseding the access permissions established at the bucket level. While enhancements have been introduced over the years such as Block Public Access, which can help mitigate the chance of objects being made public via direct Access Control Lists (ACLs), not all customers leverage the capability. Amazon has gone a step further by introducing a capability known as S3 Object Ownership, which gives administrators the ability to completely disable object-level ACLs. This setting is now the default value on all newly created S3 buckets, and customers can now migrate their existing S3 buckets to leverage this capability.

InsightCloudSec now detects the presence of this capability and renders it in the product, as well as through the API response via the `Object Ownership` property. A new filter was created to identify S3 buckets based on the value of this property, and the team has also expanded the core Insight Storage Container Without Uniform Bucket Level Access to work across AWS, AWS GovCloud, and AWS China.

InsightCloudSec Supports 12 New AWS Services Announced at re:Invent

Recycle Bin

Data Lifecycle Management can be challenging as customer cloud footprints grow from dozens of cloud accounts to hundreds or even thousands. At InsightCloudSec we’ve seen customers with millions of EBS Snapshots across their fleet of accounts. While many of our customers have embraced AWS Backup to help centralize their backup and retention management, there’s always concern with the accidental removal of an important snapshot while performing cleanup operations across accounts.

AWS offers a new Recycle Bin service that can be used to reduce the risk of accidental deletion. Think of Recycle Bin in the same way that Recycle Bin operates on your own computer. When enabled, the capability will store snapshots for a period of time defined by the customer and allow them to be recovered. Customers define the length of time they’d like these snapshots to remain in the recycle bin before being permanently deleted.

InsightCloudSec now provides visibility into these Recycle Bin Rules directly within the Resources section of the product. We’ve also included filters to identify accounts/regions where snapshots exist and recycle bin rules are not in place. These filters can help InsightCloudSec customers continue to meet their evolving governance needs.

EBS Snapshot Archive

Going beyond Recycle Bin, AWS now offers a new archive mode storage class that, when enabled, can help customers reduce their storage costs. EBS Snapshot Archive is a new storage tier that is up to 75% cheaper than the standard storage tier. Converting to this tier is quite straightforward and can be done via the AWS Console or programmatic API.

To help our customers further reduce spend with this service, we’ve introduced visibility into this storage tier, along with a new filter and Bot action to help customers begin migrating to this new tier where applicable.

More to come

This is one of our team’s favorite weeks each year. It’s always great to see the new capabilities that the teams at Amazon have been hard at work on and how they take in customer feedback to mature their offering. The InsightCloudSec team will be introducing support for a number of these enhancements with our release this week (21.7.3) and will be working closely with our customers to add additional features and capabilities.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Make Room for Cloud Security in Your 2022 Budget

2021-11-19 Shelby Matthews

Post Syndicated from Shelby Matthews original https://blog.rapid7.com/2021/11/19/make-room-for-cloud-security-in-your-2022-budget/

Make Room for Cloud Security in Your 2022 Budget

Are you thinking about cloud security when making your 2022 budget? You should be. Cloud is the key to innovation and business transformation. It can make life so much easier. The cloud enables companies to expand their products or services, rapidly develop new products, and reach new customers. In fact, 70% of companies that have moved to the cloud plan on increasing their budgets in the future.

But the cloud can also bring unwanted problems. Hackers have figured out new creative ways to get to your data, human error causes misconfigurations, and security is often implemented too far down the workflow.

Cloud security is growing

In the recent years, there has been a growing reliance on cloud-based services as more companies have adopted the cloud. According to Rapid7 survey data, 4 out of 5 organizations say cloud adoption was necessary to keep their business competitive. The global cloud security market is estimated to reach $34.8 billion at the end of 2021 and expected to grow 14.2% over the next 5 years.

So, why are companies adopting the cloud?

It saves you money. According to TechnologyAdvice, companies can save an average of 15% on technology costs by moving to the cloud.
You can work on the go. This is a big one, especially during the pandemic. Employees switched to remote work and the cloud enabled a smooth transition.
The cloud adapts to what you want. Want more storage? The cloud can do it. Want to switch to a private network? The cloud can do it.

You don’t want to be featured in the news

Our Rapid7 researchers found 121 publicly reported cloud misconfigurations that resulted in data being exposed. Looking at 2021, we are seeing the same patterns of misconfigured buckets that are exposed online. The median number of files being exposed in a breach was 10 million last year. Those files range from small things like names or ages to more serious data like social security numbers and addresses.

2021 has already seen a couple of mega breaches, one exposing over 12 billion records and another two that exposed over a billion. Polecat, a UK reputation firm, exposed over 12 billion records in March after leaving an Elasticsearch server open with no protection. Cybercrimes and attacks have become more sophisticated and security has been slow to adapt. There is a simple solution to keep this from happening to your company: investing in cloud security. Most misconfigurations are the result of human error, and having cloud security tools in place will help mitigate the risk.

What can cloud security look like for you?

So how can you keep your data safe in the cloud? In 2022 and beyond, effective cloud security relies on three core concepts.

Shift left: Prevent problems before they even happen by implementing security earlier in your workflows. Having a consistent set of security checkpoints early in your pipeline will stop misconfigurations and policy violations before they deploy.
Reduce noise: It’s easy for security professionals to get lost in the noise from constant notifications about tickets being opened and closed or constant alerts that don’t need their attention. Reducing noise means having full visibility into cloud environments.
Automation and remediation: Automation is the key to achieving cloud security at the speed of scale. Having automated security resources prevents human error and catches misconfigurations before they are even noticed. InsightCloudSec provides automation tools such as bots that are customizable to fit your needs.

Cloud is the future of technology, and no one wants to be left behind. Invest in cloud security now to ensure that you aren’t featured in our next misconfigurations report. You don’t have to choose between innovation and security anymore.

Security is the next big step in cloud adoption

Learn why in our Trust in the Cloud report

Time to Act: Bridging the Gap in Cloud Automation Adoption

2021-11-11 Erica Azad

Post Syndicated from Erica Azad original https://blog.rapid7.com/2021/11/11/time-to-act-bridging-the-gap-in-cloud-automation-adoption/

Time to Act: Bridging the Gap in Cloud Automation Adoption

Ready or not, the cloud is here. Across the board, an overwhelming majority of organizations recognize the value of the cloud. According to a recent survey conducted by Rapid7, 90% of respondents believe that cloud operations are critical to the competitiveness of their business. Analysts agree — Gartner recently forecasted that by 2026, cloud end-user spending will make up to 45% of overall IT spend.

We’ve established that the industry accepts the shift toward the cloud, so today we’re taking that a step further, specifically looking at attitudes toward automation in cloud security. To set the scene, 86% of respondents to our recent survey say they trust automation in their cloud security at least as much as manual effort by humans. Yet less than half (47%) have actually implemented automation in their cloud security program.

So what gives? Why does this gap exist between trust and actual adoption?

Attitudes toward automation

There’s a variety of factors that impact trust in automation, such as vendor relationships and breach history. For example, when surveying organizations about their trust in automation versus skilled professionals, 18% of those that reported a breach said they don’t trust automation. If you compare this to organizations that did not report a breach, only 14% stated they don’t trust automation. This slight uptick shows that organizations who already suffered a security incident are slightly more gun-shy of implementing automated security solutions as compared to those who didn’t.

Luckily for organizations hesitant to trust automation in the cloud, it is not an all-or-nothing exercise. There are different actions and levels of automation that can be experimented with until greater trust is achieved. For example, organizations can start with a cloud security solution automatically performing only one of monitoring, reporting, or remediation.

However, if you’re looking to benchmark against what other leading companies are doing, 56% of respondents trust automation in their cloud security program to do all three of the above — monitoring, reporting, and remediation.

Looking ahead

This growing level of trust in cloud security automation is reflected in many companies’ future plans as well. Another 25% of organizations are planning on implementing automation into their cloud security program over the next 12 months. Implementation may be lagging behind, but it’s still a goal many organizations are striving for. It’s clear that while trust must continue to be earned, the time is now for automation adoption in order to drive cloud security forward.

If you’re interested in exploring the topic of belief, trust, and reliance on automation, we recommend checking out our new report, Trust in the Cloud. This report covers many data points and survey responses, diving into the gap between automation attitudes and implementation.

A Matter of Perspective: Agent-Based and Agentless Approaches to Cloud Security, Part 2

2021-11-02 Amit Bawer

Post Syndicated from Amit Bawer original https://blog.rapid7.com/2021/11/02/a-matter-of-perspective-agent-based-and-agentless-approaches-to-cloud-security-part-2-2/

A Matter of Perspective: Agent-Based and Agentless Approaches to Cloud Security, Part 2

In our previous blog on this topic, we discussed some of the considerations when choosing between agent-based and agentless cloud security approaches. The following table provides a summary of these considerations.

Aspect	Agent-based	Agentless
Deployment	– Deployed on every asset independently – Can add potential friction; may require some special access permissions per asset – Deployment has to scale up with additional assets – Can be resource-intensive for the monitored asset	– Deployed externally to assets being monitored, usually at the cluster level – Relies on the provider’s inherent access role schemes and APIs – Processing and data collection are independent of assets – Can be resource-consuming at the provider’s billing level
Monitoring	– Tailored for asset specifications (must be aware of and compatible with OS, kernel, and architecture of the layer in which it operates) – Can be used over a variety of different cloud providers – Has access to unexposed asset information, but requires elevated permissions, which may turn into a security consideration of its own – Has a specific view per monitored asset; higher-level correlation has to be done externally – Missing or malfunctioning deployment may result in blind spots – May require different inspection methods for different types of assets	– Agnostic to asset specifications – Relies on cloud provider’s API and its data collection facilities – No access to unexposed provider information – Has a cluster-level view of asset activities, usually from a single collection point; easy to make correlations between different cluster asset activities – Malfunctioning deployment may result in cluster-level blindness – Unified access to all asset information via a common API and data collection facility
Enforcement	– Needs an in-band access to medium for taking an action – May interfere with uncorrelated provider operations	– Integrates to and correlates with provider’s automations and enforcement tools – Cannot go beyond provider’s limitations

Aspect

Agent-based

Agentless

Deployment

– Deployed on every asset independently

– Can add potential friction; may require some special access permissions per asset

– Deployment has to scale up with additional assets

– Can be resource-intensive for the monitored asset

– Deployed externally to assets being monitored, usually at the cluster level

– Relies on the provider’s inherent access role schemes and APIs

– Processing and data collection are independent of assets

– Can be resource-consuming at the provider’s billing level

Monitoring

– Tailored for asset specifications (must be aware of and compatible with OS, kernel, and architecture of the layer in which it operates)

– Can be used over a variety of different cloud providers

– Has access to unexposed asset information, but requires elevated permissions, which may turn into a security consideration of its own

– Has a specific view per monitored asset; higher-level correlation has to be done externally

– Missing or malfunctioning deployment may result in blind spots

– May require different inspection methods for different types of assets

– Agnostic to asset specifications

– Relies on cloud provider’s API and its data collection facilities

– No access to unexposed provider information

– Has a cluster-level view of asset activities, usually from a single collection point; easy to make correlations between different cluster asset activities

– Malfunctioning deployment may result in cluster-level blindness

– Unified access to all asset information via a common API and data collection facility

Enforcement

– Needs an in-band access to medium for taking an action

– May interfere with uncorrelated provider operations

– Integrates to and correlates with provider’s automations and enforcement tools

– Cannot go beyond provider’s limitations

Hybrid approach

Neither the agent-based nor agentless approach is strictly considered better than the other. In some cases, it could be beneficial to join forces and have both flavors of security scooped into the same cone, so each can cover for the shortcomings of its counterpart. For example, agentless solutions are usually shortsighted when it comes to a workload’s confined information, such as the activity of processes executed within the workload space. Therefore, you might choose to augment your agentless solution with an agent-based deployment for this purpose.

As a counter-example, agent-based solutions could be disruptive or resource-consuming for network monitoring tasks. You could instead carry out these tasks over the already existing provider facilities by adding an agentless solution, which could then catch all cluster network activity information within a single collection point.

So, what’s the right answer?

In this post, we have covered some of the key aspects that differentiate agentless and agent-based approaches to cloud security. We can conclude that neither is necessarily preferable over the other, but each can cover the shortcomings of its counterpart, depending on your organization’s needs. Agent-based solutions can potentially provide a more in-depth perspective of a protected asset’s internal activities. Provider-integrated agentless solutions are usually agnostic to the containerized internal activities, but they can excel at a broader scale when making correlations between different sources of information, while still minimizing the friction per asset.

Essentially, there’s no right or wrong answer for cloud security. To keep your assets secure, just pick the approach — or mix of approaches — that makes sense for you and your organization.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Automation Enables Innovation in the Cloud

2021-10-27 Shelby Matthews

Post Syndicated from Shelby Matthews original https://blog.rapid7.com/2021/10/27/automation-enables-innovation-in-the-cloud/

Automation Enables Innovation in the Cloud

As public cloud adoption continues to grow year after year, we see more and more enterprises realizing the strategic advantage the cloud can provide to help deliver new and innovative products quicker, roll out new features with ease, and reach new customers. But along with those advantages comes a new level of complexity and risk that organizations need to account for.

Rapid7’s recently released 2021 Cloud Misconfigurations Report revealed that there were 121 publicly reported data exposure events last year that were the result of cloud misconfigurations.

One critical part of preventing these misconfigurations is the strategic, gradual adoption of automated notification and remediation workflows.

The benefits of automation in cloud security

Automation in the cloud is the implementation of tools that take away the responsibility of security from the user and make it automated. These tools can catch and fix misconfigurations before you even realize they were ever there.

Some of the benefits these tools can bring include:

Data breach protection: Despite increased regulations, data breaches continue to grow. Most of these breaches happen when organizations make inadequate or inappropriate investments in cloud security. Now more than ever, companies are under increasing pressure to make appropriate investments to protect customer data as they scale and expand their cloud footprint.
Threat protection: When using cloud services, it’s common to be overwhelmed with the large volume of threat signals you receive from a wide variety of sources. Without being able to decipher the signals from noise, it’s difficult to identify true risk and act on it in a timely fashion.

To deliver threat protection, InsightCloudSec integrates with native cloud service providers’ security platforms (e.g., Amazon GuardDuty) and other partners (e.g., Tenable) for best-in-class, intelligent threat detection that continuously monitors for malicious activity and unauthorized behavior. These services use machine learning, anomaly detection, and integrated threat intelligence to identify and prioritize potential threats. You’ll be able to detect cryptocurrency mining, credential compromise behavior, communication with known command-and-control servers, and API calls from known malicious IP addresses.

While automating every workflow possible isn’t the answer, one thing is clear: Enterprise-scale cloud environments have outstripped the human capacity to manage them manually.

Not only is automation essential for bringing security — it’s a way to cut down the time it would take to fix resources, as compared to a manual approach. Automation greatly reduces the risk of human error in the cloud and allows workflows to include automated security across the board.

How InsightCloudSec provides it

InsightCloudSec comes with an automated program that we call our bots, which allow you to execute actions on resources based on your conditions. Your bot consists of three things: scope, filters, and actions. A single bot can be configured to apply a unified approach to remediation across all clouds, creating a consistent, scalable, and sustainable approach to cloud security.

Scope: The scope chosen by the user determines which resources and places the bot will evaluate. You choose the bounds that the bot is constricted to. An example of a scope would be all of your AWS, GCP, and Azure accounts, looking for the Storage Container resource (e.g., S3 bucket, Blob storage, and Google Cloud storage).
Filters: InsightCloudSec comes with over 800 filters you can choose from. These filters are the condition on which the bot will act. An example of a filter would be Storage Container Public Access, which will evaluate if any of the resources within your scope have public access due to their permission(s) and/or bucket policy.
Actions: Finally, this is what the bot actually does. InsightCloudSec ships with over 100 different actions that you can customize. For example, if you set up a bot could to identify storage containers that are public, the action would be the bot notifying the team and cleaning up the exposed permissions.

Bots offer a unified approach to remediation across all your cloud environments. With InsightCloudSec, you can customize them just how you want it based on the full context of a misconfiguration. Automation with InsightCloudSec is the key to achieving security at the speed of scale.

What common cloud security mistakes are organizations making?

Find out in our 2021 Cloud Misconfigurations Report

A Matter of Perspective: Agent-Based and Agentless Approaches to Cloud Security, Part 1

2021-10-20 Amit Bawer

Post Syndicated from Amit Bawer original https://blog.rapid7.com/2021/10/20/a-matter-of-perspective-agent-based-and-agentless-approaches-to-cloud-security-part-1/

A Matter of Perspective: Agent-Based and Agentless Approaches to Cloud Security, Part 1

When it comes to securing your cloud assets’ activities at runtime, the first step is deciding how. There are enough possible solutions that you’re likely to find yourself at a crossroads trying to decide between them. The factors that may affect your choice include:

Friction level — How time-consuming or disruptive is it to instrument the solution within the existing environment? What happens to normal operations when the solution malfunctions or becomes misconfigured?
Costs — How much am I going to pay for an effective solution?
Scalability — Would I have to bother with instrumenting this solution over and over again as more assets are being added to my environment (which might have just happened without any intervention)?
Blind spots — What coverage does a single instrumentation provide? Does it cover all an asset’s activities and communications? How is overall visibility impaired when it stops working?
Depth of view — How deep does the inspection go per asset? Is it capable of retrieving all viable information required for detection of vulnerabilities and ongoing malicious activities? Is it sufficient for a reliable detection of behavioral anomalies?
Breadth of view — Do I get the big picture of what is going on? Can suspicious activity be linked to all assets involved? And again, can the solution reliably detect behavioral anomalies?
Forensics — Am I able to keep the data for post-mortem analysis on the crime afterward? Does the solution allow me to make smart conclusions about the next steps for mitigation?

In addition to such questions, there are also practical aspects of your existing cloud platform settings that may affect your selection. For example, working on a serverless setup, in which the hosting instances are completely segregated from your reach, will rule out solutions involving security agents designed to run at underlying host-level scopes.

Agent-based solutions

A solution involving an applied process or a module that resides within the asset’s scope. These kinds of solutions are aware of the hosting platform and are tailored to probe its application, as well as valuable runtime information regarding process activities, incoming or outgoing network traffic of the monitored asset, and possibly other local resources that may play a part in denial-of-service attacks, such as CPU and memory consumption. Along with information access, an agent and its host also share resources. The agent is usually also deployed with privileged access rights (a “let’s run as root” kind of routine) so it can operate at the operating system level and even in the kernel space of its host.

So how does an agent-based solution stack up against the deciding factors we listed earlier?

Friction — Due to the nature of their deployment, agent-based solutions can cause a considerable amount of friction. In the absence of an inherent central management, these solutions are required to expose some APIs, which may be non-trivial to operate in order to control and configure their activation.
Cost — Agent-based deployments are not part of the provider service stack and, as such, are mostly subject to solution vendor licensing fees. These fees can be unrelated to the actual data billing and thus may save on costs in practice.
Scalability — Agent-based solutions are usually bound per specific asset, so they’re required to scale up and down as assets are added or removed. This may incur more resource consumption from the shared resources pool of the assets and agents.
Blind spots — Agents usually operate as a mesh of probes, providing the big picture by correlating their spot coverages, typically within a database and a management application. When a probe goes down, its spot coverage vanishes as well, and the runtime information will be missing for the assets it covers.
Depth of view — Agent-based solutions are tailored tightly to the asset’s platform, which they monitor and secure. As such, they can fish out information an external service would never be able to find from the depths of the operating system, kernel, and other local devices.
Breadth of view — As mentioned, the benefit of providing the overall picture comes from correlating a mesh of agent information within a single point. Agents can’t do this by themselves. It requires the help of external applications and possibly a central database to maintain the findings and make useful links between them.
Forensics — Having a realistic retention policy for findings can play a role in determining how far back to investigate an incident and what conclusions can be drawn about it.

Agentless solutions

Instead of deploying an agent per asset or per subset of assets, agentless solutions are deployed at the cluster or cloud account level. As they live outside of the assets themselves, these kinds of solutions are based on the cloud provider’s native APIs and services. They’re also affected by and confined to the provider’s specified functionality. In this case, the protected assets and the agentless service share no resources, and there’s a strong reliance on the cloud provider role schemes and APIs for accessing valuable information.

Friction — Agentless solutions are provided as part of the official provider services stack. The only effort on the operator’s end is to enable and customize it, and customization can usually be simplified to the default settings for less experienced users. Other aspects of updates and fixes should be seamless as part of the overall provider’s user experience suite.
Costs — The provider’s pricing model may vary, but there’s a trend of billing per data capacity used for tracking, so agentless solutions can become quite an expense for a full-blown active network of assets.
Scalability — Agentless solutions take advantage of centralized services within the provider’s platform. As such, they can scale well, since they aren’t relying on the same resource pool as the assets themselves.
Blind spots — Provider-based solutions aim to deliver the big picture of cloud activity as a whole. In this context, a blind spot would be related to poor depth of view per asset internals, so you might consider blind spots to actually be “blind layers.”
Depth of view — As we’ve discussed, agentless solutions rely mostly on platform data handled by the provider itself, such as the cluster networking and user accounts. This being the case, these solutions are less aware of the containerized internals, such as the processes being executed within the containers.
Breadth of view: Agentless solutions have a cluster-level view of asset activities, usually from a single collection point. This makes it easy to correlate between different cluster assets’ activities.
Forensics: The forensic capabilities of an agentless solution are mostly related to how well the solution is integrated with the data retention facilities of the provider.

So if both approaches have their strengths and weaknesses, which do you choose? Stay tuned for part 2, where we’ll discuss a third option and draw conclusions.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Cloud implementation maturity

Maturity example

NEVER MISS A BLOG

Infrastructure as a service

Platform as a service

Software as a service

As-a-service example

Digging deeper

Externally

Internally

Platform vs. infrastructure

Internal platform pentest

Internal infrastructure pentest

NEVER MISS A BLOG

Get the Full Report

A closer look at the results

Learn more

Join our 2022 Cloud Security Summit

Traditional cloud usage

Cloud-native usage

Hybrid cloud

NEVER MISS A BLOG

Reason 1: Get a sneak peak at some original cloud security research

Reason 2: Learn from industry experts, and get CPE credits

Reason 3: Be the first to hear exciting Rapid7 announcements

Join our 2022 Cloud Security Summit

See you next time!

Other posts in this series

1. Implement continuous monitoring

2. Automate security processes

3. Improve organizational culture by sharing context

4. Gain greater visibility

Next steps: Embracing the complex relationship

What unique challenges or pain points did you/do you encounter as a CISO in finserv?

How has finserv security evolved over the last few years as it relates to the cloud?

How would you describe the general maturity level with cloud security?

What advice would you give to other CISOs in the finserv industry about cloud security?

How can CISOs mitigate these risks with cloud security going forward?

What are your predictions for the future of cloud security?

Configurations

API server

Audit log and other Kubernetes logs

Container runtime

Right tools, lower risks

NEVER MISS A BLOG

Use case 1: Create a new secret and configure it to rotate every four hours using the schedule expression builder

Use case 2: Set up a custom rotation window using a cron expression

Use case 3: Enabling a custom rotation window for an existing secret

Summary

What are the risks of using Kubernetes?

How can you defend yourself?

Processes and system calls

Network security

File system

More to come

NEVER MISS A BLOG

Assessing workload risk in the cloud

How Rapid7 is changing cloud workload protection

3 keys to consolidating cloud risk assessment

1. Shift left

2. Reduce noise

3. Automate workflows

Want to learn more?

Project by Netflix’s Cloud Infrastructure Security team (Alex Bainbridge, Mike Grima, Nick Siow)

Introducing Snare

Overview

Where We Are Today

Extensible Learnings

Information is Key

Step Functions for Remediations

Closing Thoughts

Special Thanks

A holistic approach to Kubernetes security

Built for DevOps, trusted by security

Securing Kubernetes with InsightCloudSec

Ready to drive cloud security forward?

The new AWS Inspector

VPC Network Access Analyzer

S3 Object Ownership

Recycle Bin