Educause Security Discussion mailing list archives
Re: Local Admin Access
From: Henry Wojteczko <hank.wojteczko () CLASSEDESIGNUSA COM>
Date: Sun, 16 May 2021 17:16:26 +0000
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
Current thread:
- Re: [External] [SECURITY] Local Admin Access, (continued)
- Re: [External] [SECURITY] Local Admin Access Andy Leffler (Apr 07)
- Re: [External] [SECURITY] Local Admin Access Kevin Ledbetter (Apr 07)
- Re: [External] [SECURITY] Local Admin Access John Ramsey (Apr 07)
- Re: [External] [SECURITY] Local Admin Access Rich Graves (Apr 07)
- Re: Local Admin Access Madl, Michael (May 09)
- Re: Local Admin Access Clark Gaylord (May 09)
- Message not available
- Re: Local Admin Access Clark Gaylord (May 14)
- Re: Local Admin Access Lovaas,Steven (May 14)
- Re: Local Admin Access Clark Gaylord (May 14)
- Re: Local Admin Access Clark Gaylord (May 14)
- Re: Local Admin Access Steven Alexander (May 14)
- Re: Local Admin Access Henry Wojteczko (May 16)