ece579s/7 #1 spring 2011 © 2000-2011, richard a. stanley ece579s computer and network security 7:...

ECE579S/7 #1 Spring 2011© 2000-2011, Richard A. Stanley

ECE579SComputer and Network Security

7: SSL/TLS, Trusted Systems and IDS’s

Professor Richard A. Stanley, P.E.


Last time...• Many ways to sneak into the computer -- not all of them

viruses -- and cause havoc• Many goals and objectives, from mischief to espionage• Tools exist to help manage the problem Computer

crime is a fast-growing area of illegal activity• Computers (and networks) are regulated by a large and

growing body of law• Both civil and criminal issues involved• Liability is a major consideration for any business or

practitioner


The Weakest Link

Consider alternativeswhen you plan yoursecurity measures,or your results may

look like this!

In other words, think like a crook!


If IPSec is So Good...

• Why do we need anything else?– One could also ask, if C++ is such a good

programming language, why do we need Java?– SSL provides another choice for achieving security

over insecure networks (e.g. Internet)

• Where they are:– IPSec operates at the network level– SSL operates at the transport level– Other protocols operate at the application level


Network Level Security

HTTP FTP SMTP

TCP

IP/IPSec


Transport Level Security

SSL / TLS

HTTP FTP SMTP

TCP

IP/(IPSec)


Application Level Security

TCP

IP/(IPSec)

Kerberos

S/MIME PGP SET

UDP

SMTP HTTP


What’s a Socket?

• The name, Secure Sockets Layer, implies we are securing something called a socket. What is that?

• Remember that TCP applications separate themselves by listening on one or more of 64K possible ports (i.e. addresses)

• A socket is a fully-specified TCP/IP address, e.g.10.1.7.203:80 or 192.168.5.7:23


Well-Known Ports

• Many common IP services operate on what are routinely called well-known ports– Port 80: HTTP– Ports 20, 21: FTP– Port 23: Telnet– Port 25: SMTP– Port 119: NNTP

• SSL operates on Port 443


What has TLS done for you lately?

• Why was SSL developed?– Privacy

• Netscape foresaw need for confidential sending of information

• However SSL does supply authentication and integrity as well

• What has SSL brought us?– e-commerce as we know it today

• Online banking

• Online shopping

• Online stock trading

• etc


SSL Factoids

• Developed by Netscape

• Current version is SSLv3, dates to mid-90’s

• Many efforts along the way to develop a multi-vendor approach, all of which have led to dead ends (i.e. Microsoft did not succeed in moving Netscape to their point of view)


SSL Provides

• Confidentiality– Using symmetric key cryptography

• Integrity– Using asymmetric key cryptography and

hashing

• Authenticity– Using digital signatures and certificates on

server, and optionally, on client side


SSL/TLS Timeline• Web only existed for a few short years prior to this form of

security

• Web Browser – 1990

• Netscape develops SSL – 1994

• IE adopts SSL – 1995

• Not much e-commerce pre 95


SSL Architecture

• Two layers of protocols on top of TCP– Top level

• SSL Handshake protocol

• SSL ChangeCipherSpec protocol

• SSL Alert protocol

– SSL Record Protocol


SSL Architecture Overview

SSL Record Protocol

SSL Alert HTTP

TCP

IP/(IPSec)

SSL CipherChange Spec

SSL Handshake

NB: This diagram does not infer the order in which the protocols are applied.


Sessions and Connections

• An SSL session is a client/server association– Created by Handshake protocol– Defined security parameters

• An SSL connection is a transport that provides a service (e.g., HTTP)– Connections are transient– Many connections can exist within a single session


SSL Handshake Protocol

• Most complex part of SSL

• Starts when client connects to server

• Sets up session protocols

• Selects crypto system to be used

• Authenticates client and server

• Sets up basis for shared secret key, the MasterSecret


SSL Handshake Overview(NB: Many details omitted)

Client Server

