5
Domain:
EXAMPLE
Email:
Intranet Web Server
Login:
Example_User
Password:
WOW!I’mAnEntAdminForExample!!!
Domain:
EXAMPLE
Is this a misapplication of Ockham’s Razor?
Analysis: Here we have an interesting scenario. Based upon the research that Example User has
performed, one may be confused about whether Example User has done anything wrong. What
would happen if a “hacker” broke into the database of the Internet Book Store and came across the
email and password for Example User? Example User has revealed critical information to the
“hacker” (i.e., for those readers who are unaware, an Enterprise Administrator of an Active Directory
environment is an extremely powerful user with many privileges). If it took a month for the Internet
Book Store to realize their database had been compromised, the damage that could occur against the
EXAMPLE Company could be extensive. Compare that to the original way Example User had the
usernames/passwords configured – no company information is revealed should a “hacker” retrieve
this information – in other words, “all else is not equal”. In short, Example User needs to go back to
the first approach.
The first approach doesn’t solve the problem that Example User was running into though – too many
usernames/passwords to remember. How does Example User solve that? Well, first memorize the
Enterprise Administrator login and give it a strong username/password that doesn’t reveal anything.
Next, write down the usernames and passwords for Example User’s personal accounts (e.g., Internet
Book Store) and keep them with the same security that Example User provides to credit cards,
driver’s license, and other personal information – whether that is at work or at home. What? Write
them down? Isn’t that horrible security procedure? It depends. We are memorizing the critical
account (Enterprise Admin) and writing down the passwords for personal accounts that probably use
credit cards with fraud protection anyway. Simply protect them with the same care as your credit
cards and you should be fine. Alternatively, a file can be created with the passwords and then the file
would be encrypted with a pass-phrase. This procedure allows for the passwords to be managed and
stored on the computers where the user will be doing the work from.
As we continue to promote security as a holistic enterprise, we’ve seen some category mistakes that
people make and we’ve seen a person performing incorrect application of Ockham’s Razor. Another
thing that tends to undermine security as a holistic enterprise is the things that need to be done before
security can even begin – things we will call trust anchors.
First Cause and Trust Anchors
Trust anchors are those things that need to be setup before security can even begin. Many
companies promoting a specific security technology often do not talk about trust anchors because
they usually require separate out-of-band configuration – this tends to dirty up the ease-of-use
message. Another way of explaining trust anchors is through a philosophical concept called First
Cause.
Imagine a line of upright dominoes that is so long it would take many lifetimes to watch them fall
down from beginning to end. If you were born and lived during the middle of this process, you may
begin to wonder what caused the dominoes to start falling in the first place. Essentially, something
had to kick-start the process. This idea can be referred to as First Cause or the Unmoved Mover of
the very first domino. You can see a similar line of thought in modern science as the Big Bang
Theory.
Security has similar questions, but usually they are about trust. For instance, it is all very well and
good to talk about a security solution using SSL/TLS, Web Services, Signed XML Documents,
Kerberos Tickets, and so on. Ultimately, there is a point where the “rubber meets the road” so to
