HP J2383B HP Jetdirect Print Servers - Philosophy of Security - Page 5

First Cause and Trust Anchors

Page 5 highlights

Domain: EXAMPLE Email: [email protected] 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 5

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

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