1. Supported ciphers, random number

2. Cipher choice, certificate, random number

3. PreMasterSecret (encrypted in server’s public key)

Verify certificate,Generate

PreMasterSecret

4. Generate keys4. Generate

keys

6. HMAC over handshake messages received

5. HMAC over handshake messages sent


Key Generation

Server random number

Client random number

PreMasterSecret

Label information

Key Generator

MasterSecret

SSL session keys


Client/Server Random Numbers

• Consist of– 32-bit timestamp– 28-byte random number generated by secure

RNG– So, 32 bytes long overall

• These random numbers serve as nonces

• Protect against replay attacks


PreMasterSecret

• Key to setting up secure exchange

• 48-byte random value, generated by client’s secure RNG

• Sent to server encrypted with server’s public key (from certificate sent in Step 2)

• Provides the secure basis for computing the MasterSecret


SSL Keys

• The MasterSecret allows calculation of four symmetric keys, used as follows:– Authentication key for client to server data– Authentication key for server to client data– Encryption key for client to server data– Encryption key for server to client data

• Use of symmetric keys in these areas allows for faster data transfer than asymmetric key


HMAC Revisited

• Hashed Message Authentication Code is a recursive MAC– I.e., it is a hash of data that includes a hash– Both hash functions inputs padded by repeated

instances of 5C hex (opad) or 36 hex (ipad)– Both the “internal” and “external” hash is

computed using a secret key, developed from the MasterSecret


SSL ChangeCipherSpec

• This protocol is used to change from one encryption algorithm to another– Called “strategies” in the RFC

• To change ciphers, client and server negotiate a new CipherSpec and keys– Then send ChangeCipherSpec message, which triggers

use of the new algorithm and keys

• CipherSpec usually changed at end of SSL handshake, but can be done anytime


SSL Alert Protocol• Used to provide connection management

• Involves messages such as\– Digital certificate status– Handshake failure– MD failure

• Two levels of alert– Warning: nonfatal problem– Fatal: immediately terminates session


SSL Record Protocol

• Provides two SSL services:– Confidentiality

• Using shared symmetric keys from MasterSecret

– Message integrity• Using MAC generated using shared symmetric keys

from MasterSecret

• Also provides for message fragmentation and (optionally) compression (lossless)


SSL Overview

• At a minimum, SSL authenticates the server to the client and establishes a secure data session (confidentiality + integrity)– This is what happens when the lock closes on your

browser while you are eShopping– Careful--JavaScript can make the lock close!

• Optionally, if the client has a certificate acceptable to the server, the session can be authenticated in both directions


SSL Versions

• Current version is Version 3.0

• Version 2.0 was the first version to actually see commercial service– Contains many security flaws– Don’t use it unless absolutely necessary!

• Current browsers all support SSL 3.0


How Do You Get It?

• SSL comes pre-configured on modern browsers, which also have a large suite of root certificates

• SSL must be enabled on the appropriate server during the server configuration process– Easy on IIS -- check boxes to select parameters– A completely different build for Apache


How Do You Know If You Have It?

• SSL is identified by the mnemonics HTTPS, FTPS, SMTPS

• Operates on port 443 rather than port 80 (used by HTTP)

• When operating with an HTTP connection, the URL will begin https://...

• Conversely, if SSL is enabled, it can be accessed by addressing https://...


What About Authenticating the User?

• Where in our discussion did the user present a certificate to the server?

• Advantages?

• Disadvantages?


After SSL: TLS

• Transmission Level Security (TLS) is an IETF approach to creating a “non-vendor specific” SSL

• TLS 1.0 is actually SSL v3.1, and the SSL handshake so identifies it– TLS uses a different suite of ciphers (e.g., adds AES)

– TLS uses HMAC differently from SSL

• Supported by all current browsers


Establishing Trust

• TLS does not specify trust establishment

• X.509 Certificate and Public Key Infrastructure– Hierarchy of Trust Model– Certificate Authority– Public Key Cryptography


