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 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 was also allowed to self-regulate, they would continue to prioritise style, cost, Performance and Calculated obsilescence 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 inhadly Desigedted 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 vulnerabilites person. 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' Accidents' Like Ransomware Attacks and Data Breaches Occur?
But as extraly 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 flws that lead to breaches. The work that cisa is doing with the Secure by design Initiative is an incredible 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 stages adopted two auto-safety laws and setable the national traffic safety agency. Over the decades insurance 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, Organizations Should Demand Better from Suppliers – and the It Security Team Must Play Play Anctive Role in Any and All Negotiations with Them. In fact, it should be involved from the earliest stages, stepping in during the process process and championing the security message.
Without that involvement, the risk is that an inharently insecure piece of corporate software gets purchaised and installed, later resulting in a whole stack of problems for it Updates, Planty 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 an executive team to make a software procurement decision based on what other organisations are doing, what product is considered to be 'market-tur', an existing Relationship between the Organization and a Particular Supplier, or Numerous Other Considerations – but all to the exclusion of what's actually the best for the organisation's environment and its own.
In reality, the ciso and their team are accountable for making sure that every Piece of Technology Bright Into The Organization Aligns with its Risk Posture and Its Well -EFINED SECURITY CONTOROLS. In short, they have to determine white 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 formalized 'Blind' Request for proposal (Rfp) Process can pay dividends, ensuring that software process decisions are not swayed by brand reputation or marketing clout. From there, the it security team should be activated in proof of concepts (pocs) that involve trying out elements of the new software with 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 College from Elsewhere in the business in a robust conversation about rain. It's rarely (if ever) a case of the it security team attempting to veto a purchase. It's more about them helping the organization to understand how to mitigate identified risks – or account them, if the organization turns out to be comfortable with that. Above all, it's about understanding risk -pette with the organization and how that plays out within the context of what of what the business is trying to achieve.
Buyer beware
But Above All, The It Security Team Should Be Part of A Wider Organisational Efficient to Expect more from Suppliers – Our own Effort to insist on 'Secure by Design', with the Microcosm of AnDIVIDAL 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 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-indigestion that software complexies fail to carry out Design products. If customers didn Bollywood that work to do, then Bottom-Line Financial targets.
For the Auto Industry, The First Priority Had to be a Safer, More Accident-Preof Automobile. For us, it must be Safer, More Breach-Prooof Software.