With the rise of cloud computing, businesses can store troves of data online and access it from anywhere at any time. However, this convenience comes with a price. Cybercriminals are always looking for vulnerabilities in the cloud and one of the most alarming threats to emerge is cloud ransomware.

Cloud ransomware is malware that targets cloud-based storage systems and encrypts data held in the cloud, making it inaccessible unless the compromised party agrees to pay the ransom in exchange for a decryption key. While some experts argue that cloud ransomware is a myth, others insist that it is a real threat that businesses must take seriously.

This blog post explores the reality of cloud ransomware and debunks the most common myths surrounding this threat.

Defining Cloud Ransomware

Cloud ransomware works much like a traditional ransomware. First, cybercriminals infect the victim’s system, typically through a social engineering tactic such as phishing emails or by exploiting vulnerabilities in a cloud provider’s security systems. Once inside, the cloud ransomware spreads throughout the infrastructure, infecting all connected devices and cloud storage systems.

The attacker uses an encryption algorithm to scramble the victim’s files, rendering them unreadable without a decryption key. This key is often a private key held by the attacker, who offers to provide it to the victim after they have paid a ransom. In addition, threat actors will attempt to exfiltrate data in order to use it for further leverage, a technique widely referred to as “double extortion”.

Is Cloud Ransomware Relevant for Kubernetes?

Concern for cloud ransomware attacks continues to grow amongst organizations worldwide, particularly as more businesses take on digital transformation projects and move their data and applications to the cloud. With the rise of Kubernetes (K8s) as a leading container orchestration platform in these transformations, many organizations wonder if they risk falling victim to cloud ransomware attacks.

The short answer is ‘yes’. K8s can be particularly vulnerable to ransomware attacks due to their distributed nature, making it challenging to detect and contain an attack.

Ransomware attacks on K8s can occur in a few different ways. Common methods include Kubernetes API server vulnerabilities, which allow attackers to gain unauthorized access to the cluster and its resources. Once inside, attackers can launch a ransomware attack, encrypting files and demanding payment in exchange for the decryption key.

Other potential entry points for ransomware attacks on K8s are vulnerabilities and misconfigurations. If an attacker can access an unsecured container image, they can insert ransomware into the image and then launch the attack when the image is deployed to the K8s cluster.

To protect against cloud ransomware attacks on K8s, it is important to implement a comprehensive security strategy that includes regular vulnerability assessments and penetration testing. It is also essential to ensure that all components of the K8s cluster are properly secured and that access is limited to only those who need it.

Other best practices for protecting against cloud ransomware attacks on K8s include:

• Implementing strong access controls, including multi-factor authentication and role-based access control (RBAC).
• Ensuring that all container images are scanned for vulnerabilities and only trusted images are used.
• Regularly monitoring the K8s cluster for suspicious activity, such as unusual file access or changes to configuration files.
• Keeping all K8s components updated with the latest security patches and updates.
• Implementing a disaster recovery plan that includes regular backups of critical data and applications.

While K8s can be vulnerable to cloud ransomware attacks, organizations can take steps to protect themselves and minimize the risk of falling victim. By implementing a comprehensive security strategy and following best practices for securing K8s, organizations can reduce the likelihood of a successful ransomware attack and ensure that their data and applications remain safe and secure.

Myth #1 | “Cloud Ransomware Is Not a Real Threat”

Reality: Cloud ransomware is a real and growing threat. As more businesses move their data to the cloud, cybercriminals develop new techniques to attack cloud-based systems.

According to the latest forecast in cloud computing from Gartner, businesses globally are set to increase their spending on cloud services by 20.7% making the total amount spent just over $590 billion in 2021 up from $490 billion the year before. These days, cloud services and applications are increasingly mission-critical for day-to-day operations and security.

Threat actors have followed these trends for cloud adoption and are now targeting this attack surface with a new generation of ransomware specially crafted to spread through cloud infrastructures and encrypt data stored within them. Since clouds support mass numbers of both users and sensitive information, they have become high-value targets for threat actors.

Myth #2 | “Cloud Service Providers Are Solely Responsible for Securing Your Data”

Reality: While cloud service providers have security measures in place, it is ultimately the user’s responsibility to secure their own data. Cloud providers usually offer basic security measures like firewalls, but it is up to the user to configure these settings properly and implement additional security measures like multi-factor authentication (MFA) and encryption.