Verifying a Certificate

• Obtain issuer’s public key

• Decrypt signature using issuer’s public key

• Result of decryption is a hash value of the certificate

• Compute own hash value of the certificate

• Compare the two hash values

• Repeat steps until a CA certificate is reached


SSL 2.0 Vulnerabilities

• MAC Attack

• Traffic Analysis

• Man-in-the-Middle Attack

– Rollback

• Truncation Attack

• Cipher Export Attack


MAC

• MAC = Message Authentication Code– Piece of data – hash– Generated and sent with message– Regenerated on server side– Compared


MAC Process


MAC Vulnerability

• Hashing algorithm – MD2, MD5

• Rainbow tables

• Padding Length – modification and traffic analysis

• Collisions


MAC Solutions

• TLS uses

– Better hashing algorithms such as SHA-1

– Variable padding length

– Padding length in encrypted portion


Rollback Attack

• Man-in-the-middle

• Takes advantage of

unencrypted CipherSuite

exchange

• Allows attacker to

modify which cipher

algorithm to use


Rollback Solution

• Use of two cipher spec states

• Keeps a hash of previous messages to detect modification


Truncation Attack

• Attacker sends a premature TCP connection Close

• Stops recipient from receiving the rest of the data

• Fixed in TLS by a closure alert message


Export Cipher Algorithm Flaw

• Early export laws prohibited the best encryption• Could only encrypt 40 of 128 bits

– Rest sent unencrypted

• Subject to brute force attacks• Fixed in TLS by encrypting all 128 bits


Not really a vulnerability…

• SSL 2.0, client would send its cipher suite list unencrypted

• Server would send its cipher suite list unencrypted

• Client would choose• Allows attacker to know what the server uses• TLS fixes this by allowing the server to

choose


TLS Clients• Microsoft’s Internet Explore 7

– SSL 2.0 enabled by default– Cipher Suite List

• TLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_RC4_128_SHATLS_RSA_WITH_3DES_EDE_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521…TLS_RSA_WITH_NULL_MD5TLS_RSA_WITH_NULL_SHA

– Uses smaller keys by default• Change order in Group Policy Snap-in


TLS Clients (continued)• Mozilla’s Firefox 2.0

– SSL 2.0 disabled by default– Uses Mozilla's Network Security Services (NSS)– Cipher Suite List

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_DSS_WITH_AES_256_CBC_SHATLS_ECDH_RSA_WITH_AES_256_CBC_SHATLS_ECDH_ECDSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_RC4_128_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_RC4_128_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHA…SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHASSL_DHE_DSS_WITH_3DES_EDE_CBC_SHATLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHATLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHASSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHASSL_RSA_WITH_3DES_EDE_CBC_SHA

– Uses larger keys by default (no null ciphers by default)• Enable/Disable suites with ‘about:config’• Change order user.js


TLS Clients (continued)Check Encryption type with Firefox

Check client Browser with Verisignhttp://www.verisign.com/advisor/check.html


TLS vs. IPSec

• TLS Pros– Clients standard with browsers (lower costs)

– More precise access control

– Granular network access• Role based access control

• TLS Cons– Application-based security only

• No access to network resources– File shares

– Printers


Future TLS Cryptographic Enhancements

• Elliptic Curve Cryptography

– Public Key Cryptography using Elliptic Curves

– Smaller keys sizes

– Computationally efficient


Elliptic Curve Cryptography

Symmetric Key Size

RSA and Diffie-Hellman Key Size

Elliptic Curve Key Size

bits bits bits

80 1024 160

112 2048 224

128 3072 256

192 7680 384

256 15360 521


Elliptic Curve Cryptography

Security Level Computation Ratiobits DH Cost : EC Cost80 3:1

112 6:1128 10:1192 32:1256 64:1


Pre-Shared Key (PSK) TLS

• No need for certificates

• No need for RSA or Diffie-Hellman

