In the first part of this series we introduced why Access Controls in Oracle EBS are important and how to communicate that importance to stakeholders (or roadblocks) in your organization. The second important piece is establishing some credibility, which also means knowing what you are talking about. In this article, we will cover some of the basics of access controls. I’d highly recommend not reading this laying down or immediately after lunch.
Ummm, what’s a control?
If you don’t know what a control is, don’t be embarrassed – I spent more time than I should have not fully grasping this concept as a professional auditor! The formal definitions don’t help much either: internal control is a process or set of processes put in place to ensure the achievement of an organization’s goals or objectives. Remember that much of audit regulation is developed by academics and professionals with years of experience – the concept of a control to them is so core to their thinking that they’ve probably taken it for granted!
Let’s simplify things a bit. Company’s sell stuff for money. In order to sell stuff, people need to do things. The things these people do, follow some sort of process – e.g. to sell a sled, you need to make a sled based on a design, put it through quality review, validate it with any regulatory authority, ship it, etc. These processes make up what a company does and how it makes its living. Some processes do things (e.g. make a sled) while other processes decide things (e.g. quality review asks, “can we sell this one”). These processes that make a decision are called controls.
The difference between a process and a control is if there is a decision point or not.
The basics of Access Control in a financial system
Let’s define the scope of our discussion here: we will be speaking about access controls related to financials systems. While I could wax poetic about controls in general, that is not the purpose of this article (unfortunately) – I will save that for putting my kids to bed at night.
Preventative v. Detective
Controls in general fall into one of two categories: preventative or detective. Bear with me here: preventative controls prevent things from happening whereas detective controls detect things that have already happened. Every great time-travel movie that involves going to the past, at its core, is about preventing something that was already detected. Once Fastpath has patented our time-travel technology, we will write that blog post – for now we will deal with our current constraints.
Points of Access Control
Access Control focuses on three points of the access process. Access is granted (a), access exists (b), and access is terminated (c). Points a and c are preventative – denying access to someone prevents a myriad of unrealized occurrences as does terminating their access. Point b is a detective control – it operates both as a backstop in case of a or c failing, as well as a means to identify where access needs might have changed without detection.
Types of Access Control
I will now bring these concepts together and elaborate on the types of access control in a non-exhaustive list:
o Configuration: system settings, code, or scripting that enforces a control
- Password settings – configuration of password requirements
- Workflow – scripting or configuration of approval paths within the system such as routing of journal entries for approval
o Transactional: controls that operate on a transactional basis
- Access Grant Approval – approval of access requests
- Access Termination – timely removal of access when no longer required
o Periodic Reviews: manual review of access setups to identify errors
- User Access Review – review of users and their assigned role/responsibility/group
- Role/Responsibility/Group Review – review of role or responsibility to see what they are comprise of
- Critical Access Review – review of users with elevated access – i.e. access that allows the user to change how the system operates
- Segregation-of-Duties Review – review of users for combinations of access prohibited by company policy – e.g. create a supplier, pay a supplier, approve a payment
- Security Configuration Review – review of the system configurations that support access, such as password policies, workflow, etc.
o Automated Monitoring: systematic monitoring of access to identify errors – this oftentimes mimics the manual reviews mentioned above but is more immediate and reduces the period of exposure due to access errors or breaches
- Firewall/Intrusion Monitoring
- Access and SOD Monitoring
But where do I start??
I can’t finish this section without some basic guidance on how to make the above theory practical. All control environments begin with policies – guiding principles that define the rules of play. For example, a policy would be that IT users don’t have access to perform business transactions. Next would be a procedure or control – e.g. when approving access, IT users should not be granted access to any business functions. It is that simple … in theory. My overarching recommendation would be to leverage your Internal Audit function, or if none exists to talk to your auditors that come on site. If you have neither internal nor external auditors, then reach out to a local public accounting firm to ask for some help!
The next article in this 4 part series will discuss the basics of Oracle’s security model and how you can apply the concepts from this article to your environment, read it here.