Principles for Secure Design and Software Security
0 likes88 views
The document summarizes key principles for secure software design and development: 1. It outlines core principles like confidentiality, integrity and availability as pillars of information security. 2. It then discusses principles from the book "Writing Secure Code" such as minimizing the attack surface, establishing secure defaults, least privilege, defense in depth, and failing securely. 3. Additional principles discussed include separation of duties, avoiding security through obscurity, keeping security simple, and correctly fixing security issues.
Principles for Secure Design and Software Security
- 2. Secure Design The core pillars of information security: Confidentiality – only allow access to data for which the user is permitted Integrity – ensure data is not tampered or altered by unauthorized users Availability – ensure systems and data are available to authorized users when they need it
- 3. Security Principles The security principles outlined in Michael Howard and David LeBlanc’s book Writing Secure Code • Minimize attack surface area • Establish secure defaults • The principle of least privileges • The principle of defence in depth • Fail securely • Don’t trust services • Separation of duties • Avoid security by obscurity • Keep security simple • Fix security issue correctly
- 4. Minimize attack surface area Every time a programmer adds a feature to their application, they are increasing the risk of a security vulnerability. The principle of minimizing attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities. Example: The developer could limit access to the search function, so only registered users could use it — reducing the attack surface and the risk of a successful attack.
- 5. Establish secure defaults This principle states that the application must be secure by default. That means a new user must take steps to obtain higher privileges and remove additional security measures (if allowed). Establishing safe defaults means there should be strong security rules for how user registrations are handled, how often passwords must be updated, how complex passwords should be and so on. Application users may be able to turn off some of these features, but they should be set to a high-security level by default.
- 6. The principle of Least privilege The Principle of Least Privilege (POLP) states that a user should have the minimum set of privileges required to perform a specific task. The POLP can be applied to all aspects of a web application, including user rights and resource access. For example, a user who is signed up to a blog application as an “author” should not have administrative privileges that allow them to add or remove users. They should only be allowed to post articles to the application.
- 7. The Principle of Defence in depth The principle of defence in depth states that multiple security controls that approach risks in different ways is the best option for securing an application. So, instead of having one security control for user access, you would have multiple layers of validation, additional security auditing tools, and logging tools. For example, instead of letting a user login with just a username and password, you would use an IP check, a Captcha system, logging of their login attempts, brute force detection and so on.
- 8. Fail Securely There are many reasons why a web application would fail to process a transaction. Perhaps a database connection failed, or the data inputted from a user was incorrect. This principle states that applications should fail in a secure way. Failure should not give the user additional privileges, and it should not show the user sensitive information like database queries or logs.
- 9. Don’t trust services Many web applications use third-party services for accessing additional functionality or obtaining additional data. This principle states that you should never trust these services from a security perspective. That means the application should always check the validity of data that third-party services send and not give those services high-level permissions within the app
- 10. Separation of duties Separation of duties can be used to prevent individuals from acting fraudulently. For example, a user of an eCommerce website should not be promoted to also be an administrator as they will be able to alter orders and give themselves products. The reverse is also true — an administrator should not have the ability to do things that customers do, like order items from the front end of the website.
- 11. Avoid security by obscurity This OWASP principle states that security by obscurity should never be relied upon. If your application requires its administration URL to be hidden so it can remain secure, then it is not secure at all. There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code.
- 12. Keep security Simple Developers should avoid the use of very sophisticated architecture when developing security controls for their applications. Having mechanisms that are very complex can increase the risk of errors.
- 13. Fix security issues correctly If a security issue has been identified in an application, developers should determine the root cause of the problem. They should then repair it and test the repairs thoroughly. If the application uses design patterns, it is likely that the error may be present in multiple systems. Programmers should be careful to identify all affected systems.
- 14. Principles for Secure Design
- 15. Principles for a Secure design • Design security in from the start • Allow for future security enhancement • Minimize and isolate security controls • Employ least privilege • Structure the security relevant features • Make security friendly • Don’t depend on secrecy for security Morrie Gasser 1988
- 16. To Make Security Friendly • Security should not impact users who obey the rules • It should be easy for users to give access • It should be easy for users to restrict access • Established defaults should be reasonable
- 17. Principles for Software Security
- 18. Principles for Software security • Secure the weakest link • Practice defense in depth • Fail securely • Follow the principle of least privilege • Compartmentalize • Keep it simple • Promote privacy • Remember that hiding secrets is hard • Be reluctant to trust • Use your community resources Viega and McGraw 2001
- 19. Secure the Weakest Link • A software security system is only as strong as its weakest link • Attackers go after the easy targets • they will go after endpoints rather than trying to crack encryption • they will attempt to crack an application visible through the firewall rather than firewall itself • Identify and strengthen weak links until an acceptable level of risk is achieved
- 20. Practice Defense in depth • Use diverse defensive strategies • If one layer turns out to be inadequate, another layer will hopefully prevent a complete compromise • firewall to protect subnet, but sensitive information on the subnet is encrypted • DoD Eligible Receiver experience 1997
- 21. Fail Securely • If your software has to fail, make sure it does it securely
- 22. Follow the Principle of Least Privilege • Only the minimum amount of access necessary to perform an operation should be granted, and that access should be granted only for the minimum amount of time necessary
- 23. Compartmentalize • Basic access building block is not all or nothing • Minimize the amount of damage that can be done by breaking the system into units • Very few operating systems do this because it is difficult to manage • Root privilege is an example of how not to do it
- 24. Keep it Simple • Complex design is never easy to understand
- 25. Promote privacy • Try not to do anything that compromises the privacy of the user • Often trades off against usability • System should forget credit card numbers • Users hate having to type it in each time • Should extend to systems and code • No reason to give out any more information than necessary (e.g., OS name and version)
- 26. Remember that Hiding Secrets is Hard • Skilled youth can avoid any protection that a company tries to hardcode into their software (e.g., DVD viewers) • Binaries can be reverse engineered
- 27. Be Reluctant to Trust • Instead of making assumptions that need to hold true, you should be reluctant to extend trust • How can any COTS component be trusted to be secure? • Just because a particular security feature is an emerging standard doesn’t mean it actually makes sense • Sometimes it is prudent not to trust yourself
- 28. Use your Community Resources • Repeated use without failure promotes trust • Public scrutiny promotes trust