Vulnerability Through Disablement
The question of whether a system or network is vulnerable hinges on the concept of vulnerability. If there is no vulnerability, the organization is impervious to attack or at least the ensuing adverse outcomes. This being the case, it becomes important to explore the nature of vulnerability. Vulnerabilities are often perceived to be intrinsic or internally defined – i.e. there was something wrong during inception or at the very outset. In a very real sense, many vulnerabilities are externally defined (or externally triggered). I will provide an example. If everyone in the world required a wheelchair – and the world were optimized for wheelchair use – then being in a wheelchair hardly represents much of a vulnerability. However, in a world where wheelchairs are a passing afterthought, being in a wheelchair can be dreadful. Just overcoming slight changes in ground elevation such as a curb would be challenging, and perhaps even exhausting over time.
These dynamics persist even in relation to systems. Differences in hardware or coding might not be problematic until challenging external conditions are imposed. It can be said of zero-day exploits, the same conditions likely existed perhaps for years, during which the system performed its functions according to design. A pediatric cardiologist once told me, I can avoid losing consciousness during gym by not participating in competitive sports. True enough, by avoiding competitive sports for decades, I managed to remain fully coherent during physical activities.
The basic idea is that all systems, processes, and people likely contain some vulnerabilities. It is a bit of a Rogerian perspective to commit to work with and make the most of these often natural limitations. Conversely, the other side of the discussion are the metrics of exploitation, which coincidentally can lead to the organization itself being exploited by hackers. Consider an extreme example first, just for the sake of argument, essentially oppressive in nature. A manager essentially expected everyone in a backoffice to work at least 14 hours per day. “No vacation or sick days allowed!” she said in a cavalier manner. This was meant to demonstrate not just of authority but of social placement.
The employment situation being what it is, the company was routinely able to find employees willing to work under these physically challenging conditions. The company had no front-end system for its relational database environment. The workers entered SQL manually. It became evident that this manual-entry approach seemed to cause share units to disappear from investment portfolios. The workers would reverse batch runs and try again repeatedly, obtaining different share units each time. They would sigh and simply continue on with the rest of the processing. Little did they realize that the database was skimming units from clients and redirecting them to an account for a non-client.
So in a sense, the relational database was “vulnerable” to exploit. But based on the above, actually on a deeper level it was operating in the intended manner. The database was being used but not exploited. The backoffice personnel were subject to exploitation. In a different company that expressed some level of compassion for workers, cared about the outcomes of production, and was uncompromising in its commitment to clients, there would be a greater level of employee empowerment. The question of how to quantify disablement is perhaps evasive. It just so happens I have a graduate degree studying social disablement in workplaces. What an amazing coincidence, right! In any event, as we enter the era of enterprise hacking where social engineering has been weaponized, I suggest that the external impairment of workers – their disempowerment – creates competitive disadvantages for the organization.