Database security and security in networks

Unit – 5
Database Security and Security in
Networks
1

Index
• Introduction to Database
 Security Requirements
 Reliability and Integrity
 Sensitive Data
 Inference
 Multilevel Database
• Network Security
 Network Concepts
 Threats in Networks
 Security Controls
 Firewalls
 Intrusion Detection System
• Secure Email
2

Database Concepts
• Database
 a collection of data & set of rules that organize the data
 user works with a logical representation of the data
• Relational database
 in the relational model, data is organized as a collection of RELATIONS or tables
 relations is a set of ATTRIBUTES or columns
 each row (or record) of a relation is called a TUPLE
• Database management system (DBMS)
 maintains the DB and controls read write access
• Database administrator (DBA)
 sets the organization of and access rules to the DB
3

Database Concepts
• Relationships between tables (relations) must be in the form of other relations
 base (‘real’) relations: named and autonomous relations, not derived from other relations
(have stored data)
 views: named derived relations (no stored data)
 snapshots: like views are named, derived relations, but they do have stored data
 query results: result of a query - may or may not have name, and no persistent existence
4

Database Concepts
• Within every relation, need to uniquely identify every tuple
 a primary key of a relation is a unique and minimal identifier for that relation
 can be a single attribute - or may be a choice of attributes to use
 when primary key of one relation used as attribute in another relation it is a foreign key in that
relation
5

Database Concepts
• Structured Query Language (SQL)
 to manipulate relations and data in a relational database
• Types of SQL Commands
 Data Dictionary Language (DDL)
 define, maintain, drop schema objects
 Data Manipulation Language (DML)
 SELECT, INSERT, UPDATE
 Data Control Language (DCL):
 control security (GRANT,REVOKE) and concurrent access (COMMIT , ROLLBACK)
6

Security Requirements
• Physical database integrity
• Logical database integrity
• Element integrity
• Auditability
• Access control
• User authentication
• Availability
7

• Physical database integrity
 immunity to physical catastrophe, such as power failures, media failure
 physical securing hardware, UPS
 regular backups
• Logical database integrity
 reconstruction Ability
 maintain a log of transactions
 replay log to restore the systems to a stable point
8

• Element integrity
 integrity of specific database elements is their correctness or accuracy
 field checks
– allow only acceptable values
 access controls
– allow only authorized users to update elements
 change log
– used to undo changes made in error
 referential Integrity (key integrity concerns)
 two phase locking process
• Auditability
 log read/write to database
9

• Access Control (similar to OS)
 logical separation by user access privileges
 more complicated than OS due to complexity of DB (granularity/inference/aggregation)
• User Authentication
 may be separate from OS
 can be rigorous
• Availability
 concurrent users
 granularity of locking
 reliability
10

SQL Security Model
• SQL security model implements DAC based on
 users: users of database - user identity checked during login process;
 actions: including SELECT, UPDATE, DELETE and INSERT;
 objects: tables (base relations), views, and columns (attributes) of tables and views
• Users can protect objects they own
 when object created, a user is designated as ‘owner’ of object
 owner may grant access to others
 users other than owner have to be granted privileges to access object
11

SQL Security Model
• Components of privilege are
 grantor, grantee, object, action, grantable
 privileges managed using GRANT and REVOKE operations
 the right to grant privileges can be granted
• Issues with privilege management
 each grant of privileges is to an individual or to “Public”
 makes security administration in large organizations difficult
 individual with multiple roles may have too many privileges for one of the roles
 SQL3 is moving more to role based privileges
12

SQL Security Model
• Authentication & identification mechanisms
 CONNECT <user> USING<password>
 DBMS may chose OS authentication
 or its own authentication mechanism
 Kerberose
 PAM
13

SQL Security Model
• Access control through views
 many security policies better expressed by granting privileges to views derived from base
relations
 example
CREATE VIEW AVSAL(DEPT, AVG)
AS SELECT DEPT, AVG(SALARY)
FROM EMP GROUP BY DEPT
 access can be granted to this view for every dept mgr
 example
CREATE VIEW MYACCOUNT AS
SELECT * FROM Account
WHERE Customer = current_user()
 view containing account info for current user
14

