Posted on Tue, Dec 08, 2009 @ 05:27 PM
Gartner published a great research report on Entitlement Life Cycle Management: The Evolution of Role Life Cycle Management. Besides defining the difference between business and technical roles, Earl Perkins (the author) points out that roles are really all about assigning fine-grained access permissions (entitlements) to users based on their job function.
He states, "a discussion of roles can easily overlook an important point: The real effort to assign the appropriate levels of access actually rests at the granular level of the entitlement. An entitlement (also called by various audiences a "privilege," "permission," "access right" or "authorization") is currently the most granular construct for assigning the level of access to a job function based on enterprise access policies. In other words, an entitlement is the means by which an enterprise assigns a particular level of access to an IT-based resource, whether it is information in a database, a transaction in an application or a command in an IT system. A role is one method by which these entitlements may be grouped or aggregated to make the process of assigning those entitlements more efficient."
Well stated Earl. While technical and provisioning roles benefit an organization as an efficient IT security administration tool for automating the creation of accounts in user directories, this approach isn't able to understand a user's relationship with the organization in terms of the function that a user performs for the business and can map the specfic entitlements that are appropriate to the functional role. Enterprise business roles have evolved to achieve this objective.
Posted on Wed, Oct 14, 2009 @ 10:30 AM
Interesting article from Dark Reading on database vulnerability being attributed to authorized users. http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=220300753&cid=nl_DR_DAILY_H
What strikes us from this article is the importance of merging access governance and data governance frameworks. As you will see when you read the article, role-based access control is certainly mentioned but not given much attention as a preventative control. We agree that misuse of access entitlements by "authorized users" is creating the majority of data breaches but we would question whether an authorized user really needs access to sensitive information resources, and if so does an organization know what level of privilege to provide? As stated in this article, organizations have a difficult time understanding whether access is truly required.
"Unfettered access to data is another common problem in many database environments, experts say. In many cases, employees are given access to more information than they need to do their jobs."
What we see as a common access governance failure related to database access is when a user's role or relationship with an organization changes. Take for example a DBA that changes departments and now administers a different set of data or when a DBA changes their functional role by becoming an application developer. The likelihood that this individual would drag their database access entitlements from their old position into the new one is fairly common, and increases the chances of having someone misuse their access privileges.
So the real challenge is how to effectively manage change to user access where the frequency of these changes is high and the number of information resources (databases, applications, file shares, systems, etc.) that access change needs be managed against can be in the hundreds to thousands. Organization can benefit by having a roles-based access governance control framework in place as it will provide a preventative control that ensures access is always appropriate. By establishing business roles, organizations will now have a common language for expressing access that will work for the business to use when requesting access (as it is made up of specific information resource entitlements that are truly needed for a person's functional role) and works for an IT security or operations group that is tasked with access delivery to the business while ensuring that the access request doesn't introduce any compliance violations or business risk.
Organizations that don't leverage a role-based approach for governing access should have a process in place for review and certification of user access in order to provide dectective controls. A best practice for access change management using reviews would be to conduct a review of a user's access based on a change event, such as when an individual gets an entitlement to a high risk information resources or changes departments/functions within the organization. Incremental, event-driven reviews can provide a dynamic detective control that can catch and remediate access governance issues before an audit review period.
###
Databases' Most Serious Vulnerability: Authorized Users
New Dark Reading report outlines threats posed to databases by end users -- and how to protect your data
Oct 01, 2009 | 05:09 PM
By Ericka Chickowski
DarkReading
[Excerpted from "Protecting Your Databases From Careless End Users," a new report published today in Dark Reading's Database Security Tech Center.]
In all of their frenzy to protect sensitive data from hackers and thieves, many organizations overlook the most likely threat to their databases: authorized users.
While today's headlines might be full of compromises and SQL injection attacks, most database leaks are still caused by end users who have legitimate access to the data, experts say. Yet, according to "Protecting Your Databases From Careless End Users," a new report published today by Dark Reading, many enterprises still don't do enough to protect data from accidental leaks or insider theft.
To read the rest of the article, click below.
http://www.darkreading.com/database_security/security/app-security/showArticle.jhtml?articleID=220300753&cid=nl_DR_DAILY_H
Posted on Tue, Sep 15, 2009 @ 01:32 PM
Interesting to see that access governance control failures are continuing to happen at all levels in the Federal Government.
http://www.wired.com/threatlevel/2009/09/montgomery/
Intelligence Analyst Charged With Hacking into Top Secret Anti-Terror Program
An analyst at a Defense Department spy satellite agency faces federal hacking charges after allegedly poking around in a top-secret system used in a classified terrorism investigation involving the FBI and the U.S. Army.
Brian Keith Montgomery worked on a covert program for the National Geospatial-Intelligence Agency - the spy agency in charge of satellite and aerial image collection. On April 9, he was carrying out his duties when he saw a message that "provided significant detail about a classified operation" that was unrelated to his job, according to an affidavit filed by a Pentagon investigator in the case.
According to the government, Montgomery ignored a security warning in the message he saw, and twice logged in to a classified system used in the terrorism investigation: first on April 9, when he stayed on for two hours, and then on April 14. He'd gotten the password from another classified message to which he also had legitimate access.
Curiously, just by accessing the system, Montgomery endangered the terrorism investigation, and "caused harm to the U.S. Army and the FBI," according to the affidavit by Dexter Wells, an agent with the Defense Criminal Investigative Service.
Montgomery's alleged motives are unclear, but he told DCIS that he was very interested in the information in the program, Wells wrote. Montgomery also told investigators that he'd thought he was allowed to log in to the system, and hadn't noticed a warning saying that only officials participating in the operation were allowed to use the password.
"It was not until I was called on the carpet, that I went back and read the warning notice in the message traffic," Montgomery allegedly told DCIS.
The nature of the system at issue is not clear, but it was used from all around the U.S. as part of the terrorism investigation, and was being monitored by the FBI at the time of his alleged access. That's evidently what led to the probe of Montgomery, who worked at a National Geospatial-Intelligence Agency facility at Fort Belvoir in northern Virginia.
There are no allegations that Montgomery did anything with the information he obtained.
###
We see too major issues here:
1. As we have seen in numerous employee snooping incidents, such as at the US State Department, hoping that users within the enterprise will remember access policies that live in a three ring binder on the IT Security organization's bookshelf is wishful thinking. Putting a warning in a message that states that only authorized system users who are working on particular case or project should be logging in to view the information is not an effective access governance control. Controls need to be automated to ensure that policies are enforced in a consistent fashion across the entire enterprise and all legitimate users. In this situation, I wouldn't hold the employee accountable for snooping as there we no real controls for limiting access. The DoD is responsible for enabling this situation to occur as they knew the likelihood was high that some users did not have a legitimate reason to access the information, which is why they put the warning in the message.
2. There appears to be no access governance framework in place at the DoD based on the news reports of this event. If a user is authorized with credentials to log into the system as part of performing their job function, controlling what they can and can't do requires access administration capabilities that far exceeds what a system account password provides. Controlling access is best done at the entitlement level, which is where the specific access rights are assigned to a person and the determination is made for what they can or shouldn't be able to do within the system. Had the DoD leveraged an dynamic access governance control framework they could have avoided this situation by administering access using role attributes. This approach enables user entitlements to be assigned based on a case log or project assignment code that would map to a particular user's task or process role within the department. This would make the determination of who is, and is not, authorized to view specific content based on the work they have been assigned.