One of the hottest topics now is “Passwordless”. I do not have statistics on it, but it might have even replaced “Zero Trust” on the list of the things to write about. I put question marks in the headline for each question below, because there are more questions than answers as I read about the different vendors’ releases. I have a pretty good idea of what the answers are, but it is not from reading their websites. I am not saying passwordless is a bad idea, nor that all solutions are useless or insecure, but with everything else in IT Security, the devil is in the details. Maybe these questions can help you sort through the details.

What happened to layers?

From the beginning of time (computer time anyway), proving an identity (authentication) has been using something only the user knows. Most people call this the password. In order to not only rely on one layer, companies such as Security Dynamics (later known as RSA Security) launched a second “factor” such as the SecurID. The idea was to not only rely on what the person knows, but also what the person has, and there was a dream to also be able to detect what the person “is”, biometrics. How many layers is that now? At first glance you might think three because it sometimes involves all of these three components. But are they really used in layers around the resource you want to protect?

How do you enroll to the device?

Most of the solutions that provide a passwordless experience do so by using a cryptographic key that is protected by some form of biometric, most often either a fingerprint or facial recognition. Most of those solutions offer a fallback to the PIN (Personal Identification Number) for the device. Most people have firsthand experience with this from their phone every time the battery runs out, or often when the phone is restarted.

How well is the personal identity tied to the enrolment on the device?

Some solutions, such as Mac, do not use a PIN for this, but rather the same password. For example, I would use my password to log in to my computer. Some organizations use a central control of devices that can reset the passwords to unlock a device. If these devices rely on the same passwords, it could mean that someone else can take over my enrolled key without knowing my password, PIN or biometric information, could it not?

Once the user is enrolled to the device, how is device enrolled?

There is an opportunity for an organization to provision a device to the user, and in that process record the public component of the key, and make sure the key is not exportable from the device. With that information, they can make sure it is the user’s device that is being used. But most passwordless solutions today do not use this methodology, but rather a “shared secret”, most often a password! It should not be the same password as you use to protect the device key, so now we have at least one password for the enrollment and a PIN or password per device.

How many users can use the device?

On my list of challenges where I wish more solutions would show up, is how users can share a device without sharing identity. The biggest issue is iOS and Android, that are by design a single user OS. MacOS and Windows have gotten better over the years, but if you have 100 users sharing 10 computers, each computer needs to have knowledge of the 100 users, and the users would need to enroll 10 devices.

When is my security key used?

My personal view of trust is that it is a two-way street. Most focus is on how ca protector of a resource can trust the user identity. How can the user, however, trust the system requesting that proof? Here in Sweden, we are among the leaders for authorities and banks to verify personal identity with a system called BankID. To start with, this only works because Swedes have high trust for authorities and financial institutions (relative to other countries). The biggest challenge an authentication system has, and where most fraud happens today, is how the user can verify that the request to verify their identity with their key is legit, since there is a risk that a malicious person can be acting as a proxy. For this reason, BankID never responds without a user interaction, either a PIN or biometrics.

When can a “PIN” be used instead of a “password”?

For every year that has gone by, password complexity has gone up. But all of a sudden, there was a change where a PIN of 4 digits became just as good. I sometimes hear that it is ok, because it also requires “physical access” to the device, and it matches locally. I need to add one more requirement to that, and that is that the device should disable the PIN after 3 tries (or I can go as far as 5). And if you do this, do we really need more that 4 digits? This is why I believe it is a bad idea to tie that same PIN or password that you use to protect your security key, with the unlocking of the device in itself, unless the device should self-destruct in a similar way.

What is the security domain and policy?

As might be clear by now, the beginning of the process is where the trust needs to be established. The trust can grow after that, through “reputation” and local knowledge, but for a first use event, you need to go back to how trust was established. The process for this needs to be documented, but more importantly the process needs to be controlled by technology. The communication from user to resource protector needs to transfer the level of security at the other end. The best way to do this is usually to use different keys for different levels. The resource protector then needs to know how this key is protected, in order to evaluate the trust.