SQL Security Model
• Advantages of views
 views are flexible, and allow access control to be defined at a description level appropriate to
application
 views can enforce context and data-dependent policies
 data can easily be reclassified
15

SQL Security Model
• Disadvantages of views
 access checking may become complex
 views need to be checked for correctness (do they properly capture policy?)
 completeness and consistency not achieved automatically - views may overlap or miss parts of
database
 security-relevant part of DBMS may become very large
16

SQL Security Model
• Inherent weakness of DAC
 DAC allows subject to be written to any other object which can be written by that subject
 trojan horses to copy information from one object to another
17

SQL Security Model
• Mandatory access controls (MAC)
 no read up, no write down
 traditional MAC implementations in RDBMS have focused solely on MLS
 there have been three commercial MLS RDBMS offerings
 trusted Oracle ,Informix OnLine/Secure, Sybase Secure SQL Server
18

SQL Security Model
• Enforce MAC using security labels
 assign security levels to all data
 label associated with a row
 assign a security clearance to each users
 label associated with the user
 DBMS enforces MAC
 access to a row based upon
– the label associated with that row and the label associated with the user accessing that row.
19

Case Study
RECORDID CLIENTNO DEPTNO ALLOCATION_DATE LAST_UPDATE MEDICAL_HISTORY RISK_FACTOR
0010 K108341 K01 2006/01/05 2006/02/05 Diabetes 0
0020 K104546 K01 2006/10/20 2006/11/05 Arthritis 2
0030 S245987 S02 2006/09/01 2006/10/05 High Blood Pressure 3
0040 S245456 S02 2006/06/26 2006/07/05 Asthma 1
– Medical record analyst
• READ all records
• WRITE all records
– Managers
• READ client records of their department
• READ only non-confidential columns
• No WRITE access
20

Case Study
• Columns
 medical record analysts have READ/WRITE access to confidential columns
 managers have READ access to non-confidential columns
• Rows:
 medical record analysts can read and update all the records
 managers can read but not update client records for their department
21

Case Study: DAC Solution
Three approaches used to provide row level security using DAC (Discretionary
Access Control)
• application views
• programming logic embedded in the application
• physical separation using one or more databases
22

• Application views
• Widely used approach
• Views provide the ability to
filter data.
23

Create view manager_K01 as
select recordid, clientno,
deptno, allocation_date,
last_update,risk_factor
from Med_records
where Dept = ‘K01’;
Create view manager_S01 as
select recordid, clientno, deptno,
allocation_date, last_update, risk_factor
from Med_records
where Dept = ‘S01’;
Create view med_rec_analyst as
select * from Med_records;
24

• Application views
 number of views required is sometimes large as application ages
 directing application users to the correct view becomes management burden
 application complexity tends to increase due to unforeseen security requirements
25

• Application Programmatic Logic Approach
 in this approach, application controls SQL statements outside the application.
26

• Application program logic approach
 SQL statements issued outside the application using utility such as SQL Plus can’t be
controlled
 In scenario of application rewriting SQL statements to restrict access based on data sensitivity,
typically numerous additional tables must be build
 Those tables need to be maintained to manage information related authorizations of
application user
27

• Multiple database approach
• No of databases required is equal to the number of data sensitivities.
• data can be protected by using dedicated databases to manage each
sensitivity
28

• Multiple database approach
 number of databases required is equal to the number of data sensitivities
 overhead created by running multiple databases in terms of memory, processing power and
physical storage is substantially increased
 cost associated of managing single database is multiplied by number of databases
 viewing information across multiple database requires distributed queries and application logic
29

Case Study: MAC Solution
• Designing security solution
 row and column security labels that protect the columns and rows
 user security labels that grant users the appropriate access
30

 revisit the problem
 to restrict access to the column that is confidential, apply confidential security label to the
column
 to restrict managers' access to only the records for their department, each row can be tagged
with a security label that indicates the department.
 write restriction for managers can be implemented by revoking their write privileges.
Position READ WRITE
Medical record analyst ALL ALL
Managers Client records for their department and only non-confidential columns None
31

• a column security label.
• four security labels for row protection
• user security label for medical record analysts
• grant security labels to users
32

