User and device analytics have been a primary focus of this year’s Gartner Identity and Access Management (IAM) Summit. Keynote speakers, research analysts, and vendors have all shown a vision of how companies can help to improve an organization’s security posture through deploying User and Entity Behavior Analytics (UEBA). Unfortunately, there’s been no general direction of how to get started with this technology, outside of ‘get your stakeholders involved’ and ‘talk to vendors.’
Password reuse by individuals is one of the great failings of IAM programs. The fundamental assumption of a successful IAM project is that an organization can correctly identify an individual user. Although this sounds like a low bar, many organizations are failing to clear it because of password breaches happening outside of the corporate firewall. For example, consider the recent Yahoo breach or the Friend Finder breach. Both breaches exposed passwords for millions of end users. Very, very few organizations sent their employees and contractors guidance to change their corporate passwords after these breaches hit the news, and similarly, there’s no policy that says that a user’s Yahoo email password cannot be the same as their Active Directory password. It is fundamentally easier for end users to just use the same password everywhere, which makes it exponentially easier for bad actors to use these credentials to access an increasing number of systems beyond the initial breach.
The promise of UEBA is that companies and organizations would be able to detect anomalous behavior by end users. The challenge is determining what ‘anomalous’ behavior looks like, which will vary by user or entity. This also presumes that we can identify users successfully.
Third-generation Multi-Factor Authentication (MFA) helps to address the gap of identifying end users while simultaneously deploying an initial set of analytics for an organization. The premise of the latest generation of MFA is simple: two-factor authentication was lacking context. Take an RSA key fob, for example. The premise of an RSA key fob is that it generates a secure code for a short duration of time, which the user enters when prompted for two-factor authentication. This sounds good until the key fob is borrowed from their desk or stolen while they are out at a restaurant. The bad actor can impersonate the end user if they have their password (via a public breach or another method) and the physical fob. Location does not matter – if the bad actor goes to a coffee shop four blocks away or another city, it is effectively the same.
MFA adds location as a minimum and optionally additional context like the application or if the device has symptoms of malware or is jailbroken. It is probably OK if your VP of Sales is at her office and viewing SalesForce. It might be less OK and require additional authentication if they are instead at a coffee shop and viewing SalesForce. However, it is obviously not OK if they are accessing SalesForce from Russia in the middle of the night with an unfamiliar Android phone.
Similarly, MFA can help to identify that a systems administrator, sitting at their desk, should be able to log into their PC. However, it would be worth prompting them for additional authentication if they are trying to escalate their privileges on a production server outside of an approved change control window. This initial and admittedly simple set of analytics, when tightly coupled with the user identity, serve to reduce the potential of a breach.
However, this does not mean that an organization can sprinkle magic MFA dust on Tuesday and finish by Wednesday. Some key business questions need to be asked, primarily relating to processes but also to policies. There are a broad number of MFA vendors in the market today, offering an array of SMS-based, Interactive Voice Response (IVR)-based, application-based, and biometric (fingerprints, facial scans) solutions in addition to dedicated hardware ‘key’ solutions. No single solution will work for any organization – companies need to plan to support multiple acceptable authentication methods. IVR works except for employees who are hard of hearing. Fingerprints work except for medical technicians who wear gloves. Thus organizations need to choose a preferred mechanism, and then one or more potential fallback methods to present to the end user.
The other business question which inevitably comes up is who should require MFA. Most organizations focus on the privileged users – those users who are AD Domain administrators, or who have root, or who can log on to the SOX-audited servers, for example. This is a short-sighted view of the threat landscape. All users have some degree of privilege, whether it is being able to inadvertently install malware on their PC, or view network resources, or view financial records or intellectual property that can be exfiltrated for profit by bad actors.
The last primary business question is what to protect. Endpoints and servers should be considered the minimum – if a user is accessing a key server from an untrusted endpoint, they should be prompted under most circumstances. If they’re in the habit of also storing valuable IP on their laptops, they should be prompted at the endpoint level. Applications, particularly SaaS applications, are another obvious target for MFA as they reside outside the organizational boundaries.
MFA for everyone is the long view for an IAM program and is coincidentally the easiest way to get started with UEBA. By having an agreed-upon standard of identifying users by requiring one or more approved forms of MFA, businesses can then trust that the users and entities accessing their resources are whom they say they are. The associated analytics and monitoring help to ensure that users with privilege can have the privileges to perform their functions when it is contextually appropriate. These analytics also will help organizations to understand what ‘normal’ looks like, which can help to identify what a breach looks like by comparison.
Original story
https://www.linkedin.com/pulse/getting-started-identity-analytics-access-management-iam-mcgladrey
Comments are closed.