ten tough questions to ask your developers about security and the web
DESCRIPTION
Ten Tough Questions to Ask Your Developers About Security and the Web. Phil Wherry ([email protected]) ApacheCon 2001 Santa Clara, California. About the Course. Goals Identify a short list of key questions to answer when developing secure Web-based systems - PowerPoint PPT PresentationTRANSCRIPT
Ten Tough Questions to Ask Your Developers About Security and
the Web
Phil Wherry([email protected])ApacheCon 2001Santa Clara, California
6 April 2001 2
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 3
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 4
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 5
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Information Security is an
Enabling Technology
Privacy of transactions
Host data integrity
Authenticity of buyer/seller
Access restrictions
Guaranteed transactions
Reliable transport
Assured service Accountability
Availability
Integrity
Confidentiality
Security technologyprovides…
Security technologyprovides…
… to satisfy critical business needs
… to satisfy critical business needs
6 April 2001 6
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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?
6 April 2001 7
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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 ?
6 April 2001 8
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #1
What do I protect, and why?
6 April 2001 9
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
A financial services organization providing online home banking, equity trading, and credit card customer service
A financial services organization providing online home banking, equity trading, and credit card customer service
6 April 2001 10
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
Customers use Web browsers to interact with bank services. They connect to the bank via the Internet.
6 April 2001 11
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
The bank provides a number of different services to its customers via a set of Web servers.
6 April 2001 12
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
Customer information (account balances, etc.) resides in databases on the bank’s mainframe systems.
6 April 2001 13
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
Communication between the Web servers and the mainframes takes place over the bank’s internal network.
6 April 2001 14
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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
6 April 2001 15
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Typical System Threats
Hardware Denial of Service
Theft
Software Theft
Deletion
Modification
Data Fabrication
Modification
Interception
Loss
Security in Computing, C.P. Pfleeger, 1997
6 April 2001 16
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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
6 April 2001 17
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Countermeasures
Anything that reduces a vulnerability Software
Hardware
Technique
Procedure
Action
Terminology
6 April 2001 18
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 19
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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...
6 April 2001 20
Ten Tough Questions to Ask Your Developers About Security and the Web
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 are mirrored at www.attrition.org
6 April 2001 21
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 22
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
Understanding basic types of misuse is important fordeveloping enterprise-wide countermeasures
6 April 2001 23
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Examples of Computer Misuse
(Concluded)
Masquerading Impersonation
Spoofing
Playback
Bypassing controls Trapdoors
Active attacks
Malicious programs Trojan horses
Viruses
Worms
6 April 2001 24
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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
6 April 2001 25
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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
6 April 2001 26
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Benefits of Formal Risk Analysis
Helps ensure completeness of design
Provides a documented basis for making balanced decisions
Helps justify security investments
6 April 2001 27
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 28
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 29
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #2
Answer: It should be everywhere On your intranet
In the new employee folder
Attached to annual employee assessments
On your developer’s desktops...
Where can I find a copy of our security policy?
(What do you mean, we don’t have a policy?!?)
6 April 2001 30
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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.
Policies must be realistic, useful, maintainable, and widely disseminated.
6 April 2001 31
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 32
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Typical Security Policies
Military security policies (label based)
Commercial security policies
Transaction-based security policies (Clark-Wilson)
6 April 2001 33
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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)
Top Secret
Secret
Confidential
Unclassified
Most Sensitive
Least Sensitive
Sensitivity Levels
Label-based policies
In actual military policies, other labels are also associated with data.
6 April 2001 34
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web “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
6 April 2001 35
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 36
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Transaction-based Security
Policies (Continued)
Precise steps must be performed in order, by authorized individuals, to constitute a well-formed transaction
Accounting Dept.Accounting Dept.
1. Order Supplies
Purchase Order
3. Receive supplies
Delivery receipt
2. Vendor ships supplies
Invoice
4. Send payment
Payment
6 April 2001 37
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 38
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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.
6 April 2001 39
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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?
6 April 2001 40
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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 testingPenetration testingOngoing “white hat” assessments
6 April 2001 41
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Security Functional Testing
Attempt to demonstrate that security services and mechanisms are: Correct
Always invoked
Tamper-resistant
Clear security policy and requirements are critical
6 April 2001 42
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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.
6 April 2001 43
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 44
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 45
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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?)
6 April 2001 46
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #3
What principles do our designers and developers apply when building a secure system?
6 April 2001 47
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Answer #3
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
6 April 2001 48
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Adequate Protection
Resources must only be protected until they lose their value
Resources must be protected to a degree consistent with their value
6 April 2001 49
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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
6 April 2001 50
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
6 April 2001 51
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Fail-Safe Defaults
Base security decisions on permission rather than exclusion By default, access should always be denied
Explicit actions should be required to grant access
Use fail-safe defaults in the protection mechanism’s external appearance and internal implementation
6 April 2001 52
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Consider this permission test pseudocode:
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!
Fail-Safe Defaults (Concluded)
if user_allowed(x) perform_ops();else deny_ops();
if user_denied(x) deny_ops();else perform_ops();
6 April 2001 53
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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 The potential for misbehavior (accidental or
malicious) to compromise the integrity of the application or system is minimized
You can’t abuse what you don’t have.
6 April 2001 54
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Separation of Privilege
A protection mechanism that requires two conditions to be met for access is better than a mechanism that requires only one Multiple conditions can be constructed such
that no single implementation error, accident, deception, or breach of trust will compromise security
Examples: Multi-party concurrence to perform a
transaction
Firewall + host-level hardening + application security
6 April 2001 55
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Economy of Mechanism
Protection mechanisms should be small, simple, and straightforward Reduces the likelihood of errors in development
or future maintenance
Ideally, it should be possible to easily determine the operation of a protection mechanism by a simple reading of the code.
6 April 2001 56
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Open Design
The design of protection mechanisms should not be kept secret Extensive review will improve the design
Skeptics can convince themselves of the adequacy of the security mechanisms
Secrets are very hard to keep from those determined to get them
Open-source software has a huge advantage in this respect.
“Security by Obscurity” is a dangerous design philosophy“Security by Obscurity” is a dangerous design philosophy
6 April 2001 57
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Psychological Acceptability
Make protection mechanisms easy to use 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: Unnecessary
Too hard or too complicated
Too time consuming
Too intrusive
6 April 2001 58
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #4
How do our application developers translate from policy and principle to practice?
6 April 2001 59
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Answer #4
How do our application developers translate from policy and principle to practice? By understanding our security requirements and
the techniques for satisfying those requirements
By carefully partitioning our applications into trusted and untrusted components (Security Architecture)
By employing a set of “best practices” for implementation
Defensive programming
Defensive networking
6 April 2001 60
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Selected Security Issues:
Financial Services Scenario
Who is the user?
Is the user allowed to perform an action?
How can integrity/privacy of information in transit be protected?
How can a record be kept of actions taken by the user (and the system on behalf of the user)?
Internal authorization: credit card app has no business touching equities data, for example.
How can the integrity of the audit trail be maintained?
6 April 2001 61
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web From Policy to Practice
Security policySecurity policy
Security principlesSecurity principles
Security architectureSecurity architecture
Security practiceSecurity practice
6 April 2001 62
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Trusted vs. Untrusted Components
Trusted components Responsible for maintaining application security
Misbehavior of trusted components can compromise overall application/system security
Typical examples of trusted components: authentication server, authorization module, transaction processor
Untrusted components Not responsible for security of application
Misbehavior can degrade or deny service, but will not compromise application/system security
6 April 2001 63
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Client/Server Designs
The server can be made much more secure than the client Client systems may have weak operating
systems
Client systems are subject to alteration by the end user (or programs the user runs)
Client systems may be left unattended
Web developers generally have no control over client configuration
Don’t trust the client!
6 April 2001 64
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Centralization of Security
Authority
Security components are difficult to develop and verify
Multiple parallel security entry points into an application or system increases risk
6 April 2001 65
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Centralization of Security
Authority (Concluded)
Centralization of security authority can minimize the number of potential entry points Test/debug is consequently simplified: smaller
code base to verify
More coherent administration is usually possible
Security designers can better focus on critical areas
6 April 2001 66
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web The Limits of Centralization
Centralization of security authority only makes sense within a trust domain
Where trust domains differ, each should enforce security controls
Judicious use of client-side cookies and cryptography can make this process transparent.
6 April 2001 67
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web From Policy to Practice
Security policySecurity policy
Security principlesSecurity principles
Security architectureSecurity architecture
Security practiceSecurity practice
6 April 2001 68
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Few Best Practices
Design before you start
Limit the flexibility of security-critical code
Use native capabilities where possible
Don’t make assumptions about input data content
Initialize programs correctly
Log useful information
6 April 2001 69
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Few Best Practices (Continued)
Protect against object reuse
Use chroot(), or similar capabilities, where possible
Don’t depend on the environment
Check return codes
Test permissions as they’re used
Check buffer boundaries
Consider race conditions
6 April 2001 70
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Few Best Practices (Continued)
Use temporary files properly
Handle multiple instances of the same application running simultaneously
Ensure security of persistent storage
Use one-way hashes to protect data
Carefully create random numbers
Plan to fail
6 April 2001 71
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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? Data validation should be done at the server
(though client-side data validation is useful in addition to server-side checking)
Never rely on the contents of HTTP cookies, hidden values in forms, etc.
Log exceptions; this is useful for debugging as well as security. Be sure logging doesn’t introduce additional risks, though!
A closer look at a few best practices...
6 April 2001 72
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Above All Else: Do Not Make
Assumptions About Input Data
Be especially careful when passing user-supplied data to shells and/or databases. Enumerate characters to be allowed
Enforce maximum length
Log exceptions
6 April 2001 73
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Check Buffer Boundaries
Consider this code fragment…
(from Unix fingerd source, circa 1988)
Problems… fingerd runs as root (a fully-privileged user).
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
char line[512];…line[0] = ’\0’;gets(line);
A closer look at a few best practices...
6 April 2001 74
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Check Buffer Boundaries
Assume any operating system function can be subverted by a buffer overrun
In recent versions of Unix, dozens of system calls have been susceptible to overrun
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
Manage buffer lengths carefully before handing control to any external code
6 April 2001 75
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Random Numbers
Random numbers are often used for things like temporary session keys If the random numbers can be predicted, the need to
exhaustively search a keyspace can be eliminated (or the problem greatly reduced)
Most operating-system random number routines are weak
Choosing good seed values is hard 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
A closer look at a few best practices...
6 April 2001 76
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #5
How have we secured our electronic perimeter?
6 April 2001 77
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Answer #5
How have we secured our electronic perimeter? By developing a security perimeter based on
our security policy and our chosen network architecture
By selecting a firewall based on our security needs and IT infrastructure
By integrating authentication and other security services
By ensuring that the hosts visible at our perimeter have been “hardened”
6 April 2001 78
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web System and Application Security
System Security Architecting and deploying the hardware and
software components of a distributed system to ensure a reasonable degree of security
Application Security Designing and implementing security controls
into application software
6 April 2001 79
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Revisited
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
Provide a first line of defense for resources accessible via the internet
6 April 2001 80
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Revisited
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
Control remote access to the basic infrastructure
Remember the Principle of Easiest Penetration !
6 April 2001 81
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Financial Services Scenario
Revisited
Credit card app
Equity trading app
Home banking app
Internal network
Customers connect via the Internet
Customer account data
Customer account data
A coherent, enterprise-wide security perimeter is needed
6 April 2001 82
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Why Use Perimeter Controls? To establish a “zone of control” around your
enterprise
To enforce: Who - may use your networks
What - actions they may perform
Where - on what systems
When - (time of day, from what locations, using what program etc.)
And to monitor their actions
Perimeter controls may impact application design. Plan ahead!
6 April 2001 83
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Characteristics of a Good Security
Perimeter
Limited and controlled connectivity
Minimize “islands of infosec”
Coherent network addressing scheme
Makes it easier to partition the network into segments with different protection requirements
Makes security-related routing decisions possible
Simplifies security administration
Integrated point solutions
Cohesive, holistic view
6 April 2001 84
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Mechanisms for Implementing a
Security Perimeter
Firewalls
Remote access
Authentication mechanisms
Hardened operating systems
6 April 2001 85
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Firewalls
Simple packet filtering e.g., Cisco routers, tcp_wrappers
Stateful filtering e.g., Checkpoint’s Firewall-1
Proxy-based e.g., Gauntlet
…the lines of distinction between these basic types are often blurry.
6 April 2001 86
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Firewall Policy
Connection requirements should be analyzed and committed to writing For each external network (internet, corporate),
define and document allowable connection types and destinations.
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
Fundamental policy rule: “Deny that which is not explicitly permitted”
6 April 2001 87
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Firewall Architecture
Router Router
FirewallHost
Internet CorporateUsers
DMZ
6 April 2001 88
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Firewall Architecture
Each section of the network is on its own physical network segment. Firewall machine contains multiple network
interfaces.
Network partitioning Internet (dial-in/ISDN traffic also falls into this
category)
Corporate (serves company sites)
DMZ (houses services visible to external Internet)
6 April 2001 89
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Firewall Impact on Application
Design
Perimeter controls may constrain some application designs, e.g.:
Downloading Java applets (may be forbidden by firewall policy)
Use of IIOP (may be prevented or firewall may not provide sufficiently fine-grained control)
Management of port numbers (proxy firewalls change source port numbers)
Use of File Transfer Protocol (FTP) (reverse connection)
Development of custom protocols (unavailability of proxies)
…this can and will occur at the end user’s network: Web application developers, take note!
6 April 2001 90
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Perimeter Control Requires
Hardened Platforms
Perimeter control depends on the security of the underlying operating systems that host critical software components Firewalls and authentication servers run on
common operating systems (e.g., Unix, NT)
Most operating systems are not secure in their factory-default configuration
Remember the principle of easiest penetration !
6 April 2001 91
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Hardening an Operating System --
A Few Examples
Change default passwords (and IDs if possible)
Check permissions, ownership on kernel files
Remove all unnecessary services Ex: TFTP, SMTP
Tighten security on necessary components Ex: Anonymous FTP
Double-check “trust” relationships (rlogin, NFS mounts, etc.)
Apply vendor fixes
Monitor vendor security postings, bug alerts, emergency response alerts
6 April 2001 92
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question #6
Can I trust my most sensitive data to the Web?
Yes, with some conditions: Ensure that a compelling business need exists
Take appropriate precautions
Understand HTTP authentication and its limits
Use SSL
Distrust client-supplied data
Protect your Web server
6 April 2001 93
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web The Relationship Between
HTTP and the Web
HTTP (HyperText Transport Protocol) is the mechanism by which files (HTML and otherwise) are transferred via the Web. Protocol originally developed to deliver
hyperlinked static information to readers
Server-side capabilities allow the delivery of dynamic content
Additional functionality has been added by most browser manufacturers to allow the user to interact with server-delivered content
6 April 2001 94
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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 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
6 April 2001 95
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web HTTP and the Web:
Authentication
Stateless nature of HTTP presents a big problem for authentication. 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?
As it turns out, the HTTP server does require authentication information for every single protected element accessed.
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.
6 April 2001 96
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Implementing “Sessions” Using
HTTP
Many Web applications require a long-lived session
HTTP requests may be logically associated with a session By authentication information
But, cached authentication information can make this approach risky
By using hidden fields or cookies
By using hybrid approaches
6 April 2001 97
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web SSL and HTTP
SSL (Secure Sockets Layer) allows secure communication between client and server. Provides confidentiality between client and
server (prevents eavesdropping)
Provides integrity protection (prevents unauthorized modification of data in transit)
Combination of certificate verification and key exchange prevents spoofing, eavesdropping, midstream tampering
SSL operates below the application level; HTTP is unaltered
A slightly newer version of SSL is known as TLS (transport layer security)
6 April 2001 98
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web SSL Protocol Issues
Key Length - export laws now largely lifted
Key Management Thoroughness of CA’s identification verification
Certificate revocation
Certificates still password protected on client side
6 April 2001 99
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Client-Server Architecture
Considerations
Client software is especially vulnerable to misuse
Don’t interpret security-sensitive information on the client side (or even store it there prior to interpretation); server should verify authentication/authorization
Server can pass a token back to the client for presentation at a later time. Server should re-verify the re-presented token (at time of use)
6 April 2001 100
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Basic Server Recommendations
Do not run servers as root
Manage server file permissions
Use chroot()
Manage the risk of user-maintained directories
Disable server-side includes
Manage the risk of automatic directory displays
Prevent ftp users from uploading data readable to the http server
Use SSL
Integrate strong authentication
Be realistic about content restrictions by IP address
6 April 2001 101
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Server Extensions
Application extensions to Web servers provide Web-server/application integration CGI scripts
Cold Fusion
mod_perl
mod_php
JServ
All of these extensions run code at the server and are therefore a potential entry point for attackers.
6 April 2001 102
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Follow-up Question
Is it safe to use mobile code such as Java or ActiveX?
Yes, if you’re careful: Most of the risk is actually at the client, not the
server
The server must--as always--distrust data originating at the client
All involved must recognize the risks of implementation errors
6 April 2001 103
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Java, ActiveX, and Client-side
Scripting Languages
Java applets (downloaded from the Web) are subject to “sandbox” security controls
Signed applets provide a mechanism for better-controlled access to the client machine’s operating system
ActiveX controls have no restrictions; publisher accountability is provided through digitally-signed control code
Client-side scripting languages run within the confines of a sandbox. Source code for scripts is readily available to the end user
6 April 2001 104
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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
Ten Tough Questions to Ask Your Developers About Security and the Web Encryption Techniques
Symmetric The same key is
used for encryption and decryption
The key must be kept secret
All communicating parties share a secret key (which can be troublesome if the number of parties is large)
6 April 2001 106
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Public-Key Encryption Public-key encryption works around some of the limitations of symmetric-key algorithms. The key consists of two different parts: public and private
The public key is not security-sensitive It can be shared with any communication participant; or,
It can be posted in a public or semi-public directory
The private part is security-sensitive; it is not shared with anyone
Messages encrypted with the public key can only be decrypted with the private key, and vice versa
Most notable examples: RSA (Rivest-Shamir-Adelman)
Elliptic-curve
6 April 2001 107
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Public-Key and Symmetric-Key Cryptosystems Are Usually Combined For Efficiency
A secret key (known as a session key) is randomly generated, then sent securely using the public-key system
Decrypt sessionkey using thereceiver’s privatekey.
ReceiverReceiverSenderSender
Encrypt sessionkey using thereceiver’s publickey.
““message”message” ““message”message”
““nfttbhf”nfttbhf”
The session key can then be used to exchange private messages
6 April 2001 108
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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 The public key corresponds only to the private
key used by the sender
Enable detection if either the signature or the document is changed Changes in the document will render the hash
invalid
Changing the signature will render either the hash or the public key invalid
6 April 2001 109
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Non-Repudiation
One special feature of digital signatures is that they can: Ensure the identity of the sender of a message
Ensure that the sender cannot later deny signing the message
6 April 2001 110
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Problem With Public-Key
Encryption
In order to ensure privacy and authenticity, one must know the public key of each correspondent. Verifying authenticity of public keys is
troublesome; same basic secure-channel problem as with secret-key encryption
Verification must be done individually for each correspondent
6 April 2001 111
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
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: CA ascertains identity in some fashion
CA encrypts a secure hash of the sender’s public key using the CA’s private key
Receiver can verify this if CA’s public key is well-known
Alterations cause the secure hash to fail, so sender can’t cheat
CA can’t cheat either, since it never has sender’s private key
CA only certifies public key, not individual messages
6 April 2001 112
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Certificate Authority Provides:
Process for validating identity of certificate holder (for using the subject name)
Means for generating and verifying signatures
Registration and repository of certificates
Process for revoking and reissuing certificates
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!
The processes associated with CA management are far more complex than the technology underlying them!
6 April 2001 113
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Private Certificate Authorities
Some organizations choose to act as their own certificate authorities. This gives them: Increased control over verification process
Ability to bind certificates to an individual’s role rather than simply identity
Flexibility to embed additional secure data within the certificate
6 April 2001 114
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Private Certificate Authorities
Technical requirements are simple (certificate generation system) OpenSSL has all of the tools one needs
Procedural requirements are complex Administration, key generation, revocation
process, liability concerns, etc.
In short: consult with an expert; mistakes are not easy to undo once made!
6 April 2001 115
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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.
6 April 2001 116
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Basic Principles Apply
More Than Ever
Several principles are particularly important when considering the evolution of an application or system of applications. Principle of least privilege: each component
should be allowed to perform only the functions necessary to do its job
Separation of privilege: where multiple application components can verify permissions, do so.
Economy of mechanism: keep it simple!
6 April 2001 117
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Early Design Decisions Matter
The right time to think about expansion and integration is during the design of the initial application. Isolate functions that might be common to more
than one application
Document your design decisions
Note the placement and handling of security-sensitive information
6 April 2001 118
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Good And Bad Designs
Business logic
Authentication
Customer datamanagement
User Interface
Business logic
Authentication
Customer datamanagement
User Interface
Monolithic application: Embedded application logic is difficult to
separate from other functional components
Reusability is low
Difficult to enforce principle of least privilege
6 April 2001 119
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Good And Bad Designs
Business logic
Authentication
Customer datamanagement
User Interface
Business logic
Authentication
Customer datamanagement
User Interface
Component software: One component per function
High reuse
Principle of least privilege is easy to implement
6 April 2001 120
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Evolution of a Bad Design
Business logic
Authentication
Customer datamanagement
User Interface
Each application does the same things a bit differently.
Bad for the user
Bad for security
Business logic
Authentication
Customer datamanagement
User Interface
Business logic
Authentication
Customer datamanagement
User Interface
6 April 2001 121
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Evolution of a Good Design
Business logic
AuthenticationCustomer datamanagement
User Interface
Business logicBusiness logic
Modular applications share security-sensitive and UI components.
Users are presented with a common interface
Security-sensitive code is isolated (easier to verify; insider attacks are much more difficult; layered architecture permits security in depth)
6 April 2001 122
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web 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.”
6 April 2001 123
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Incident Response Planning
Plan for an information security breach before it occurs
Create an incident response teamPut detection measures in placeDecide how to respond to different situationsDetermine clear lines of authority
Practice the planUpdate the plan regularly
Detect React Recover
6 April 2001 124
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Incident response team members
Incident Response Manager Leads the incident response team
Decides how to react
Has firm backing of, and reports to, senior management
Understands the value of assets and can lead team in determining loss
Ensures proper coordination across company and with any effected partners or customers
6 April 2001 125
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Incident Response Team Members
(Continued)
Technical Advisor Incident Response Manger’s single point-of-
contact for resolving technical issues
Liaison to system administrators and operators of effected systems
Must be knowledgeable about key systems
Needs sharp technical skills
6 April 2001 126
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Incident Response Team Members
(Concluded)
Legal Counsel Understands issues of liability and prosecution
Advises Incident Response Manager in dealings with law enforcement agencies
Serves as custodian of evidence gathered and documentation generated by the team
Public Relations Specialist Added to team if a penetration is verified
Responsible for managing external communications
6 April 2001 127
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Detection
How will you know there is a problem? An administrator might find an intrusion in progress
An administrator might deduce that an intrusion has occurred
Damage, deletion, or misuse of protected assets
Entries in security log files
Unexplainable entries in accounting files
You might be told that you have a problem
Users
Third parties (other admins, law enforcement, press)
Perpetrator
Detection is often the most difficult part of incident response.
6 April 2001 128
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Key Resources for Incident
Detection
Secure system baseline
Log files
System diagnostic programs
Security programs
Diagnostics (e.g., integrity checkers, port monitors)
Intrusion detection software
Well trained customer service representatives
Security-aware employees
Proactive intelligence gathering
Detect
React
Recover
6 April 2001 129
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web React (Continued)
Keep a reasonably low profile
Strictly enforce need-to-know rules
Follow the plan!
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)
Detect
React
Recover
6 April 2001 130
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web React (Continued)
Don’t overreact 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: Level 1: Random or sporadic events
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
Detect
React
Recover
6 April 2001 131
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web React (Continued)
Sample guidelines for activating the Incident Response Team (continued) Level 2: Suspicious system behavior
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
Detect
React
Recover
6 April 2001 132
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web React (continued)
Sample guidelines for activating the Incident Response Team (continued) Level 3: System scanning and/or probing
Examples: Systematic password guessing, port scanning, extensive attempts to access invalid URLs on public server
Action: Consider the activity the beginning of an attack. Inform the Incident Response Manager
Level 4: Denial of service Examples: Overflowing connection buffers
Actions: Inform the Incident Response Manger, who will activate the full team. Be prepared to handle a highly visible incident.
Detect
React
Recover
6 April 2001 133
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web React (Concluded)
Sample guidelines for activating the Incident Response Team (Concluded) Level 5: Confirmed penetration
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
Detect
React
Recover
6 April 2001 134
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Recover
Restore the system from the protected baseline
Analyze the attack to determine new preventive measures
Detect
React
Recover
6 April 2001 135
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web Question 10
How do I proceed from here?
6 April 2001 136
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web How is System Security
Achieved?
RulesRules
Policy
Procedures
Awareness
EnforcementEnforcement
Assessments
Monitoring
Penetration
Management
Security Architecture
Security Components
Security Engineering
...by taking a cohesive enterprise-wide view of system security...
and...
6 April 2001 137
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web How is System Security
Achieved? ...by recognizing that “the system” is more than just hardware and software.
Management
Phy
sica
l C
ontr
ols
Personnel
Controls
Facility access
Critical component protection
Hiring practices
Background checks
Periodic reviews
Oversight
Corporate commitment
6 April 2001 138
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Ask Questions Throughout the System Life-Cycle
Design
Implement
Test
Production
What if something goes wrong?
How can our application evolve securely?
How do we use encryption?Can I trust my most sensitive data to the Web?
Have we secured our perimeter?
How are principles translated into practice?
What principles do our designers and builders apply?
Where can I find a copy of our security policy?
How are principles translated into practice?Have we secured our perimeter?
Have we secured our perimeter?
What if something goes wrong?
Where can I find a copy of our security policy?
Where can I find a copy of our security policy?
What if something goes wrong?
How can our application evolve securely?
6 April 2001 139
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web
Ask Questions Throughout the System Life-Cycle (Concluded)
Tough questions need to be asked at each phase of the system’s development. Many questions need to be asked at multiple
phases of the development process
Of particular importance: make sure that what is designed is what gets built
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!
6 April 2001 140
Ten Tough Questions to Ask Your Developers About Security and the Web
Ten Tough Questions to Ask Your Developers About Security and the Web A Final Note
Bear in mind that Web application security, like any other component of modern application design, is an iterative process! New threats and countermeasures appear on a
daily basis
Value of data being protected changes over time
Evolving application and user requirements impact security requirements
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.