To put it simply, privileged accounts are like the keys to the kingdom of IT.
They grant access to sensitive data and configuration settings. They’re rarely changed in most organisations, yet they’re known to nearly everyone. They don’t have the same level of accountability and auditing you get with normal user logins. And they’re unlikely to be managed by existing Identity and Access Management systems.
To make it worse, privileged accounts are found virtually everywhere.
On every server and workstation platform, on networking and datacenter appliances - from routers and switches, to load balancers and security appliances, and on almost every type of software you can name - including line-of-business applications, Web services, databases and middleware.
It’s easy to see why regulators want them controlled or better still eradicated. But, perhaps more importantly, that’s the reason you as an organisation need to get control of these deadly accounts.
Top Five Audit Traps
In recent years we have witnessed more and more organisations fail to adequately secure their systems. When examining the evidence, there are common practices that have lead to these failed IT compliance audits and security breaches. How many of the top five are you guilty of?
No. 5: the ‘Attribution’ Trap
An organisation’s processes and practices make it impossible to know who had access to view sensitive data and change system settings, on what system, when, and for what purpose.
The characteristics of an organisation that falls into this trap are:
- Reliance on spreadsheet files and printouts for accessing highly privileged logins
- Staff use built-in administrator accounts more frequently than you’d expect
- Privileged logins are seldom changed
- IT staff manually track “who did what, when” using privileged logins
In a recent survey, conducted by Lieberman, a surprising 68% of respondents believe that, as an IT professional, they have more access to sensitive information than colleagues in other departments such as HR, finance and the executive team
No. 4: the ‘DIY’ Trap
All too often privileged account management practices lack the efficiency, scale and resilience to secure the network against external and internal threats. Organisations rely heavily on scripts and ad hoc processes to complete routine management tasks, ignore accounts that can’t be easily secured and therefore leave large security holes. The complications are:
- Everyone involved with scripting and manual changes knows the credentials
- Use undocumented workarounds and incomplete coverage
- IT Staff have less time for strategic projects
- Processes and scripts are maintained by a small number of expert staff
For example, to change a single Windows service account password, you need to discover everywhere that the account is in use, stop all other dependent services in the right order, change every instance of the service credential and then restart all dependent services in the proper order. One large software vendor found it took 240 IT staff hours to change a single privileged service account manually ‘the right way’ inside its datacenter.
No. 3: the ‘Temporary Worker’ Trap
Organisations often get caught out because they’ve failed to revoke contractor or employee highly privileged access when there is no longer an immediate business need. The reason is, in the majority of cases, it’s impossible to document who accessed data, when, and for what purposes. It’s further compounded as access is sometimes from unknown locations at odd times or, in some cases, there can even be an undocumented ‘back door’.
The most common cause behind recent data breaches involves either third parties, contractors or people who have left the organisation. In fact, one financial institution discovered that its privileged logins where published on an internet hacker board by a fired IT administrator!
No. 2: the ‘Lazy Admin’ Trap
While on the surface it might seem idiotic, but in many cases practices exist that actually allow IT staff to circumvent security in the name of ‘convenience’.
- Staff avoiding changing highly privileged logins
- Reusing passwords that grant too much access
- Frequent use of Admin account logins
- Too few actionable audit logs
A very large insurance company used a common local admin password at the company’s sales office by a few non-IT staff. This practice allowed thousands of unauthorised, and potentially unlicensed, applications installed at offices all over the US.
It’s important to remember - if one person can save the ship, he can also sink it!
No. 1: the ‘Network Creep’ Trap
This is the one that gets most organisations as they fail to account for privileged account security holes introduced by new and changed systems and applications. Organisations don’t know, and can’t find out, where all their privileged accounts reside. Also, password changes can cause account lockouts because of unknown interdependencies.
The problem is that it’s the blind leading the blind as many vendor staff, responsible for placing new equipment and applications, don’t themselves know if the products comply or conflict with the organisations existing infrastructure, security controls and policies.
A national healthcare provider based on the US West Coast had failed to change a published default password for a server in its data centre. This meant it was possible to take control of the server through a ‘lights out’ management card, access data and even power off the machine through this published password.
Four Steps to Counteract Five Traps
It takes just four, basic steps to regain control of privileged identities. These steps are easy to remember because they’re abbreviated as I.D.E.A .
I is for identify all of the privileged identities that are present on critical IT assets in your infrastructure, whether on server or desktop operating systems, network appliances, line-of-business applications, and so on. Understand which of these identities are interdependent, so that when you change the credentials of one account you know to update the dependent accounts to avoid lockouts and service disruptions.
D is for delegate access to these accounts so that only appropriate personnel can login to critical IT assets, always in a timely manner whenever needed, over a secure communication channel, using the least privilege required (to reduce the potential for damaging errors), with a documented purpose, only during designated times.
E is for enforce rules for password strength, uniqueness (so that a password isn’t reused except where absolutely necessary) and change frequency, synchronising all of those changes across dependent processes.
A is for use auditing and alerting processes that make individuals accountable for privileged access, set the right organisational tone, and alert management to any unusual events.
Taking control of privileged identities will help your organisation’s IT regulatory compliance and governance position, while reducing your IT staff workload. But it’s capable of much more than that. It will help increase your security posture.
Avoiding the auditor’s trap is a strong motivator, but avoiding falling into a criminal’s trap has got to be the ultimate goal.
Posted by Jane Grafton, Director of Business Development, Lieberman Software