In speaking with a number of customers about Identity Auditing, it's pretty clear that there's a lack of clarity in the space. And customer needs differ. Some customers want help figuring out how to navigate the regulations that govern their industry. Others want a solution that puts them in compliance. And yet others are looking for a solution that proves that their controls are working. I think this variety of needs is symptomatic of the fact that each of those customers may be at a different stage of the Identity Audit project cycle. Even if you haven't called it an Identity Audit project, simply defining policies related to identity management & access is the first step toward an IdA solution. Here's a breakdown:
I. Determine Policies
Organizations may base IT security and identity-related policies on any number of requirements.
a. Often, identity policies are driven by external regulations. Sarbanes-Oxley and HIPAA as examples help companies determine what security-related policies to implement.
b. Another set of policy drivers are industry standard best practice frameworks like COBIT or ISO17799. An organization may choose to comply with one of those standards and allow it to determine many of the identity policies.
c. Of course, risk mitigation is an obvious driver of security-related policies. So, an organization may implement certain policies to achieve a more comfortable level of risk. For example, a company with no regulatory or standards-based requirement for two factor authentication may still choose to implement a solution to minimize risk associated to a given application.
d. Some policies may be based on business enablement requirements. For example, the policy decision to grant employee access to a given set of files may not be related to regulations, standards or risk mitigation. It may be driven by a new revenue opportunity that's success is dependent upon employee access to those files.
II. Implement Controls
Identity-related security controls can be implemented in a number of ways. A common way to implement policies on a Microsoft network is to build policies into Active Directory and leverage Microsoft Window's built-in file system access security. Access to systems outside of the Windows file system can also be granted or denied based on Active Directory group memberships (via LDAP calls). Identity Management tools help implement controls by enforcing business rules during the user provisioning and reconciliation processes. There are numerous third-party applications and in-house solutions that can help implement identity controls. For example, a PKI infrastructure may be implemented to meet a two-factor authentication policy. An entire book can probably be written on the various methods for implementing identity-related policies. Generally, all of the software vendors in the IdM space attempt to provide this capability to some degree.
III. Test and Confirm Controls (Identity Audit)
Once policies and controls are in place, an organization can start to think about testing and auditing those controls. The goal of these audits is to ensure that the controls in place are putting the organization in compliance with its defined policies. If the policies are driven by regulation, then proving that the policies are being properly controlled also confirms that the organization is in compliance with that regulation. This is really the goal of identity audit solutions -- to ensure that the identity systems in place (which implement controls) are effective at enforcing adherence to an organization's identity policies.
Conclusion
Hopefully, the above provides a basic overview of the core components of identity auditing. One of the main take-aways should be that it's near impossible to prove compliance without defined policies. Without clearly defined identity policies, what would you be complying with? I suppose an argument could be made that there's value in just auditing that the identity system is doing what it's supposed to do as determined by the identity system's requirements document. But, I think the real value lies in proving that an organization is meeting its identity-related business goals as determined by its identity-related policies.
No comments:
Post a Comment