cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tmekelburg1
Community Champion

Revoking permissions as a Leader

"...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 

5 Replies
denbesten
Community Champion

Re: Revoking permissions as a Leader

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
Contributor II

Re: Revoking permissions as a Leader

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
Advocate I

Re: Revoking permissions as a Leader

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.

 

 

-----------------------------------------------------------
Steve Wilme CISSP-ISSAP, ISSMP MCIIS
tmekelburg1
Community Champion

Re: Revoking permissions as a Leader


@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
Defender I

Re: Revoking permissions as a Leader

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

 

D. Cragin Shelton, DSc
Dr.Cragin@iCloud.com
My Blog
My LinkeDin Profile
My Community Posts