Application security: an afterthought. A cumbersome chore. A thankless task. The stuff of nightmares.

Yep, it’s all of those things, yet so critical. Especially in this day and age.

(credit: Google images)

But does it have to be? This is a multi-part series that focuses on Oracle Planning Cloud security. The tips provided in this first blog post are generic enough to apply to multiple security implementations.

I’ve been designing and implementing Oracle EPM & BI security for nearly 2 decades. During this time, I’ve seen customers make security design and implementation mistakes up front, which can have dangerous consequences down the road. And, to be very candid, most of the customers I’ve worked for have had little to no strategy in the way of application security.

(credit: Google images)

Therefore, in this first post I will start with the basic tips for a healthy security strategy.

Tip #1: Proper Planning is the Key

(credit: Google images)

Yes, that was an intentional play on words (since this series will focus on Planning Cloud). But seriously…it’s critical to have a tight strategy and comprehensive design. All elements of the application solution should be considered and dynamically managed, especially if you have a daunting number of users (hundreds +). This could take weeks to plan out and develop in advance. And it should – it should take longer to plan and design the security than it does to actually implement it. Take the proper amount of time to do this correctly in advance and accept that a good strategy takes time to think through.

Don’t wait until the last minute.

Tip #2: Document the Security Design

(credit: Google images)

I’ve been to one too many customers where the original administrator created the security design, then left, then no one knew how to maintain it. So the remaining team started implementing band aids and stop gaps. Two years later and security is a jumbled mess. You don’t want a security strategy built on a house of cards because no one took the time to document it.

Planning Cloud offers out of the box audit reports, but we’re not talking about the end result. A document outlining the basic security guidelines for each cube and each group’s design and purpose is what you need.

This task may sound awful, but it becomes imperative to have backup documentation in an emergency. This is one time when the exception case outweighs the upfront amount of effort.

Tip #3: Have a Backup Security Administrator

(credit: Google images)

If only one person understands the security design, you’re going to be in a world of hurt (and waste much time) if they don’t have a backup and you need them. What if that person wins the lottery one day? (note that in the consulting world we now refrain from the “gets hit by a bus” hypothetical)  What if your company undergoes a reorganization and they leave your department? What if your security administrator doesn’t leave behind any documentation? What if that person gives notice – can they really knowledge transfer a complex security design in the usual 2 weeks of notice (on top of everything else they have to pass on) before they leave?

The backup security administrator should know the security design intimately. It’s recommended that both people maintain Planning security regularly and be involved in design to ensure that the knowledge stays current. Having a regular backup security administrator also alleviates stress when one administrator needs to take leave.

Tip #4: Create Dynamic Security

(credit: Google images)

Assuming you have many users to manage, you will want to focus on creating a dynamic design. The following principles apply to this “dynamic” concept:

• Design intuitively and logically. It shouldn’t take a rocket scientist to figure out how to maintain the security design.
• Steer clear of hard-coding
• Avoid user-specific security (go for groups)
• Avoid low-level object security (take advantage of inherited permissions from parent level objects like folders)
• Aim for an easily maintainable design
• Create automated maintenance processes

Tip #5: Test Your Security Implementation

(credit: Google images)

And test it well. I’d recommend creating test scripts for every major grouping of user. If you’re storing sensitive data, you’ll also want to think outside of the box when you create those scripts (can your Finance users see employee salaries?)

To go one level deeper from the standard, use dummy data and have one user from every group log in and test everything out in a formal test phase. They should also document their results so you know where the gaps are for future refinements and evolution.

Tip #6: Audit Security Regularly

(credit: Google images)

Turnover is common at companies. You’ll want a strategy for auditing and adjusting your security regularly. Since most Oracle EPM Cloud customers have a traditional public Cloud license, you don’t want folks who have recently departed the company to continue having access (although the default Oracle EPM Cloud password protocols will eventually correct this issue). The best scenario is if you have formal governance around security (see next tip).

If you’re at a smaller firm with not very many users you can do this manually on a regular basis. However, if you have hundreds of users, this task becomes unrealistic to do manually. There are methods for implementing fluid and automated audits, and some products are more flexible than others. If you’re using an implementation partner, ask them for their recommendations.

Tip #7: Create Security Governance

(credit: Google images)

This will not be an overnight project. However, given that we’re talking about public Cloud, this needs to be a priority. Scrutinizing security and the policies surrounding security becomes even more critical in this world of data privacy and invasion nightmares. Processes that might be considered within scope of this type of governance plan:

• New user requests
• Employee promotions
• Employee transfers
• Employee departures
• Impacts when affected application components change (new dimensions/objects are created)
• Assessing impact for a reorganization
• Mergers and acquisitions

Tip #8: Understand the Security Nuances of Each Product

(credit: Google images)

Each product may come with its own set of subtleties regarding security: the way security is handled, what objects need to be secured, the product-specific set of security roles, etc. Even between EPBCS and PBCS there are minor differences that need to be acknowledged and accounted for in the security design.

At a high level, it’s important to understand the security nuances related to:

• The overall product architecture
• Security roles by product
• Security access types by object
• Best strategy design by user role (administrators, developers, power users, planners, reviewers/managers, reporting users, etc.)
• Security integration with on-prem products
• Pass through security between integrated Cloud products
• Ways of automating security processes
• The moving pieces outside of the Cloud platform

In future posts in this series, I will focus on a more tactical strategy and the security nuances for Planning Cloud.

Have any tips to share? Please put them in the comments!

Also, a quick plug for my friends at Oracle: check out the Customer Connect portal (you must have an active Oracle account). Oracle Product Management, Customers, Partners, and others visit this site to get questions answered, provide advice, stay up to date on up and coming webinars, participate in discussions, and much more!