D. Best Practices D.1. Assurance The 5 th A

Transcription

1 Best Practices I&C School Prof. P. Janson September 2014 D. Best Practices D.1. Assurance The 5 th A 1 of 20

2 IT systems are insecure for two main reasons: People are fallible and systems are complex and brittle If architects built buildings the way programmers build IT systems the first woodpecker would cause civilization to collapse Software products hold promises but no liability like religious preaches 2 of 20

3 Technology cannot do much about human fallibility but it can do more and more about systems brittleness 3 of 20

4 How can we built more reliable systems? SD 3 systems Emerging security engineering code books Recommended security engineering practices 4 of 20

5 Recommended security design practices Cursory inspection of main secure coding guidebooks reveals many common recommendations 1. Strategy and education 2. Requirements and standards 3. Architecture / design & review 4. Implementation & review 5. Testing and vulnerability assessment 6. Deployment and response 5 of 20

6 4. Implementation => e.g. 50% reduction in XSS vulnerabilities from 2008 to of 20

7 Secure programming Implement security as designed, watching for classical pitfalls (especially SANS Top 25 list) Ensure proper authentication, authorization, crypto, configuration Watch out for potential data leakage opportunities Encapsulate, confine, sandbox components / instances as much as possible Run different ones in different virtual machines Beware of importing java classes with clashing names Separate executable code and data Watch out for dangerous file types Properly validate all inputs (See next chart) Properly encode / escape all output Best practice against XSS attacks Watch out for resource usage & dangling pointers to de-allocated objects Excessive de/allocation size and rate may signal DoS attack Properly handle exceptions and safely recover from errors (without leaks) Beware of non-reentrant error-handling code Beware of race conditions To avoid TOCTOU attacks etc. 7 of 20

8 IT Security Secure programming Input validation BEWARE OF XSS, CSRF, INJECTION ATTACKS, BUFFER OVERFLOWS Rule #1: Validate all inputs & all incoming data for size and content Rule #2: Validate all inputs & all incoming data for size and content Rule #3: Validate all inputs & all incoming data for size and content Rule #4: Validate all inputs & all incoming data for size and content Check size, format, content of every input Beware of character counts null & other invisible and end-of-string chars Beware of character vs. byte counts (esp. with DBCS) Beware of polymorphic objects Beware of input files, file content, file types Beware of inputs passed by reference (unrestricted file pathnames & resource URLs) Filter or map to internal pathname Jail code to restricted root (chroot) Watch out for uncontrolled redirects, forwards, and their parameters Isolate back-end from possible front-end mistakes / malice Never let external input data be used as internal control statement Beware of executed / evaluated / interpreted (script) input (injection attacks) Beware of use of environment variables, format strings, dangerous functions 8 of 20

9 Secure programming Always inform users of previous login to allow abuse detection Always require SSL with strong ciphers and valid certificates Always prefer HTML5 to avoid the risks of unknown browser plug-ins Validate / enforce file type extensions Run mobile code in confined sandboxes Restrict privileges to resources that code really needs Turn directory indexing OFF Turn logging ON Restrict error handling to uninformative, static messages Do not forget to patch included components to latest level 9 of 20

10 Secure programming education Mark G. Graff, Kenneth R. van Wyk Secure Coding: Principles and Practices O'Reilly, 2003 John Viega, Zachary Girouard, Matt Messier Secure Programming Cookbook for C and C++ O'Reilly, 2003, freely downloadable Michael Howard & David LeBlanc Writing Secure Code, 2nd Edition Microsoft, 2003 Michael Howard, David LeBlanc, John Viega 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them Microsoft, 2005 Tom Gallagher, Lawrence Landauer, Bryan Jeffries Hunting Security Bugs Microsoft, 2006 Robert C. Seacord The CERT C Secure Coding Standard Addison-Wesley, of 20

11 Code reviews = white-box vulnerability scanning Use security experts Motivate / reward them because this is time-consuming and boring but essential Use automated tools that Verify and enforce coding standards Specifically check code against SANS / Mitre Top 25 or other pitfall lists Trace tainted data and control flows, memory de/allocations Check dependencies, operational assumptions, boundary conditions Maintain centralized reporting incl. bugs list 11 of 20

12 Code review education 12 of 20

13 5. Security testing and vulnerability assessment = black-box vulnerability scanning Functional testing tests that software can be used as advertised by legitimate users Security testing tests that software cannot be abused by illegitimate users 13 of 20

14 Security Testing Enhance quality assurance (QA) beyond the functional perspective Practice risk-based security testing = Deriving security tests from risk analysis results Capture risk analysis results into declarative security features derived from Threat models, abuse cases, security requirements, documentation Use external audit teams 14 of 20

15 6. System deployment and incident response Documentation Document security features for operators as well as users Software certification Deployment Ensure clean supply chain Incident response 15 of 20

16 Certification Common Criteria (ISO 15408) Resulted from merge and extension of US government Trusted Computing Security Evaluation Criteria (TCSEC) EU Information Technology Security Evaluation Criteria (ITSEC) Defines 7 system Evaluation Assurance Levels EAL1 functionally tested EAL2 structurally tested EAL3 methodically tested and checked EAL4 methodically designed, tested, and reviewed EAL5 semi-formally designed and tested EAL6 semi-formally verified design and tested EAL7 formally verified design and tested 16 of 20

17 Certification Common Criteria (ISO 15408) Merits Provide logical links from threats and policies down to required security and even source code Specify everything as testable, evidence-based Attempt to deal with system composition Highlight some of the basic security principles KISS Complete mediation Separation of privileges Self-protection / tamper-resistance 17 of 20

18 Certification Common Criteria (ISO 15408) Shortcomings Focus on assurance with only few good hints on development process Weak in some assurance areas that are still important No real mention of education No real mention of code review (static / dynamic vulnerability analysis) (Did not exist at the time) Includes functional testing of security code but no security testing of functional code (Distinction was not explicit at the time) Perverse economics Vendors pay for certification but not for security failure Assume no damage liability Suffer no certificate revocation 18 of 20

19 Incident response Software manufacturer and software buyer share common but contradictory interests Incident report => fix software flaws No incident publication => prevent brand damage Requires process including Channel for reporting Design flaw identification + fix Software patch implementation + distribution Delinquency is rampant 19 of 20

20 Patches are still unavailable for ca. 40% of all vulnerabilities Source: IBM X-force 2011 Trend and Risk Report Reprinted by courtesy of International Business Machines Corporation, ( ) International Business Machines Corporation 20 of 20