For some obscure reason, this morning I ploughed through the rather excellent but rather deep tome of Peter Gutmann's Cryptographic Security Architecture - Design and Verification (or at least an older version of chapter 2, taken from his thesis).
He starts out by saying:
Security-related functions which handle sensitive data pervade the architecture, which implies that security needs to be considered in every aspect of the design, and must be designed in from the start (it’s very difficult to bolt on security afterwards).
And then spends much of the chapter showing why it is very difficult to design it in from the start.
When, then, to design security in at the beginning and when to bolt it on afterwards? In my Hypotheses and in the GP essays I suggest it is impractical to design the security in up-front.
But there still seems to be a space where you do exactly that: design the security in up-front. If Peter G can write a book about it, if security consultants take it as unquestionable mantra, and if I have done it myself, then we need to bring these warring viewpoints closer to defined borders, if not actual peace.
Musing on this, it occurs to me that we design security up front when the mission is security . And, not, if not. What this means is open to question, but we can tease out some clues.
A mission is that which when you have achieved it, you have succeeded, and if you have not, you have failed. It sounds fairly simple when put in those terms, and perhaps an example from today's world of complicated product will help.
For example a car. Marketing demands back-seat DVD players, online Internet, hands-free phones, integrated interior decorative speakers, two-tone metallised paint and go-faster tail trim. This is really easy to do, unless you are trying to build a compact metal box that also has to get 4 passengers from A to B. That is, the mission is transporting the passengers, not their entertainment or social values.
This hypothesis would have it that we simply have to divide the world's applications into those where security is the mission, and those where some other mission pertains.
E.g., with payment systems, we can safely assume that security is the mission. A payment system without security is an accounting system, not a payment system. Similar logic with an Internet server control tool.
With a wireless TCP/IP device, we cannot be so dismissive; an 802.11 wireless internet interface is still good for something if there is no security in it at all. A wireless net without security is still a wireless net. Similar logic with a VoIP product.
(For example, our favourite crypto tools, SSH and Skype, fall on opposing sides of the border. Or see the BSD's choice.)
So this speaks to requirements; a hypothesis might be that in the phase of requirements, first establish your mission. If your mission speaks to security, first, then design security up front. If your mission speaks to other things, then bolt on the security afterwards.
Is it that simple?
Posted by iang at May 21, 2007 07:01 AM | TrackBackA thought that was lingering: Maybe it is simply a case of "premature optimisation is the root of all evil?"
Posted by: Iang at May 21, 2007 09:58 AMI was thinking a more modern software engineering mantra is something like "premature design is evil/bad/impratical" (cf. XP, Agile, etcetera).
Is "it is impractical to design the security in up-front" different from, say, "it is impractical to design software up-front"?
Posted by: fluortanten at May 21, 2007 10:27 AMAh, games with words :)
It all depends on what "it" is. If "it" is software, then one is generally advised to design it up-front, although as you suggest there is a case for design-by-discovery.
Primarily, we design according to requirements, and if we have the requirements nailed down, then the question is whether we also include the security in that design, as well as the 3-way-tilt and vibrating leather seats, the dominos hanging from the rear-vision mirror and the extra fat tailpipes. The requirements will tell us.
Once we have assumed security as part of or all of the mission, then security is part of the "it". So design it up front.
Posted by: Iang at May 21, 2007 11:01 AMHi,
> Is it that simple?
I think there are several reasons that will lead to security integrated into the design.
One of the questions is, whether it is a new application (with a new market), a new innovation, or not. New applications and new markets are likely better served with a prototype lacking much security, established markets will likely need more security. E.g. a Hypertext viewer 20 years ago, didn´t and couldn´t care much about security. For a modern browser nowadays it´s essential to have security in-built, and even then it´s a tough job.
I am not sure about the other questions yet, but I believe there are a few more.
Best regards,
Philipp Gühring
Hi,
> Is it that simple?
I found another question: Standardisation.
If you create a Standard, you shouldn´t retro-fit security into it. (See WLAN/WEP/WPA)
Best regards,
Philipp GÜhring