The nature of systems security has definitely changed, as modern organizations optimize their own cocktails of third party and open source software, hosted services, and repurposed legacy applications.  This has put a new pressure on security teams to educate the teams that acquire or develop the software and services that are composed to create the end system.

A few years ago, while researching some new historical references to help people better understand their own responsibilities in a changing computing environment, I  came up with examples from other industries, where lessons can be learned.  They may not be about IT security, but the echoes are strong and the stories are interesting.

Lesson 1: Hidden Issues are Your Responsibility – The Paisley Snail

In one of the earliest and most heavily studied cases of liability and law, a maker of ginger beer is found to be liable when a customer at a restaurant becomes ill from a decomposing snail which tumbles, unwanted, from a bottle of soda that she has been drinking from (The incident happened in Paisley; the snail was actually, well, snail-colored).  At the time, the convention and prior art stated that the court should hold the restaurant owner responsible, as the bottle was actually sold to the customer by the restaurant.  In this landmark case, however, because the bottle was opaque (dark brown ), the court ruled that it was the responsibility of the bottler to ensure that the product was safe, as the bottlers were the only participants in the creation and sale of the ginger beer who could possibly have seen and eliminated this threat.

For today’s security leader, the lesson is clear.  If you are offering a service to customers, especially through business partners, you should take special care to keep your teams and your management committed to the responsibility you hold for securing that experience. In cases where the software or architectures are opaque to the customer or partner, it is even more important to mitigate issues, as it would be virtually impossible for the user to detect them and take measures to protect themselves.

Lesson 2: Built or Bought, You Own It – McPherson v. Buick

As in the case of the Paisley Snail, McPherson vs. Buick was a transformative legal story, in that it redefined responsibility for complex systems makers.  In this case, a gentleman was driving his 1909 Buick Runabout when the wheel collapsed and he was thrown from the car (Ironically, he was transporting a friend to the hospital at the time).  He sued the automaker, even though the actual cause of the accident was a rotted wooden wheel, manufactured by another firm and then installed during vehicle assembly.  In addressing this line of thinking, the courts ruled that while the wheel maker had clearly created a faulty product, it was the responsibility of the auto company to detect this flaw, since it was the auto maker that was in the best position to balance the use and danger of the product and to appropriately test all of the components.

As more and more systems are developed with contributions from multiple sources, security teams will do well to keep organizations on top of the requirements and enforcement techniques that will ensure that the various components come together in a way that keeps users protected.  The context and composability of software and systems makes required security characteristics of each element co-dependent, and so the ultimate arbiter of sufficient security has got to be the security team, comprehending and communicating the big picture.

Lesson 3: New Threats May Mean New Insights and Practices – The 1982 Tylenol Scare

In 1982, seven people died from potassium cyanide poisoning of Tylenol capsules near Chicago Illinois.  While the police and other investigators determined that the source of the poison was not in the manufacturing process, the Johnson and Johnson (the parent company of the Tylenol manufacturer, McNeil Consumer Healthcare) took very strong measures to mitigate the risk.  In addition to recalling approximately 31 million bottles of medicine, at a value of over $100M, the company transformed manufacturing across the market through the introduction of tamper-proof and tamper-resistant packaging.  These changes, made in response to the new threat of post-manufacture tampering, changed the retail packaging industry, making it safer for everyone.

In the same way, security leaders need to think outside of the common practices to address these new potential threats to their systems and assets.  Complex multi-phase and multi-platform attacks, which may attack several elements of a composed system, may well require a re-thinking of protection, identification, and interdiction techniques.  Recognizing the changing threat landscape and the exposed surfaces of systems can help inform the next generation of risk mitigation techniques.

Responsibility is the Key

While avoiding liability may be one of the drivers of better security, a much more positive take on it is the understanding and acceptance of responsibility.  As security leaders take responsibility for protecting systems and assets, it is a far simpler message to describe why an organization has the obligation to protect clients, than it is to describe the likelihood and impact of a specific attack.  By taking responsibility, and owning the processes that ensure security in our dealings with clients and partners, not only is the supply chain made stronger, but so are the relationships to which these chains bind us.

Until next time.