The big security hole most companies leave wide open
February 16, 2010 by Steve HannafordPosted in: Security, Special Report
Super-smart hackers make the headlines, but careless database administration is a much bigger vulnerability. The good news: It’s a threat that can be minimized with careful management of employees’ access to company records.
The problem: disgruntled and/or malicious ex-employees whose accounts and access privileges have never been deleted by a busy IT staff. Unless there is a well-documented and reviewed process for closing out accounts when an employee leaves the company, there is a good chance it doesn’t get done, at least not in a timely manner.
That’s the conclusion an article in the Dark Reading data security Web site.
The article cites the case of two recently indicted data thieves who easily managed to get into the database through unexpired accounts they had when they worked for the company. They then gained access to company data and tried to sell it to competitors.
The problem is widespread, according to security experts, and it exists because the task of terminating accounts is not clearly assigned. Add the fact that most companies only have a rough idea of who does and who does not have database access, with relatively primitive manual methods used to track that status. As one expert is quoted as saying, “Many people actually keep Excel spreadsheets manually of how many accounts are in the database and who has ownership, so there is no automation around it.”
There are several recommended practices:
- Assemble a centralized list of all access permissions currently active. You should be able to produce an active up-to-date list of who currently has access and to what.
- Make future maintenance of the list a clearly assigned responsibility.
- Put in explicit procedures for human resources and IT to terminate access for departing employees.
- Conduct a review of log-in behavior on the database. In a small company, this might be a manual task. In a larger company, you should have software tools installed to create automatic login summaries, highlighting unusual activity from specific users.
- Larger companies should consider security information and event management (SIEM) tools. These programs make sense if you have hundred to thousands of database searches each day, too many for manual review. The smarts built into these programs allow you to focus on out-of-the-ordinary behavior. They are made by such companies as Q1 Labs, Tripwire and TriGeo.
DocuCrunch.com delivers the latest IT and Imaging news once a week to the inboxes of over 200,000 IT and Imaging professionals.
Click here to sign up and start your FREE subscription to DocuCrunch!
Tags: administration, database, ex-employees, Security, user accounts
Loading ...
February 17th, 2010 at 3:11 pm
Some additional guidance…
Here is an auditable process for any kind of access control, including databases:
1. Establish an owner for the component in question. If you’re looking at database permissions, it might be the application owner, but it can’t be the person handling security administration (so probably not the DBA). This provides segregation of duties.
It helps to maintain a spreadsheet, database, or sharepoint with a list of components, applications, or systems and owners.
2. Any change in permissions should be authorized by the identified owner. The requester, request date, owner authorization, auth date, and the administrator’s name or ID and date of effective permissions (date permissions change was made) should all be logged in a spreadsheet, database or sharepoint. Artifacts, such as a form or e-mail authorization should be stored. If you have a gifted Sharepoint administrator, a simple workflow can be set up in Sharepoint that logs the authorization tied to the authorizing person’s ID.
3. Quarterly, the list of systems, components, and applications should be reviewed to make sure the “owners’ list” is current. As harsh as this sounds, a system, component, or application without an owner should be turned off. If a new owner can’t be found, say if an owner leaves the company, threaten to turn it off, and someone will either step up to own it, or the application is no longer required. One method is to assign ownership to the highest-ranking person who has access to the application. Send out an e-mail notifying the owners of their systems, components and applications, as well as the responsibility and expectations associated with being an ‘owner’.
4. Quarterly access control reviews should occur, where the owner is handed a list of who all has access, and what permissions they have. Feedback from the owner should be recorded, and updates should be made appropriately. A second review should follow any updates to confirm with the owner that permission changes were successfully implemented. A log of who performed the review, who modified the permissions, and the owner’s acceptance should all be maintained.
5. Track privileged access. This can be as simple as logging “super user” logins to a file with the date/time, source machine or user ID. The auditors will want to see that if someone logs in as a DBA, the fact that they logged in is recorded somewhere, and from what machine or user ID that DBA login originated. Most systems can be configured to log access. If not, sometimes a simple script can be implemented, such as part of a login script, that can perform this function automatically.
Although this sounds like a lot of effort, this is a bullet-proof process from an audit standpoint.
February 17th, 2010 at 11:19 pm
[...] Post From SharePoint Security – Google Blog Search: The requester, request date, owner authorization, auth date, and the administrator’s name [...]