8
just saying “We use SSL” as our Security Developer did is not enough of an answer to really explain
anything, much less justify the security claim being made. With our view of security as a holistic
enterprise, we can see the people questions – “who configures what settings, where does this
configuration take place, when does this configuration need to be done, how is this configuration
performed, and what knowledge do I need to give them in order for them to be successful at the tasks
they are assigned to do” are very important security questions to answer in our example (Note: this
doesn’t mean that cryptography is unimportant)
We found our trust anchors using a methodology known as reductionism. We needed to eliminate
some variables and focus in on the things that need to be established that our security protocol for
device management has to rely on. However, reductionism can be tricky – there are good forms and
bad forms.
Greedy Reductionism
If you’ve made it this far, you’ve hopefully realized that Security, in its general form, is best analyzed
as a holistic enterprise – basically a complex system worth more than the sum of the parts. However,
when a certain part of security must be analyzed, some sort of elimination of variables and focusing
in on relevant but simpler aspects of a complex security system is required – this would be following a
methodology which we will call reductionism. Reductionism is extremely useful for developing
explanations and predictions for complicated systems. For us, we are using reductionism as a
technique by focusing on a specific relative part of a system that is of interest to us.
As an example, let’s look at the things that someone needs to do to keep their automobile in good
shape. They could spend all their energy learning everything about that automobile – essentially all
the knowledge that the team of engineers that designed it had and then develop a service plan. An
alternative is to make the assumption that things that break down are usually the moving parts.
Instead of studying the entire automobile, we can now simply study the moving parts and develop a
service plan around that. This would be an example of using reductionism as a technique to help
simplify problems (of course, they could simply read their owner’s manual maintenance schedule as
well).
However, reductionism can be misused and when it is misused, we will call it greedy reductionism,
using a term from a famous philosopher (Dennett). Here is where simplifying things too much results
in a type of category mistake. For instance, in the previous example, saying an automobile is “just the
sum of its moving parts” would be an example of Greedy Reductionism.
Sometimes security products are marketed with Greedy Reductionism in mind. For example, let’s
assume that a company marketed an encrypted hard disk for a printer or mulit-function device (MFP).
The marketing department for the encrypted hard disk claims that buying this product results in
“peace of mind” for your printed and imaged documents because no one will be able to recover your
documents using forensics. Unfortunately, this marketing strategy is using greedy reductionism. Let’s
look at an actual path of a confidential document stored on an intranet web server:
•
A user brings up a confidential document from an internal web server. This user has a
meeting and would like everyone to have a printed copy, so the user prints multiple copies.
The internal web server obviously has a copy of the document on its hard rive and any
backup tapes or DVDs.
•
Unless the web browser was using some form of transmission security (e.g., IPsec, HTTPS,
etc…), the document probably went over the company’s local network in the ‘clear’ and
could be captured. Even if a secure transmission was used, if the trust anchors were not
setup correctly, then other attacks can be used to read the document without the knowledge
of the server or client.