SQL Security Model
• Issues with MAC
 information tends to becomes over classified
 no protection against violations that produce illegal information flow through indirect means
 inference Channels - A user at a low security class uses the low data to infer information about
high security class
 covert channels - Require two active agents, one at a low level and the other at a high level and an
encoding scheme
33

Sensitive Data
• Sensitive data is data that should not be made public
• Factors determining sensitivity
 inherently sensitive: The value itself may be so revealing that it is sensitive
 locations of defensive missiles
 from a sensitive source
 CIA informer whose identity may be compromised
 part of a sensitive attribute or a sensitive record
 salary attribute from an HR database
 sensitive with respect to previously disclosed data
 longitude of secret army base if latitude is known
34

Sensitive Data
• Even metadata (data about data) may be sensitive
 bounds: indicating that a sensitive value, y, is between two values, L and H.
 negative Result: disclosing that z is not the value of y may be sensitive. Especially when z has
only small set of possible values
 existence: existence of data is itself may be sensitive piece of data
 probable Value: probability that a certain element has a certain value
35

Security vs. Precision
• Precision: revealing as much non sensitive data as possible
 disclose as much data as possible
 Issue: User may put together pieces of disclosed data and infer other, more deeply hidden, data
• Security: reveal only those data that are not sensitive
 rejecting any query that mentions a sensitive field
 Issue: may reject many reasonable and non disclosing queries
• The ideal combination : perfect confidentiality with maximum precision
 achieving this goal is not easy !
36

Statistical Databases
• A database limited to statistical measures (primarily counts and sums)
• Example: medical record database where researchers access only statistical
measures
• In a statistical database, information retrieved by means of statistical (aggregate)
queries on an attribute
38

Inference
• Security issue with statistical databases
• Inference problem exists when sensitive data can be deduced from non sensitive
data
 attacker combines information from outside the database with database responses
39

Inference
• Sensitive fields exist in database
• Only when viewed row wise
• DBA must not allow names to be associated with sensitive attributes
• “n items over k percent” rule (do not respond if n items represents over k% of the
result)
40

Inference
SSN Name Race DOB Sex Zip Marital Heath
Asian 09/07/64 F 22030 Married Obesity
Black 05/14/61 M 22030 Married Obesity
White 05/08/61 M 22030 Married Chest pain
White 09/15/61 F 22031 Widow Aids
•Anonymous medical data:
Name Address City Zip DOB Sex Party
…. …. …. …. …. …. ….
Sue Carlson 900 Market
St.
Fairfax 22031 09/15/61 F Democrat
•Public available voter list:
•Sue Carlson has Aids!
41

Inference
• Types of attack
 direct attack: aggregate computed over a small sample so individual data items leaked
 indirect attack: combines several aggregates;
 tracker attack: type of indirect attack (very effective)
 linear system vulnerability: takes tracker attacks further, using algebraic relations between
query sets to construct equations yielding desired information
42

Inference
NAME SEX RACE AID FINES DRUGS DORM
Adams M C 5000 45 1 Holmes
Bailey M B 0 0 0 Grey
Chin F A 3000 20 0 West
Dewitt M B 1000 35 3 Grey
Earhart F C 2000 95 1 Holmes
Fein F C 1000 15 0 West
Groff M C 4000 0 3 West
Hill F B 5000 10 2 Holmes
Koch F C 0 0 1 West
Liu F A 0 10 2 Grey
Majors M C 2000 0 2 Grey
43

Inference
• Direct Attack
 determine values of sensitive fields by seeking them directly with queries that yield few
records
 request LIST which is a union of 3 sets
LIST NAME where (SEX =M  DRUGS = 1) 
(SEX  M  SEX F)  (DORM = Ayres)
 No dorm named Ayres , Sex either M or F
 “n items over k percent” rule helps prevent attack
44

Inference
Indirect attack: combines several aggregates
 1 Male in Holmes receives 5000
 1 Female in Grey received no aid
 request a list of names by dorm (non sensitive)
Students by Dorm and Sex
Holmes Grey West Total
M 1 3 1 5
F 2 1 3 6
Total 3 4 4 11
Sums of Financial Aid by Dorm and Sex
M 5000 3000 4000 12000
F 7000 0 4000 11000
Total 12000 3000 8000 23000
45

