The real costs of being reactive – and a way forward

By Jeff Spielberg | August 21, 2019

My team talks a lot about “proactive security” – the concept of baking cybersecurity measures into architecture and design as opposed to responding to vulnerabilities and breaches when they occur. However, I lacked a quantitative answer when recently asked: “how do you convince businesses to start being proactive?”

While instinctively we think it is cheaper and more responsible to build security into systems from the start, this is still often not the norm, especially in the internet-of-things (IoT) and embedded world that I live in. While we can continue to try to make arguments based on threats and risks, this may not be enough to convince firms to take systematically different approaches to product development and security.

To start quantifying this, I looked at several aspects of this debate to account for financial and R&D considerations:

  1. Security Services Spend: Using or team’s data as a security services firm working on IoT secure design and vulnerability response, the cost of responding to a single public vulnerability is almost always more than the ground-up secure design of a new IoT system. Note that this does not even count the time and costs of internal personnel, leading to the next issue.

  2. Context Shifting Costs: The costs of context shifting for engineering and product development teams is well documented – shifting between tasks can cost as much as 40 percent of someone’s productive time1 . The “fire drills” created when a vulnerability is exposed can significantly impact a team’s focus and ability to accomplish their goals and ship products.

  3. Rearchitecture Costs: When vulnerabilities are identified in existing products, they cannot always be easily patched. Fixing IoT vulnerabilities may require firmware updates for numerous remotely deployed devices, but firmware updates are often not simple. For example, some devices lack the ability to perform field updates, making vulnerabilities essentially impossible to remediate at scale. We have also seen remediations hit power or memory limits in devices, requiring hardware-level changes to fix them. Because of these issues, the cost of remediation may rival those of introducing an entirely new product.

  4. Regulatory Risk: In addition to direct security spend, vulnerability response can incur legal fees and regulatory risk. Vulnerabilities are increasingly attracting the attention of the FTC, FDA, and others. For example, the FTC has pursued cases against firms ranging from Twitter to HTC2,3, requiring them to improve their cybersecurity practices. Handling regulatory matters in addition to technical, customer service, and PR issues creates additional costs and risks when vulnerabilities are identified.

Lastly, while we can’t measure it, we have found it very enjoyable to work with firms on secure architecture and design. It creates a better dynamic between security professionals and the rest of the technology development community, while building knowledge and skills on both sides.

While it seems obvious that firms should be prioritizing security in the design of their new products, we still have a long way to go to make this a universal practice. We have worked with several firms battling their way through public vulnerability disclosures and have helped them come out the other side building new secure products in a market-leading fashion. It’s possible, it’s doable, and it’s the responsible, necessary way to develop products today.

  1. “Multitasking: Switching Costs.” American Psychological Association, 20 Mar. 2006, [return]
  2. “Twitter Settles Charges That It Failed to Protect Consumers’ Personal Information; Company Will Establish Independently Audited Information Security Program.” Federal Trade Commission, 24 June 2010, [return]
  3. “HTC America Settles FTC Charges It Failed to Secure Millions of Mobile Devices Shipped to Consumers.” Federal Trade Commission, 22 Feb. 2013, [return]