Principle 7:Promote privacy Privacy of users,but also of systems Counterexample:services tend to give information about themselves that can help the attacker figure out how to break in. -Telnet service tends to give the operating system name and version. ->telnet somemachine Trying 1.2.3.4 Connected to somemachine (1.2.3.4) Red Hat Linux release 7.0(Hedwig) Kernel 1.2.3.4 on an i686 login: -Solution 1:use firewalls to block unnecessary services Solution 2:remove such info from software (e.g.,changing telenet login) -Solution 3:give the WRONG info!No hurt to lie to attackers! Counterexample:SQL error messages on webpage Counterexample:HTTP (http://www.cse.msu.edu/~alexliu/a.html) ■CSE825 16
CSE825 16 Principle 7: Promote privacy Privacy of users, but also of systems Counterexample: services tend to give information about themselves that can help the attacker figure out how to break in. ─ Telnet service tends to give the operating system name and version. – > telnet somemachine Trying 1.2.3.4 Connected to somemachine (1.2.3.4) Red Hat Linux release 7.0 (Hedwig) Kernel 1.2.3.4 on an i686 login: ─ Solution 1: use firewalls to block unnecessary services ─ Solution 2: remove such info from software (e.g., changing telenet login) ─ Solution 3: give the WRONG info! No hurt to lie to attackers! Counterexample: SQL error messages on webpage Counterexample: HTTP (http://www.cse.msu.edu/~alexliu/a.html)
Principle 8:Hard to hide secrets Don't rely on security by obscurity [Kerckhoff principle] Don't assume attackers don't know the application source code, and can't reverse-engineer binaries -Don't hardcode secrets in code. Don't rely on code obfuscation Counterexample -DVD encryption -webpages with hidden URLs - passwords in javascript code-this happens! -CSE825 17
CSE825 17 Principle 8: Hard to hide secrets Don’t rely on security by obscurity [Kerckhoff principle] Don’t assume attackers don’t know the application source code, and can’t reverse-engineer binaries ─ Don’t hardcode secrets in code. ─ Don’t rely on code obfuscation Counterexample ─ DVD encryption ─ webpages with hidden URLs ─ passwords in javascript code – this happens!
Principle 9:Be Reluctant to Trust Minimize Trusted Computing Base (TCB),i.e.,the part of the system that has to be trusted Trusted'is not the same as“trustworthy” Counterexample:trust is extended far too easily in customer support. All user input is evil -Unchecked user input leads to buffer overflows,SQL injection,XSS on websites -User input includes cookies,environment variables,.. User input should not be trusted,and subjected to strong input validation checks before being used Don't trust your employees. Trust is transitive-make sure that trusted programs never invoke untrusted programs. -CSE825 18
CSE825 18 Principle 9: Be Reluctant to Trust Minimize Trusted Computing Base (TCB), i.e., the part of the system that has to be trusted “Trusted” is not the same as “trustworthy” Counterexample: trust is extended far too easily in customer support. All user input is evil ! ─ Unchecked user input leads to ● buffer overflows, SQL injection, XSS on websites ─ User input includes cookies, environment variables, ... User input should not be trusted, and subjected to strong input validation checks before being used Don’t trust your employees. Trust is transitive – make sure that trusted programs never invoke untrusted programs