Many organizations erroneously think, if certain technologies and tools are put in place, processes are reviewed...
and risk assessments are conducted, they are in compliance.
However, compliance isn't about the act of providing more secure processes and technologies; it's about demonstrating these processes and technologies are indeed providing a more secure environment. It is also important to note that just because new compliance processes get put on paper doesn't mean the worker population is following them. Fortunately, many identity and access management (IAM) systems offer the features and policies necessary to help enterprises establish, maintain and prove regulatory compliance.
Managing and enforcing permissions
Many government regulations have specific mandates concerning identity, including directives about how information is stored, the privacy of that data, user access controls and auditing. Identity management systems provide two major assurances that are considered the backbone of many regulations and industry security initiatives:
- Principle of least privilege is the concept of giving a user account only those privileges that are essential to do that user's work.
- Separation of duties 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 have turned to IAM systems for the answer.
The IAM and compliance relationship
Looking more closely at the identity management-compliance relationship, IAM systems can be broken down into two areas:
- User provisioning 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.
- Access control is regulated once the user has been granted an account and can make access requests.
Ideally, at access request time, these technologies will determine where the user is, what device the user is using, whether the user is able to access the data at the time of request and what requests are allowed to be executed, as well as ensuring the right data is returned to the user.
User provisioning is key to streamlining the onboarding process of a user and authorizing access. As it relates to compliance requirements, 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. For example, 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 separation of duty rules are being applied? Or is the access requested by another person on the user's behalf, such as a 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 are all 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, such as during an audit.
Access controls 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 access control, compliance is achieved by logging user information and access commands, as well as the data returned by the requests. These logs should be 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.
Most IAM systems today -- web-based, portal-based, APIs or via a cloud service -- provide user provisioning and access controls that are key to enterprise compliance strategies. Other IAM features that may tie into compliance include the following:
- remote access
- password management
- multifactor authentication
- IAM analytics
- single sign-on
- lifecycle management
In addition, many IAM systems offer specific user activity compliance and compliance controls to help companies meet common regulations and verify compliance with corporate policies and government regulations.
IAM compliance regulations
Many U.S., worldwide and industry-specific data security and privacy laws contain specific IAM mandates. For example, HIPAA's Security and Privacy Rules define access control measures for health information. IAM systems can help organizations comply by, for example, ensuring only the appropriate users have access to sensitive data and conducting account and privilege recertification.
Learn more about how these regulations relate to IAM here.
Managing IAM systems and policies with compliance
Nonrepudiation is another compliance concept that must be understood and maintained. In other words, ensuring the access methods taken were the only methods available to the user. Too often, organizations put in new IAM systems but fail to shut down the old access methods. By allowing these backdoors to remain open, data can be accessed outside of the controlled methods, thus providing not only noncompliant 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 maintain compliance with regulations.
Note that installing new IAM mechanisms won't guarantee compliance. All IAM 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 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.