Form Follows Function on SPaMCast 426

SPaMCAST logo

One of the benefits of being a regular on Tom Cagley’s Software Process and Measurement (SPaMCast) podcast is getting to take part in the year-end round table (episode 426). Jeremy Berriault, Steve Tendon, Jon M. Quigley and I joined Tom for a discussion of:

  1. Whether software quality would be a focus of IT in 2017
  2. Whether Agile is over, at least as far as Agile as a principle-driven movement
  3. Whether security will be more important than quality and productivity in the year ahead

It was a great discussion and, as Tom noted, a great way to finish off the tenth year of the SPAMCast and kickoff year eleven.

You can find all my SPaMCast episodes using under the SPAMCast Appearances category on this blog. Enjoy!

Apple vs. the FBI: Winning and Losing

Drawing of an Apple with a Worm

The FBI, with the help of a third party, has managed to gain access to Syed Farook’s iPhone. In a court filing Monday, the FBI stated that they did not require Apple’s help any longer.

Apple, on the other hand, now has a need to know what vulnerability was exploited to access the phone. Whether the FBI will provide that information is questionable. From a purely legal standpoint, it seems there is no obligation for it to disclose that to Apple:

Attorneys for Apple are researching legal tactics to compel the government to turn over the specifics, but the company had no update on its progress Tuesday.

The FBI could argue that the most crucial information is part of a nondisclosure agreement, solely in the hands of the outside party that assisted the agency, or cannot be released until the investigation is complete.

Many experts agree that the government faces no obvious legal obligation to provide information to Apple. But authorities, like professional security researchers, have recognized that a world in which computers are crucial in commerce and communications shouldn’t be riddled with technical security flaws.

So, had Apple decided not to fight the FBI’s writ, it would likely have full control (IP ownership and physical custody) over a handset-specific version of IOS that only bypassed the feature limiting access attempts and was only provided pursuant to a legal writ. Now, the FBI has access (through a third party) to what’s reputed to be the same capability, but Apple does not. It appears that there may be no way to compel the FBI to share that information with Apple.

So the question is: did Apple win or lose in this case? More importantly, did Apple’s customers win or lose?

Law of Unintended Consequences – Security Edition

Bank Vault

More isn’t always better. When it comes to security, more can even be worse.

As the use of encryption has increased, management of encryption keys has emerged as a pain point for many organizations. The amount of encrypted data passing through corporate firewalls, which has doubled over the last year, poses a severe challenge to security professionals responsible for protecting corporate data. The mechanism that’s intended to protect information in transit does so regardless of whether the transmission is legitimate or not.

Greater complexity, which means greater inconvenience, can lead to decreased security. Usability increases security by increasing compliance. Alarm fatigue means that as the number of warnings increase, so does the likelihood of their being ignored

Like any design issue, security should be approached from a systems thinking viewpoint (at least in my opinion). Rather than a one-dimensional, naive approach, a holistic one that recognizes and deals with the interrelationships is more likely to get it right. Thinking solely in terms of actions while ignoring the reactions that result from them hampers effective decision-making.

To be effective, security should be comprehensive, coordinated, collaborative, and contextual.

Comprehensive security is security that involves the entire range of security concerns: application, network, platform (OS, etc.), and physical. Strength in one or more of these areas means little if only one of the others is fatally compromised. Coordination of the efforts of those responsible for these aspects is essential to ensure that the various security enhance rather than hinder security. This coordination is better achieved via a collaborative process that reconciles the costs and benefits systemically than a prescriptive one imposed without regard to those factors. Lastly, practices should be tailored to the context of the problem at hand. Value at risk and amount of exposure are two factors that should help determine the effort expended. Putting a bank vault door on the garden shed not only wastes money, but also hinders security by taking those resources away from an area of greater need.

As with most quality of service concerns, security is not a binary toggle but a continuum. Matching the response to the need is a good way to stay on the right side of the law of unintended consequences.

“Design? Security and Privacy? YAGNI” on Iasa Global

Two of my favorite “bumper sticker philosophies” (i.e. short, pithy, and incredibly simplistic sayings) are “the simplest thing that could possibly work” and YAGNI. Avoiding unnecessary complexity and unneeded features are good ideas at first glance. The problem is determining what is unnecessary and unneeded. Just meeting the functional requirements is unlikely to be sufficient.

Read “Design? Security and Privacy? YAGNI” on the Iasa Global site for a post about how it’s important to have someone responsible for Quality of Service requirements in general and security in particular.