A recent New York Times article described a scenario that most likely outraged the public and became a recurring nightmare for security administrators. The article described a breach at Stanford Hospital in Palo Alto, California, in which the names of more than 20,000 emergency room patients were posted for more than a year on Student of Fortune, a privately owned website designed for helping students with their homework.
Yes, that’s correct; the data was public for more than a year. According to the New York Times article, a spreadsheet with the patients’ data was attached to an email message sent to the Student of Fortune website asking for information on how to convert the data into a bar graph.
Could this breach have been avoided? What kind of controls governing access to this sensitive data were in place at Stanford Hospital?
This article piqued my interest in procedures that need to be taken to analyze users’ access to data in an SAP system. An example is running segregation of duties (SoD) reports in SAP BusinessObjects Access Control. However, just running these reports is not enough. You also have to validate the data that is shown in them.
According to Jayne Gibbon’s article for GRC Expert, “How to Validate Segregation of Duties Results,” “SAP BusinessObjects Access Control is a reporting application that depends on the segregation of duties (SoD) rule master data to analyze users’ access in the connected systems. When you are trying to prove that the results of the analysis are correct, your analysis needs to consider both the master data rule set, which is the responsibility of the company, and the processing logic of SAP BusinessObjects Access Control, which is the responsibility of SAP.”
Jayne adds that “[u]pon first running segregation of duties (SoD) reports in SAP BusinessObjects Access Control, management staff can become overloaded with data and assume that the results simply cannot be correct. It is then the responsibility of the owners of SAP BusinessObjects Access Control to prove that the reports are accurate.”
In her article Jayne also states that “[m]anagement has two types of concerns with regard to [SoD] reporting accuracy….
• False negatives: Users are not showing in the report in which you think they should show. This concern is the more risky of the two concerns, as management would be unaware that there is a risk in their environment because SAP BusinessObjects Access Control is not reporting them. From an audit and control perspective, this issue is of most concern.
• False positives: Users are showing in the report in which you think they should not show.”
There are several steps that are necessary for validating reports with false negatives and reports with false positives. With regard to false negatives, Jayne states that the first step is “to check if there are rules that exist for the system for which the risk analysis is being run. This check has several parts:
a. First, check to ensure that risks are loaded into the system. Go to RAR > Rule Architect > Rules > Permission Rules. Enter the Risk ID that you are concerned with and click the Search button.”
Regarding false positives, Jayne states that “[t]he first step with false positives is to validate the rule against the user’s security. As with false negatives, many times SAP BusinessObjects Access Control is correctly reporting based on how the rule is configured.”
In her GRC Expert article titled “Ensuring SoD Library Quality,” Mari Hurskainen states that “[c]ompanies using SAP BusinessObjects Access Control are ultimately responsible for the thoroughness of their segregation of duties (SoD) library, even though SAP delivers a baseline ruleset …. To have trust that SoD rules are complete and accurate for a certain environment, that rule set needs to be reviewed. The IT department needs to deploy, and to some extent support, the risk analysis and remediation tool (RAR) and the SoD library. However, most of the users benefiting from effective monitoring of SoD risks are on the business side. It may prove difficult to make business users see the benefits of the SoD principle and devote enough time and energy to SoD risk review. Only when the correct people are involved in creating and updating the SoD risk rules, and committed to the task, will the SoD library be valuable and actually help in protecting the company data and operations.”
These two articles underscore the challenges related to implementing effective SoD rules within an organization. The IT team needs not only to validate the data in the SoD reports but also to review the accuracy of the SoD rules themselves.