Preventing Insider Threats In Kubernetes Clusters

Brought to you by Gilad David Maayan  

What Is an Insider Threat?

An insider threat has authorized access to the organization’s data, systems, and networks and can potentially use this access to wittingly or unwittingly cause harm to the organization. An insider can be a current or ex-employee, a business partner, a contractor, or any part with authorized access. 

An insider threat can misuse their access to negatively affect the confidentiality, integrity, or availability (CIA) of an organization’s information systems or data. Examples of insider threat attacks include sabotage, data theft, espionage, competitive advantage, and fraud.

An insider might act alone or with other accomplices. They can launch attacks intentionally or might not even be aware they are assisting a threat actor. To protect against insider threats, organizations must determine what constitutes normal employee behaviors and ensure employees and other parties with access understand how threat actors can use them to obtain information.

Why Are Insider Threats Dangerous?

Most organizations struggle to detect insider threats, even those employing advanced security threat detection solutions. Since most insider threats do not reveal themselves until the attack begins and they look like legitimate users, it can be difficult to identify them. As a result, they might perform malicious activities for weeks or even months without being detected.

Insider threats with authenticated access to sensitive information can avoid detection until the data is gone. Depending on the type of data stolen, the organization might face compliance violations that result in fines and loss of revenue, loss of valuable trade secrets, and disruptions to business operations. 

According to the Ponemon Institute’s 2022 Insider Threats Report, reported incidents of insider threats have seen a 44% increase over the past two years. The reported cost per incident increased to $15.4 million annually.

Additionally, the report indicated the time it took to contain an insider threat incident increased from 77 to 85 days. As a result, the biggest share of costs organizations reported in connection to insider threats was the cost of containing threats.

Technical Indicators of Insider Threats

Malicious insider threats cannot be adequately detected by traditional security tools, which are based on pattern matching with rules and thresholds. Anyone familiar with an organization’s security settings, policies, and procedures can bypass these protections.

Modern insider threat detection systems combine artificial intelligence (AI) and analytics to capture data from across the enterprise, in order to baseline all user and device activity. They use this data to assign custom risk scores to each user and device. This provides additional context when cybersecurity teams review alerts on their systems, making it possible to proactively identify unusual activity that could indicate insider threats.

AI-based insider threat detection can identify anomalies like:

• Access to networks, systems, or assets at unusual times.

• Unexpected or unexplained spikes in network traffic, indicating that users are downloading or copying large volumes of data.

• Users requesting access to applications, data or documents not required for their role.

• Access to certain combinations of documents or data that together could indicate malicious activity.

• Use of personal devices such as laptops, cellphones, and USB drives without approval.

There are other tell-tale signs of active insider threats:

• Backdoors discovered in the network that could allow unauthorized users remote access.

• Use of hardware or software that has not been approved, installed, or monitored by your IT or security team.

• Attempts to manually disable security tools or change their settings.

Three Ways to Secure Kubernetes from Insider Threats

Role-Based Access Control (RBAC):    Strategies for mitigating threats to containers are different from securing physical servers. However, both traditional servers and Kubernetes clusters can benefit from role-based access control (RBAC). 

RBAC is a way for enterprises to restrict network access by assigning individual users to roles. RBAC ensures that employees only have access to the information and systems they need to do their jobs. An employee's role in the organization determines the privileges an individual has and prevents employees from accessing sensitive information or performing higher-level tasks than their job requires.

In the role-based access control model, a role is based on several factors such as authorization, responsibility, and ability to perform tasks. Thus, companies can specify whether users are end users, administrators, or professional users. Also, access to computer resources may be restricted to certain actions, such as viewing, creating, or modifying files.

Logical Isolation with Namespaces:    Applications deployed on clusters must use namespaces. This is a logical separation of resources to which administrators can assign security policies. Namespaces can have separate quotas and resource limits for pods running within them. Originally intended for environments with users across multiple projects or teams, using namespaces is now considered a security best practice for any cluster.

By default, nothing in Kubernetes prevents two different containers from communicating with each other. However, a simple way to restrict communication is by separating them into different namespaces. 

NetworkPolicy:    A NetworkPolicy is a resource that defines how pods (logical groups of one or multiple containers with shared network and storage resources) communicate with each other and with other endpoints.

By default, Kubernetes will allow traffic from all sources. NetworkPolicy is a software firewall between pods running in a Kubernetes cluster. Admins can create a secure default policy for a namespace, using a NetworkPolicy that applies to all pods and does not allow inbound or outbound traffic to those pods by default.

Administrators can then configure specific pods that are allowed to connect to each other. These policies are highly customizable, allowing admins to specify the namespaces they can communicate with and select the port numbers to apply to each policy.

NetworkPolicy requires a network backend to support configuration (such as Canal or Calico).

Conclusion

In this article, I explained the basics of insider threats and how to prevent it in Kubernetes:

Role-Based Access Control - RBAC is a way for enterprises to restrict network access by assigning individual users to roles.

Logical Isolation with Namespaces - You can restrict communication by separating them into different namespaces.

The NetworkPolicy Resource - A NetworkPolicy allows administrators to specify the namespaces they can communicate with and select the port numbers to apply to each policy.

I hope this will be useful as you secure your Kubernetes clusters from inside threats.

Gilad David Maayan is a technology writer producing thought leadership content that elucidates technical solutions for developers and IT leadership.                       Image: Unsplash

You Might Also Read:  

Using SAST To Prevent Zero Day Vulnerabilities: