SAP BO BI 4 Security – Quick & dirty security: the short-cut can become the longest cut
“Your security model is a living breathing entity.” Xoomworks BI 2015
“Oil and Gas organisations must move beyond operating strategies based on myths and confusion about SAP security.” CEO Onapsis, Gartner Security & Risk Management Summit 2015.
“Research findings show the vast majority of SAP systems evaluated contained critical vulnerabilities that exposed them to espionage, sabotage, and fraud.” Onapsis research labs.
“The criticality of the threat to infrastructure was recognised by the FBI.” Nasdaq
“We found one of the biggest problems was shortcuts being taken.” Xoomworks BI 2015
Onapsis were Silver Sponsors at 2015 Gartner Security & Risk Management Summit. They revealed some salutary research. They identified common threats to SAP BI systems. They are the threats to business-critical data.
In the oil and gas industry threats came from:
- Disgruntled employees.
- Foreign states.
They identified four common approaches:
- Customer information.
- Credit card breaches.
- Customer and supplier portals.
- Database warehousing.
Breaches in security could be accidental. For example, 30,000 users receiving 16 reports due to a stray “view” permission, causing a production outage, and causing a data breach.
Breaches in security could be corruption. A recent high-profile security breach; U.S. Secretary of State Hillary Rodham Clinton is an example of bad practice. She wilfully strayed outside the parameters of accepted behaviour with no adequate monitoring. In Clinton’s case, she physically extracted material with a high-security rating and placed them on a personal server. The leaks were traced from emails. The FBI’s current investigation into Mrs. Clinton involves over 100 agents.
Business Intelligence tools have many functions. They organise, extract and analyse data. The data resides in complex systems. Security (or the strong right arm of BI) reflects that complexity. We often deal with security in SAP Business Objects. When we break down the function or the output we require from security and adapt to how it is designed, organisations and users simplify their task.
Complex processes have always needed a way to be drawn. Frank Gilbreth the process analyst of the 20th Century created a flow-process chart. He broke down complex tasks into individual parts. The parts to be examined and improved. Computer programmers of the 1970’s borrowed the idea. They used the IPO (Input-Process-Output) chart. The commonality was starting with the Output. Then designing the system to deliver it. No different to security in a complex Business Intelligence system. Start with the desired result and design a flexible system to deliver it. A system that grows with an organisation.
Follow some simple rules, I would go so far as to say axioms. Doing so reduces the chance of something going wrong. BI deals with massive amounts of data. Security must secure the data and control the access to it. The access will mean the data is available only to the right person, at the right time, for the chosen purpose.
In 2015, Xoomworks BI gave a presentation on SAP BusinessObjects Security: Authentication, Security Token Service Problems, Pitfalls, Tips & Tricks. It was one of numerous “how to”, “help me please” presentations by experts. These include the definitive guides produced by SAP. Here we are extracting a few of the general principles.
AT Xoomworks BI, we found one of the biggest problems was shortcuts being taken. Rather than following a security structure and keeping to the good path. Complexity is part of the story with security; it impacts performance as the structure grows and stays flexible.
As far back as 2011 SAP was publishing 65 security notes per month. That is Microsoft and Oracle level. Demonstrating how seriously they considered security. SAP BusinessObjects security is now an Object based system, not user-centric. Everything in BO is an object. That means everything to which security can be applied. Not just data, users are also nothing but objects. Permissions are granted to these objects. They can be folders, groups, servers, and more.
Users will reside within a group. That group resides in your user and group structure. SAP BO has predefined access rights and the ability to assign granular rights. Predefined access levels: No Access, View, Schedule, View On Demand, Full Control. No Access is not a denial; it sets permission to “Not Specified” which can be overridden. Full control means a user can modify an object up to its deletion. The others lie in between.
Never assign granular rights to content. That is the easiest way for information to go to the wrong people. Keep to groups, and give them Custom Access Levels (CAL). If you have a user with a specialised security requirement, set up a group for them. Then assign security for the group. You can add people to the group when you need. They’re in that group so they can have the group permissions.
Content Groups: Grants rights to folders. The folders contain the content. For example, the marketing group will have access to the marketing folders.
Application Groups: Grants rights to applications. For example, the members of marketing will have permission to create documents in the marketing group.
Split groups in to two defined sections. This is a step towards simplifying your security model. Every user becomes a member of a content group, and an application group. As required they become members of other groups. If a user leaves a group, he loses permissions for that group. The replacement user adopts the permissions when they enter the group. Permissions never rest with the user, but with the group. Documents follow the same pattern. Permissions never rest with a document. Folders are created with appropriate security and the documents live within that.
Custom Access Levels
“We can say that securing SAP Business Objects properly is not possible if custom access levels are not used.” GB & Smith. They go on to say “Complexity arises from the fact that a custom access level is applied to a resource. Calculating the impact, it could have on sub-resources, sub-groups, and users is thus required.” CAL’s are apart from the pre-defined access levels in BO security.
Building CAL’s is sequential and cumulative for any object
Each access level builds on the rights granted by the previous level. Administrators can set frequently needed or common security levels uniformly. A better and safer option than setting individual rights or trawling through the 1,000 granular rights.
Tip: Assign each right in only one CAL. Build up a user type’s permission by assigning multiple CAL’s. If Info Consumer is your lowest level, an info worker will have both info Consumer and info Worker CAL’s assigned to them.
For example, two groups, procurement managers, and procurement employees. As two groups they require access to 20 documents. The documents are in the BO enterprise system. But the managers require more rights than the employees. Rights not covered by the pre-defined levels. Don’t add groups to 20 documents. That would require modifying their rights in 20 places.
Rather two new custom access levels can be created. Call them Procurement Managers and Procurement Employees. Both groups are added as principles to the documents. Their rights can be modified when needed. The access levels apply to both groups across the 20 documents.
Application and Content CAL’s
While it is possible to create a single CAL which covers both Application and Content permissions, it is better to ensure the CALs satisfy a single purpose.
Create separate CALs for Application (e.g., WebI, CMC, Crystal Reports) and Content (e.g., reports, universes, connections.)
CALs should be broken down into the various functional areas as well as being modular.
Info Worker should have all previous access levels as well as the CALs named after their user types.
Security Token Service – Brokered Authentication
Security Token Service (STS) is not a new concept. Brokered authentication has been used to grant access to applications and web services for many years. STS was introduced in SAP BO BI 4.0. It is a one-way trust; BW systems trust BI4, but it does not trust the BW systems. A neat idea to place an intermediary.
In a multi BW system, a user logs in with one method and can still use another method’s functionality. So sign on with a single sign-on (SSO) to one BW, and connect to another with the same SSO as the credentials are brokered. In a complex environment, an STS can streamline authentication. In fact, the more complex, the more STS helps.
The STS can replace a Secure Network Configuration (SNC) setup between BI 4 and a BW. The SNC will only be used for legacy workflows; new workflows will use the STS. You can see detailed setup guides on our slide presentation, and on the links within that document.
The last but not final words
Keeping on top of your requirements is vital. Adjust the security model as and when required. Never assume that shortcuts are not being taken.
It is a fact that the more complex security and authentication are, the greater the impact on performance. Security Token Services and aliasing users can make your security solution simpler.
Make your security model as flexible as possible.
Finally, If you intend to run for the U.S. Presidency, treat your data security with some respect.