Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

6/23/2020
02:00 PM
Raj Mallempati
Raj Mallempati
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Back to Basics with Cloud Permissions Management

By using the AAA permissions management framework for cloud operations, organizations can address authentication, authorization, and auditing.

As I spend more time discussing the cloud with security customers and partners, it has made me think a lot about how the industry is continuously evolving to figure out new ways to layer on security and complexity while at the same time neglecting some of the basics.

A primary example is permissions management for identities and resources accessing cloud (private, public, or hybrid) infrastructure.One of the frequently quoted frameworks in security is a relatively simple AAA framework: authentication, authorization, and auditing. This framework is intended to help people understand the nuances of identity management and think specifically about how to reduce or mitigate risk by minimizing the attack surface. 

Specifically, enterprises need to manage all identities (human or nonhuman) based on what they are permitted to access (through authentication — e.g., passwords) as well as what tasks these identities can perform through authorization and privilege management. The framework also defines the actions performed by the identities through auditing and logs.

Although the threat vectors facing organizations have evolved significantly and increased in sophistication, I still believe this framework is easy to understand and deploy; it's also still essential to use as the foundation for enterprises to build their cloud security strategy.

Here's how this might work in a cloud-first or cloud-centric organization.

Authentication? Or Zero Trust?
With the continued adoption of cloud infrastructure, cloud applications, and mobile devices and applications, the concept of perimeter-based security for authentication is inadequate. In fact, I believe it's a very arcane way of looking at authentication. Over the past 10 years, this space has seen a much-needed shift in thinking and strategy led by vendors like Okta, Ping Identity, and Netskope. Customers are looking for an authentication solution that works across their existing data center infrastructure and their cloud infrastructure. The new authentication architecture and strategy is intended to focus on either "trust but verify" or "verify but never trust" in all authentication processes.

In the end, this just means more rigorous and comprehensive authentication that requires a fundamental rearchitecture of existing networks for organizations. This can take time to implement because there are a lot more basics to get right in authentication. First, multifactor authentication is no longer negotiable —  it needs to be implemented for all cloud-native services and infrastructure, so stop delaying and get it implemented for all your identities.

Right-Sizing Authorization
Authorization is the most overlooked permission management control in the security organization. This tends to be the case across all companies because in a cloud world, basic visibility requires deep knowledge on the underlying infrastructure, and there are tens of thousands of permissions and resources to manage. Imagine if every cloud infrastructure identity, human or machine, had the same ability to perform tasks and access to the same information, systems, and data.

Authorization is essential to restrict the actions of identities to only what they absolutely need to perform, thereby reducing unwanted, avoidable risk significantly. It should form the basis for every security program but can be daunting in complexity.

The key to getting the basics right is right-sizing permissions and focusing on the permissions that an identity requires based on what they require to do their job on a daily basis compared with identifying all the permissions they might possibly need. Augment this with delivering any additional permissions or privileges on demand when and only when identities need them. This delivers a comprehensive authorization model based on permissions used as opposed to permissions granted.

Auditing: Who Did What?
It sounds simple to most people, but it is surprisingly complicated and difficult to determine all the activities on which identities have executed. This is especially true when you consider the thousands of resources that these identities can access across multiple cloud infrastructure platforms.

It is essential to have auditing capabilities as a key building block to a robust cloud infrastructure security framework, however difficult or complex this may be. Knowing what resources are being accessed or attempted to be accessed is not enough. Knowing what every identity is doing or attempting to do inside your cloud infrastructure resources is mandatory for detecting threats and for robust incident response. This is also critical for continuous security and compliance controls across all your cloud infrastructure platforms.

The move to the cloud is daunting and made even more complex by the cloud infrastructure providers themselves. Each provider's services offer a bewildering number of options that all come with their own set of default permissions. This complexity is further compounded by the use multiple clouds. As this shift to the cloud occurs, and access control is the only thing preventing someone from accessing sensitive information on an S3 bucket or EC2 instance, pursuing a back-to-basics approach for authentication, authorization, and audit controls is important to protect data at scale.

Related Content:

 
 
 
 
 
Learn from industry experts in a setting that is conducive to interaction and conversation about how to prepare for that "really bad day" in cybersecurity. Click for more information and to register for this On-Demand event. 
 

Raj Mallempati is Chief Operating Officer at CloudKnox Security, where he is responsible for CloudKnox's overall business and go-to-market strategies. Prior to joining CloudKnox, Raj was most recently the Senior Vice President of Marketing at Malwarebytes. Raj has also held ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I like the old version of Google assistant much better.
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8567
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver Vault Plugin prior to v0.0.6, Azure Plugin prior to v0.0.10, and GCP Plugin prior to v0.2.0 allow an attacker who can create specially-crafted SecretProviderClass objects to write to arbitrary file paths on the host filesystem, including /var/lib/kubelet/pods.
CVE-2020-8568
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver versions v0.0.15 and v0.0.16 allow an attacker who can modify a SecretProviderClassPodStatus/Status resource the ability to write content to the host filesystem and sync file contents to Kubernetes Secrets. This includes paths under var/lib/kubelet/pods that conta...
CVE-2020-8569
PUBLISHED: 2021-01-21
Kubernetes CSI snapshot-controller prior to v2.1.3 and v3.0.2 could panic when processing a VolumeSnapshot custom resource when: - The VolumeSnapshot referenced a non-existing PersistentVolumeClaim and the VolumeSnapshot did not reference any VolumeSnapshotClass. - The snapshot-controller crashes, ...
CVE-2020-8570
PUBLISHED: 2021-01-21
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executi...
CVE-2020-8554
PUBLISHED: 2021-01-21
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typicall...