Privileged Access Security - A Deeper Dive

A Detailed Look into the Need for Privileged Access Security

​We're going to take a deeper look into why Privileged Access Security (PAS) is a must-have for all organisations. Despite what most of the cybersecurity market tell us, systems are relatively secure. Vulnerabilities do occur, but most often these are small and complex keyholes into a wider system. Attacks using vulnerabilities exploit the fact that human failings will leave credentials lying around.

Here's the short version of the story, make sure your CISO takes a look!

Why Privileged Access Security is critical

You can check through every breach report ever and only find a handful of attacks that have relied solely on a system weakness. All those that I know of have been website links to back-end services that were not properly secured- so that's a different kind of human failure.

You could consider that most of the cybersecurity industry protects systems against external attacks. In contrast, PAS protects systems against the human behaviours that make systems insecure. This statement is a generalisation, since PAS helps to segment operations such that a weakness in one area cannot bleed over to other areas. Unlike anti-malware, where all the estate needs protection, PAS can be implemented in stages, and each stage is a worthwhile investment in security.

PAS gives a structure and policy to human-system and human-process activities. It gives the organisation a fully audited record of who can do what, where, and when - as well as what was done.

Here's the first chapter in the PAS Deep Dive series that outlines the key drivers of risk and the need for PAS.

‍

​

Three fundamental human behaviours that cause most of the security breaches

• Credentials: If asked to create a credential (a username and password for example) humans will simplify to aid memory. If you can remember a password, you can be pretty sure that the elements in its makeup are in rainbow tables (the tables used to drive brute force password cracking). Human-generated credentials are not enough - other factors are needed. Computer-generated passwords cannot be brute-forced.
• Privilege Hoarding: (AKA "Entitlement Hoarding") Users will ask for the privileges they need to get their work done. They will never ask to have privileges taken away.  Over-privilege is a problem. Malware often acts in the context of the user- the more privileged the user - the more the malware can get to.
• Local Admin Rights and Workstation 'customisation': Users want to control their own working environment. Users will use the Internet to solve problems. If that means downloading a 'utility' to get something done, then that is what happens.  It will be no surprise to find that the Internet is full of good tools wrapped in malware envelopes.  It is malware at the workstation that is responsible for most of the credential loss from organisations. Uncontrolled access to the user's workstation means that approximately 1/3 of all these systems will have some form of detected malware per year. The net result is that we cannot trust the workstation as an environment to store, or even reveal credentials - they will simply be intercepted at the keyboard buffer, file system or browser level.

‍

To err is human. It's not an intended behaviour, but these mistakes cause damage and leave security holes. This is why process automation is growing at such a rate.

​Other behaviours that increase the security attack surface

• Sharing credentials: We all need to think about this. A department hires a temp to get things done.  It takes too long for IT to grant a new set of credentials - or it’s seen as too costly. Therefore the temp gets to share an existing employee’s credentials -and often these are from senior managers.
• Wandering:  Some people will wander around the network to prod and poke systems and applications just out of curiosity or even boredom. This is where errors and issues are introduced.  We need to consider that 1 in 240 people have criminal tendencies - and if they find things they think will be profitable, they may be tempted.
• Have the system remember the credentials: This is very common. People feel as if they are the only ones to use a system, so this will be OK.  Modern malware knows this. Modern malware often mimics user behaviour, right down to the time of day and typing cadences.  It is quite common for malware to run a background process in the user's browser and use it to access systems with remembered credentials. This type of malware is very difficult to detect at the system end.
• Embedding credentials: Most often seen in Excel - a sort of naive automation that may get a spreadsheet passed around a department. This is credential sharing, and actually the easiest form for malware to recover.
• Getting Phished: Yes, this will happen to even the best of your users.  Mostly, users work out they have been phished after the event. There will be something about the web page or system that doesn't ring right. You can be sure that not all users will tell you this has happened and your gullible users will not even realise!

‍

The astute reader could be thinking that anti-malware and keeping patches up to date would go a long way to solving these issues. If this were the case,there would be a lot fewer breaches reported. Then there are all the odd exceptions where updates cause applications to fail, or older systems that cannot be updated.

​The simple conclusion is to use and develop systems that avoid the human behaviour problem in the first place. This is what Privileged Access Security (PAS) is all about.

​PAS helps in many other ways as well.  For example, we tend to abuse our users. We ask them to remember too many passwords and systems always seem to ask the user to change their password at a critical moment (probably the reason that rainbow tables have so many profanities in them!)

​Osirium's PAS moves human behaviour away from your critical attack surfaces

​The key steps to privileged security:

• Separate People from Credentials: With PAM (Privileged Access Management), there is no need for your users to remember any other set of credentials than their own. This one step is a major contribution to attack surface reduction. Phishing for privileged account credentials is totally eliminated. Users cannot be tricked into revealing credentials they have no access to. This is very different from a vault approach where a user can be fooled into retrieving and entering credentials into a fake site or having the credentials stolen from the cut and paste buffer.
• Make credentials ultra-complex: PAS can make passwords as big as a system can cope with. For PAS, keeping track of a 256 character password is little effort. Updating the password on events or periodic cycles is just part of the automatic policy.
• Identity In - Role Out: This is the policy key to least privileged operations. It is much easier to manage a low number of role-based accounts than all the privileges on all the user accounts. Separation is also much easier. For user accounts, an AD granted privilege may get used on systems that it was never intended for. With PAS, the mapping between the user account and the role-based accounts a user can use is obvious and simple.
• Session Recording: Just recording a session will change the way that a user treats an open session to a system, device or application.
• Process Automation: This is a major contribution to security.  Removing the need for any privilege in the first place is the best way to avoid them being put at risk. There are many repetitive operations that need privilege - and these are prime candidates for automation. Osirium's Privileged Process Automation (PPA) element of PAS helps with credentials embedded in code. It provides a simple way of replacing them, which renders code "safe at rest". We've seen many credentials harvested from GitHub repositories, but that isn’t the fault of GitHub. It's a human failing in the programmers that embedded the credentials in the first place. Process Automation eliminates most human error. With PPA, we provide functions to guide the user even further away from the path of mistakes.
• Safely delegate Local Admin Rights: Any reader from the IT world will realise that it is impossible to do all the things for all the users. There's always that class of user that needs something special. Equally, it is difficult to work out which individual privileges any user will need on their workstation for any operation. The Privileged Endpoint Management (PEM) function of Osirium's PAS is specifically designed to deal with these dilemmas. It can learn what users do and encapsulate the safe operations into policy. Users are elevated to Local Admin Rights for known operations automatically. And for those special individuals there is a request process and even an offline token-based system to deal with road warriors (or everyone in these lock-down days). Just this simple step of removing local admin rights reduces the reach of malware and makes it much harder for the user to be fooled into installing bad code.

This about completes chapter one of our deep dive into Privileged Access Security. In the next chapter we will look at the inner workings of Privileged Access Management. Of course, if you'd like to know more - please get in touch.

‍