Ten Tough Questions to Ask Your Developers About Security and the Web

1. Ten Tough Questions to Ask Your Developers About Security and the Web Phil Wherry(psw@wherry.com)ApacheCon 2001Santa Clara, California

2. About the Course • Goals • Identify a short list of key questions to answer when developing secure Web-based systems • Look beyond simple security measures such as firewall deployment and host hardening • Explain key concepts and technologies required to design and build secure Web applications

3. Intended Audience • PHBs: Development and project managers • Responsible for progress and security of Web application development efforts • Need to know what questions to ask • Software developers • Familiar with Web development; unfamiliar with security • Need to anticipate questions that might (or should) be asked

4. Information Security is a Growing Concern • Attacks on security are real • 85% of survey respondents were successfully attacked. 64% acknowledged financial losses (the reported total exceeds $377,000,000!) • Threat is both internal and external • 31% reported attacks from the inside • 70% reported attacks from the outside • Damage takes a number of forms • Site vandalism (90%) • Denial of service (78%) • Theft of transaction information (13%) • Financial fraud (8%) Source: 2001 FBI/CSI Computer Crime and Security Survey

5. Information Security is an Enabling Technology • Privacy of transactions • Host data integrity • Authenticity of buyer/seller • Access restrictions • Guaranteed transactions • Reliable transport • Assured service Security technology provides… … to satisfy critical business needs Confidentiality Integrity Availability Accountability

6. Ten Tough Questions 1. What are we protecting, and why? 2. Where can I find a copy of our security policy? 3. What principles do our designers and developers apply when building a secure system? 4. How do our developers translate from policy and principle to practice? 5. How have we secured our electronic perimeter?

7. Ten Tough Questions (Concluded) 6. Can I trust my most sensitive data to the Web? 7. What role does encryption play in my security posture? 8. As our business needs change, will my security be strong enough, yet flexible enough to grow/expand/evolve? 9. What if something goes wrong ? 10. How do I proceed from here ?

8. Question #1 • What do I protect, and why?

9. Financial Services Scenario Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data A financial services organization providing online home banking, equity trading, and credit card customer service

10. Financial Services Scenario Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customersuse Web browsers to interact with bank services. They connect to the bank via the Internet. Customer account data

11. Financial Services Scenario The bank provides a number of different services to its customers via a set of Web servers. Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data

12. Financial Services Scenario Home banking app Internal network Customer account data Customer information (account balances, etc.) resides in databases on the bank’s mainframe systems. Credit card app Customers connect via the Internet Equity trading app Customer account data

13. Financial Services Scenario Communication between the Web servers and the mainframes takes place over the bank’s internal network. Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data

14. Threats • Circumstance or event that could cause harm • Human attacks • Inadvertent human errors • Software or hardware flaws • Natural disasters • Threats may be internal, external, or both • System threats may be against hardware, software, or data Terminology

15. Hardware Denial of Service Theft Software Theft Deletion Modification Data Fabrication Modification Interception Loss Typical System Threats Security in Computing, C.P. Pfleeger, 1997

16. Vulnerability • A weakness in system security that might be exploited to cause loss or harm • Weak system design • Flawed implementation • Bad procedural controls • Improper operation • Inadequate personnel controls Terminology

17. Countermeasures • Anything that reduces a vulnerability • Software • Hardware • Technique • Procedure • Action Terminology

18. Continuing Trends • Intruders have better technical knowledge • Intruders know more about network topology and operations • Attacks on the network infrastructure are increasing • Use of publicly available automated attack tools is increasing • Intruders are cloaking their behavior through use of Trojan horses and cryptography • Cracking for profit is on the rise

19. Financial Services Scenario Revisited • An attacker of this system might seek to: • Disclose a user’s credit card number or other personal information • Modify bank balances • Deny service to customers • Illegally transfer of funds • Illegally change an “address of record” • Damage the corporate image (“spray painting”) • Many others...

20. Electronic vandalism August 1996 attack on the Department of Justice. DOJ detected damage within a few hours. Web site off the air for ~2 days. This and over 12,000 other attacks are mirrored at www.attrition.org

21. Answer #1 • Why take on the challenges of information security? • To avoid embarrassment • To avoid financial loss • Because the public cares about it • Because your competitors are doing it • What do I protect ? • Assets that may be misused • Assets that are worth protecting

22. Examples of Computer Misuse • Abuse of authority • External misuse without system access • Social engineering attacks • Spying • Scavenging • Hardware misuse • Eavesdropping • Theft, damage, or modification • Scavenging Adapted from Computer Related Risks, Peter G. Neumann, 1997 Understanding basic types of misuse is important for developing enterprise-wide countermeasures

23. Examples of Computer Misuse (Concluded) • Masquerading • Impersonation • Spoofing • Playback • Bypassing controls • Trapdoors • Active attacks • Malicious programs • Trojan horses • Viruses • Worms

24. Risk Analysis • Goal: Apply cost-effective security controls where they are needed • General steps: • Identify assets • Determine threat sources and vulnerabilities • Estimate likelihood of occurrence • Estimate losses • Consider potential countermeasures • Balance potential losses with cost of countermeasure Deciding what to protect

25. Risk Analysis Techniques • Formal • Follow a well defined methodology for data collection and analysis • Use specific valuations • Usually includes use of [expensive, proprietary] software tools Informal • Identify issues and potential responses • Select course of action based on experience

26. Benefits of Formal Risk Analysis • Helps ensure completeness of design • Provides a documented basis for making balanced decisions • Helps justify security investments

27. Drawbacks to Formal Risk Analysis • Relies on dollar values and assumptions that are hard to verify • Not all costs and benefits can be quantified • Can easily provide a false sense of precision • Statistical basis for some risk analysis may not apply to information security breaches • Catastrophic threats may be obscured • No standard risk model, especially for systems-of-systems • Can be tedious and costly if carried to extremes

28. In The End... • There are no easy answers • Value judgements abound • You will have to balance cost of losses with cost of countermeasures • …however, • Incomplete risk analysis will still deliver significant value

29. Question #2 Where can I find a copy of our security policy? • Answer: It should be everywhere • On your intranet • In the new employee folder • Attached to annual employee assessments • On your developer’s desktops... (What do you mean, we don’t have a policy?!?)

30. Policy -- The Basis for a Secure System • Policy = a statement of intended behavior • Establishes guiding security principles for an organization • Employees • Contractors • Partners • Developers, etc. Policies must be realistic, useful, maintainable, and widely disseminated.

31. Different Policies for Different Needs • Organizational policies • Statements to guide organizational behavior • E.g., “All Company Information shall be protected against unauthorized disclosure, dissemination, modification and destruction.” • Organizational policies must be refined to increasingly lower levels of detail to guide implementation. The statement above, by itself, won’t help Web application developers in any meaningful way. • Application policies • Statements to guide application development

32. Typical Security Policies • Military security policies (label based) • Commercial security policies • Transaction-based security policies (Clark-Wilson)

33. Top Secret Secret Confidential Unclassified Most Sensitive Sensitivity Levels Least Sensitive Military Security Policies • Focused primarily on controlling disclosure • Based on strict, well-defined rules and central security authorities • Data is labeled based on its sensitivity (sensitivity level) Label-based policies In actual military policies, other labels are also associated with data.

34. “Commercial” Security Policies • Some concepts are similar to military policies • Commercial data has different degrees of sensitivity • Employees have different degrees of trustworthiness and need-to-know • E.g., Accounting, Personnel, Proprietary, Public, Project Alpha, Project Beta • Often less structured than military policies • “Clearances” are rarely formalized • Centralized authority is usually weak • Access control rules are often not formalized

35. Transaction-based Security Policies • Focuses on integrity, rather than confidentiality • Fraud prevention and error detection is key • Basic policy concepts: • Well-formed transactions • Users can only manipulate data in constrained ways • Separation of duties • Any user who can create and “certify” a well-formed transaction must be prohibited from executing that transaction First formalized in A Comparison of Commercial and Military Computer Security Policies, Clark & Wilson, 1987

