In our current world of cyber insecurity, Identity en Access Management (IAM) feels like a journey back in time. IAM focuses on internal threats and on the workforce, as it did in the days when the world was still small and relatively safe. By 2009, IAM felt mature and complete – standard solutions, established names and a proven approach. All in all, a commodity. A bit of a bore, in fact. But now none of this holds true anymore. IAM has entered a maelstrom of changes, which erode all certainties we have.
It used to be straightforward: IAM protected the front door and hackers tried to get in through a back door – or an open window. The front door was for the workforce, and IAM ensured that employees received their keys; logistics above security. And the key was a username and password. IAM systems, provisioning systems in particular, were not required to be hacker-proof since they were in the secure zone, the internal network. IAM and cyber security truly operated in separate worlds.
Today, hackers no longer seek back doors and open windows. They attack the front door head-on. According to the Verizon DBIR 2017, in 81% of all breaches user accounts were compromised. It appears that the colleagues from cyber security have closed the back doors, and today IAM is the weakest link.
The point is best illustrated by the demise of the password; it has to go as it is not good enough to keep out the bad guys. So we’re all engaged in Multifactor projects. Just as clear is the rise of PAM; we must protect administrator accounts as they are any attacker’s prime target. Until recently, no one actually did PAM, it was just something we talked about. Well, today we do MFA and we do PAM – but we are hitting the limits of available resources.
That isn’t all. Security dogmas teach that IAM is preventive security. So we stay generally aloof when there is a breach – in IAM, we do office hours only and leave the incidents to the hard-core security people in the incident response teams.
But we can’t; when the attackers go for the domain
administrator password – or the hash – we are the only party that can reset all
passwords (and MFA keys) to lock the bad guys out again. For any hack, this is what
must be done; as Notpetya proved, adding Mimikatz to a run-of-the-mill attack is
just a matter of a few mouse clicks. Mimikatz does not only harvest passwords
for domain administrators, but from anything that signs in. This includes applications
and devices. So be ready to reset them too.
In these attacks, it is best to assume that the root certificates for the Active Directory and the web authentication systems will have been copied. Replace them. For any attack above the least sophisticated, you’d have to reset all application accounts (and check for rogues), SSH keys and the accounts used by APIs – accounts traditionally not in IAM scope. Nevertheless, it must be done. Welcome to the present: IAM is a major player in incident response. Be there.
Then again – very likely you are not. You have yet to
develop the capabilities, as some sort of IAM Resilience project.
Now, IAM will be in the office until the hack is stopped. We need a culture change in IAM before we can actually close this gap. We all prefer to do office hours only, but this is no longer so. Then we must develop response procedures and adapt our systems so they are up to the task.
This is only the beginning. Because the next major change is already under way.
Traditionally, Identity Management is an extension of
HR to translate HR data to IT entitlements. It is process automation of
creating and distributing accounts and access rights to what used to be called
employees but is termed the workforce today. Workforce, as we’ve finally solved
the problems with contractors and suppliers. But today we have an explosion of
accounts not linked to a human: Non-Person Accounts (NPA).
NPA have become an issue with the rise of APIs, especially REST. REST is the extremely popular successor of SOAP – lightweight applications that can be thrown together quickly. One of the reasons why REST is easier than SOAP, is because it doesn’t do security. SOAP has a lot on the security, with top-heavy standards WS-Security and WS-Trust that somehow never fit into a project plan. So, REST it is.
REST uses http and hence has to rely on the standard login forms of basic authentication to set up a session with another machine. This results in an interface that can also be accessed by a human hacker. Or a scripted attack.
Of course you can ‘solve’ the authentication issue for
a REST interface with dual-side TLS. That means using certificates, but these
things expire all the time and managing that is a terrible hassle. Furthermore,
each client would need a secure storage for the client certificate with the
private key, which – in practice – is no more than somewhere on the hard disk. Security-wise,
TLS can be part of the solution, but certainly not the entire answer.
Certificates can’t replace authentication, just strengthen it; there will always be an account logged into by the API. Accounts had better have passwords, and if they do, passwords would like to expire. But an API can’t change a password or call the help desk – so we do away with the password change policy, or else the API programmer must write all kinds of creative code to work around changing and resetting passwords. This takes away the advantages of cheap and simple. Finally, the API must store the password somewhere and it is quite common to include it in a script: the dreaded hard-coded password. There are no glossy brochures stating that PAM can help here, but this is far from mature; it works some of the times. Another possible part of the solution.
But, but... don’t they have API key solutions that provide good security? From an authentication perspective, these are just longer passwords – just much more difficult to brute-force. Eventually, without a key roll-over it is not good. And they will be stored somewhere on the application server and every client can be copied and abused. API keys are good, but only another piece of the solution puzzle.
Oauth is also presented as a solution. The trouble is that Oauth doesn’t do authentication – and authentication is the problem to solve. And we need stronger authentication than mere username passwords, not just for humans. As computers don’t have fingers, we can’t use standard TOTP based solutions. TOTP requires a separate device to qualify as a true multi-factor, and computers generally don’t have Smartphones to load the app on. Computers don’t have fingerprints or irises to help check biometrics. It appears that strong authentication for non-person accounts is beyond our current means. Maybe we could use reverse Turing testing – if an API suddenly enters keys with a human rhythm, we’d know that something is definitely wrong. The idea may be helpful but behavioural authentication is only just going mainstream.
Should IAM solve the API Account puzzle at all? APIs are used by applications, so most of the time IAM will not be involved. As this is about account, not users, they have a semantically valid point. From the perspective of keeping difficult stuff outside this works fine, but thinking from a security governance perspective it is plain wrong. These accounts live in account stores managed by IAM. If IAM doesn’t manage these accounts, no one does. And those are the bad guys' dream. If IAM wants to be relevant now, there is only one answer to the question whether API accounts are in scope for IAM: Yes.
So get to it. And fast. Since the next revolution has also started: the rise of Things.
There are numerous publications on the security of IoT, or rather, the lack of it. However, these publications rarely touch the IAM perspective. The normal perspective is that IoT can be hijacked and abused, as some rogue robot – a nice perspective for movies. What we should be considering is that IoT devices log on to our systems or our cloud – and these accounts will thus be stolen. Something we could name the Identity Of Things: IDOT.
The notion that IDOT exists shows that all traditional IAM questions apply: who can create an IDOT account, what rights does the Thing have on your systems, how do we manage the account life cycle, and most difficult of all: how can you know you are dealing with the Thing you are expecting? Authorization and above all, Authentication.
Just as with an API, it is a computer signing in to your computer. Just as with API all we have is a username/password, what we now consider woefully inadequate for human users. If we wanted to use certificates to strengthen authentication for IDOT, we'd smack into the walls of revocation and enrollment. How can you get a 2-euro device to support new protocols such as CMC/CMS or EST so this can be automated? Considering that most normal server systems have yet to implement these, we either have to postpone the IoT revolution or we have a ton of extra work over the next years in solving breaches. At least we know in advance what will be on the DBIR 2021 report as the #1 attack vector.
“In truth most of the automation today is not yet about intelligence, but what you might term ‘automated stupidity’ – it’s the dull and mindless work that’s been automated so that humans are freed up to leverage their intelligence.”
RPA salesmen inform us that RPA does not make
mistakes, works 24/7 and is much more secure as there are no humans involved
that could be socially engineered. “Robots lack curiosity (e.g., won’t open
phishing e-mails), cannot be tricked into divulging information or downloading
unauthorized software, and have no motives which might tempt them to violate
existing policies”. It
is true that a human may be influenced to do stupid things – but it is far from
true that computers can’t. Drive-by installers and SMB exploits break into
computers whether there is a human looking at the screen or not. If computers
could not be spoofed or otherwise misled, there would be no hacks and no
malware. Infallible computers do not exist.
Figure 1: IAM and RPA
The first-generation RPA currently implemented with top priority is a very immature technology, certainly from a security perspective. RPA impersonates a human user: it is on a windows desktop (virtual or actual) and uses the very same applications humans use: e-mail, cloud applications, windows shares – all the regular stuff. RPA can handle unstructured data which makes it very valuable for the business. But in practice, RPA is a bunch of users in your Active Directory, synched to various cloud applications, that interactively logs on.
If anything logs on, IAM is involved. So let’s begin at the beginning. A robot will have to authenticate to all the systems the white collar that previously did the work authenticated to. Presumably, the software robot can enter a username and a password. But just as any API or IoT, the robot can’t do multifactor, reset a locked password via the helpdesk, memorize a password without it being somewhere not on disk, and it can’t do biometrics. In a nutshell: for all systems RPA will be signing in also, we’ll have to build bypasses for the regular and strong authentication mechanisms. Considering the popularity of RPA in finance, that will include systems that for compliance (PIC-DSS for instance) must have multi factor. Of course, we can wiggle out of that, with the same semantic wordplay the RPA vendors use. However, it does make the RPA a prime target for any hacker seeking financial gain. And as it usually is a piece of software running on a desktop operating system receiving e-mail, there is a ton of available attack vectors and exploits.
The RPA robot impersonating a human will need good error handling if it is to do all things a human does to have access. If the robot doesn’t do the password reset self-service, its account will be locked out and stay that way. Robots will get stuck in security systems designed for humans, relying on analogue or out-of-band processes. If an application changes, a human is likely to read and figure it out, or ask a colleague how to do it. A human may call security when something looks suspicious. The current generation of RPA (which has every action scripted – the AI part is brochured only today) will just break at the first anomaly. In practice, RPA will be a reason not to change anything: don’t touch it, it works. This does not bode well for automatic platform upgrades such as security fixes.
One final word on misleading robots. True, they will
not respond to a Microsoft employee over the telephone to hand over the
session. But as soon as the RPA will handle e-mail, it will have to parse files
that have been sent as attachments. It will open PDF, DOCX, RTF, POTX and any
other type of file the platform supports. It has the same means of validating
the trustworthiness of the sender as the human user – none. If the attachment
contains an attack, it will work just as well as with a human user on the
receiving end. Or better.
On a much higher abstraction level, we have an even larger security challenge. We may know how one robot works, but we have little knowledge how a combination of robots works out. Consider the Black Swam syndrome. We can see this in action with the so-called Flash Crashes in the stock markets or with Ethereum: all robots are programmed for stop loss orders. When the stock market price drops, all robots will sell immediately to reduce losses. With Ethereum recently, the course thus dropped from $320 to $0,10 and the damage amounted to millions. Human traders realized that this was stupid and started buying, halting the fall – and earned millions, bringing the price back to its original levels.
One might say that a Flash Crash isn’t cyber security, as there is no hacker involved, but the damage caused by immature robots is very real. And security is not just keeping hackers out, it is keeping computer systems secure.
To conclude this long
article: with all new developments happening Identity and Access Management is
up for a hard reset. IAM is involved in anything that needs access, and it is
central to every security undertaking. Get used to it.
Jan Koot is security engineer at Traxion. He is primarily active as a penetration tester and security improvements at major companies.
Melvis Hadzic has been working in IAM for over fifteen years, the last ten years as an independent contractor, in various roles from architecture to project management.