10.) GRC ARA Part 1.1

Understanding Risk Analysis in GRC

Introduction to Risk Analysis

• The video begins with a welcome message and references previous content on risk analysis, types of risks in Governance, Risk Management, and Compliance (GRC), rule sets, and their components.

• The presenter outlines the focus of this video: different reports under access risk analysis and their usage.

Access Risk Analysis Reports

• The presenter navigates to the GRC interface, specifically the access management section where access risk analysis reports are located.

• It is noted that users typically utilize around four to five reports regularly, with some being used bi-weekly or quarterly depending on organizational needs.

Types of Reports Explained

User Level Risk Analysis

• User level risk analysis checks if a user has existing risks associated with their access rights. This report is essential for monthly or quarterly submissions to organizations.

• Users can generate reports based on specific user groups or individual users by selecting systems and filtering usernames starting with certain characters.

Uploading User Lists

• Users can upload lists of usernames via notepad files for bulk processing in risk analysis instead of using Excel sheets.

• Instructions are provided on how to format the username list correctly before uploading it into the system.

Selecting Risk Levels and Rule Sets

• After uploading usernames, users must select desired risk levels (high, medium, low, critical) for their report.

• The presenter demonstrates selecting a global rule set for analyzing risks associated with dialog users.

Background Job Processing

• For larger user selections, it's recommended to run jobs in the background. Users can check job statuses through background jobs functionality within the system.

User Level Simulation: What If Scenarios?

Understanding User Level Simulation

• User level simulation assesses potential risks when a user requests additional access after approval from security teams.

• This tool helps determine if granting extra roles will introduce any new risks based on existing role configurations.

Executing User Level Simulations

• To perform simulations, users need to specify systems and roles while allowing multiple selections for various users requesting similar roles.

This structured approach provides clarity on key concepts related to risk analysis within GRC frameworks as discussed in the video.

Role Level Risk Analysis and Remediation Process

Understanding Include and Exclude Functions

• The "include" function is used when analyzing risks for users requesting a specific role, allowing the addition of roles to assess potential risks.

• The "exclude" function helps determine if removing a role eliminates associated risks, essential during the remediation phase.

• When assigning a new role to a user with existing roles, it's crucial to check for conflicts by clicking on "risk from simulation only."

• Failing to click this option may result in overlooking existing violations that could affect risk analysis outcomes.

Running Risk Analysis

• After setting up roles and users, you can choose to run the analysis in the background for many users or in the foreground for fewer (5-10).

• Role level risk analysis involves checking pre-existing roles against their assigned transactions (T codes) to ensure they are risk-free.

Role Level Simulation

• Typically, organizations have dedicated teams responsible for verifying whether created roles contain any violations or risks.

• Users can directly input role names into the system and run analyses to identify any associated risks.

Adjusting Roles and T Codes

• Role level simulation allows adjustments before implementing changes in the system; adding new T codes can be tested without immediate execution.

• Users can modify permissions related to authorization objects within simulations before finalizing changes.

Managing Violations

• If there’s an existing role with identified risks, you can simulate removing certain T codes using the exclude function to see if it resolves violations.

• This process ensures that any modifications made will not introduce new risks while aiming to remediate existing ones.

Reporting and User-Level Management

• Profile-level analyses are less frequently utilized compared to user-level assessments which focus on invalid mitigation assignments.

• Reports help identify invalid mitigations that need addressing, such as extending validity dates or reassigning valid monitors.

Mitigation Controls and Role Management

Overview of Mitigation Controls

• The discussion emphasizes the importance of adding mitigation controls directly rather than focusing solely on users. This approach allows for better management of roles and responsibilities.

• Users can be assigned as mitigation owners, with the ability to change or extend their ownership if a mitigation control expires.

• Mitigation control IDs are typically valid only for specific time periods, highlighting the need for careful tracking of these timelines.

Validity and Extensions

• If there is a need to increase the validity period of a mitigation control, it is possible to manage this at both user and role levels.

• The concept of "invalid mitigation" is introduced, indicating that both user-level and role-level mitigations can become invalid over time, necessitating regular reviews and updates.