• Intended for performance-constrained devices


SSL/TLS Summary

• SSL/TLS provides a means for secure transport layer communications in TCP/IP networks

• SSL is a commonly used protocol, developed by Netscape, but ubiquitously used in browsers, etc.

• The key element of SSL is the handshake protocol


Trusted Systems

• One way to enhance the ability of a system to defend against intruders and malicious programs is to implement trusted system technology

• Be careful whom you trust!– But you have to trust someone


Trusted Systems Concept

• Trusted Systems– Protect data and resources on the basis of levels

of security (e.g. military)– Users can be granted clearances to access

certain categories of data– Trusted systems need not discern levels of

permissions; they can operate “system high”• cf. Telephone systems


Security Levels

• Multilevel security: multiple categories or levels of data

• Multilevel secure system must enforce:– No read up: A subject can only read an object of lower

or equal security level (BLP Simple Security Property)

– No write down: A subject can only write into an object of greater or equal security level (BLP *-Property)

– May enforce discretionary security (BLP DS property)

• Security levels may be linear or latticed


Trusted Systems Implementation

• Reference Monitor provides multilevel security for a data processing system– Reference Monitor is a concept, not a thing


Reference Monitor Up Close and Personal


Reference Monitor

• Controlling element in the security kernel of a computer that regulates access of subjects to objects on basis of security parameters

• The monitor has access to a file (security kernel database)

• The monitor enforces the security rules (no read up, no write down)


Reference Monitor Properties

• Complete mediation: Security rules are enforced on every access

• Isolation: Reference monitor and database protected from unauthorized modification

• Verifiability: reference monitor’s correctness must be mathematically provable – this may be where we bend the rules!


Trusted Systems

• A system that can provide such verifications (properties) is referred to as a trusted system


Trojan Horse Defense

• Secure, trusted operating systems are one way to secure against Trojan Horse attacks


Security Evaluation: The Way We Were

• Got its start with the Orange Book– Trusted Computer Security Evaluation Criteria– Generated several counterparts in US, overseas

• Focuses on products or systems– Operating Systems are a product– Collection of products

• Tend to focus on security, not user needs


Evaluations

• Targets

• Purpose

• Method

• Structure

• Organization framework of process

• Costs and benefits


Orange Book (Trusted Computer Security Evaluation Criteria)

• Provides– A way to assess the degree of trust to be placed in a

computing system

– Guidance for computer security manufacturers

– Basis for specifying security requirements

• Examines the TCB– Emphasis on formal methods

– Assumes simple TCB permits exhaustive analysis


Evaluation Classes

• Security policy• Marking of objects• Identification of subjects• Accountability• Assurance• Documentation• Continuous protection


Security Divisions and Classes

• D - minimal protection (read none)

• C1 - discretionary security protection

• C2 - controlled access protection

• B1 - labeled security protection

• B2 - structured protection

• B3 - security domains

• A1 - verified design


Information Technology Security Evaluation Criteria (ITSEC)

• European approach to TCSEC

• Tries to deal with new requirements as they arise

• Focuses on effectiveness and correctness

• Applies to products and systems

• Attempts to measure both functionality and effectiveness


Common Criteria

• Newest version of evaluation standards

• Managed by NIST and NSA

• Available on CD-ROM and via the ‘web– http://csrc.nist.gov/cc/– voluminous text

• Does not address all the shortcomings of the original Rainbow Books


The Way We Are

• The Common Criteria Evaluation and Validation Scheme (CCEVS)– Multiple sets of requirements (security targets)

• Security and assurance requirements selected from the Common Criteria

• Still largely based on machine models

– Vendor-funded evaluations by commercial laboratories– Shorter (but not short) time between evaluation start and

release of results– Confusion about security targets and protection profiles– Internationally recognized approach and results


Common Criteria: The International Standard

What the standard is –

• Common structure and language for expressing product/system IT security requirements (Part 1)

