One of the more common issues that those of us involved in trust in general and security in particular are guilty of perpetuating is that we tend to be a bit myopic when it comes to what we focus on when trying to ensure appropriate trust levels for critical assets. Our primary concern is almost always protecting confidentiality, with most emphasis on the primary access channels – e.g. user accounts. We spend a lot of time and effort implementing controls such as enforced strong passwords, multi-factor authentication, user activity management, encryption, etc. in order to try to ensure only appropriate agents have access to the our information. There are a number of significant factors that drive this behavior – massive amounts of press about data breaches, industry and government regulations that mandate it, and vendors that market it heavily all contribute to management translating ‘protect the data’ into ‘control access to the data’. But there’s a critical secondary control channel that can have a huge impact on the confidentiality, integrity and availability of your critical assets – the management interfaces for the infrastructure components behind the systems. These include everything from the management console for a storage array to the control dashboard for a cloud service. What kind of impact can an attacker have if they gain access to these interfaces?
Consider a scenario where an environment utilizes an intelligent storage array as back-end storage for a number of critical assets. A lot of resources have been devoted to ensuring user access to the front-end applications and data is locked down tight and monitored closely. But if an attacker or unscrupulous employee has management access to the storage array they could potentially create a point-in-time copy (snapshot or clone) of your sensitive data, mount it on an unsecured server attached to the SAN (e.g. a test server) and bypass all of your access and monitoring controls. Management interfaces tend to provide access to extremely powerful functions, ranging from creating new user accounts that could then be used to access your assets to deleting all of your data. The potential concern around properly securing management interfaces isn’t just hypothetical – several organizations,were recently hit with dramatic denial-of-service attacks when attackers gained access to their Amazon Web Services (AWS) management dashboard, demanded a ransom and , when they didn’t get it, began deleting critical customer data as well as the backups of the data.
One factor that is having a huge impact on management interface security concerns is the growing prevalence of what is commonly referred to as ‘shadow IT’ or ‘stealth IT’. This is where groups other than the official IT team contract for and manage their own IT functions, typically through cloud vendors. From the sales organization contracting with SalesForce.com to the marketing team leveraging DropBox to share collateral with design firms, the number of IT functions (and their associated management interfaces) not being directly controlled or even influenced by the IT team is growing dramatically. How significant is this growth? According to Skyhigh Networks, a survey of over 100 organizations and 3,000,000 users shows that the average organization accesses 545 different cloud services; the question then becomes how many of these services is IT even aware of, much less managing? And this trend will continue – Gartner estimates that by the end of the decade 90% of an organization’s technology spending will happen outside of IT. Unfortunately the individuals usually tasked with managing these contracted functions have little if any trust expertise, and usually consider the management function as a part-time job. The result is a mish-mash of shared management accounts, no monitoring and simple passwords that are never changed.
Organizations should ensure that management interfaces are at least well secured as user interfaces, and probably more so. Some points to consider are:
Policy – The organization should have a clearly defined enforced policy on management access for any IT service, regardless of where it resides in the organization.
Documentation – A system-of-record should exist for all management interfaces and accounts for all systems and services across the entire organization. Integration into change processes should be enabled to ensure automatic updates of this system-of-record whenever any changes are made.
Segregation of duties – Any given management account should only have access to the minimum functions necessary to support its role. If the vendor doesn’t support the concept of roles in its management interfaces you should probably consider a new vendor.
Risk-based authentication – The level of authentication should be commensurate with the level of risk for the role associated with any given management account. Enforced strong passwords that are regularly rotated are probably fine for an account that can only access utilization reports; two factor authentication should probably be required for any account that can negatively impact confidentiality, availability or integrity.
Segregation of access – Management accounts should not have access to or be able to gain access to the assets on the system being managed.
Monitoring and review – All activities on the management console should be closely monitored; ideally any activities that could impact significantly impact risk (e.g. creating a new user or management account, deleting a large amount of data, etc.) should require review and approval prior to execution. At a minimum such activities should be reviewed quickly after their execution to ensure their validity.
Communications – All network communications to the management interface should be encrypted.
Account protection – Any accounts used by or that have access to the management interface should be restricted from engaging in any risky activity (e.g. web surfing). Also, management accounts should not be shared – each individual should have a unique named account.
Account management – Account access should be modified or disabled as soon as the individual’s role changes (e.g. leaving the organization, transitioning to a new team, etc.)
IT administrators tend to be a finicky bunch – they typically claim that any additional overhead imposed by security controls will impact their ability to do their job and support the business. As a Trust professional it’s your job to work with IT management to help them understand the potential risks associated with an improperly secured management interface, then architect and implement the appropriate solutions to address those risks in an acceptable manner.