Many organizations look at compliance the wrong way. They think if certain technology tools are put in place, processes are reviewed and risk assessments are conducted, they are in compliance.
But compliance isn’t about the act of providing more secure processes and technologies; it’s about demonstrating that these processes and technologies are indeed providing a more secure environment.
Installing new identity management applications won’t guarantee compliance. Any identity management program must provide the services that the tools are expected to deliver.
Putting new compliance processes on paper doesn’t mean the worker population is following them. Likewise, deploying an IAM tool doesn’t mean it will improve an organization’s compliance position. In this tip, we'll cover IAM issues that can affect compliance, and how to ensure IAM technology and processes effectively support enterprise compliance.
Identity management provides two assurances that are considered the backbone of many regulations and industry security initiatives. These are:
- Principle of least privilege: This is the concept of giving a user account only those privileges that are essential to do that user's work.
- Separation of duties (SoD): This is the concept of having more than one person required to complete a task.
These are important because when it comes to compliance, the one activity that causes the most risk is an individual making changes that compromise the security of a protected data set without the audit or oversight capabilities to detect and prevent this from happening. As organizations have strived to solve this problem, they’ve turned to identity management systems for the answer.
Looking more closely at the identity management-compliance relationship, IAM systems can be broken down into two areas: predetermined and real-time access control. Predetermined access control is the function of determining in advance what access a user should have, what systems a user should have access to and how a user can interact with the data on those systems. Real-time access control is regulated once the user has been granted an account and can make access requests. Ideally, at access request time, these technologies should determine where the user is, what device they’re using, whether the user is able to access the data at the time of request, what requests are allowed to be executed and ensure the right data is returned to the user.
Predetermined access is primarily provided by a provisioning service. Regarding compliance, it’s important to be able to demonstrate not that a user was granted an account, but from where the authorization to provision an account for the user was initiated. Was it a self-service request? If so, what logic was applied to ensure the user is authorized to be granted the request and confirm that SoD rules are being applied? Or is the access requested by another person on the user’s behalf, like their supervisor? If so, how does the organization know this person is authorized to determine what proper access for this user is? Only recording that a user is granted access isn’t enough for compliance. How the proper access is determined, who is authorized to approve the access, and how the request is verified to determine the proper access was granted is important information to track and retain. By retaining this information, the logic of the authorization can be examined at a later date by a third party to validate the enterprise’s compliance.
Real-time access is controlled by IAM systems. These tools are inline, between the user making the access request and the system/data. Whether Web-based, portal-based or an application programming interface (API), these services interrogate the request to ensure the credentials are correct and the requesting system is in a safe location to access the data the user wishes to obtain. In the case of real-time access, compliance is achieved by logging the user information and the access commands as well as the data returned by the request. These logs are best stored in a log management system where compliance rules can be stored and where third parties can review the transactions taking place to ensure they meet the access rules of the company.
Assuming these activities are functioning correctly, nonrepudiation is another compliance concept that must be maintained. In other words, the access methods taken were the only methods available to the user. Too often organizations put in new identity management systems but fail to shut down the old manual access methods. By allowing these “back doors” to remain open, data can be accessed outside of the controlled methods, thus providing not only non-compliant access, but a risk of data loss or exposure. It’s not enough to create new tollways of access, the grass-covered roadways also need to be decommissioned and closed off. Sometimes this can be difficult in large, distributed organizations and is still one of the major struggles for many organizations to be in compliance with regulations.
Installing new identity management applications won’t guarantee compliance. All identity
management systems must provide the services the tools are expected to deliver. In addition,
resources need to be allocated to document how the systems were configured and operations personnel
must be directed to capture and maintain the daily logs that are generated. At the end of the
deployment, a documented review must be conducted to ensure the old access request and runtime
systems have been deactivated, or ideally retired, to ensure unsanctioned methods for accessing
sensitive information can no longer be used.
About the author:
Randall Gamby is the information security officer for the Medicaid Information Service Center of New York (MISCNY). MISCNY manages and maintains the largest state-run Medicaid claims data warehouse in the United States. Prior to this position he was the enterprise security architect for a Fortune 500 insurance and finance company. His experience also includes many years as an analyst for the Burton Group's Security and Risk Management Services group. His coverage areas included: secure messaging, security infrastructure, identity and access management, security policies and procedures, credential services, and regulatory compliance.
This was first published in May 2012