• Catalog of standardized IT security requirement components and packages (Parts 2 and 3)

How the standard is used –

• Develop protection profiles and security targets -- specific IT security requirements and specifications for products and systems

• EvaluateEvaluate products and systems against known and understood IT security requirements


Common Criteria Terminology

• Protection Profile (PP)An implementation-independent set of security requirements for a category of products that meet specific consumer needs.

• Security Target (ST)A set of security requirements and specifications to be used as the basis for evaluation of an identified product.


Protection Profile (PP)

• Answers the question:

What do I need in a security solution?

• Implementation independent

• Multiple implementations may satisfy PP

requirements

• Authors can be both consumers and producers of IT

products and systems


Security Target (ST)

• Answers the question:

What do you provide in a security solution?

• Implementation dependent/specific

• Authors can be product vendors, product

developers, or product integrators


Protection Profiles and Security Targets

• PP makes a statement of implementation independent security needs- A generic operating system with discretionary access

controls, audit, and identification and authentication

• ST defines the implementation dependent capabilities of a specific product, e.g.- Microsoft Windows 2000

- Sun Solaris 8


Common Criteria Evaluation and Validation Scheme (CCEVS)

• Objective– Test Security Properties of Commercial Products

• Approach– Tests performed by Accredited Commercial Laboratories

– Validity/Integrity of results underwritten by NIAP

– Results posted for public access


• Evaluates conformance of the security features of IT products to the International Common Criteria (CC) for Information Technology Security Evaluation.

• Issues Certificates to vendors

for successful completion

of evaluations.– Not an NSA or NIST endorsement

– Not a statement about

goodness of product

Common Criteria Evaluation and Validation Scheme (CCEVS)

The IT product identified in this certificate has been evaluated at an accredited testing laboratory using the Common Methodology for IT Security Evaluation (Version X) fr conformance to the Common Criteria for IT Security Evaluation (Version X). This certificate applies only to the specific version and release of the product in its evaluated configuration. The product’s functional and assurance security specifications are contained in its security target. The evaluation has been conducted in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme and the conclusions of the testing laboratory in the evaluation technical report are consistent with the evidence adduced. This certificate is not an endorsement of the IT product by any agency of the U.S. Government and

no warranty of the IT product is either expressed or implied.

Vendor Name

Product Name: Version and Release Numbers: Protection Profile Identifier: Evaluation Platform:

Name of CCTL: Validation Report Number: Date Issued: Assurance Level:

National Information Assurance Partnership

Common Criteria Certificate

Deputy Directorfor

Information Systems Security National Security Agency

Director, Information Technology Laboratory

National Institute of Standards and Technology

®


Protection

Profile

Evaluation Process SummaryProduct

Security

Target

Product

Security

Target

Protection

Profile

- Analyze- Test- Document- Report

- Oversee- Review- Validate

VALIDATION

Commercial Evaluation Facility

Validation

Report

The IT product identified in this certificate has been evaluated at an accredited laboratory for conformance to the Common Criteria for IT Security Evaluation (Version X). This certificate applies only to the specific version and release of the product in its evaluated configuration. The product’s functional and assurance security specifications are contained in its security target. The evaluation has been conducted in accordance with the provisions of the NIAP Common Criteria Evaluation and Validation Scheme and the conclusions of the testing laboratory in the evaluation technical report are consistent with the evidence adduced. This certificate is not an endorsement of the IT product by any agency of the U.S.

Government and no warranty of the IT product is either expressed or implied.

IT Product Developer

Product Name: Version and Release Numbers: Protection Profile Identifier: Evaluation Platform:

Name of CCTL: Validation Report Number: CCEVS-0000Date Issued: Assurance Level:

Deputy Directorfor

Information Systems Security National Security Agency

National Information Assurance Partnership

Common Criteria Certificate

TM

DirectorInformation Technology Laboratory

National Institute of Standards and Technology

EVALUATION


