Revoking permissions as a Leader

[tmekelburg1]

"...once you go into leadership in one of my programs, you give up console access to technical systems. The reason is that it erodes trust, your job should be focused on mission, leadership, and being a good steward of the people. Your mission has changed..." -Steve Moore

Obviously not all organizations can do this if they have a smaller department but the idea behind it is to train and mentor first. Not just fix the issue yourself because you can do it quicker or better. Do you agree or disagree with his statement? Or is it one of those "it just depends"?

The New CISO: Empowering People to Bring Their “Whole Self” to Work 

[denbesten]

I think there might be a distinction to be made between "read-only" and "edit" access.  I tend to be much more generous with random IT staff being able to peek under the hood, but quite restrictive with who can play in my sandbox.

[mgorman]

As you said, not all orgs can do this, as they may not have the staff.  My other thought is, where does "leadership" begin organizationally?  A Manager would be nearly impossible to enforce this on, as they may need to train, monitor, and backfill their staff at any time.  Moving beyond to Director, or whatever the Manager supervising role is in the org could take that step.  I think it would be a strong move for a couple of reasons.  To the point of trusting your staff, it is a very clear message.  I also think that in the current trend of working to make cybersecurity a business enabler and partner, it would send a clear message to the leader that their job is to lead; their team, the culture, and the business.

[Steve-Wilme]

It depends on the sort of leader that is expected.  If a leader is expected to step in, if there is a major incident and/or to understand the detail then removing the access may not be the best course.  It may be better to have a transition period during which the people being managed/lead get fully up to speed and take over the reins rather than feel abandoned.  You have to consider than some simply would not have the experience or confidence initially and could decide to vote with their feet and leave the organisation, at which point you're left leading less or no people at all.

[tmekelburg1]

---

@Steve-Wilme wrote:

 If a leader is expected to step in, if there is a major incident and/or to understand the detail then removing the access may not be the best course. 

---

I had the same thought. There could possibly be an emergency account pre-setup, e.g., in an emergency procedure binder that had credentials in an event of an incident. Not saying that's the best way to do that but there are workarounds. 

I view this as more of a mindset and not really taking away permissions unless all of these little 'gotchas' have been thought out well in advance. 

[CraginS]

Size and structure of the organization make a difference. The COOP and DR policies should make it clear that every key system administrator position must be at least two deep in terms of access and control privileges. Then the COOP and DR plans should show who by position holds those accesses and privileges. In a relatively small operation, key top management may need to be the back-up admin for some duties to fulfill this requirement. 

Security reviews and audits should confirm that the people in the designated positions know they have that back-up responsibility, and how to carry out the tasks should it befall to them. COOP and DR exercises, even if just table-top, should exercise these fail-over shifts in task completion.

Craig