CSC 607 Meeting 6 Charts - Security in Computing – CSC 607 Security Wireless Security – WCM 605 Wireless Meeting 6 Thursday 21 Jan 2010 1 Week 3

This is the end of the preview. Sign up to access the rest of the document.

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