Hacker Defined

2. Hacker Defined Original Meaning • Originally (1960s) used at the Massachusetts Institute of Technology (MIT); implied • Love of technology and technical excellence • Pursuit of deep understanding of systems • Playful creativity, extending the bounds of what could be done • As opposed to someone who knows just enough to get basic job done • RFC 1392, Internet User’s Glossary, 1993 defined “hacker” as “A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.”

3. Hacking Your Way to Secure Development John HeimannSr. Director, Security Programs Oracle

4. Classic Hack MIT Green Building Becomes Tetris Game Source: hacks.mit.edu

5. Hacker Defined More Recent Meaning • Wikipedia defines “hacker” as: • “Someone who seeks and exploits weaknesses in a computer system or computer network” • Usually connotes specific hacking knowledge and techniques: • Understanding of language specific capabilities and limitations • Knowledge of common developer errors and how to recognize them • Ability to probe system behavior and recognize likely flaws • Use of specific tools such as fuzzers • The best hackers perform deep analysis of systems to understand what is possible in the system (like hackers in the original sense)

6. Both Senses of Hacking are Importantfor Security! • Thinking like a hacker - in original sense of deep insight and understanding of technology, its capabilities and limits, thinking creatively about what is possible - is important for secure design and development • Acting like a hacker - in new sense of special knowledge and techniques to find security flaws - can find and avoid many security flaws in systems during development and testing

7. Not Everyone Can be a Hacker But everyone can leverage them • Expert hackers (old and new sense) are rare • Requires mental flexibility, deep knowledge of technology and security, creativity, insight, patience and hard work • Thinking like a hacker is critical in early stages of system development (requirements and design) • Hacker-specific knowledge and techniques (acting like a hacker) can often be captured and leveraged in coding and testing • Knowledge captured in coding standards, developer training • Techniques captured in analysis and testing tools

8. Requirements, Design, Implementation, Testing and Cost • By 1960s, computer systems engineers had learned that an error that cost $1 to fix in requirements phase • Cost $10 to fix in design phase • Cost $100 to fix in coding phase • Cost $1000 to fix in testing phase • Assuming finite budget, building a good system implies • Good requirements • Good design • Good coding • Good testing Thinking like a hacker (insight and creativity) Acting like a hacker (specific knowledge and techniques)

9. Hacking Your Way to Security Thinking like a hacker • Software system specification, design and coding must include security considerations • Based on deep understanding of software technology from a security point of view • Based on understanding of system security and operating environment • Requires thinking like a hacker – insight, understanding and creativity • Not just making the system work in the nominal, expected environment • What are the limits of what the can the system be made to do? • Specifically, what can errors or malicious users cause the system to do?

10. Hacking Your Way to Security Technical Context • Hacking methods used during and after development (analysis and testing) should be driven by knowledge of the nature and limits of the technology • Top N lists of vulnerabilities don’t apply absolutely • Searching for OWASP Top 10 problems makes sense in a web application but not in an operating system • Seek out most easily found and exploited weaknesses first • Prioritize findings based on potential damage, e.g., using Common Vulnerability Scoring Scheme (CVSS)

11. Hacking Your Way to Security Acting like a hacker • Hacker-specific knowledge and techniques are important parts of the security life cycle • Even with good requirements and design, errors can occur in coding • Design and implementation should be subject to hacker analysis and testing • Hacker techniques are not a substitute for hacker insight • Requirement and design errors are difficult to find through testing (and much more expensive to fix at that time) • Given finite development budget, security must be built into all phases of the development process (requirements, design, coding, testing)

12. Hacking Your Way to Security Practical Guidance • Organizations who develop software should implement secure development lifecycles which incorporate • Thinking like a hacker during requirements and design • Leverage hacker-specific knowledge and skills in development and testing • Secure development lifecycle should • Focus on avoidance of vulnerabilities prior to release, but also • Limit damage when vulnerabilities are found after release

13. Hacking Your Way to Security For software users • Ask questions about the secure development lifecycle (if any) for software used • Not all vendor practices are equal • One million eyes doesn’t make software secure, if none of the eyes are focused on security • Don’t leave low hanging fruit • Understand and follow software security best practices • Stay up to date on security patches • Actively seek out insecure configurations, unpatched systems

