Re: Local Admin Access

[Henry Wojteczko <hank.wojteczko () CLASSEDESIGNUSA COM>]

Colleagues:

There are many types of admin accounts, inclusive of root for Linux, cloud admin accounts, services accounts, cloud 
admin accounts, etc. Strategies should encompass the entire IT ecosystem to ensure privileged accounts remain secured.

Linux systems should be considered a juicy target since they often contain an organization’s most sensitive data, such 
as health care and ERP. Ransomware criminals know this, and there is a lot of code available on the dark web for 
purchase to probe and penetrate this systems. I personally have examined code from root kits that are capable of 
engaging in multipronged stealth attacks that are undetectable to many classes of detection software.

First and foremost we use SSH key authentication for all managed systems. The SSH keys have a very complex pass phrase. 
For all resources accessing internal or client systems, we require that a password manager be used for storage of the 
pass phrase, such as KeyPass on Windows. Local password authentication is disabled, and service accounts like oracle, 
banjobs , and banner never have a password set. We use sudo and authorized resources must first authenticate with their 
non-priv’d ID and then sudo as the service user, or in very restrictive and limited cases, root. As a precautionary 
measure, SSH root login access is disabled in sshd_config. End users are never permitted direct access to database 
resources, be such access via SSH or sqlplus.

Directories for service users and code bases are set to an access mode of 750 or 700. None of this Oracle pre-install 
nonsense of 755 allowed. Auditing is enabled, and audit files are archived off the OSs should analysis later be 
required.

Root console passwords are set for emergency recovery, are highly complex, and follow the same conventions described 
above for password management.

Data backups are in cloud, to object storage, with retention periods that are defined to conservatively version backups 
so we can reconstruct systems from scratch should the need arise.

We have been moving towards containerization for some time as part of an effort to create a more manageable, portable, 
and secure application tier for mission critical applications. As is true in most DevOps models, we consider 
application services to be immutable and disposable. We also consider nodepools and k8s backplanes disposable as well. 
This is not to suggest that containerizing makes your app tier more secure. What we are saying is that we refactor 
applications to be as secure as possible from the get-go in an attempt to raise the bar so high that an intruder will 
simply move on to easier targets.

For cloud admin accounts, we are moving in a direction away from daily use of UIs (OCI console, Azure Portal, etc) 
towards managing the infrastructure as code with API key pairs. Code may be declarative or imperative dependent on the 
problem to be solved. Code bases and image layers are built into secured container customized images that do not 
contain any credentials. These images are pushed by developers to docker hub and are later pulled either to a cloud 
admin’s desktop or to an orchestration cloud resource (such as Azure DevOps). Once running as a container, cloud API 
key pairs are created or are securely stored within the orchestration tool. Cloud infrastructure is then managed from 
within the container, with the UI used only when needed.

Finally, we are looking into confidential computing as a possible future state of computing. I personally believe there 
is a bit of vendor hoopla and hype around this evolving technology, along with the usual false claims by some shady 
players. I believe that confidential computing will further raise the bar on security. It is my opinion that most 
vendor products are not there yet.

In closing, I hope the above sparks more discussion around the topic of effective management of local admin and 
privileged account identity management. The risks are BIG, as are the challenges. The more we collaborate and listen, 
the more effective I hope we can be in protecting our most vital information assets.

Thanks;

Hank Wojteczko
Practice Manager – Cloud Professional Services
David Kent Consulting, Inc.
832.226.4432(m)
hankwojteczko () davidkentconsulting com<mailto:hankwojteczko () davidkentconsulting com>
www.davidkentconsulting.com<http://www.davidkentconsulting.com>

