Identity Security
Identity security has pushed authentication to a new, more secure landscape, reacting to improved technologies and sophisticated attacks. The need for more accessible and secure authentication has led to the wide adoption of zero trust identity management zero trust authentication technologies like risk-based authentication (RBA), fast identity online (FIDO2), and just-in-time (JIT) techniques.
If you examine our identities, applications, and devices, they are in the crosshairs of bad actors, making them probable threat vectors. In addition, we are challenged by the sophistication of our infrastructure, which increases our attack surface and creates gaps in our visibility. Controlling access and the holes created by complexity is the basis of all healthy security. So firstly, before we jump into the zero trust authentication and components needed to adopt zero trust identity management, let’s start with the basics of identity security.
Before you proceed, you may find the following posts helpful
Zero Trust Identity |
|
- A key point: Back to basics with identity security
In its simplest terms, an identity is an account or a persona that can interact with a system or application. And we can have different types of identities.
- Human Identity: Human identities are the most common. These identities could be users, customers, or other stakeholders requiring various access levels to computers, networks, cloud applications, smartphones, routers, servers, controllers, sensors, etc.
- Non-Human: Identities are also non-human as operations automate more processes. These types of identities are seen in more recent cloud-native environments. Applications and microservices use these machine identities for API access, communication, and the CI/CD tools.
Example: Identity Security: The Workflow
The concept of identity security is straightforward and follows a standard workflow that can be understood and secured. First, a user logs into their employee desktop and is authenticated as an individual who should have access to this network segment. This is the authentication stage.
They have appropriate permissions assigned so they can navigate to the required assets (such as an application or file servers) and are authorized as someone who should have access to this application. This is the authorization stage.
As they move across the network to carry out their day-to-day duties, all of this movement is logged, and all-access information is captured and analyzed for auditing purposes. Anything outside of normal behavior is flagged. Splunk UEBA has good features here.
- Identity Security: Stage of Authentication
Authentication: You need to authenticate every human and non-human identity accurately. After an identity is authenticated so that they confirm who they are, it only gets a free one for some to access the system with impunity.
- Identity Security: Stage of Re Authentication
Identities should be re-authenticated if the system detects suspicious behavior or before completing tasks and accessing data that is deemed to be highly sensitive. So if we have an identity that acts outside of normal baseline behavior, they would be required to re-authenticate.
- Identity Security: Stage of Authorization
Then we need to move to the authorization: It’s necessary to authorize the user to ensure they’re allowed access to the asset only when required and only with the permissions they need to do their job. So we have authorized each identity on the network with the proper permissions so they can access what they need and not more.
- Identity Security: Stage of Access
Then we look into the Access: Provide access for that identity to authorized assets in a structured manner. How can the appropriate access be given to the person/user/device/bot/script/account and nothing more? Following the practices of zero trust identity management and least privilege. Ideally, access is granted to microsegments instead of significant VLANs based on traditional zone-based networking.
- Identity Security: Stage of Audit
Finally, Audit: All identity activity must be audited or accounted for. Auditing allows insight and evidence that Identity Security policies are working as intended. How do you monitor the activities of identities? How do you reconstruct and analyze the actions an identity performed?
An auditing capability ensures visibility into activities performed by an identity, provides context for the usage and behavior of the identity, and enables analytics that identifies risk and provides insights to make smarter decisions about access.
Starting Zero Trust Identity Management
Now we have an identity as the new perimeter compounded by identity being the new target. Any identity is a target. Looking at the modern enterprise landscape, it’s easy to see why. Every employee has multiple identities and uses several devices.
What makes this worse is that security teams’ primary issue is that identity-driven attacks are hard to detect. For example, how do you know if a bad actor or a sys admin uses the privilege controls? As a result, security teams must find a reliable way to monitor suspicious user behavior to determine the signs of compromised identities.
We now have identity sprawl which may be acceptable if every one of those identities only has user access. However, they don’t, and they most likely have privileged access. All these widen the attack surface by creating additional human and machine identities that can gain privileged access under certain conditions. All of which will establish new pathways for bad actors.
So we must adopt a different approach to secure our identities regardless of where they may be. Here we can look for a zero trust identity management approach based on identity security. Next, I’d like to talk about the common challenges you may encounter when adopting identity security.
Common challenges to zero trust identity management
- Challenge: Zero trust identity management and privilege credential compromise
Current environments may result in anonymous access to privileged accounts and sensitive information. Unsurprisingly, 80% of breaches start with compromised privilege credentials. If left unsecured, attackers can compromise these valuable secrets and credentials to gain possession of privileged accounts and perform advanced attacks or use them to exfiltrate data.
- Challenge: Zero trust identity management and exploiting privileged accounts
So we have two types of bad actors. First, there are external attackers and malicious insiders that can exploit privileged accounts to orchestrate a variety of attacks. Privileged accounts are used in nearly every cyber attack. With privileged access, bad actors can disable systems, take control of IT infrastructure and gain access to sensitive data. So we face several challenges when securing identities, namely protecting, controlling, and monitoring privileged access.
- Challenge: Zero trust identity management and lateral movements
Lateral movements will happen. A bad actor has to move throughout the network. They will never land directly on a database or important file server. The initial entry point into the network could be an unsecured IoT device, which does not hold sensitive data. As a result, bad actors need to pivot across the network.
They will laterally move throughout the network with these privileged accounts, looking for high-value targets and then using elevated privileges to steal confidential information and exfiltrate data. There are many ways to exfiltrate data, with DNS being a common vector that often goes unmonitored. So how do you know a bad actor is moving laterally with admin credentials using admin tools built into standard Windows desktops?
- Challenge: Zero trust identity management and distributed attacks
These attacks are distributed, and there will be many dots to connect to understand threats on the network. Could you just look at Ransomware? Enrolling the malware needs elevated privilege, and it’s better to detect this before the encryption starts. Partial encryption performed by some of the Ransomware families is fast. Once encryption starts, it’s games over. So you need to detect this early in the kill chain in the detect phase.
So knowing who accesses the data, ensuring the users they claim to be, and operating on the trusted endpoint that meets compliance is the best way to approach zero trust authentication. So there are plenty of ways to authenticate to the network; many claim password-based authentication is weak.
The core of identity security is understanding the password issue is that they can get phished; essentially, using a password is sharing. So we need to add multifactor authentication (MFA). MFA gives a big lift but needs to be done well. You can get breached even if you have an MFA solution in place.
- A key point: Knowledge check for multi-factor authentication (MFA)
More than simple passwords are needed for healthy security. A password is a single authentication factor – anyone with it can use it. No matter how strong it is, keeping information private is useless if lost or stolen. You must use a different secondary authentication factor to secure your data appropriately.
Here’s a quick breakdown:
•Two-factor authentication: use of two-factor classes to provide authentication. This is also represented as ‘2FA’ and ‘TFA.’
•Multi-factor authentication: use of two or more factor classes to provide authentication. This is also represented as ‘MFA.’
•Two-step verification: use of two independent steps for authentication that might not involve two separate factor classes. This is also represented as ‘2SV’.
•Strong authentication: authentication beyond simply a password. It may be represented by the usage of ‘security questions’ or layered security like two-factor authentication.
The Move For Zero Trust Authentication
No MFA solution is an island. Every MFA solution is just one part of multiple components, relationships, and dependencies. Each piece is an additional area where an exploitable vulnerability can occur.
Essentially, any component in the MFA’s life cycle, from provisioning to de-provisioning and everything in between, is subject to exploitable vulnerabilities and hacking. And like the proverbial chain, it’s only the most robust as its weakest link.
- The need for zero trust authentication: Two or More Hacking Methods Used
Many MFA attacks use two or more of the leading hacking methods. Often social engineering is used to start the attack and get the victim to click on a link or to activate a process, which then uses one of the other methods to accomplish the necessary technical hacking.
For example, a user gets a phishing email directing them to a fake website, which accomplishes a man-in-the-middle (MitM) attack and steals credential secrets. Or physical theft of a hardware token is performed, and then the token is forensically examined to find the stored authentication secrets. MFA hacking requires using two or all of these main hacking methods.
So you can’t rely on MFA alone; you need to validate privileged users with context-aware Adaptive Multifactor Authentication and secure access to business resources with Single Sign-On. Unfortunately, credential theft remains the No. 1 area of risk. And bad actors are getting better at bypassing MFA using a variety of vectors and techniques.
For example, a bad actor can be tricked into accepting a push notification to their smartphone to grant access in the context of getting admission. So you are still acceptable to man-in-the-middle attacks. This is why MFA and IDP vendors introduce risk-based authentication and step-up authentication. These techniques limited the attack surface, which we will talk about soon.
Critical considerations for zero trust authentication
Think like a bad actor.
By thinking like a bad actor, we can attempt to identify suspicious activity, restrict lateral movement, and contain threats. Try envisioning what you would look for if you were a bad external actor or malicious insider. For example, are you looking to steal sensitive data to sell it to competitors, or are you looking to start Ransomware binaries or use your infrastructure for illicit crypto mining?
Attacks with happen
The harsh reality is that attacks will happen, and you can only partially secure some of their applications and infrastructure wherever they exist. So it’s not a matter of ‘if’ but a concern of “when.” Protection from all the various methods that attackers use is virtually impossible, and there will occasionally be day 0 attacks. So, they will get in eventually; It’s all about what they can do once they are in.
The first action is: Protect Identities.
Therefore, the very first thing you must do is protect their identities and prioritize what matters most – privileged access. Infrastructure and critical data are only fully protected if privileged accounts, credentials, and secrets are secured and protected.
The bad actor needs privileged access.
We know that about 80% of breaches tied to hacking involve using lost or stolen credentials. Compromised identities are the common denominator in virtually every severe attack. The reason is apparent:
The bad actor needs privileged access to access network infrastructure and steals data. However, without privileged access, an attacker is severely limited in what they can do. Furthermore, without privileged access, they may be unable to pivot from one machine to another. And the chances of landing on a high-value target are doubtful.
The malware requires admin access.
The malware used to pivot and requires admin access to gain persistence; privileged access without vigilant management creates an ever-growing attack surface around privileged accounts.
Adopting Zero Trust Authentication
Zero trust authentication: Technology with Fast Identity Online (FIDO2)
So where can you start identity security with all of this? Firstly, we can look at a zero trust authentication protocol. So we need an authentication protocol that can be phishing resistant. This is FIDO2, known as Fast Identity Online (FIDO2), built on two protocols that effectively remove any blind protocols. FIDO authentication Fast Identity Online (FIDO) is a challenge-response protocol that uses public-key cryptography. Rather than using certificates, it manages keys automatically and beneath the covers.
The FIDO2 standards
FIDO2 uses two standards. The Client to Authenticator Protocol (CTAP) describes how a browser or operating system establishes a connection to a FIDO authenticator. The WebAuthn protocol is built into browsers and provides an API that JavaScript from a web service can use to register a FIDO key, send a challenge to the authenticator, and receive a response to the challenge.
So there is an application the user wants to go to, and then we have the client that is often the system’s browser, but it can be an application that can speak and understands WebAuthn. FIDO provides a secure and convenient way to authenticate users without using passwords, SMS codes, or TOTP authenticator applications. Modern computers and smartphones and most mainstream browsers understand FIDO natively.
FIDO2 addresses phishing by cryptographically proving that the end-user has a physical position over the authentication. And there are two types of authenticators. So we can have a roaming authenticator such as a USB device. These need to be certified FIDO2 vendors.
The other is a platform authenticator such as Touch ID or Windows Hello. While roaming authenticators are available, for most use cases, platform authenticators are sufficient. This makes FIDO an easy, inexpensive way for people to authenticate. The biggest impediment to its widespread use is that people won’t believe something so easy is secure.
Zero trust authentication: Technology with risk-based authentication
Risk is not a static attribute, and it needs to be re-calculated and re-evaluated so you can make intelligent decisions for step-up and user authentication. We have Cisco DUO that reacts to risk-based signals at the point of authentication.
So these risk signals are processed in real-time to detect signs of known account takeout signals. These signals may include Push Bombs, Push Sprays, and Fatigue attacks. Also, to determine a change of locations that can signal high risk. Risk-based authentication (RBA) is usually coupled with step-up authentication. For example, let’s say your employees are under attack. RBA can detect this attack as a stuffing attack and move from a classic authentication approach to a more secure verified PUSH approach than the standard PUSH.
This would add more friction but result in better security, such as adding three to six digital display keys at your location/devices, and you need to enter this key in your application. This eliminates fatigue attacks. This verified PUSH approach can be enabled at an enterprise level or just for a group of users.
- A key point: Conditional Access
Then we move towards conditional access, which is a step beyond authentication. Conditional access goes beyond authentication to examine the context and risk of each access attempt. For example, contextual factors may include consecutive login failures, geo-location, type of user account, or device IP to either grant or deny access. And based on those contextual factors, it may grant only to specific network segments.
- A key point: Risk-based decisions and recommended capabilities
The identity security solution should be configurable to allow SSO access, challenge the user with MFA, or block access based on predefined conditions set by policy. It would help if you looked for a solution that can offer a broad range of shapes, such as IP range, day of the week, time of day, time range, device O/S, browser type, country, and user risk level.
These context-based access policies should be enforceable across users, applications, workstations, mobile devices, servers, network devices, and VPNs. A key question is whether the solution makes risk-based access decisions using a behavior profile calculated for each user.
Zero trust authentication: Technology with JIT techniques
Secure privileged access and manage entitlements. For this reason, many enterprises employ a least privilege approach, where access is restricted to the resources necessary for the end-user to complete their job responsibilities with no extra permission. A standard technology here would be Just in Time (JIT). Implementing JIT ensures that identities have only the appropriate privileges, when necessary, as quickly as possible and for the least time required.
JIT techniques that dynamically elevate rights only when needed are a technology to enforce the least privilege. The solution allows for JIT elevation and access on a “by request” basis for a predefined period, with a full audit of privileged activities. Full administrative rights or application-level access can be granted, time-limited, and revoked.
Final Notes For Identity Security
Zero trust identity management is where we continuously verify users and devices to ensure access and privilege is granted only when needed. The backbone of zero trust identity security starts by assuming that any human or machine identity with access to your applications and systems may have been compromised. The “assume breach” mentality requires vigilance and a Zero Trust approach to security centered on securing identities. With identity security as the backbone of a zero-trust process, teams can focus on identifying, isolating, and stopping threats from compromising identities and gaining privilege before they can harm.
Zero Trust Authentication
The identity-centric focus of zero trust authentication uses an approach to security to ensure that every person and every device granted access is who and what they say they are. It achieves this authentication by focusing on the following key components:
- The network is always assumed to be hostile.
- External and internal threats always exist on the network.
- Network locality needs to be more sufficient for deciding trust in a network. Just so you know, other contextual factors, as discussed, must be taken into account.
- Every device, user, and network flow is authenticated and authorized. All of this must be logged.
- Security policies must be dynamic and calculated from as many data sources as possible.
Zero Trust Identity: Validate Every Device
- Not just the user
Validate every device. While user verification adds a level of security, more is needed. We must ensure that the devices are authenticated and associated with verified users. Not just the user.
- Risk-based access
After a device has been validated and verified as belonging to an authorized user, risk-based access intelligence should be employed to reduce the attack surface. This allows aspects of the security posture of endpoints, like device location, a device certificate, OS, browser, and time to be used for further access validation.
- Device Validation: Reduce the attack surface
Remember that while device validation helps limit the attack surface, device validation is only as reliable as the endpoint’s security. Antivirus software to secure endpoint devices will only get you so far. We need additional tools and mechanisms that can tighten security even further.
- Rise in Ransomware Attacks - March 31, 2023
- Network Connectivity - March 30, 2023
- Carriers Based on Open Ethernet with SONiC - March 28, 2023