Category: InsightCloudSec

Addressing the Evolving Attack Surface Part 1: Modern Challenges

Lately, we’ve been hearing a lot from our customers requesting help on how to manage their evolving attack surface. As new 0days appear, new applications are spun up, and cloud instances change hourly, it can be hard for our customers to get a full view of risk into their environments.

We put together a webinar to chat more about how Rapid7 can help customers meet this challenge with two amazing presenters Cindy Stanton, SVP of Product and Customer Marketing, and Peter Scott, VP of Product Marketing.

At the beginning of this webcast, Cindy highlights where the industry started from traditional vulnerability management (VM) which was heavily focused on infrastructure but has evolved significantly over the last couple of years. Cindy discusses this rapid expansion of the attack surface having been accelerated by remote workforces during the pandemic, convergence of IT and IoT initiatives, modern development of applications leveraging containers and microservices, adoption of the public cloud, and so much more. Today, security teams face the daunting challenge of having so many layers up and down the stack from traditional infrastructure to cloud environments, applications, and beyond.They need a way to understand their full attack surface. Cindy, gives an example of this evolving challenge of increasing resources and complexity of cloud adoption below.

Addressing the Evolving Attack Surface Part 1: Modern Challenges

Cindy then turns things over to Peter Scott to walk us through the many challenges security teams are facing. For example, traditional tools aren’t purpose-built to keep pace with cloud environment, getting complete coverage of assets in your environment requires multiple solutions from different vendors that are all speaking different languages, and no solutions are providing a unified view of an organization’s risk. These challenges on top of growing economic pressures often make security teams choose between continued  investment in traditional infrastructure and applications, or investing more in securing cloud environments. Peter then discusses the challenges security teams face from expanded roles, disjointed security stacks, and increases in the threat landscape. Some of these challenges are highlighted more in the video below.

Addressing the Evolving Attack Surface Part 1: Modern Challenges

After spending some time discussing the challenges organizations and security teams are facing, Cindy and Peter dive deeper into the steps organizations can take to expand their existing VM programs to include cloud environments. We will cover these steps and more in the next blog post of this series. Until then, if you’re curious to learn more about Rapid7’s InsightCloudSec solution feel free to check out the demo here, or watch the replay of this webinar at any time!

Cloud IAM Done Right: How LPA Helps Significantly Reduce Cloud Risk

Today almost all cloud users, roles, and identities are overly permissive. This leads to repeated headlines and forensic reports of attackers leveraging weak identity postures to gain a foothold, and then moving laterally within an organization's modern cloud environment.

This has become a prevalent theme in securing the cloud, where identity and access management (IAM) plays a much larger role in governing access than in traditional infrastructure. However, the cloud was built for innovation and speed, with little consideration as to whether the access that has been granted is appropriate. The end result is an ever-growing interconnected attack surface that desperately needs to be tailored down.

To govern and minimize IAM risk in the cloud, organizations need to adopt the principle of least privilege access (LPA). Rapid7 is pleased to announce the release of LPA Policy Remediation as part of its InsightCloudSec product line. If you're not familiar, InsightCloudSec is a fully-integrated cloud-native security platform (CNSP) that enables organizations to drive cloud security forward through continuous security and compliance. The platform provides real-time visibility into everything running across your cloud environment(s), detecting and prioritizing risk signals (including those associated with IAM policies), privileges, and entitlements, and provides native automation to return resources to a state of good whenever compliance drift is identified.

With the release of LPA Policy Generation, InsightCloudSec enables customers to take action when overly permissive roles or unused access is detected, automatically modifying the existing policy to align actual usage with granted permissions. Any actions that aren't utilized over a 90-day period will be excluded from the new policy.

Permissions can't become a point of friction for developers

In today's world of continuous, fast-paced innovation, being able to move quickly and without friction is a key ingredient to delivering for customers and remaining competitive within our industries. Therefore, developers are often granted “godlike" access to leverage cloud services and build applications, in an effort to eliminate the potential that they will hit a roadblock later on. Peeling that back is a daunting task.

So how do you do that? Adopt the Principle of least privilege access, which recommends that a user should be given only those privileges needed for them to perform their function or task. If a user does not need a specific permission, the user should not have that permission.

Identity LPA requires dynamic assessment

The first step to executing on this initiative of LPA is to provide evidence to your dev teams that there is a problem to be solved. When first collaborating with your development partners, having a clear report of what permissions users have leveraged and what they have not can help move the discussion forward. If “Sam" has not used [insert permission] in the past 90 days, then does Sam really need this permission?

InsightCloudSec tracks permission usage and provides reporting over time of all your clouds, and is a handy tool to commence the discussion, laying the groundwork for continuous evaluation of the delta between used and unused permissions. This is critical, because while unused permissions may seem benign at first glance, they play a significant role in expanding your organization's attack surface.

Effective cloud IAM requires prioritization

The continuous evaluation of cloud user activity compared to the permissions they have been previously granted will give security teams visibility into what permissions are going unused, as well as permissions that have been inappropriately escalated. This then provides a triggering point to investigate and ultimately enforce the principle of least privilege.

InsightCloudSec can proactively alert you to overly permissive access. This way security teams are able to continuously establish controls, and also respond to risk in real time based on suspicious activity or compliance drift.

Like with most security problems, prioritization is a key element to success. InsightCloudSec helps security teams prioritize which users to focus on by identifying which unused permissions pose the greatest risk based on business context. Not all permissions issues are equal from a risk perspective. For example, being able to escalate your privileges, exfiltrate data, or make modifications to security groups are privileged actions, and are often leveraged by threat actors when conducting an attack.

Taking action

Ultimately, you want to modify the policy of the user to match the user's actual needs and access patterns. To ensure the insights derived from dynamically monitoring cloud access patterns and permissions are actionable, InsightCloudSec provides comprehensive reporting capabilities (JSON, report exports, etc.) that help streamline the response process to harden your IAM risk posture.

In an upcoming release, customers will be able to set up automation via “bots" to take immediate action on those insights. This will streamline remediation even further by reducing dependency on manual intervention, and in turn reduces the likelihood of human error.

When done right, LPA significantly reduces cloud risk

When done right, establishing and enforcing least-privilege access enables security teams to identify unused permissions and overly permissive roles and report them to your development teams. This is a key step in providing evidence of the opportunity to reduce an organization's attack surface and risk posture. Minimizing the number of users that have been granted high-risk permissions to the ones that truly need them helps to reduce the blast radius in the event of a breach.

InsightCloudSec's LPA Policy Remediation module is available today and leverages all your other cloud data for context and risk prioritization. If you're interested in learning more about InsightCloudSec, and seeing how the solution can help your team detect and mitigate risk in your cloud environments, be sure to register for our bi-weekly demo series, which goes live every other Wednesday at 1pm EST.

Real-Time Risk Mitigation in Google Cloud Platform

With Google Cloud Next happening this week, there’s been some recent water cooler talk - okay, informal, ad hoc Zoom calls - where discussions about what makes Google Cloud Platform (GCP) unique when it comes to security. A few specific differences have popped up here and there (default data encryption, the way IAM is handled, etc.), but, generally speaking, many of the principles that apply to all other cloud providers apply to GCP environments.

For one, due to the speed and scale of these environments, it’s simultaneously very difficult and extremely critical to maintain an up-to-date inventory of the state of all resources in your environment. This means constantly monitoring your environment for resources being created, deleted, or modified in as close to real time as possible.

And in an effort to avoid ambiguity or hide behind marketing buzz terms, when I’m referring to “real time” here, I’m talking about sub 5-minute intervals based on activity happening in the environment. This is not to be confused with “near real time” approaches some vendors tout, which, in reality, still only pulls in data once or twice a day based on a static schedule.

In GCP, like in AWS, Azure, and all other cloud environments, simply getting a snapshot once a day to identify misconfigurations, vulnerabilities, or suspicious behaviors like you might with an on-prem data center just isn’t a scalable strategy. It’s a common cliche, but the ephemeral nature and rate of change in public cloud environments makes that kind of scanning strategy extremely ineffective when it comes to monitoring, analyzing, and eliminating actual risk in a cloud environment.

Let me lay out a couple examples where this kind of real-time monitoring can provide significant, potentially necessary, value to security teams working to make their cloud risk management programs more effective.

Identification of high-risk resources

As an example, say a developer is in a GCP project associated with your company’s revenue-generating application and they spin up a Cloud Storage instance that is, whether mistakenly or maliciously, open to the public internet.

If your security team is reliant on a scan to happen 12 hours later to get visibility into this activity, your organization will constantly be left open to significant risk. Take away the hyperbole here and assume it’s a much smaller risk or compliance violation. Even in that situation, your team is still working from behind and, presumably, almost always facing some level of stress about what issues are out there in the environment that they won’t know about for another 12-18 hours.

Worst of all, with this type of scanning you’re generally just getting a point-in-time snapshot of the environment and usually don’t know who made the change or how long ago it happened. This makes it much more difficult and time consuming for your team to actually assess the risk or get their hands on the right information to make an informed decision about how the situation should be addressed.

When a team is working with real-time data, however, they can be much more diligent and confident that they’re prioritizing the right issues at any given moment, with all the necessary context about who made the change and when it occurred. This not only helps teams stay ahead of issues and reduce the risk of a breach in their environment, but also helps keep individuals and teams feeling positive about the impact that the program is having on the organization.

Delayed remediation workflows

Building off of the previous example, it’s not only that teams can’t respond to risk they haven’t been notified of, it’s also that any automated response workflows your team may have built out to be more efficient are significantly less effective when they’re triggered by hours-old data. A 12-hour delay in an automation workflow all but eliminates the value of the automation itself, and it can actually cause headaches and confusion that detract from your team’s efficiency, rather than improving it (more on this in the next example).

In contrast, if you’re able to detect risky changes to your environment as they happen, you can automatically respond to that issue as it happens. In the case of this all being a mistake caused by a developer working a little too quickly, you’re able to automatically notify them of their error within a matter of minutes, likely while they’re still working within that project. Giving your development team this kind of feedback in the moment, rather than forcing them to context switch and go back into the project to fix the error a day later, is an excellent way to build stronger relationships and rapport with that team.

In the more rare case that this is indeed a malicious internal or external actor, enabling your automated remediation workflows to kick into gear within seconds and potentially stop the behavior could mean the difference between a minor incident and a breach requiring public disclosure from your organization.

Minimizing false positives and cross-team friction