More importantly, the security domain has a center of gravity and a purpose. We cannot boil it down to one policy that will rule it all. For this reason, the IT industry has developed a concept coined “federation”. It allows different security domains to keep their uniqueness and purpose, and for collaborative purposes, learn about each other. (I will write a separate blog entry about that.) For the purpose of this blog, it is clear that we need to continue to evolve federation as well. Passwordless does not remove the need for bridging security domains, and if bridges are built, the password needs to be used less often, and you need less of them.

Does passwordless and Zero Trust work together?

I will also write a blog entry of “Zero Trust”, but let me just clarify now that John Kindervag’s original report from 2010 was about “Zero Trust Network”. Google were one of the first organization to take into a solution called BeyondCorp, where they clearly defined that the key concept was to base access decisions on the identity of the user AND the device. The way I read it, and the way I agree with it, is that both should be verified by the resource protector.  A computer has two separate type of areas, one being the system itself, or as Microsoft calls it “Local Machine” and the other area is the user or as microsoft calls it “Current User”. The user should not be able to change a device security setting of the system, if it is under an organization’s control. In order to achiev Zero Trust Network, i.e. not pay to much attention on where and how the device and user is connecting from, and is that the case in Passwordless? I am sure some solution keeps it separate.

Is passwordless a new concept?

No, it is not. If you have made it this far and have some experience with smart cards and PKI, you might have compared this with that ancient concept. Personally, I was VP Engineering at RSA Security for their PKI offering in protecting operating systems and applications. If you are not a fan of smart cards, you might have an issue with the smartcard reader, and do I. But already in 2001, we showcased a solution at the RSA Conference where we used the most commonly used smart card reader today, a mobile phone, integrated to a computer using BlueTooth. We adapted our CSP (Cryptographic Service Provider) in Windows, and it was Ericsson’s first BT phone with WPKI (Wireless PKI) capabilities (hence the picture). Unfortunately, it did not take off, because too many players wanted to make money on this, and the trust model was not well-defined. It was not federated enough, nor federated properly (TelCos wanted in on this). But the demo showed the concept of a user logging in to the computer with the help of the phone, and being logged out when the phone left the BT range, which at the time was outside the booth. The phone would prompt for each use of the PKI with different PIN requirement per type of operation.

With today’s technology, such as me being able to authenticate to my Mac through my watch, and all these great ideas coming out, there are even more opportunities to get this right. I hope these questions can help you analyze what is right for you. Let me know if there are other questions you might have.

 

 

 

Filed under: Insights by Göran Fransson
No Comments »

As the number of directories started to grow some 30 years ago, one approach was to build solutions that tied these directories together, and presented a view of the information from multiple sources. The way this is explained in Wikipedia is as follows (April 2022):

• A metadirectory system provides for the flow of data between one or more directory services and databases, in order to maintain synchronization of that data, and is an important part of identity management systems. The data being synchronized typically are collections of entries that contain user profiles and possibly authentication or policy information. Most metadirectory deployments synchronize data into at least one LDAP-based directory server, to ensure that LDAP-based applications such as single sign-on and portal servers have access to recent data, even if the data is mastered in a non-LDAP data source. 

• Metadirectory products support filtering and transformation of data in transit. 
• Most identity management suites from commercial vendors include a metadirectory product, or a user provisioning product. 

In 2000 however, Microsoft launched Windows 2000, with a new architecture that was very reliant on a new directory named “Active Directory” (AD). The name is to some extent misleading, because it is a fairly passive directory. There are some features that have become popular, that have some active components, with the Group Policy “push” and software deployments being the most common. 

The big change AD created in 2000, was that all application vendors had to adapt their solutions to AD. AD was almost LDAP, and introduced its own schemas, that few were brave enough to change. AD became the mountain, that everyone went to. 

One of the challenges with AD is it reliance on some internal network protocols (I.e. Kerberos) and security models. As applications dared to break away from the local network, Microsoft’s first response was ADFS, and most organizations used it as its first step in integrating applications outside. 

