Cyber Security - The Design perspective: Cyberattacks through the decades

While my search for the elusive unified security metric continues unabated, today, I wish to focus on an understanding of cyber attacks through the decades. While the topic may appear tangential to search of that unified security metric, I can assure you that in time, we can connect back to our search from my minor detour that I take today. Please read on.

Over the years, cyberattacks and consequent data breaches have intensified in both quality and quantity. The Centre for Strategic and International Studies in Washington DC has studied such attacks and documented their impacts. Besides, there are several news portals and technology magazines that have opted to track the nature and disruption caused by such attacks in history. For instance, the Digital Guardian (on data breaches) and ZDNet (on major cyber hacks) articles highlight some of the major events that are imprinted our memory. In some ways, these attacks and our own responses have etched a path for our current state of affairs. This article attempts to discuss our understanding and interpreting the nature of such cyberattacks, the context under which these were carried out and any lessons on design that one may glean.

Early Cyberattacks

Historically, most systems were held on-premise, with limited or no access to the internet and over time it was deemed not to scale with the needs and requirements of nations or organisations. In such early days, cyberattacks did not need to much beyond access the user database and access their credentials, often stored in plain text.

Gradually, with the advent of federated identity management and authentication mechanisms, they opened for access. Of course, along came the necessary tools of trade to abstract the identities and authentication keys via complex cryptographic and hashing schemes. Given this complicated the discrimination of users’ credentials, one from the other, cyberattacks focussed on gaining the access to authentication keys, stored in user’s system memory, while they were in effect. It gave the attackers a small window of opportunity to create guile and dupe the users into willingly provide access to their machines and system memory to obtain this information. A wide range of cyber attacks through the previous decade was pivoted on this approach. Of course, during this time, we all became familiar with the term “phishing” and emails and messages related to “phishing”. 

There is a point I note here, federated identity and authentication takes a user out of their current context and establishes authentication beyond reasonable doubt before bringing them back to where they took a detour. Organisational mechanisms kept this process to within the organisational boundaries; however, it is not necessarily a condition for this technology to operate, which of course was leveraged quite heavily. We shall get to that momentarily. Please read on. 

Evolution in the Malware Detection Spectrum

When access to users’ system memory became routine, the cyberattacks thrived in not “doing the deed” themselves, but in fact, making the users act on their whims and fancies. This was the era where we saw the advent and proliferation of “fileless malware” and exploitation of vulnerabilities primarily for the purpose of remote code execution (RCE). These fileless malware leveraged native operating system tools using the credentials of a user who was logged in to conduct the attack, often without the user’s explicit permission or even knowledge. This period witnessed a revolution in the malware detection space from many prominent vendors when signature-based malware detection gave way to behaviour-based detection. Artificial Intelligence and Machine Learning became mainstay in the cybersecurity industry. Numerous user entity behaviour models were generated across the spectrum that attempted to detect malware from user space, kernel memory and indeed even some got carried across to network detection methods. The intrusion detection methods slowly but surely gave way to intrusion prevention techniques on many network device vendors’ products and it was commonly rolled into routers as a soft function.

Understanding the AI/ML geometry

To those who understand machine learning this may be trivial, however, there is a point to be made. I do so with an analogy. When one teaches a child to play, one provides the child with a well-defined boundary, a sandpit, say, and establishes clear behaviour patterns that are to be expected. While the child is free to experiment and try out various actions, even those one did not envisage, the child is still bound by the terms one sets at the start of that exercise. The child may be provided with periodic or episodic feedback which can be regarded as suggestions to improve their performance, which of course the child can choose to assimilate or ignore. No matter the freedom that is given, it is entirely within the scope of the sandpit. 

So too, when a machine is expected to train to conduct an activity, one attempts to set the scope of the “experiment” before one allows the machine to train. In most examples, the training set, as machine learning scientists call it, are meant to define a coordinate system that covers the length and breadth of the sample space from within which outcome may be derived. However, in matters associated with cybersecurity, defining this boundary is often a grey area. Any input or programmed boundary defined should provide near-100%, if not complete precision and accuracy; the absence of which can yield incomplete or non-terminating experiments! The models from such experiments can have a hard time detecting the true cyberattacks when they occur. The point being, when attempting to develop a machine learning solution, ensure one’s problem statement allows for a clear definition of such boundary and the set of actions within the scope of the experiment. Where there is ambiguity in developing such a boundary, be prepared for further refinement, iteratively, until such time the boundary becomes concrete. Forcing an ML based solution is not an answer!

Representation State Transfer API

Around this time, organisations came to the realisation that infrastructure stored and managed internally was leaking on the balance sheets and hence an alternate up-to-date infrastructure solution was needed that would allow for debit as operational expenditure. Along came the public cloud infrastructure which allowed for workloads to be migrated and operated on a spectrum: from entirely within a single public cloud to partially split across public cloud infrastructure and split three ways between multiple public clouds and on-premise infrastructure. A whole suite of migrations later, users were toggling between access entirely on-premise to those on one or more public cloud infrastructure, each of which required strict access rules and strong authentication methods. Besides, during this time, a parallel revolution in the software industry saw the transformation in application access to representational state transfer API access.

An architectural design pattern, REST, defines the set of constraints under which the Internet architecture should behave in order to allow for resources to be exchanged or transformed over the Internet. It transformed the software middleware industry into a confluence of rapid stateful request-responses sequences. Any artefact on the Internet was accessible and operable as long as one had access to it. The whole gamut of services provided by the public cloud infrastructure is indeed a manifestation of this architectural design pattern. As REST API calls integrated access credentials and authentication tokens, one could access resources on far corners of the world with Internet access and this allowed for one to be anywhere and access anything! If not for this technological realisation of this architectural pattern, all of us would have struggled to conduct any work over the past 18 months, if not longer, during this enormous disruption to natural life as one would know with the novel Coronavirus pandemic. However, the pattern did allow for users to be anywhere and access anything, as long as they had access! Or, they had the access token! This allowed for a whole range of data breaches as reported in the various articles and documents where predominantly information from a variety of organisations stored in public cloud infrastructure was compromised using access to such credentials and access tokens. As organisations took cognizance of the “attack-surface” with growing cloud-based migrations, they attempted to introduce DMZ like sections of the network where a suite of jump servers allowed access to another part of intranet or internet, as the case may be. With it, came the additional security controls, often introducing another technology into the mix!

Supply-Chain weakness exposed

Despite this rather expected progression, vendors who were engaged in providing solutions, themselves, had their infrastructure on public clouds, which could mean users would need to move between two or more authentication mechanisms and across environments, often non-native, before they are allowed to access the resource they were after. Now back to my original point on federated authentication (Ref. section Early Cyberattacks), users were being forced into multiple environments, often non-native, where the authentication occurred. Each exit and re-entry into one’s environment created a compounded effect on the attack surface one was exposed to. As users adopted more and more technology vendors, each of whom, had their own public cloud infrastructure footprint, one or more, the number of such steppingstones to one’s original goal of access to an organisational resource became more challenging. This development gave rise to a wave of unsurprising yet unexpected supply chain attacks which have created a wave in, not just the industry but whole economies!  

As nations and organisations, reeling from the wave of attacks on their economies lick their wounds and attempt a return to normalcy, one might ask, have we let loose Mr Hyde and if so, how do we rein it in to bring out Dr. Jekyll? Should we examine the translational paths for one to access one’s resource, wherever it may be? Should we perhaps look into the number of such technologies that come between us and our resource? In closing, I note that perhaps there is a quantification to be made for reining in the number of such translational technologies between one organisational resource and the next! Until next time.