Ten Tough Questions to Ask Your Developers About Security and the Web Phil Wherry (psw@wherry. com) Apache. Con 2001 Santa Clara, California
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 2 About the Course Goals l Identify a short list of key questions to answer when developing secure Web-based systems l Look beyond simple security measures such as firewall deployment and host hardening l Explain key concepts and technologies required to design and build secure Web applications
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 3 Intended Audience PHBs: Development and project managers l Responsible for progress and security of Web application development efforts l Need to know what questions to ask Software developers l Familiar with Web development; unfamiliar with security l Need to anticipate questions that might (or should) be asked
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 4 Information Security is a Growing Concern Attacks on security are real l 85% of survey respondents were successfully attacked. 64% acknowledged financial losses (the reported total exceeds $377, 000!) Threat is both internal and external l l Source: 2001 FBI/CSI Compute r Crime and Security Survey 31% reported attacks from the inside 70% reported attacks from the outside Damage takes a number of forms l Site vandalism (90%) l Denial of service (78%) l Theft of transaction information (13%) l Financial fraud (8%)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 5 Information Security is an Enabling Technology Security technology provides… Confidentiality Integrity … to satisfy critical business needs Privacy of transactions Host data integrity Authenticity of buyer/seller Access restrictions Availability Accountability Guaranteed transactions Reliable transport Assured service
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 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?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 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 ?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 8 Question #1 What do I protect, and why?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 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
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 10 Financial Services Scenario Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Customers use Web browsers to interact with bank services. They connect to the bank via the Equity trading app Customer account data
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 11 Financial Services. The bank provides Scenario Home banking app a number of different services to its customers via a set of Web servers. Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 12 Financial Services Scenario Home banking app Internal network Customer account data Customers connect via the Internet Customer Credit card app information (account balances, etc. ) resides in Equity trading databases on the app bank’s mainframe systems. Customer account data
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 13 Financial Services Scenario Communication between the Web Home banking servers and the app mainframes takes place over the bank’s internal network. Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data
Ten Tough Questions to Ask Your Developers About Security and the Web Terminology 6 April 2001 14 Threats Circumstance or event that could cause harm l Human attacks l Inadvertent human errors l Software or hardware flaws l Natural disasters Threats may be internal, external, or both System threats may be against hardware, software, or data
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 15 Typical System Threats Hardware Data l Denial of Service l Fabrication l Theft l Modification l Interception l Loss Software l l Security in Computing, C. P. Pfleeger, 1997 Theft Deletion l Modification
Ten Tough Questions to Ask Your Developers About Security and the Web Terminology 6 April 2001 16 Vulnerability A weakness in system security that might be exploited to cause loss or harm l Weak system design l Flawed implementation l Bad procedural controls l Improperation l Inadequate personnel controls
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 17 Countermeasures Anything that reduces a vulnerability Terminology l Software l Hardware l Technique l Procedure l Action
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 18 Continuing Trends l Intruders have better technical knowledge l Intruders know more about network topology and operations l Attacks on the network infrastructure are increasing l Use of publicly available automated attack tools is increasing l Intruders are cloaking their behavior through use of Trojan horses and cryptography l Cracking for profit is on the rise
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 19 Financial Services Scenario Revisited An attacker of this system might seek to: l Disclose a user’s credit card number or other personal information l Modify bank balances l Deny service to customers l Illegally transfer of funds l Illegally change an “address of record” l Damage the corporate image (“spray painting”) l Many others. . .
Ten Tough Questions to Ask Your Developers About Security and the Web 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 6 April 2001 20
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 21 Answer #1 Why take on the challenges of information security? l To avoid embarrassment l To avoid financial loss l Because the public cares about it l Because your competitors are doing it What do I protect ? l Assets that may be misused l Assets that are worth protecting
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 22 Examples of Computer Misuse l Abuse of authority l External misuse without system access l l Spying l l Social engineering attacks Scavenging Hardware misuse l l Adapted from Computer Related Risks, Peter G. Neumann, 1997 Eavesdropping Theft, damage, or modification l Scavenging Understanding basic types of misuse is important for developing enterprise-wide countermeasures
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 23 Examples of Computer Misuse (Concluded) l Masquerading l l Spoofing l l Impersonation Playback Bypassing controls l l l Trapdoors Active attacks Malicious programs l Trojan horses l Viruses l Worms
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 24 Risk Analysis Goal: Apply cost-effective security controls where they are needed General steps: l l Determine threat sources and vulnerabilities l Decidin g what to protect Identify assets Estimate likelihood of occurrence l Estimate losses l Consider potential countermeasures l Balance potential losses with cost of countermeasure
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 25 Risk Analysis Techniques Formal l Follow a well defined methodology for data collection and analysis l Use specific valuations l Usually includes use of [expensive, proprietary] software tools Informal l Identify issues and potential responses l Select course of action based on experience
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 26 Benefits of Formal Risk Analysis l Helps ensure completeness of design l Provides a documented basis for making balanced decisions l Helps justify security investments
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 27 Drawbacks to Formal Risk Analysis l Relies on dollar values and assumptions that are hard to verify l Not all costs and benefits can be quantified l Can easily provide a false sense of precision l Statistical basis for some risk analysis may not apply to information security breaches l Catastrophic threats may be obscured l No standard risk model, especially for systemsof-systems l Can be tedious and costly if carried to extremes
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 28 In The End. . . There are no easy answers l Value judgements abound l You will have to balance cost of losses with cost of countermeasures …however, l Incomplete risk analysis will still deliver significant value
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 29 Question #2 Where can I find a copy of our security policy? (What do you mean, we don’t have a policy? !? ) Answer: It should be everywhere l On your intranet l In the new employee folder l Attached to annual employee assessments l On your developer’s desktops. . .
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 30 Policy -- The Basis for a Secure System Policy = a statement of intended behavior Establishes guiding security principles for an organization l Employees l Contractors l Partners l Developers, etc. Policies must be realistic, useful, maintainable, and widely disseminated.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 31 Different Policies for Different Needs Organizational policies l Statements to guide organizational behavior l E. g. , “All Company Information shall be protected against unauthorized disclosure, dissemination, modification and destruction. ” l 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 l Statements to guide application development
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 32 Typical Security Policies Military security policies (label based) Commercial security policies Transaction-based security policies (Clark -Wilson)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 33 Military Security Policies l In actual military policies, other labels are also associated with data. l Based on strict, well-defined rules and central security authorities l Labelbased policies Focused primarily on controlling disclosure Data is labeled based on its sensitivity (sensitivity level) Top Secret Sensitivit y Levels Most Sensitive Secret Confidential Unclassified Least Sensitive
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 34 “Commercial” Security Policies l Some concepts are similar to military policies l l 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 l “Clearances” are rarely formalized l Centralized authority is usually weak l Access control rules are often not formalized
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 35 Transaction-based Security Policies l Focuses on integrity, rather than confidentiality l l Fraud prevention and error detection is key Basic policy concepts: l Well-formed transactions – Users can only manipulate data in constrained ways l First formalized in A Comparison of Commercial and Military Computer Security Policies, Clark & Separation of duties – Any user who can create and “certify” a well-formed transaction must be prohibited from executing that transaction
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 36 Transaction-based Security Policies (Continued) 1. Order Supplies Purchase Order 3. Receive supplies Delivery receipt Accounting Dept. Invoice 2. Vendor ships supplies l Payment 4. Send payment Precise steps must be performed in order, by authorized individuals, to constitute a wellformed transaction
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 37 Transaction-based Security Policies (Concluded) A simplified view of required mechanisms: l Identification & authentication of users l A way to certify transactions l A means of associating transactions with users l A way to restrict data modification to certified transactions l A means of restricting users to authorized transactions l A means to certify that transactions receiving user input behave properly l A means of certifying the initial state
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 38 Sample Statements for Financial Services Example l Customers may access only their own financial data, and only after appropriate identification and authentication information has been presented l Web users may not directly access production databases l Web-based transactions shall create end-to-end audit trails l …there are many others in a typical system.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 39 Also ask your developers… (the answers should be traceable to security policy) l What type of authentication will be used? l l l How strong? How easy to use? What degree of isolation is required between system components? l l Mediated proxy l l “Air gap” Router or firewall Is it sufficient to know that something happened, or must it be traceable to a specific individual?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 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
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 41 Security Functional Testing Attempt to demonstrate that security services and mechanisms are: l Correct l Always invoked l Tamper-resistant Clear security policy and requirements are critical
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 42 Security Functional Testing (Continued) Techniques l Traditional black, white, and gray box testing techniques may be used l Flaw hypothesis methodology may also be used l Gather knowledge of the system control structure l Generate an inventory of suspected flaws l Confirm the hypotheses l Make generalizations about the underlying system weakness for which the flaw represents a specific instance.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 43 Security Functional Testing (Concluded) Use positive and negative testing techniques l Positive testing = show that security mechanisms implement the security policy l 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
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 44 Penetration Testing Tiger team of security experts tries to crack system security l Draws on knowledge of: l l Network protocols l l Typical flaws Configuration errors, etc. Information comes from: l Bug lists l Newsgroups l CERT advisories l Books, magazines, newsletters l Underground sources
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 45 Adapting Black-Hat Techniques to System Security Testing Full-Fledged Attack l Create, or hire, a tiger team to attempt system penetration without providing the team any special information or access Assisted attacks l Create, or hire, a tiger team to attempt system penetration l Focus the team on the most critical systems or applications l 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? )
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 46 Question #3 What principles do our designers and developers apply when building a secure system?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 47 Answer #3 Principles for building secure systems and applications l Adequate protection l Easiest penetration l Complete mediation l Fail-safe defaults l Least privilege l Separation of privilege l Economy of mechanism l Open design l Psychological acceptability
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 48 Adequate Protection Resources must only be protected until they lose their value Resources must be protected to a degree consistent with their value
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 49 Easiest Penetration An attacker will look for the weakest link Examples l A social engineering attack may be easier than a technical attack l Intercepting an encryption key is probably easier than breaking the underlying encryption algorithm l Walking through an open back door (literally or figuratively) is easier than breaking down a locked front door
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 50 Complete Mediation Every access to every object must be checked for compliance with the security policy l Maximizes security since it’s impossible to bypass security checks l Principle must be applied throughout system operation (initialization, normal operation, recovery, shutdown, maintenance) l Tension between security and performance will always exist
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 51 Fail-Safe Defaults Base security decisions on permission rather than exclusion l By default, access should always be denied l Explicit actions should be required to grant access Use fail-safe defaults in the protection mechanism’s external appearance and internal implementation
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 52 Fail-Safe Defaults (Concluded) Consider this permission test pseudocode: if user_allowed(x) perform_ops(); else deny_ops(); if user_denied(x) deny_ops(); else perform_ops(); Assuming correct permission tables in each case, both fragments are identical But, permission tables are sometimes truncated. One example fails safe; the other grants permissions to unauthorized users!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 53 The Principle of Least Privilege Every user or component of an application or system should operate using the smallest set of privileges necessary to perform the job l The potential for misbehavior (accidental or malicious) to compromise the integrity of the application or system is minimized l You can’t abuse what you don’t have.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 54 Separation of Privilege A protection mechanism that requires two conditions to be met for access is better than a mechanism that requires only one l Multiple conditions can be constructed such that no single implementation error, accident, deception, or breach of trust will compromise security l Examples: l l Multi-party concurrence to perform a transaction Firewall + host-level hardening + application security
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 55 Economy of Mechanism Protection mechanisms should be small, simple, and straightforward l Reduces the likelihood of errors in development or future maintenance l Ideally, it should be possible to easily determine the operation of a protection mechanism by a simple reading of the code.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 56 Open Design The design of protection mechanisms should not be kept secret l Extensive review will improve the design l Skeptics can convince themselves of the adequacy of the security mechanisms l Secrets are very hard to keep from those determined to get them l Open-source software has a huge advantage in this respect. “Security by Obscurity” is a dangerous design philosophy
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 57 Psychological Acceptability Make protection mechanisms easy to use l Users are more likely to accept a security mechanism that seems appropriate and fits their mental image of what they are trying to accomplish Users (and developers) will, in most situations, fight a mechanism they find: l Unnecessary l Too hard or too complicated l Too time consuming l Too intrusive
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 58 Question #4 How do our application developers translate from policy and principle to practice?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 59 Answer #4 How do our application developers translate from policy and principle to practice? l By understanding our security requirements and the techniques for satisfying those requirements l By carefully partitioning our applications into trusted and untrusted components (Security Architecture) l By employing a set of “best practices” for implementation l Defensive programming l Defensive networking
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 60 Selected Security Issues: Financial Services Scenario l Who is the user? l Is the user allowed to perform an action? l How can integrity/privacy of information in transit be protected? l How can a record be kept of actions taken by the user (and the system on behalf of the user)? l Internal authorization: credit card app has no business touching equities data, for example. l How can the integrity of the audit trail be maintained?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 61 From Policy to Practice Security policy Security principles Security architecture Security practice
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 62 Trusted vs. Untrusted Components Trusted components l Responsible for maintaining application security l Misbehavior of trusted components can compromise overall application/system security l Typical examples of trusted components: authentication server, authorization module, transaction processor Untrusted components l Not responsible for security of application l Misbehavior can degrade or deny service, but will not compromise application/system security
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 63 Client/Server Designs The server can be made much more secure than the client l Client systems may have weak operating systems l Client systems are subject to alteration by the end user (or programs the user runs) l Client systems may be left unattended l Web developers generally have no control over client configuration Don’t trust the client!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 64 Centralization of Security Authority l Security components are difficult to develop and verify l Multiple parallel security entry points into an application or system increases risk
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 65 Centralization of Security Authority (Concluded) Centralization of security authority can minimize the number of potential entry points l Test/debug is consequently simplified: smaller code base to verify l More coherent administration is usually possible l Security designers can better focus on critical areas
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 66 The Limits of Centralization l Centralization of security authority only makes sense within a trust domain l Where trust domains differ, each should enforce security controls l Judicious use of client-side cookies and cryptography can make this process transparent.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 67 From Policy to Practice Security policy Security principles Security architecture Security practice
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 68 A Few Best Practices l Design before you start l Limit the flexibility of security-critical code l Use native capabilities where possible l Don’t make assumptions about input data content l Initialize programs correctly l Log useful information
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 69 A Few Best Practices (Continued) l Protect against object reuse l Use chroot(), or similar capabilities, where possible l Don’t depend on the environment l Check return codes l Test permissions as they’re used l Check buffer boundaries l Consider race conditions
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 70 A Few Best Practices (Continued) l Use temporary files properly l Handle multiple instances of the same application running simultaneously l Ensure security of persistent storage l Use one-way hashes to protect data l Carefully create random numbers l Plan to fail
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 71 Above All Else: Do Not Make Assumptions About Input Data Your application protocol may specify that only certain types of data are acceptable What happens when an attacker sends something else instead? l A closer look at a few best practices. . . Data validation should be done at the server (though client-side data validation is useful in addition to server-side checking) l Never rely on the contents of HTTP cookies, hidden values in forms, etc. l Log exceptions; this is useful for debugging as well as security. Be sure logging doesn’t introduce additional risks, though!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 72 Above All Else: Do Not Make Assumptions About Input Data Be especially careful when passing usersupplied data to shells and/or databases. l Enumerate characters to be allowed l Enforce maximum length l Log exceptions
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 73 Check Buffer Boundaries Consider this code fragment… char line[512]; … line[0] = ’ ’; gets(line); (from Unix fingerd source, circa 1988) Problems… l A closer look at a few best practices. . . fingerd runs as root (a fully-privileged user). l gets() assumes an arbitrarily large buffer. This was one of two vulnerabilities exploited in the now-famous Morris Internet Worm. More than a decade later, buffer overruns are still one of the leading avenues of successful attack
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 74 Check Buffer Boundaries l Assume any operating system function can be subverted by a buffer overrun l In recent versions of Unix, dozens of system calls have been susceptible to overrun l l l The NT situation is similar Test before calling! Remember that these functions don’t have to be called directly by your application to be troublesome l Manage buffer lengths carefully before handing control to any external code
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 75 Random Numbers Random numbers are often used for things like temporary session keys l l Most operating-system random number routines are weak l A closer look at a few best practices. . . If the random numbers can be predicted, the need to exhaustively search a keyspace can be eliminated (or the problem greatly reduced) Choosing good seed values is hard l l Reasonably good: fine-grained packet arrival times, constantly-changing OS parameters, /dev/random on certain operating systems Bad: hardware serial numbers, time of day, Ethernet/IP addresses RFC 1750 contains details on good and bad pseudo-random numbers
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 76 Question #5 How have we secured our electronic perimeter?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 77 Answer #5 How have we secured our electronic perimeter? l By developing a security perimeter based on our security policy and our chosen network architecture l By selecting a firewall based on our security needs and IT infrastructure l By integrating authentication and other security services l By ensuring that the hosts visible at our perimeter have been “hardened”
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 78 System and Application Security System Security l Architecting and deploying the hardware and software components of a distributed system to ensure a reasonable degree of security Application Security l Designing and implementing security controls into application software
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 79 Financial Services Scenario Revisited Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Provide a first line of defense for resources accessible via the internet Customer account data
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 80 Financial Services Scenario Revisited Remember the Principle of Easiest Penetration ! Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data Control remote access to the basic infrastructure
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 81 Financial Services Scenario Revisited Home banking app Internal network Customer account data Credit card app Customers connect via the Internet Equity trading app Customer account data A coherent, enterprisewide security perimeter is needed
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 82 Why Use Perimeter Controls? To establish a “zone of control” around your enterprise To enforce: l l Perimeter controls may impact application design. Plan ahead! Who - may use your networks What - actions they may perform l Where - on what systems l When - (time of day, from what locations, using what program etc. ) And to monitor their actions
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 83 Characteristics of a Good Security Perimeter l Limited and controlled connectivity l l Minimize “islands of infosec” Coherent network addressing scheme l Makes it easier to partition the network into segments with different protection requirements l Makes security-related routing decisions possible l Simplifies security administration l Integrated point solutions l Cohesive, holistic view
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 84 Mechanisms for Implementing a Security Perimeter l Firewalls l Remote access l Authentication mechanisms l Hardened operating systems
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 85 Firewalls Simple packet filtering l e. g. , Cisco routers, tcp_wrappers Stateful filtering l e. g. , Checkpoint’s Firewall-1 Proxy-based l e. g. , Gauntlet …the lines of distinction between these basic types are often blurry.
Ten Tough Questions to Ask Your Developers About Security and the Web Fundamental policy rule: “Deny that which is not explicitly permitted” 6 April 2001 86 Firewall Policy Connection requirements should be analyzed and committed to writing l For each external network (internet, corporate), define and document allowable connection types and destinations. l For an internal network (DMZ), allowable connection types and destinations are defined on a per-machine basis rather than per-network. The policy usually translates quite literally into the router and firewall configuration files
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 87 Firewall Architecture Router Firewall Host Internet Corporate Users DMZ
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 88 Firewall Architecture Each section of the network is on its own physical network segment. l Firewall machine contains multiple network interfaces. Network partitioning l Internet (dial-in/ISDN traffic also falls into this category) l Corporate (serves company sites) l DMZ (houses services visible to external Internet)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 89 Firewall Impact on Application Design Perimeter controls may constrain some application designs, e. g. : l Downloading Java applets (may be forbidden by firewall policy) l Use of IIOP (may be prevented or firewall may not provide sufficiently fine-grained control) l Management of port numbers (proxy firewalls change source port numbers) l Use of File Transfer Protocol (FTP) (reverse connection) l Development of custom protocols (unavailability of proxies) …this can and will occur at the end user’s network: Web application developers, take note!
Ten Tough Questions to Ask Your Developers About Security and the Web Remember the principle of easiest penetration ! 6 April 2001 90 Perimeter Control Requires Hardened Platforms Perimeter control depends on the security of the underlying operating systems that host critical software components l Firewalls and authentication servers run on common operating systems (e. g. , Unix, NT) l Most operating systems are not secure in their factory-default configuration
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 91 Hardening an Operating System -A Few Examples l Change default passwords (and IDs if possible) l Check permissions, ownership on kernel files l Remove all unnecessary services l l Ex: TFTP, SMTP Tighten security on necessary components l Ex: Anonymous FTP l Double-check “trust” relationships (rlogin, NFS mounts, etc. ) l Apply vendor fixes l Monitor vendor security postings, bug alerts, emergency response alerts
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 92 Question #6 Can I trust my most sensitive data to the Web? Yes, with some conditions: l Ensure that a compelling business need exists l Take appropriate precautions l Understand HTTP authentication and its limits l Use SSL l Distrust client-supplied data l Protect your Web server
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 93 The Relationship Between HTTP and the Web HTTP (Hyper. Text Transport Protocol) is the mechanism by which files (HTML and otherwise) are transferred via the Web. l Protocol originally developed to deliver hyperlinked static information to readers l Server-side capabilities allow the delivery of dynamic content l Additional functionality has been added by most browser manufacturers to allow the user to interact with server-delivered content
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 94 HTTP Protocol Basics Each named file is a separate transaction (pages, graphics within a page, etc. ) Protocol is stateless; server doesn’t know if you’ve contacted it before, nor does it know if you’ll contact it again l Recent versions of the HTTP protocol are beginning to maintain open connections between client and server, though this is done for efficiency, not security HTTP provides for simple authentication of the user to the server
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 95 HTTP and the Web: Authentication Stateless nature of HTTP presents a big problem for authentication. l How do we require user ID/password from the user without requiring it for every single page (and graphic on these pages) accessed by the user? l As it turns out, the HTTP server does require authentication information for every single protected element accessed. l Browser behavior helps us out; authentication information is cached and re-presented to every subsequent access to the same server in the same browsing session.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 96 Implementing “Sessions” Using HTTP Many Web applications require a longlived session HTTP requests may be logically associated with a session l By authentication information l But, cached authentication information can make this approach risky l By using hidden fields or cookies l By using hybrid approaches
Ten Tough Questions to Ask Your Developers About Security and the Web A slightly newer version of SSL is known as TLS (transport layer security) 6 April 2001 97 SSL and HTTP SSL (Secure Sockets Layer) allows secure communication between client and server. l Provides confidentiality between client and server (prevents eavesdropping) l Provides integrity protection (prevents unauthorized modification of data in transit) l Combination of certificate verification and key exchange prevents spoofing, eavesdropping, midstream tampering l SSL operates below the application level; HTTP is unaltered
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 98 SSL Protocol Issues Key Length - export laws now largely lifted Key Management l Thoroughness of CA’s identification verification l Certificate revocation l Certificates still password protected on client side
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 99 Client-Server Architecture Considerations l Client software is especially vulnerable to misuse l Don’t interpret security-sensitive information on the client side (or even store it there prior to interpretation); server should verify authentication/authorization l Server can pass a token back to the client for presentation at a later time. Server should reverify the re-presented token (at time of use)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 100 Basic Server Recommendations l Do not run servers as root l Manage server file permissions l Use chroot() l Manage the risk of user-maintained directories l Disable server-side includes l Manage the risk of automatic directory displays l Prevent ftp users from uploading data readable to the http server l Use SSL l Integrate strong authentication l Be realistic about content restrictions by IP address
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 101 Server Extensions Application extensions to Web servers provide Web-server/application integration l CGI scripts l Cold Fusion l mod_perl l mod_php l JServ All of these extensions run code at the server and are therefore a potential entry point for attackers.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 102 Follow-up Question Is it safe to use mobile code such as Java or Active. X? Yes, if you’re careful: l Most of the risk is actually at the client, not the server l The server must--as always--distrust data originating at the client l All involved must recognize the risks of implementation errors
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 103 Java, Active. X, and Client-side Scripting Languages l Java applets (downloaded from the Web) are subject to “sandbox” security controls l Signed applets provide a mechanism for bettercontrolled access to the client machine’s operating system l Active. X controls have no restrictions; publisher accountability is provided through digitallysigned control code l Client-side scripting languages run within the confines of a sandbox. Source code for scripts is readily available to the end user
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 104 Question #7 What role does encryption play in my security posture? (What’s all this “certificate” stuff? )
6 April 2001 105 Ten Tough Questions to Ask Your Developers About Security and the Web Encryption Techniques Symmetric l The same key is used for encryption and decryption l The key must be kept secret l All communicating parties share a secret key (which can be troublesome if the number of parties is large)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 106 Public-Key Encryption Public-key encryption works around some of the limitations of symmetric-key algorithms. l The key consists of two different parts: public and private l The public key is not security-sensitive l It can be shared with any communication participant; or, l It can be posted in a public or semi-public directory l The private part is security-sensitive; it is not shared with anyone l Messages encrypted with the public key can only be decrypted with the private key, and vice versa l Most notable examples: l RSA (Rivest-Shamir-Adelman) l Elliptic-curve
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 107 Public-Key and Symmetric-Key Cryptosystems Are Usually Combined For Efficiency l A secret key (known as a session key) is randomly generated, then sent securely using the public-key system The session key can then be used to exchange private messages “message” Encrypt session key using the receiver’s public key. Sender Decrypt session key using the receiver’s private key. “message” Receiver “nfttbhf”
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 108 Digital Signatures Secure hash values (difficult-to-forge checksums) and public-key encryption form the basis for digital signatures Bind the signer to the document l The public key corresponds only to the private key used by the sender Enable detection if either the signature or the document is changed l Changes in the document will render the hash invalid l Changing the signature will render either the hash or the public key invalid
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 109 Non-Repudiation One special feature of digital signatures is that they can: l Ensure the identity of the sender of a message l Ensure that the sender cannot later deny signing the message
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 110 A Problem With Public-Key Encryption In order to ensure privacy and authenticity, one must know the public key of each correspondent. l Verifying authenticity of public keys is troublesome; same basic secure-channel problem as with secret-key encryption l Verification must be done individually for each correspondent
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 111 Certificates A certificate is a public key to which a digital signature has been affixed. This allows a trusted third party (a certificate authority) to act as a notary for public keys: l CA ascertains identity in some fashion l CA encrypts a secure hash of the sender’s public key using the CA’s private key l Receiver can verify this if CA’s public key is wellknown l Alterations cause the secure hash to fail, so sender can’t cheat l CA can’t cheat either, since it never has sender’s private key l CA only certifies public key, not individual messages
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 112 A Certificate Authority Provides: l Process for validating identity of certificate holder (for using the subject name) l Means for generating and verifying signatures l Registration and repository of certificates l Process for revoking and reissuing certificates l Process for confirming or denying the validity of a certificate The processes associated with CA management are far more complex than the technology underlying them!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 113 Private Certificate Authorities Some organizations choose to act as their own certificate authorities. This gives them: l Increased control over verification process l Ability to bind certificates to an individual’s role rather than simply identity l Flexibility to embed additional secure data within the certificate
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 114 Private Certificate Authorities Technical requirements are simple (certificate generation system) l Open. SSL has all of the tools one needs Procedural requirements are complex l Administration, key generation, revocation process, liability concerns, etc. l In short: consult with an expert; mistakes are not easy to undo once made!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 115 Question #8 As our business needs change, will my security be strong enough, yet flexible enough to grow/expand/evolve? It can be. Good design makes it easier.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 116 Basic Principles Apply More Than Ever Several principles are particularly important when considering the evolution of an application or system of applications. l Principle of least privilege: each component should be allowed to perform only the functions necessary to do its job l Separation of privilege: where multiple application components can verify permissions, do so. l Economy of mechanism: keep it simple!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 117 Early Design Decisions Matter The right time to think about expansion and integration is during the design of the initial application. l Isolate functions that might be common to more than one application l Document your design decisions l Note the placement and handling of securitysensitive information
6 April 2001 118 Ten Tough Questions to Ask Your Developers About Security and the Web Good And Bad Designs Authentication User Interface Customer data management Business logic Monolithic application: l Embedded application logic is difficult to separate from other functional components l Reusability is low l Difficult to enforce principle of least privilege Business logic Customer data management
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 119 Good And Bad Designs Authentication User Interface Business logic Customer data management Business logic Component software: Customer data management l One component per function l High reuse l Principle of least privilege is easy to implement
6 April 2001 120 Ten Tough Questions to Ask Your Developers About Security and the Web Evolution of a Bad Design User Interface Authentication Customer data management Business logic Each application does the same things a bit differently. l Bad for security Authentication User Interface Bad for the user l Business logic Customer data management Business logic
6 April 2001 121 Ten Tough Questions to Ask Your Developers About Security and the Web Evolution of a Good Design User Interface Business logic Authentication Business logic Customer data management Modular applications share security-sensitive and UI components. l Users are presented with a common interface l Security-sensitive code is isolated (easier to verify; insider attacks are much more difficult; layered architecture permits security in depth)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 122 Question 9 What if something goes wrong? The answer you don’t want to hear: “Panic!” The answer you do want to hear: “We will follow our Incident Response Plan. ”
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 123 Incident Response Planning Plan for an information security breach before it occurs Create an incident response team Put detection measures in place Decide how to respond to different situations Determine clear lines of authority Practice the plan Update the plan regularly Detect React Recover
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 124 Incident response team members Incident Response Manager l Leads the incident response team l Decides how to react l Has firm backing of, and reports to, senior management l Understands the value of assets and can lead team in determining loss l Ensures proper coordination across company and with any effected partners or customers
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 125 Incident Response Team Members (Continued) Technical Advisor l Incident Response Manger’s single point-ofcontact for resolving technical issues l Liaison to system administrators and operators of effected systems l Must be knowledgeable about key systems l Needs sharp technical skills
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 126 Incident Response Team Members (Concluded) Legal Counsel l Understands issues of liability and prosecution l Advises Incident Response Manager in dealings with law enforcement agencies l Serves as custodian of evidence gathered and documentation generated by the team Public Relations Specialist l Added to team if a penetration is verified l Responsible for managing external communications
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 127 Detection How will you know there is a problem? l An administrator might find an intrusion in progress l An administrator might deduce that an intrusion has occurred l l Detection is often the most difficult part of incident response. Entries in security log files l l Damage, deletion, or misuse of protected assets Unexplainable entries in accounting files You might be told that you have a problem l Users l Third parties (other admins, law enforcement, press) l Perpetrator
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 128 Key Resources for Incident Detection l Secure system baseline l Log files l System diagnostic programs l Security programs l Diagnostics (e. g. , integrity checkers, port monitors) l Detect Intrusion detection software Recover Well trained customer service representatives l React l Security-aware employees l Proactive intelligence gathering
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 129 React (Continued) l Keep a reasonably low profile l l Follow the plan! l l Detect l React Recover l Strictly enforce need-to-know rules Should a law enforcement agency be contacted? Should the effected system be isolated immediately, or should the team try to learn more about the attacker? Does this incident map to an existing scenario? Document everything (but not on the effected network, and not via email to or through any effected systems)
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 130 React (Continued) Don’t overreact l Detect Establish groups of security-related events and determine when they should cause an alarm to be raised Sample guidelines for activating the Incident Response Team: l Level 1: Random or sporadic events l React l Recover Examples: User entering a bad password, user accessing an invalid URL, user trying to access an unavailable service Action: Keep records and report regularly, but do not activate team
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 131 React (Continued) Sample guidelines for activating the Incident Response Team (continued) l Level 2: Suspicious system behavior l Detect l React Recover Examples: Unexpected processes running on a system, modified or missing executable or log file, repeated crashes, user complaints Action: System admins should investigate. Coordinate with Technical Advisor, but do not activate full team unless a penetration is verified
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 132 React (continued) Sample guidelines for activating the Incident Response Team (continued) l Level 3: System scanning and/or probing l l Detect l Recover Action: Consider the activity the beginning of an attack. Inform the Incident Response Manager Level 4: Denial of service l React Examples: Systematic password guessing, port scanning, extensive attempts to access invalid URLs on public server l Examples: Overflowing connection buffers Actions: Inform the Incident Response Manger, who will activate the full team. Be prepared to handle a highly visible incident.
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 133 React (Concluded) Sample guidelines for activating the Incident Response Team (Concluded) l Level 5: Confirmed penetration l Detect React Recover l Examples: Third party notification, detection of intrusion in progress Action: Inform the Incident Response Manager, who should activate the full team and follow the plan
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 134 Recover l l Detect React Recover Restore the system from the protected baseline Analyze the attack to determine new preventive measures
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 135 Question 10 How do I proceed from here?
6 April 2001 136 Ten Tough Questions to Ask Your Developers About Security and the Web How is System Security Achieved? . . . by taking a cohesive enterprise-wide view of system security. . . Security Architecture Security Components Security Engineering Rules Enforcement Monitoring Policy Procedures Awareness Assessments Penetration Management and. . .
How is System Security Achieved? . . . by recognizing that “the system” is more than just hardware and software. Hiring practices Facility access Critical component protection l ne on s rs ol Pe ontr C Ph Co ysic ntr al ols Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 137 Management Oversight Corporate commitment Background checks Periodic reviews
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 138 Ask Questions Throughout the System Life-Cycle Design Impleme nt Test Producti on Can I trust my most sensitive data to the How Web? if something goes wrong? do we use What encryption? Where can I find a copy of our security policy? principles do our designers and What builders Have we secured our perimeter? apply? How can our application evolve securely? How are principles translated into practice? Where can I find a copy of our security policy? How are principles translated into Have we secured our perimeter? practice? What if something goes wrong? Have we secured our perimeter? Where can I find a copy of our security policy? How can our application evolve securely?
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 139 Ask Questions Throughout the System Life-Cycle (Concluded) Tough questions need to be asked at each phase of the system’s development. l Many questions need to be asked at multiple phases of the development process l Of particular importance: make sure that what is designed is what gets built l l l security precautions are frequently disregarded during the implementation process absent oversight Modifications to original design need to be assessed for security significance Don’t be afraid to ask multiple people the same questions!
Ten Tough Questions to Ask Your Developers About Security and the Web 6 April 2001 140 A Final Note Bear in mind that Web application security, like any other component of modern application design, is an iterative process! l New threats and countermeasures appear on a daily basis l Value of data being protected changes over time l Evolving application and user requirements impact security requirements l Over time, even some of the questions to ask may change. Universal awareness of the need for security will ensure that the right questions get asked (and answered) in the future.
Скачать презентацию Ten Tough Questions to Ask Your Developers About
1287ff44d254e2b985466bb572244a8a.ppt