Tag Archives: InsightCloudSec

Cloud Threat Detection: To Agent or Not to Agent?

Post Syndicated from Gadi Naor original https://blog.rapid7.com/2022/07/22/cloud-threat-detection-to-agent-or-not-to-agent/

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

Post Syndicated from Shalini Subbiah original https://blog.rapid7.com/2022/07/05/cloud-complexity-requires-a-unified-approach-to-assessing-risk/

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

Post Syndicated from Ryan Blanchard original https://blog.rapid7.com/2022/06/07/identifying-cloud-waste-to-contain-unnecessary-costs/

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

Post Syndicated from Ryan Blanchard original https://blog.rapid7.com/2022/05/13/update-for-cis-google-cloud-platform-foundation-benchmarks-version-1-3-0/

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?

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2022/05/02/cloud-native-application-protection-cnapp-whats-behind-the-hype/

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.

InsightCloudSec Supports the Recently Updated NSA/CISA Kubernetes Hardening Guide

Post Syndicated from Alon Berger original https://blog.rapid7.com/2022/04/14/insightcloudsec-supports-the-recently-updated-nsa-cisa-kubernetes-hardening-guide/

InsightCloudSec Supports the Recently Updated NSA/CISA Kubernetes Hardening Guide

The National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) recently updated their Kubernetes Hardening Guide, which was originally published in August 2021.

With the help and feedback received from numerous partners in the cybersecurity community, this guide outlines a strong line of action towards minimizing the chances of potential threats and vulnerabilities within Kubernetes deployments, while adhering to strict compliance requirements and recommendations.

The purpose of the Kubernetes hardening guide

This newly updated guide comes to the aid of multiple teams — including security, DevOps, system administrators, and developers — by focusing on the security challenges associated with setting up, monitoring, and maintaining a Kubernetes cluster. It brings together strategies to help organizations avoid misconfigurations and implement recommended hardening measures by highlighting three main sources of compromise:

  • Supply chain risks: These often occur during the container build cycle or infrastructure acquisition and are more challenging to mitigate.
  • Malicious threat actors: Attackers can exploit vulnerabilities and misconfigurations in components of the Kubernetes architecture, such as the control plane, worker nodes, or containerized applications.
  • Insider threats: These can be administrators, users, or cloud service providers, any of whom may have special access to the organization’s Kubernetes infrastructure.

“This guide focuses on security challenges and suggests hardening strategies for administrators of National Security Systems and critical infrastructure. Although this guide is tailored to National Security Systems and critical infrastructure organizations, NSA and CISA also encourage administrators of federal and state, local, tribal, and territorial (SLTT) government networks to implement the recommendations in this guide,” the authors state.

CIS Benchmarks vs. the Kubernetes Hardening Guide

For many practitioners, the Center for Internet Security (CIS) is the gold standard for security benchmarks; however, their benchmarks are not the only guidance available.

While the CIS is compliance gold, the CIS Benchmarks are very prescriptive and usually offer minimal explanations. In creating their own Kubernetes hardening guidelines, it appears that the NSA and CISA felt there was a need for a higher-level security resource that explained more of the challenges and rationale behind Kubernetes security. In this respect, the two work as perfect complements — you get strategies and rationale with the Kubernetes Hardening Guide and the extremely detailed prescriptive checks and controls enumerated by CIS.

In other words, CIS Benchmarks offer the exact checks you should use, along with recommended settings. The NSA and CISA guide supplements these by explaining challenges and recommendations, why they matter, and detailing how potential attackers look at the attack. In version 1.1, the updates include the latest hardening recommendations necessary to protect and defend against today’s threat actors.

Breaking down the updated guidance

As mentioned, the guide breaks down the Kubernetes threat model into three main sources: supply chain, malicious threat actors, and insider threats. This model reviews threats within the Kubernetes cluster and beyond its boundaries by including underlying infrastructure and surrounding workloads that Kubernetes does not manage.

