Lecture 1 - The University of Texas at Dallas

Download Report

Transcript Lecture 1 - The University of Texas at Dallas

Data and Applications Security
Developments and Directions
Dr. Bhavani Thuraisingham
The University of Texas at Dallas
Lecture #1
Introduction to Data and Applications Security
January 9, 2006
Outline
 Data and Applications Security
-
Developments and Directions
 Secure Semantic Web
-
XML Security; Other directions
 Some Emerging Secure DAS Technologies
-
Secure Sensor Information Management; Secure Dependable
Information Management
 Some Directions for Privacy Research
-
Data Mining for handling security problems; Privacy vs. National
Security; Privacy Constraint Processing; Foundations of the Privacy
Problem
 What are the Challenges?
Developments in Data and Applications
Security: 1975 - Present
 Access Control for Systems R and Ingres (mid 1970s)
 Multilevel secure database systems (1980 – present)
- Relational database systems: research prototypes and products;
Distributed database systems: research prototypes and some
operational systems; Object data systems; Inference problem
and deductive database system; Transactions
 Recent developments in Secure Data Management (1996 – Present)
- Secure data warehousing, Role-based access control (RBAC); Ecommerce; XML security and Secure Semantic Web; Data
mining for intrusion detection and national security; Privacy;
Dependable data management; Secure knowledge management
and collaboration
Developments in Data and Applications
Security: Multilevel Secure Databases - I
 Air Force Summer Study in 1982
 Early systems based on Integrity Lock approach
 Systems in the mid to late 1980s, early 90s
- E.g., Seaview by SRI, Lock Data Views by Honeywell, ASD and
ASD Views by TRW
- Prototypes and commercial products
- Trusted Database Interpretation and Evaluation of Commercial
Products
 Secure Distributed Databases (late 80s to mid 90s)
- Architectures; Algorithms and Prototype for distributed query
processing; Simulation of distributed transaction management
and concurrency control algorithms; Secure federated data
management
Developments in Data and Applications
Security: Multilevel Secure Databases - II
 Inference Problem (mid 80s to mid 90s)
- Unsolvability of the inference problem; Security constraint
processing during query, update and database design
operations; Semantic models and conceptual structures
 Secure Object Databases and Systems (late 80s to mid 90s)
- Secure object models; Distributed object systems security;
Object modeling for designing secure applications; Secure
multimedia data management
 Secure Transactions (1990s)
- Single Level/ Multilevel Transactions; Secure recovery and
commit protocols
Some Directions and Challenges for Data and
Applications Security - I
 Secure semantic web
- Single/multiple security models?
- Different application domains
 Secure Information Integration
- How do you securely integrate numerous and heterogeneous
data sources on the web and otherwise
 Secure Sensor Information Management
- Fusing and managing data/information from distributed and
autonomous sensors
 Secure Dependable Information Management
- Integrating Security, Real-time Processing and Fault Tolerance
 Data Sharing vs. Privacy
- Federated database architectures?
Some Directions and Challenges for Data and
Applications Security - II
 Data mining and knowledge discovery for intrusion detection
- Need realistic models; real-time data mining
 Secure knowledge management
- Protect the assets and intellectual rights of an organization
 Information assurance, Infrastructure protection, Access
Control
- Insider cyber-threat analysis, Protecting national databases,
Role-based access control for emerging applications
 Security for emerging applications
- Geospatial, Biomedical, E-Commerce, etc.
 Other Directions
- Trust and Economics, Trust Management/Negotiation, Secure
Peer-to-peer computing,
Directions and Challenges for Securing the
Semantic Web
 The Semantic Web by Tim Berners Lee
- Definition and Layers
 Steps for Securing the Semantic Web
 XML Security for Securing the Semantic Web
 Related research and directions for secure semantic web
- Secure Information Integration
Secure Semantic Web
 According to Tim Berners Lee, The Semantic Web supports
- Machine readable and understandable web pages
 Layers for the semantic web: Security cuts across all layers
 Challenge: Not only integrating the layers for the semantic web, but
also ensuring secure interoperability
Logic, Proof, Trust
Layer 5
Ontologies, Semantic Interoperability
Layer 4
RDF
XML, XML Schemas
TCP/IP, Sockets, HTML, Agents
Layer 3
Layer 2
Layer 1
Steps to Securing the Semantic Web
 Flexible Security Policy
-
One that can adapt to changing situations and requirements
 Security Model
-
Access Control, Role-based security, Nonrepudiation, Authentication
 Security Architecture and Design
-
Examine architectures for semantic web and identify security critical
components
 Securing the Layers of the Semantic Web
-
Secure agents, XML security, RDF security, secure semantic
interoperabiolity, security properties for ontologies, Security issues for
digital rights
 Challenge: How do you integrate across the layers of the Semantic Web and
preserve security?
 Much of the research is focusing on XML security; Next step is securing RDF
documents
XML Security
 Some ideas have evolved from research in secure multimedia/object
data management
 Access control and authorization models
- Protecting entire documents, parts of documents, propagations
of access control privileges; Protecting DTDs vs Document
instances; Secure XML Schemas
 Update Policies and Dissemination Policies
 Secure publishing of XML documents
- How do you minimize trust for third party publication
 Use of Encryption
 Inference problem for XML documents
- Portions of documents taken together could be sensitive,
individually not sensitive
Secure Sensor Information Management
 Sensor network consists of a collection of autonomous and
interconnected sensors that continuously sense and store
information about some local phenomena
- May be employed in battle fields, seismic zones, pavements
 Data streams emanate from sensors; for geospatial applications
