Unformatted text preview: Security in Computing – CSC 607
Security
Wireless Security – WCM 605
Wireless
Meeting 6 Thursday, 21 Jan, 2010 1/21/2010
1/21/2010 1 Week 3 Schedule
Tue 1/19 Mid Term Exam Security and the Layered Architecture II Form Teams for Breaking WEP Projects
Thu 1/21 Week 2 Small Group Project Presentations Database Security Security Planning, Policy and Administration Voice Oriented Wireless Networks I
Week 3 Reading – Pfleeger & Pfleeger 4th Edition Chapters 6 and 8
Chandra Chapter 3 pp 7584, Chapter 4, Chapter 5
Written Assignment B due by midnight, Saturday, Jan 23 1/21/2010
1/21/2010 2 Database Security 1/19/2010
1/19/2010 3 Outline Database Concepts and Components
Security Requirements of Databases
• Integrity and Reliability Confidentiality
•
• 1/19/2010
1/19/2010 Protection of Sensitive Data
Attacking via Inference Multilevel Data Bases and Multilevel Security
4 Database Concepts and
Database
Terminology
Terminology A database is: • A collection of data PLUS • A set of rules 1/19/2010
1/19/2010 The rules organize the data by specifying relationships among the data Data items are stored in a file
User interact with the database through a Database Management System (DBMS) 5 Database Components A database file consists of records
Each record contains fields (also known as elements)
A twodimensional matrix is a typical view of a database:
• Each row is a record
• Columns correspond to different fields 1/19/2010
1/19/2010 The logical structure of a database is called a schema 6 Simple Database Example
Name
ADAMS
ADAMS
BENCHLEY
CARTER
CARTER
CARTER
CARTER
CARTER First
Charles
Edward
Zeke
Marlene
Beth
Ben
Lisabeth
Mary Address
212 Market St.
212 Market St.
501 Union St.
411 Elm St.
411 Elm St.
411 Elm St.
411 Elm St.
411 Elm St. City
Columbus
Columbus
Chicago
Columbus
Columbus
Columbus
Columbus
Columbus State
OH
OH
IL
OH
OH
OH
OH
OH Zip
Airport
43210 CMH
43210 CMH
60603 ORD
43210 CMH
43210 CMH
43210 CMH
43210 CMH
43210 CMH Users retrieve, modify, add or delete fields and records in a database file through commands known as queries
• 1/19/2010
1/19/2010 Typically using Structured Query Language (SQL) 7 Advantages of Using Databases Shared Access • Single, common, centralized set of data Minimal Redundancy • No need for users to collect/maintain their own data Data Consistency • Changes affect all users of that datum Data Integrity • Data values protected against accidental or malicious changes Controlled Access • Only authorized users are allowed to view/modify 1/19/2010
1/19/2010 8 Basic Security Requirements of a
Basic
DB System
DB Physical Database Integrity
Logical Database Integrity
Element Integrity
Auditability
• Not feasible to log all details Access Control • Much more complicated than for an OS User Authentication • Supplementary to OS Availability • DBMSs require HIGH availability 1/19/2010
1/19/2010 9 Whole Data Base Integrity
• Issue: Protection against corruption by program or person • Solution: Updates only by authorized individuals • Issue: Protection against corruption from outside force, e.g. power failure, fire, … • Solution: Regular backups of all files Maintain transaction log to allow reconstruction 1/19/2010
1/19/2010 10 Data Base Element Integrity Issue: Potential for inaccurate elements
Solutions:
• Field Checks Tests for appropriate values Range comparisons State constraints
Transition constraints • Access Controls No simultaneous updates
Sequence control, when appropriate • Maintenance of a Change Log
• Twophase Update Prepare all values to be changed during Intent Phase, but make no updates
Change values only during Commit Phase
• No new intents allowed during Commit Phase 1/19/2010
1/19/2010 11 Data Base Confidentiality Protection of Sensitive Data • Sensitive = data that should not be made public Nothing Sensitive – no issue
Everything Sensitive – relatively easy to handle
Some data elements more sensitive than others – complicated • Security concerns not only the individual data elements, but also their context and meaning 1/19/2010
1/19/2010 12 Data Sensitivity Factors Definition of Sensitive Data:
• Should not be made public Data may be:
•
•
•
• Inherently sensitive
From a sensitive source
Declared sensitive
Part of a sensitive attribute or record e.g a “salary” field • Sensitive in relation to previously disclosed information All of these factors must be considered in determining the sensitivity of data
1/19/2010
1/19/2010 13 Decisions to Grant Access to Data Factors to consider are:
• Availability of data Access may be denied during an update • Acceptability of Access Access may be denied because of what may be indirectly derived or inferred • Assurance of Authenticity Additional requirements may be applied • Access during working hours only
• May limit repeated requests for the same date 1/19/2010
1/19/2010 14 Data Disclosure
What can be disclosed includes:
•
•
•
•
• The actual data
Bounds or limits on data values
What data IS NOT
The existence of a data element
Probable value of data
A successful strategy must protect from both direct and indirect disclosure 1/19/2010
1/19/2010 15 Security vs. Precision Precision: • Protect all sensitive data • Reveal as much nonsensitive data as possible Ideal: Disclose ALL and ONLY the nonsensitive data
1/19/2010
1/19/2010 16 The Inference Problem – Deriving
The
Sensitive Data from Non-Sensitive
Data
Data
Attack Methods • Direct Attack Use queries that yield one or few records • Indirect Attack Sums • Can sometimes infer a negative result from a total Counts • Often combined with sums to reveal data Intersecting Medians • Tracker Attack Multiple queries that cancel out everything except the one data item desired • Linear System Attack 1/19/2010
1/19/2010 Generalization of solution of system of linear equations
17 Controls to Prevent Inference
Controls
Attacks
Attacks Two Kinds of Controls – Suppress or Conceal
Three approaches:
• Suppress sensitive data Query rejected without response Primarily effective against direct attacks
Example: nitem kpercent rule • Conceal or Disguise Data Reveal approximate but not exact value
Combine rows or columns to protect sensitive values
Reveal from a random sample • Track what the user knows 1/19/2010
1/19/2010 Query Analysis There is no perfect solution to the inference problem 18 Aggregation 1/19/2010
1/19/2010 Definition: Building sensitive results from less sensitive inputs
Example: adding longitude to known latitude of gold mine
The basic method used by police in crimesolving
The rise (and success) of Data Mining has increased concerns about aggregation
There are few proposals for countering aggregation 19 Multilevel Database Issues Security of an element in a row or column may differ from security of other elements in a record
More than two levels – secure and non
secure – may be needed
Security of an aggregate (sum, count, group of values) may be higher or lower than security of the individual elements making up the aggregate “Primarily of research and historical interest”
1/19/2010
1/19/2010 •Civilian users don’t like inflexibility of military security
•Too few military users 20 Requirements and Issues Requirements
Sensitivity at the Element Level
Sensitivity Requirements: Two General Concerns:
Confidentiality 1. Can lead to polyinstantiation
Care is needed to avoid eliminating legitimate duplications Integrity 2. 1/19/2010
1/19/2010 An Access Control Policy
A guarantee that the element has not been changed by an unauthorized person Either the process cleared at a higher level cannot write to a lower level
OR The process must be a trusted process 21 Multilevel Security Approaches - I Partitioning
•
• Physically separate, isolated databases
Can destroy the reason for having a database Encryption • Different key for each level of sensitivity
Can be defeated by plaintext attack User can substitute fake data • Different key for each element Eliminates above problems Introduces MUCH more processing → not often used 1/19/2010
1/19/2010 22 Multilevel Security Approaches - II
Integrity Lock provides both integrity and limited access
• Checksum is computed across both data and sensitivity mark • Sensitivity label must be:
Unforgeable
Unique
Concealed •Cryptographic checksum includes: Something unique to the record
Something unique to the data field
Value of the element
Sensitivity classification 1/19/2010
1/19/2010 23 Multilevel Security Approaches - III Sensitivity Lock combines •
•
• Unique identifier Sensitivity level
Key Each lock: • Relates to one record
• Protects secrecy of sensitivity level 1/19/2010
1/19/2010 24 Multilevel Secure Database
Multilevel
Designs
Designs Integrity Lock
Trusted Front End
Commutative Filters
Distributed Databases
Restricted View
Design choice depends on tradeoff among:
• Efficiency
• Flexibility
• Simplicity
• Trustworthiness 1/19/2010
1/19/2010 25 Integrity Lock Design Concept: Shortterm solution
Approach: Combine untrusted database manager with trusted access control
Issues:
•
•
• 1/19/2010
1/19/2010 Substantial increase in processing time
Significantly expands memory required
Subject to Trojan Horse attacks 26 Trusted Front End Concept: Guard that operates like a Reference Monitor
Approach: Trusted front end serves as oneway filter, screening out results user should not be able to access
Issue:
• Inefficient; much data gets retrieved and discarded 1/19/2010
1/19/2010 27 Commutative Filter Concept: Screen user requests, reformatting as necessary, so only data of appropriate sensitivity level are returned to user
Approach: Multistep process
•
•
• 1/19/2010
1/19/2010 Reformat queries in a trustable way First screen out unacceptable records, Second screen retrieves only data allowable under users clearance level 28 Distributed Databases Concept: Trusted frontend controls access to two unmodified commercial DBMS
Approach: Front end separates user queries into single queries to those databases which user is cleared to access
• Query is never submitted to a DB for which user is not cleared
• Front end combines results, if user has access to both DBs Issues: • Front end must be trusted → high complexity Front end may become a full DBMS in itself • Design does not scale easily to many degrees of sensitivity 1/19/2010
1/19/2010 29 Restricted View Concept: Each user is restricted to a picture of the data reflecting only what the user needs to see
Approach: • •
• 1/19/2010
1/19/2010 Contents of original data are filtered so that user sees only acceptable items
View includes both elements and their relationships
User can create new relationships that are accessible to others with same permission level Advantage: Makes views a logical division and functional division of a DB Layers 1, 2 and 3 make up the Trusted Computing Base (TCB) of the system 30 Security Planning, Policy and
Security
Administration
Administration 1/21/2010
1/21/2010 31 Outline 1/21/2010
1/21/2010 Security Planning
Risk Analysis
Security Policies
Physical Security 32 Evolution of Security
Evolution
Responsibilities
Responsibilities 1960s1970s – Large mainframe era • Security was responsibility of the computing center 1985present • Shift to personal computers but many users have not assumed security responsibilities formerly performed by computing centers. Users: 1/21/2010
1/21/2010 Do not appreciate or understand risks
Choose to ignore risks Every application has requirements for:
• Confidentiality
•Data
• Integrity
•Programs
related to
• Availability
•Computing Equipment
33 Security Plan •
•
•
• 1/21/2010
1/21/2010 A document that describes how an organization will address its security needs
An official record of current practices
A blueprint for orderly change
Alerts/notifies employees that security is important
Subject to periodic review and revision Addresses seven issues 1.
2.
3.
4.
5.
6.
7. Policy
Current Status
Requirements
Recommended Controls
Accountability
Timetable
Structure for Periodic Updates 34 Policy Statement Addresses three issues:
•
•
•
•
•
• 1/21/2010
1/21/2010 Who should be allowed access
What should they be allowed to access
What types of access should be allowed
The organization’s security goals
Who has responsibility for security
The organization’s commitment to security Policy Statement specifies: 35 Current Security Status & Security
Current
Requirements
Requirements Current Security Status
•
•
•
• Based on understanding of vulnerabilities
Vulnerabilities identified through risk analysis
Defines limits/boundaries of responsibilities
Identifies process to be followed upon identification of new vulnerabilities Security Requirements
•
•
•
• The heart of the plan
Distinct from constraints and controls
Describe what should be accomplished; NOT how
Requirements Characteristics: 1/21/2010
1/21/2010 Correctness
Consistency
Completeness
Realism
Need
Verifiability
Traceability 36 Other Parts of the Security Plan Recommended Controls – the how • Based on mapping of vulnerabilities to controls through risk analysis Responsibilities for implementation • Who is responsible
• Who is accountable if a requirement is NOT met Timetable – phased implementation • Specifies the order in which controls are to be implemented
• Procedure for change and growth 1/21/2010
1/21/2010 Plan for periodic review of security • How new equipment/applications will be addressed
• May be timebased or eventbased 37 Security Planning Team Members Each of the following groups should be represented:
•
•
•
•
•
•
• Computer Hardware Group
System Administrators
Systems Programmers
Applications Programmers
Data Entry Personnel
Physical Security Personnel
Representative Users •Team must be sensitive to needs of all stakeholders
•Stakeholders must understand impact of plan on them
•Management commitment must be secured 1/21/2010
1/21/2010 38 Coping with Disasters – Business
Coping
Continuity Plans
Continuity Steps in developing a business continuity plan: • Assess business impact of a crisis Identify essential assets
• Determine what could disrupt use of essential assets
• Develop strategy to cope with disruptions Strategy analysis Best actions organized by circumstances • Develop and implement a plan for the strategy 1/21/2010
1/21/2010 Who is in charge when an incident occurs?
What to do?
Who does it? 39 Incident Response Plan How to deal with a security incident
Defines what constitutes an incident
Identifies response team and policy
Describes the action plan
• Advance planning •
•
• Legal Issues
Gathering and Preserving Evidence
Maintaining Records
Handling Public Relations Triage
Running the Incident
Postincident review after situation abates Does not address business issues • Business issues are addressed by the Business Continuity Plan 1/21/2010
1/21/2010 40 Risk Analysis Risk analysis addresses how to deal with those problems that cannot be avoided
Three things characterize a risk • Risk impact – the loss associated with a risk The likelihood that the risk will occur How much the risk can be reduced through:
• Avoidance
• Transference to other systems/ people/ organizations/ assets, e.g. through purchase of insurance
• Risk Control – assuming responsibility for the risk
• Risk exposure – the likely monetary cost of the risk
• Risk leverage=[risk exposure before applying control minus risk exposure after applying control] divided by cost of applying control 1/21/2010
1/21/2010 41 Risk Analysis Steps - I Identify assets needing protection
•
•
•
•
•
• Hardware
Software
Data
People
Documentation
Supplies Determine Vulnerabilities • Any situation that could cause loss of confidentiality, integrity or availability
• Several different approaches may be used
• There is no single “right” approach 1/21/2010
1/21/2010 42 Risk Analysis Steps - II Estimate likelihood of exploitation by:
•
•
• Classical probability analysis
Frequency analysis using observed data
Subjective analysis by experts Compute expected annual loss • Include impacts on business, legal obligations, potential legal costs, future loss of business, etc. Identify possible controls and their costs • Map vulnerabilities to controls
• Consider both positive and negative effects of controls, and interaction among controls 1/21/2010
1/21/2010 Determine annual savings from applying controls
• Consider cost tradeoffs 43 Cost Tradeoff Analysis Example
Risk Exposure (RE) P(UO) = 0.75 L(UO) = $ 0.5M $0.375M L(UO) = $30M $1.5M Find critical fault
P(UO) = 0.05 Don’t find critical fault
P(UO) = 0.20 L(UO) = $0.5M No critical fault Yes Combined Risk Exposure = ∑ RE $1.975M $0.100M Do Software
Testing? No P(UO) = 0.25 L(UO) = $ 0.5M $0.125M L(UO) = $30M $16.5M Find critical fault
P(UO) = 0.55 Don’t find critical fault
P(UO) = 0.20 L(UO) = $0.5M No critical fault $16.725M $0.100M P(UO) = Probability of Unwanted Outcome L(UO) = Loss from UO
1/21/2010
1/21/2010 Figure 88, Pfleeger & Pfleeger, Security in Computing 3 Ed, p 527
rd 44 Pros & Cons of Risk Analysis Pros:
•
•
•
•
• Improved Awareness across organization
Ties security to management objectives
Identifies assets, vulnerabilities, and controls
Improves basis for security decisions
Justifies cost of security expenditures Cons: • Can give a false sense of precision and confidence
• Not always accurate Ranges from very subjective and imprecise to highly quantitative
• Difficult and potentially expensive to perform
• Too easily treated as something to be filed and forgotten 1/21/2010
1/21/2010 45 Security Policy A highlevel management document to inform all users of goals and constraints on using a system
Answers three questions:
•
•
•
•
•
•
• 1/21/2010
1/21/2010 Recognize sensitive information assets
Clarify security responsibilities
Promote awareness for existing employees
Guide new employees •
•
• Who can access system resources?
Which resources can they access?
How can they be accessed? (constraints/protection) Users
Owners
Beneficiaries Purposes Audience 46 Security Policy Content Audiences • Nature of each audience and their security goals Purpose of the computing system • Examples: efficient business operation, facilitate sharing of information, safeguard business and personal info, etc. Resources needing protection
• Identified through Risk Analysis Nature of the protection • What degree of protection, using what mechanisms, to protect which resources 1/21/2010
1/21/2010 47 Characteristics of Good Security
Characteristics
Policies
Policies 1/21/2010
1/21/2010 Comprehensive Coverage
Ability to adapt to system growth and expansion
Realistic, in terms of ability to implement at reasonable cost with existing technology
Useful. Written in language that is easy to understand
Security Policies and Plans MUST fit in with larger societal issues 48 Physical Security The protection needed outside the computer system
• Typically guards, locks and fences Many physical security measures are simply good common sense
Physical security must address: • Natural disasters Flood, fire, earthquakes, building collapse • Power Loss/Major power fluctuations • Malicious humans 1/21/2010
1/21/2010 Sabotage
Theft 49 Some Controls for Physical
Some
Security Vulnerabilities
Security Well thought out contingency plans
Insurance
Back ups
• Data backup
• System backup 1/21/2010
1/21/2010 Uninterruptible power supplies
Surge Suppressors
Theft prevention
Prevention of portability e.g. CDs, PDAs, laptops
Detecting exit of human perpetrators
Shredding
Overwriting magnetic data
Degaussing
Protection against signal emanation 50 Voice-Oriented Wireless Networks 1/21/2010
1/21/2010 51 Traditional Wireless Networks (TWNs) Think “cellular” • First commercially successful wireless networks
• (Relatively) straight forward extension of the wired Public Switched Telephone Network (PSTN)
• Mobile phones can complete calls to PSTN phones Base Stations/MSCs do any necessary protocol conversion • PSTN phones can complete calls to Mobile phones 1/21/2010
1/21/2010 •TWNs are basically a Wide Area Network (WAN) technology
Designed for voice
Evolving to...
View
Full Document
- Spring '11
- Dr.PradipP.Dey
- Computer Security, sensitive data, CMH
-
Click to edit the document details