Via a new compliance pack, InsightCloudSec supports and covers the main sources of compromise for a Kubernetes cluster, as mentioned in the guide. Below are the high-level points of concern, and additional examples of checks and insights, as provided by the InsightCloud Platform:

  • Supply chain: This is where attack vectors are more diverse and hard to tackle. An attacker might manipulate certain elements, services, and other product components. It is crucial to continuously monitor the entire container life cycle, from build to runtime. InsightCloudSec provides security checks to cover the supply chain level, including:

    • Checking that containers are retrieved from known and trusted registries/repositories
    • Checking for container runtime vulnerabilities

  • Kubernetes Pod security: Kubernetes Pods are often used as the attacker’s initial execution point. It is essential to have a strict security policy, in order to prevent or limit the impact of a successful compromise. Examples of relevant checks available in InsightCloudSec include:

    • Non-root containers and “rootless” container engines
      • Reject containers that execute as the root user or allow elevation to root.
      • Check K8s container configuration to use SecurityContext:runAsUser specifying a non-zero user or runAsUser.
      • Deny container features frequently exploited to break out, such as hostPID, hostIPC, hostNetwork, allowedHostPath.
    • Immutable container file systems
      • Where possible, run containers with immutable file systems.
      • Kubernetes administrators can mount secondary read/write file systems for specific directories where applications require write access.
    • Pod security enforcement
      • Harden applications against exploitation using security services such as SELinux®, AppArmor®, and secure computing mode (seccomp).
    • Protecting Pod service account tokens
      • Disable the secret token from being mounted by using the automountServiceAccountToken: false directive in the Pod’s YAML specification.

  • Network separation and hardening: Monitoring the Kubernetes cluster’s networking is key. It holds the communication among containers, Pods, services, and other external components. These resources are not isolated by default and therefore could lead to lateral movement or privilege escalations if not separated and encrypted properly. InsightCloudSec provides checks to validate that the relevant security policies are in place:

    • Namespaces
      • Set up network policies to isolate resources. Pods and services in different namespaces can still communicate with each other unless additional separation is enforced.
    • Network policies
      • Set up network policies to isolate resources. Pods and services in different namespaces can still communicate with each other unless additional separation is enforced.
    • Resource policies
      • Use resource requirements and limits.
    • Control plane hardening
      • Set up TLS encryption.
      • Configure control plane components to use authenticated, encrypted communications using Transport Layer Security (TLS) certificates.
      • Encrypt etcd at rest, and use a separate TLS certificate for communication.
      • Secure the etcd datastore with authentication and role-based access control (RBAC) policies. Set up TLS certificates to enforce Hypertext Transfer Protocol Secure (HTTPS) communication between the etcd server and API servers. Using a separate certificate authority (CA) for etcd may also be beneficial, as it trusts all certificates issued by the root CA by default.
    • Kubernetes Secrets
      • Place all credentials and sensitive information encrypted in Kubernetes Secrets rather than in configuration files

  • Authentication and authorization: Probably the primary mechanisms to leverage toward restricting access to cluster resources are authentication and authorization. There are several configurations that are supported but not enabled by default, such as RBAC controls. InsightCloudSec provides security checks that cover the activity of both users and service accounts, enabling faster detection of any unauthorized behavior:

    • Prohibit the addition of the service token by setting automaticServiceAccountToken or automaticServiceAccounttoken to false.
    • Anonymous requests should be disabled by passing the --anonymous-auth=false option to the API server.
    • Start the API server with the --authorizationmode=RBAC flag in the following command. Leaving authorization-mode flags, such as AlwaysAllow, in place allows all authorization requests, effectively disabling all authorization and limiting the ability to enforce least privilege for access.

  • Audit logging and threat detection: Kubernetes audit logs are a goldmine for security, capturing attributed activity in the cluster and making sure configurations are properly set. The security checks provided by InsightCloudSec ensure that the security audit tools are enabled. In order to keep track of any suspicious activity:

    • Check that the Kubernetes native audit logging configuration is enabled.
    • Check that seccomp: audit mode is enabled. The seccomp tool is disabled by default but can be used to limit a container’s system call abilities, thereby lowering the kernel’s attack surface. Seccomp can also log what calls are being made by using an audit profile.

  • Upgrading and application security practices: Security is an ongoing process, and it is vital to stay up to date with upgrades, updates, and patches not only in Kubernetes, but also in hypervisors, virtualization software, and other plugins. Furthermore, administrators need to make sure they uninstall old and unused components as well, in order to reduce the attack surface and risk of outdated tools. InsightCloudSec provides the checks required for such scenarios, including:

    • Promptly applying security patches and updates
    • Performing periodic vulnerability scans and penetration tests
    • Uninstalling and deleting unused components from the environment

Stay up to date with InsightCloudSec

Announcements like this catch the attention of the cybersecurity community, who want to take advantage of new functionalities and requirements in order to make sure their business is moving forward safely. However, this can often come with a hint of hesitation, as organizations need to ensure their services and settings are used properly and don’t introduce unintended consequences to their environment.

In order to help our customers to continuously stay aligned with the new guidelines, InsightCloudSec is already geared with a new compliance pack that provides additional coverage and support, based on insights that are introduced in the Kubernetes Hardening Guide.

Want to see InsightCloudSec in action? Check it out today.

Additional reading:

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

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

Register Now

