As anyone that has worked in IT for some time will tell you, there are moments when things just hit the fan, for all sorts of unexpected reasons. Systems will shut down, services will stop, CPU or memory utilization will render systems or apps unusable, rabid gangs of squirrels take over the data center…all totally normal. OK, maybe not the systems shutting down, that would be abnormal, of course. The point is - what do you do? What emergency procedures do you institute to get things up and running again in a timely fashion, minimizing the impact to the business while still following established protocol?
The problem is this: we often don’t have much in the way of real protocol when it comes to emergency and incident scenarios. Things go south on us, we react, and most of the time people are focused exclusively on just getting things running again as they should be. Is that such a bad strategy? On the one hand, this strategy is perfectly sound. Keeping things running is always job number one for people who work in IT operations. However, the way we handle administrative access to systems during emergency scenarios often leaves a lot to be desired, and in some cases may even expose us to entirely new channels of risk that we didn’t face before.
By now, most organizations are coming to realize that privileged accounts and access to systems and applications deserves attention, and this may even be mandated by compliance requirements. The usual first steps to curbing admin access include gathering an inventory of privileged accounts, using lower-privilege accounts to conduct day-to-day tasks, and restricting (or at least reducing) the use of default privileged accounts like local Administrators on Windows and “root” on Linux, for example.
However, some of these measures can go entirely out the window when emergencies or incidents occur. Often, the local privileged accounts get used for system access, ideally with a “break glass” password that has been set aside in escrow for such scenarios. While this is not a great practice, it works in a pinch, and most teams are comfortable with this idea for extenuating circumstances. However, one crucial factor that often gets left out of the equation is CONTEXT. Where is the admin logging in from? What time of day is it? What system is being used to initiate the access?
These are important things to consider, and should play a role in how privileged access is granted or managed, including monitoring all activities taken by the admin while logged in. Ideally, a password will be “checked out” from a secure, random one-time password generation platform for these situations, but that platform should be smart enough to apply granular policies to the emergency account based on contextual factors that exist, as well. Without context, admin access could be granted from unsafe locations or to unapproved systems or accounts, opening the door for attackers or other malicious activity to occur.
Join me in this upcoming webinar with BeyondTrust, where we’ll delve into this idea of applying context to privileged access, even in emergency and incident scenarios.
Register Now | Just-in-time Privileges – Using Context to Determine System Access |December 10, 2015, 10AM PT / 1PM ET
Dave Shackleford, Cybersecurity Expert and Founder of Voodoo Security
Dave Shackleford is the owner and principal consultant of Voodoo Security and a SANS analyst, senior instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering, and is a VMware vExpert with extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies.
