CIS 4615 meeting -*- Outline -*- * Guiding principles for software security Based on chapter 5 of the book by John Viega and Gary McGraw: Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley Professional, 2002. We've gone over several key attacks, but new ones keep coming up, partly because people know how to defend against the old ones. Q: How do we construct software so that it doesn't suffer from unknown vulnerabilities? We need some positive principles... ** principles based on risk management ------------------------------------------ PRINCIPLES FOR AVOIDING FUTURE PROBLEMS From "Building Secure Software: How to Avoid Security Problems the Right Way" by John Viega and Gary McGraw (Addison-Wesley, 2002), chapter 5. Overall idea: risk management 1. Secure the weakest link. 2. Practice defense in depth. 3. Fail securely. 4. Follow the principle of least privilege. 5. Compartmentalize. 6. Keep it simple. 7. Promote privacy. 8. Remember that hiding secrets is hard. 9. Be reluctant to trust. 10. Use your community resources. ------------------------------------------ We'll try to explain those... *** Secure the weakest link ------------------------------------------ 1. SECURE THE WEAKEST LINK A system is only as secure as its weakest component Assumes attackers will seek and attack it Examples: - cryptography - firewalls Lesson: - do a - address the - prioritize ------------------------------------------ Q: Which is robbed more often: a bank or a 7-11 store? Probably the 7-11 store, since it's got less security measures. ... is usually not the weakest link easier to attack data before encrypted or after it is decrypted ... are usually not attacked directly, usually attack apps visible through the firewall ... risk analysis ... most serious risk first ... according to risk ------------------------------------------ SOCIAL ENGINEERING Often a weak link for a system Example: technical support staff - reset passwords for callers How to fix this attack? - limit the capabilities of technical support staff to ------------------------------------------ technical support staff will want to help, don't want stress ... just refer customers to web page to verify their identity, or just send a reset link to their email. *** Practice defense in depth ------------------------------------------ 2. PRACTICE DEFENSE IN DEPTH Real-world Examples: - bank security (cameras, guards, vault) - prisons (cells, several walls, guards) - military fortresses (moat, walls, cannon, soldiers) Computer system examples: ------------------------------------------ Q: Have you ever visited St. Augustine's fort (Castillo de San Marcos)? It has an artificial slope leading up to a moat, walls, and the fort is shaped so that different parts can cover each other... ... - encrypted traffic even on LAN - firewall around application server - apps coded securely - data encrypted on disks *** Fail securely ------------------------------------------ 3. FAIL SECURELY Plan for failure of the system, and fail to a secure state. Think about the invariants of the system! Example: - design a forced upgrade path in case - when exiting ------------------------------------------ ... security flaws are discovered and app needs to be rewritten ... make sure to restore invariant so system is stable *** use the principle of least privilege ------------------------------------------ 4. USE PRINCIPLE OF LEAST PRIVILEGE Not: "here, take my wallet and get me a coke" but "here's $1.25, go buy me a coke" Examples: - run app with - give/get file permissions that - run mobile code in ------------------------------------------ ... least privileged account possible ... only allow minimal access necessary (e.g., reading by the app) ... a sandbox with restrictive policies Q: Is there a tradeoff with usability? Yes, it is easier to ask for more privileges, e.g., in mobile code, so users aren't bothered with security decisions *** Compartmentalize ------------------------------------------ 5. COMPARTMENTALIZE Idea: breach of one "compartment" doesn't sink the entire ship System examples: - Trusted Solaris breaks system into roles: e.g., LogWriter Negative examples: - root access in Unix needed to open a port < 1024 so sendmail runs as root... ------------------------------------------ Like separate compartments of a submarine or the Titanic *** Keep it Simple ------------------------------------------ 6. KEEP IT SIMPLE Complexity increases risk of problems "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." -- Tony Hoare, Turing Award lecture, 1980 Complex designs are Complex implementations are Do reuse code of high quality, experience builds assurance ------------------------------------------ ... hard to understand and thus likely to have subtle problems ... likely to be buggy and also harder to maintain Q: Is this principle at odds with another principle? Yes, with defense in depth, as that adds more complexity Maybe only 2 layers of defense are enough ------------------------------------------ HOW TO DESIGN SIMPLICITY IN? Have a small number of choke points - small interfaces - helps to avoid - no "back doors"! Make the system usable easily - users shouldn't have to think hard to be secure - users shouldn't have to read documentation - get inputs directly from users - err on the safe side (securely) - users are lazy, so don't burden them with choices they don't want ------------------------------------------ ... through which control must pass ... scattering of security code/policies throughout system *** promote privacy ------------------------------------------ 7. PROMOTE PRIVACY Don't compromise user's privacy Protect personal information Keep security-related information private - especially in error messages ------------------------------------------ Q: Why promote privacy of user information? Good for business, and the right thing to do. *** remember that keeping secrets is hard ------------------------------------------ 8. REMEMBER THAT KEEPING SECRETS IS HARD E.g., PII of users cryptographic keys Compilation does not hide secrets, attackers can - don't hide cryptographic keys in code Insider attacks are real most attacks done by insiders ------------------------------------------ ... reverse engineer binaries (as we'll see) Q: Where should cryptographic keys be? Nowhere, created fresh for the session. In access-controlled files *** be reluctant to trust ------------------------------------------ 9. BE RELUCTANT TO TRUST Examples: - servers vs. clients - technical support for customers - use independent code audits Trust is transitive - you trusting code means you trust whatever that calls ------------------------------------------ Spafford: there always needs to be a root of trust, to guide any extension of trust in a system ... neither should servers trust clients or vice versa, as either could be compromised. Helps with compartmentalization ... trust of callers enables social engineering attacks *** use your community resources ------------------------------------------ 10. USE YOUR COMMUNITY RESOURCES Don't write your own cryptography routines use standard ones Use security libraries that are - widely used - widely scrutinized However: - open source software can have flaws e.g., heartbleed bug, FTP server ------------------------------------------