Establishing Quality Access and Control
Any company’s approach to reducing access-related risk in their systems should follow a standard process. Think of this as a funnel, beginning with total reduction in access, and proceeding to more specific issue remediation. In addition, there is a parallel process related to policies and procedures, and controls. If done correctly, many of these activities need only be updated or reviewed annually.
The initial step is to understand the organizational environment - information systems are a combination of people, process, and technology, with people being the most complicated and unreliable piece of the puzzle. In order to be as effective and efficient in reducing access-related risk, you need to know who's in charge of what. These are your stakeholders.
- Identify the application in scope (e.g. ERP)
- Determine the data in the application
- What is it? (e.g. financial data)
- What is it for? (e.g. financial reporting in 10Q and 10K)
- Determine who owns that data in entry, movement, and reporting
- Who is responsible for entry? (e.g. sales, accounts receivable, etc.)
- Who is responsible for maintenance? (e.g. accountant, system admin, etc.)
- Who is responsible for what comes out the other end? (e.g. controller, CFO)
- Who else is involved, and who do they report to? (e.g. finance, procurement, manufacturing, etc.)
Define the Rules
Now that you know who oversees what, you can begin determining what the 'rules of engagement' are. Short, concise, clear policies are what drive uniform behavior in organizations: policies are the company’s rules. Interview all of the key stakeholders you identified in the earlier exercise, and ask them some simple questions:
- What risks are related to the data you own (e.g. financial misstatement, fraud, error, etc.)
- What rules could be put in place to reduce or eliminate this risk? (e.g. reduce access, regular reconciliations, etc.)
- What types of system users are the riskiest? (e.g. system admins, generic accounts)
The output of this exercise will be a brainstorm of potential rules. Consolidate the similar items and put the resulting list into order of importance. Often the top of the list consists of items such as:
- “System administrators should not have access to transact";
- "System users should have the least privilege needed to accomplish their job duties", or;
- "System users should be reviewed annually for Segregation of Duties".
Like the rules of a basketball game, these policies will now drive the rest of your behavior going forward, creating a unified understanding of end goals that can be referenced throughout the process.
Reduce the Noise
Most business systems are rife with unnecessary access. Security is often undervalued during implementation (who cares who can do what if nobody can do anything!) and, when left to its own devices, will erode over time. The initial user might be a single business user with access to do anything, and that user gets copied when the second finance resource joins the team, and so and so forth. An additional factor is the amount of access in most ERPs and business system, much of which is not understood (think of the buttons on your television remote: too much choice is not a good thing).
The first step in this exercise is to reduce the overall access in the system to only what folks need. The purpose of this is two-fold: by reducing overall access you are lessening the amount of 'noise' you have to deal with in the more targeted later steps of this process, and you are performing a heavy-duty one-time access review to reassess everyone's access. You can think of this as a baselining exercise - you are creating a foundation that your will build your security on top of once-and-for-all.
Warning: this is a heavy exercise, and can take some time to get through - a few tips as you proceed:
Take multiple sweeps at initial rationalization - you will get pushback but can't bog down in arguing about corner-cases and one-off use cases. Reduce as much as you can agree on, rinse, repeat.
Break the job up into smaller parts - if you try to take on the whole exercise at once, you increase your chance of failure. Instead, break up the exercise by owner or business cycle.
Ensure you have leadership's buy-in, so that you can escalate any 'unsolvable' debates to a decision maker, and then move on.
The following example outline can help you determine your steps - make sure you document your final steps as these will become the procedures you follow upon reiteration.
- Run the Role Access and User Access reports in the Access Reviews module in Fastpath Assure and export to excel
- Conduct an initial meeting (30 min) with your stakeholders to introduce the exercise, including expectations and timeline. Also address 'markup' requirements: how will reviewers denote access reduction, modification, or addition.
Note: there may be an initial step to determine optimal roles in the organization to then compare access against - this is a much more complex process involving many more people in the organization, including Human Resources.
- Distribute user reports to stakeholders and set follow-up meetings to ensure timeliness and opportunity to review questions. System Administrators or Business System Analysts should be involved in this meeting to (a) provide clarity, and (b) ensure clear communication of what changes need to be made.
- Set a deadline for system administration, and close with a meeting to review all changes made (including Fastpath reporting for before-and-after review). Ensure that any compliance or audit related considerations are included - approvals for changes, ticketing, etc. need to be included, though can be aggregated as part of a project approval if allowed.
Once this exercise is completed, you have two outputs: the first is much cleaner access reporting and a resulting reduction in access-related risk; and the second is a blueprint for annual or quarterly audit certification procedures which can be used to configure the Fastpath Access Certification module to automate going forward.
Reduce your Risk
Now that you have users in the system with only the required access they need to do their jobs, you are ready to focus on risk. There are two areas of focus here: critical access and segregation of duties.
- Critical Access: access to key functions in the application that allow modification of how the system operates, including who has access, and access to powerful computing functions that can have a broad impact on the data that comes out of the application (e.g. post journals, mass upload, data deletion, etc.)
- Segregation of Duties (SoD): access to two business processing capabilities that allow users to complete key pieces of transactions without detection (e.g. modify a vendor bank account and then process a payment to that vendor, mis-receive inventory and then adjust inventory balance to cover mistake, etc.)
Critical Access and SoD definitions are provided out-of-the-box in Fastpath Assure, and you can certainly use them to drive your process. The best practice here would be to determine your own needs, and then to modify the Fastpath rulesets to fit your specific use cases. Critical Access and SoD definitions are typically driven by a Risk Assessment, which is too large of a concept to cover here - this may be an existing process in your organization, or one that you need to develop (reference Fastpath blog on risk assessments).
Where the review of access performed prior to this relied on business cycle or sub-cycle ownership, the ownership for SoD is typically higher up in the food chain. The reason for this is that SoD conflicts often encapsulate a business cycle or can cross business functions (e.g. where access to Receive Inventory can be reviewed by the Receiving Manager, the conflict between Receive Inventory and Inventory Adjustment probably needs to be reviewed by the Director of Inventory). The hierarchy created in the first step should still apply here - if not, repeat an abbreviated version of that process to determine conflict ownership. If Critical Access was addressed in the prior review, then you don't need to address it here.
In order to review SoD and Critical Access, reviewers should be asked to look at appropriateness of access and then to determine if access should be remediated or mitigated:
Critical Access: You should involve both business and system administration resources in this meeting as it can get quite technical based on the technology. *This is slightly paraphrased as it is a reiteration of the steps in the previous section
- Run Critical Access reports from the Access Reviews module in Fastpath Assure. An alternative is to look to the standard reporting in the Reports section of the Access Reviews module. Export if needed.
- Conduct reviews live with key stakeholders – this will allow deeper consideration of access risk, clarification of understanding on both sides, and buy-in from the system administration or IT team (those most likely to have critical access).
- Agree on remediation or mitigation
- Implement changes and controls
- Complete a completion review to validate that goals were achieved.
SoD: Most business systems use a role or responsibility concept to aggregate and assign access to users. Leveraging the funnel concept, we should always begin with where we can have the most impact before focusing on more granular tasks. The below procedures should be followed twice - once at the intra-role/responsibility level, and then again at the user level. As any user with an inherent role conflict will show up on the latter reporting, you can reduce your total effort by nipping those in the bud at the role/responsibility level first and then addressing those conflicts created by owning two or more roles/responsibilities. *This is slightly paraphrased as it is a reiteration of the steps in the previous section.
- Run SoD reporting and export if needed.
- Conduct meeting to outline procedures, expectations, and timing.
- Reviewers will determine which conflicts should be remediated (removed) or are mitigated (addressed by controls)
- Deadline meetings should be conducted to ensure clarity of request, and to discuss remediation with system administration team.
- Where remediation is not advisable, mitigating controls need to be developed and implemented.
- A final review meeting should be conducted to discuss the final results - Fastpath reporting should be used to show before-and-after.
Once complete, your organization will have addressed all Critical Access and SoD risk and will have clean reporting from Fastpath to provide to management and or audit/compliance.
Lock it Down
Now that you have cleaned up access and addressed your access-related risk, it is time to protect all the good work you have done. Leveraging the Identity Management module within Fastpath Assure will enable your organization to avoid adding risk or noise back into your environment. You can leverage the ownership identification that you produced in the prior steps to determine who should review access requests, and then configure Fastpath to risk report all access requests and route them to the appropriate reviewer. Technology permitting, Fastpath can be setup to write directly to the security within the in-scope business system, alleviating unnecessary work on the part of the system administration team.
Automate the Process
Even with Identity Manager in place and policies and procedures defined, nothing is foolproof. Mistakes get made. In order to maintain a healthy environment, you need to perform a regular review. Fortunately, you've already defined the procedures of this review in the prior exercises. The cadence of these procedures depends on how dynamic your access environment is, your appetite for risk, the granularity of your manual controls, and your audit/compliance situation. Leveraging Fastpath Assure's Access Certification module, you can automate the procedures already completed, set them on a cadence, and let them run. All resulting reviews are logged within Fastpath for status and completion review. Full Reviews are useful for compliance reporting, while rolling reviews can be more frequent operational activities to ensure issues to arise during the year.
The Audit Trail module in Fastpath Assure can help with identifying any weaknesses in the policies and procedures developed during this project. By monitoring changes to configuration, standing data, and key transactions, you can identify any issues immediately. Any inappropriate activity can then be addressed via access remediation or control mitigation. In addition, any policies driven by an assumption of key system configurations (e.g. Oracle R12 configuration that prohibits creation and approval of the same transaction by a single user is enabled) can be bolstered by the monitoring of that configuration.