Notice of Confidentiality:  This E-mail message and attachments (if any) are intended solely for the use of the 
intended addressee(s) hereof.  In addition, this message and the attachments may contain information that is 
confidential, privileged or otherwise exempt from disclosure under applicable law. If you are not one of the intended 
recipients of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating, or 
otherwise using this transmission.  Delivery of this E-mail to any person other than the intended recipient is not 
intended to waive any right or privilege. Unauthorized use of distribution is prohibited and may be unlawful.  If you 
have received this E-mail in error, please notify the sender by reply E-mail and immediately delete this E-mail from 
your system and destroy any and all other copies.  Thank you.


From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> on behalf of Steven Alexander 
<steven.alexander () KCCD EDU>
Reply-To: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU>
Date: Friday, May 14, 2021 at 2:55 PM
To: "SECURITY () LISTSERV EDUCAUSE EDU" <SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Local Admin Access

I missed this initially but since the thread is active now, I'll jump in.

We are working to eliminate users running as local admin. For staff who truly need it, including IT staff, we create a 
secondary account with local admin rights. We are also in the process of rolling out LAPS and plan to have it 
implemented everywhere within the next few weeks.

My concern isn't users abusing their privileges, it's that getting local admin is often a key step in compromising a 
domain. In particular, if you want to run mimikatz or another tool to dump credentials, you need local admin 
privileges. We're doing other things to protect against this (e.g. disabling Wdigest, using the protected users group) 
but local admin still matters.
If regular users accounts have local admin, or if users are using a local admin account as their daily driver, it 
provides an attacker with a much easier pathway if they are successful in compromising those user's machines (they 
don't have to find a way to escalate). It's a mistake to look at local admin rights as affecting only the security of 
individual machines. Managing local admin rights is important for the security of the whole network/domain.

Steven Alexander
Director of IT Security
Kern Community College District
________________________________
From: The EDUCAUSE Security Community Group Listserv <SECURITY () LISTSERV EDUCAUSE EDU> on behalf of Emilie Kunze 
<ekunze () AUSTINCC EDU>
Sent: Wednesday, April 7, 2021 10:08 AM
To: SECURITY () LISTSERV EDUCAUSE EDU <SECURITY () LISTSERV EDUCAUSE EDU>
Subject: [SECURITY] Local Admin Access

We are curious how other institutions handle local admin access for faculty/staff?

Thank you,
Emilie


[Image removed by 
sender.]<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2faustincc.edu%2f&c=E,1,gKVH9FTo-lhK1-gU_tbpx5TuXDICwmJesRSmT0gjBD_PikfZplqW3f18jrtSAmN3pODAAumo_Rir6t5ZLRpYLXO3Tbc4kpDQMQFeVmUXW9B7pP1kwIz22w,,&typo=1>

Emilie Kunze

IT Security Analyst Sr.

Acting Information Security Officer

Office of Information Technology

ekunze () austincc edu<mailto:ekunze () austincc edu>  | o 512-223-1157

ACC Information 
Security<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fit.austincc.edu%2fdepartments%2finformation-security%2f&c=E,1,-0jT9_WAX6ICKufqi_zp-lMAE6mTxfM7J8czsYIaDRFd_m6C5C5jSuESewIZq-9gOX71D0YPXB34whZfvbsrfuVSvLYaBRy88GWtzh8rNrUaHhMEOFU,&typo=1>

      [Image removed by sender.] <https://www.facebook.com/accinfosec/>     [Image removed by sender.] 
<https://twitter.com/ACCInfoSec>


                                                  CONFIDENTIAL NOTICE
This communication, including any attachments, may contain confidential information and is intended only for the 
individual or entity to which it is addressed. Any review, dissemination, or copying of this communication by anyone 
other than the intended recipient is strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply e-mail, delete and destroy all copies of the original message.


**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.educause.edu%2fcommunity&c=E,1,GjxHaovsgcDbCMoMQsWpikNrWYW9cwN2sVXzAVfumLswfjVKCuFexME-c-Be43RJs6LwojP0XcQpnBi7Y-jc3BVN9SylwVB3faURSXwTJuZ4&typo=1>

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**********
Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the 
person who sent the message, copy and paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community