National Information Assurance Partnership®

• NIST initiative to improve information assurance in government, cooperative with NSA

• NSTISSP #11 – Policy issued by the Chairman of the National Security

Telecommunications and Information Systems Security Committee (NSTISSC)

– Only validated COTS products to be purchased by the Executive Branch effective 1 July 2002 for processing of national security information


Objective

• The objective of NSTISSP #11 is to ensure that COTS IA and IA-enabled IT products acquired by the U.S. Government for use in national security systems perform as intended by their respective manufacturers, or satisfy the security requirements of the intended user.


Mutual Recognition Arrangement

NIAP, in conjunction with the U.S. State Dept, negotiated a Common Criteria Recognition Arrangement that:

• Provides recognition of Common Criteria certificates among 19 nations• Eliminates need for costly security evaluations in more than one country• Offers excellent global market opportunities for U.S. IT industry• Limits Mutual Recognition to EAL 4 and below, but higher levels

between some countries


Outside the U.S.

• Certification authorities tend to be government agencies with a commercial focus– e.g., in Germany, the Bundesamt für Sicherheit in der

Informationstechnik (BSI - Federal Office for Information Systems Security) is an agency of the Interior Ministry (Bundesministerium des Innern)

• Greater tendency overseas to focus on commercial benefits of certification than is the case in the U.S.


Benefits

• Accreditors do not need to spend project funds to redo security tests already performed under CCEVS

• An evaluated list of acceptable products exists, simplifying product selection for program offices

• Greater flexibility in defining requirements provides finer granularity of results


Evaluation Concerns

• Confusion about meaning and application of Security Targets and Protection Profiles

• No clear understanding of whether a product evaluated against one PP might also meet another

• The Common Criteria is much more complex than the old Orange Book and is not well understood by users

• All of these lead to disconnects and apparent errors in the process

• Evaluation laboratories are paid by the vendor, and so focus on getting the product evaluated as quickly and inexpensively as possible.

• Validation of evaluations (oversight by CCEVS partners) helps to ensure evaluation quality and consistency, but can’t guarantee it.

• Process still takes too long to keep up with product upgrades.


Don’t Be Overconfident

• In autumn 2002, Windows 2000 received a security certification under the Common Criteria, no small accomplishment

• The very day after certification was announced, Microsoft released warning of a serious security flaw just discovered in Windows 2000!

• Certification isn’t everything– But it is important to understand that the flaw

discovered was not in an area evaluated under the CC


Does Quality Count?

• ISO 9000 meaningful here?

• How do you measure it?

• Is B2 “better” than C1? If so, for what?

• How do you measure the cost versus benefits of “improved” security?


Evaluation Issues

• Government-driven• Potentially dated• Based largely on single, isolated systems• No clear correlation of security divisions and user

needs and benefits• Cost of evaluation is often prohibitive• Were falling into disuse, but NSTISSP #11 has

resurrected for national security info• CC also popular internationally as indication that

software meets at least minimum standards


Trends

• Just a few years ago, it looked as if formal security evaluation and certification were becoming extinct

• The new awareness of cybersecurity needs has changed all that

• Today, the trend is for evaluation and certification for federal IT purchases, with the cognizant agency typically being NIST

• Increasing emphasis on security in commercial systems (witness Windows developments)


Other Approaches to Security Evaluation

• One approach:– Define what is desired security by policy

– Use Tiger Teams to assess compliance with policy

– Extend findings by formal examination to find “holes” not seen in empirical attacks

• Will this work? • Is this a suitable substitute for TCSEC or CC?


What Is a Tiger Team?• n. [U.S. military jargon] 1. Originally, a team whose purpose

