In the past few years as VP of GB&Smith 360Suite, I have been working with hundreds of customers using 360Suite tools for Business Objects. A common issue with most deployments is how Business Objects Security, with a capital “S”, is perceived whether it is by IT, QA, CISO or any person in an organization. Typically models are extremely complex, they lack common sense and implementers have a poor understanding of regulations. Security needs to have answers to the “W” questions: Who, When, What, Why & Where.
Security in an organization is more than ‘Who has access to what’. Security in SAP Business Objects can be related to:
Who has access to What
Who had access to What
Who has access to what? Or account certification
Who has access to What? Easy to ask, tough to answer!
I had the chance to work with banks, federal entities and fortune 500 companies. An honest answer to this simple question is, “I do not know”.
Security models need to be as simple as possible working from a Role or Group and avoid individual user security. Most of the time, security rights are poorly implemented without understanding the needs or of the security’s life cycle management. Over time, organizations forget what was exactly granted to specific users and the impacts on the environments.
The best way to secure a deployment is at the database level, using row-level security. Additional security can be applied at the reporting level.
For legacy environments, where it is difficult to accurately map out security, 360Suite can export security via excel and import it back with modifications.
Current State in Business Objects: It is only easy to find explicit rights. The issue is, when you assign security, it impacts the entire environment like a domino effect. Each time you make a change, it can have downstream effects. At the end of it all, it has turned into a maze.
The most common way to keep track of such changes for the best deployments is to make changes on an excel file, with the X axis being resources to be secured and the Y axis being users and groups to be secured. This is pretty easy to do in a company of 10 users but when you start to reach deployments of 100 or more users it is very tricky to keep track of since there are so many changes, people who change security come and go throughout the life of any organization.
Ask an admin What User Bob has access to in detail, the honest answer is “I don’t know”.
Ask the CIO who has access to “Finance folders” with all detailed security, the honest answer is “I don’t know” or “let me refer to an old Excel file”.
360Suite Solutions: 360Suite provides a real-time view of security, and offers the possibility to document it via an Excel export. Not possible in Business Objects. You also have the possibility to make changes to security and see all the impacted rights (inheritance and double inheritance).
Our tools offer the possibility to use a user centric and resource centric view to audit security.
Use case: Edward Snowden Case. Gaining a clear view of security with 360View. It would have been very simple to recognize that Snowden had admin rights on most resources, such as viewing inheritance and rights to modify security.
Are accounts still needed and accurate? Large organizations and federal organizations need to perform such recertification on a regular basis depending on their regulatory requirements. Some organizations do an annual account recertification and then perform quarterly recertification based on a predefined % of accounts.
Current State in Business Objects: At present, this not something that is being handled.
360Suite Solutions: This is a multiple step process involving Users/Resources/Security.
First, you need to determine whether user access is still needed, this is based on an organization’s policy. Next, you need to have access and document security at the deepest level. Then compare it to the policy in place. 360 allows to modify directly in XLS and push back security. In certain cases, you might want to use a work flow with comments associated to each change.
Other steps based on activity or non-activity level, 360Suite is able to capture, report and fine tune recertification and trigger whether a specific user needs to be recertified or not.
Unlinked users and unlinked groups. 360 is able to find and cleanup such unlinked actors.
Use case: I had the chance to work with multiple organizations including federal ones. I can say that in 90% of the cases their account recertification was either false or inaccurate. Typically, the main reasons are a mix of a poor understanding of account recertification rules, poor training of people implementing recertification, poor understanding of IT architecture from policy makers and an overall inability to have access to detailed information.
Who had access to what?
Who had access to What? A common answer to that is “I don’t know” and “do not know what the security changes were”.
Last year while working with a large East Coast Hospital, they had an urgent need to show who had access to a specific folder six months earlier regulated by HIPAA. The answer is they could only guess and furthermore had no idea of any security changes.
Current State in Business Objects: Currently, the only answer to this question is to rollback to a previous backup. Once this is done, determine the explicit rights. No information is available re the life cycle management of the security changes for that specific resource. https://360suite.io/2017/03/10/rollback-security-business-objects/
360Suite Solutions: 360Suite is able to take daily snapshots of security and compare changes over time like a time machine. Workflows to cover the security life cycle management can be handled, auditing any changes in the security.
Segregation Of Duties
SOD rules are typically easy to determine, a little tougher to implement and tough to control.
Current State in Business Objects: It is possible to implement SOD rules in Business Objects but virtually impossible to track and check them.
360Suite Solutions: SOD is managed very easily due to a 360Suite Patent allowing admins to display and manage security. For a specific segregation, a Matrix appears with users selected on X axis and resources on Y axis. As a result, you can check all the security for the zone and if there are any issues, you can modify it and see all the impacted rights.
Use case: 2 years ago we were doing a POC for a prospect specializing in manufacturing. The Customer initially was interested in our BI on BI solutions. While exchanging conversations with the customer he mentioned the complexity of his security model and was curious to check his SOD in the Accounting Dept. Funny enough, he found out that the person handling payments could also handle PO’s, never a good idea and a typical SOD breach. The customer investigated and discovered the reason for the breach, it was because the person changed roles within the organization and was removed from the previous role at an explicit level but not the inheritance level. As a result, the POC lasted 10 days and we received a PO shortly after.
Life Cycle Management of users leaving and changing roles
How do you know if a user who left the organization still has rights? Or a user who moved to a new department does not have access to his old resources?
Current State in Business Objects: Explicit permissions can be found and administrators need to go fishing (and be lucky enough) to determine what the inherited and double inherited permissions are. By default, if a user is deleted and they own documents or instances, they are reassigned to the Administrator.
360Suite solutions: When a user leaves an organization, or changes roles, 360Suite offers the “Swap” feature. You enter the name of the old user and the new user and the object ownership is transferred from one to the other within 3 clicks!
When a user leaves an organization, he/she is typically disconnected from the organization directory and the link between the organization directory and Business Objects is lost. However, the user (if an Enterprise alias has been created which is a best practice) is still in Business Objects, typically without access granted. 360Suite finds all these unlinked users and provides the ability to remove them.
360Suite also offers the opportunity to provide a report verifying that the user who left the company no longer has access to anything and is not unlinked. For users who moved in the organization, a security report can be issued comparing old and new security.
Use case: The most famous and expensive banking scandal was caused by a trader who changed roles within the financial organization. Since the user changed roles within the organization, he kept access to a few older resources. Moral of the story, the user used old credentials and caused the bank to lose billions.
Backup Disaster and Recovery
In the past few years, when asking clients if they have fully stressed their Business Objects Backup / Disaster / Recovery… answer is > 80% of cases “we have not”. By experience, I know this is true in > 95% of cases.
Current state in Business Objects: It is possible to do full backup, prepare for disaster and recovery with BOBJ out of the box. This task is very challenging and most people fail while tackling it and take laborious hours and days to finish the job. Reason is you need to have a full backup of the filestore (FRSinput/FRSoutput) and backup of repository database schema. All of these need to be in sync. Once you have that, you need to have a server ready with BOE installed, and a proper DB Schema. Read more here.
VMs are the most common way to prepare for DR, the issue you have is if you have a corrupted object, universe, version, etc. it is of no help. Last year I had an aerospace organization who learned that the hard way.
360Suite Solution: In Business Objects when you generate a backup, it takes a very large amount of objects and treats it as 1 mega BIAR, making it hard to promote and impossible to disassociate. 360Plus is able to manage 1 backup per object, universe, report, user, etc., as a result it is very flexible to promote and each individual object can be selectively restored.
If you have a corrupted VM you just roll back to the uncorrupted object(s) and restore. In case of a DR, you just ask the tool to restore Full content or content from date X to date Y and you are up and running. This is as simple to use as the time machine I use with my MacBook Pro.
Use Case: Recently, over a weekend, a hospital did an upgrade to the latest version of SAP BusinessObjects. On the following Monday morning, I received a phone call from the customer… “Bruno we upgraded to latest BOBJ version but have serious issues. We need to rollback ASAP.” Within 1-2 hours, the customer was running on the previous version.
I have witnessed a more challenging cases with federal customers who upgraded to the latest BOBJ version after 2 months of preparation (at the time of this issue they were considering buying our tools but had not yet, still a POC). In the process of this migration, the customer installed the new version of Business Objects, on top of the previous version (I never recommend that). After a few days, the customer realized that certain applications, despite initial preparations and testing, had major issues. The problem in this scenario, they could not rollback to the previous version.
I have seen so many stories like the ones above; a fire in a server room, person physically removing and damaging a SAN, administrator doing false manipulation, etc.
In most organizations, you have multiple report developers working on the same report. Cases like when you work on a Microsoft Word document, exchange it with co-workers who does the modifications, and at the end you have so many versions you have no idea what the proper version is, the visibility of who changed what, and what was changed.
Current state in Business Objects: Limited version management is possible out of the box but does not comply with most regulations such as FISMA, SOX, HIPAA, etc. Read here the article on version control.
360Suite Solution: 360Suite offers the possibility to Check in & Check out. While a report is checked out, only developer who checked it out. (The Administrator can unlock if necessary). When reports are checked in, version # is assigned and comments can be added. As a result, you have full report traceability of changes and the ability to compare, promote and restore versions as well.
Use case: All regulated industries for GRC need to be able to answer: Who changed What? When? In which report? With the ability to see changes. Certain organizations can be more demanding than others. Last year, the US Treasury asked us to deliver a feature in version control that includes workflows. Before reports or universes are promoted between environments, they need to be approved by specific users. The Use Case for Version management is complete report traceability.
Wrong report bursted into inboxes!
This is a common problem despite internal procedures, what can you do when the wrong report has been bursted into BOBJ inboxes. Send a message to the recipients “do not open!” (I have seen that) you can bet recipients will open! Or you can wish you could delete that action, what if I told you…Yes you can!
Current state in Business Objects: There is nothing you can do about this issue without manually going into each users’ BOBJ inbox.
360Suite Solution: 360Suite offers the ability to selectively choose to burst a specific report, on a specific date. For Bursting, 360Suite offers the ability to manage bursting dynamically or semi-dynamically. As a result, you get all your bursting via excel and you can simply modify the destination, filter values, prompt values, format, etc., with the possibility to manage password for recipients.
Use case: One of the customers who requested that feature, blasted sensitive HR information to wrong recipients. This created a huge problem. With the bursting feature, the problem could have been solved or limited depending on how fast actions could have been taken.
Secure your bursted reports
It is always better to follow bursted reports with passwords! (If you remember your password)
Current state in Business Objects: You cannot secure your scheduled/bursted report with a password.
360Suite Solutions: Don’t fret, 360Suite offers the ability to secure your bursted reports with passwords!
Use case: We specifically developed that feature for a customer who bursted sales information to the wrong customers (incidentally, it was the customer’s competitor).
Showing inaccurate data can be a serious security and compliance problem. Whether you do an upgrade, a migration, implement a service pack or make a change on DB side regressions… it does happen. The only question is where it is?
Current state in Business Objects: Regression testing is not available out of the box.
360Suite Solutions: 360suite offers the ability to automate all your regression testing with the possibility to check data and pixels inside the reports. Processes can be automated and results can be e-mailed to reports’ recipients. 360Suite also manages security so that only the recipient can see the data, and regression testing results are not shared to inappropriate people.
Once regressions are found, 360Suite can perform impact analysis across the entire environment and check if such regression is affecting other reports. If the issue is with report variable, 360Suite is then able to update all affected reports in bulk.
Use case: We have seen so many cases dealing with regressions, typically not good stories for customers. We have stories about customers publishing false financial data, central banks freezing service packs, utility organization sending false bills, etc.
Let’s take a pure ROI use case. One of our customers is a Motorcycle Manufacturer, and in the past they had 14 consultants searching for their regressions due to their regulatory needs, now with 360 they only need 2 consultants.
360Suite application security
By default, 360Suite has the same security as Business Objects by default, it is also possible to apply more restrictive security.
Use case: A healthcare organization needed to provide admin access to multiple users in order to kill sessions (very bad practice) as their security model was not allowing them to do granular rights. With 360Suite, they were able to limit access rights of non IT Admins so that they could use admin credentials only to kill sessions.
Improper Universe Object Description
Over time, deployments grow and grow and go through different developers, eventually organizations perform acquisitions and object descriptions become less and less streamlined.
How does that affect security? Without proper nomenclature of Universe content, it is very difficult to keep track of why such Objects exists and what sensitive information it relates to.
Current state in Business Objects: You can manually update 1 by 1 and it is extremely time-consuming and error prone.
360Suite Solutions: You have the possibility to export and document all Universe content Classes, objects names, objects descriptions, field types, object select, etc. Make any necessary updates, deletes, inserts in excel, and import the excel file to update in bulk.
Use case: I remember back in 1999, there was the concern of the Y2K bug (for the most part it was a big scam, and a good way for consulting companies to sell services). For certain organizations it was a big security issue. Problem was people who coded software rarely left notes around fields relating to dates. Back in those days, I use to go to Japan frequently and I saw it was not a serious problem. One of the reasons (outside of low employee turnover) was that they kept excellent Object descriptions. More recently I have seen organizations with a need to have unified nomenclatures around objects relating to SSN or country of residence.
All these regulations need to answer the W questions: Who, What, When, Where & Why.
You may think it is pretty common sense… Well it is! However, I worked with 5 big consulting firms and most of the time they could not simply explain the W’s and how to retrieve that info.
A great example is organizations that need to be SOX compliant often have their data SOX but never think that Business Objects publishes such info. Mind you, Business Objects needs to be SOX compliant as well.
Current state in Business Objects: There are inherent limitations, therefore answering all W’s as all sourced can’t be queried out of the box.
Answering all the W’s in Business Objects is impossible due to the lack of access of all metadata, capture of all historical changes/updates, etc.
360Suite Solutions: 360Suite allows to capture all the Metadata, historical changes, updates, etc.
Use Case: With our customers, the organizations that are the most careful about Regulatory needs are Banks. Well yes, like all banks in the US and Europe, but I am speaking of banks particularly in Switzerland!
Security is very complex in Business Objects as typically, BOBJ is used as a reporting tool capturing data from multiple sources and users within organizations. With common sense, basic knowledge and proper tools, it is very easy to a have secured deployment and answer to the W’s: Who, When, What, Where & Why. As a last note, I have seen many organizations going from OBIEE, Cognos to SAP Business Objects. The reason being is, it is far safer to use and less flexible which is a good thing for security.
Request a Trial today from 360Suite here.
How our customers used and conquered with 360Suite? Find out more!