ISM/ISC Middleware Module

(1)

ISM/ISC Middleware Module

Lecture 13:

Security for Middleware

Applications

Dr Geoff Sharman

Visiting Professor in Computer Science

Birkbeck College

(2)

Lecture 13



Aims to:

 Show why security is important and differentiate

network security from application security

 Describe commonly used network security

measures provided by firewalls

 Introduce the various forms of application security

which are relevant to transactional applications

 Explain how encryption is used to support

security measures and how it is administered

(3)

Problems can Happen!

■ The following sites were attacked in Feb 2000, using Trojan Horses and automated tools which resulted in denial of service:

 Yahoo  CNN  e-Bay  Buy.com  MSN  E*Trade  Amazon.com  ZDNet

■ Outages lasted three to five hours in most cases

■ Attacks were declared a Criminal Offence, FBI investigated ■ Revenue losses in advertising and sales estimated at $100m

■ Affected companies planned to spend $100m-$200m on security 3

(4)

We Know Security is Important

■ Web site subverted by hackers/trojan horses

■ Major outage due to denial of service attack

■ Sensitive data seen by unauthorised users

■ Transactions committed by unauthorised users

■ Users do not pay for goods received

■ Bad publicity as a result of problems, e.g:

■ How do we pick this apart and decide what to do?

... but what are the risks?

"Report Says Web Hacks to Cost $1.2Bn" “Government data loss anger”

(5)

What are we Trying to Protect?



Major organisational assets:

 Data/information

 Capability to commit transactions

 Processing resources

 Other assets, e.g. money

 Reputation

- need to understand their value & level of risk



These might be lost or damaged by user

error, unauthorised users, faulty software /

applications, or inadequate procedures



The basis of all security is physical security

 system is only as good as its administrator

(6)

Networking Security

(7)

Networking Security Hazards



By tradition, systems running Middleware

applications use private networks, e.g:

ATM, POS, and Call Centre systems



These are physically protected against

wire-tapping and mis-use of network

endpoints, e.g. supermarket till



Only accessible to authorised employees

(8)

Networking Security Hazards (II)



e-Commerce is based on public networks

using Internet Protocol (IP)

 Network endpoints may be anywhere in the world

 Network addresses may be assigned dynamically

(DHCP), so cannot be traced

 Traffic is packet based, may be intercepted &

manipulated by routers and other computers

 Transmission Control Protocol (TCP) enables

end-to-end sessions by creating virtual circuits



Need to isolate in-house network from public

network via a firewall gateway

(9)

Firewall Technologies

Filter: limited IP connectivity Proxy: no direct connectivity

Insecure network Secure network Application proxy Network Address Translation Rules 9 Network router DNS www.me.org ==> 86.140.182.229

(10)

The Firewall Gateway



Computers inside an organisation should only

connect to computers outside (on public

networks) via the firewall router



The firewall acts a gateway, controlling:

 incoming traffic (who/what can visit this org.)

e.g. allow access only via defined ports

 outgoing traffic (what people in the org. can visit)



It must be simple, non-extensible, limited

access, and physically secure

(11)

Demilitarised Zone (DMZ)

Insecure network Secure network

Ro u ter/ fi lte r fi rew al l P ro xy /fi lte r fi rew al l Demilitarised Zone

Domain Name server Public web server

(12)

Firewall Policies



Typical policies include:

 Disallow all traffic from outside (e.g. IIOP requests)

except that which is explicitly permitted (why?)

 Translate network addresses of internal machines,

so their real addresses remain unknown

 Allow HTTP requests using Port 80 (or 8080)  Note: although restrictive, this policy may still be

vulnerable to tunnelling

(13)

Application Security

(14)

Identity



Application security is based on the concept

of identity: a known user of an application

corresponding to a particular individual



Enables:

 assignment of powers to individuals

 accountability for using those powers

 tracing/auditing of what actually happens

- so identity should not be shared



Vulnerable to identity fraud:

 Now easier than breaking network security

 Most cases arise from non-system activities

(15)

Data Access Logic Presentation Logic Business Logic

Who are you? What are you _{allowed to do?}

Basic Types of Application Security

● Authentication - prove your identity?

● Authorization - what is identity allowed to do?

● Privacy - which identities can read this message? ● Message integrity - is message received what was sent? ● Non-repudiation - prove which identity sent this message? ● Code auditing - does this program do what it says?

(16)

Authentication



Proof of identity is based on:

 production of an object, e.g. smart card

 knowledge of a secret, e.g. password, pin, X.509

certificate

 physical identifying marks, e.g. biometrics, DNA

 combinations of these, e.g. chip & pin



Other measures may enhance security:

 e.g. application managed identity, password

expiry, one-time passwords



Whatever credentials chosen, identity must

be mapped to operating system identity

(17)

Authorisation



Basic idea is that an identity may only