Speaking of relationships with the development team (sorry, #DevSecOps), I can almost guarantee that working with data from scans or snapshots that occur every 12 or 24 hours in your cloud will cause friction between your two teams. Whether it’s tied to manual identification of risky resources or automated workflows notifying them of a non-compliant asset, working with stale data will inevitably lead to false positives that will both annoy and distract your already overburdened development team.

Take the example highlighted above, but instead, let’s say the developer actually spun up that Cloud Storage instance for a short amount of time in a dev instance with no actual customer data as part of a testing exercise. By the time your team gets visibility into this and either reaches out manually or has some automated notification sent to the developer, that instance could have already been deleted for hours. Now your team is looking at one set of old data and seeing an issue, meanwhile the developer is insisting that the storage container doesn’t even exist anymore. As mentioned above, this is going to cause headaches and frustration for both parties, and cause your team to lose credibility with the dev team.

At this point, you can probably guess where this is going next. With real-time monitoring in your environment this situation can be avoided altogether because your team will be looking at the same up-to-date information, and your team will be able to see that the storage container was shut down or removed from the project rather than spending time chasing down a false positive.

Earlier this month we released event-driven harvesting for GCP in InsightCloudSec. This agentless, real-time monitoring helps your security team achieve every one of the benefits outlined above while also avoiding API rate limiting. In addition, we’ve recently added GCP CIS Benchmarks v1.3.0, added GCP threat findings into our console, and added support for Google Directory to give visibility into IAM factors such as user last login, MFA status, group association and more.


If you want to learn more about how Rapid7 can help you secure Google Cloud Platform, or any other public cloud environment, sign up for our live bi-weekly demo of InsightCloudSec.


Shift Left: Secure Your Innovation Pipeline

There’s no shortage of buzzwords in the tech world. Some are purely marketing spin. But others are colloquial ways for the industry to talk about complex topics that have a massive impact on how organizations and teams drive innovation and work more efficiently. Here at Rapid7, we believe the “shift left” movement very much falls in the latter category.

Because we see shifting left as so critical to an effective cloud security strategy, we’re kicking off a new blog series covering how organizations can seamlessly incorporate security best practices and technologies into their existing DevOps workflows — and, of course, how InsightCloudSec and the brilliant team here at Rapid7 can help.

What does “shift left” actually mean?

For those who might not be familiar with the term, “shift left” can be used interchangeably with DevOps methodologies. The idea is to “shift” tasks that have typically been performed by centralized and dedicated operations teams earlier in the software development life cycle (SDLC). In the case of security, this means weaving security guardrails and checks into development, fixing problems at the source rather than waiting to do so upon deployment or production.

Shift Left: Secure Your Innovation Pipeline

Historically, security was centered around applying checks and scanning for known vulnerabilities after software was built as part of the test and release processes. While this is an important step in the cycle, there are many instances in which this is too late to begin thinking about the integrity of your software and supporting infrastructure — particularly as organizations adopt DevOps practices, resources are increasingly provisioned declaratively, and the development cycle becomes a more iterative, continuous process.

Our philosophy on shift left

One of the most commonly cited concerns we hear from organizations attempting to shift left is the potential to create a bottleneck in development, as developers need to complete additional steps to clear compliance and security hurdles. This is a crucial consideration, given that accelerating software development and increasing efficiency is often the driving force behind adopting DevOps practices in the first place. Security must catch up to the pace of development, not slow it down.

Shift left is very much about decentralizing security to match the speed and scale of the cloud, and when done poorly, it can erode trust and be viewed as a gating factor to releasing high-quality code. This is what drives Rapid7’s fundamental belief that in order to effectively shift security left, you need to avoid adding friction into the process, and instead embrace the developer experience and meet devs where they are today.

How do you accomplish this? Here’s a few core concepts that we here at Rapid7 endorse:

Provide real-time feedback with clear remediation guidance

The main goal of DevOps is to accelerate the pace of software development and improve operating efficiency. In order to accomplish this without compromising quality and security, you must make sure that insights derived from your tooling are actionable and made available to the relevant stakeholders in real time. For instance, if an issue is detected in an IaC template, the developer should be immediately notified and provided with step-by-step guidance on how to fix the issue directly in the template itself.

Establish clear and consistent security and compliance standards

It’s important for an organization to have a clear and consistent definition of what “good” looks like. A well-centered definition of security and compliance controls helps establish a common standard for the entire organization, making measurement of compliance and risk easier to establish and report. Working from a single, centrally managed policy set makes it that much easier to ensure that teams are building compliant workloads from the start, and you can limit the time wasted repeatedly fixing issues after they reach production. A common standard for security that everyone is accountable for also establishes trust with the development community.

Integrate seamlessly with existing tool chains and processes

When adding any tools or additional steps into the development life cycle, it is critically important to integrate them with existing tools and processes to avoid adding friction and creating bottlenecks. This means that your security tools must be compatible with existing CI/CD tools (e.g., GitHub, Jenkins, Puppet, etc.) to make the process of scanning resources and remediating issues seamless, and to enable developers to complete their tasks without ever leaving the tools they are most comfortable working with.

Enable automation by shifting security left

Automation can be a powerful tool for teams managing sprawling and complex cloud environments. Shifting security left with IaC scanning allows you to catch faulty source templates before they’re ever used, allowing teams to leverage automation to deploy their cloud infrastructure resources with the confidence that they will align to organizational security standards.

Shifting cloud security left with IaC scanning

Infrastructure as code (IaC) refers to the ability to provision cloud infrastructure resources declaratively, by writing code in the same development environments used to write the software it is intended to support. IaC is a critical component of shifting left, as it empowers developers to write, test, and release software and infrastructure resources programmatically in a highly integrated process. This is typically done through pre-configured templates based on policies determined by operations teams, making development a shared and reproducible process.

When it comes to IaC security, we’re primarily talking about integrating the process of checking IaC templates to be sure that they won’t result in non-compliant infrastructure. But it shouldn’t stop there. In a perfect world, the IaC scanning tool will identify why a given template will be non-compliant, but it should also tell you how to fix it (bonus points if it can fix the problem for you!).

IaC scanning with InsightCloudSec

By this point, it should be clear that we here at Rapid7 strongly believe in incorporating security and compliance as early as possible in the development process, but we know this can be a daunting task. That’s why we built powerful capabilities into the InsightCloudSec platform to make integrating IaC scanning into your development workflows as easy and seamless as possible.

With IaC scanning in InsightCloudSec, your teams can identify and evaluate risk before infrastructure is ever built, stopping non-compliant or misconfigured resources from ever reaching production, and improving efficiency by fixing problems at the source once and for all, rather than repeatedly addressing them in runtime. With out-of-the-box support for popular IaC tools like Terraform and CloudFormation, InsightCloudSec provides teams with a common understanding of good that is consistent throughout the entire development life cycle.

Shifting security left requires consistency

Consistency is critical when shifting left, because if you’re scanning IaC templates with checks against policies that differ from those being applied in production, there’s a high likelihood that after some — likely short — period of time, those policy sets are going to drift, leading to missed vulnerabilities, misconfigurations, and/or non-compliant workloads. That may not seem like the end of the world, but it creates real problems for communicating issues across teams and increases the risk of inconsistent application of policies. When you lack consistency, it creates confusion among your stakeholders and erodes confidence in the effectiveness of your security program.

To address this, InsightCloudSec applies the same exact set of configuration standards and security policies across your entire CI/CD pipeline and even across your various cloud platforms (if your organization is one of the many that employ a hybrid cloud strategy). That means teams using IaC templates to provision infrastructure resources for their cloud-native applications can be confident they are deploying workloads that are in line with existing compliance and security standards — without having to apply a distinct set of checks, or cross-reference them with those being used in production environments.

Sounds amazing, right?! There’s a whole lot more that InsightCloudSec has to offer cloud security teams that we don’t have time to cover in this post, so follow this link if you’d like to learn more.

Additional reading:

NEVER MISS A BLOG

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


What We’re Looking Forward to at AWS re:Inforce

AWS re:Inforce 2022 starts tomorrow — Tuesday, July 26th — and we couldn't be more excited to gather with the tech, cloud, and security communities in our home city of Boston. Here's a sneak peek of the highlights to come at re:Inforce and what we're looking forward to the most this Tuesday and Wednesday.

Expert insights at the Rapid7 booth

After two and half years of limited in-person gatherings, we have kind of a lot to say. That's why we're making the Rapid7 booth at AWS re:Inforce a hub for learning and sharing from our cybersecurity experts. Stop by and learn how our team members are tackling a range of topics in cloud and security overall, including:

  • Adapting Your VM Program for Cloud-Native Environments — Jimmy Green, VP of Software Engineering for Cloud, will walk through some of the key considerations when building a fully cloud-first approach to vulnerability management.
  • Speeding Up Your Adoption of CSP Innovation — Chris DeRamus, VP of Technology - Cloud, will detail how Rapid7 evaluates cloud service providers (CSPs) for risk in order to promote faster, more secure adoption.
  • Context Is King: The Future of Cloud Security Operations — Peter Scott, VP of Strategic Engagement for Cloud Security, will discuss why obtaining context around security data is key to managing complexity in cloud environments.
  • Hybrid Is Here: Is Your SOC Ready? — Megan Connolly, Senior Security Solutions Engineer, will highlight the role that extended detection and response (XDR) technology can play in helping SOCs move toward a cloud-first model.
  • InsightCloudSec Demo — Joe Brumbley, Cloud Security Solutions Engineer, and Sean Healy, Senior Domain Engineer - Enterprise Cloud Security, will show InsightCloudSec in action, taking you through the different use cases and features that enable integrated security for multi-cloud environments.

Sharing how we walk the walk

At Rapid7, we're laser-focused on helping companies accelerate in the cloud without compromising security. Our technology and expertise help security teams bring that vision to life — and they form the foundation for how we secure our own cloud infrastructure, too.

In the AWS re:Inforce featured session, "Walking the Walk: AWS Security at Rapid7," Ulrich Dangle (Director, Software Engineering - Platform) and Lauren Clausen Fenton (Manager, Software Engineering - Platform) will share their firsthand experiences developing, scaling, and operationalizing a cloud security program at Rapid7. They'll talk about how they manage to reduce risk while supporting Rapid7's business goals, as well as the needs of our fast-moving DevOps team.

Join us on Tuesday, July 26th, at 11:40 AM, or Wednesday, July 27th, at 10:05 AM to learn how our security team is working around-the-clock to keep our large cloud environment secure and compliant, with standardized configurations and a tried-and-true threat response playbook.

Conversations over cloudy beers

It's no secret that great craft beer is an integral part of tech culture — so where better to talk about all things cloud than a Boston brewery known for the cloudy appearance of its hazy New England IPAs?

On Tuesday, July 26th, from 5:15 PM to 8 PM, we'll be at Rapid7 Reception at Trillium Fort Point, right in the heart of the Seaport District. It's a perfect chance to network with your fellow protectors and meet some of our Rapid7 security experts over a double dry-hopped pale ale or a nitro milk stout. (If beer's not your thing, not to worry — we'll have wine and seltzer, too.)

If that wasn't enough...

Last but not least, we're giving away a vacation of your choice valued at $5,000! The more you engage with us at re:Inforce, the more chances you have to win. You'll be entered in the drawing when you stop by to see us at Booth 206 to receive a demo or watch a presentation, or when you attend the Rapid7 Reception at Trillium Fort Point.

Check out what we have planned and register with us today!

Cloud Threat Detection: To Agent or Not to Agent?

The shift towards cloud and cloud-native application architectures represents an evolutionary step forward from older paradigms. The adoption of containers, Kubernetes, and serverless functions, along with the use of cloud-based infrastructure, introduces a new set of risks and security challenges — as well as new opportunities. These go well beyond application security and security posture management, spanning from the build phase all the way to the application run phase.

Three areas for cloud-native security

One particular area of focus for security defenses is actively security monitoring cloud-based applications and cloud workloads, often referred to as runtime security.

We can break down cloud-based runtime security into three main categories:

1. Cloud environment security

The cloud environment is where we provision the infrastructure and services to run our applications. Running applications often involves provisioning computing resources, networking, storage resources, and access credentials to external elements such as data, external services, or secrets. This is the foundation that our cloud applications are built on, and is a critical first step in ensuring their integrity.

2. Workload and workload orchestration security

Operating modern cloud-native applications often means leveraging a container orchestration platform. In recent years, Kubernetes has been the go-to application server vehicle. Leveraging application server infrastructure like Kubernetes requires attention from a risk and threat perspective. For example, Kubernetes credentials theft, or credential compromise as a result of application breach, can be detected through continuously analyzing the Kubernetes audit log. Another example would be the detection of malware that exploit inherent weaknesses in DNS protocol through network security analysis of the workload (Pod) communications.

3. Application security

If the cloud environment is our workload vehicle where we operate and run our workloads, and containerized workloads are our application vehicle, then OS processes are where our application logic runs. Cloud functions are another example of normally short-lived processes that carry our application logic. Protecting applications is a long-standing challenge on its own. This includes application API security, memory protection, data protection, network isolation, and control, and can be achieved using multiple techniques — some of which are only practically possible through the use of security agents.

Security agents defined

Security agents represent a specialized software deployed on an application workload or application endpoint to perform specific security functions, such as network monitoring, process-level monitoring, memory monitoring, file system monitoring, system API call monitoring, and memory monitoring. They may be involved in preventive actions, detection actions, or security forensics data collection actions.

For example, we can deploy security agents to virtual machines (cloud instances) and provide host-level security. We can use security agents for containerized environments like Kubernetes, where one security agent monitors and secures Kubernetes Pods, as well as the Kubernetes node itself. We can also have embedded security agents that monitor and secure serverless functions such as Lambda, or even security agents that provide process-level security and API-level security.

Agentless security is an approach that leverages security signals obtained via cloud APIs, such as network flows, DNS flows, cloud API access audit logs, or application API access logs. Collecting data from those security signals incurs a lower operational cost than agent-based security, but it can come with some limitations. For instance, in application security, the agentless approach has fewer security signals to analyze, and may not support some threat detection techniques such as process system call analysis.

Should I use agents to secure my cloud applications?

So should you be using agents, or not? The answer really boils down to how wide and deep a detection and protection fabric you want to cast, and how many skilled personnel are available to deploy and operate various security controls and respond to security incidents.

Agents provide a greater level of detail, and are generally your best bet when it comes to preemptive prevention of fine-grained policy-based controls such as network segmentation. However, they also require additional effort and overhead to manage the agents themselves with regular updates and configurations.

The agentless approach is excellent at correlating, segmenting, and analyzing data from various workloads, as it does not rely on sharing resources with the monitored workloads. That said, you’re going to sacrifice depth of coverage at certain layers of the stack as a trade-off to relatively lower operational overhead, because agentless approaches rely on cloud provider APIs, which are less granular than what host/workload or process-level agents can collect.

So to achieve comprehensive security and balance operational overhead, the recommendation is typically to leverage both technologies.

You’ll likely want to use an agentless approach to get fast and wide coverage of both risks and threats, or in places where agents can not be deployed, such as a hosted container environment like AWS Fargate or Cloud Functions. Another example would be to assess software vulnerability and detect persistent malware — which can be achieved using both technologies, but with different levels of time until detection.

Conversely, agents can be used in environments like Kubernetes where the operational overhead is relatively low, and the containerized workload granularity requires fine-grained and deeper security controls.

The decision of where to use an agent-based approach depends on what you’re trying to secure. If you’re looking to get real-time visibility into all of your cloud resources and workloads, establish a single source of “good” across your multiple cloud platforms, prioritize risk across your environments, and measure compliance against organizational and industry standards and best practices, an agentless approach like InsightCloudSec is a great choice.

Cloud Complexity Requires a Unified Approach to Assessing Risk

There has been an unprecedented acceleration in the shift to the cloud as a result of the COVID-19 pandemic. McKinsey experts estimate companies have moved to the cloud “24 times faster [...] than they thought” over the past two years. As organizations move quickly to scale, drive innovation, and revamp the way they engage with their consumers by moving to the public cloud, there is an increasing need for a security strategy that aligns with the varied states of organizations' maturity in their usage and adoption of the cloud.

Modern cloud environments are complex and require multiple areas of focus, including security, application modernization, reduction of infrastructure overhead, accelerating software delivery, maintaining compliance, and countless more. All of these are critical to realizing the end goals of cloud adoption: increased speed, flexibility, and performance. Rapid cloud adoption without the appropriate visibility and automated security controls will lead to imminent exposure and vulnerability.

Whose responsibility is cloud security?

When it comes to cloud environments, security and compliance are a shared responsibility between the cloud service provider (CSP) and the customer’s internal security team. In the typical shared responsibility model, cloud providers are responsible for the security OF the cloud. This essentially means they are on the hook to make sure the actual underlying resources you’re using – such as a storage bucket or a compute instance – or the physical hardware sitting in their data centers aren’t a security threat.

So, if the provider is responsible for security of the cloud itself, what falls to the customer? Customers are responsible for security IN the cloud, meaning they are responsible for making sure their own data – and their customers’ data – is properly secured. Generally speaking, this means keeping track of how various resources and services are configured properly; identifying and remediating exploitable vulnerabilities; managing identity and access management (IAM) policies to maintain least privilege access; and utilizing encryption for data, whether it’s at rest, in transit, or even in use.

Cloud Complexity Requires a Unified Approach to Assessing Risk

So why is it that such a large majority of breaches are the fault of the customer if the responsibility is shared? There are a few drivers behind this, but it’s primarily because the goal of most bad actors is to gain access to sensitive and potentially lucrative customer data, which falls outside of the responsibility of the cloud provider.

I know what you’re thinking: “The answer is simple – just don’t leave a cloud resource housing sensitive data exposed to the public internet.” That’s, of course, the intent of any well-meaning engineer. That said, mistakes are unfortunately quite common. As engineers and developers work at light speed to bring new products to market, it can be very easy for security and compliance to fall through the cracks, especially as powerful new cloud capabilities enable infrastructure to be implemented with the click of a mouse.

This is consistent with our own research in our 2022 Cloud Misconfigurations Report, in which we found the most commonly breached resources were those that were secure and private by default, such as a storage bucket. This suggests human error played a pivotal role in leaving data exposed.

Prioritizing risk requires a unified approach to cloud security

The scale and complexity of modern cloud environments make it impossible to respond to every alert and potential issue that arises. So, what can you and your team do to make sure you’re not vulnerable to attack?

The key is context.

It is imperative for organizations to think of cloud security holistically so that they can understand their true risk exposure. Organizations need to be able to easily prioritize the issues that are the most critical to fix right away from the flood of alerts and incidents that are calling for their teams’ attention.

The question that needs answering seems simple, yet can be quite complex: “What are the biggest threats to my cloud environment today, and how do I mitigate them?” As mentioned earlier, it is not sufficient anymore to look at an issue through a single lens. Without a unified approach to cloud security, you could be leaving your organization and the systems it relies on in jeopardy.

This means examining not just the risks associated with a workload itself, but a holistic mapping of all resource interdependencies across your environment to understand how one compromised resource may impact others. It means taking into consideration whether or not a given resource is connected to the public internet, or whether there is potential for improper access to potentially sensitive information. There is also business context that needs to be taken into account, where an understanding of resource ownership and accountability can highlight relevant stakeholders that need to be looped in for remediation or audits and provide color as to potential business impact.

See? Simple – yet complex.

Extend this concept across millions of resources spanning hundreds of cloud environments, architectures, and technologies, and you have the complexity of cloud security today. It is therefore a non-negotiable starting point to have a consolidated, weighted, and standardized view of risk to one’s cloud estate. This can only be accomplished by gathering and analyzing all of the relevant data in a single solution that helps you see the full context – and passing that context along to other teams like DevOps – so that organizations can start being more strategic about prioritizing and remediating risks in their environment.

While there are many cloud security tools and vendors that focus on various aspects of cloud security, such as misconfigurations, vulnerabilities, access permissions, and exposure to the internet, very few offer a holistic understanding of all of the above combined to provide a “true” understanding of risk.

A holistic approach to cloud security with InsightCloudSec

Maintaining visibility can only get you so far from a security perspective. Given the sheer volume of monitored resources, chances are without an effective strategy to prioritize the flood of alerts cloud environments produce, your teams won’t know where to start.

The cloud is here to stay, and it is ever-changing. As cloud security and technologies evolve, so do attempts by bad actors to breach it. It is crucial for organizations to invest in best practices and automated cloud security throughout the development lifecycle. Cloud architectures and initiatives must be built on solid risk detection, prioritization and management processes, and platforms that provide seamless and real-time visibility into the true risk posture of the organization.

Increasingly, organizations want to focus their efforts on activities that increase their bottom line and competitive advantage. They simply don’t have the time to sift through multiple lines of code, teams, and repositories to understand the breadth and depth of risks associated with their cloud estate. Cloud security has to be looked at holistically to understand its true impact and threat to the organization.

That’s the difference with InsightCloudSec. We go beyond providing visibility to help organizations uncover the most critical threats facing their cloud ecosystem and provide guidance toward prioritization and response based on the true, holistic risk across multiple security domains. With a higher signal-to-noise ratio, development teams will be able to detect, understand, prevent, prioritize, and respond to threats better and faster, enabling them to build safely and efficiently in a multi-cloud environment.

Interested in learning more? Don’t hesitate to request a free demo!

Additional reading:

NEVER MISS A BLOG

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


Identifying Cloud Waste to Contain Unnecessary Costs

Cloud adoption has exploded over the past decade or so, and for good reason. Many digital transformation advancements – and even the complete reimagination of entire industries – can be directly mapped and attributed to cloud innovation. While this rapid pace of innovation has had a profound impact on businesses and how we connect with our customers and end users, the journey to the cloud isn’t all sunshine and rainbows.

Along with increased efficiency, accelerated innovation, and added flexibility comes an exponential increase in complexity, which can make managing and securing cloud-based applications and workloads a daunting challenge. This added complexity can make it difficult to maintain visibility into what’s running across your cloud(s).

Beyond management challenges, organizations often run into massive increases in IT costs as they scale. Whether from neglecting to shut down old resources when they are no longer needed or over-provisioning them from the beginning to avoid auto-scaling issues, cloud waste and overspend are among the most prevailing challenges that organizations face when adopting and accelerating cloud consumption.

Just how prevalent is this issue? Well, according to Flexera’s 2022 State of Cloud Report, nearly 60% of cloud decision-makers say optimizing their cloud usage to cut costs is a top priority for this year.

The cost benefits of reducing waste can be massive, but knowing where to look and what the most common culprits of waste can be a challenge, particularly if your organization are relative novices when it comes to cloud.

Common cases of cloud waste and how to avoid them

Now that we’ve covered the factors that drive exploding cloud budgets, let’s take a look at some of the most common cases of cloud waste we see, and the types of checks you and your teams should make to avoid unnecessary spending. I’ve categorized these issues as major, moderate, and minor, based on the relative cost savings possible when customers we’ve worked with eliminate them.

Important to note: While this is what we’ve seen in our experience, it’s important to keep in mind that the actual real-world impact will vary based on each organization’s specific situation.

Unattached volumes (major)

Multiple creation and termination of instances often results in certain volumes remaining attached to already terminated instances. These unused and overlooked volumes contribute directly to increased costs, while delivering little or no value.

Cloud teams should identify volumes that are not shown as attached to any instances. Once detected, schedule unattached storage volumes for deletion if they are no longer in use. Alternatively, you could minimize overhead by transitioning these volumes to serve as offline backups.

Load balancer with no instances (major)

Load balancers distribute traffic across instances to handle the load of your application. If a load balancer is not attached to any instances, it will consume costs without providing any functionality. An orphaned load balancer could also be an indication that an instance was deleted or otherwise impaired.

You should identify unattached load balancers, and double-check to make sure there isn’t a larger problem related to an improperly deleted instance that was once associated with those load balancers. After you’ve determined there isn’t a bigger issue to dig into, notify the necessary resource owners that they should delete them.

Database instance with zero connections (moderate)

Databases that have not been connected to within a given time frame are likely to be billable for all classes of service, except for free tiers.

After some agreed-upon time frame (we typically see teams use about 14 days), you should consider these databases stale and remove them. It’s important here to be sure there isn’t a good reason for the perceived inactivity before you go ahead and hit that delete button.

Snapshot older than 60 days (moderate)

Snapshots represent a complete backup of your computing instances at a specific point in time. Maintaining snapshot backups incurs cost and provides diminishing returns over time, as snapshots become old and diverge more and more from the instances they originally represented.  

Unless regulatory compliance or aggressive backup schedules mandate otherwise, old snapshots should be purged. Before scheduling a deletion or taking any other actions, create a ServiceNow Incident for reporting purposes and to ensure snapshot policy socialization.

Instance with high core counts (minor)

Instances that have more cores will tend to perform tasks more quickly and be able to handle larger loads. However, with greater power comes greater costs. For many workloads, eight cores should be more than sufficient.

Users should identify these instances, mark them non-compliant, and notify the resource owner or operations team about potentially downsizing, stopping, or deleting instances with more than eight cores.

How InsightCloudSec can help contain cloud costs

By this point, you might be wondering why we here at Rapid7 would be writing about cloud cost management. I mean, we’re a security company, right? While that’s true, and our dedication to powering protectors hasn’t waned one bit, the benefits of InsightCloudSec (ICS) don’t stop there.

ICS provides real-time visibility into your entire cloud asset inventory across all of your cloud platforms, which gives us the ability to provide relevant insights and automation that help improve cost effectiveness. In fact, we’ve got built-in checks for each of the issues outlined above (and many more) available right out of the box, as well as recommended remediation steps and tips for automating the entire process with native bots. So while you might initially look into our platform for the ability to simplify cloud security and compliance, you can also use it to get a handle on that runaway cloud spend.

Our customers have realized massive savings on their cloud bills over the years, covering portions –  or in some cases, the entirety – of the cost of their InsightCloudSec licenses. (Gotta love a security platform that can pay for itself!) If you’re interested in learning more about how you accelerate in the cloud without sacrificing security and save some money at the same time, don’t hesitate to request a free demo!

Additional reading:

NEVER MISS A BLOG

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


Update for CIS Google Cloud Platform Foundation Benchmarks - Version 1.3.0

The Center for Internet Security (CIS) recently released an updated version of their Google Cloud Platform Foundation Benchmarks - Version 1.3.0. Expanding on previous iterations, the update adds 21 new benchmarks covering best practices for securing Google Cloud environments.

The updates were broad in scope, with recommendations covering configurations and policies ranging from resource segregation to Compute and Storage. In this post, we’ll briefly cover what CIS Benchmarks are, dig into a few key highlights from the newly released version, and highlight how Rapid7 InsightCloudSec can help your teams implement and maintain compliance with new guidance as it becomes available.

What are CIS Benchmarks?

In the rare case that you’ve never come across them, the CIS Benchmarks are a set of recommendations and best practices determined by contributors across the cybersecurity community intended to provide organizations and security practitioners with a baseline of configurations and policies to better protect their applications, infrastructure, and data.

While not a regulatory requirement, the CIS Benchmarks provide a foundation for establishing a strong security posture, and as a result, many organizations use them to guide the creation of their own internal policies. As new benchmarks are created and updates are announced, many throughout the industry sift through the recommendations to determine whether or not they should be implementing the guidelines in their own environments.

CIS Benchmarks can be even more beneficial to practitioners taking on emerging technology areas where they may not have the background knowledge or experience to confidently implement security programs and policies. In the case of the GCP Foundation Benchmarks, they can prove to be a vital asset for folks looking to get started in cloud security or that are taking on the added responsibility of their organizations' cloud environments.

Key highlights from CIS GCP Foundational Benchmarks 1.3.0

Relative to benchmarks created for more traditional security fields such as endpoint OS, Linux, and others, those developed for cloud service providers (CSPs) are relatively new. As a result, when updates are released they tend to be fairly substantial as it relates to the volume of new recommendations. Let’s dig in a bit further into some of the key highlights from version 1.3.0 and why they’re important to consider for your own environment.

2.13 - Ensure Cloud Asset Inventory is enabled

Enabling Cloud Asset Inventory is critical to maintaining visibility into your entire environment, providing a real-time and retroactive (5 weeks of history retained) view of all assets across your cloud estate. This is critical because in order to effectively secure your cloud assets and data, you first need to gain insight into everything that’s running within your environment. Beyond providing an inventory snapshot, Cloud Asset Inventory also surfaces metadata related to those assets, providing added context when assessing the sensitivity and/or integrity of your cloud resources.

4.11 - Ensure that compute instances have Confidential Computing enabled

This is a really powerful new configuration that enables organizations to secure their mission critical data throughout its lifecycle, including while actively in use. Typically, encryption is only available while data is either at rest or in transit. Making use of Google’s new Secure Encrypted Virtualization (SEV) feature, Confidential Computing allows customers to encrypt their data while it is being indexed or queried.

A dozen new recommendations for securing GCP databases

The new benchmarks added 12 new recommendations targeted at securing GCP databases, each of which are geared toward addressing issues related to data loss or leakage. This aligns with Verizon’s most recent Data Breach Investigations Report, which found that data stores remained the most commonly exploited cloud service, with more than 40% of breaches resulting from misconfiguration of cloud data stores such as AWS S3 buckets, Azure Blob Storage, and Google Cloud Storage buckets.

How InsightCloudSec can help your team align to new CIS Benchmarks

In response to the recent update, Rapid7 has released a new compliance pack - GCP 1.3.0 - for InsightCloudSec to ensure that security teams can easily check their environment for adherence with the new benchmarks. The new pack contains 57 Insights to help organizations reconcile their own existing GCP configurations against the new recommendations and best practices. Should your team need to make any adjustments based on the benchmarks, InsightCloudSec users can leverage bots to notify the necessary team(s) or automatically enact them.

In subsequent releases, we will continue to update the pack as more filters and Insights are available. If you have specific questions on this capability or a supported GCP resource, reach out to us through the Customer Portal.

Additional reading:

NEVER MISS A BLOG

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


Cloud-Native Application Protection (CNAPP): What's Behind the Hype?

There's no shortage of acronyms when it comes to security product categories. DAST, EDR, CWPP — it sometimes feels like we're awash in a sea of letters, and that can be a little dizzying. Every once in a while, though, a new term pops up that cuts through the noise, thanks to a combination of catchiness and excitement about that product category's potential to solve the big problems security teams face. (Think of XDR, for a recent example.)

Cloud-native application protection platform, or CNAPP, is one of those standout terms that has the potential to solve significant problems in cloud security by consolidating a list of other “C” letter acronyms. Gartner introduced CNAPP as one of its cloud security categories in 2021, and the term quickly began to make headlines. But what's the reality behind the hype? Is CNAPP an all-in-one answer to building secure apps in a cloud-first ecosystem, or is it part of a larger story? Let's take a closer look.

New needs of cloud-native teams

CNAPP is a cloud security archetype that takes an integrated, lifecycle approach, protecting both hosts and workloads for truly cloud-native application development environments. These environments have their own unique demands and challenges, so it should come as little surprise that new product categories have arisen to address those concerns.

Cloud infrastructures are inherently complex — that makes it tougher to monitor these environments, potentially opening the door to security gaps. If you're building applications within a cloud platform, the challenge multiplies: You need next-level visibility to ensure your environment and the applications you're building in it are secure from the ground up.

A few trends have emerged within teams building cloud-native applications to address their unique needs.

DevSecOps: A natural extension of the DevOps model, DevSecOps brings security into the fold with development and operations as an integral part of the same shared lifecycle. It makes security everyone's business, not just the siloed responsibility of a team of infosec specialists.

Shift left: Tied into the DevSecOps model is the imperative to shift security left — i.e. earlier in the development cycle — making it a fundamental aspect of building applications rather than an afterthought. The "bake it in, don't bolt it on" adage has become almost cliché in security circles, but shifting left is in some ways a more mature — and arguably more radical — version of this concept. It changes security from something you do to an application to part of what the application is. Security becomes part of the fundamental conception and design of a web app.

All of that said, the real challenge here comes down to security teams trying to monitor and manage large-scale, complex cloud environments – not to mention trying to generate buy-in from other teams and get them to collaborate on security protocols that may occasionally slow them down.

How CNAPP hopes to help

To bring DevSecOps and shift-left practices to life, teams need tools that support the necessary levels of visibility and flexibility that underlie these goals. That brings us to where CNAPP fits into this picture.

"Optimal security of cloud-native applications requires an integrated approach that starts in development and extends to runtime protection," Gartner writes in their report introducing CNAPP, according to Forbes. "The unique characteristics of cloud-native applications makes them impossible to secure without a complex set of overlapping tools spanning development and production."

Forbes goes on to outline the 5 core components that Gartner uses in its definition of CNAPP:

• Infrastructure as code (IaC) scanning: Because infrastructure is managed and provisioned as code in many cloud environments, this code must be continuously scanned for vulnerabilities.

• Container scanning: The cloud has made containers an integral part of application development and deployment — these must also be scanned for security threats.

• Cloud workload protection (CWPP): This type of security solution focuses on protecting workloads in cloud data center architectures.

• Cloud infrastructure entitlement management (CIEM): This cloud security category streamlines identity and access management (IAM) by providing least-privileged access and governance controls for distributed cloud environments.

• Cloud security posture management (CSPM): CSPM capabilities continuously manage cloud security risk, with automated detection, logging, and reporting to aid governance and compliance.

A holistic approach to cloud-native security

You might have noticed some of the components of CNAPP are themselves cloud security categories as defined by Gartner. How are they different from CNAPP? Do you need all of them individually, or are they available in a single package? What gives?

While CNAPP is meant to be a product category, right now the broad set of capabilities in Gartner’s definition describes an ideal future state that remains rare in the industry as a single solution. The fact remains there aren’t many vendors out there that have all these components, even across multiple product sets – let alone the ability to fit them into a single solution.

That said, vendors and practitioners can start working together now to bring that vision to life. While there are and will continue to be products that label or identify themselves as a CNAPP, what's really needed is a comprehensive approach to cloud security – both from the technology provided by vendors and the strategy executed by practitioners – that simplifies the process of monitoring and remediating risks from end to end within vast, complex cloud environments.

The cloud is now dominant, and infrastructure is increasingly becoming code — that means scanning for vulnerabilities within infrastructure and in applications have begun to look more alike than ever. Just like DevSecOps brings development, security, and operations together into (ideally) a harmonious unit, application security testing and cloud security monitoring are coequal, integral parts of a truly cloud-native security platform.

The real excitement around CNAPP is that by bringing once-disparate cloud security concepts together, it shines a light on what today's organizations really need: a full-access path to a secure cloud ecosystem, with all the necessary speed of innovation and deployment and as little risk as possible.

Additional reading:

NEVER MISS A BLOG

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