Cloud service providers are responsible for ensuring the security of their infrastructure and the applications they provide to their customers. This includes implementing security measures such as firewalls, antivirus software, and encryption protocols to protect their systems from cyber threats. They also provide secure storage, network access, and data transmission. However, they do not have full responsibility for securing a business’ data.

The Cloud Shared Responsibility Model

Cloud security is a shared responsibility between the cloud service provider and the customer. The provider ensures the security of the infrastructure including the physical data centers, networking, and server hardware. In tandem, the customer is responsible for securing their data. The customer’s responsibilities include securing their account access, configuring their security settings, managing their data, and monitoring their activity.

The Cloud Shared Responsibility Model has become a critical tool in cloud security as it helps businesses and cloud service providers clarify who is responsible for what and ensure effective cloud security. Without such a model, responsibilities are often miscommunicated and misunderstood, leading to gaps in security coverage and duplication of efforts.

A Customer’s Responsibility for Securing Their Cloud Data

The customer is responsible for securing their data while it is in storage, in transit, and while it is being used. This includes implementing access controls, encryption, and monitoring for any unauthorized activity. Customers should also ensure that their data is backed up and stored in a secure location. Failure to secure data can lead to data loss, theft, or a data breach.

Myth #3 | “Backing Up Your Data Is Enough Protection Against Cloud Ransomware”

Reality: Backing up sensitive data is a first step in protecting against any kind of service outage, including malicious attacks from malware including ransomware. However, since at least 2020, ransomware threat actors began to pivot to using double-extortion techniques to counteract victims trying to restore their data from backups and security software that could rollback infected machines to a pre-infected state. Threatening to leak or sell stolen data is now a widespread tactic in use by many ransomware gangs.

In addition, should a business fall victim to an attack, security leaders and technical teams must restore their data from a clean backup, which can be time-consuming. Depending on the severity of the attack, it may take days, weeks, or even months to restore data from a backup. During this time, the organization may be unable to operate normally, resulting in lost productivity and revenue.

Having multiple backups in different locations and testing them regularly is important to ensure they will work correctly in times of need. If the backup process is not comprehensive or if backups are not taken regularly, there may be gaps in the data that is recoverable. In such cases, some data may be lost forever.

Cybercriminals are constantly evolving their tactics, and newer forms of ransomware can also target backups or corrupt them. In such cases, the data may not be recoverable even with the backups.

Myth #4 | “Cloud Ransomware Only Affects Large Corporations”

Reality: Cloud ransomware can affect anyone who stores data in the cloud, regardless of the business size. In fact, some cybercriminals choose to target small and medium-sized businesses (SMBs) due to their less experienced security posture and lack of dedicated security resources.

SMBs also hold valuable data such as customer data, financial data, and intellectual property to, potentially, a large number of local clients. Ransomware operators know that if they can successfully encrypt this data, they can demand a ransom to release it, potentially causing significant disruption to the business.

Locked into the potential for quick payouts, ransomware operators often see SMBs as easier targets as they may be more likely to pay the ransom quickly to avoid business disruption. Larger businesses and global enterprises in contrast may have more resources to recover from a ransomware attack without having to pay the ransom.

Myth #5 | “Paying the Ransom Will Ensure Return of Your Data”

Reality: To help meet the risks of ransomware incidents head on, CISA launched an ongoing, comprehensive campaign called Stop Ransomware to arm businesses with critical best practices and knowledge about the threats that face them.

One of the most important reminders coming from this campaign has been to strongly discourage businesses from paying ransoms in the case of an attack. From the campaign resources, “Since ransomware payments do not ensure data will be decrypted or systems or data will no longer be compromised, federal law enforcement do not recommend paying ransom. In addition, the Treasury Department warns these payments run the risk of violating Office of Foreign Assets Control (OFAC) sanctions. Therefore, prevention is key.”

Additionally, there is no guarantee that the attacker provides their victims with the decryption key even if the ransom is paid. Having data backups and working with cybersecurity experts during active incidents ensures file recovery without the need to pay out.

Myth #6 | “Cloud Ransomware Is Easy to Prevent”

Reality: Cloud ransomware can be difficult to prevent if the organization does not have proper security controls in place. Once an attack takes hold, it can spread rapidly through an organization as it often operates silently in the background, encrypting critical data without disrupting day-to-day workflows and processes. Security teams must regularly monitor their cloud-based systems for any unusual activity and cloud workload protection on associated devices in the cloud.

By nature, cloud environments are highly dynamic, with resources being created, destroyed, and moved constantly. This can make it difficult to establish a baseline of normal activity, making it harder to identify abnormal behavior associated with ransomware.

Also, cloud environments work through multiple layers of abstraction, which can cause security teams issues in maintaining full visibility into the underlying infrastructure. For example, virtual machines may be running on physical servers that are managed by a cloud provider, making it difficult to detect ransomware that is running within a virtual machine.

Myth #7 | “Preventing Cloud Ransomware Is Too Expensive”

Reality: While implementing security measures like encryption and MFA can come with a larger, upfront cost, the cost of a ransomware attack is sure to be much higher. In IBM’s Cost of a Data Breach report, the average cost of a data breach in the United States cost businesses $9.44 million – $5.09 million more than the global average cost. The report noted that ransomware attacks have grown more destructive and that nearly half of all data breaches happen in the cloud.

Post-attack costs are often not considered when organizations push back on implementing new security measures. After data breaches, companies face long-term financial losses that are often irreversible and, if severe enough, can put the company at risk of foreclosure. Common costs that pile up after severe cyberattacks include:

• Financial Losses – Data breaches can result in financial losses for the affected individuals or organizations. These losses can result from theft of financial information, fraud, or loss of business due to damage to the organization’s reputation.
• Reputational Damage – A data breach can damage an organization’s reputation, resulting in a loss of customer trust and loyalty. This damage can be long-lasting and difficult to repair. Losses also include any prospective customers and future business opportunities.
• Legal Issues – Data breaches can result in legal issues, such as lawsuits from affected individuals or regulatory fines for non-compliance with data protection regulations.
• Increased Security Costs – Following a data breach, an organization may need to increase its security measures to prevent future breaches. This can result in increased costs for security personnel, software, and hardware.
• Identity Theft – If personal information such as Social Security numbers or credit card information is stolen in a data breach, affected individuals may be at risk of identity theft for years to come.

Conclusion

Attracted to the mounds of sensitive data stored in clouds and a wide-spread adoption of cloud computing in recent years, threat actors are evolving their ransomware to target cloud infrastructures and services especially. Cloud ransomware is a growing threat that can affect any who choose to store their data in the cloud.

When it comes to securing the cloud surface, SentinelOne enables organizations to protect their endpoints across all cloud environments, public, private, and hybrid, through Singularity Cloud. Singularity Cloud works by extending distributed, autonomous endpoint protection, detection, and response to compute workloads running in both public and private clouds, as well as on-prem data centers. Contact us today or book a demo to see how Singularity Cloud brings agility, AI-powered security, and compliance to organizations globally.

Kubernetes, a popular open-source container orchestration system, has gained popularity among enterprises for its ability to manage and automate large-scale containerized workloads. However, as with any technology, inherent security risks must be considered and addressed.

In this post, we explore the top ten Kubernetes security risks and provide recommendations for mitigating these risks.

What is Kubernetes?

Kubernetes, commonly referred to as “K8s”, is a container orchestration system that automates the deployment, scaling, and management of containerized workloads. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).

Kubernetes is a powerful tool that offers self-healing, auto-scaling, and service discovery features. In addition, it allows developers to deploy their applications as workloads that can run on any platform that supports Docker containers.

Understanding Kubernetes Security

Teams securing Kubernetes are responsible for addressing all its various layers and services. Kubernetes security comprises three main components: securing the cluster, securing nodes, and securing applications.

Securing K8 Clusters

The Kubernetes control plane manages the cluster, including scheduling, scaling, and monitoring. Securing the cluster includes securing the control plane components, such as the API server, etcd, and Kubernetes controller manager by enabling authentication, authorization, and encryption.

Securing K8 Nodes

Nodes are the worker machines in a Kubernetes cluster that run the containers. Nodes can be secured through the host operating system, by configuring network security, and by securing the Kubernetes runtime environment. Removing unnecessary user accounts and ensuring that nothing runs as root are all best practices to consider when securing K8 nodes.

Securing K8 Applications

In Kubernetes, a pod is a container used to run an application. Securing these applications means securing the pod. Kubernetes provides several security features to help secure applications. These features can be used to limit resource access, enforce network policies, and enable secure communication between containers.

Top 10 OWASP Kubernetes Security Risks & Recommendations

The OWASP Foundation was created to improve software security through community-led, open-source software projects. Here are the top ten strategies recommended by OWASP for securing Kubernetes ecosystems.

1. Insecure Workload Configurations

