Ok, I admit it. I LIKE the idea of being the "go to" security person....until... (Did you bring the Latte? )
.................................................................
...................................................>>>>>>>>
Documentation BLUES.
Ok, I admit it. I LIKE the idea of being the "go to" security person....until... (Did you bring the Latte? )
There are a lot of tasks that a SECADM can enjoy. Setting up LBAC, Roles, Trusted Contexts, Auditing, these are FUN things (ok, at least to ME they're fun). But then, there comes a day of reckoning....the Dreaded Day of Documentation.
Remember in Part 1, we covered some of the ways that the SECADM could, shall we say, share the joy, by letting others in on the security fun? Remember how happy your SECADM was to learn about all the ways to divide and conquer? Remember me saying I would share my thoughts on this new Security Model and the necessary Controls?
Take a LARGE SIP of the LATTE...reach for the Kleenex and let me explain.
All this freedom to share tasks comes at a price. That price is....(wait for it).....DOCUMENTATION.
When you have one SECADM who is doing all the work, you "might" get away with less robust documentation and controls. It's pretty obvious if there is one individual who holds SECADM, that's the only person who will be doing the SECADM specific tasks. Whether to Praise or Blame...it's easy to identify who "did" it, when there is only one.
In DB2 9.7, with the ability to delegate, the ability to grant SECADM to roles and the ability to assign a user to handle the audit stored procedures, the complexity of answering the question of "who is doing what?" becomes more challenging to answer.
So, my advice is....do the preparation work up front BEFORE you start delegating and separating tasks. Get a handle on it from day one. Be ready to answer the "WHO, WHAT, WHY, WHEN and HOW" questions regarding the SECADM responsibilities and tasks, whether delegated or not.
Grab your Latte, sit down and design a tracking methodology. You will probably come up with several pieces of information that you will what to track. For example, if user BOND was given ACCESSCTRL authority, the questions I would immediately have are: who approved that authority, why (for what business reason), what date was it effective and what date will it be it revoked? I would also want a "reminder' date. By that I mean, I want to be reminded to check the work that "crazy, shoe-loving" BOND user is doing, just to make sure she's ACCESSCTRL worthy.
I would encourage you avoid doing this in Spreadsheets or Text Documents because I always worry about protection for items that "live" outside the database. My personal preference would be to create a new, separate schema in a nice, 'locked down' secure DB2 database and build a set of tables there to hold the information. That way it could be easily updated as things changed, queried via SQL AND AUDITED for extra protection. You can set up LBAC on these tables to help protect them from unauthorized prying eyes.
You will also need some "written", text based, policies and procedures on your tracking methodology and they should be incorporated into your general security policies and procedures (in too many organizations it is that dusty 4" white binder in the corner of someone's office).
Now that the work is done, kick back, put your feet up and finish reading that 5” CISSP study manual.
Until the next time, keep those cards, letters and shoes coming in. 
I WELCOME YOUR EMAILS TO:
db2locksmith at securedb2.com
Post from : http://www.dbisoftware.com/blog/db2_security.php
Printed from : http://www.dbisoftware.com/blog/db2_security.php?id=152