In 2009 the SVP of Engineering (Todd McKinnon) and a solution engineer (Frederic Kerrest) at Salesforce saw the growing need for a true identity source in the cloud as a SaaS.  During their first ten years, most of their business was about going to the “mountains” that started appearing in the cloud, such as Salesforce, ServiceNow, Box, Microsoft and Google. 

When I joined Okta as the first solution engineer in the Nordics, I saw the value of having a “gofer” that ran around and talked to the mountains. Over the years, Okta became a mountain by itself, and required the applications to take over the work of integrations. Their nice feature, the discovery of applications’ identities as a first step in integration, was not followed up in terms of using the applications as a source (except a number of HR systems, Google, Microsoft AD (not Azure AD) and LDAP. Okta has a lot of value in what they still deliver, but I decided to step outside of Okta and continue to help organizations to build bridges with what I call a true metadirectory, very much in line with Wikipedia’s definition. 

A true metadirectory is, in my view, a process that does not host the truth by itself, but collects the truth from the sources that hold the truth. I believe that data should managed and owned where the knowledge sits. This means that a metadirectory needs to understand how to prioritize each attribute and group membership per user type. Because of the true metadirectory being sourced from other systems, you can run multiple instances of it, using the same sources. 

 

Filed under: Insights by Göran Fransson
No Comments »

Working with identity and access is more of a journey than a destination. Many of the areas above have dependencies in both directions, and it is important to gradually improve each one. For every iteration, the system matures. One method of evolving is to continuously ask 5 questions: 

• Who works here? 
• What should they do and why? 
• How do we make sure and improve? 
• What can go wrong? 

• Are we playing by the rules? 

Who works here? 

It might look like an easy question to answer, but most often it is more complex than one would think. The easy answer is “the employees”, but looking at use of IT in an organization, there are usually wide varieties of users such as consultants, partners, suppliers, customers and more. This question is answered by work in the area of Identity. Within Identity there are two major areas. One is the connection from an Identity Manager to other applications and directories and the other area is how the identities should be “proven” as users access the IT infrastructure. 

What should they do and why? 

Besides knowing who the users are, it is important to understand what they should have access to and why. It is both to make sure that they get the access they need to do their job, but also make sure they do not get access to information that they are not privilege to. Most organizations try to define groups, attributes and/or roles that the users belong to, which in its turn is the basis for what access they should get, which is the authorization. There are many models for this, but in reality, most often it becomes a combination of them. The highest level of decisions is if the user should have any access to an application, and the second highest level is typically what role the user should have. Sometimes there is also a deeper level of authorization where the IAM solution decides on individual “permissions”. The enforcement is all about how the IAM solution shares this information to the application, and how the application makes sure it follows the policies. 

How do we make sure and improve? 

As mentioned above, this is more of a journey, and the systems under control are not static. Governance is often looked upon as an obstacle, but handled correctly and proactively, it can become a resource and create a structure that makes life easier. It is important to be able to follow what happens. To avoid overload, it is important to detect changes to what is considered normal. Based on this information there is always room for improvement, and changes should be controlled. An uncontrolled change can have a negative impact in many ways. What is important is that since an audit often goes back 12 months, it is important to be able to answer what access was possible during that time. Automation can often handle many events, but exceptions to automation must be possible, and also tracked. 

What can go wrong? 

No one can build a perfect system where nothing goes wrong. It is important to analyze what one should be prepared for, have a plan on how to fix it, and understand the impact or consequences. With mitigation one can also reduce the risk that it actually happens. 

Are we playing by the rules? 

When defining policies and setting the level of control, it is important to follow the rules defined both internally and externally. Compliance frameworks can be used as measuring sticks of progress  and as a driver for making changes to the other four areas. 

Management –   ”top down” or  ”bottom up” 

Different organizations have different approaches, but in the more mature the organization, the more common it is with ”bottom up”. A very immature and reactive organization also uses the “bottom up” approach, but with a lot of pain and seldom good results. The first proactive steps are to try to answer the five questions from the top. It is hard to decide what a person should do, unless you know if they are working ”here”. 

Filed under: Insights by Göran Fransson
No Comments »