these data streams could contain continuous data of maps, images,
etc. Data has to be fused and aggregated
 Continuous queries are posed, responses analyzed possibly in real-
time, some streams discarded while rest may be stored
 Recent developments in sensor information management include
sensor database systems, sensor data mining, distributed data
management, layered architectures for sensor nets, storage
methods, data fusion and aggregation
 Secure sensor data/information management has received very little
attention; need a research agenda
Secure Sensor Information Management:
Directions for Research
 Individual sensors may be compromised and attacked; need
techniques for detecting, managing and recovering from such
attacks
 Aggregated sensor data may be sensitive; need secure storage sites
for aggregated data; variation of the inference and aggregation
problem?
 Security has to be incorporated into sensor database management
- Policies, models, architectures, queries, etc.
 Evaluate costs for incorporating security especially when the sensor
data has to be fused, aggregated and perhaps mined in real-time
 Research on secure dependable information management for sensor
data
Secure Dependable Information Management:
Directions for Research
 Challenge: How does a system ensure integrity, security, fault
tolerant processing, and still meet timing constraints?
- Develop flexible security policies; when is it more important to
ensure real-time processing and ensure security?
- Security models and architectures for the policies; Examine realtime algorithms – e.g.,query and transaction processing
- Research for databases as well as for applications; what
assumptions do we need to make about operating systems,
networks and middleware?
 Data may be emanating from sensors and other devices at multiple
locations
- Data may pertain to individuals (e.g. video information, images,
surveillance information, etc.)
- Data may be mined to extract useful information
- Need to maintain privacy
Secure Dependable Information Management
Example: Next Generation AWACS
Navigation
Data Analysis Programming
Group (DAPG)
Data Links
Sensors
Sensor
Detections
Multi-Sensor
Tracks
Technology
Future
App
provided by
Future
App
the project
Data
Mgmt.
Data
Xchg.
MSI
App
Infrastructure Services
Real-time Operating System
Hardware
Future
App
Display
Processor
&
Refresh
Channels
Consoles
(14)
•Security being considered after
the system has been designed
and prototypes implemented
•Challenge: Integrating real-time
processing, security and
fault tolerance
Research Directions for Privacy

Why this interest now on privacy?
-
Data Mining for National Security
Data Mining is a threat to privacy
Balance between data sharing/mining and privacy

Is federated data management a solution

Privacy Preserving Data Mining

Inference Problem as a Privacy Problem
-
Handling privacy constraints; Foundations

Web/Semantic Web will have to address privacy

Federated Architectures for Data Sharing?
Data Mining to Handle Security Problems
 Data mining tools could be used to examine audit data and flag
abnormal behavior
 Much recent work in Intrusion detection
- e.g., Neural networks to detect abnormal patterns
 Tools are being examined to determine abnormal patterns for
national security
- Classification techniques, Link analysis
 Fraud detection
- Credit cards, calling cards, identity theft etc.
Data Mining as a Threat to Privacy
 Data mining gives us “facts” that are not obvious to human analysts
of the data
 Enables inspection and analysis of huge amounts of data
 Possible threats:
Predict information about classified work from correlation with
unclassified work
Mining “Open Source” data to determine predictive events (e.g.,
Pizza deliveries to the Pentagon)
It isn’t the data we want to protect, but correlations among data items
Initial ideas presented at the IFIP 11.3 Database Security Conference,
July 1996 in Como, Italy
Data Sharing/Mining vs. Privacy: Federated Data Management
Architecture for the Department of Homeland Security?
-
What can we do?:
Privacy Preserving Data Mining
 Prevent useful results from mining
- limit data access to ensure low confidence and support
- Extra data (“cover stories”) to give “false” results with Providing
only samples of data can lower confidence in mining results;
 Idea: If adversary is unable to learn a good classifier from the data,
then adversary will be unable to learn good
- rules, predictive functions
 Approach: Only make a sample of data available
- Limits ability to learn good classifier
 Several recent research efforts have been reported
Privacy Constraints
 Simple Constraints - an attribute of a document is private
 Content-based constraints: If document contains information about
XXX, then it is private
 Association-based Constraints: Two or more documents together is
private; individually they are public
 Dynamic constraints: After some event, the document is private or
becomes public
 Several challenges: Specification and consistency of constraints is a
Challenge; How do you take into consideration external knowledge?
Managing history information
Architecture for Privacy
Constraint Processing
User Interface Manager
Privacy
Constraints
Constraint
Manager
Query Processor:
Constraints during
query and release
operations
DBMS
Database Design
Tool
Update
Processor:
Constraints during
database design
operation
Constraints
during update
operation
Database
Secure Federated Database Management for
Data Sharing: Policy Integration
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
External policies: Policies
for the various classes of users
Federated policies: integrate export policies
of the components of the federation
Export policies for the components:
e.g., export policies for components A, B, and C
(note: component may export different policies
to different federations)
Generic policies for the components:
e.g., generic policies for components A, B, and C
Policies at the Component
level: e.g., Component policies
for components A, B, and C
Adapted from Computers and Security, Thuraisingham, December 1994
Some Key Directions
 Transfer security technology to operational systems; need to
develop systems that are flexible, usable and secure
- Bring human computer interaction and people aspects into
system design
 Security for emerging applications
- E.g., medical informatics, bioinformatics, scientific and
engineering informatics, and other areas
 Data mining for security (e.g., intrusion detection, insider cyber
threat); cannot forget about Privacy
 Interdisciplinary research in information security
 Emerging areas include Secure semantic web, Secure Information
Integration, Secure Sensors, Trust Management/Negotiation,
Economics, - - - - -