Additional reading:

Cloud Security and Compliance: The Ultimate Frenemies of Financial Services

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.

3. Improve organizational culture by sharing context

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:

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

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.

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

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.

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

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

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.

Kubernetes Guardrails: Bringing DevOps and Security Together on Cloud

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

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.

InsightCloudSec Supports 12 New AWS Services Announced at re:Invent

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.

InsightCloudSec Supports 12 New AWS Services Announced at re:Invent

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

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.

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

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.

Automation Enables Innovation in the Cloud

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

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.

Turn On, Tune In, Drop the Noise: Achieve Better Cloud Security by Reducing Noise

Post Syndicated from Rapid7 original https://blog.rapid7.com/2021/10/14/turn-on-tune-in-drop-the-noise-achieve-better-cloud-security-by-reducing-noise/

Turn On, Tune In, Drop the Noise: Achieve Better Cloud Security by Reducing Noise

The modern world is full of signals. A select few are critically important, others are interesting or informative, and the overwhelming majority are less useful or painfully irrelevant. All of these signals that are neither useful nor relevant are best categorized as noise.

For security professionals, it’s easy to get lost in this noise. Many of them get email, text, or Slack notifications for every helpdesk ticket that is issued, updated, and closed. The average security manager might get hourly, daily, weekly, and monthly reports from a variety of different tools that they and their teams may or may not interact with on a regular basis. And at some point, the thousands of alarms and notifications that these same tools generate on a weekly basis end up causing mind-numbing alert fatigue that bogs down security teams. Research has found that 75% of companies are actually spending more time chasing down false positives than responding to genuine security incidents, TechRepublic reports.

Are these signals important? Maybe. Are they getting to the right people at the right time? Hopefully. But hope is not enough when it comes to cloud security.

Misconfigurations add to the clamor

Our 2021 Cloud Misconfigurations Report confirms that data breaches attributed to cloud misconfigurations are still a significant concern for enterprises across all industries. It’s hard to go a few days without hearing of yet another incident in which the data is breached, leaked, or otherwise mishandled. In fact, according to our data, there are 2.3 data breaches per week… and that number doesn’t include those that aren’t reported.

There are many reasons why cloud misconfigurations remain such a significant problem. One contributing factor that continues to be front and center is the overabundance of noise that comes with the ephemeral, fast-evolving nature of cloud environments. The cadence at which security teams are bombarded with alerts and notifications is overwhelming. Yet these teams are still responsible for ensuring the security of the sensitive data in complex cloud environments.

As stewards of this data, security teams must have a comprehensive cloud security solution that allows them to continuously monitor and react to threats. Security teams are trying to understand the high-priority issues that actually matter, all while keeping up with the fast, continuous pace of innovation. To accomplish this, they must invest in a solution that gets the right signals to the right people at the right time, through the right means.

Many of the tools that enterprises use to be better, faster, and stronger are incredibly powerful, but sometimes this power can create chaos and noise. This is especially true for the many cloud security solution types available today. Almost any cloud security tool should be able to tell you if you have a storage bucket open to the public. But what if that storage bucket is meant to be open? What if it’s in a protected environment? What if your developers have created strategic exemptions to specific rules for a legitimate reason?

At best, the security team receives the alert, investigates it, and then determines that there is no issue. While this is by no means an efficient or scalable approach to handling cloud security incidents, nothing catastrophically bad has happened. There wasn’t an actual data breach, and the developers weren’t impeded by security, since their instance wasn’t shut down automatically.

But there are other, more likely scenarios to consider. For example, what if the security team’s investigation of a harmless exemption diverts their attention from a more critical alert? If the real alert is ignored amid the noise and the threat remains unresolved, the entire organization is at risk. As we know, there are huge repercussions of a data breach — from financial to legal to operational to reputational. In fact, according to the Ponemon Institute, the average cost of a data breach is now up to $4.24 million.

Cutting through to the signal

With this much at stake, security teams can’t become immune to critical alerts or blind to the information that is essential to maintaining continuous cloud security. InsightCloudSec helps reduce noise through its extensibility and the level of granularity through which you can determine the scope of alerts (and actions in response to those alerts).

Unified visibility and terminology

InsightCloudSec sets the noise-reduction table by providing a single source of visibility into cloud environments that spans across AWS, GCP, Microsoft Azure, Alibaba Cloud, Oracle Cloud Infrastructure, and Kubernetes. By offering a standardized asset inventory across cloud service providers, security teams can apply policy and leverage real-time automated remediation consistently.

Curated, context-rich information

We’ve added value to this unified visibility by giving you the ability to finely tune the scope of what information you want to capture through our filters, insights, and exemptions.

