cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
d46j48fx
Contributor I

Access control advice requested: the sysadmin has become the IT manager

Hi colleagues!

 

A technical team lead for an understaffed IT team with extensive organization and technical knowledge has been promoted to manager of their team. This individual literally has "the keys to the kingdom".

 

I would appreciate your advice/direction regarding the individual's system access privileges.

I am thinking I should apply a "need to know" perspective to this and recommend a complete revocation of admin/god-level system access, or reduce access to what would be necessary to function in their new role as manager of the team.

 

I would appreciate your advice on this matter as soon as possible, preferably before July 1st (which is when the individual will be assuming their new role.)

 

Thanks in advance for your input!

 

Derek

 

 

11 Replies
AppDefects
Community Champion


@d46j48fx wrote:

 

A technical team lead for an understaffed IT team with extensive organization and technical knowledge has been promoted to manager of their team. This individual literally has "the keys to the kingdom".

 

I would appreciate your advice/direction regarding the individual's system access privileges.

I am thinking I should apply a "need to know" perspective to this and recommend a complete revocation of admin/god-level system access, or reduce access to what would be necessary to function in their new role as manager of the team.

 


I'll assume that they understand the need to enforce least privilege for roles, but sometimes putting it to them in terms of risk and liability works. Whatever you do make sure that they do not have access to application/system event logging mechanisms. Those logs might save you one day.

kevinkidder
Newcomer III

Derek,

 

The principle of "least privilege" should apply to each and every job role as a basic tenant of security. That being said, it is most effective when coupled with separation of  duties. Many organizations, unfortunately don't adhere to least privilege principles and access is coupled with positions (the higher your management position, the more access you are granted).  This is, for obvious reasons, the worst security posture, as phishing, spear phishing and whaling are intended to target people with access.  

 

Do you believe that this individual in their role will be granted access beyond their requirement? Or will they be a working manager, where they should be doing the work of the sysadmin along with management? 

 

Another consideration is privilege creep.  Take for example, Mary who works in Billing. She has access to Billing systems, data, etc. Mary has taken a new job in credit finance, so now access to those systems are added, but no one clean up her old access. Now she is in a position where she can create fraud because her access violates the company's checks and balances. 

 

I hope that helps.

 

Kevin

AppDefects
Community Champion

If you are in the financial world then you probably are familiar with what @kevinkidder describes as "privilege creep" - great concept, bad name. Anyway, that is something a SOX auditor will look for measure you against. Make sure there is at least an annual account review process policy or one that kicks off with a job change.

d46j48fx
Contributor I

Hi Kevin,

 

My understanding is there is a back-filling attempt in progress, during which the individual will function as sysadmin until their current role is filled.  From that point onward, my understanding is that the individual will be functioning as a people manager only, albeit with vast technical knowledge.

 

From a "separation of duties" standpoint, I believe the individual should have their sysadmin privileges revoked and the responses so far (thanks!) seem to substantiate my thinking. 

 

"Privilege creep" would also come into play as the individual has been with the organization a long time and has no doubt accumulated access privileges along the way.

 

I'm thinking to have the individual's privileges transitioned to another member of the team and possibly myself as, right now, if something untoward was to happen to the individual, no-one else (not even their current manager) has access to their "key ring".  Any thoughts on that?

 

Thanks!

 

Derek

d46j48fx
Contributor I

@AppDefects ,

 

Thanks for your responses.  Account review has been occurring on an event-driven basis but it is certainly been on my mind to formalize the process going forward.  Thanks for the reminder to do so!

 

Derek

Shannon
Community Champion

 

 


@d46j48fx wrote:

 

A technical team lead for an understaffed IT team with extensive organization and technical knowledge has been promoted to manager of their team. This individual literally has "the keys to the kingdom".

 

I would appreciate your advice/direction regarding the individual's system access privileges.

I am thinking I should apply a "need to know" perspective to this and recommend a complete revocation of admin/god-level system access, or reduce access to what would be necessary to function in their new role as manager of the team.




The manager essentially has to know everything that he's managing, so a need-to-know methodology may not work --- instead, you can use one of least privilege allocation. Assuming he already has accounts with root-level / enterprise wide privileges, create accounts having read-only access on the systems, so that the privileged accounts needn't be used for this. 

 

 

Also take the following steps:

 

  1. Ensure that you've got organizational policies that define requirements for account management, logging, & auditing --- all approved by top management before you go about enforcing them.
  2. Configure logging for all privileged accounts, either on your directory service, or another system set up for this.
  3. Ensure that personal accounts aren't given administrative privileges, but dedicated accounts are used instead.
  4. Configure account privileges so that logs can only be edited / deleted by a specific account, so that holders of privileged accounts can't cover tracks. (Credentials for it should reside with the top management)
  5. Keep privileged accounts disabled unless they have to be used.
  6. Set up appropriate retention periods for the logs --- if a SIEM is being used, have it collect the logs, properly retain them, and configure use cases to trigger alerts for specific accounts.

 

Even if this person has the keys to the kingdom, your measures will ensure that he can't do much after entering --- other than looking at everything.

 

 

 

Shannon D'Cruz,
CISM, CISSP

www.linkedin.com/in/shannondcruz
rslade
Influencer II

Managers should have read access to everything, and write access to nothing ...

====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
`But that's ... completely ridiculous! ... [Y]ou could claim that
*anything's* real if the only basis for believing in it is that
nobody's *proved* it doesn't exist!'
`Yes, you could,' said Xenophilius. `I am glad to see that you
are opening your mind a little.'
- `Harry Potter and the Deathly Hallows', J. K. Rowling
victoria.tc.ca/techrev/rms.htm http://twitter.com/rslade
http://blogs.securiteam.com/index.php/archives/author/p1/
https://is.gd/RotlWB

............

Other posts: https://community.isc2.org/t5/forums/recentpostspage/user-id/1324864413

This message may or may not be governed by the terms of
http://www.noticebored.com/html/cisspforumfaq.html#Friday or
https://blogs.securiteam.com/index.php/archives/1468
dcontesti
Community Champion

Sorry for being late to the game on this one.  I am going to make an assumption (I know bad move) that you are a windows shop.  If you are you can use GPO to granularize their rights.

 

Or have you considered forcing the use of two accounts.  One for their everyday usage (non-privileged, limit access to only what they need) and then have a privileged account that they must Su/SUdo to the new account (UNIX) or Run CMD to use.  This allows you a couple of things:

 

1) the access is restricted to exactly what they need

2) the SU/Run CMD is auditble so you know when they are using the Account and can trace what they are doing.

3) If Windows, you can also use GPO to restrict what that Admin account can/should be doing

 

The last thing I recommend is that you put this in Policy along with repercussions for not adhering to policy.

 

I agree that no manager needs a privileged account for any reason.  

 

 

My two cents

 

d

 

 

Steve-Wilme
Advocate II

You probably need a short transitional period, which you agree with the new manager up front, during which the team can be resourced and they can step up into their new role.  Cutting off admin level access straight away probably isn't workable.  Once in the new state with the manager only having read only / audit access then you'd also need to implement a periodic check of admin privilege to ensure least privilege remains in place going forward. 

-----------------------------------------------------------
Steve Wilme CISSP-ISSAP, ISSMP MCIIS