14. Thinking Like a Hacker Before you (or your vendors) start development • Ensure that there is a lifecycle process for secure development of all your software • Hackers don’t break into the strongest systems you have, they break into the weakest, and exploit chains of trust between systems • Ensure the organization is aligned with the process • Who is responsible for implementation of the process? • Is there independent oversight and reporting to executive management? • Have security experts been recruited/cultivated within development?

15. How Not to Hack your Way to Security Whitewashing development’s mistakes “Has the pentest team signed off on the product yet?” Image source: Project Gutenberg

16. Leveraging Hacker Knowledge Pre-development Standards and Training • Those who develop software, including architects, coders, QA, product management, and doc writers must know: • That hackers will try to break into the code they write/test/specify/document • How hackers think and work • Basic principals for avoiding security bugs, e.g.: • Never trust user input • Enforce least privilege • Make defaults secure • Overview of the secure lifecycle, reference to secure coding standards)

17. Thinking Like a Hacker Requirements and Design • System requirements and design should include consideration of security goals, threat environment • What is value of information managed or protected by the system? • Who can access the system, in what way? • What are the potential objectives of an adversary, and what might they be able to exploit to gain unauthorized access? • Best done by technology experts (hackers in old sense) who have deep knowledge, insight, creative thinking • Security-based architectural risk analysis can make the process more structured

18. Leveraging Hacker Knowledge Coding • Ensure that each development organization follows secure coding standards • Typically written by hackers • Good external standards exist for a number of languages • E.g., Carnegie Mellon CERT for C, C++, Java… • Internal standards can and should supplement externally defined standards, based on unique internal requirements and • Lessons learned from past failures • New technologies • New threats

19. Leveraging Hacker Skills Code review and analysis • Static code analysis tools can identify routine insecure coding patterns • E.g., Fortify, Parfait • Hackers can tailor the tools for maximum efficiency and minimum false positives • Ordinary developers/QA can then run the tools with very high leverage • Hacker code review • Can find subtle errors that tools would not find • Is expensive • Best focused on particularly critical code (crypto, authentication, etc.) • Often creates new analysis tools, which non-hackers can run

20. Leveraging Hacker Skills Penetration Testing • Fuzzing tools can find many vulnerabilities in deployed systems • Designed to mimic how hackers work • Can be run by non-hackers • Most effective when selected by and configured by hackers • Commercial (e.g., Webinspect) tools can be supplemented by special purpose tools selected or built by hackers • Hacker penetration testing is similar to hacker code review • Can often find vulnerabilities that tools don’t • Expensive so should focus on most critical functionality • Can often lead to new tools which non-hackers can use

21. Leveraging Hacker Skills Approved Security Implementations • Critical security functions should be carefully designed (hacker thinking) and thoroughly tested (hacker knowledge and technique) • Encryption • Authentication and Authorization • Cloud isolation • Reduces technical risk • Increases probability of successful evaluation (e.g., FIPS 140) or certification (e.g., PCI)

22. Hacking Your Way to Secure Deployment Is Your Securely-Developed Software Secure in Operation? • Scanning and pen testing (hacker techniques) can identify weaknesses in deployment, but • Holistic assessment of deployed software security, including controls around the software (thinking like a hacker), is critical • What are potential attacker objectives and attack vectors? • Have security capabilities of software been fully leveraged? • Are network access, auditing, OS hardening appropriate given threat? • Ongoing assurance depends on adapting to new information • Changes to system environment/threat – reassess security • Newly discovered vulnerabilities – keep up to date on patches

23. Hacking Your Way to Security Impact on software developers • Hacking insights, knowledge, and techniques must be built into the software development lifecycle • Hacker insight and ability during requirements and design • Hacker knowledge and skills during coding and testing • Hacker knowledge and skills applied after development • E.g., by third party pen testing or security assessment companies • May be useful to check security or find residual bugs • Is not a substitute for a secure development lifecycle

24. Hacking your Way to Security Impact on software buyers • Ask about the secure development lifecycle process of your vendors • Does the process include appropriate security knowledge and insight at each phase of the lifecycle (thinking like a hacker, acting like a hacker)? • Is the process publicly documented? • Consumers of software should not accept security claims based solely on third party analysis or testing

25. Hacking Your Way to Security Throughout the Software Product Lifecycle

26. Graphic Section Divider