Designing Security Controls for Critical Applications

There are many resources that companies use to assist them when they are designing IT security controls. Typically, companies utilize a risk-based approach, meaning they start by analyzing risks in their environment; starting with designing controls to mitigate the most critical and high-risk activities first. Risk ratings are derived in a multitude of ways; some are often derived by looking at systems that support high-risk processes within the organizations. Such examples include: Record to Report (General Ledger and Financial Reporting), Purchase to Pay (Payables and Procurement), and/or Order to Cash (Order entry and Receivables). Auditors usually determine a materiality threshold for processes and underlying systems that are considered key to the organization.

When designing controls to mitigate risk, it is important to consider many factors. A well-designed control will explicitly detail the who, what, when, where, why and how of the control; i.e. who is responsible for performing the control (e.g. Controller or Line Manager), when does the control become validated (e.g. Quarterly, Annually or continuous), etc. There are also several types of controls and control enablers; these could be Preventive or Detective controls. Automated or Manual, and/or a combination thereof. The graph below provides a visual depiction of the diverse types of IT security controls that might exist in an organization. It also provides some detail of the effectiveness of these controls in mitigating risk.

Designing and defining controls in an organization is an exhaustive process. Typically, the most effective controls are in the upper left quadrant (Automated – Preventive controls). This is primarily due to the pervasive nature of these controls and less handling of the control which reduces “human error”. It is recommended that companies utilize guidance that is readily available from various organization throughout the world to assist them in defining control objectives, e.g. COSO or COBIT, and designing controls that meet the specifications of globally recognized standards, e.g. ISO or NIST. It is also important to understand where your company exists in maturity to some of these standards.  Some companies don’t have the infrastructure or manpower to effectively implement certain controls. It’s good to perform a fit-gap IT Risk Assessment on your control environment to understand how much work needs to be done.

As you can see from the figure above, there are several types of controls that can be implemented to make any system or process more secure. For the purposes of this blog, I am going to focus on four types of business process controls: Access, Configuration, Transactional and Reporting. In the rudimentary “Create Journal” sub-process I have detailed below, I have included where one might expect to design specific controls. There will, of course, be other controls involved in this process (e.g. policies and procedures, training, provisioning, access certification, etc.).

As you can see in the figure below, in almost every activity there are access controls. Who will we provide with the access in which to transact these activities (e.g who has the ability to create a journal or approve journals that have been created)? There are configuration controls also, which determine setup around how the application is going to operate (e.g. if approval workflow for a specific journal source is turned on/off or if subledgers are frozen once they are uploaded into the main ledger). There are transactional controls that can be designed to add an extra layer of security when specific types of transactions are entered (e.g. when a journal entry of more than $1M is entered into the system). There are reporting controls provided to those responsible for monitoring this process (e.g. all denied journal entries). As part of access controls, there are also segregation of duties (SOD) controls to help ensure that no one user can transact every activity within the process or that no user has access that might provide them with the ability to complete transactions that have the potential to be fraudulent.

At Saviynt, we have utilized globally recognized standards and frameworks from ISACA, NIST and ISO, to assist us in building out the risks. Our SOD and critical access rules cover several business cycles, sub-processes and master pillars. We have defined fine-grained rules that go down to the activity level for all of the ERP applications that have been mentioned. Each activity is mapped to the entitlement used to perform that activity specifically for each application. We also have the capability to perform cross-application SOD testing, so for example, if you are maintaining sales orders and customer activity in Salesforce, but you perform all Accounts Receivables activities in Oracle EBS, we can test cross-application SOD to ensure no users have too much access or inappropriate access within the Order to Cash business cycle. We also have tailored specific analytics for each application so, whether a company needs to specifically test for AZN Menus in Oracle EBS or wants to understand who has Production development capabilities assigned via Application Designer in PeopleSoft, we can design specific analytics for each application. Custom transactional and configuration controls are also supported.

We have deep business process control and application security control knowledge at the heart of our product’s design. We understand that controls are important to our customers, so we put a lot of attention to ensuring appropriate controls are bundled with the product and are also available in Controls Exchange, where our customers can contribute and collaborate with others.