Security Blogging - A Stitch in Time…

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

By Rick Epstein

Have you ever heard someone rationalize an important decision with a folksy saying? It may make one seem wise at the time, but you should be aware that, for every such "wise" saying, there is generally an equally wise and opposite saying. For example, "look before you leap," but "he who hesitates is lost."

If your rationale for not reconsidering your SAP BusinessObjects security model is "If it ain't broke, don't fix it," then my reply to you is that "A stitch in time saves nine." You won't know whether it's broken until you look.

There are, of course, other sorts of objections to taking action that I hear over and over again from normally risk-averse people who don't want to address necessary changes to their SAP BusinessObjects security model.

Here are the top five:

We don't have any data that needs to be secured.

Great. Just publish it all on the Internet. No? Every company has private data that they don't want to share with competitors and/or the public. The only difference is the degree to which a breach will hurt. What is your pain threshold?

We don't have time right now.

What will it take to get your attention? Delaying the discussion of your SAP BusinessObjects security model will almost inevitably lead to an unanticipated security breach. Implementing a well designed security model is an investment. Prioritize and make the time.

We don't have money in the budget.

Budgets are expressions of priorities. If you don't have money in the budget, then you need to re-examine your priorities. The potential cost to your company -- in terms of both money and reputation -- in the event private information is viewed by an unauthorized person or persons far exceeds what it would cost you to analyze and reengineer your SAP BusinessObjects security model.

Why should we change? Our security model works fine.

If it seems as though the pain of change is too much to bear, ask yourself how you will feel about the pain of regret. It is quite likely that there are unknown security holes in your security model. Designing and implementing a security model using a true top-down methodology is the only way to ensure that there are no such holes.

We don't have resources who know enough…
…about SAP BusinessObjects security to instantiate a true top-down security model. Then I guess today is your lucky day. Please reach out to me at repstein@resolvitinc.com. I would be glad to provide some tips and tricks and answer some questions in a 1-hour free consultation.

SAP BusinessObjects Security - Remediation, or How to Find & Repair Gaping Holes in Your Current Security Model

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

By Rick Epstein

Ideally, you will want to plan your security architecture and design a bulletproof security model. However, sometimes assessment will uncover gaping holes in your current architecture, and you will want to close those holes as quickly as possible to reduce risk to your organization.

Here are the broad strokes for assessment and remediation. Keep in mind the best practices discussed in the previous post as you proceed through each of these steps:

1. Inventory groups and group members (users)
2. Look at each granular inherited & explicit permission for each principal for each content folder, universe folder, category folder, connection (connection folders in BI 4.x)
3. Are there any permissions set specifically on content within these folders?
4. Create groups for each application and apply the No Access to the Everyone group for each group on its respective application
5. Create groups for every content folder, universe folder, category folder, connection (connection folders in BI 4.x)
6. Apply the same security to each group on each folder
7. Create generic groups for specific grants or denials of rights
8. From your inventory of groups and users and permissions set for each, assign users to these new groups
9. Remove users from the old groups
10. Store the old groups in another group called something like "zzzToBeDeleted"

As I said, these are the broad strokes. They are a good start, but there remain traps for the unwary, and great potential for unintended consequences. If it reminds you of old mariners' charts with captions such as "There be dragons here," that may be a good thing.

Next in the security blogging series: Why companies don't update their security model.

Webinar: SAP BusinessObjects Security Management & Impact Analysis for Epic Deployments

When: June 25, 2014, 2pm EDT
Guest Presenter: Rick Epstein, President, ResolvIT Inc.

Healthcare business intelligence has many unique challenges. For healthcare providers, practice management, financial management, and the tracking of "meaningful use" information can be simplified by tight integration of the BI and EMR platforms. However, this integration has serious implications for security management and the safeguarding of electronic Protected Health Information (ePHI).

For organizations using Epic solutions, there is often a recurring need to update SAP BusinessObjects reports when an Epic update is implemented. We will look at ways to perform efficient and effective impact analysis of Epic updates, and to update your SAP BusinessObjects deployment accordingly.

Join security expert Rick Epstein of ResolvIT Inc. and Fred Walther of APOS Systems as they examine issues around SAP BusinessObjects security management and impact analysis for Epic deployments.

Register for this webinar…

Common SAP BusinessObjects Security Mistakes - Miscellaneous

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

By Rick Epstein

This post concludes the list of most common security mistakes begun in these earlier posts:

• Abuse of the Everyone Group
• Securing Content

We end our discussion of common SAP BusinessObjects security mistakes a couple of miscellaneous items.

Mistake #8: Allowing too many people to be able to see the SAP BusinessObjects License Key(s)

Allowing all administrators to see license keys is NOT a good practice. Only 1 or 2 people should have rights to see this as well as your company’s purchasing dept.

Mistake #9: Applying security on an Active Directory group directly

The problem with applying security directly on an Active Directory group is that it moves security outside of the BI deployment, creating a very large potential for unintended consequences.
If there is an Active Directory server upgrade, or service pack, or other maintenance, Active Directory communication may be interrupted, and groups may be "reset". While such a reset doesn’t affect the Windows environments, it can have an adverse effect on SAP BusinessObjects Active Directory integration. For example, an Active Directory group mapped in SAP BusinessObjects may become "unreadable" by SAP BusinessObjects. When you re-import or re-map that Active Directory group, you would need to set up all permissions on that group all over again. A far easier and better solution is to make Active Directory groups part of SAP BusinessObjects Enterprise groups and have security assigned on those Enterprise groups only.

