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

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 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 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 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

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 (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 Question #1

What do I protect, and why?

6 April 2001 9


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


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



Credit card app

Equity trading app

Home banking app

Internal network




Customers use Web browsers to interact with bank services. They connect to the bank via the Internet.

6 April 2001 11



Credit card app

Equity trading app

Home banking app

Internal network




The bank provides a number of different services to its customers via a set of Web servers.

6 April 2001 12



Credit card app

Equity trading app

Home banking app

Internal network




Customer information (account balances, etc.) resides in databases on the bank’s mainframe systems.

6 April 2001 13



Credit card app

Equity trading app

Home banking app

Internal network




Communication between the Web servers and the mainframes takes place over the bank’s internal network.

6 April 2001 14



Threats

Circumstance or event that could cause harm Human attacks

Inadvertent human errors

Software or hardware flaws

Natural disasters

Threats may be internal, external, or both

System threats may be against hardware, software, or data

Terminology

6 April 2001 15



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



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



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 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



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



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 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 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 Examples of Computer Misuse

(Concluded)

Masquerading Impersonation

Spoofing

Playback

Bypassing controls Trapdoors

Active attacks

Malicious programs Trojan horses

Viruses

Worms

6 April 2001 24



Risk Analysis

Goal: Apply cost-effective security controls where they are needed

General steps: Identify assets

Determine threat sources and vulnerabilities

Estimate likelihood of occurrence

Estimate losses

Consider potential countermeasures

Balance potential losses with cost of countermeasure

Deciding what to protect

6 April 2001 25



Risk Analysis Techniques

Formal Follow a well defined methodology for data

collection and analysis

Use specific valuations

Usually includes use of [expensive, proprietary] software tools

Informal Identify issues and potential responses

Select course of action based on experience

6 April 2001 26



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 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 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



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 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 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



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 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 “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 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



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



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 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



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 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 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



(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



(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 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 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



What principles do our designers and developers apply when building a secure system?

6 April 2001 47



Principles for building secure systems and applications Adequate protection

Easiest penetration

Complete mediation

Fail-safe defaults

Least privilege

Separation of privilege

Economy of mechanism

Open design

Psychological acceptability

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

6 April 2001 49



Easiest Penetration

An attacker will look for the weakest link

Examples A social engineering attack may be easier than

a technical attack

Intercepting an encryption key is probably easier than breaking the underlying encryption algorithm

Walking through an open back door (literally or figuratively) is easier than breaking down a locked front door

6 April 2001 50


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 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



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 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 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 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 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 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



How do our application developers translate from policy and principle to practice?

6 April 2001 59



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 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 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 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 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 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 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 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 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 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 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 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 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 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 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);


6 April 2001 74


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 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


6 April 2001 76



How have we secured our electronic perimeter?

6 April 2001 77



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 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



Revisited

Credit card app

Equity trading app

Home banking app

Internal network




Provide a first line of defense for resources accessible via the internet

6 April 2001 80



Revisited

Credit card app

Equity trading app

Home banking app

Internal network




Control remote access to the basic infrastructure

Remember the Principle of Easiest Penetration !

6 April 2001 81



Revisited

Credit card app

Equity trading app

Home banking app

Internal network




A coherent, enterprise-wide security perimeter is needed

6 April 2001 82



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 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 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 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 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



Firewall Architecture

Router Router

FirewallHost

Internet CorporateUsers

DMZ

6 April 2001 88



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 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 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 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



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 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 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 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 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 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 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 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 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 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 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 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



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 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



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



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 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 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 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



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 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 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 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



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 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 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 Good And Bad Designs

Business logic

Authentication

Customer datamanagement

User Interface

Business logic

Authentication


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 Good And Bad Designs

Business logic

Authentication


User Interface

Business logic

Authentication


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 Evolution of a Bad Design

Business logic

Authentication


User Interface

Each application does the same things a bit differently.

Bad for the user

Bad for security

Business logic

Authentication


User Interface

Business logic

Authentication


User Interface

6 April 2001 121


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 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 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



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 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 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 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 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 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



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



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 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 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 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 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?

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 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



Ask Questions Throughout the System Life-Cycle

Design

Implement

Test

Production


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?


How are principles translated into practice?Have we secured our perimeter?

Have we secured our perimeter?





How can our application evolve securely?

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. 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 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.

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

Documents

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