This sub-project is an effort to leverage frameworks and tools to position Access Governance within a global Information Security Program. We will simplify the process, with the goal to provide a simple example, and a potential skeleton for a more detailed process.
COBIT is a Framework for IT Governance and Control. For more on COBIT, check http://www.isaca.org/cobit
Let’s start from the COBIT 4.1 Maturity Model and derive a maturity model specific to Access Governance, including Data Governance.
|0 Non-existent||Complete lack of any recognisable processes. The enterprise has not even recognized that there is an issue to be addressed.
Access is granted using inconsistent procedures, e.g. copying from an existing account access profile, and cumulative entitlements are added to account profiles without recertification of access. The need-to-know principle is loosely applied, resulting in excessive access. The organization has no plan to identify excessive access, establish global procedures across systems, or implementing review processes for access.
|1 Initial/Ad Hoc||There is evidence that the enterprise has recognized that the issues exist and need to be addressed. There are, however, no standardized processes; instead, there are ad hoc approaches that tend to be applied on an individual or case-by-case basis. The overall approach to management is disorganized.
The organization is reactive, e.g. following an audit, some partial, system specific reviews are initiated without cohesive global processes. System specific processes are loosely implemented by separate groups, with the goal to improve the posture, but without global guidelines or procedures.
|2 Repeatable but Intuitive||Processes have developed to the stage where similar procedures are followed by different people undertaking the same task. There is no formal training or communication of standard procedures, and responsibility is left to the individual. There is a high degree of reliance on
the knowledge of individuals and, therefore, errors are likely.
Separate groups are developing procedures that are system specific for creating and managing account profiles. No enforcement is implemented in systems, and procedures or guidelines are shared in a loose fashion. Procedures or guidelines, and instructions on how to use them, are circulating in a mesh fashion.
|3 Defined Process|| Procedures have been standardised and documented, and communicated through training. It is mandated that these processes should be followed; however, it is unlikely that deviations will be detected. The procedures themselves are not sophisticated but are the formalisation of existing practices.
The organization has centralized procedures and guidelines, and implemented training for new and existing users on how to use them. Procedures are being enforced through administrative rules, not by systems, so deviations cannot be easily detected, and cannot be prevented. Procedures are not cohesive between separate systems, and still require technical expertise about specific systems in order to be understood.
|4 Managed and Measurable||Management monitors and measures compliance with procedures and takes action where processes appear not to be working effectively. Processes are under constant improvement and provide good practice. Automation and tools are used in a limited or fragmented way.
Reports are available to management about access that abstract technical details, leveraging business labels. Management can review/certify access and request remediation as needed using a recertification tool. Remediation is partially automated, and still rely on manual tasks for many systems or specific access. Statistical and trending reports are available, together with automated recommendations based on customizable thresholds, which allow constant improvement and provide a basis for good practices.
|5 Optimised||Processes have been refined to a level of good practice, based on the results of continuous improvement and maturity modelling with other enterprises. IT is used in an integrated way to automate the workflow, providing tools to improve quality and effectiveness, making the enterprise quick to adapt.
Access information is centralized into a reporting, recertification, and workflow tool that provides assistance for decision making up to the business level, leveraging predefined targets and objectives. A cohesive framework for access across the organization is implemented, which allows recertification to be conducted by LOBs(Line of Business) managers, and supervision by senior management. The majority of access granting or remediation tasks are automated in order to provide quick provisioning and deprovisioning of access. Rules can be implemented to trigger automated remediation.
The first step would be to determine the Maturity Level of the organization vs Access Governance. For example, the Current State could be 2, but the Desired State could be somewhere between 3 and 4, above the industry average.
In order to progress from the Current State to the Desired State, a Strategy is required.
A Road Map is required, for example 18 months to reach the Desired State, with a milestone date after 12 months to achieve intermediate state 3. Also, we could include in the strategy that we want to implement Role Based Access Control(RBAC) in the organization.
What will allow us to execute the Strategy? First we need to capture the organization’s intent to execute the strategy using a high level statement. We need to obtain support from senior management, by capturing its intent, expectations and direction. We need to create a Policy together with senior management.
Policy: Access to IT resources and data must be granted on a need-to-know basis, and reviewed at regular intervals to assess compliance. Remediation must be enforced in a timely fashion when non-compliance is identified. Access Compliance processes should be regularly evaluated in order to increase their performance and be aligned with good practices.
Then from the Policy, we need to derive Standards, which are metrics, allowable boundaries, and other elements that allow us to attest that Policy requirements are met.
Standard vs Roles: Access must be granted through Roles in a minimum proportion of 80% for each individual account. For a specific system or application, a maximum of 10% of accounts are allowed to be granted out-of-roles access. Each individual role must be granting a minimum of 5 individual access elements or entitlements, otherwise entitlements that cannot be grouped together in this way should be granted in an out-of-role fashion.
Standard vs Recertification: Each individual role for an account must be reviewed on a yearly basis by managements. Administrative roles and out-of-role entitlements must be reviewed on a quarterly basis by management. The granting of an entitlement that violates compliance(e.g. Separation of Duty) requires exception approval by 2 levels of management, and must be recertified on a monthly basis except when specified otherwise.
Standard vs Performance: Compliance for Roles and Recertification Metrics must be reported on a montly basis, and trends must be determined. Event-driven reporting and recertification must be supported for out-of-compliance access.
After Standards, we would be defining Procedures and Guidelines. Procedures are operational in nature, and include step-by-step instructions on how to accomplish specific tasks. A Procedure could be defined on how to create reports using corporate templates within a specific software tool. Or it could be about the information that must be typed into an electronic form to request the creation of a new role in the tool, or the definition of a specific recertification workflow with attributes like escalation interval and path, configuration of e-mail notifications for assigned tasks, etc. Procedure will be specific to the tools in use, or tools to be acquired. If the tools need to be acquired, a list of requirements would need to be created from the Standards, and a proposal could be requested from multiple vendors. Once the tools is identified, Procedures specific to the tools and how the organization decides to implement them can be created.
Guidelines are more prescriptive in nature, and can include examples vs Procedures, suggestions like a typical long description attribute for a role or a resource.
In order to build the business case for the project, a Risk Assessment in a mandatory step. Here is a simplified example that attempts to identify assets, criticality, controls in place, threats, and probability of occurence over one year.
RTO = 24 hr
|Web, J2EE||password, groups||Breach, Aggregation||20%|
RTO = 72 hr
|Customer Order Processing App||Internal||Critical||Important
RTO = 48 hr
|Desktop app||SSO with AD Domain, AD Groups||Compliance violation vs SOX||40%|
RTO = 72 hr
|Desktop app||SSO with AD Domain, AD Groups||SoD violations||30%|
|eCommerce Web Server, B2C + B2B||Public||Critical||Critical
RTO = 2 hr
|Web, J2EE||password, SSL||Downstream SoD violations coming from Business Partner||20%|
The above example is not complete. Weaknesses should be explicitely derived from Controls, and Threats would need to be categorized into Compliance, Confidentiality, Integrity or Availability. Quantitative(e.g. out-of-compliance fines, cost to recreate business process) and Qualitative(e.g. Lost customer confidence) impact should be linked with Threats and Likelihood(Probability). This Risk Assessment exercise is about the Current State. Then we would need to position the additional controls available through Access Governance tools that are part of the Desired State vs each individual Asset and how it can contribute to reduce the risk to an acceptable level for the organization.
For example, Access Governance, through pro-active discovery, could detect and remediate a SoD violation before an actual audit results into compliance fines, or before a SoD violation is exploited in a fraud. Also, Access Governance can reduce the effort for the annual self-audit significantly by providing continuous monitoring of the Access landscape for the organization, and also reduce the effort associated with an external audit which traditionally require internal resources. The Business Case should factor in those cost reductions, but also factor in business enablers. For example, without Access and Data Governance, and real-time transaction monitoring(separate solution), strict compliance with PCI-DSS may prove impossible, which could prevent the eCommerce server to accept credit card transactions while avoiding compliance penalties from credit card issuers.
For more information and additional content, you can check http://www.infosecprogram.org