Countermeasures for Security

• Design principles for security
  • Least Privilege: users and programs only have access to what they need.
  • Economy of mechanism: The design of protection systems should be small, simple and straightforward so it can be easily analyzed, tested and verified.
  • Open Design: Do not depend on obscurity or ignorance. Open to public inspection to validate, find and fix flaws, and ensure trust.
  • Complete mediation: Everything must go through the security system.
  • Permission based: with a default of deny.
  • Separation of privilege: access should depend on multiple conditions (password, authentication key)
  • Ease of use.
• Top ten secure coding practices
  • Validate input
  • Heed compiler warnings
  • Design for security policies
  • Keep it simple.
  • Default to deny
  • Adhere to the principal of least privilege
  • Sanitize data sent to other systems.
  • Practice defense in depth
  • Use effective quality assurance techniques.
  • Adopt a secure coding standard.
• An organization called SAFECode has developed a set of Standards for Secure Software Development.
• Penetration Testing
  • A team of experts attempts to break into a system.
  • Tiger Team or White Hat testers.
  • Ethical hacking.
  • An organized, methodical approach.
  • Requires both knowledge and creativity.
  • Again, this can only show the flaws discovered.
  • It can not assure that the system is secure.
  • The authors seem to indicate that Management probably overestimates the effectiveness of this process.
  • This is just part of the security toolkit, not the entire solution.
• Validation
  • Makes sure that the developer is building the right product.
  • They list a set of ways to validate programs
    • Requirement Checking: Demonstrate that the program meets the requirements as specified.
      • Make sure it does what it is required to do.
      • But possibly also make sure it does not do things it should not do.
    • Design and code reviews
      • Attempt to address system correctness.
      • Trace from requirements to implementation.
    • System Testing
      • Probably involving an independent test team.
• Defensive programming
  • Write code that is not only correct, but anticipates what could go wrong.
    • What happens if I get the wrong data for the type?
    • What if the value is out of range?
    • Check for unreasonable values (4kg of salt in a recipe)
    • Values out of scale (4 bedroom house 30 bathrooms)
    • Incorrect parameters (value, count, order, ...)