Shadow IT and Technical Debt: The Adversary's Allies

Shadow IT increases your business' security risks and is invisible to you.  It might not be covered on your asset lists, because your asset management lists are incomplete.  It might have no assigned owner, either because it doesn't fit neatly into any business unit, or isn't related to any current operational priorities but hasn't been fully decommissioned yet.  It might have been installed outside of usual processes, either without authorisation or because usual processes were overridden.

As well as shadow IT that you may know nothing about, any internal network left to its own devices over time will accumulate systems and data that probably shouldn't be there.  There is always a finite amount of time and money available to build and maintain systems and without ever-increasing investment, it is almost inevitable that over time resources tend to become focused on maintaining BAU rather than implementing new projects or redesigning existing infrastructure to take business evolution into account.  When new features need to be considered, they are often implemented as quick fixes, or as part of an existing system to reduce the up-front investment needed on a project.  Over time, this creates a technical debt.

The problem with shadow IT and technical debt builds up over time inside because of decisions by individuals – and every one of those decisions usually has a legitimate business pressure behind it.

When legacy systems aren't needed anymore, sometimes there isn't time to decommission these because attention is needed elsewhere to develop new functionality.

When moving from one business process to a new business process, you might need to keep a set of older systems running to support a subset of customers who don't want to move to the new platform.  

When you decide to roll out a new set of security controls to your current estate, maybe you save a lot of money if you only roll these controls out to your active production servers, and leave out legacy systems, or development hosts.  Maybe you can't afford to monitor everything, so you focus on the systems that are most important to keep your business running right now.

When you're a developer working on a project with deadlines approaching, maybe it's quicker to run a bunch of services on a workstation next to you for testing, rather than following usual processes to deploy these on one of the servers in the environment.

Maybe you have to do a major upgrade to a piece of software, and you decide to take a quick backup before you do just in case anything goes wrong.

Every example above has a business imperative driving it in one way or another – prioritising innovation, focus on business development, budgetary constraints, the need to meet deadlines, and the need to keep backups around.  What is challenging for all organisations is that each of these decisions will, over time, have an unintended adverse impact on cyber security resilience as your technical debt builds up.

The shadow IT infrastructure doesn't feel very important when you're working on your business impact assessments.  It might not handle any critical data assets.  It probably doesn't support any important production processes.  If it goes offline, you probably wouldn't notice and it's likely none of your BAU would be affected.  But it does impact on the security of your other systems, in some cases seriously.

Picture a typical attack, if there is such a thing.  An adversary will launch a phishing attack against a member of staff and, if they're lucky, end up with a foothold on a workstation inside your infrastructure.  That's very rarely the end game for the attacker – they want what's on the inside.  Your data assets – it might be intellectual property, customer data, or credit card information.  The foothold is only the start – your attacker wants to consolidate their position, move laterally inside your network and elevate their privileges until they can act on their objectives.

Attackers are always trying to build a pathway from their latest compromise point towards their objective – they are drawing a graph towards their objective.  When we are attacking organisations as an adversary would, shadow IT inside the network is our first port of call.  It's often where we find the low-hanging fruit that lets us escalate our privileges.  

In centralised authentication environments like an Active Directory network, the compromise of a single server which has not been maintained will almost always lead to a compromise of the whole network because of trust relationships that can be exploited.  Compromise of the centralised authentication mechanism is usually one of the key points on the path to achieving our objectives – if we compromise Active Directory, we can then gain access to any of the systems or applications which rely on Active Directory as an authentication mechanism and therefore access the data we're interested in.

If you have legacy systems which are Active Directory member servers, and they are not included in the usual patch cycles, then we can exploit these legacy systems to further our aims.  Undocumented web applications, test platforms, data backups and database services are also extremely common and often give us the ‘leg up' we need to reach control of the internal AD environment.  

We frequently find unsanctioned file shares, and they have usually been created for convenience for a particular purpose – collaboration on a project, migration of a system or ad-hoc documentation.  They're often out of date, but the information these file shares contain is often useful to us (containing account credentials, backup files, documentation).

Shadow IT is often where security weaknesses in the wider network make themselves most obvious.  We often find accounts with weak passwords, or manufacturer-default configurations, passwords that are shared with other systems, or password patterns which have become well-known inside the business amongst systems administrators.   Critically, because these systems, applications and file stores are not documented, they are never cleaned up.

It's so easy to inadvertently store sensitive information somewhere temporarily and then forget about it.  Several people reading this have probably, at some point in the past, written a password down in a text file and saved it to a workstation or to a file share.  A few have probably backed up configuration files that they were working on to a file share, without thinking that those configuration files might hold database credentials, or keys for server components.  Amongst your thousands of users, only one person needs to do that and forget to clean up after themselves to give an attacker the first foothold they need.

Shadow IT is also one of the reasons why strict compliance-based approaches to cyber security can only help you so far.  If you are measuring patching of your internal systems as a security KPI, for example, then you need to be conscious that if you have a 99% success rate at patching servers, an adversary will probably find that 1% of servers you have not patched.  And if you have a 100% success rate at patching servers, you absolutely have to make sure that every server that exists is part of that measurement – if you have a server which is not enrolled in asset management and therefore not monitored in patch management processes, you could still be exposed and not be aware of it.

We talk about the "advanced persistent threat" a lot in security and it is easy to get hung up on the "advanced" part of that epithet.  Although "advanced" is dangerous, what we should be most concerned about is "persistent".  You may have thousands of servers properly enrolled in your technical controls, fully-monitored and fully-patched - and one undocumented server which is not patched and not monitored.  You can't afford to assume that an adversary won't take the time to find this weak link.  Once inside your network, a persistent adversary will not stop until they reach their objective; if that means examining thousands of servers, reading thousands of files or accessing thousands of databases, they are motivated to achieve their goals at your expense.

If you want to defend against an adversary who is persistent and motivated, you need to be equally persistent in making sure you have comprehensive asset management and understand exactly where and how systems and data are being used.  You also need to be prepared to detect and respond to intrusions that could happen at any time because of something you don't know you don't know.  The adversary looking to breach your defences only has to be lucky once; you have to be mindful all the time.