Like many in the IT security profession, I welcomed the recent remarks made by outgoing CISA chief Jen Easterly, in which she pointed out that making software safer may not be easy or cheap, but is the only way to truly protect IT systems.
Easterly’s comparison of today’s software industry with the “before seat belts” automotive industry of the 1960s struck me as particularly apt. Unsafe at Any Speed, published in 1965 by Ralph Nader, precipitated transformational change in the auto industry, arguing as long as carmakers were allowed to self-regulate, they would continue to prioritise style, cost, performance and calculated obsolescence over safety and the best interests of the consumer.
They would also continue to victim-blame when it came to accidents, casting drivers in the role of “the nut behind the wheel”, rather than shouldering the responsibility for inherently poorly designed cars.
Sixty years on, there are clear parallels with modern software products. With developers in hot pursuit of style, speed and other priorities, bugs and vulnerabilities persist. And there’s a fair amount of finger-pointing at users, too. We are told they don’t know how to use these systems safely or to protect them adequately. This convenient narrative conveys the message that, with users like these, is it any wonder that ‘accidents’ like ransomware attacks and data breaches occur?
But as Easterly has pointed out, that’s just not fair. We cannot continue to accept dangerous software and we need to dig deeper into the issues and flaws that lead to breaches. The work that CISA is doing with the Secure By Design initiative is an incredibly important and constructive step in holding the software industry more accountable.
But as customers, we also need to play our part in pushing for change. In the year or so following the publication of Nader’s book, the United States adopted two auto-safety laws and established the National Traffic Safety Agency. Over the decades since then, customer pressure has helped drive the widespread introduction of seat belts, anti-lock brakes and airbags.
Demanding better from suppliers
As buyers of software, organisations should demand better from suppliers – and the IT security team must play an active role in any and all negotiations with them. In fact, it should be involved from the earliest stages, stepping in during the procurement process and championing the security message.
Without that involvement, the risk is that an inherently insecure piece of corporate software gets purchased and installed, later resulting in a whole stack of problems for IT security: lots of patches, lots of updates, plenty of fire drills and emergency responses. In short, you’ve got a piece of software that represents a significant drain on resources and a consistent source of interruptions for the IT security team. In terms of the car analogy, you’ve just purchased a lemon.
After all, it’s not unheard of for an executive team to make a software procurement decision based on what other organisations are doing, what product is considered to be ‘market-leading’, an existing relationship between the organisation and a particular supplier, or numerous other considerations – but all to the exclusion of what’s actually best for the organisation’s environment and its security.
In reality, the CISO and their team are accountable for making sure that every piece of technology brought into the organisation aligns with its risk posture and its well-defined security controls. In short, they have to determine whether this proposed purchase will meet the same requirements that every other piece of software is expected to meet.
In my experience, this is where a formalised ‘blind’ Request for Proposal (RFP) process can pay dividends, ensuring that software procurement decisions are not swayed by brand reputation or marketing clout. From there, the IT security team should be actively engaged in proof of concepts (POCs) that involve trying out elements of the new software within the current environment, making sure they work and identifying any potential issues, taking the software for a “test drive,” if you will.
This will give the IT security team a solid foundation for engaging colleagues from elsewhere in the business in a robust conversation about risk. It’s rarely (if ever) a case of the IT security team attempting to veto a purchase. It’s more about them helping the organisation to understand how to mitigate identified risks – or accept them, if the organisation turns out to be comfortable with those risks. Above all, it’s about understanding risk-appetite within the organisation and how that plays out within the context of what the business is trying to achieve.
Buyer beware
But above all, the IT security team should be part of a wider organisational effort to expect more from suppliers – our own effort to insist on ‘Secure by Design’, within the microcosm of an individual purchase.
Put simply, the risk landscape that IT teams face today, with its many data breaches and attacks, is the direct result of not expecting more, of simply accepting that regulations and compliance requirements around IT security must necessarily be shouldered by the purchasers of software, and not its creators.
That must change. We must raise our expectations and shift accountability, because until that happens, customers will continue taking on work post-implementation that software companies fail to carry out when they design products. If customers didn’t have that work to do, then they could spend more time looking at how they could run their environments better, provide better customer experiences, and help businesses achieve their top- and bottom-line financial targets.
For the auto industry, the first priority had to be a safer, more accident-proof automobile. For us, it must be safer, more breach-proof software.