is to penetrate security, and thus test security measures. These people are paid professionals who do hacker-type tricks, e.g., leave cardboard signs saying “bomb” in critical defense installations, hand-lettered notes saying “Your codebooks have been stolen”" (they usually haven't been) inside safes, etc. After a successful penetration, some high-ranking security type shows up the next morning for a ‘security review’ and finds the sign, note, etc., and all hell breaks loose. Serious successes of tiger teams sometimes lead to early retirement for base commanders and security officers. 2. Recently, and more generally, any official inspection team or special firefighting group called in to look at a problem.

The Jargon Dictionary


Tiger Team Issues

• Plan the attack thoroughly before starting• Ensure you have written permission of the system owner––

not just a friendly sysadmin –– before proceeding• Document everything you do and find• Do not do anything that will disable or compromise the

system• Report findings promptly• Realize that Tiger Teams tend to exploit the first

problem(s) found, not do a comprehensive search for other issues. This can limit the effectiveness of this approach.


Summary• Formal security evaluation techniques are

academically interesting, but have until recently failed to provide significant practical improvement in fielded systems security

• Emphasis is shifting to new evaluation schemes and empirical, policy-based security evaluation

• Both approaches offer opportunities for exploitation by malefactors and for real improvement in systems security


Intrusion Detection Systems

• Oddly enough, these are systems designed to detect intrusions into protected systems

• Security intrusion (per RFC 2828):– A security event, or a combination of multiple

security events, that constitutes a security incident in which an intruder gains, or attempts to gain, access to a system (or system resource) without having authorization to do so.


What’s a Security Incident?

• A security event that involves a security violation. (See: CERT, GRIP, security event, security intrusion, security violation.)

• In other words, a security-relevant system event in which the system's security policy is disobeyed or otherwise breached.

• "Any adverse event which compromises some aspect of computer or network security." [R2350]

Source: RFC 2828, page 152; emphasis added


Why Do We Need This?

• With the exception of authentication systems, most of the defenses we have studied up to now are directed towards intruders coming from outside the firewall

• These systems are not perfect--some intruders will get through

• Moreover, defenses such as firewalls cannot protect against intruders on the inside


Intrusion Detection Functions

• Monitor protected networks and computers in real time (or as close to real time as is practicable)

• Detect security incidents– Requires a policy, and a way for the IDS to know

what that policy is

• Respond– Raise an alarm– Send some automated response to the attacker


IDS vs. Auditing

• Audits tend to be a posteriori– But an IDS can be seen as performing a

constant, near real time audit function

• To perform an audit, you need to know what the policy is– Audits measure departures from the policy

norms– Audits depend on system logs


Early IDS’s

• Emulated the audit function– Crawled the logs, looking for deviations from

policy-permitted actions– Intent was to speed up the audit, making it

nearly real time– Still a useful approach

• IDS technology has been around only since the early 1990’s; not too mature


IDS Uses

• Monitor system usage– Determine access, usage patterns– Plan for capacity engineering

• Monitor specific problem areas

• Serve as a deterrent– Sort of like the “burglar alarm” label on a

house, even if there is really no alarm


Log Files

• Are evidence if an intrusion occurs– Must be stored in their original, unmodified

form, otherwise inadmissible in court– Provide data from which trends can be deduced– Can be subjected to forensic analysis– Probably needed to assess level of system

compromise/damage and to restore to state prior to intrusion


Legal Issues - 1

• Privacy of your employees– Courts have held that employees have little

expectation of privacy in the workplace, especially if told so at the outset

• email can be monitored at work by employer

• phone calls can be monitored at work by employer

• doing either of these things outside the workplace violates the wiretap statutes (18 USC § 2516, etc.)


Legal Issues - 2

• What if the IDS discovers illegal acts being performed on/by your network?– Employees using the network for illegal

activities– Outsiders having planted zombie programs so

that your system attacks others– What is your responsibility and liability?


Legal Issues - 3

• This may be a Catch-22 issue– If an attacker is using your system, law

enforcement may want you to continue to allow that to happen so they can apprehend the attacker

• If you interrupt the attack, could be interpreted as obstruction of justice

– But, if you allow the attack to continue, you may be liable for damages to those attacked

