SoD Reporting: What should I do?
SoD Reporting: What should I do?
What to do after running a Separations of Duties (SoD) report:
A Tactical Approach
Today’s complex IT environments are difficult to govern and secure. To help identify and manage risk across one or more enterprise applications organizations turn to Governance, Risk, and Compliance (GRC) software. A common goal of implementing a governance solution is to increase application security, reduce risk, and enhance the governance process. For many organizations who have done this crucial first step, there is often a struggle with what to do after running that first report. So, you’ve implemented a GRC solution. You’ve developed a set of risks and rules to evaluate your systems, and you’ve run your first Separation of Duties risk analysis. When you finally look at the results the report shows thousands and thousands of rows of data that seem to go on endlessly. The volume of data and complexity of the reports often present a daunting task to make sense of and develop a plan for remediation. This often leaves even the most seasoned user management teams struggling with next steps.
The Initial Report: Sifting through the Data
The first step is understanding the results of the SoD and Sensitive/Critical Access analysis report. These reports often contain thousands of rows of data and can look very overwhelming. The first step in understanding a seemingly unmanageable dataset is to break down the data. There are many ways to accomplish this, some common considerations include:
- Risk Frequency – Instead of looking at the risks on a user by user level, consider looking at the frequency of each risk. This will put a focus on the risks with the highest frequency to be addressed first.
- Risks by Process Area – Grouping the risks by process area will also help with the prioritization and analysis. Understanding which process area(s) contains the most risks can help identify a starting point by either tackling the biggest impact area or finding some “lower hanging fruit” to test out and refine the remediation process.
- Risks by User – Looking at the users that are the “heavy hitters”, with the most risks, may highlight the need to reduce access to administrative roles. Further, this can help easily identify opportunities to reduce risk exposure by removing excessive security roles from users.
- Risks by Roles – Which security roles have inherent risks? If roles are architected without risk violations, then when they are assigned on a standalone basis no new risks will be created.
- Risk Ranking – SoD tools typically allow risks to be ranked by severity, such as High, Medium, Low. Grouping risks by these risk levels can help security teams focus on the biggest risk points for the organization.
Once the data is analyzed and sorted to be more meaningful, it is far easier to engage with business process owners and managers to review these violations and formulate an effective plan for addressing the identified issues.
Remediation - Where To begin?
Once the business team has had a chance to review and digest the data, the business and IT teams must decide on an appropriate place to begin the remediation. This is a key step in the process to achieve alignment and buy-in and one that can help pave the way to success. Once a strategy for addressing the violations on the SoD report is established, a tactical approach on how and where to begin is influenced by many factors, including:
- Quick Wins – Select several small changes that will show immediate results. Even small wins can help the business become more confident in the ability to keep the business full operational
- Measured Approach – Design the approach to mitigating these risks so that only a small group of users is impacted at one time. Consider rebuilding roles or entitlements so that groups are incrementally migrated rather than all done at once.
- Select High Value Changes – In the event that the business would like to see change happen quickly, select several simple changes, such as the removal of a single entitlement that will result in big change.
As a key component of the mitigation plan, the team must consider the following
- Usage - It is helpful to understand usage. For the users and roles that contribute to violations what access has been used by anyone assigned the various roles vs. what access is assigned to roles, but not used by individuals who are assigned the role(s) in question.
- History - It is helpful to understand the organization, access management policies, the ERP system, and how these have evolved over time. This history enables the background details to like why roles built a certain way or assigned to specific users.
All of the above needs to be considered and balanced in order to identify a remediation plan, priority of roles/business processes, and ultimately scope.
When reviewing the SoD results, the business and IT teams may find that the security model does not adequately support business needs. This may manifest itself through broad based access roles that lack required flexibility. In this case, the most effective approach to mitigating/remediating risks may be the removal of entitlements, a targeted role rebuild, or even a complete security architecture redesign. One or more of the following approaches are often adopted to accomplish security and access mitigation/remediation goals:
- Ground Up Design: This approach is based around a minimal set of permissions for business processes or tasks. This can be accomplished by working closely with key functional team members to “build up” the permissions in a role or roles, while executing key business functions in a test system.
- Data Driven Approach: This approach focuses on a data driven approach to minimize the initial heavy lift from the business function teams. In this approach, usage history is leveraged to develop and construct new security roles with a focus on least privileged access while providing the business with the necessary permissions to enable day to day responsibilities.
- Targeted Role Design: Some business requirements and needs are much more time sensitive and may not have enough time for a full role redesign or remediation. To address these scenarios, a targeted or focused approach can drive results over a narrow scope of roles or business processes. Based on input form the SoD reports, audit, compliance, and/or the business a subset of roles, risks, or processes are prioritized and redesigned/remediated using either a ground up role build approach, or a data driven role build approach.
Remediation: An Ongoing Task
Separation of Duties risk mitigation is not a simple task. It is also not a once a year activity. Organizations should consider SoD and risk mitigation as an ongoing activity, requiring consistent review and constant refinement. To support a sustainable approach to security management many organizations require significant assistance and the right approach to manage the risk for the business. Altum’s experienced practitioners work with organizations to interpret the overall SoD picture, security architecture, and business operations to determine the right fit for role redesign or remediation. If you would like help in determining the approach that best fits your organization, are looking for a place to start the Separation of Duties clean up journey, and would like to see how Altum Strategy Group can help, please feel free to reach out.
- Risk Management
- Maximizing Technology
- Digital Transformation
- Efficiency and Effectivness
- risk mitigation
- looking forward
- Remote Workforce
- Separation of Duties
- Software Selection
- Privileged Access Management
- Supply Chain Management
- User Access
- artificial Intelligence
- supply chain