Filters

InsightCloudSec filters provide a way to explore your cloud environment and surface problems of interest. You can specify the conditions that InsightCloudSec searches to identify matching resources. Currently, InsightCloudSec offers almost 1,400 out-of-the-box filters, with almost infinite possibilities for customization.

Insights

An InsightCloudSec insight is a check on a specific behavior, condition, or characteristic of a cloud resource. Built from the abundant (and continuously growing!) library of filters, an insight allows you to view all of your clouds and provides an in-depth understanding of your infrastructure’s security, compliance, optimization, or other characteristics that you specify.

Insights can be defined around any individual resource or resource type to identify resources that may need to have limited public accessibility. Insights can focus on specific characteristics or configuration issues, identify a network missing an internet gateway, or identify a database without encryption. As with filters, insights can be customized to fit almost any need.

Exemptions

As with any rule, there are always exceptions… or in this case, exemptions. InsightCloudSec allows you to specify resources that should be exempt from an insight. Exemptions can even be tuned to a specific time period. Using this functionality allows organizations to have a highly curated, context-rich approach to the data, and to notifications about that data.

Get the alerts you want, how and when you want them

InsightCloudSec integrates with SMTP/email, Slack, Microsoft Teams, ServiceNow, PagerDuty, Jira, Jinja2, and more. These integrations empower security teams to specify how they want to receive their alerts to monitor and address problems efficiently and effectively.

For example, let’s say that you only want to receive notifications related to a specific regulation (e.g., PCI-DSS). Through our pack-level notifications, you can send notifications (via email, Slack, etc.) based on a collection of insights that together form the compliance framework. InsightCloudSec offers both out-of-the-box compliance packs and the ability to create custom packs to fit your organization’s specific needs.

The pack-level notification capability includes cadence settings, so you have the ability to send it weekly, daily, or hourly. It allows for the delivery of information around an entire category of insights, enabling organizations to cut down on the noise of individual notifications that might not provide the full context your team needs.

With the persistence of data breaches due to cloud misconfigurations, it is essential for organizations to invest in tools to help them tune into the right information about their complex cloud environments.

Interested in seeing firsthand how InsightCloudSec can reduce noise for your organization? See it in action in our demo.

To learn more about the essentials of good cloud security, see our previous blog post on shifting left here.

Have You Checked the New Kubernetes RBAC Swiss Army Knife?

Post Syndicated from Gadi Naor original https://blog.rapid7.com/2021/10/12/kubernetes-rbac-swiss-army-knife/

Have You Checked the New Kubernetes RBAC Swiss Army Knife?

Kubernetes Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API. This is all quite useful, but Kubernetes RBAC is often viewed as complex and not very user-friendly.

Introducing Your Swiss Army Knife for RBAC Controls

InsightCloudSec’s RBAC tool is an all-in-one open-source tool for analyzing Kubernetes RBAC policies and simplifying any complexities associated with Kubernetes RBAC.

InsightCloudSec’s RBAC tool significantly simplifies querying, analyzing, and generating RBAC policies. It is available as a standalone tool or as a kubectl Krew Plugin.

Visualize Cluster RBAC Policies and Usage

A Kubernetes RBAC command can be used to analyze cluster policies and how they are being used and generate a simple relationship graph.

Have You Checked the New Kubernetes RBAC Swiss Army Knife?

By default, rbac-tool viz will connect to the local cluster (pointed by kubeconfig) and create a RBAC graph of the actively running workload on all namespaces except kube-system.

Examples

# Scan the cluster pointed by the kubeconfig context 'myctx'
rbac-tool viz --cluster-context myctx

# Scan and create a PNG image from the graph
rbac-tool viz --outformat dot --exclude-namespaces=soemns && cat rbac.dot | dot -Tpng > rbac.png && google-chrome rbac.png

Analyze Risky RBAC Permission

The command rbac-tool analysis analyzes RBAC permissions and highlights overly permissive principals, risky permissions, or any specific permissions that are not desired by cluster operators.

The command allows the use of a custom analysis rule set, as well as the ability to define custom exceptions (global and per-rule), and can integrate into deployment tools such as GitOps and automation analysis tasks in order to detect undesired permission changes, unexpected drifts, or risky roles.

Examples

# Analyze the cluster pointed by the kubeconfig context 'myctx' with the internal analysis rule set
rbac-tool analysis --cluster-context myctx

Query Who Can Perform Certain Kubernetes API Actions

The command rbac-tool who-can enables operators to simply query which subjects/principals are allowed to perform a certain action based on the presently configured RBAC policies.

Examples

# Who can read ConfigMap resources
rbac-tool who-can get configmaps


