Printer Friendly

One hot trend in audit regulations ... and 2 cold facts behind it.

What's a hot trend in IT security audit regulations? Privileged accounts and passwords. These are the pre-built administrative IDs found in virtually every piece of hardware and software in an organization, such as root on UNIX, Administrator in a Windows workstation and embedded passwords that connect applications. Privileged passwords are under increased scrutiny in evolving regulations such as:

**** Sarbanes-Oxley 404. This legislation requires that companies prove they have control over their financial systems. If an enterprise has key financial information whose administrative access is not sufficiently secured or managed, then that organization may be in violation of Sarbanes-Oxley.

**** HIPAA. This set of healthcare regulations encompasses similar requirements to Sarbanes-Oxley. For HIPAA, the goal is to ensure patient information is absolutely confidential and secure. If an organization allows unsecured administrative access to patient data, it may be violation of HIPPA.

**** PCI. Payment Card Industry standards are perhaps the most explicit in terms of managing, securing and updating privileged passwords. These requirements, as spelled out in sections 8.5.1 through 8.5.16, have become the standard for many other legislative bodies. For example, parallels can be found in the energy industry's NERC/FERC compliance requirements.

**** More international regulations are being added daily. A partial list of international regulations that touch on privileged passwords now includes Basel II, 21 CFR Part 11 and Gramm-Leach-Bliley.

**** Country-specific regulations are also on the rise. When it comes to privileged identities, numerous countries around the world are enacting tighter regulations for control of privileged passwords, such as France's "Loi de Securite Financicre," Germany's "KonTraG," the UK's "Combined Code" and the Netherlands' "Tabaksblat Code".

Every day I work with auditors and enterprises in order to help enforce these and related regulations. But no matter what the regulation, industry or country, two key principles hold true. These "cold hard facts" are:

1. Organizations must prove control over key systems and information

Time was, sensitive information was stored in file folders with locks. I remember that time well! The more powerful an individual was in an organization, the more the keys to those many locks jangled in his or her pocket. Now those days are gone, and a full key ring seems to be solely reserved for folks who maintain facilities. One beneficial thing I miss about those good old "key days" was that it was simple to track who had access to what information. Typically a slip of paper in the CEOs desk listed the number of keys and who had them. If a key were lost or went missing, all keys would be replaced. Today that confidential information resides in electronic file folders in a wide array of systems inside an organization. Send a sensitive document in an email and--bingo--it now exists in even more places than ever before, including the mail server and recipient storage systems. In other words, even the most sensitive 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 electronic keys to be tracked were those for individual workers, such as the identity Jane_Marketer. In this sense, identity management solutions do a wonderful job of provisioning users to systems. For example, a typical provisioning maneuver would ensure that Jane_Marketer was provisioned to have access to Microsoft Office, Quark Express and Email Blaster 3000 ... and NOT to the general ledger system. Identity Management solutions will also remind Ms. Marketer that she needs to change her password regularly, such as every 30 days. Control the electronic keys for individual employees and you would seem to be controlling access to all sensitive information.

Sadly, it's not that simple. Virtually every piece of hardware and software has privileged identities built-in--these are basically secret keys which are added to system by its creator. The best-known privileged identity is the Administrator account that appears when starting up your local workstation. Manufacturers create these identities because somewhere, sometime, some user is going to do something so incredibly unexpected that their actions crash the entire system.

The privileged identity is the manufacturer's back door to restart destroyed and corrupted systems. Because it is the entry point of last resort, it's built so that it can not be disabled or destroyed. Sometimes clever IT folks find a way to remove the privileged identity, but this can compromise the integrity of the entire system and weaken your 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 to fix them. So the next question is this: How many of these privileged identities exist in your organization? Analyst research firms such as IDC* have estimated that the number of privileged identities far outstrips those for personal accounts. It's not hard to replicate their math. Every employee has at least one workstation and that workstation has at least one privileged identity. Add to that all the privileged IDs in firewalls, email servers, applications, databases and so on, and the number grows quickly; especially when you consider that some systems include dozens of privileged identities, depending on what subsystem you are trying to restore.

To sum up, the myriad regulations covering privileged identities all concur on one fact: Proving control over a target electronic system means proving that EVERY key to that system is completely secure. And in the high-tech world, that means keys for both personal identities and privileged identities.

2. Accountability, Accountability, Accountability

A second principle driving many regulations is that of accountability. Here's the reasoning. Suppose you have an employee who is up to no good. Perhaps this perpetrator wants to copy the customer database and sell it to a competitor. Or maybe our baddie wants to erase one year's worth of incriminating emails.

However no matter what the motivation, our perpetrator has decided to do something nasty and doesn't want to get caught. Their next step? Turn to Google and search. In minutes they'll find out about these wonderful privileged identities: super-secret and anonymous ways to do virtually anything to any system and leave no fingerprint. They'll also find dozens of pre-written scripts that are available for instant download with the most common manufacturer default passwords for any privileged identity.

A note on default privileged passwords. When manufacturers create privileged back-door identities, they also insert a default password into that identity BEFORE the system ships. Once the target system hits a company's loading dock, it's often time-consuming to locate and manually update all these default passwords. In the end, many rushed IT departments skip this step. In fact, surveys show that up to 40% of default privileged passwords are never changed.** It comes as no surprise then that insider attacks using these privileged identities are now the most common and serious security threat to enterprises, according to the Department of Defense and Carnegie Mellon University.***

Now back to our hypothetical perpetrator. Next we reach the part of the story where our imaginary baddie has done their work and all heck breaks loose. The internal search is on for the employee who stole the database ... the judge wants to know who erased every email in 2003 ... and as the internal auditor, your phone rings off the hook. But whatever the catastrophe, you as auditor will be asked to review internal systems and find the culprit. And who will these systems say was at fault?

The administrator.

Here is where the regulations step in. It's simply not acceptable to set up an identity called "Administrator" in a system that's built to track "Jane_Marketers." In organizations where that practice is approved, it inevitably comes back to haunt the audit and security groups. The best practice is to tie anonymous identities to personal ones, and 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 are in fact secured; and second, to tie any activity performed under these generic and anonymous IDs to real-life individuals. The good news is that automated solutions can help accomplish both of these tasks. The bad news is, of course, that until all your privileged identities are secured and personalized, your organization may be at risk for insider attacks, lost revenue and failed audits.

Adam Bosnian is Vice President of Cyber-Ark Software, developers of the Enterprise Password Vault.

*Source: IDC, "Privileged Password Management: Combating the Insider Threat and Meeting Compliance Regulations for the Enterprise," Jan
COPYRIGHT 2007 A.P. Publications Ltd.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2007, Gale Group. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Security Viewpoint
Author:Bosnian, Adam
Publication:Software World
Date:Sep 1, 2007
Previous Article:Lock the door!!
Next Article:The great data exodus.

Related Articles
Flippping the switch: software issues blamed for border project delay.
DARPA looks for ways to verify integrated computer chip security.
New ag-inspector mission proposed for border agents.
NASA aerial drone collects disaster data.
Electronic attackers: computer crimes keep government and industry on the defensive.
34th Street Partnership recognized for demystifying city parking.

Terms of use | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters