Security Review – Workshop 1 – Access Control

Context:
Security review from user access control point of view.

The below are some of the key points to dicuss and uncover on existing and to-be state, drive out the action items.

Key factors:

• User Identification & Authentication
• User Access Authorization
• Access Review & Recertification
• User Lifecycle Management
• Access Modification & Revocation
• Privileged Access Management
• User Activity Monitoring
• Access Logging & Audit Trails
• Access Monitoring & Compliance Audits
• User Authentication – Password Policy
• Multi-Factor Authentication
• IP Whitelisting
• User Authorization – Role-Based Access Control (RBAC)
• Access Control Lists (ACLs)
• User Session Management – Session Timeout
• Single Sign-On

Ideal Outcome:

As-is state and to-be state

So that a migration strategy and roadmap could be established, including the cost & timelines.

What can you stop doing?

Ok, I am coming back into this after rather a very long time.  I have been thinking about starting to write for a while now, as it really helps you think and get clear on your head if you ask me. I do write a bit as part of my job, although mostly technical and content specific and this freedom of being able to write on anything is even more satisfying.

To the topic now, I was having this conversation this morning with one of my colleague and he asked me couple of interesting questions.

1. What can you stop doing? (in the context of your job – to maximize time)
2. What the best value an Architect can add?

While they both seem unrelated, there is a lot of synergy between these questions and they shape what we do on our day to day job.  In my view if you answer question 2, you are answering question 1 regardless.

As an Architect (read as Solution, Data and in general IT Architect), the biggest value one can add is defining the need.  The business (from top CxOs to bottom middle managers) generally comes to you as wish list.  i.e. what they “think” as the requirement that will satisfy all their needs or solve their current problems.  But if you are really good and able to understand the essence of the “ask or wish” in the context of the organisation, its business, underlying constraints (IT, operational, cost, risk, etc)  – [see through the clutter and complexity] and able to come up with actual “need“, then you have already solved 80% of the problem.  And in my nearly 20 years of experience, trust me, the need is usually very different or much smaller than the original ask.

This I believe is the biggest value the architects can add.  So what you need to stop doing is taking the business wish list as a Gospel and turn the world upside down to solve it.  As once you start on the wrong foot, the chances are you are multiplying the waste factor from then on.

So how do you know you have understood the problem and you have established the need.  An Interesting thought that can support this here, – don’t know the source but I do remember and made a lot of impact in my life is “if you understand the problem, you should be able to articulate it in simple language under 30 seconds to anyone, failing that means you don’t any idea about what you are talking about”.

This however requires a holistic knowledge of business, (i.e. domain knowledge, how business works and its people), information being processed and churned in & out (data) and the technology in place to support and scale the above. And this comes with experience.

Some of the other techniques you can use to filter down waste from your downstream activities, you can adopt methodologies like critical chain (especially the network diagram/logic that maps the network activities), agile or recruit a bloody good project manager or scrum master who will ensure the effective usage of time & resources once he has been given the clear, concise business need and what need to be delivered.