Kubernetes manifests contain a plethora of configurations that can affect the reliability, security, and scalability of a given workload. These configurations should be audited and remediated continuously to prevent misconfigurations. However, some high-impact manifest configurations are more likely to be misconfigured than others. Some examples are:

• Running application processes as root inside a container is a common misconfiguration in many clusters. Though root may be required for some workloads, it should be avoided when possible. If the container were to be compromised, the attacker would have root-level privileges, allowing actions such as starting a malicious process that otherwise wouldn’t be permitted with other users on the system.
• To limit the impact of a compromised container on a Kubernetes node, it is recommended to utilize read-only filesystems when possible. This prevents a malicious process or application from writing back to the host system. Read-only filesystems are a key component to preventing container breakout.
• Privileged containers should be disallowed as they can access additional resources and kernel capabilities of the host. Workloads running as root combined with privileged containers can be devastating as the user can access the host completely. This is, however, limited when running as a non-root user. Privileged containers are dangerous as they remove many of the built-in container isolation mechanisms entirely.

While many security configurations are often set in the securityContext of the manifest itself, other misconfigurations can be detected elsewhere. They must first be detected in both runtime and code to prevent misconfigurations. It is imperative to enforce that applications run as non-root users, run in non-privileged mode, and set ‘AllowPrivilegeEscalation’ to ‘False’ to disallow child processes from gaining more privileges than their parents.

Security teams can use tools such as Open Policy Agent as a policy engine to detect common misconfigurations like the ones listed above. Using the CIS Benchmark for Kubernetes is a good starting point for discovering misconfigurations. However, it is important to continuously monitor and remediate any potential misconfigurations to ensure the security and reliability of a Kubernetes workload.

2. Supply Chain Vulnerabilities

At various phases of the development lifecycle supply chain, containers take on many forms and each will present its own unique security challenge. This is because a single container may rely on hundreds of external, third-party components, diluting the level of trust at each phase. The most common supply chain vulnerabilities are below:

• Image integrity – Container images are made up of layers, each bringing possible security risks. Since container images use third-party packages extensively, they can be dangerous to run within a trusted environment. To mitigate this, it’s important to ensure image integrity by validating software at each phase using in-toto attestations. Doing so increases the SLSA level of the build pipeline, which means it is more resilient against attacks. Additionally, using image signing and verification through cryptographic key-pairs can detect tampering with the artifacts throughout the DevOps workflow, which is an essential step in building a secure supply chain.
• Image composition – Container images contain layers, each presenting different security implications. A properly constructed container image reduces the attack surface and increases deployment efficiency. Thus, it’s important to create container images using minimal OS packages and dependencies to reduce the attack surface, considering using alternative base images such as Distroless or Scratch to improve security posture and reduce image size. Furthermore, tools like Docker Slim are available to optimize image footprint for performance and security reasons.
• Known software vulnerabilities – Security flaws are widespread due to the extensive use of third-party packages in container images. Image vulnerability scanning is crucial for enumerating known security issues in container images, which should be used as a first line of defense. Open-source tools such as Clair and trivy statically analyze container images for known vulnerabilities such as CVEs, and should be used as early in the development cycle as reasonably possible.

Enforcing policies to prevent unapproved images from being used is also essential. Kubernetes admission controls and policy engines such as Open Policy Agent and Kyverno can reject workload images that haven’t been scanned for vulnerabilities, use a base image that’s not explicitly allowed, don’t include an approved SBOM, or originate from untrusted registries.

3. Overly-Permissive RBAC

Role-based access control (RBAC) allows the definition of who has access to what resources in a cluster and what they can do with those resources. When configured correctly, RBAC helps prevent unauthorized access and protect sensitive data.

However, if RBAC is not configured correctly, it can lead to overly-permissive settings that allow users to access resources that they should not have access to or perform actions that they should not be able to perform. This can create serious security risks, including data breaches, data loss, and compromise.

Examples of overly-permissive RBAC include the unnecessary use of cluster-admin in Kubernetes. Granting access to this “superuser” role gives unfettered control over every resource in the cluster, which is especially dangerous when used in a ClusterRoleBinding, which grants the all-powerful cluster-admin privilege to every single Pod in the default namespace, making the entire cluster vulnerable to attack.