Are you aware of other common security mistakes, or do you have questions about what is written here? Use the Comments section for this post, or email me directly at repstein@resolvitinc.com.

In my next post, I'll look at "top-down methodology and best practices."

SAP BusinessObjects Security - Access Levels

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

By Rick Epstein

An access level is a set of permissions that apply to a user or group concerning an object such as a folder or report. SAP BusinessObjects lets you create custom access levels -- something I will write about in a future post -- but for now, let's restrict ourselves to the five pre-defined Access Levels in SAP BusinessObjects:

• View: Can see the object and view instances of reports
• View on Demand: Inherits rights of the View Access level and can run reports real time
• Schedule: Inherits rights of the View On Demand Access level and can schedule reports
• Full Control (owner): Inherits rights of the Schedule Access level and can add, copy, delete content if the user is also the owner
• Full Control: Inherits rights of the Schedule Access level and can add, copy, and delete content regardless of the content's owner

Nothing too controversial there, but it does open up the topic of inheritance, a topic which will be important in all that follows, and which may be the source of many unintended consequences. So let's be clear about what we mean by inheritance:

• Inheritance: Getting the rights of the parent group(s) and/or parent folder(s)

Access levels apply to users and groups. My next post will deal with rights settings, which are assigned at the object level.

Security Knowledge Framework

By Rick Epstein

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

It is always difficult to dive into a topic that is both very large and very granular in nature. SAP BusinessObjects security is just such a topic. Where do we start?
Experienced administrators will have a good grasp on the basics of security administration, and will want to get granular very quickly. Those who are just coming to the topic of SAP BusinessObjects security, or who are not hands-on administrators, but need a better understanding of security to ensure corporate data governance objectives are being met, will benefit from more high-level discussion.

Well, as they say, you can't please everyone.

At the risk of alienating some security veterans, I'm going to start at the 30,000-foot level, just so we can all get onto the same page as quickly as possible. If we're going to have a meaningful conversation about security, we first have to make sure we're all speaking the same language. I promise we will get granular quickly, with tips and tricks that both veterans and beginners will be able to appreciate.

To start, let's establish a frame of reference -- a Security Knowledge Framework.
What is the Security Knowledge Framework? It is the collection of concepts and definitions that you need to understand to implement and manage an efficient and effective security model in SAP BusinessObjects. It helps you establish your security requirements and develop your security model.

At its most basic, security is about access -- ensuring that the appropriate people have access to the appropriate information. But the converse is equally important -- ensuring that sensitive information does not fall into inappropriate hands. Access is all-important, so my next post will examine access levels in SAP BusinessObjects.

Security Blogging with Rick Epstein

For information on using APOS solutions to help you bolster and manage security, visit our more recent series of security posts.

SAP BusinessObjects Security expert Rick Epstein of ResolvIT Inc. recently co-hosted a webinar with APOS concerning Security Architecture & Management in SAP BI 4. (View the recorded webinar.) The webinar touched on many areas of SAP BusinessObjects security., including security model design and migration, data governance, and regulatory compliance. Rick will be following up on that very well received webinar with a series of security-related guest posts on this blog.

Rick's professional focus is on SAP BusinessObjects security, report and universe design, process streamlining and data consolidation -- all with the objective of helping organizations establish their SAP BusinessObjects deployment as the single source of truth for operational excellence and efficient planning. He has implemented SAP BusinessObjects security models in numerous industries, including healthcare, aerospace and defense, and manufacturing.

Why You Need to Focus on Security

Those of you who attended the webinar, or watched the recorded webinar, will know that we started out with an overview of how growing BI volume and complexity have made the work of BI platform managers and administrators much more difficult. BI volume and complexity raise many issues for system analysis, administration, storage, query management and publishing, but none is more important than ensuring that the right people -- and only the right people -- have access to appropriate information within your system.

With the increasing emphasis on mobile and self-serve BI, the roles of BI platform managers and administrators will become even more demanding. If you are one of these people, the security of your BI platform has to be very high on your list of concerns.

Our first focus is generally on the accessibility of data -- getting our data into data warehouses, moving our reports between environments, bursting reports to a wide variety of information consumers, etc. We spend so much time getting these things right that we may not fully consider what can go wrong. Worse still, we may not know something can go wrong until it does. Bringing resources to bear on the issue of security is part of the solution. The other, equally important, parts are knowledge and experience.

Topics for Discussion

Rick will start his series of blog posts by taking a deeper look at the Security Knowledge Framework. What is the Security Knowledge Framework? It is the collection of concepts and definitions that you need to understand to implement and manage an efficient and effective security model in SAP BusinessObjects. It helps you establish your security requirements and develop your security model. The first order of business is to make sure we're speaking the same language.

Future entries will drill down into areas such as:

• Security model design and implementation
• Security model migration
• Security assessment
• Regulatory compliance
• Data governance

Do you have a specific security-related question? Contact Rick Epstein at repstein@resolvitinc.com.