Organizations can build better security with added IT agility for private clouds by externalizing authorization from applications using Oracle Entitlements Server.
Typically in a private cloud scenario you might have a data center with a hardware grid hosting a middle-ware platform so let’s take the next step:
- You have the departmental application owners building their own custom applications using the set of shared services available through the framework. Application developers can then use Oracle’s Platform Security Services as the single security framework for both Oracle and third-party environments, externalizing Authorization Controls from Application into XACML policies, decreasing application development, administration, and maintenance costs.
- The application is deployed to the runtime environment
- Enterprise IT defines policies and services. So you have a centralized infrastructure to enforce your security policies throughout the organization. With Oracle Entitlements Server, IT then centralizes enforcement of consistent policies throughout the infrastructure
- Once the application is deployed end users can access the applications. The application, in conjunction with Oracle Entitlements Server security modules, enforce fine-grained security policies in the app (so you can restrict access to sensitive application functions by user entitlements)
If security mandates evolve or policies changes the application doesn’t need to be recoded. The new policies can be enforced across all applications using the OES infrastructure.
As for writing the policies, well you can use OES OOB or go with standard XACML (the eXtensible Access Control Markup Language (XACML) is an access control model that describes how to interpret policies, and an access control policy language (written using XML).
Writing Policy in an XACML World
There is a lot of chatter going on right now in trying to figure out who will be responsible to write those nagging IF, THEN, ELSE statements that will be the norm in the XACML implementations around the world. So who should write the policies to begin with? That is a question I think needs to be broken down into a few components before it can be answered.
1) Education – How do I write XACML policy to begin with? That will depend on version but the sake of this blog entry I plan to stick with XACML 3.0 (data types and functions at a minimum).
2) Role – Does the organization view the business or IT side of the house as the responsible party and more importantly, should they?
3) Technology – This is a question of whether we put the proverbial cart before the horse. The question being what role the XACML coders themselves will have in the policy implementation? Also, what technology are we using to write the policies, translate them and implement them?
The IF statement is simple in that we wish to define the attributes and their associated values that will let me get to the THEN statement? IF the user is located in RENO and has a title of SVP or IT Manager THEN…
Within XACML 3.0 we start off with the concept of Permit or Deny and add in to the mix Obligations and Comments. Basically, what authorized actions can I take post-authentication (typically), what am I allowed to do (permitted or denied) and are there any hoops I have to jump through in addition to simply a Permit/Deny scenario. This bit of confusion being the THEN statement.
ELSE should be self-explanatory but I will sum it up as follows, “If all else fails, do the following”.
You may be asking yourself why I bothered to write the above. I did so because the folks writing policy may be doing so in MS Word or Excel. So let’s segue into our Role conversation.
This is the bigger question surrounding policy. Should the business write the policies? Should the IT group write the policies? Should the lawyers write the policies? There is no simple answer but I can make a few suggestions I have found reasonable with previous customers.
1) If you have an IT or Business Governance group, they should be on the hook for policy. In lieu of Governance, IT Security is a great place to start.
2) Within Governance or Security, an SME is always welcome, followed by an IT Architect. This has to be weighed with Functional vs. Technical. I have met many IT Architects in my day and they fall into two buckets. The Technical Architect is the person you want defining ports and protocols, services and well, technology. The Functional Architect is the person who can and usually does, double as an Analyst. A guiding force as it were along the lines of an SME. The Functional Architect is the person you want meeting with your business and IT teams and pulling out the policies one tooth at a time.
3) Once Policy has been built, and I truly mean built, through questionnaires, meetings and workshops, it needs to go to the business and IT teams for review and approval.
4) Post approval I recommend a legal review and possibly a Governance review. Make sure no HIPAA, SOX, FERC, etc. regulations have been violated and that proper Separation of Duties (SOD) exists.
So how are our Functional Architects supposed to deliver policies to the “Policy Administrators” that will implement them? This really depends on the strength of your education to the business and IT units and the delivery your SME/Function Architect/Analyst is most comfortable with. My own preference is to use a basic tool that will allow an easy understanding when presented to Auditors, Lawyers, and the Business. This can easily be Microsoft Word, Excel or Access (all of which can be saved in XML format). The goal being that these policies will need to be converted to XACML policies in either an editor or vendor application. The policy administrators must be keepers of code from a create/change/remove perspective so that we have a built in checks and balance approach to Policy validation. Whatever you do, stop before you write a line a code and determine if the steps outlined in the Role discussion above have been fulfilled. The biggest mistake we make is implementing technology before we have defined what we are trying to implement in the first place. Never code side by side while you are writing requirements. There is an order to things that if followed results in less wasted work.
So whether you are deciding to bring in a vendor or go it alone in the XACML, ABAC, PBAC spaces just remember Policy is what you make it and if you plan it out effectively then there will be less roadblocks that lead you to project failure.
Questions, comments concerns? Ask away at IDMWorks.