To prevent such an attack, it is crucial to continuously analyze RBAC configurations and enforce the principle of least privilege (PoLP). This can be achieved by reducing direct cluster access by end users, avoiding using Service Account Tokens outside of the cluster, and auditing RBAC included with installed third-party components. Moreover, deploying centralized policies to detect and block risky RBAC permissions, utilizing RoleBindings to limit the scope of permissions to particular namespaces, and following the official RBAC Good Practices is highly recommended.

4. Policy Enforcement

Policy enforcement involves the implementation of rules and regulations to ensure compliance with organizational policies. In the context of Kubernetes, policy enforcement ensures that the Kubernetes cluster adheres to the security policies set by the organization. These policies could be related to access control, resource allocation, network security, or any other aspect of the Kubernetes cluster.

Policy enforcement is essential for ensuring the security and compliance of the Kubernetes cluster. Failure to enforce policies can lead to security breaches, data loss, and other potential risks. Additionally, policy enforcement helps maintain the integrity and stability of the Kubernetes cluster, ensuring that resources are allocated effectively and efficiently.

Best Practices for Policy Enforcement in Kubernetes

It is essential to follow best practices to ensure effective policy enforcement in Kubernetes. Some of these include:

• Defining policies that align with organizational goals and regulatory requirements.
• Implementing policies using Kubernetes-native resources or policy controllers.
• Regularly reviewing and updating policies to ensure they remain relevant and effective.
• Monitoring policy violations and remediating them promptly.
• Educating users on Kubernetes policies and their importance.

5. Inadequate Logging

Logging is an essential component of any system that runs applications. It involves collecting and storing data about the system’s behavior and its applications. Logging in Kubernetes is no different. Kubernetes logs are records of events that occur within a Kubernetes cluster.

These logs can help identify system issues and provide valuable insight into system performance, security breaches, and data loss. Various sources, including application code, Kubernetes components, and system-level processes, can generate Kubernetes logs.

Best Practices for Kubernetes Logging

• Use a Centralized Logging System – A centralized logging system collects and stores logs from all Kubernetes components and applications in a single location. This makes it easier to identify and respond to issues with the system. There are many different centralized logging systems available for Kubernetes. Some popular options include Elasticsearch, Fluentd, and Logstash.
• Use Standardized Logging Formats – Standardized logging formats make searching and analyzing logs from multiple sources easier. This is especially important when using a centralized logging system. Several standardized logging formats are available for Kubernetes, including JSON and syslog. Security teams will need to choose a format supported by their logging system and configure their Kubernetes components and applications to use that format.
• Maintain Complete Logs – When it comes to Kubernetes logging, it’s important to log everything: application logs, Kubernetes component logs, and system-level logs. Logging everything ensures a complete picture of system behavior. However, logging everything can also generate a large amount of data. To manage this data, consider setting up log rotation and retention policies. Log rotation policies ensure that logs are rotated and compressed regularly to conserve disk space. Retention policies determine how long logs are kept before being deleted.
• Use Labels and Annotations – Labels and annotations are a powerful feature of Kubernetes that can provide additional context to logs. Labels are key-value pairs that can be attached to Kubernetes objects, such as pods and services. Annotations are similar to labels but can contain larger amounts of information. Labels and annotations can filter and search logs based on specific criteria. For example, security teams can add a label to all pods that are part of a particular application and then search for logs from those pods based on the label.
• Monitor Kubernetes Logs – Monitoring logs regularly allows security teams to identify issues with the system and respond to them quickly. There are many different tools available for monitoring Kubernetes logs. Some popular options include Prometheus, Grafana, and Kibana. These tools support log visualization where alerts can be set up based on specific criteria.
• Set Up Auditing – Setting up auditing in Kubernetes enables teams to track changes to the Kubernetes API server and other Kubernetes components, help identify unauthorized system changes, and ensure compliance with security policies. To set up auditing in Kubernetes, configure the Kubernetes API server to log audit events. These events can then be sent to a centralized logging system for analysis.

6. Broken Authentication

Broken authentication is a vulnerability that allows attackers to bypass authentication and gain unauthorized access to an application or system. Authentication is verifying a user’s or system’s identity, usually by requiring a username and password. If an attacker can bypass the authentication process, they can gain access to sensitive data, systems, or applications. In Kubernetes, broken authentication can occur due to several factors, including:

• Weak or compromised authentication credentials – If an attacker can obtain a user’s credentials, they can bypass authentication and gain unauthorized access to the Kubernetes cluster.
• Misconfigured authentication settings – Kubernetes supports several authentication mechanisms, including X.509 certificates, static tokens, and OAuth tokens. Misconfigured authentication settings can leave the Kubernetes cluster vulnerable to attack.
• Insecure communication channels – Kubernetes uses various communication channels, including the Kubernetes API server, kubelet, and, etcd. An attacker can intercept and manipulate traffic to bypass authentication if these communication channels are insecure.