• Get legal advice--beforehand!


What About Automated Response?

• Tempting capability

• If attacking your system is illegal, what makes your attack on the attacker in response less illegal?

• What if you are, or are acting on behalf of, a governmental entity and the attacker is also a governmental entity?– Casus belli


IDS Architecture

Sensor Sensor Sensor

Sensor

Sensor

ManagementConsole


Console

• Monitors and controls sensors– Sets policy, alarm levels, etc.– Stores logs

• Must have secure communications with sensors– Encrypted connection– Out of band (OOB)


IDS Types

• Network-based (NIDS)– Monitors the network backbone

• Network node-based (NNIDS)– Monitors network nodes, not the backbone

• Host-based (HIDS)– This is the “log crawler” that started it all

• Gateway (GIDS)– NIDS in series with the network


What Can It See?

• Network packets

• OS API calls

• System logs

• How do we merge this data to detect intrusions?


Host-Based

• Sits on a host as a background task

• Monitors (potentially)– traffic to and from the host– OS API calls– system logs

• Adds to processing load on the host, so host must be able to support the extra load


Network-based

• NIDS sensors placed on network backbone– Can view only packet traffic passing by, much

like a classic passive sniffer– Does not place processing load on network, but

the NIDS platform must be capable of dealing with network traffic speeds

• Software can usually handle 100 Mbps

• Hardware only 2-3 times faster

• If network is faster, looks only at subset of packets


Network Node-based

• Used to inspect intrusions directly into network nodes– Effectively a blending of HIDS and NIDS– Used to protect mission-critical machines– Again, a background process on existing nodes,

so node must be able to handle added processing load


Gateway

• In series with network– Often set to block prohibited traffic

automatically– Think of it as an in-network firewall with an

extended rule set– Must be able to keep up with network load


Intrusion Protection Systems

• Latest trend in IDS technology• Idea is to use what the IDS identifies to

change the network rules ad hoc, in theory preventing further exploitation– This involves anomaly detection– Which, in turn, requires knowledge of the real

baseline network conditions

• Very similar to GIDS in implementation


IPS Issues

• Attack signatures generally known only a posteriori• Heuristic anomaly analysis has not worked very

well in other venues, such as virus detection• Establishing the network baseline is nontrivial and

subject to manipulation• How long to maintain the “new” rules before

reverting to the original ones?• Exploitation of the IPS


Deployment

• Putting in an IDS is a complex and time-consuming affair– Typically, start simple and add functionality as

you learn more about the network– NIDS tends to see more and load network least– Follow up with HIDS on selected hosts,

perhaps NNIDS on critical nodes

• Policy has to be in place first


Attack Signatures

• Critical to success of any IDS• Must be maintained, just like virus signatures

– You want some visibility into this– Do you want strangers deciding what is an attack

on your critical systems?

• Some IDS’s let you write/modify signatures, others do not

• CVE: http://www.cve.mitre.org/


IDS Deployment

• First, design the IDS sensor and management layout

• Next, deploy the IDS – Test the network for normal operation– Test the IDS

• Run packaged attacks to see if all are detected

• Document performance and repeat test regularly

– Tune the IDS


Sampling of IDS Products

• Snort: http://www.snort.org/

• SnortSnarf: http://www.silicondefense.com/software/ snortsnarf/


IDS Summary

• IDS’s can be useful in monitoring networks for intrusions and policy violations

• Up-to-date attack signatures and policy implementations essential

• Many types of IDS available, at least one as freeware

• Serious potential legal implications• Automated responses to be avoided


Homework

• Research rainbow tables, and describe how they can be used to break hashes. Give your assessment of the utility of this technique.

• Identify two additional attacks that could be used to compromise SSL and TLS. Describe how they work, and how they can be countered or mitigated.

ece579s/7 #1 spring 2011 © 2000-2011, richard a. stanley ece579s computer and network security 7:...

Documents