Application-level vulnerability monitoring usually includes evaluating the application’s capacity to promote the segregation of duties (SoD) as part of organizational security assessments. Specifically, these checks are guided by compliance requirements as demanded by regulations such as PCI-DSS, GDPR, HIPAA, or SOX.
What is Segregation of Duties (SoD)?
SoD is a vital building block of the sustainable management of risk and internal controls of a company. Essentially, SoD tries to ensure that key business processes have sufficient controls and balances to ensure the distribution, between various entities and/or departments, of critical touchpoints. In the business world, SoD helps to defend against fraud, market disturbance, and other kinds of malicious activities.
A SoD assessment at the application level focuses on the ‘Roles’ specified by the application, the ‘Permissions’ attached to those roles, and the users assuming one or more of those roles. Simply put, permissions that have a great deal of control over a business process should not have a single function. And no single user should have multiple roles that allow the user to subvert the checks and balances associated with the method.
Think of an agency dealing with many suppliers. It can be a corporate malfeasance formula to grant a single person the power to do any of the following: a) set up a new seller, b) create payments for that seller, c), and then approve those payments.
SoD has been a central component in security assessments for quite a while. Yet SoD is developing steadily. In our changing regulatory environment, laws such as the GDPR and the California Consumer Privacy Act (CCPA) are focused on what people do and what they see. These new laws impose user rights over who accesses personal data, specifically their private details, such as their bank account information, and social security number, etc.
The Relevance of Segregation of Duties (SoD)
To incorporate the conditions around enforcing what people can see, we can use the word ‘Segregation of Access’ (SoAx). Who wants to be able to see your bank account data inside your organization? Maybe just you and maybe a few workers of Payroll. Yet, in a system and other confidential data about you, the information is usually in full view, on screens with other data that computer users can need to use to do their job.
For example, if your boss accesses your employee record to check your bank account details, job or department settings and date of birth are usually on show. In order to do his job, your boss does not have to see all your data. The SoAx principle should ensure that confidential data can be viewed only by those who need to see it to achieve their job. And likely implement access controls to ensure that only when working on-site, certain legitimate users can access the information, to minimize the risk of stolen passwords, etc.
Conclusion In order to report on access to sensitive information as required to comply with regulatory and compliance-driven guidelines, by limiting access to a “need to see it” role, businesses can be far better prepared. There are extensive standards that need to be complied with as per data privacy legislation. In order to secure company data and adhere to regulatory requirements, companies would do well to incorporate data protection strategies and tools