Cybersecurity
DevOps Cloud (ADM)
IT Operations Cloud
This sub-project is an effort to leverage frameworks and tools to position Identity Management 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 Identity Management, focusing on Rules-Based and Approval-Based Provisioning, Self-Service and Reports.
Maturity level | Description |
---|---|
0 Non-existent | Complete lack of any recognizable 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 privileges are added to account profiles without following pre-defined rules or tracking approval and sponsorship. Accounts are not deactivated or deprovisioned in a consistent manner at the end of their lifecycle. Password strenght and lifecycle is not enforced administratively or technically. Elevated risk due to orphan accounts and access overspill. |
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. Separate business units have implemented partial procedures to provision accounts and access, leveraging a mix of import/export manual procedures and operational user account templates. Some systems are enforcing password complexity in an inconsistent fashion. The new account creation is a manual process which requires a security administrator to check a list in order to avoid duplicate account names. Tracking of approval or sponsorship is system specific, and associated with shared admin accounts. There is no unified view of all corporate accounts or access for a specific user. |
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 and provisioning access. 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 standardized 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 formalization 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. Procedures are more answering operational requirements vs security requirements. |
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 provisioning, approvals and sponsorships, that abstract technical details, leveraging business labels. Management can participate in Approval-Based provisioning as approvers, supervisors, or an escalation point. Statistical and trending reports are available, which demonstrate operational business value of controls like Password Self-Service and Return on Investment. Business metrics are generated through constant monitoring of controls, which allow constant improvement and provide a basis for good practices. However, some systems are still dependent on manual provisioning tasks or not yet fully integrated, the unified view of accounts and access for users is incomplete. |
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. Unified view information for accounts and access is centralized into a reporting, provisioning, and workflow tool that allows all business units and level to participate. A cohesive framework for provisioning access across the organization is implemented, which reaches all key systems. The unified view allows the generation of reports and metrics that can assist LOBs(Line of Business) managers and senior management in decision making. The majority of access provisioning 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 Identity Management. 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 through a uniform and coherent process across the organization, and accountability for requesting, approving and sponsoring access must be maintained. A unified view of access must be available for managing, reporting, and auditing.
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 Provisioning: A uniform workflow-based provisioning solution must be provided to all users for requesting, approving, or sponsoring access, and individual workflow request must have lifecycle attributes for escalation, reminder, expiration, and other parameters. The provisioning solution must also be coupled with e-mail for notifications and tasks assignments.
Standard vs Performance and Monitoring: Provisioning and Self-Service Metrics must be reported on a montly basis, and trends must be determined. Event-driven reporting and alerting, and automated provisioning actions must be configurable.
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 account in the tool, or the definition of a specific provisioning workflow with attributes like escalation interval and path, configuration of e-mail notifications for assigned tasks, etc. Procedures 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.
Asset | Confidentiality | Integrity | Availability | Interface | Controls | IDMThreats | Prob/yr |
---|---|---|---|---|---|---|---|
Payroll App | Confidential | Critical | Urgent RTO = 24 hr |
Web, J2EE | password, groups | Brute force attack, ghost accounts, access overspill | 20% |
CRM App | Internal | Important | Important RTO = 72 hr |
Web, .NET | password, app roles |
Brute force attack, ghost accounts | 10% |
Customer Order Processing App | Internal | Critical | Important RTO = 48 hr |
Desktop app | SSO with AD Domain, AD Groups | AD admins can provision access, reset passwords | 40% |
Procurement App | Internal | Important | Important RTO = 72 hr |
Desktop app | SSO with AD Domain, AD Groups | AD admins can provision access, reset passwords | 30% |
eCommerce Web Server, B2C B2B | Public | Critical | Critical RTO = 2 hr |
Web, J2EE | password, SSL | Brute force attack, Ghost accounts | 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 Identity Management 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, Identity Manager allows to centrally manage passwords and enforce password strength or complexity, and other attributes like expiration interval, which would reduce the risk of Brute force attacks on passwords. More important, it can deprovision account and access in relation to the lifecycle of users and their accounts, and disable or remove orphan accounts. Additionally, through Password Self-Service, less calls to the Help Desk would translate into cost savings and faster access recovery(Availability) for users who forgot their passwords.
A simple deployment plan example derived from the Waterfall Model
The waterfall model, a simple model but sufficient for a small project, shows a process where Identity Management experts are to follow these phases in order:
Planning and Design
The important task in deploying an Identity Management product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced resources at this point. Frequently prototyping business logic may help reduce the risk that the requirements are incorrect.
Once the general requirements are gleaned from the client, an analysis of the scope of the deployment should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of the project.
Implementation, testing and documenting
Implementation is the part of the project where Identity Management experts actually configure business logic for the project.
Business logic testing is an integral and important part of the project. This part of the project ensures that overlooked use cases are identified as early as possible.
Documenting the internal design of business logic including rules for the purpose of future maintenance and enhancement is done throughout development, together with updating the list of use cases that are in and out of scope.
Deployment and maintenance
Deployment
Deployment starts after the business logic is appropriately tested, is approved for release and ready to be deployed into a production environment.
Software Training and Support is important because a large percentage of software projects fail because the Identity Management experts fail to properly transfer knowledge around the software components and the specific use within the project to the operational team.
People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new users of the Identity Management solution.
Maintenance
Maintenance and the lifecycle of the Identity Management deployment require a minimum of formal change management best practices. A process to monitor the release of minor and major software updates or patches must be implemented, and also a process to document changes to the deployed solution, will need to be designed jointly by the Identity Management experts and the operational team.
For more information and content, check http://www.infosecprogram.org