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.

Attacks/Breaches

1/28/2019
09:00 AM
Sharon Besser, CSO & VP of Products, Guardicore
Sharon Besser, CSO & VP of Products, Guardicore
Sponsored Article
100%
0%

Racing to Zero Trust: 4 Key Principles

Trust nothing, always verify. Grant no access without explicit permission. These mantras are the heart of the zero trust framework. The challenge is in how you implement them.

Here’s a quick question for you: When will your organization experience a serious security breach? If your answer to the question is "never," you are probably wrong. No matter how much artificial intelligence, machine learning, and automation your security systems use, there are chances that something bad will happen.

In my opinion, it’s the human factor that is the main reason organizations can’t achieve a perfect security score. A second reason, to reference "Murphy's Law," is that if anything can go wrong, it will … or as my kids simply say, "It happens." Another reason, though less important, is the lack of adequate resources and budget.

When I started writing this article, I was in the middle of my company’s annual ISO 27001 audit and wanted to share my experience as a security officer trying to implement a zero trust security program. As I started to develop the story, I considered the controversial title of "No Chance for Zero Trust - Why Theory Doesn't Work in the Real World and What Comes Closest." Then, while I was trying to express my thoughts about what we, security practitioners, should do in order to secure our networks I realized how difficult a zero trust framework is to implement, and why it is such an important discussion.

A Brief History
The zero trust concept was developed by Forrester Research about nine years ago and started to gain momentum a couple of years later. At the time, it was a revolutionary idea but gained awareness due to the growing number of high-profile data breaches. Today, while many people talk about zero trust, few know what it means and even fewer know how to implement it.

Significant market attention and hype around zero trust has developed over the past several years. In a recent public Gartner webinar on Continuous Adaptive Risk and Trust Assessment (CARTA), 70% of attendees said they had heard of zero trust. However, 23% of these attendees reported that they weren’t quite sure what the term means. The concept of zero trust is compelling but remains largely conceptual for most enterprises. Only 8% of the respondents had a specific zero trust networking project planned for 2019.

In its essence, zero trust is a security model developed to address the shortcomings of other models by suggesting that security should be implemented in a way that will allow an organization to define and enforce a policy for all users, workloads, assets, applications, data and the communications traffic between them, regardless of location.

Trust nothing, always verify. Grant no access without explicit permission. These seem to be straightforward mantras that translate into crucial tasks at the heart of the zero trust model. Yet, implementing these aphorisms successfully is difficult. For a start, one should define an access rights model, then decide how to implement it, including a method to change permissions and revoke them when an employee is changing his/her role or leaving the company.

Assume Access
In our implementation of the zero trust security model, we assume that an attacker can gain access to the network or is already inside. He or she might have managed to get their hands on employee credentials so that once inside, the attacker has access to all the resources that the network provides. Consequently, we also need to define the methods to identify, contain and respond.

Our zero trust model has four high-level principles. Other models might have a different number but they are all very similar:

  1. Adopt a least privilege access strategy. Assign access permissions to resources based on a well-defined need. This is true for users, applications, and the data itself. Continuously review the need for access. I recommend assigning group permissions - adding and removing individual assets, applications or data elements from the group in order to change its privilege.
  2. Provide secure access to resources regardless of location of both the resource and the purpose or person it is serving. At Guardicore, for example, we require the same level of authentication inside and outside the LAN. Services that must be provided from our LAN will not be available via VPN.
  3. Enforce access control at all levels. Our implementation requires more than a single authentication method per resource including both the network and application.
  4. Audit everything. We use the term audit to highlight the fact that we go one step further and review the logs. We manually collect logs and use bots to generate alerts. We are proudest of our "nightwatch" bot which generates a phone call to the person on duty and will read the alert to make sure this person is actually awake.

To implement these principles, your organization needs to be mature enough and able to put into practice a least-privilege model, and to be able to identify all resources across all environments (users, their devices, workloads across all environments, applications and data). You also must have a method to classify your critical applications and data. This is a big ask for many companies, part of what makes the entire process difficult. I suggest starting with mapping of resources first, and then moving on to create the access model.

Creating the policies will also be tricky. I recommend that companies first define the policies on paper as part of a wide organizational policy, and only then decide how to enforce these policies.

At Guardicore, I’m lucky to be in a position where I can influence the direction our micro-segmentation solution takes in order to solve specific challenges. Today (without Guardicore), you’ll probably need more than a single product to enforce your policies. My advice is to stick to your plan: once you have decided about a policy, look for the best tool that will allow you to enforce it. Don’t try to define a policy based on whatever product you might have been using.

Implementing zero trust is a thought process and a challenge worth pursuing. Although every organization is different and each one will have unique requirements, the principles remain the same for everyone, and are well worth the effort.

About the Author
Sharon Besser, CSO & VP of Products, Guardicore

Sharon Besser is chief security officer and vice president of products at Guardicore, an innovator in data center and cloud security focused on delivering more accurate and effective ways to protect critical applications from compromise through unmatched visibility, micro-segmentation and real-time breach detection and response.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-10133
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.
CVE-2019-10134
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The size of users' private file uploads via email were not correctly checked, so their quota allowance could be exceeded.
CVE-2019-10154
PUBLISHED: 2019-06-26
A flaw was found in Moodle before versions 3.7, 3.6.4. A web service fetching messages was not restricted to the current user's conversations.
CVE-2019-9039
PUBLISHED: 2019-06-26
The Couchbase Sync Gateway 2.1.2 in combination with a Couchbase Server is affected by a previously undisclosed N1QL-injection vulnerability in the REST API. An attacker with access to the public REST API can insert additional N1QL statements through the parameters ?startkey? and ?endkey? of the ?_a...
CVE-2018-20846
PUBLISHED: 2019-06-26
Out-of-bounds accesses in the functions pi_next_lrcp, pi_next_rlcp, pi_next_rpcl, pi_next_pcrl, pi_next_rpcl, and pi_next_cprl in openmj2/pi.c in OpenJPEG through 2.3.0 allow remote attackers to cause a denial of service (application crash).