How to Prevent Broken Authentication in Kubernetes

Preventing broken authentication in Kubernetes requires implementing several security measures, including:

• Strong authentication credentials – Users must use strong and unique passwords or authentication tokens that are not easily guessable.
• Secure communication channels – Communication channels between Kubernetes components must be encrypted using SSL/TLS.
• Proper authentication configuration – The authentication mechanisms used in Kubernetes must be correctly configured to prevent unauthorized access.
• Implementing RBAC – Role-Based Access Control (RBAC) should be used to restrict access to Kubernetes resources based on a user’s role.

7. Network Segmentation

Network segmentation divides a network into smaller subnetworks, each isolated. This is done to improve security by limiting the scope of potential attacks. By isolating different parts of the network from each other, network segmentation makes it harder for attackers to move laterally within the network and gain access to sensitive resources.

By default, any workload can communicate with another workload when no additional controls are put in place in a Kubernetes network. An attacker can leverage this default behavior by exploiting a running workload to probe the internal network, move to other running containers, or even invoke private APIs.

How to Implement Network Segmentation in Kubernetes Clusters

Isolating traffic within the context of a Kubernetes minimizes damage and loss should a container become compromised. Several techniques can be used to implement network segmentation in Kubernetes clusters to stop lateral movement and still allow valid traffic to route as normal. Two important techniques are:

• Using Network Policies – Kubernetes supports network policies, which define how traffic flows between pods and namespaces. Using network policies controls which pods can communicate with each other and which ones are isolated from the rest of the cluster.
• Using Network Segmentation Tools – Many third-party tools can implement network segmentation in Kubernetes clusters. The most popular ones include Calico, Weave Net, and Cilium. These tools provide advanced network segmentation capabilities, such as encryption, firewalling, and intrusion detection.

8. Secrets Management

A “secret” is an object in Kubernetes that contains sensitive data such as passwords, certificates, and API keys. Secrets store confidential data that should be inaccessible to other users and processes within the cluster. Kubernetes secrets are stored in etcd, a distributed key-value store used by Kubernetes to store all cluster data.

Kubernetes Secrets Management Best Practices

Though secrets are a very useful function in the Kubernetes ecosystem, they need to be handled with caution. Managing Kubernetes secrets can be broken down into the following steps:

1. Deploy encryption at rest – A potential attacker can gain considerable visibility into the state of a cluster by accessing the etcd database, which contains any information accessible via the Kubernetes API. Kubernetes offers encryption at rest; a feature introduced in version 1.7 and v1 beta since 1.13. Encryption at rest safeguards secret resources in etcd, ensuring that the content of those secrets remains hidden from parties that access etcd backups. This feature is still in the beta stage, but it provides an extra layer of security in situations where backups are not encrypted, an attacker has read access to etcd.
2. Address security misconfigurations such as vulnerabilities, image security, and policy enforcement – RBAC configuration should also be locked down, and all Service Account and end-user access should be restricted to the least privilege, especially when accessing secrets. Auditing the RBAC configuration of third-party plugins and software installed in the cluster is also necessary to ensure that access to Kubernetes secrets is not granted unnecessarily.
3. Ensure that logging and auditing are in place – This helps detect malicious or abnormal behavior, including access to secrets. Kubernetes clusters produce useful metrics around activities that can be leveraged to detect such behaviors. Therefore, enabling and configuring Kubernetes audit records and centralizing their storage is advisable.

A few more additional tips and tricks include rotating secrets regularly to reduce the risk of secrets being compromised, auditing secret access to detect any unauthorized access to secrets, and using third-party secret management tools such as HashiCorp Vault or CyberArk Conjur to manage Kubernetes secrets.

9. Misconfigured Cluster Components

Kubernetes clusters are composed of various different components from key-value storage within etcd, the kubelet, the kube-apiserver, and more. All of the components are each highly configurable, meaning teams must implement the right security defaults to ensure their security.

Cluster compromise can happen when there are misconfigurations in core Kubernetes components. The most commonly misconfigured components on the Kubernetes control plan and nodes include the below:

• Kubelet – Check that the configuration is set up to deny anonymous authentication. Also, when communicating with Kubelets, authorization checks should always be performed. Set the Authorization mode to anything other than ‘AlwaysAllow’ in order to block unauthorized requests.
• Kube-apiserver – Inspect the internet accessibility of the API server in use and keep the Kubernetes API off of any public networks.

Performing CIS Benchmark scans and audits can help security teams focus on eradicating component misconfigurations. Using hosted services such as EKS, GKE, or AKS can help implement secure defaults and limit some of the options for component configuration.

10. Vulnerable Components

As Kubernetes clusters run vast amounts of third-party software, security teams will need to build a multi-tiered strategy to combat vulnerable components. Some best practices on how to do so are as follows:

• Track CVE databases – A key element in managing known and new vulnerabilities in Kubernetes is to stay up-to-date on CVE databases, security disclosures, and community updates. Security teams can use this intel to build actionable plans to implement regular patch management processes.
• Implement continuous scanning – Using a tool such as OPA Gatekeeper can be helpful in writing custom rules that work to uncover any vulnerable components within a Kubernetes cluster. Security teams can then track and document these findings to improve their security processes and policies.
• Minimize third-party dependencies – Third-party software must be thoroughly audited for overly permissive RBAC, low-level kernel access, and vulnerability disclosure records before deployment occurs.

Conclusion

Though Kubernetes is powerful, its adoption comes with the inevitable introduction of new risks into an environment’s existing infrastructure and applications. Having a comprehensive approach to securing Kubernetes ensures security teams can address all types of vulnerabilities and risks that can affect the individual layers of a Kubernetes cluster.

Following the recommendations provided in this post can set businesses on the right path to hardening their Kubernetes environments and reduce its attack surface. Through best practices implementation, security teams managing Kubernetes can gain visibility into their environments and better control each layer of their Kubernetes deployment.

Organizations always find it challenging to derive the maximum value from their security investment and deployment, and on top of these, different managed services options and new buzzwords in the market add to the problem. Every service provider claims to be doing everything that the organization wants, but it may not solve the problem in hand for the organization.

In this post, we explore the different services on offer and the needs that they aim to meet. We explore a framework that can help organizations understand which services are able to meet their particular requirements.

Facing the Challenge of Protecting the Enterprise

Organizations need a combination of People, Process and Technology to derive value out of their security technology investments. It is quite a common practice to buy the security technology first without understanding the need of managing and operating it, which ends up just becoming a tick in the box exercise and a lot of unrealized potential.

In the recent past, we saw organizations adopt EDR to solve the failure of legacy AV, assuming that it would work in ‘set and forget’ mode. Despite 24/7 monitoring, many organizations using EDR still aren’t engaging in active threat hunting, which leaves a lot of value and potential unrealized.

Managing and operating some security technologies has been made more challenging as a result of the skills shortage in the cybersecurity industry, which can be understood in two aspects:

• Talent Capacity Shortage: Not having the required number of people in-house or in the team to run operations 24/7 (a numbers problem)
• Talent Capability Shortage: Unable to find the find suitably skilled professionals to run the operations (a skills problem)

The Need for Managed Services

In such scenarios, organizations typically decide to outsource security to a third party such as Managed Security Service Providers (MSSPs). However, the service is limited to mostly management of the security technology rather than security operations. It’s very important to understand the difference between ‘security tool management’ and ‘security operations’ in the context of a SOC.

Security Tool Management – focuses on maintaining the general hygiene and administration of the security product such as policy enforcement, policy modification, setting role-based access control, changing access requirements, provisioning, and de-provisioning on the tools; in case of on-prem deployment, patching the underlying infrastructure, scaling the storage, upgrade of the application, etc. In some cases, it involves basic monitoring of alerts.

Security Operations – focuses on the use of the tool to fulfill the objective or the meet the goal for which tool was originally deployed; for example, EDR is deployed to protect and detect sophisticated attacks on endpoints and take timely response on detected attacks, so security operations would include monitoring to identify incidents, then contain, investigation and respond to the incident.

Organizations buy and deploy technology not just to manage it but to extract value out of it; hence, security operations should be at the core of investment in a security technology.

When it comes to challenges with security operations and adding the people and process part to the technology, organizations are often confused about what they need, whether they need Managed Detection & Response (MDR), Managed Threat Hunting (MTH), or Managed Security Service Provider (MSSP). Let’s explore these terms for a better understanding of what each provides.

Managed Detection & Response

MDR services perform proactive 24/7 monitoring of threat-facing security technologies and detect, investigate, and respond to attacks.

Managed Threat Hunting

MTH takes a proactive approach that goes beyond the tool alerting to detect attacks using attackers TTPs, IoAs and attacker hypothesis based on the security telemetry being collected by security technologies. This helps you in identifying attacks that are currently active and even compromise assessment.

Managed Security Service Provider

MSSPs mostly focus on the upkeep of the security technologies like firewalls, email gateways, web gateways, EDR, SIEM, and others. They provide basic alert triaging and alert an organization of a possible attack but don’t take action or consolidate various alerts into an incident. MSSP focuses on Security Tool management.

Given these differentiations, it is important to understand the organization’s context and requirements to identify the right kind of service. The following provides a helpful framework.

People and Process are essential for effective security operations and organizations should be using the framework above to understand which option is the best fit for their organization, given the context. Although the framework highlights different services such as MSSP, MDR, and MTH, these services can come from the same or multiple providers.

Type 1 Organizations

These are small and midsize organizations for which cybersecurity decisions are mostly based on compliance requirements. They also generally don’t have dedicated cybersecurity teams, heavily outsource security functions to managed security service providers (MSSP) and only have a security leader (shared capacity) to make cybersecurity decisions.

However, as the data and attack statistics suggests, ransomware threats are more actively targeting midsized organizations as they see them as low hanging fruit. A ransomware attack can result in significant business loss, and even lead to closure of the business. Hence, Type 1 organizations should look beyond just security technology management and actively invest in continuous monitoring for threats and alerts. As it is difficult for Type 1 organizations to build their own team, they should actively look at Managed Detection and Response providers (MDR) to add Security Operations Center Capabilities.

Type 2 Organizations

Type 2 organizations are mainstream and have mid to high maturity in cybersecurity. They are more likely to have a SOC in-house with some functions outsourced to an MSSP. However, the existing SOC may not be 24/7 and more likely to be focusing on compliance requirements and basic alert monitoring.

Because of their limited SOC capabilities, type 2 organizations should look at augmenting SOC capabilities with an MDR service to make the existing SOC 24/7 and add threat detection and response capabilities.

Type 3 Organizations

These are highly mature organizations and run a 24/7 SOC with dedicated analysts for threat detection and response use cases. However, because of the overwhelming nature of the SOC, scaling the SOC operations becomes difficult.

Type 2 organizations can also find it challenging to operationalise and perform continuous threat hunting. Thus, these organizations need help with MDR providers to scale their SOC operations, Managed Threat Hunting for continuous threat hunting across their environment and continuous compromise assessment. These services can provide assistance in SOC to type 3 organizations.

Incident Response Retainers (IRR)

Irrespective of Type 1, 2 and 3 organizations, every organization needs an incident response service on a retainer to help them manage a crisis situation. IRRs are available in Prepaid and Zero Dollar agreements. Though it is advisable to have a Prepaid Retainer agreement in place, organizations with limited budgets should at least have a ‘Zero Dollar’ retainer agreement to save crucial time in the event of a security incident.

It is worth noting that when buying Managed Services (MDT,MTH, etc.) from a technology vendor such as EDR, the services should be used to augment the product offerings and not complete the product offerings.

It is recommended that MSSP and MDR are from two separate service providers to avoid conflict of interest as these services focus on different objectives: MSSP provide security management and monitoring and MDR specialize in threat detection and response.

The IRR agreement can be sourced through a current MSSP/MDR provider as well given that they have expertise and the required credentials in the IR domain.

Security incidents are a matter of when and not if. When a security incident occurs, the organization’s preparedness will help prevent the incident turning into a crisis. Incident Response Retainers have evolved from just being reactive to being proactive and should also be used before an incident to prepare better for a security incident to reduce the time to detect, contain and recover from an attack.

Conclusion

It is no news that threats and their tactics, techniques and procedures are evolving fast and becoming more sophisticated.

Despite rapid advances in AI-assisted security technology, it remains the case that no technology can guarantee to detect 100% of attacks. An effective cybersecurity approach requires a human-machine teaming where the sum becomes greater than the parts.

This additional cybersecurity value will add more business value in terms of less business disruption, less compliance and regulatory fines, higher customer confidence and lower TCO of the cybersecurity investment.

SentinelOne offers robust Managed Detection & Response (MDR), Managed Threat Hunting (MTH), Compromise Assessment and Incident Response Services. To learn more contact us or visit SentinelOne Global Services.