Steve Lamb's Blog

Security Matters

Blogs

How to think like a hacker - Scott Culp's 10 Immutable Laws of Security

  • Comments 3
  • Likes

Back in the year 2000 Scott Culp published a paper outlining the 10 Immutable Laws of Security. I've restated them here to be concise but strongly encourage you to read the original article as it develops each law to discuss each in turn.

If you're new to information security and would like to put everything in context then Scott's paper will help. In addition remember that information security is all about risk measurement, mitigation together with policy, process and people - security policy must support the requirements of the business whilst mitigating the risks to a level that the company are comfortable with.

Policy and processes must be constantly reviewed and updated to ensure compliance with the requirements and operation of the business. People outside the security team must be involved with and buy into the security of information otherwise they are likely to take shortcuts.

Security Policy must be realistic - users can be encouraged to comply with reasonable security policy and associated guidelines - if they think "the policy's stupid" then they are far less likely to follow it. Security policies must "have teeth" to make it clear to users that failure to comply will result in consequences.

Here are the 10 Immutable Laws of Security:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore
Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more
Law #5: Weak passwords trump strong security Law #5: Weak passwords trump strong security
Law #6: A computer is only as secure as the administrator is trustworthy Law #6: A computer is only as secure as the administrator is trustworthy
Law #7: Encrypted data is only as secure as the decryption key Law #7: Encrypted data is only as secure as the decryption key
Law #8: An out of date virus scanner is only marginally better than no virus scanner at all Law #8: An out of date virus scanner is only marginally better than no virus scanner at all
Law #9: Absolute anonymity isn't practical, in real life or on the Web Law #9: Absolute anonymity isn't practical, in real life or on the Web
Law #10: Technology is not a panacea Law #10: Technology is not a panacea

Comments
  • Actually, Law #1 doesn't have to be that way.

    The reason why that law exists is the security model that is used in Unix and Windows: principals and access controls.
    If each program only got the minimum authority that it needed, it could not do much damage. Also, if you manage to create protected components within a program and each component only gets the authority it needs, you can further improve the granularity level of security.

    This cannot be done with ACLs, because it becomes un-manageable.
    Another security model: capability-based security, merges the security aspect into the design. It is authority-driven design.

    I can send you the draft of a paper I'm writing, that summarizes this approach.
    More info at http://erights.org (E language).

  • The Administrator Accounts Security Planning Guide has recently been posted to TechNet and hence...

  • PingBack from http://thebestbrew.wordpress.com/2008/10/10/risk-risk-riskdo-i-sound-like-steve-lamb-yet/