Knoco
exact  any/all
  The original knowledge-management publication
denotes premium content | Jan 9 2009 

Regular

posted 1 Aug 2007 in Volume 10 Issue 10

Last word

Ghosts in the machine

You don’t give a key to your house or office to just anyone, so why are many organisations still unaware of the information risks posed by privileged accounts and passwords?

By Adam Bosnian

What’s the biggest issue today in IT security? Privileged accounts and passwords. These are the pre-built administrative IDs found in virtually every piece of hardware and software, including ‘root’ on Linux operating systems and ‘administrator’ on Microsoft Windows. Privileged passwords are under increased scrutiny as a result of regulations that require organisations to lock down access to sensitive corporate data. These include:

  • The Sarbanes-Oxley Act. This well-known US legislation demands that companies prove they have control over financial systems;
  • Health Insurance Portability and Accountability Act (HIPAA). These healthcare regulations are similar to Sarbanes-Oxley. For HIPAA, the goal is to ensure that patient information is kept confidential and secure;
  • Payment Cards Industry (PCI ) Security Standards Council. PCI standards are, perhaps, the most explicit in terms of managing, securing and updating privileged passwords in corporate systems. These requirements have become the standard for many other legislative and standards bodies, too;
  • More regulations are being added daily – all round the world Basel II tops the list of international regulations. In the US, key regulations include Title 21 CFR Part 11 of the Code of Federal Regulations, which deals with electronic records and signatures.

Uninvited guests

Every day I work with auditors and enterprises in order to help enforce these and other regulations. But whatever the regulation, industry or country, two key principles always hold true. These are as follows:

1. Organisations must prove control over key systems and information

Time was when sensitive information was stored in filing cabinets with locks. If it was really important, the room would be kept locked, too. The more powerful an individual was, the more keys jangled in his or her pocket. Now a full key-ring seems to be reserved solely for janitors. In the ‘good old days’ it was simple to track who had access to what information. Typically, a slip of paper in the CEO’s desk listed the number of keys and who had them.

If a key were lost or went missing, all could be replaced. Today that information resides in electronic files in a wide array of systems inside an organisation. Send a sensitive document in an e-mail and – bingo – it now exists in more places than ever before, including the mail server and recipient storage systems. In other words, even the most sensitive of documents can exist in a multitude of electronic filing cabinets, making it even more important to keep track of the ever-expanding list of electronic keys.

The first keys to be tracked were those for individual workers such as, for instance, the identity ‘Jane_Marketer’. A typical provisioning system would ensure that she could access OpenOffice, Adobe InDesign and RocketSales 4.0, but certainly not to the general ledger. The system would also enforce a regular change of password. Control access to applications in this way and you can control access to all sensitive corporate information, right?

Wrong. Sadly, it’s not that simple.

Virtually every piece of hardware and software has privileged identities built-in – these are secret keys added to a system by its creators. The best-known privileged identity is the administrator-account.

These identities are created because somewhere, some time, some idiot is going to do something so incredibly unexpected that their actions will crash the entire system. This privileged identity is the manufacturer’s back door, enabling them to restart destroyed or corrupted systems. Because it is a last resort, it’s built so it cannot be disabled or destroyed.

Sometimes, clever IT folks can find a way to remove the privileged identity, but this can compromise the integrity of the entire system and weaken the case for free technical support if the need arises (and trust me, it will). Accidents happen and when they do it’s great to have a privileged account with which to fix them.

So how many of these identities likely exist in your company? Not many, surely? Just a couple? Far from it. Analysts, such as IDC1, estimate that the number of privileged identities far outstrips the number of personal accounts.

The reason? Every employee these days has at least one workstation, which will have at least one privileged identity. Add to that all the privileged IDs in firewall software, e-mail servers, applications, databases and so on and the number quickly grows – and some will have dozens of privileged identities.

2. Accountability, accountability, accountability

A second principle driving many regulations is that of accountability. Why? Suppose you have an employee who is up to no good – it happens more often than you might imagine. Perhaps he or she wants to copy the customer database and sell it to a competitor. Or maybe they want to erase some incriminating e-mails. Or perhaps both.

Regardless, they are going to do something nasty and certainly do not want to get caught. Their next step? Search on Google. In minutes they’ll find out about these wonderful privileged identities: super-secret and anonymous ways to do virtually anything and leave no fingerprint. They’ll also find dozens of pre-written scripts with the most common default passwords for any privileged identity.

A note on default privileged passwords. When manufacturers create such back-door identities, they also insert a default password into that identity before the system ships. But once the software has been installed, it’s time-consuming to locate and update all these default passwords with something stronger. In the end, many IT departments simply skip this step (some might not even realise that it’s necessary).

In fact, surveys show that up to 40 per cent of default privileged-passwords are never changed2. It is no surprise, then, that insider attacks using these identities are now the most common security threat to enterprises, according to Carnegie Mellon University3.

Disaster strikes

Now back to our hypothetical baddie. Now, he or she has done their business and all hell breaks loose. The search is on for the employee who stole the database, while the judge wants to know who erased every e-mail since 2003. An internal review will be launched to find the culprit. And who will these systems say was at fault? The administrator, of course.

And the the regulations state that it is simply not acceptable to have a general identity called ‘administrator’ in a system that’s built to track individuals, such as Jane_Marketer. Increasingly, such practices inevitably come back to haunt the audit and security groups. The best practice is to tie anonymous identities to personal ones and to have the reports and ‘paper trail’ to back up your systems.

In summary, there are a multitude of regulations that require enterprises to secure privileged passwords, the all-powerful and anonymous codes built into almost every piece of hardware and software. These regulations have two main purposes: first, to ensure that privileged identities really are secured; and, second, to tie any activity performed under these generic and anonymous IDs to real-life individuals.

The good news is that automation can help accomplish both of these tasks. The bad news is, of course, that until all your privileged identities are identified, secured and personalised, your organisation may be at risk from insider attacks – as well as failed compliance and IT security audits.

Adam Bosnian is vice president of Cyber-Ark Software. You can contact him via the website www.cyber-ark.com.

References

1 IDC, Privileged Password Management: Combating the Insider Threat and Meeting Compliance Regulations for the Enterprise, Jan 2007;

2 Cyber-Ark password survey 2006;

3 Management and Education of the Risk of Insider Threat (MERIT), CERT3 Programme, Software Engineering Institute and CyLab at Carnegie Mellon University.


Other publications
by Ark Group


Copyright ©1994-2005 Ark Group Ltd All rights reserved. No part of this site or the publications described herein
may be reproduced in any form without the permission of Ark Conferences Ltd, Registered in England, No. 2931372.