Secure systems and the three little pigs

Everyone knows the story of the three little pigs. Pigs #1 and #2 built houses of straw and wood; the wolf was able to blow their houses down, and presumably have them for a nice barbecue lunch. Pig #3 built his house out of brick and survived the wolf’s attack. In fact, the wolf fell down the chimney and was lunch himself. 

Pig #3 built security into his house, whereas the others did not. This story provides a nice feeling for security professionals. We start with a good foundation and add walls and roof. Then we are safe. We are clearly as smart as pig #3. We will build security into our system and survive attack. Our program managers and developers will be satisfied.

Yes, “building security in” has long been a goal for secure software systems. The question is: is this concept still relevant? This post argues that it is obsolete. Since innovation built on software is cutting across all industries, it is important to get this right. 

In security, the idea has been to build security in, as opposed to bolting it on. The FTC tells us to do the same thing with privacy. Since I have recently had the opportunity to research federal practices in this area, I will cite some of those references.

A good site for historical information is Build Security In, an official website of DHS. This is a collection of best practice articles on the topic; most are from 2013, some go back to 2005. Another reference is NIST SP 800-64, Rev 2 (2008): “Security Considerations in the Systems Development Lifecycle”. This document talks about “building security into their IT development processes” and “build in security”.  SP 800-64 is especially aligned with the linear waterfall development process. The most recent NIST publication on systems security is SP 800-160 (2016): “Systems Security Engineering”. This document takes a different approach and describes security as an emergent property of a system, meaning that “system security results from many things coming together to produce a state or condition [of security]”. 

For example, I consider the buoyancy of a modern military ship to be an emergent property of the ship. All of the components individually will sink. Put together the right way, operated the right way, maintained the right way and defended the right way, it floats. SP 800-160 says that you need to orchestrate a number of security processes correctly to build secure systems. Figure 4 in 800-160 outlines these 30 processes.  You should review these to see if you are including them in your development life cycle.

Pig #3 unfortunately did not take this approach. A group of wolves surrounded his house (wolves hunt in packs). Lacking an alarm system, pig #3 was not able to summon help. Then one of the wolves, in sheep’s clothing, knocked on the front door, looking for a charitable donation. Pig #3 became lunch as well.

Systems development teams face the same problems today. Threats are not “built-in” to initial risk analyses, they are constantly changing. If a new open source vulnerability shows up in your production code, how fast can you react? With sprints producing new releases every two weeks, and DevOps teams deploying them into production, you can’t expect developers alone to build in security. They will need a whole ecosystem supporting that goal. 

It’s time to start seeing your secure development processes as an interconnected system…or you may become lunch, too.

Add your comments to our Facebook page if your house is secure that is.