# Who can watch Deployments
rbac-tool who-can watch deployments.apps


# Who can read the Kubernetes API endpoint /apis
rbac-tool who-can get /apis


# Who can read a secret resource by the name some-secret
rbac-tool who-can get secret/some-secret

A Flat and Simple View of RBAC Permissions

The command rbac-tool policy-rules aggregates the policies and relationships from the various RBAC resources, and provides a flat view of the allowed permissions for any given User/ServiceAccount/Group.

Examples

# List policy rules for system unauthenticated group
rbac-tool policy-rules -e '^system:unauth'

Output:

Have You Checked the New Kubernetes RBAC Swiss Army Knife?

Generate RBAC Policies Easily

Kubernetes RBAC lacks the notion of denying semantics, which means generating an RBAC policy that says “Allow everything except THIS” is not as straightforward as one would imagine.

Here are some examples that capture how rbac-tool generate can help:

  • Generate a ClusterRole policy that allows users to read everything except secrets and services
  • Generate a Role policy that allows create, update, get, list (read/write) everything except Secrets, Services, Ingresses, and NetworkPolicies
  • Generate a Role policy that allows create, update, get, list (read/write) everything except StatefulSets

Command Line Examples

Examples generated against Kubernetes cluster v1.16 deployed using KIND:

# Generate a ClusterRole policy that allows users to read everything except secrets and services
rbac-tool  gen  --deny-resources=secrets.,services. --allowed-verbs=get,list


# Generate a Role policy that allows create, update, get, list (read/write) everything except Secrets, Services, NetworkPolicies in core,Apps and networking.k8s.io API groups
rbac-tool  gen --generated-type=Role --deny-resources=secrets.,services.,networkpolicies.networking.k8s.io --allowed-verbs=* --allowed-groups=,extensions,apps,networking.k8s.i


# Generate a Role policy that allows create, update, get, list (read/write) everything except StatefulSets
rbac-tool  gen --generated-type=Role --deny-resources=apps.statefulsets --allowed-verbs=*

Example output

# Generate a Role policy that allows create, update, get, list (read/write) everything except Secrets, Services, NetworkPolicies in core,Apps & networking.k8s.io API groups
rbac-tool  gen --generated-type=Role --deny-resources=secrets.,services.,networkpolicies.networking.k8s.io --allowed-verbs=* --allowed-groups=,extensions,apps,networking.k8s.io

Output:

Have You Checked the New Kubernetes RBAC Swiss Army Knife?

Another useful policy generation command is rbac-tool auditgen, which can generate RBAC policy from Kubernetes audit events.

Conclusion

InsightCloudSec’s RBAC tool fills various gaps that exist in the Kubernetes native tools, and addresses common RBAC-related use cases. This RBAC tool is an all-in-one solution that helps practitioners to perform RBAC analysis, querying, and policy curation.

You’ve got your full Swiss army knife now—what are you waiting for?

Check out this link for more information and a step-by-side installation guide.

Rapid7 Introduces: Kubernetes Security Guardrails

Post Syndicated from Alon Berger original https://blog.rapid7.com/2021/07/26/rapid7-introduces-kubernetes-security-guardrails/

Rapid7 Introduces: Kubernetes Security Guardrails

Cloud and container technology provide tremendous flexibility, speed, and agility, so it’s not surprising that organizations around the globe are continuing to embrace cloud and container technology. Many organizations are using multiple tools to secure their often complex cloud and container environments, while struggling to maintain the flexibility, speed, and agility required to keep security intact.

Cloud Security Just Got Better!

In addition to acquiring DivvyCloud, a top-tier Cloud Security Posture Management (CSPM) platform in 2020, Rapid7 recently announced another successful acquisition— joining forces with Alcide, a leading Kubernetes security start-up that offers advanced Cloud Workload Protection Platform (CWPP) capabilities.

Rapid7 is taking the lead in the CSPM space by leveraging both DivvyCloud’s and Alcide’s capabilities and incorporating them into a single platform: InsightCloudSec, your one-stop shop for superior cloud security solutions.

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 the Kubernetes security blind spots. It is for this reason that we are introducing Kubernetes Security 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 ability 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. Integrated within minutes, Kubernetes Guardrails simplifies the security assessment for the entire Kubernetes environment and the CI/CD pipeline while creating baseline profiles for each cluster, 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 such as PCI, GDPR, and HIPAA.

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

Rapid7 proudly brings forward a Kubernetes security solution that encapsulates all-in-one capabilities with incomparable coverage for all things Kubernetes.

With a security-first approach and a 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? Register for the webinar on InsightCloudSec and its Kubernetes protection.