Working across organizational boundaries I hear the same refrain often enough to want to discuss it. From the intelligence analyst working an intrusion set I hear, “Why don’t they just patch their systems and we’d be fine.” On the other side I hear security engineers who say, “I need resources to get this job done.” All of this is related to the root cause of how we got here and why nobody is going to solve information security risk problems anytime soon.
The bottom line up front is that we engineered systems that provided radical improvements in productivity without thinking through the downstream risks of those productivity increases. In the mid 1990s we had the productivity paradox by the mid 2000s the paradox had abated. Once information technology productivity capabilities are cost adjusted into the profit and loss of a company the loss of those capabilities become core business risks. Think of it this way. A bank in a small town builds itself up, and over time the town grows up with the business. As the economy flourishes so does the bank. A vault meant to secure a thousand one dollar bills at the turn of the century now must secure a thousand, one hundred dollar bills. Orders of magnitude increase in value with the same security mechanisms.
The ramifications of technical security debt.
The business schools talk about how much more productive companies are in this new digital age. The automation revolution alone created new jobs and changed company business models. Software development strategies similarly have gotten very lean and very fast to meet the evolving needs of business. Between dev/ops and other rapid delivery strategies there is a substantial gain across all industry verticals moving forward. This represents a technical version of a gold rush. Though the fictional accounts of the American experience with the silver and gold rush are fantastical. They do show a pattern of high risk acquisition and deployment of assets only to have dastardly brigands challenge and pillage the resources. Now the west is filled with ghost towns.
There is an interesting principle to how you build bank vaults. I talked extensively with a vault engineer on how most consumer banks start building with a vault and then build the structure around it. I also spent some quality time talking to the Federal Reserve Bank Gold Vault custodians recently. Security of a vault is a key consideration of the business rules and architecture of a business. The same consumer bank vault engineer suggested money vaults were getting smaller as banks digitized all of their processes and he surmised absent safety-deposit boxes his line of work was in danger. I surmised that the money saved on physical vault security was not being captured in the information security realm since they are different verticals within a corporate financial institution.
Decreasing physical plant run rate costs during build out of a new infrastructure, or reducing the physical plant costs on a current structure through refresh is just good business. Increasing shareholder value is a principle requirement for the officers of a corporation, but also reducing overall technical risk is also important. The issue is that risk occurs in this limited case with an increasing technical debt that is realized as an information security event. Realizing that all analogies are subject to some whimsy. You might think of that technical debt as water being held back by a dam. As your internal controls are applied and if you are agile enough with your security practice the pressure will be relieved. If the business and efficiency drivers expand too rapidly and flood your solutions and technical systems a breach occurs and wide spread devastation to the business and organization results. Of course, none of the realized risk is at a time and place of your choosing. Often the catastrophic event is precipitated by a malignant influence or adversarial actor. That particular get out of jail free card is losing some of its efficacy.
The dams are built and as efficiency and productivity pressures mount against all businesses the flood waters of risk are building up behind the shaky infrastructure of your security program. Some will argue for acquisition of new technology that will build the dam higher or maybe thicker. Some will argue that the risk v. reward is misaligned and drill holes through the dam to relieve pressure in chosen spots versus a breach event.
Most pundits are going to tell executives to “just patch your systems” which is usually pandered by people that have never had to run legacy servers older than most of your techs, and or critical to the point of catastrophe. Entire business segments grow around these legacy solutions. Lost to many pundits is the fact that a developer in the distant past saw a business requirement. That requirement was turned into a technical solution of hardware and software. Often around what they knew rather than what was appropriate. Companies adopt the technology. The developer gets rich and retires to the beach. Companies make money. 20 years later you’re being told to patch the system. These technical costs are sunk costs. You aren’t going to be rebuilding the vault now.
What is an executive to do?
Start innovating towards security by rotating your security team through your engineering and business analysis teams. This is a low cost high speed method to get ahead of the productivity and security quandary by aligning security implementation with the production teams efficiency gains. Determine a risk appetite for the organization and an investment plan based on reality not percentage of the IT budget. Zero defect strategies require infinite resources and authorities but security is driven by business not the organizations operational IT costs.
If security requirements are driven by business requirements than security budgets should be tied to the business drivers. Given that almost never happens come up with new better aligned resource requirements separate from information technology operations. Use your infrastructure program upgrades as opportunities to increase security across the enterprise.
As an executive consider a strategic plan along the lines of refresh to success. Use your organizational refresh cycle to innovate towards a secure infrastructure. The more technical security debt you perceive within the organization, which is usually a reflection of the legacy nature, the more your strategic imperative. Consider creating an identified agent as an innovation entity within the security program. You should be actively hunting for stabilizing technologies for those legacy systems that allow you to facilitate business processes and secure the systems.
Of course, you could just hire me and I’ll bring all of this actionable information to your organization.
Key take away: Technical security debt is cumulative; information security budgets should be aligned to business requirements not an artifact of information technology base budgets; Information security is a core business driver.