36. 1. Order Supplies 3. Receive supplies Purchase Order Delivery receipt Payment Invoice 2. Vendor ships supplies 4. Send payment Transaction-based Security Policies (Continued) • Precise steps must be performed in order, by authorized individuals, to constitute a well-formed transaction Accounting Dept.

37. Transaction-based Security Policies (Concluded) • A simplified view of required mechanisms: • Identification & authentication of users • A way to certify transactions • A means of associating transactions with users • A way to restrict data modification to certified transactions • A means of restricting users to authorized transactions • A means to certify that transactions receiving user input behave properly • A means of certifying the initial state

38. Sample Statements for Financial Services Example • Customers may access only their own financial data, and only after appropriate identification and authentication information has been presented • Web users may not directly access production databases • Web-based transactions shall create end-to-end audit trails • …there aremany othersin a typicalsystem.

39. Also ask your developers…(the answers should be traceable to security policy) • What type of authentication will be used? • How strong? • How easy to use? • What degree of isolation is required between system components? • “Air gap” • Mediated proxy • Router or firewall • Is it sufficient to know that something happened, or must it be traceable to a specific individual?

40. Follow-up Question • How do I know that my security policy is reflected in the system as implemented? • Answer: • Because our designers and developers adhere to certain fundamental security principles and a set of security best practices (more on that later) • By taking steps to ensure that assurance is considered an integral part of the system • Security functional testing • Penetration testing • Ongoing “white hat” assessments

41. Security Functional Testing • Attempt to demonstrate that security services and mechanisms are: • Correct • Always invoked • Tamper-resistant • Clear security policy and requirements are critical

42. Security Functional Testing (Continued) • Techniques • Traditional black, white, and gray box testing techniques may be used • Flaw hypothesis methodology may also be used • Gather knowledge of the system control structure • Generate an inventory of suspected flaws • Confirm the hypotheses • Make generalizations about the underlying system weakness for which the flaw represents a specific instance.

43. Security Functional Testing (Concluded) • Use positive and negative testing techniques • Positive testing = show that security mechanisms implement the security policy • Negative testing = show that attempts to circumvent and violate the security policy are unsuccessful • Test the least used aspects of security mechanisms • Ideally, security functional testing will occur throughout the lifecycle

44. Penetration Testing • Tiger team of security experts tries to crack system security • Draws on knowledge of: • Typical flaws • Network protocols • Configuration errors, etc. • Information comes from: • Bug lists • Newsgroups • CERT advisories • Books, magazines, newsletters • Underground sources

45. Adapting Black-Hat Techniques to System Security Testing • Full-Fledged Attack • Create, or hire, a tiger team to attempt system penetration without providing the team any special information or access • Assisted attacks • Create, or hire, a tiger team to attempt system penetration • Focus the team on the most critical systems or applications • Provide a point-of-contact who supplies information on request that could eventually be found through extensive probing (why pay someone to discover what you already know?)

46. Question #3 • What principles do our designers and developers apply when building a secure system?

47. Principles for building secure systems and applications Adequate protection Easiest penetration Complete mediation Fail-safe defaults Least privilege Separation of privilege Economy of mechanism Open design Psychological acceptability Answer #3

48. Adequate Protection • Resources must only be protected until they lose their value • Resources must be protected to a degree consistent with their value

49. Easiest Penetration • An attacker will look for the weakest link • Examples • A social engineering attack may be easier than a technical attack • Intercepting an encryption key is probably easier than breaking the underlying encryption algorithm • Walking through an open back door (literally or figuratively) is easier than breaking down a locked front door

50. Complete Mediation • Every access to every object must be checked for compliance with the security policy • Maximizes security since it’s impossible to bypass security checks • Principle must be applied throughout system operation (initialization, normal operation, recovery, shutdown, maintenance) • Tension between security and performance will always exist