Inference
• Often databases protected against delivering small response sets to queries
• Trackers can identify unique value
 request (n) and (n-1) values
 given n and n – 1, we can easily compute the desired single element
46

Inference
• How many caucasian females live in Holmes Hall?
 count((SEX=F)(RACE=C) (DORM=Holmes)
 result: refused because one record dominates the result
 now issue two queries on database
 count(SEX=F) response = 6
 count((SEX=F) (RACE C) (DORM Holmes)) response=5
 thus 6-5=1 females live in Holmes Hall
47

Inference
• Tracker is a specific case of ‘Linear system vulnerability’
 result of the query is a set of records
 q1 = c1+c2+c3+c4+c5
 q2 = c1+c2 +c4
 q3 = c3+c4
 q4 = c4+c5
 q5 = c2 +c5
 we can obtain c5 = ((q1 – q2) – (q3 –q4))/2
 all other c can be derived
48

Inference
• Protection techniques
• Only queries disclosing non sensitive data allowed
 difficult to discriminate between queries
 effective primarily against direct attacks
• Controls applied to individual items within the database
 suppression: don’t provider sensitive data
 concealing: provider slightly modified value
49

Inference
• “n item over k percent rule” not sufficient in itself prevent inference
• We must suppress one other value in each row and column to disallow
Students by Dorm and Sex, with Low Count
Suppression
M – 3 – 5
F 2 – 3 6
Total 3 4 4 11
50

Inference
• Suppression by Combining results
 combines rows or columns to protect sensitive values
Suppression by Combining
Revealing Values
Drug Use
Sex 0 or 1 2 or 3
M 2 3
F 4 2
51

Inference
• Random sample
 partition data and take random sample from partition
 equivalent queries may or may not result in the same sample
• Random data perturbation
 intentionally introduce error into response
• Query analysis
 history Driven
 difficult
52

Aggregation
• Aggregation problem exists when the aggregate of two or more data items is
classified at a level higher than the least upper bound of the classification of the
individual items that comprise the aggregate
 the data items multiple instances of same entity
• Addressing the aggregation problem is difficult
 requires the DBMS to track what results each user had already received
 it can take place outside the system
 relatively few proposals for countering aggregation
53

Aggregation
• Data association: A sub-problem of aggregation
 data association – sensitive associations between instances of two or more distinct data items
 (cardinal) aggregation - associations among multiple instances of the same entity
54

Inference vs. Aggregation
• They are similar but different
 inference: sensitive data deduced from non sensitive data
 relatively easier problem
 protection by means of control over query , data and other ways
 aggregation: multiple instances of entity result in sensitive data
 difficult problem
 protection requires the DBMS to track what results each user had already received
55

Multilevel Databases
• Data sensitivity not black or white
 exist shades of sensitivity
 grades of security may be needed
• So far we seen sensitivity a function of the attribute (column)
 e.g. ‘Drug use’ column sensitive
• Actually sensitivity not function of column or row
 the security of one element may be different from that of other elements of the same row or
column
 security implemented for each individual element
56

Data and Attribute Sensitivity
Name Department Salary Phone Performance
Rogers training 43,800 4-5067 A2
Jenkins research 62,900 6-4281 D4
Poling training 38,200 4-4501 B1
Garland user services 54,600 6-6600 A4
Hilten user services 44,500 4-5351 B1
Davis admin 51,400 4-9505 A3
57

• Leads to Multi Level Security Model
 n levels of sensitivity
 objects separated into compartments by category
 sensitivity marked for each value in database
 every combination of elements can also have a distinct sensitivity
 access control policy dictate which users may have access to what data
58

• To preserve Integrity , DBMS must enforce “No write down” (*-property)
 the process that reads high level data cannot write to a lower level
 issue: DBMS must read all records and write new records for backups, query processing etc
 solution: trusted process
• Preserving confidentiality
 issue: Leads to redundancy
59

• Polyinstantiation
 different users operating at two different levels of security might get two different answers to
the same query
 one record can appear (be instantiated) many times, with a different level of confidentiality
each time
Polyinstantiated Records
Name Sensitivity Assignment Location
Hill, Bob C Program Mgr London
Hill, Bob TS Secret Agent South Bend
60

Future Direction
• Civilian users dislike inflexibility of MLS databases
 MLS databases primarily research interest
• Privacy concerns fueling interest in database security
 hippocratic database
 database design that takes consumer privacy into account in the way it stores and retrieves
information
61

Example of steps to implement LBAC:
1. Defining the security policies and labels
a. Defining the security label component
CREATE SECURITY LABEL COMPONENT SLC_LEVEL
SET {'CONFIDENTIAL'}
CREATE SECURITY LABEL COMPONENT SLC_LIFEINS_ORG TREE {'LIFE_INS_DEPT' ROOT,
'K01' UNDER 'LIFE_INS_DEPT',
'K02' UNDER 'LIFE_INS_DEPT',
'S01' UNDER 'LIFE_INS_DEPT',
'S02' UNDER 'LIFE_INS_DEPT' }
b. Defining the security policy
CREATE SECURITY POLICY MEDICAL_RECORD_POLICY COMPONENTS SLC_LEVEL, SLC_LIFEINS_ORG
WITH DB2LBACRULES
RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL
62

c. Defining the security labels
CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MED_RECORD COMPONENT
SLC_LEVEL 'CONFIDENTIAL'
For each department,
CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.LIFEINS_DEPT_K01 COMPONENT
SLC_LIFEINS_ORG 'K01'
For Medical analyst
CREATE SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST
COMPONENT SLC_LEVEL 'CONFIDENTIAL', COMPONENT SLC_LIFEINS_ORG
'K01', 'K02', 'S01', 'S02'
63

2. Altering the MEDICAL_RECORD table by adding a security label column for row level
protection, marking the confidential column as protected, and attaching the security policy to
the table.
GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.MEDICAL_ANALYST TO USER <administrator_auth_id>
FOR ALL ACCESS
ALTER TABLE MEDICAL_RECORD ALTER COLUMN MEDICAL_HISTORY SECURED WITH
MEDICAL_RECORD_POLICY.MED_RECORD ADD COLUMN DEPARTMENT_TAG DB2SECURITYLABEL ADD
SECURITY POLICY MEDICAL_RECORD_POLICY
64

3. Updating the MEDICAL_RECORD table security label column.
GRANT EXEMPTION ON RULE DB2LBACWRITETREE FOR MEDICAL_RECORD_POLICY TO USER
<administrator_auth_id>
For each department,
UPDATE MEDICAL_RECORD set DEPARTMENT_TAG= SECLABEL_BY_NAME
('MEDICAL_RECORD_POLICY', 'DEPT_K01') where DEPTNO='K01'
65

LBAC(Label Based Access Control)
4. Granting the appropriate security labels to users.
GRANT SECURITY LABEL MEDICAL_RECORD_POLICY. MEDICAL_ANALYST TO USER PETER
FOR ALL ACCESS
GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_K01 TO USER Andrea FOR ALL
ACCESS
GRANT SECURITY LABEL MEDICAL_RECORD_POLICY.DEPT_S02 TO USER Joseph for ALL
ACCESS
66

Network Security
Network Concepts, Threats in Networks, Security Controls, Firewalls, Intrusion Detection System
67

Threats in Network
 Intercepting data in traffic
 Accessing programs or data at remote hosts
 Modifying programs or data at remote hosts
 Modifying data in transit
 Inserting communications
 Impersonating a user
 Inserting a repeat of a previous communication
 Blocking selected traffic
 Blocking all traffic
 Running a program at a remote host
68

Security Threat Analysis
• 3 steps in analyzing a security threat:
 Scrutinize all the parts of the systems
 Consider the possible damage to confidentiality, integrity, & availability
 Hypothesize the kinds of attacks that could cause the specific kind of damage
• Similar approach can be taken to analyze threats in a network.
69

What an Attacker Might Do?
• Read communication
• Modify communication
• Forge communication
• Inhibit communication
• Inhibit all communication passing through a point
• Read data at some machine C between two people
• Modify or destroy data at C
70

Security Controls
• Can be implemented at different levels
• Compliant with different security requirements
• Have some advantages and drawbacks depending on the scenario
71

Architectural Security Control 1
• Segmentation
 It reduces the number of
threats
 It limits the amount of
damage a single
vulnerability
can allow
72
Segmented Architecture

Architectural Security Control 2
 Redundancy
 It allows a function to be performed on more than one node
 Failure over mode- The server communicates with each other periodically, each determining if
the other is still active.
 Single points of failure
 Eliminating a single point in the network which if failed, could deny access to all or a
significant part of the network
 Mobile agents
73

Encryption
 Encryption is the most important & versatile tool for a network security expert.
 Encryption is used for providing:
 Privacy
 Authenticity
 Integrity
 Limited access to data
 Note: Encryption protects only what is encrypted
74

Kinds of Encryption 1
• Link Encryption
 Data are encrypted just before the system places them on the physical communication link
 Encryption occurs at layer 1 or 2 in the OSI model
 Encryption protects the message in transit between two computers
 This kind of encryption is invisible to user
 It is most appropriate when the transmission line is the point of greatest vulnerability
75

Kinds of Encryption 2
• End-to-End Encryption
 It provides security from one end of a transmission to the other
 The message is transmitted in encrypted form through the network
 It addresses potential flaws in lower layers in the transfer model
 When used, messages sent through several hosts are protected
76

Virtual Private Networks (VPN)
 VPN allows users to access their internal networks and computers over the
Internet or other public network, using encrypted tunnels (communication passes
through encrypted tunnel).
 VPN are created when the firewall interacts with an authentication service inside
the parameter.
 Firewall
 It is an access control device that sits between two networks or two network segments.
 It filters all traffic between the protected or “inside” network and a less trustworthy or
“outside” network or segment.
77

Public Key Infrastructure (PKI)
• PKI
 It is a set of policies, products, & procedures leaving some room for interpretation.
 It is a process created to enable users to implement public key cryptography, usually in large
settings.
 It offers each user a set of services related to identification & access control.
 It sets up entitles called certificate authorities that implement the PKI policy on certificates.
 It is not yet a mature process.
78

Encryption
 SSH (Secure Shell) encryption
 A pair of protocols, originally defined for UNIX
 It provides authenticated and encrypted path to the shell or operating system command
interpreter.
 SSL (Secure Sockets layer) encryption
 It is also known as TLS (Transport Layer Security)
 It was originally designed by Netscape
 It interfaces between applications and the TCP/IP protocols to provide server authentication,
optional client authentication, & an encrypted communication channel between client & server.
79

IP Security Protocol Suite (IPSec)
 IPSec
 It is designed to address fundamental shortcomings such as being subject to spoofing,
eavesdropping, & session hijacking.
 It is implemented at the IP layer
 It is somewhat similar to SSL (supports authentication & confidentiality in a way that does not
necessitate significant change either above or below it)
 Security association
 The basis of IPSec
 It is roughly compared to an SSL session
80

Related Terms
 Security Parameter Index (SPI)
 A data element that is essentially a pointer into a table of security associations.
 Encapsulated Security Payload (ESP)
 It replaces (includes) the conventional TCP header and data portion of a packet.
 It contains both an authenticated header (AH) and an encrypted portion.
 Internet Security Association Key Management Protocol (ISAKMP)
 It requires that a distinct key be generated for each security association.
 It is implemented through IKE or ISAKMP key exchange
81

Content Integrity
• Three potential threats:
 Malicious modification that changes content in a meaningful way
 Malicious or non-malicious modification that changes content in a way that is not necessarily
meaningful
 Non-malicious modification that changes content in a way that will not be detected
82

Guard Modification Threats
• Error correcting codes
 Error detection & error correcting codes can be used to guard against modification in a
transmission.
 Parity Check is the simplest error detection code technique.
 Even Parity – the parity bit is set so that the sum of all data bits plus the parity bit is even.
 Odd Parity – It is similar to the even parity bit except the sum is odd.
 Hash code or Huffman code are some other error detection codes
83

Cryptographic Checksum
• Cryptographic Checksum (Message Digest)
 It is a cryptographic function that produces a checksum.
 It prevents the attacker from changing the data block.
 Major uses of cryptographic checksum are code tamper protection & message integrity
protection in transit.
84

Authentication Methods
 One-Time Password
 It is good for only one time use
 A password token can help in generating unpredictable passwords
 This technique is immune to spoofing as it works on a password generating algorithm
 Challenge-Response System
 It looks like a simple pocket calculator
 This device eliminates the small window of vulnerability in which a user could reuse a time-
sensitive authenticator
 Digital Distributed Authentication
85

Access Controls
• ACLs on Routers
 Problems on adding ACLs to the routers
 Routers in a large network perform a lot of work
 Efficiency issues
 Nature of threat
• Firewalls
 Can examine an entire
packet’s content, including
the data portion.
86
Access to Services & Servers in Kerberos

Wireless Security 1
 Service Set Identifier (SSID)
 It is the identification of an access point
 It is a string of up to 32 characters
 Wired Equivalent Privacy (WEP)
 It uses an encryption key shared between the client and the access point.
 It uses either a 64bit or 128 bit encryption key.
 WiFI protected access (WPA)
 It is an alternate to WEP
 The encryption key is changed automatically on each pocket by a key change approach called
Temporal Key Integrity Program (TKIP)
87

Wireless Security 2
 Alarms & Alerts
 An intrusion detection system is a device that is placed inside a protected network to monitor
what occurs within the network.
 Honey pots
 Loaded with servers, devices & data; it is a computer system or a network segment.
 A honeypot is put up for several reasons
 To watch what attackers do
 To lure an attacker to a place where you can identify and stop the attacker
 To provide an attractive but diversionary playground
88

Wireless Security 3
• Traffic Flow Security
 Onion routing – messages are repeatedly encrypted and then sent through several network
89
Onion Routing

Summary 1
90
Target Vulnerability Control
Authentication
Failures
•Impersonation
•Eavesdropping
•Spoofing
•Man-in-the Middle Attack
•Strong, One-Time
Authentication
•Encrypted Authentication
Channel
•Strong, One-Time
Authentication
• Strong, One-Time
Authentication
•VPN
•Protocol Analysis

Summary 2
91
Programming
Flaws
•Buffer Overflow
•Parameter
Modifications
•Programming Controls
•Personal Firewall
•Intrusion Detection System
•Personal Firewall
Confidentiality •Protocol Flaw
•Eavesdropping, Passive
Wiretap, Mis-delivery
•Cookie
•Programming Controls
•Controlled Execution
Environment
•Encryption
•Firewall

Summary 3
92
Integrity •Protocol Flaw
•Active Wiretap
•Noise
•DNS Attack
•Controlled Execution Environment
•Audit
•Encryption
•Error Detection Code
•Error Detection Code
•Firewall
•Strong Authentication for DNS
Changes
•Audit

Summary 4
93
Availability •Protocol Flaw
•DNS Attack
•Traffic Redirection
•DDoS
•Firewall
•Redundant Architecture
•Firewall
•ACL on Border Router
•Honeypot
•Encryption
•Audit
•ACL on Border Router
•Honeypot

Firewalls
94
What Is a Firewall?
• A device that filters all traffic between a protected or "inside” network and a less trustworthy or "outside”
network.
• The purpose of a firewall is to keep "bad" things outside a protected environment.
Types of Firewall
• packet filtering gateways or screening routers
• stateful inspection firewalls
• application proxies
• Guards
• personal firewalls

Packet Filtering Gateway
• A packet filtering gateway or screening router is the simplest, and in some
situations, the most effective type of firewall.
95

Stateful Inspection and Application Proxy Firewall
• A stateful inspection firewall maintains state information from one packet to
another in the input stream.
• An application proxy gateway, also called a bastion host, is a firewall that
simulates the (proper) effects of an application so that the application receives
only requests to act properly.
• A proxy gateway is a two-headed device: It looks to the inside as if it is the
outside (destination) connection, while to the outside it responds just as the insider
would.
96

Guard
• A sophisticated firewall.
• Like a proxy firewall, it receives protocol data units, interprets them, and passes
through the same or different protocol data units that achieve either the same result
or a modified result.
• The guard decides what services to perform on the user's behalf in accordance
with its available knowledge, such as whatever it can reliably know of the
(outside) user's identity, previous interactions, and so forth.
• The degree of control a guard can provide is limited only by what is computable.
• But guards and proxy firewalls are similar enough that the distinction between
them is sometimes fuzzy.
97

Personal Firewalls
• An application program that runs on a workstation to block unwanted traffic,
usually from the network.
98

Intrusion Detection System
99
• An intrusion detection system (IDS) is a device, typically another separate computer, that monitors
activity to identify malicious or suspicious events.

Functions of IDS
• IDSs perform a variety of functions:
 monitoring users and system activity
 auditing system configuration for vulnerabilities and misconfigurations
 assessing the integrity of critical system and data files
 recognizing known attack patterns in system activity
 identifying abnormal activity through statistical analysis
 managing audit trails and highlighting user violation of policy or normal activity
 correcting system configuration errors
 installing and operating traps to record information about intruders
100

Types of IDS
• The two general types of intrusion detection systems
 Signature-based intrusion detection systems perform simple pattern-matching and report
situations that match a pattern corresponding to a known attack type.
 Heuristic intrusion detection systems, also known as anomaly based, build a model of
acceptable behavior and flag exceptions to that model Intrusion detection devices.
• A network-based IDS is a stand-alone device attached to the network to monitor
traffic throughout that network;
• A host-based IDS runs on a single workstation or client or host, to protect that
one host.
101

Signature-Based Intrusion Detection
• The problem with signature-based detection is the signatures themselves.
• An attacker will try to modify a basic attack in such a way that it will not match
the known signature of that attack.
• Signature-based IDSs cannot detect a new attack for which a signature is not yet
installed in the database.
• Tend to use statistical analysis
102

Heuristic Intrusion Detection
• Instead of looking for matches, heuristic intrusion detection looks for behavior
that is out of the ordinary.
• The inference engine of an intrusion detection system performs continuous
analysis of the system, raising an alert when the system's dirtiness exceeds a
threshold.
• Inference engines work in two ways.
 state-based intrusion detection systems, see the system going through changes of overall state
or configuration.
 model-based intrusion detection systems, try to map current activity onto a model of
unacceptable activity and raise an alarm when the activity resembles the model.
103

Stealth Mode
• Most IDSs run in stealth mode, whereby an IDS has two network interfaces: one
for the network (or network segment) being monitored and the other to generate
alerts and perhaps other administrative needs.
104

Goals for IDS
• Filter on packet headers
• Filter on packet content
• Maintain connection state
• Use complex, multipacket signatures
• Use minimal number of signatures with maximum effect Filter in real time, online
• Hide its presence
• Use optimal sliding time window size to match signatures
105

Responding to Alarms
• Whatever the type, an intrusion detection system raises an alarm when it finds a
match
• In general, responses fall into three major categories (any or all of which can be
used in a single response): Monitor, collect data, perhaps increase amount of data
collected Protect, act to reduce exposure
• Call a human
106

False Results
• Although an IDS might detect an intruder correctly most of the time, it may
stumble in two different ways:
 Raising an alarm for something that is not really an attack (called a false positive, or type I
error in the statistical community)
 Not raising an alarm for a real attack (a false negative, or type II error).
• Too many false positives means the administrator will be less confident of the
IDS's warnings, perhaps leading to a real alarm's being ignored.
• But false negatives mean that real attacks are passing the IDS without action.
• We say that the degree of false positives and false negatives represents the
sensitivity of the system.
107

Threats to Email
109
• Consider threats to electronic mail:
• message interception (confidentiality)
• message interception (blocked delivery)
• message interception and subsequent replay message
• content modification
• message origin modification
• message content forgery by outsider message origin forgery by outsider
• message content forgery by recipient message origin forgery by recipient
• denial of message transmission

Requirements and Solutions
• If we were to make a list of the requirements for secure e-mail, our wish list would
include the following protections.
• Message confidentiality (the message is not exposed en route to the receiver)
• Message integrity (what the receiver sees is what was sent)
• Sender authenticity (the receiver is confident who the sender was)
• Non-repudiation (the sender cannot deny having sent the message)
110

References
• Pfleeger, “Security in Computing”, 3rd ed, 2003(Chapter 8)
113

Database security and security in networks

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Database security and security in networks

Similar to Database security and security in networks (20)

More from G Prachi

More from G Prachi (20)

Recently uploaded

Recently uploaded (20)

Database security and security in networks