perform those actions which it has been

authorised to do e.g.:

 run program x

 access data file y

 usually enforced by the operating system



Middleware systems often impose further

limitations, e.g. identity may:

 only perform transaction z (no knowledge of pgm)

 not install programs (unless administrator)

 have no direct access to data

(18)

Authorisation (II)



To ensure that applications perform only

authorised actions, it's common practice to:

 log security holes in software and manage fixes

 assign a responsible owner to each program

 inspect application program as they're developed

 certify the source of a program

 identity “sensitive” programs, e.g. those

controlling money, and audit them

 log actual use of applications to enable later

investigation

(19)

Authorisation (III)



Sometimes we need authorisation controls

which are more fine-grained than the

middleware provides:

 e.g. user can only sign off expenditure > £5K if

he/she is a second level manager



These checks must be performed by

application programs

 Use middleware facilities to handle error conditions

(20)

Data in Transit



When sensitive data flows across an insecure

network, we want to achieve:

 Privacy/confidentiality: message cannot be read

by unauthorised identities

 Message integrity: message received is what was

actually sent

 Non-repudiation: message can be traced to an

authorised sender & cannot be denied



These types of security require the use of

encryption

(21)

Cryptographic Techologies



Two technologies in common use:

 Secret key: single key shared by sender & receiver

- used to encrypt and decrypt messages

- algorithm is symmetric: work factor ~ 2**(n-1)

- e.g. Data Encryption Stnd (DES 1971), 56 bit keys

 Public/private key: public key to encrypt, private key

to decrypt

- algorithm is asymmetric: work factor ~ 2**(0.3n) - e.g. Rivest/Shamir/Adelman (RSA 1977) with 512, 1024, 2048 bit keys

 (n = key length in bits) 21

(22)

Secret Key Encryption

Insecure network Decryption

Algorithm Encryption Algorithm clear text message clear text message encrypted message secret key 22

(23)

Public/Private Key Encryption

Insecure network _Decrypt

Encrypt clear text message clear text message encrypted message receiver's public key receiver's private key 23

(24)

Message Integrity

Insecure network Encrypt input msg + digest input message Compute message digest

■ Message digest algorithm produces fixed length "digital hash" ■ Same algorithm used to validate message received

receiver's public key message digest receiver's private key Decrypt, recompute digest and compare 24

(25)

Non-Repudiation

■ Message digest encrypted with sender's private key is known as

digital signature message digest Insecure network Decrypt digest Encrypt digest Encrypt message Decrypt msg, compute digest input message receiver's public key sender's public key sender's private key receiver's private key Compare digests 25

(26)

Making Encryption Usable



To make encryption usable in everyday life

we:

 Build it in to communication protocols, e.g.

- Secure Sockets Layer (SSL) (1994)

- HTTP over SSL (HTTPS): https://www.x.com/ - designed by Netscape for use in browsers

 Use it to support authentication

 Arrange secure methods for allocation and

distribution of keys

(27)

Secure Sockets Layer



SSL may be used in place of TCP/IP sockets



Provides:

 Authentication of server using public/private key

- requires server certificate

 Secure message interchange using secret key

 Optional authentication of client using

public/private key

- requires client certificate

 Lightweight implementation for Java is provided by

Java 2 SE Security

(28)

SSL Handshake

Hello, I support RC4, DES, and none

Here's my certificate Here's the RC4 key to use (encrypted)

Session data encrypted using RC4 key

CLIENT SERVER

Hello, let's use RC4

Change cipher spec

Confirm change cipher spec

■ check server

certificate

■ decrypt session

key and cache

(29)

Client Authenticated SSL Session

Hello, I support RC4, DES, and none

Hello, let's use RC4, here's my certificate

Can I have your certificate please?

Here's my client certificate

Here's the RC4 key to use (encrypted)

Session data encrypted and authenticated

CLIENT SERVER

■ check client

certificate

(30)

Digital Certificates

■ Makes owner's public key available to others

■ Must be issued by a trusted Certificate Authority (CA)

Owner's public key Owner's distinguished

name, e.g. BBK.geoff

Certificate Authority's distinguished name Encrypted message digest CA's private key 30

(31)

Certificate Authorities



Browsers are normally shipped with

certificates identifying the major Certificate

Authorities, e.g. Equifax, Verisign



Server certificates are checked against

these to see whether issued by one of them

- if so, server can be trusted



Client certificates must be purchased from

one of them (or allocated by employer)

(32)

Certificate Authorities (II)

Root certificate authority Certificate issuing authority 1 Certificate issuing authority 2 sender receiver not trusted 32

(33)

Key Ring/Certificate Database

Root CA's certificate Subordinate CA's certificate Client certificate

■ Browser/client has database which contains certificates needed ■ Also needs utilities which enable database to be maintained ■ Database must be password protected

(34)

Summary



You should now be able to: