Académique Documents
Professionnel Documents
Culture Documents
02/19/15
Vivek Kapoor
Introduction
02/19/15
Vivek Kapoor
Introduction
Vivek Kapoor
.
02/19/15
Vivek Kapoor
Vivek Kapoor
02/19/15
Vivek Kapoor
Version 1
Version 2
Version 3
All Versions
Vivek Kapoor
Fig.
Key Generation
Registration
Verification
Certificate Creation
02/19/15
Vivek Kapoor
10
a)
b)
02/19/15
Vivek Kapoor
11
This step is required when user generates key in the first step.
Here subject sends public key along with other information &
evidences to the RA.
For this software provides wizard in which all users enters the data
and submits it. It is called certificate signing request.
This is one of the public key cryptographic standards which we will
study latter.
02/19/15
Vivek Kapoor
12
a)
b)
1)
2)
3)
Vivek Kapoor
13
Vivek Kapoor
14
02/19/15
Vivek Kapoor
15
02/19/15
Vivek Kapoor
16
Encrypt
02/19/15
Message Digest
Digital Signature
Vivek Kapoor
17
Digital Signature
CAs public
key
Is MD1
=MD2?
Yes
No
Invalid 18
Reject it
Suppose Alice received Bobs certificate & she wants to verify it. For
Alice wants to design the bobs certificate using Bobs CA public key.
How will Alice know Bobs CA public key?
If their CAs are same then there is no problem ? But if they are
different then the problem arises.
To resolve this type of problem Certification Authority Hierarchy is
created. This is also called Chain of Trust. In other terms CAs are
grouped into multiple level of CA hierarchy.
CA hierarchy begins with the root CA.
The root CA has one or more 2nd level CA, which in turn have one or
more third level CAs and so on.
This type of hierarchy relieves the root CA from having to mange all
the possible digital certificates.
02/19/15
Vivek Kapoor
19
2nd Level CA
3rd Level CA
02/19/15
2nd Level CA
3rd Level CA
2nd Level CA
3rd Level CA
Vivek Kapoor
3rd Level CA
20
2nd Level CA A1
3rd Level CA B1
02/19/15
Alice
2nd Level CA A2
3rd Level CA B2
2nd Level CA A3
Vivek Kapoor
Bob
21
If Alice has obtained her certificate from a third level CA & Bob has
obtained his certificate from other third level CA, How can Alice verify
Bobs certificate?
Clearly Bob in addition to his own certificate Bob will send certificate
of his CA (i.e B11) to Alice. This would tell Alice the public key of B11.
Using the public key of B11, Alice can design and verify Bobs
certificate.
Now question arises how will Alice will trust B11 certificate.
For this Alice will required A3 certificate since B11 certificate has
obtained certificate from A3 and this will go so on until it reaches the
root certificate.
The root CAs are considered to be trusted CAs, for this Alice web
browser contains pre programmed, hard coded certificate of the root
certificate
Root certificate is self signed certificate i.e root signs its owns
certificate
02/19/15
Vivek Kapoor
22
02/19/15
Vivek Kapoor
23
02/19/15
Vivek Kapoor
24
Cross Certification
It is possible that Alice & Bob live in different countries i.e their root
CAs will be different.
In fact, in one country can have multiple root CAs.
Root CAs in US are VeriSign, Thawte & US postal service.
This could lead us to the same old story of a never ending chain of
certification authority hierarchy and their validations.
Alternative to this problem is cross-certification.
Because single monolithic CA certifying every possible user in the
world is quiet unlikely. This is a concept of decentralization. Of CAs
for different countries.
It helps CAs not only to work with smaller population but also work
independently.
02/19/15
Vivek Kapoor
25
Cross Certification
Fig.
Root CA of
INDIA
Root CA of USA
2nd level CA
(A1)
Alice
3rd level CA
(B2)
.
02/19/15
3rd level CA
(Q1)
.
Vivek Kapoor
3rd level CA
(Q2)
Bob
26
Certificate Revocation
1)
2)
3)
Vivek Kapoor
27
Certificate Revocation
Fig.
Digital Certification
revocation Checks
Certification revocation
List (CRL)
02/19/15
Online revocation
status checks
Online certification
validation protocol (OCSP)
Vivek Kapoor
Online certification
validation protocol (OCSP)
28
02/19/15
Vivek Kapoor
29
Fig.
CA: XYZ
Certification revocation List (CRL)
This CRL: 1 Jan 2002, 10.00AM
Next CRL: 12 Jan 2002, 10.00AM
Serial No.
Date
Reason
1234567
30-Dec-01
2356115
30-Dec-01
Changed job
02/19/15
Vivek Kapoor
30
Vivek Kapoor
31
Format of a CRL
Fig.
Version
Signature Algorithm identifier
Header
Fields
..
CRL Ext.
Signature
02/19/15
Vivek Kapoor
Repeating
entries
Trailer
fields
32
1)
2)
3)
02/19/15
Vivek Kapoor
33
Vivek Kapoor
34
Certificate Types
Not all digital certificates have same status and cost. Depending on
requirements they differ.
Certificate types can be classified as follows:
# Email certificates: It includes the users email id. It is used to verify
that signer of an email message has an email id i.e is same as it
appears in users certificate.
# Server-side SSL certificates: These are for merchants who allow
buyers to purchase goods from their online website. They are issued
after careful scrutiny of merchant credentials.
# Client-side SSL certificates: It allow merchant to verify client.
# Code-signing certificates: These are used to sign java applets code
or Microsoft active X codes which are embedded over the web
page.
02/19/15
Vivek Kapoor
35
Roaming Certificates
1)
2)
3)
Vivek Kapoor
36
Attribute Certificates
02/19/15
Vivek Kapoor
37
1)
2)
3)
4)
5)
02/19/15
Vivek Kapoor
38
1)
2)
02/19/15
Vivek Kapoor
39
Key Archival
Ca must plan & maintain history of the certificates & the keys of its
users.
This helps us to inquire a document which is signed way back.
It help to avert legal problems.
02/19/15
Vivek Kapoor
40
02/19/15
Vivek Kapoor
41
PKIX Services
1)
2)
3)
4)
5)
6)
7)
8)
9)
Vivek Kapoor
42
1)
2)
3)
4)
5)
Vivek Kapoor
43
02/19/15
Vivek Kapoor
44
Withdrawn
No longer active. Covered RSA
encryption of message
digests, but was merged into PKCS #1.
Vivek Kapoor
45
PKCS #4 Withdrawn
key
merged into PKCS #1.
PKCS #5 Password-based
Encryption Std.
Vivek Kapoor
46
Vivek Kapoor
47
Vivek Kapoor
48
02/19/15
Vivek Kapoor
49
They are used to keep symmetric session key safe & protect it from
unauthorized access.
We first encrypt plain text message with the symmetric key, & then
encrypt the symmetric key with key encryption key (KEK). It protect
symmetric key from unauthorized access.
Next question is that where do we store KEK & how to protect it.
To protect KEK is to never store it anywhere.
The approach is to generate it on demand, use it for
encryption/decryption & discard it.
For this purpose, a password is used.
Password is input for key generation process (usually a message
digest algorithm) output is KEK.
Password
02/19/15
Key generation
process
Vivek Kapoor
KEK
50
Vivek Kapoor
51
It describes syntax for storing pvt. key securely so that they cannot
be attacked.
PKCS#10 describes syntax for certification requests.
Certification requests are sent to a certification authority which
transform request to an X.509 public key certificate.
02/19/15
Vivek Kapoor
52
02/19/15
Vivek Kapoor
53
02/19/15
Vivek Kapoor
54
PKCS#14-Psuedo-Random number
generation standard
02/19/15
Vivek Kapoor
55
PKCS#14-Psuedo-Random number
generation standard
02/19/15
Vivek Kapoor
56
PKCS#15-CryptographicToken information
syntax standard
02/19/15
Vivek Kapoor
57
Thank You
-----------------------------------------------------------
02/19/15
Vivek Kapoor
58
Chapter 2
Internet Security Protocols
02/19/15
Vivek Kapoor
59
02/19/15
Vivek Kapoor
60
Web browser
02/19/15
Web server
3. Program
executes &
produce HTML
output.
Vivek Kapoor
2. Invokes an
application
program in
response to
HTTP request
61
02/19/15
HTML Page
----------------------------------------------
Vivek Kapoor
Small prog.
(Applet or
Microsoft
Active X
controls
62
Communication link
02/19/15
Vivek Kapoor
63
Application
Transport
Transport
Network
Data Link
Physical
02/19/15
Network
Network
Network
Data Link
Data Link
Data link
Physical
Physical
Physical
Vivek Kapoor
64
L5 Data
L5 Data
Application
Transport
H4
L4 Data
L3 Data
L5 Data
Internet
H3
H2
L4 Data
Data link
011101010101010100101010
02/19/15
L5 Data
L3 Data
Physical
Vivek Kapoor
H4
H3
H2
011100000110101010110110
65
Vivek Kapoor
66
L5 Data
L5 data
SH
L5 Data
H4
L4 Data
L3 Data
L5 Data
SSL
L5 data
Transport
L5 Data
Internet
H3
H2
L4 Data
Data link
011101010101010100101010
SH
H4
H3
L3 Data
Physical
H2
011100000110101010110110
Vivek Kapoor
67
Handshake Protocol.
(a) Establish Security Capabilities.
Client Hello
Server Hello
(b) Server authentication & Key Exchange,
Certificate
Server Key Exchange
Certificate Request
Server Hello Done
(c) Client authentication & Key Exchange
Certificate
Client key Exchange
Certificate Verify
(d) Finish
Change Cipher Specs
Finished
02/19/15
Vivek Kapoor
68
3.
Record Protocol
Fragmentation
Compression
Addition of MAC
Encryption
Append Header
Alert Protocol
Fatal Alerts
Non-Fatal Alerts
02/19/15
Vivek Kapoor
69
1.
2.
3.
4.
Length
Content
1 byte
3 bytes
1 or more bytes
02/19/15
Vivek Kapoor
70
02/19/15
Vivek Kapoor
71
Vivek Kapoor
72
02/19/15
Vivek Kapoor
74
Pre-master
Secret
Client
Random
Server
Random
Master Secret
02/19/15
Vivek Kapoor
75
Master Secret
Client
Random
Server
Random
Symmetric
Key
02/19/15
Vivek Kapoor
76
Fig
02/19/15
Vivek Kapoor
77
Vivek Kapoor
78
Vivek Kapoor
79
Vivek Kapoor
80
Before ending the communication each part should notify the other
close notify alert & end the connection from its side.
The handshake protocol is quite complex & time consuming as it
use asymmetric key cryptography.
Thus it is desired that client-server should reuse earlier connection,
rather than going for new connection.
A SSL connection should not be used after 24 hrs in any case.
02/19/15
Vivek Kapoor
81
02/19/15
Vivek Kapoor
82
02/19/15
Vivek Kapoor
83
02/19/15
Vivek Kapoor
84
1.
2.
3.
02/19/15
Vivek Kapoor
85
Vivek Kapoor
86
SET Process
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
02/19/15
Vivek Kapoor
87
1.
Online payment requires that customer sends its credit card info.
To the merchant.
There are two issue related to it i.e an intruder can get the no. and
use it for malicious intentions.
Second is that credit card no. is made available to the merchant
who can misuse it in future.
First issue is generally dealt by SSL, since SSL sends all the info.
In encrypted form hence an intruder cannot make any sense out
of it.
Second issue is dealt bi SET since it hides credit card information
from the merchant.
For this SET relies on the concept of digital envelope.
The following steps illustrates the idea:
SET software prepares the payment info. (PI) on cardholders
computer.
02/19/15
Vivek Kapoor
88
Vivek Kapoor
89
SET Internals
Vivek Kapoor
90
Cardholder
02/19/15
Vivek Kapoor
Merchant
91
Cardholder
02/19/15
Vivek Kapoor
Merchant
92
1.
Vivek Kapoor
93
Cardholder
02/19/15
Vivek Kapoor
Merchant
94
Dual signature:
PI
MD5
PIMD
OI
MD5
OIMD
MD5
POMD
95
+
OI
MD5
02/19/15
POMD1
OIMD
Dual Signature
(DS)
POMD1
MD5
POMD2
POMD2
Vivek Kapoor
If Yes then
accept else
reject
96
+
PI
MD5
02/19/15
POMD1
PIMD
Dual Signature
(DS)
POMD1
MD5
POMD2
POMD2
Vivek Kapoor
If Yes then
accept else
reject
97
1.
2.
3.
4.
02/19/15
Vivek Kapoor
98
Payment Authorization
Payment
Gateway
Authorization request
02/19/15
Vivek Kapoor
99
Payment Authorization
Fig.
Merchant
Authorization Response
02/19/15
Vivek Kapoor
100
Merchant
Capture Request
02/19/15
Vivek Kapoor
101
Merchant
Capture Response
02/19/15
Vivek Kapoor
102
SET Model
Fig.
Please verify
cardholders certificate
Request for
Certificate
Merchant
Certificate
Authority (CA)
CA 1
Please verify
merchants certificate
CA 2
Merchant Certificate
Cardholders Certificate
Purchase Response
Request for
Certificate
Cardholder
Purchase Request
Authorization Request
Payment
Authorization Response Gateway
02/19/15
Vivek Kapoor
103
Issue
SSL
SET
Main Aim
Exchange of data in
encrypted form
Certification
Strong mechanisms
Risk of
merchant
fraud
Possible
Not possible
Risk of
customer
fraud
Possible
Not possible
Practical
Usage
High
02/19/15
Vivek Kapoor
104
SET has one limitation, it does not prevent user from providing
someone else credit card no.
New protocol called 3-D Secure protocol helps to achieve this.
Here card holder who wish to participate in a payment transaction
has to enroll on the issuer banks Enrollment server.
At the time of 3-D secure transaction when merchant receives a
payment instruction from cardholder, he forward this request to
issuer bank.
Issuer bank ask cardholder for user id & password which was
created at the time of enrollment process.
Cardholder provides the detail which is verified by the bank.
If authenticated then it accept the card payment.
02/19/15
Vivek Kapoor
105
Electronic Money
Vivek Kapoor
106
%^^A
$ 100
Encrypt with
banks private key
02/19/15
Encrypt with
customers private
key
Vivek Kapoor
Twice
encrypted data
107
Fig.
Customer
$ 100
%^^A
Decrypt with
customers private
key
02/19/15
Original
message
108
02/19/15
Vivek Kapoor
109
Bank
Customer
SR 100
$ 100
Customer
Merchant
SR 100
$ 100
Merchant
Bank
SR 100
02/19/15
Vivek Kapoor
110
02/19/15
Vivek Kapoor
111
Online/Offline money
1.
2.
3.
4.
Vivek Kapoor
112
02/19/15
Vivek Kapoor
113
Email Security
Headers
Body
Regards.
John
02/19/15
Vivek Kapoor
114
Email Security
Sender
Senders
SMTP server
02/19/15
Receiver
SMTP server
Vivek Kapoor
Pull
Receiver
115
Email Security
Here there are two SMTP server's i.e Sender & receiver.
Based on clients request for an email transfer message, server
sends back READY FOR MAIL reply, indicating that it can accept an
email message from the client.
Client sends HELO to the server & identifies itself.
Client can now send one or more email messages to the server.
Email transfer begins with MAIL command that identifies the sender.
Recipient allocates the buffers to store the in coming message &
sends back OK response to the client. Server also sends back
response code 250.
Client now sends the list of intended recipients by one or more
RCPT commands ( one per recipient).
The server must send back a 250 OK or 550.
Client sends DATA command, informing server that client is ready to
start transmission of the email message.
02/19/15
Vivek Kapoor
116
Email Security
02/19/15
Vivek Kapoor
117
Encryption
02/19/15
Non
Repudiation
Vivek Kapoor
Message
integrity
118
3. Encryption
4. Base 64 Encoding
02/19/15
Vivek Kapoor
119
MD5
10001
01010
01010
Encrypt
Digital
Signature
Senders
private key
02/19/15
Vivek Kapoor
120
Here original email & digital signature are encrypted together with a
symmetric key.
For this DES or IDEA is used.
02/19/15
Vivek Kapoor
121
02/19/15
Vivek Kapoor
122
0111010101011101010011100001010
34
45
77
02/19/15
24 bit input
Vivek Kapoor
123
02/19/15
Vivek Kapoor
124
Vivek Kapoor
125
Chapter 3
User Authentic Mechanisms
02/19/15
Vivek Kapoor
127
Introduction
Vivek Kapoor
128
Authentication Basics
02/19/15
Vivek Kapoor
129
Passwords
02/19/15
Vivek Kapoor
130
Vivek Kapoor
131
1.
2.
3.
02/19/15
Vivek Kapoor
132
Here the variation is that not to use password itself but to use
something that is derived from the password.
Here we run some algorithm on the password & store the output of
this algorithm as the (derived) password in the database.
When user wants to get authenticated, the user enters the password
& user computer performs same algorithm locally, & sends the
derived password to the server, where it is verified.
There are several requirements of this scheme:
Each time the algo. Is executed for same password, it must produce
the same output.
Output of algo. Must not provide any clue about the password.
It should be infeasible for any person to provide an incorrect
password, & yet obtain the correct derived password.
These requirements closely match MD5 or SHA-1.
02/19/15
Vivek Kapoor
133
Vivek Kapoor
134
Here attacker may not be able to use the message digest to work
backwards to retrieve the original password.
The attacker can simply listen to the communication between user &
the server involving login request-response pair.
In this he would get the user id & message digest of password.
Attacker will copy that information & submit them after some time to
the server as a new login request.
This is called replay attack because attacker simply replay the
sequence of events of a normal user.
02/19/15
Vivek Kapoor
135
Adding randomness
Vivek Kapoor
136
Adding randomness
Step 4- User signs the random challenge with the message digest of
the password: Here message digest of the password is now used to
encrypt the random challenge received from the server.
Step 5- Server verifies the encrypted random challenge received
from the user: Server receives encrypted random challenge. In
order to verify server must perform following steps:
Server can decrypt the random challenge with the message digest
of the user password stored in the user data base . If decryption
matches the original random challenge available on the server, then
server can be assured.
Step 6- Server returns appropriate message back to the user.
Random challenges are generally 16-bit random numbers.
02/19/15
Vivek Kapoor
137
Password encryption
02/19/15
Vivek Kapoor
138
02/19/15
Vivek Kapoor
139
Password Policies
02/19/15
Vivek Kapoor
140
Authentication Tokens
02/19/15
Vivek Kapoor
141
Authentication Tokens
Step 1: Creation of a token:
When ever authentication token is generated, a random seed is
generated by authentication server.
This seed is stored in the users record in the user data base. User
does not know the value of seed.
Step 2: Use of token :
Authentication token automatically generates pseudorandom
numbers called one time passwords based on the seed value.
User send its user id & this pseudorandom number to the server.
Server calls the seed retrieval program which in turns establish
relationship between pseudorandom no. & seed.
Authentication token is generally protected with 4-digit pin.
Step 3 :Server sends the appropriate message back to the user.
02/19/15
Vivek Kapoor
142
Vivek Kapoor
143
02/19/15
Vivek Kapoor
144
Vivek Kapoor
145
Vivek Kapoor
146
Smart Cards
In certificate based authentication smart cards are used.
Card stores digital certificates, public-private key pairs with in the
card in a tamper free fashion.
Public key & digital certificate can be exported outside.
Smart card capable of performing cryptographic functions within the
card.
If we wish to sign a 1MB document using a smart card then to copy &
perform all cryptographic functions with in the card will require 15
mins at the rate of 9600 bits per second.
So to avoid this first generate a message digest of 1MB document
outside the card then feed it to smart card for cryptographic function.
Drawback of smart cards are non availability of smart card readers,
smart card aware cryptographic services software on every
computers.
Cost of smart card & smart card readers are high.
02/19/15
Vivek Kapoor
147
Biometric Authentication
Vivek Kapoor
148
Kerberos
It is an authentication protocol.
Basis of this protocol is another protocol called Needham-Shroeder.
Kerberos means a multi-headed dog in greek mythology (apperently
used to keep outsiders away).
Version 4 is used in practical implantations, version 5 is also out
now.
There are four parties involved in Kerberos protocol:
Alice: Client work station.
Authentication server (AS): Verifies the user during login.
Ticket Granting server (TGS): Issue tickets to certify proof of identity.
Bob: Server offering services such as network printing, file sharing,
application program etc
02/19/15
Vivek Kapoor
149
KS + TGT
Encrypt
Output
Symmetric key
Randomly generated
User
Name
derived from Alices
session key (KS)
password (KA)
Symmetric key shared by the
Encrypt
ticket granting server (TGS)
Session Key
(KS)
TGT
KS + TGT
02/19/15
Vivek Kapoor
150
Output
Fig.
Alice
AS
02/19/15
Vivek Kapoor
151
Encrypt
Encrypted
Timestamp
TGT
Bob
Output
02/19/15
Vivek Kapoor
152
02/19/15
Vivek Kapoor
153
Output
Fig.
Alice
Bs Secret
key
KAB
Encrypt
Bob
Session
Key (KS)
KAB
Encrypt
Output
02/19/15
Vivek Kapoor
154
02/19/15
Vivek Kapoor
155
Vivek Kapoor
156
Thank You
-----------------------------------------------------------
02/19/15
Vivek Kapoor
157
Chapter 4
Network Security
02/19/15
Vivek Kapoor
158
SMTP
Presentation
FTP
Network
HTTP
TELNET
Session
Transport
DNS
Application
TCP
ICMP
UDP
IP
ARP
RARP
Data Link
Physical
02/19/15
Vivek Kapoor
159
Fig.
Destination
port no.
6 bytes
Reserved
Sequence
no.
Ack No.
6 bytes
2 bytes
Flag
2 bytes
4 bytes
Window
Size
0 to 40 bytes
Urgent
pointer
Options
DATA
02/19/15
Vivek Kapoor
160
IP Datagram Format
Fig.
Version
(4bits)
HELEN
(4bits)
Service
Type(8bits)
Identification(16 bits)
Time to live
(8 bits)
Protocol (8 bits)
Total
Length(4bits)
Flags(3
Fragmentation
bits)
Offset (13 bits)
Header Checksum (16 bits)
02/19/15
Vivek Kapoor
161
Firewalls
In internet any computer can be connected to any other computer in
the world.
This is a great advantage for individuals and corporate.
But it is a nightmare for network support staff to protect the corporate
network from variety of attacks.
There is a possibility of leakage of confidential information as well as
viruses & worms can create havoc.
We encrypt the confidential info. To protect it from outside world.
To protect from outside attacks Firewall comes into the picture.
Firewall is just like a guard which checks all the in coming & outgoing
packets in the corporate network.
A firewall is a specialized version of router which it performs with the
help of additional software resources.
02/19/15
Vivek Kapoor
162
Firewalls
Fig.
Internet
Corporate Network
02/19/15
Vivek Kapoor
Firewall
163
Firewalls
02/19/15
Vivek Kapoor
164
Vivek Kapoor
165
Advantages of packet filters are its simplicity & there fast operating
speed.
Disadvantages are difficulties in setting up packet filter rules & lack
of support for authentication.
Following types of attacks takes place in case of packet filters:
IP address spoofing: An intruder can send packet outside the
network having IP address equal to IP address with in the network.
Source routing attacks: Here attacker specify the route that a packet
should take as it moves with along the internet.
Tiny fragment attacks: IP packets pass through variety of networks
such as Ethernet, Token ring, X.25 etc. So IP packets get
fragmented each time. Attacker feels that packet filter can be fooled,
so that after fragmentation, it checks only 1st fragment & by
intentionally creating the fragments he can intrude into the system.
02/19/15
Vivek Kapoor
166
02/19/15
Vivek Kapoor
167
Vivek Kapoor
168
User thinks that a direct connection between itself & remote host
has been established.
Thus computers from internal users are hidden from outside world.
SOCKS server is an example of the real life implementation.
Socks client runs on the internal hosts & server runs on the firewall.
Thus application gateway act as a proxy of the actual end user &
remote host.
It is more secure than packet filters.
Rather examining every packet against number of rules, here we
simply detect that weather user is allowed to work with TCP/IP
application or not.
Disadvantage is that there is a overhead in terms of connections.
There are two sets of connections: between end user & application
gateway another between application gateway & remote host.
02/19/15
Vivek Kapoor
169
Firewall configurations
02/19/15
Vivek Kapoor
170
Application gateway
Packet filter
Internet
02/19/15
Vivek Kapoor
171
Direct connection between internal host & packet filter are avoided.
Application gateway
Packet filter
Internet
02/19/15
Vivek Kapoor
172
Two packet filters are used one between internet & application
gateway other between application gateway & internal network.
Packet filter
Application gateway
Packet filter
Internet
02/19/15
Vivek Kapoor
173
Internet
DMZ
Firewall
02/19/15
Vivek Kapoor
174
Limitations of firewall
Insider intrusions.
Direct internet traffic.
Virus attacks.
02/19/15
Vivek Kapoor
175