In my years of performing organizational security assessments, application level vulnerability testing usually included an evaluation of the application’s ability to support the “segregation of duties”. Especially assessments driven by regulatory or compliance requirements, such as PCI DSS, HIPAA or SOX.
What is the concept of segregation of duties (“SoD”)?
According the AICPA, SoD is “a basic building block of sustainable risk management and internal controls for a business.” Essentially SoD seeks to ensure that key business processes incorporate sufficient checks and balances to ensure that critical touch points are distributed to various people and/or departments.
Think of a nuclear weapons system.
What if the keys, locks and codes were all controlled by a single individual? A recipe for a literal disaster. In the corporate world, SoD seeks to protect against fraud, business disruption and other forms of malicious activities.
At the application level, an SoD assessment focuses on the Roles the application defines, the Permissions attached to those roles and the Users that assume one or more of those roles. Simply put, no single role should have permissions that grant to much control over a business process. And no single user should have multiple roles that allow that user to subvert the checks and balances associated with the process.
Think about a company that does business with multiple vendors – allowing a single individual (or even department) to have the power to do all of the following: A) set up a new vendor B) create payments to that vendor C) and then approve those payments can be a recipe for corporate malfeasance.
SoD has been a key component of security assessments for quite a while and was a key finding in audits of companies like Enron and Lehman Brothers. Hint: Both are no longer around due to massive corporate malfeasance.
But SoD is evolving. In our changing regulatory environment, laws such as GDPR and the California Consumer Privacy Act are not just focusing on what people do, but also on what they see. These new regulations are introducing user rights around who is accessing personal data – especially their sensitive data, such as social security number, bank account information, etc.
I like to use the example of me not receiving a scheduled paycheck.
I don’t know where the funds went or how the bad actors potentially got in, but chances are, my second call (the first being to the bank) will be to my employer. My bank account information is typically stored in a work system, typically an ERP application, to enable direct deposit. In the new regulatory environment, I have the right to go to my employer and demand to see who has accessed my bank account information. This would include legitimate users as well potential bad actors. Ultimately, I would want to know if that account information was changed to facilitate a theft of my paycheck, but determining who has accessed the account data is a necessary first step.
SoD is about trying to manage what people can and can’t do.
I’m coining the phrase “Segregation of Access”, or “SoAx”, to now add the requirements around being able to enforce what people are able to see. Who needs to be able to see my bank account data? Probably just me and maybe a couple of designated Payroll employees. Yet, that data, as well as other sensitive items about me are typically in full view in a system – on screens with other innocuous data that system users may need to see to do their jobs.
For example, if my manager accesses my employee record to review my role or department settings, typically my date of birth and social security number are on display. Data my manager doesn’t need to see to do their job. The principle of SoAx should ensure that sensitive data is only accessible by the people that need to see it to accomplish their job. And maybe adding controls around access that ensure those legitimate users are only able to access that data while working onsite, reducing the risk of stolen credentials, etc.
By limiting the access to a “need to see it” posture, companies will be much better prepared to meet regulatory and compliance driven mandates to report on the access of sensitive information.
Contact us to learn how Appsian can help bolster your SoAx (yes, I’m hoping the acronym catches on) efforts.
