Enterprise Software Security: Design Activities

The Design Review

Today is the first meeting of the newly minted Product Security Team (PST) for the ongoing development of version 2.0 of Peabody’s Wandering Medic (WM) app. The first step is to decide on some of the basics and what things can reasonably be done, despite the fact that the development team is already well into the implementation of WM 2.0.

It is agreed that a lightweight design review would be the first course of action. The team would use this opportunity to get to know each other, as well as for everyone to thoroughly “get their heads around” the WM 2.0 design itself. After all, the Peabody team had, to date, only seen the WM apps from the outside, and this is their first deep dive into how the system will work.

So the Peabody CTO starts the process by asking the dev team, apparently without a hint of irony, to produce whatever design documentation they currently have. The dev team nervously grins and proclaims their design to be their source code. The code is modular; it is laid out logically; any first-year computer science graduate should be able to look at the code and intuitively understand the flow of operation. The CTO is less than convinced, and he insists on whiteboarding a top-level design flow of the app and all of its components, including both the mobile client components and the server-side components. The dev team is quite frustrated, but because they really want to see the new merger succeed, they agree.

It takes the dev team and CTO staff a good solid four hours of discussions and whiteboard sketching to put together their visualization of the WM 2.0 design. The whiteboard, although quite cluttered and ugly, now contains the first design view of WM 2.0 (see Figure 3.2). It has been a frustrating process, but not without value.

Figure 3.2 The architecture of the Wandering Medic portal.

Most of the frustrations have been because the dev team had differing opinions about how some components of the system would work in the final 2.0 product. The discussions have been lively and heated, but the good news is that the dev team itself has been able to solidify their own understanding of the system they’re building. In fact, they even reluctantly agree that the mere process of writing their design—such as it is—on the whiteboard has helped them. They stop short of saying that the four hours in the conference room were better than four hours of coding, though.

Still, drawing the design is only the first step in the design review. The team takes a break until morning, when they’ll do a quick design review using a threat modeling approach.

Freshly rested, our PST returns to the conference room to start the second phase of their process, the threat model.

With the design drafted, the CTO suggests dividing it into security zones as a starting point. The functional zones are easy: mobile zone, middleware/controller zone, database zone, authenticator zone. As a starting point, these delineations help the team consider them one at a time.

The first step is now to consider all the threat agents (people, mostly) who have access—legitimate and otherwise—across each zone. To get things rolling, the CTO suggests starting with the mobile zone. Then they will brainstorm all the threat agents they can come up with and then consider each in light of the following details. They must be sure to clearly set the rules for the brainstorming session in advance.

• Doctors

  Clearly, the primary users of the app are the doctors. They have legitimate access to the devices and the app itself. What could motivate a doctor to attack the system? (1) Financial gain—a doctor might look through patient records to brainstorm “legitimate” medical procedures the patient should receive. Far-fetched, but this is a brainstorming exercise.… (2) Privacy violation—a doctor might want to read the records of a VIP patient, out of curiosity, or to give/sell the info. (3) Competition—a doctor might want to read another doctor’s patient information to find out how the other doctor is treating a specific ailment. (4) Coverup—a doctor could attempt to remove or alter information to cover up mistakes. The team continues this brainstorming to come up with as many things as they can that could motivate a doctor to attack.

  Now, for each of these potential attacks, the team considers how (technologically) skilled the doctor would need to be in order to be able to succeed.

• Nurses

  Although the primary app users are the doctors, without a doubt nurses will also need to use the app. However, they might well have different motivations for (potentially similar) attacks. (1) Embarrassment—a nurse might enter false data to make a doctor look bad. (The team considers that attack case to be more likely than the other way around.) (2) Many of the same attack cases the team identified for doctors also exist for nurses.

• IT technicians

  Certainly, the hospital’s own IT staff would have to have access to each mobile device. While discussing this, the team briefly considers the case of “BYOD” (bring your own device) situations. The debate on this topic gets quite heated, with the developers primarily saying that they absolutely want to support BYOD situations. In the end, however, the Peabody CTO prevails and says that a medical enterprise environment will never allow patient data on a BYOD device, so they dismiss that case. Secretly, the CTO hopes that decision doesn’t come back to haunt them later.… So what would motivate the hospital’s own technicians to attack a system? (1) Sabotage—the techs are disgruntled because of continued budget cutbacks, and they want to teach the big hospital conglomerate a lesson. (2) Sabotage—the techs might want to build a Trojan horse into the app deployment so that the app fails if/when a technician is laid off. (3) Financial gain—the techs know about VIP patients in the hospital, and they could use access to the app to look up private details and then sell that information externally. (4) And again, this list continues.

  The skills required to do an attack, however, are far more prevalent in our IT technicians than in the doctors and nurses.

• Patients

  From time to time, it is quite conceivable that a patient will have access to a doctor or nurse’s mobile device. In those situations, what might motivate a patient to attack the app? (1) Alter records—a patient might change his own record to show more/less severe ailments. Perhaps this is financially motivated, to attempt to be charged less for a medical service. (2) Drugs—a patient could try to use a device to add or alter prescriptions, for various reasons. (3) Privacy violation—a patient might attempt to look up someone else’s medical records.

  Of course, patients’ technology skills will span a broad spectrum, so it’s best to assume that the patient is very technically astute.

• Doctors’ families

  Unless the hospital has a policy of not allowing staff to take mobile devices home, the team has to consider what the families could do. Here it might be a good idea to consider some actual attack cases as well as inadvertent attack cases. (1) Games—perhaps it’s cliche[as], but it still bears consideration. What happens if/when a doctor’s family members try to install games (or other nonsanctioned apps) on a hospital-owned mobile device?

Table 3.2 provides the final summary of potential threat agents that the PST team has come up with after an exhausting deliberation, as well as their potential motivations and expected technical skill levels.

Table 3.2 Threat Agents

Next, keeping its scope to the mobile zone, the team considers all the following factors. When carrying out this step, the team continues its brainstorming approach. One technique to facilitate this is to use a large whiteboard and construct a matrix (see Table 3.3) with each of the following column headings:

• Target

  Here, the team considers all the targets within the mobile zone. The targets can be technical, data, or process based. For this app, the team considers its primary targets to be patient data (including PII, prescriptions, diagnoses, etc.), medical staff accounts, and encryption keys from back-end applications.

• Vulnerability

  To consider all the weakness states of these targets, the team must deeply understand the app and how it functions. In particular, they need to consider all the circumstances where the target data is stored on a mobile device, whether in nonvolatile storage, in volatile storage, or in transit to/from the device.

• Attack

  To brainstorm the potential attacks, we need to deeply understand the application’s architecture—and force some vital decisions—and understand how things will be implemented. For the team’s first shot at doing a threat model, they agree to hold off on several of the technology decisions and then revisit them later. For example, one attack they consider is to gain access to any local data stores via their SQLite (or whatever database the implementation team uses) files, which can be trivially done on iOS or Android versions of their app. They also consider carefully whether the access is read-only or read/write.

  In fact, many of the issues the team will consider at this point will slowly be updated as the development process continues.

• Impact

  There are two types of impacts any vulnerability will have: technical and business. Whereas the development team understandably concentrates on the technical side of this activity, business stakeholders become worried about business impact, so they very strongly push the team to include business considerations in the impact analysis.

• Remediation

  This is where the technical world really clashes with the business reality. If the vulnerability remediation requires completely rearchitecturing the solution, management gets quite impatient. This is where the impact analysis is really utilized, because the team and business folks will have to evaluate the risks of additional costs and delays incurred while fixing security issues versus not doing it and potentially being hit with breaches, data losses, and similar niceties. None of which Peabody wants to happen, of course—and neither does its CTO want to reimplement the portal.

Table 3.3 Matrix