Buggy software is insecure software

Digital health software is like a favela — great UX, layers of challenging complexity under the hood

Business Threat Modeling

What risks really count. Spoiler — its not human weakness and messaging.

Abstract

  1. Security assessment of complex software systems
  2. Quantitative evaluation and financial justification for security countermeasures
  3. Explicit communications between developers and security
  4. Sustain continuous risk reduction

The problem: Defective systems are insecure systems

This seemingly obvious observation is graphically borne out in a study that analyzed a sample of 167 customer data breaches in 2005.[1] Based on data provided by the Privacy Rights Clearinghouse,[2] the study classified each event according to attack method, attacker and vulnerability exploited.

Email security and human weakness is not the issue

Why don’t digital health organizations do more to improve their production software quality?

Let’s examine commitment to quality at three levels in an organization: end-users, development managers and top executives.

The need to understand operational risk of information security

Network and application security products are reactive means used to defend the organization rather than proactive means of understanding and reducing operational risk.

The objective: cost effective system defect reduction for digital health

It is rare to see systematic defect reduction projects in production software running in the enterprise, apparently, if it were easy, everyone would be doing it. So what makes it so hard?

  1. Use a risk analysis process that is suitable for production software systems. Collect data from all levels in the organization that touch the production system and classify defects for risk mitigation according to standard vulnerability and problem types.
  2. Provide executives with financial justification for defect reduction.
    Quantify the risk in terms of assets, software vulnerabilities, and the organization’s current threats.
  3. Require the development and IT security teams to start talking.
    Explicit communications between software developers and IT security can be facilitated by an online knowledge base and ticketing tool that provide an updated picture of well-known defects and security events.

Security assessment of complex software (Tenet #1)

There are no rules — anyone can play

The Business Threat Modeling process identifies, classifies and evaluates digital health software vulnerabilities in order to recommend cost-effective countermeasures. The process is iterative and its steps can run independently, enabling any step to feed changes into previous steps even after partial results have been attained.

The risk analysis loop — chaos is ok in the process

1. Set scope — stay focused and do less

The first step is to determine scope of work in terms of business units and assets. Focus on a particular digital health business unit and application functions will improve the ability to converge quickly. The process will also benefit from executive level sponsorship that will need to buy into implementation of the risk mitigation plan.

Set scope for your work — be focused

2. Identify business assets

In step 2, the team identifies operational business functions and their key assets:

Identify your business assets

3. Identify software components

After identifying business functions in Identify business assets, the team now identifies software components (but doesn’t assess vulnerabilities) using two sub-steps:

Break down your system into bite-size pieces

4. Classify the software vulnerabilities.

CVSS[6] scores are computed for each component identified in the Identify software components step. In addition to the CVSS score, we collect an additional field, the CLASP [7] problem type category, for example ”Use of hard-coded password”.

Quantify your vulnerabilities

5. Build the threat model

The team now populates the PTA (Practical Threat Analysis) threat model.

Build the threat model

6. Build the risk-mitigation plan

In step 6, the team specifies countermeasures for vulnerabilities found in the software components and records them in the PTA data model. While the best countermeasure for a problem is fixing it, in reality there may not be documentation and the programmers who wrote the code are probably in some other job. This means that other means may be required, such as code wrappers or application proxies.

Prioritize risk mitigation with money and depth of damage reduction

7. Validate findings — more eyeballs are better

This extremely important step validates the current findings with expert/relevant players in the digital health operation.

Quantitative evaluation and financial justification (Tenet #2)

The output of the process provides digital health executives with financial justification for an effective risk mitigation plan.

Customer case study — digital transformation of a legacy healthcare system

We analyzed a healthcare business unit with legacy IT systems for online order processing, make-to-order production and customer credit payment processing. Three key assets were identified: patient records, credit card details and internal price-lists. As can be seen in the below financial analysis, the risk to the assets can be reduced from 15% to 2% at a cost of $29,500 with seven selected countermeasures. Risk is reduced to a minimum by proactive defect-reduction at a cost of less than 3 percent of the asset value. The cost is an order of magnitude less than acquisition of a proprietary system for preventing leakage of credit cards and privacy information.

Risk summary in dollar terms

Explicit communications between developers and security (tenet #3)

The first order of business is having people talk to each other and argue the issues. By publishing CVSS scores and countermeasure costs, the developer and security teams can be confident that they can respond to a particular type of event in a consistent fashion.

Using Slack and Github for digital health risk management

You can use Slack and Github to support continuous enterprise risk analysis and management of your digital health system. Slack for the collaboration and Github to build a knowledge base and track open issues.

Sustaining CONTINUOUS risk reduction

Training a team that can sustain quality

While the Business Threat Modeling process itself has educational benefit for a digital health business, there is no question that the quantity and complexity of production systems in a large organization requires skills for continuous risk analysis and defect reduction.

Improving best practices in the software development life cycle

The risk analysts supporting the process, together with the knowledge base are a significant resource for any organization that wants to evaluate the economic feasibility of a defect reduction program and improve best practices in the software development life cycle:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Danny Lieberman

Danny Lieberman

I am a physicist by training, serious amateur musician and everyday biker. Working in cybersecurity and AI-driven monitoring of clinical trials.