As you check into any hotel, a concierge will hand you a keycard. The card gives you access to your room, the fitness center and the pool during operating hours, and opens locked, non-main entrances to the building. Members of the hotel’s housekeeping team have keycards that access each guest room and supply storage areas. Hospitality staff get access to luggage storage, culinary staff to the kitchen. And when keycards are used, the hotel’s security system logs who entered a room and what time they entered. It seems like common sense. People are granted access to only the rooms they need to enter to complete their tasks. Each person has a unique identity in the system — in the hotel it’s the keycard, and in your network, it’s the user listed in your unified identity management system. This is zero-trust architecture, and it all starts with identity.
By Matt Graves, VP of Information Security Practice, MajorKey Technologies
With zero trust methodology that starts with identity in mind, users get the minimal access they need and no more. Everything is tracked through the system, so it’s known which individual is present, what they have access to, and when they used that access.
What appears as common sense isn’t the norm. And that’s because for years, the nature of networks and how employees worked meant that security with perimeter defenses and passwords provided an imperfect but passable solution.
The nature of work today can’t rely on an assumption that each user, once inside a network, can be implicitly trusted. People enter the network from a wide variety of endpoints because of the rise of mobile devices, remote work, and cloud-based applications. Network users are no longer only employees, but customers, outside vendors, and contractors.
Default enterprise directories, like Active Directory, can’t account for all these different users, tracking who is where in the system, granting access as needed and tracking how that access is used. And the most well-known form of computer security — the password — not only isn’t enough to secure your infrastructure, but actually makes getting work done more difficult.
The Perils of Passwords
The top hacking vector in breaches last year, according to the An alarming three out of four IT decision makers whose organization suffered breaches said it involved privileged access credential abuse. According to a Centrify report, 65% said they share root or privileged access to systems and data at least somewhat often.
These over sharers aren’t malicious actors, but they are slowed by a system that creates roadblocks in their work. So even though they know it may not be safe or secure, they share access credentials as a shortcut.
The issue with passwords is that you don’t actually know the identity of the person using a password to access a network resource. Whether the password was shared or stolen, it can’t represent an implicit confirmation of identity.
So instead of passwords, zero trust relies on identity established in a unified user directory. With identities established for each user on the network, they sign in once — what’s known as single sign-on (SSO) — and have secure access to the tools, applications and resources they need.
This not only reduces attack surfaces by reducing the amount of passwords used to access an organization’s resources, but increases productivity as well. A Health Informatics Journal research paper cited a study at a midsized integrated delivery health network in Kentucky comprising five health systems. The study found that the time and dollars spent within one of their five emergency departments utilizing traditional login methods and application timeouts to access an electronic tracking board required more than 14 hours of accumulated lost user productivity during the course an 8-hour shift, equating to $588,600 over the course of a year.
Having a unified user directory and SSO in place, though, is only the first step in creating a zero-trust architecture, because it’s not just about establishing identity (this of course is the foundation), but continuously confirming it. This is where your context- and risk-based policies come into play, allowing access when necessary and requiring secondary confirmation of identity when a user’s actions raise red flags.
Context is King
Back to our hotel analogy, let’s say guests can use their keycards to access the pool area from 7 a.m. to 7 p.m. each day. However, staff need to access the pool during off-hours for maintenance and cleaning, so their keycards can open doors to the pool area 24/7, but during those off-hours, they are prompted for a one-time code texted to their phone.
This is like having a context-based policy. It’s utilizing user identity in combination with a behavioral context to determine whether to trigger multi-factor authentication (MFA). These triggers have become more commonplace for customers, such as when using a bank’s website to access account information from a new, unrecognized device.
In a network environment, these contextual cues can account for the time a resource is being accessed, just like the hotel pool access example, or other factors like geolocation or device. If employees use both work-issued and personal devices to access work resources, a policy could require MFA for any attempts to access a normally allowed resource from a personal device as an additional security measure.
Team members who log in from a new geolocation could be another trigger. If a company’s team member who regularly travels between offices located in Boston and Chicago, both those geolocations could be allowed automatically, but if they sign on from Jacksonville, an MFA request could be triggered. These policies can all be tailored to best meet an organization’s needs based on location and time of day.
These context-based access policies are rapidly changing security standards. Okta surveyed 500 security leaders and found that in 2019, 55% of those leaders listed the network as a top factor for context-based access decisions. A year later, that figure dropped to 20%.
Risk-based policies add an additional layer of security for particularly sensitive data or resources. For example, financial information or data that is subject to federal regulations like HIPAA can be set to always require MFA. And instead of having that verification serving as a one-time check, your system can assert levels of risk tolerance and trigger additional authentication requests based on new contextual information. Identity verification no longer becomes one-and-done, but an ongoing process, powered by a robust identity management system and the clear and concise policies created.
Creating this system sounds complicated, but one of the greatest benefits of an identity-based system developed on the zero trust methodology is that when your architecture is in place, it can actually make navigating the network easier for your users.
Stronger Security Behind the Scenes
Zero trust methodology and architecture offers enterprises intuitive and adaptive security. It simplifies user experiences, while keeping the security running and monitoring actions behind the scenes. It also simplifies your IT management.
A Gigamon survey of senior IT decision makers found that 87% said productivity either had or would have improved since the implementation of zero trust. Of those decision makers, 43% said the increased productivity came from the system running faster, 35% said due to fewer security breaches, and 23% because of reduced downtime.
It begins at onboarding. Let’s say a new sales professional is onboarded and has a user account created, which gives them on day one access to all the resources they need. The role-based security simplifies access for them and eliminates the need for them to filter out what they don’t need. If this employee switches departments, their sales department related access is removed and new access privileges granted by the role change. This is all handled in the identity management system.
A formal offboarding process that ensures access is revoked is also critical to maintain the security of your systems. An Intermedia study found that 89% of those surveyed still had privileged access after leaving their job to sensitive company applications like Salesforce, PayPal, email and SharePoint. Of those surveyed, 45% retained access to confidential data. In zero-trust architecture, when an employee leaves, their user account is maintained for archival logging of important data and history, but their access is revoked through the identity provisioning system.
Ultimately, it all comes down to the three fundamental questions of identity: who is in your system, what they have access to and what are they doing with that access. Zero trust methodology is founded on these three key questions, and the answer is identity management. Without that, your enterprise remains at-risk, your customers and partners frustrated, and your staff stuck in an inefficient system. With identity management, it’s as simple as checking into your favorite hotel.
About the Author
Matt Graves is a Vice President and Information Security Practice Lead at MajorKey Technologies. An experienced information security and cloud architect, Matt is responsible for IAM solutions development across the MajorKey client community. He advises clients on how to evolve their information security strategies and solutions in ways that align with their business objectives and leads solutions architecture to ensure effective delivery. Prior to his current role, Matt held senior operational positions within Highmetric, helping clients implement service management processes and solutions. An expert with multi-cloud platforms, Matt joined the company from the healthcare insurance industry.
Disclaimer
Views expressed in this article are personal. The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.
