In Part I of this post I discussed generic design principles that apply directly to information security, viz. modularity and flexibility. I discussed the six operators on modularity identified by Baldwin & Clark and in this post I will examine examples of each of these operators from engineering secure systems . To review the operators were as follows:
- splitting
- substituting
- augmenting
- excluding
- inverting
- porting
The first thing that is typically done during redesign with a monolithic interdependent system is to split the modules. Take for example a symmetric cryptographic system which produces a single key for encryption and decryption. The symmetry can be broken by splitting the functions such that I have one key for encryption and one for decryption (public key, private key). Although it wouldn’t make sense in this example, once we have split the function, development can continue in parallel with each new module following a separate evolutionary path.
The next operator, substituting, is complementary with splitting. With substituting we replace an existing module with one that is “better” in some way whether lower cost, higher performance, for example having previously broken the symmetry of our encryption we are now able to optimize the encryption and decryption functions so long as they don’t lose their essential mathematical relatedness. Following this innovation we replace the existing functions. The operation of substitution normally occurs over the useful life of the system.
Further into the lifecycle the augmentation operator is used. This is where a new module is added to an existing system. For example, If only one person has the launch authentication code for a nuclear weapon and that person is eliminated, the country loses the ability to respond to a first strike. Therefore a new module is added, a backup system, where the authentication code is a shared secret among several parties who when they put their part of the secret together, can derive the authentication code.
The exclusion operator is the removal of a module. We take something away to make it more secure and possibly lower cost. A common example would be the removal of the application programming interface (API) prior to deploying an application to reduce the attack surface, or the removal of unused network protocols when hardening a system.
The fifth operator is inversion. This typically happens later into the life cycle after many design iterations. An example of inversion would be an identity management system where prior to its deployment each application managed its own identities. Now there exists a single system which centralizes the function and eliminates redundancy.
Porting is the operator that people are most familiar with and there are numerous examples. A common port is moving a security monitoring system, for example, a host based intrusion detection system from one operating system to another. Porting occurs normally following the design being proven on one particular platform whether that proof occurred via testing or was proven in the market.
Those are the six modular operators with examples. In the next post I will address things that can go wrong when using them.
May 1, 2009 at 4:50 am
[...] by gdippold on 1 May 2009 The second part of my series on security architecure and design is up a Risk Intelligence. In this post I look at [...]