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.
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?
Education
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.
Role
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.
Technology
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.
Looking for a PBAC, XACML and/or ABAC SME, Functional Architect, Analyst or Implementor? Feel free to reach out to the IDMWorks ABAC team.
