Security Concepts and Capabilities
CSE
5810
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-1155
Storrs, CT 06269-1155
steve@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 - 4818


The majority of these slides represent material that has been accumulated
from various sources over the years.
A portion these slides are being used with the permission of Dr. Ling Lui,
Associate Professor, College of Computing, Georgia Tech.
Security_BG-1
Motivation: Recall Project Architecture
Providers
Patients
EMR
CSE
5810
Where are
the
Security
Web-Based
+ HL7)
IssuesPortal(XML
and
Concerns?
Open Source DB
(XML or MySQL)
Consider Components
of Architecture…
Feedback
Repository
Clinical Researchers
Education
Materials
Security_BG-2
Motivation: Security Issues?
Patients
CSE
5810
Patient GUI
Providers
for RN vs. MD
XML
https
https
html
Web Server
Encryption
Firewall
Appl Server
Web - Control Services
Clinical
Researchers
Appl. – Control Methods
Encryption
Secure Communication
Web Content
DB Server
Encryption
GUI Look and Feel
Security_BG-3
Overview

CSE
5810








Objective: Cover the wide range of Background
Concepts and Security Ideas
Motivation: Importance, Concepts, and Issues
Glossary of Security Terms
Security Policy, Authentication, and Authorization
Security in Java
Access Control
 Mandatory Access Control (MAC)
 Discretionary Access Control (DAC)
 Role-Based Access Control (RBAC)
DB Security, Cryptography, Security in Statistical DB
Web Based Security
Concluding Remarks
Security_BG-4
Motivation: General Concepts

CSE
5810


Authentication
 Proving you are who you are
 Signing a Message
 Is Client who s/he Says they are?
Authorization
 Granting/Denying Access
 Revoking Access
 Does Client have Permission to do what s/he
Wants?
Encryption
 Establishing Communications Such that No One
but Receiver will Get the Content of the Message
 Symmetric Encryption and Public Key Encryption
Security_BG-5
Motivation: Type of Security Issues

CSE
5810



Legal and Ethical Issues
 Information that Must be Protected
 Information that Must be Accessible
 HIPPA vs. Emergent Health Situations
Policy Issues
 Who Can See What Information When?
 Applications Limits w.r.t. Data vs. Users?
System Level Enforcement
 What is Provided by the DBMS? Programming
Language? OS? Application? Web Server? Client?
 How Do All of the Pieces Interact?
Multiple Security Levels/Organizational Enforcement
 Mapping Security to Organizational Hierarchy
 Protecting Information in Organization
Security_BG-6
Glossary of Protection and Security Terms

CSE
5810

Principal
 Entity (Person/Process/etc.) to Which
Authorizations are Granted
 Can be a User, User Group, Program, Client, etc.
 Also Known as Subject
Protected Object
 Known Object whose Internal Structure is
Inaccessible Except by Protection System
 The Unit of Protection
 For Our Purposes:
 Table, Column, Tuple
 Data and Meta-Data
Glossary from: Saltzer and Schroeder, “The Protection of Information in
Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.
Security_BG-7
Glossary of Protection and Security Terms

CSE
5810


Access Control List
 List of Principals (User, User Group, Process, …)
Authorized to have Access to Some Object
 For Every Object, Maintain Authorized Principals
 Easily Implemented in Algorithm/Typically in OS
Authenticate
 Verify Identity of Principal Making Request
 In OS - Equivalent to Logging on (ID, Password)
 May be More Complicated Based on Security
Needs
Authorize
 Grant Principal Access to Objects
 Granularity Ranges from Fine to Coarse
 Application Directed
Security_BG-8
Glossary of Protection and Security Terms

CSE
5810


Capability
 Unforgeable Ticket as Proof of Authorization of
Presenter (Principal) to Access Named Object
 Ticket or Certificate Must be Presented at Each
Access
Capability List
 List of Protected Objects which Likewise List
Authorized Principles
 Used in Conjunction with Tickets for
Authorization
Certify
 Verify Accuracy, Correctness, & Completeness of
Security/Protection Mechanism
 Critical for Select Domains (DoD, Banking, etc.)
Security_BG-9
Glossary of Protection and Security Terms

CSE
5810



Confinement
 Restricting What a Process Can Do to with
Authorized Objects
 Similar in Concept to Sandbox of Java
Domain
 Objects Currently Accessed by Principal
(De)Encryption
 De(Encoding) of Data According to
Transformation Key for Transmission/Storage
 Reciprocal Activity - Many Different Options
Grant
 Authorize Access to Objects by Principals
 Who Can do What When
Security_BG-10
Glossary of Protection and Security Terms

CSE
5810
Password
 Encrypted Character String to Authenticate
Identity of Individual
 Critical to Encrypt Also from Client to Login
Server
 Client Types in Plain Text that is Encrypted
 Encrypted login Travels of Network
 Decrypted at Login Server and Verified

Permission
 Form of Allowed Access to Object (R, W, RW)
 Level of Access is System Dependent
 Unix File System has:
 r, w, x for User, Group, and Other
Security_BG-11
Glossary of Protection and Security Terms

CSE
5810


Privacy
 Ability to Decide Whether, When, and to Whom
Information is Released
 Is Anyone Intercepting Client/Server
Communications?
Propagation
 Principal Passing on Authorization to Object to
Another Principal
 Current Term Today is “Delegation”
 Principal Must be Authorized to Delegate
Privileges to Another Principal
Enforcement Mechanism
 Centralized and Distributed “Code”
 Enforces Security Policy at Runtime
Security_BG-12
Glossary of Protection and Security Terms

CSE
5810


Protection & Security
 Mechanisms and Techniques to Control Access to
Information by Executing Programs
 Enforcement Mechanism, Cryptography
Algorithms, Database Security, etc.
Revoke
 Remove Previously Authorized Access from
Principals
 Security Tools Must Promote Grant, Revoke, and
Authorize in a Dynamic Setting
Ticket-Oriented
 Each Principal Maintains List of Unforgeable
Tickets Denoting Objects have been Authorized
 Works with Capability Lists
Security_BG-13
Policy & Mechanism

CSE
5810



Security Policy Defines Rules for Authorizing Access
to Computer and Resources
 Who are Users? What are DB Items? What DB
Items are Available to Each User? Etc…
 For PHR – Patient Defines Policy
Protection Mechanisms Authenticate
 Access to DB Items, File and Memory Protection
 What is the Granularity of Access?
A Security Policy is an Organizations Strategy to
Authorize Access to the DBMS DB Items
 Each Policy is Application Dependent
 Range from Full to Limited Access
Security Transcends DB as a Separate Research and
Realization for All Types of Systems/Applications
Security_BG-14
Authentication

CSE
5810
User/Process Authentication
 Is this User/Client Who It Claims to Be?
 Passwords
 More Sophisticated Mechanisms
 Need for Re-authentication

Authentication in Networks
 Is this Computer Who It Claims to Be?
 File Downloading and Transferring
 Obtaining Network Services
 What is Java Promise? What Does Java Guarantee re.
Applets? What can Application do that Applet Can’t?

DB Authentication
 Uncontrolled Access (Select, Modify, etc.) Can be
Limited (Authorized) requiring Authentication
Security_BG-15
Authorization

CSE
5810





Ability of Principals to Use Machines, Objects,
Resources, etc.
Security Policy Defines Capabilities of Each Principal
Against Objects, Resources, etc.
Authorization Mechanism Enforces Policy at Runtime
External Authorization
 User Attempts to Access Computer
 Authenticate Identify and Verify Authorizations
Internal Authorization
 Can Process Access a Specific Resource?
Database Authorization
 What Can Each User Do Against the DB? Select,
Insert, Update, Delete?
 Are Users Limited to Subsets of Tuples by Value?
Security_BG-16
User Authentication

CSE
5810

Combination of User ID and Password Universal for
Access to Computers
However, Cannot Prevent …
 Guessing of Passwords
 Stolen and Decrypted Passwords
 Masquerading of Intended User
 Is User Who they are Supposed to be?
 What Extra Information Can User be Asked to Supply?
 What About Life Critical Situations – EMR’s Treating
Accident Victim?

Past Invasion of Engineering Computing
 yppasswd File Stolen/Decrypted
 S. Demurjian’s Sun Workstation Corrupted
Security_BG-17
Network Authentication

CSE
5810
Computers Must Interact with One Another
 Classic Example, Transmitting E-Mail Msgs.
 Does Transferring Computer have Right to Store a
File on Another Computer?
 What About PHR Data Routed from Web to
Application to DB to EMR?
 Where is the Control? https? Encryption?
 Guarantee Unencrypted Data not Stored on the Way?


Viruses: Passive Penetrating Entity
 Software Module Hidden in Another Module
 When Container Executed, Virus Can Penetrate
and Wreak Havoc
Worms: Active Penetrating Entity
 Actively Seeks to Invade Machine
Security_BG-18
Core Security Capabilities of Java

CSE
5810


Sandbox and Applet Level Security
 Downloaded Applets are Confined in a Targeted
Portion of System During Execution
 Execution of Untrusted Code in Trusted Way
What is Sandbox?
 Area of Web-Browser Dedicated to Applet
 Applet Limited to Sandbox to Prohibit Access to
Local Machine/Environment
 Utilizes Class Loader, Bytecode Verifier, and
Security Manager
 Three Components Maintain System Integrity
 How Does this Occur?
Why is this Relevant for BMI Applications?
 Pervasive Usage of Applets and Client Java Code
Security_BG-19
Core Security Capabilities of Java

CSE
5810



Class Loader - Only Load Correct Classes
Bytecode Verifier - Classes in Correct Format
 Both Don’t care Where the Code is from (compiled
from Java or another PL – just is it correct)
Security Manager - Untrusted Classes Can’t Execute
Dangerous Instructions nor Access Protected System
Resources
Role of Security Managers
 Enforces Boundaries of Sandbox
 All Java Classes ask Manager for Permission to
Perform Certain Operations
 Implements/Imposes Appl. Security Policy
 Java Interface Class Implementable by Users
 Integrated with Exception Handling of Java
Security_BG-20
Recall Java Bytecode Verification:
CSE
5810
Security_BG-21
Digital Signatures and JAR Files

CSE
5810


When Can Applets Become Applications?
 Trusted Publisher (Originator of Applet)
 Signed Applet is Authenticated
 Java Security Manager May Allow Applet out of
Sandbox to be Application
How is Information Transmitted and Exchanged?
 JAR: Archived (Compressed) Files
 Bundling of Code/Data into Java Archive
 Associated Digital Signature for Verification
 Transmission via Object Serialization
Again, for BMI
 Web Applications to PCs, PDAs, and Cells
 Pervasiveness of Technology and Potential for
Misuse and Information Release
Security_BG-22
Available Access Control Approaches

CSE
5810


Mandatory Access Control (MAC)
 Bell/Lapadula Security Model
 Security Classification Levels for Data Items
 Access Based on Security Clearance of User
Role Based Access Control (RBAC)
 Govern Access to Information based on Role
 Users can Play Different Roles at Different Times
Responsibilities of Users Guiding Factor
 Facilitate User Interactions while Simultaneously
Protecting Sensitive Data
Discretionary Access Control (DAC)
 Richer Set of Access Modes - Govern Access to
Information based on User Id
 Discretionary Rules on Access Privileges
 Focused on Application Needs/Requirements
Security_BG-23
What are Key Access Control Concepts?

CSE
5810

Assurance
 Are the Security Privileges for Each User
Adequate to Support their Activities?
 Do the Security Privileges for Each User Meet but
Not Exceed their Capabilities?
Consistency
 Are the Defined Security Privileges for Each User
Internally Consistent?
 Least-Privilege Principle: Just Enough Access

Are the Defined Security Privileges for Related
Users Globally Consistent?
 Mutual-Exclusion: Read for Some-Write for Others
Security_BG-24
Mandatory Access Control

CSE
5810
Bell-Lapadula Model [1976]
 An Extension of the Access Matrix Model
 The Model is Based on Subject-Object Paradigm
 Subjects: Active Elements
 Objects: Passive Elements

Four Access Modes/Categories





Executable by Subjects on Objects
Read-only or Read
Append (Write without Read)
Execute (Executes an Object/program)
Read-Write or Write
Security_BG-25
Mandatory Security Mechanism

CSE
5810

Typical Security Classification Levels for
Subjects/programs and Objects/resources
 Top Secret (TS) and Secret (S)
 Confidential (C) and Unclassified (U)
Rules:
 TS is the Highest and U is the Lowest Level
 TS > S > C > U
 Security Levels:




C1 is Security Clearance Given to User U1
C2 is Security Classification Given to Object O1
U1 can Access O1 iff C1  C2
This is Referred to as the Domination of U1 Over O1
Security_BG-26
Operations

CSE
5810







Get access
 Initiate access to object in the given mode
Release access
 Terminate access previously started by get
Given access
 grant an access mode on an object to a subject
Rescind access
 Revoke access previously granted with the “give” operation
Create object
 An object may be inactive or active; this takes an inactive
object and adds to the object hierarchy
Delete object
 Deactivates an active object
Change subject security level
Change object security level
Security_BG-27
Mandatory Security Mechanism

CSE
5810
Restriction (Axiom 1):
 No Subject S Can Read an Object O if the Object’s
Security Classification is Higher Than the
Subject’s Security Clearance
 S Can Read O iff Clearance(S)  Classification(O)

No Subject May Write an Object that has Lower
Security Class than the Subject’s Security
Clearance
 S Can Write O iff Clearance(S)  Classification(O)
 This Prevents Information Flow from Higher
Classification to Lower Classification Levels

Depending on the Desired MAC, Different Axioms
Can be Employed that Satisfy Different Criteria of
Clearance Dominating Classification
Security_BG-28
Other Axioms

CSE
5810


Simple Security (SS) Property
 Subject S may have Read(Write) Access to Object
O iff Clearance of S Dominates the Classification
of O
Star (*) Property
 A Subject Can Only Read Objects at or Above
their Level
 A Subject Can Only Write Objects at or Below
their Level
Tranquility Principle
 No Subject Can Modify Classification of Active
Object
Security_BG-29
Mandatory Security Mechanism

CSE
5810


There are Numerous Security Properties Regarding the
Ability of a Subject S to Read (Write) an Object O
These Properties Control the flow of Information from
Users to the Objects that they are allowed to Access
Simple Security Property (Read Down – No Read Up)
 No Subject S Can Read an Object O if the Object’s
Security Classification is Higher Than the
Subject’s Security Clearance
 S Can Read O iff Clearance(S)  Classification(O)
 This Insures that a Subject S cannot Read
Information Above his/her Security Level
TS
S
User (S)
C
U
Read Down
Security_BG-30
Mandatory Security Mechanism

CSE
5810

Simple Integrity Property (Write Down–No Write Up)
 A Subject May Write an Object only if that Object
is at or Below the Subject’s Security Clearance
 S Can Write O iff Clearance(S) ≥ Classification(O)
 This Allows the Potential of Information Flow
from Higher Classification to Lower Classification
Levels
 This Prevents the Ability of a Subject S to Corrupt
Data above its Security Level
Security Designer Must Choose their Poison!
TS
S
User (S)
C
U
Write Down
Security_BG-31
Mandatory Security Mechanism

CSE
5810

Liberal * Property (Write Up–No Write Down)
 No Subject May Write an Object that has Lower
Security Class than the Subject’s Security
Clearance
 S Can Write O iff Clearance(S)  Classification(O)
 This Prevents Information Flow from Higher
Classification to Lower Classification Levels
 Such an Attempt can be Overt or Unintentional
Likewise, this Allows a Subject to Corrupt
Information above its Level
TS
S
C
U
Write Up User (S)
Security_BG-32
Mandatory Security Mechanism

CSE
5810
Strict * Property (Read/Write Equal)
 A Subject May Only Read/Write an Object that has
the Exact Same Security Class than the Subject’s
Security Clearance
 S Can Read/Write O iff Clearance(S) =
Classification(O)
 This Limits Information Flow to within a Level
TS
S
C
U
Read Equal
Write Equal
User (S)
Security_BG-33
Using the Properties

CSE
5810

Security Policy is Typically a Combination of one
Read and one Write Property
 Simple Security + Simple Integrity
 Simple Security + Strict * (Write)
 Simple Security + Liberal *
 Strict * (Read) + Simple Integrity
 Strict * (Read) + Strict * (Write)
 Strict * (Read) + Liberal *
Objective: Security Engineer Must Choose the Most
Appropriate Combination for their Application
Security_BG-34
A Classic Example

CSE
5810

Simple Security for Reads
 See Information at User Clearance Level and
Lower (Less Secure)
 No Chance of Viewing TS Information
Liberal * for Writes
 Write Information at User Clearance Level and
Above (More Secure)
 No Chance of Releasing “S” Data to Lower Levels
User (S)
TS
S
Read Down
C
U
Write Up
Security_BG-35
Other Axioms

CSE
5810


Discretionary Property (DS-property)
 Every Current Access Must Be Present in the
Access Matrix
 For All Subjects S, Objects O, and the Access
Mode M:
<S,o,m>  B  M  M[s,o]
Non-Accessibility of Inactive Objects
 A Subject Cannot Read the Contents of an Inactive
Object
Rewriting of Inactive Objects
 A Newly Activated Object is Assigned to an Initial
State Independent of the Previous Activation of the
Object
Security_BG-36
Illustrating MAC

CSE
5810

Consider the EMPLOYEE Table Below with Two
Instances
 Notice Classifications on Each Tuple (TC)
 Notice Classifications on Each Attribute Value
Interpretation:
 Limit Who Can See Each Tuple and Values
 Focus on User Clearance w.r.t. Classifications
Security_BG-37
Illustrating MAC

CSE
5810
Whenever a User Attempts to Access a Table, the
Table is Filtered According to U’s Clearance
 First Set are for a User at Confidential Level
 Second Set is For a User at Unclassified Level
Security_BG-38
MLS in HL7

CSE
5810
Part of the Vocabulary of HL7, Specifically in the Definition of
Confidentiality Labels:
 L – low, M – moderate, N – normal, R – restricted, V –
very restricted, U – unrestricted
 HL7 Version 3 - Value sets using code system:
Confidentiality



http://www.hl7.org/documentcenter/public_temp_5969D197-1C23-BA170C1ADD88E2E4CEBD/standards/vocabulary/vocabulary_tables/infrastructure/
vocabulary/vs_Confidentiality.html
http://www.hl7.org/documentcenter/public_temp_F7525D5D-1C23-BA170C9A9B2F4EEFA395/standards/vocabulary/vocabulary_tables/infrastructure/v
ocabulary/Confidentiality.html#L
Access Control for Document Using HL7 Identifies Issues
Related to PHI
 Guide to the HL7 Health care Privacy and Security
Classification System (HCS) May 2013 HL7 Informative
Guidance Release 2

https://www.hl7.org/documentcenter/public_temp_57724ED9-1C23-BA170CB16856B7F6E33F/wg/secure/3.%20HCS%20Guide%20Final%202013%20
0322%20JMD.pdf
Security_BG-39
Confidentially
U unrestricted
CSE
5810
L low
This indicates that the information is not classified as sensitive.
Examples: Includes publicly available information, e.g., business name, phone, email or physical address.
The information requires protection to maintain low sensitivity.
Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data
sets. Low information might need to be accessed by a wide range of administrative staff to manage the subject of care's
access to health services.
M moderate
This is moderately sensitive information, which presents moderate risk of harm if disclosed without authorization.
Examples: Includes allergies of non-sensitive nature used inform food service; health information a patient authorizes to
be used for marketing, released to a bank for a health credit card or savings account; or information in personal health
record systems that are not governed under health privacy laws. Less sensitive information might need to be accessed by
a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology staff).
N normal
This information is typical, non-stigmatizing health information, which presents typical risk of harm if disclosed without
authorization.
Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI)
given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information
disclosed in an application for health, workers compensation, disability, or life insurance. Default for normal clinical care
access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to
normal confidentiality for treatment information but not to ancillary care, payment and operations.
R restricted
This is highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if
disclosed without authorization.
Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI)
given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health information
disclosed in an application for health, workers compensation, disability, or life insurance. Default for normal clinical care
access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR).
V very
restricted
This information is extremely sensitive and likely stigmatizing health information that presents a very high risk if disclosed
without authorization. This information must be kept in the highest confidence.
Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects
relating to health status that must be discussed with the patient by an attending provider before sharing with the patient.
May also include information held under “legal lock” or attorney-client privilege. May not disclose this information except
as directed by the information custodian, who may be the information subject.
Security_BG-40
Health Classification System – Policy
Considerations

CSE
5810

Unmasked PHI (meaning PHI that makes patient data
visible) is allowed to be utilized by
 clinical decision support system of a HIT
 or some other system (e.g., drug-drug interaction
checking in a EMR)
 Objective: inform a non-authorized stakeholder
that a patient may be in danger of an interaction or
adverse event.
In certain situations, defined security policies that
exist related to a patient’s PHI can be automatically
overridden
 Accomplished through a process termed Security
policies “break the glass access” which could be
utilized in an emergent situation
 Ex. scene of an accident on in an ER).
Security_BG-41
Health Classification System – Policy
Considerations

CSE
5810

If patients own of their medical/health/fitness data,
then in some situations, patients can allow medical
providers to access masked PHI.
 This permission when given is termed a “shared
secret”
 Essentially shares a patient’s decryption key with
their permission.
Careful balance between masking & redacting.
 Releasing masked PHI allows a medical provider
to see all of the information in order to make an
informed decision regarding a patient’s care with
all available information.
 Redaction has one main problem, the removal of
information (e.g., a medication allergy) that could
not only impact patient care in an emergent
situation, but may also be never recoverable.
Security_BG-42
Health Classification System (HCS) in HL7

CSE
5810
An EHR is Capable of:
 Disaggregating health information into clinical
data elements, which are the most granular level of
clinically relevant information,
 Retrieving clinical attributes about
 the patient, clinical information category
 provenance such as information source and encoding
clinical vocabulary,

Applying clinical attributes as metadata tags on
clinical data elements to generate clinical facts in
accordance with clinical rules.
Security_BG-43
Health Classification System in HL7

CSE
5810
Notes:
 Clinical facts have no intrinsic security or privacy
value.
 The sensitivity of a clinical fact is determined by
matching clinical attributes with the criteria for
governance under privacy policies, including patient
consent directives.


Security labels can convey the relative risk
associated with disclosure of clinical information
based upon standardized security and privacy
vocabularies applied to a HCS
Nothing in the application of sensitivity labels
prevents the appropriate disclosure of information
affecting patient safety.
Security_BG-44
Access Control Model

CSE
5810

Uses Classifications and Clearances as Discussed
For example, if the clinical fact is tagged with security
label field values for sensitivity = HIV, then access is
permitted only if the user possesses a security
clearance that includes the corresponding HIV
clearance
Security_BG-45
Applying Clinical and Security Labels

CSE
5810

Security policy/privacy Rules dynamic and depend on
the Clinical Facts and Factors such as:
 patient consent directives
 purpose of use of the information
 environmental constraints
 the identity and roles of the requestor
 various policies for use and re-disclosure of the
information by the recipient
Cannot be known or predicted in advance
Cannot be known or predicted in advance
Security_BG-46
Applying Clinical and Security Labels

CSE
5810
Issues to be Addressed include:
 Maintaining static tagging of security and privacy
labels for individual clinical facts may be
problematic, inefficient or impossible
 Tags and rules for any particular access present
variability that cannot generally be assessed until
runtime
 Security and privacy tagging is best done at
runtime when access control variables are avaialbe
that tell
 whom, why, where, and what type of information are
known and can be resolved
Security_BG-47
Applying Clinical and Security Labels

CSE
5810
Issues to be Addressed include:
 Security and privacy tagging is applied to the
aggregated EHR response to a query for
information based
 upon rules, policies, and obligations in effect at the time
of release,
Preservation of the tagging, handling caveats
(including obligations), and information
provenance becomes the responsibility of the
recipient if subsequent reuse or disclosure to
additional parties is contemplated
Security labels allow for the management and
enforcement of inter-enterprise privacy policies


Security_BG-48
Proposed Work Defines Classifications

CSE
5810
Three categories are:
 Normal (N), Restricted (R), and Very Restricted
(VR)
 Sub-categories in the figure
Security_BG-49
Interpreting Sub-Categories

CSE
5810



Two Step Authorization Process
 Authorize to a Category
 Identify Which Sub-categories Can be Assigned
For N – there is no second Step – User Limited to N
For R
 User can be Authorized to A, B, and/or AB
 User can access all Data Items in N
For VR
 User can be Authorized to C, AC, BC, and/or ABC
 User can access all Data Items in N and R
Security_BG-50
Interpreting Sub-Categories

CSE
5810

Essentially a lattice is formed with:
 N < R < VR
 N is its own sensitivity level
 R has three sensitivity levels (A, B, and AB)
 VR has four sensitivity levels (C, AB, BC, ABC)
Each Clinical Fact/Portion of a Patient’s PHI will be
Assigned
 N, R.A, R.B, R.AB, VR.C, VR.AB, VR.BC or
VR.ABC
 Is this Versatile Enough?
 Does PHI need finer grained Sensitivities?
Security_BG-51
Recall Data Items from Paper

CSE
5810
Are 8 Levels of Sensitivity Enough to Classify Data and Make
Available to Diverse set of Stakeholders?
Recipient
Primary physicians (current)
Mental health providers
Pharmacists
Government agencies
Health insurance companies
Specialized physicians involved in care
Nurses and assistant medical staff
Alternative-medicine therapists
Administrative personnel
Researchers
Home-care and rehabilitation providers
Physician (not treating you)
Family and close social network
Emergency medicine providers
Description
Generalists
Psychiatrists or counselors
(Intentionally blank)
State health department, court system
(Intentionally blank)
Cardiologist, endocrinologist, allergist
(Intentionally blank)
Acupuncture, massage, herbal therapy
Front desk, scheduling, billing
Education, medical or pharmaceutical
Nursing care, physical/occupational therapists
(Intentionally blank)
Spouse, close family members or friends
Emergency care physicians, paramedics
Data Item
Contact information and demographics
Information relevant to current condition
Medications
Recent test results
Past medical history (unrelated)
History of substance abuse*
Mental health information*
Sexual health information*
Records relating to domestic violence*
Reproductive health records*
Genetic information*
Description
Address, telephone number, race
Illness, symptoms, hospitalization
Prescribed and over-the-counter medicines
Pulse, blood pressure, weight, height
Previous injuries or illnesses
Records of drug or alcohol abuse, treatment
Psychiatric diagnosis, suicide attempts
STDs including HIV, sexual orientation
Fear of partner, suspicious physical injury
Infertility, abortions or miscarriages, adoption
Paternity testing, genetic tests
Security_BG-52
HCS Operational Model
CSE
5810
Security_BG-53
Manage Information at Multiple Levels
CSE
5810
Security_BG-54
Applying Clinical Labels

CSE
5810





Establishes clinical vocabularies to be used for tagging
Defines rules for tagging clinical elements
Provisions Clinical Label Services
Retrieves clinical elements and their clinical attributes Tags
Creates clinical facts by application of clinical attributes
(standard metadata) to clinical elements by a clinical rule
Stores clinical facts in EHR repository.
Security_BG-55
Access Control at Runtime

CSE
5810


ACS must establish that the request itself and requestors
attributes meets acceptance parameter
If not, the query is rejected and an appropriate negative
response returned
Following this first pass, the request is forwarded to the EHR
which returns the initial response to Security Labeling Service
 labels the EHR response content
 applies masking/redaction and obligation rules
Security_BG-56
eXtensible Access Control Markup Language

CSE
5810

XACML schema Provides Several Structures and
Elements to Represent Policies
 PolicySet, Policy, Rule
PolicySets and Rules Combined by Policy/Rule
Combination Algorithm
 Permit-overrides
 Deny-overrides
 First-applicable
 Only-one-applicable
PolicySet
Policy Combination
Algorithm
Policy
Rule Combination
Algorithm
Rule
Resource
Subject
Action
Security_BG-57
Security Labeling via NIST Standards
CSE
5810
Security_BG-58
Labeling Clinical Facts – Consider Data
CSE
5810
Security_BG-59
Apply Security Labels
CSE
5810
Security_BG-60
Sample Labels
CSE
5810
Security_BG-61
Security in Software Applications

CSE
5810



Extensive Published Research (Demurjian, et al) in
Last Ten Years for DAC/RBAC for OO
Efforts in
 Automatically Generatable and Reusable
Enforcement Mechanisms
 MAC/DAC/RBAC within Distributed Setting
Premise:
 Customizable Public Interface of Class
 Access to Public Interface is Variable and Based
on User Needs and Responsibilities
 Only Give Exactly What’s Needed and No More
Please see:
www.engr.uconn.edu/~steve/DSEC/desc.html
Security_BG-62
What is Role Based Access Control (RBAC)?

CSE
5810


Most OO Programming and Database Languages have
a Single Public Interface that is Shared by All Users
of OT/Class
Consequently, Public Interface Often Union of all
Possible Methods Required by All Likely Users
Discretionary Access Control:
 Occurs at Type-Level
 Different Portions of Public Interface Available to
Different Users at Different Times Depending on
User-Roles
 Promote Potential Public Interface
Security_BG-63
NIST RBAC Standard

CSE
5810




http://csrc.nist.gov/groups/SNS/rbac/
Formalized in 1992 (Ferraiolo and Kuhn)
Based on Work by Sandhu, et al.
Lot’s of Health Care Related Case Studies:
http://csrc.nist.gov/groups/SNS/rbac/case_studies.html
 Please Visit the Site …
 May be Applicable Applications ….
Briefly, Let’s Review …
Security_BG-64
RBAC Model Variants
CSE
5810

http://csrc.nist.gov/groups/SNS/rbac/documents/towards-std.pdf

Transition from Essential Features to Complex Model
Security_BG-65
Level 1 and Level 2

CSE
5810

Level 1: Three States and UA/PA
Level 2: Add in Role Hierarchy Look on R State
Security_BG-66
Example Role Hierarchies
CSE
5810
Security_BG-67
Level 3 and Level 4

CSE
5810

Level 3: Constrained RBAC – with Separation of Duty
Constraints (SOD)
Level 4: Sessions of Users and Roles
Security_BG-68
Constrained RBAC – with SOD
CSE
5810
Security_BG-69
Motivating Security for OO Paradigm

CSE
5810


OO Paradigm Provides Minimal Support via Public
Interface and Private Implementation
Public Interface Represents UNION of all Possible
Privileges Needed by All Potential Users
A Method in the Public Interface for One Specific
User Available to ALL Users
 Can Access to Public Interface be Customized?
 Can Individuals have Particular Access to Specific
Subsets of Public Interface?
 Can Access be Based on (Potentially) Dynamic
User Roles?
 Can Code be Automatically Generated to
Implement an Enforcement Mechanism?
 Role of OO Paradigm in Support a Generic,
Evolvable, Reusable Enforcement Mechanism?
Security_BG-70
Why is RBAC Needed?

CSE
5810

In Health Care, different professionals (e.g., Nurses
vs. Physicians vs. Administrators, etc.) Require Select
Access to Sensitive Patient Data
Suppose we have a Patient Access Client
 Lois playing the Nurse Role would be Allowed to
Enter Patient History, Record Vital Signs, etc.
 Steve playing M.D. Role would be Allowed to do
all of a Nurse plus Write Orders, Enter Scripts, etc.
 Vicky playing Admin Role would be Allowed to
Enter Demographic/Insurance Info.
 Role Dictates Client Behavior
Security_BG-71
Why is RBAC Needed?

CSE
5810

Many Situations When Application Library Designer
(SWE) Could Utilize More Fine-Grained Control to
Access of Public Interface
Tradeoff Between Developers and End-Users
 SWEs Have Different Roles Based on Their
Responsibilities Related to Cooperative Design on
an Application
 SWEs Should Only See Those Portions of the
Application That They Need to See or That They
Will Be Responsible for Implementing
 End-users Must Be Limited in Their Interactions
and Access Depending on Their Roles
Security_BG-72
Examples of Why RBAC is Needed

CSE
5810

In HTSS, the public interface for Items has methods
that read (for Scanner, I-Controller) and modify
instances (only for I-Controller)
 Read Methods Targeted for Certain System
Functions (e.g., Scan Item)
 Update Methods Targeted for Others (e.g., as Item
is Scanned, Decrement Inventory Amount)
In HCA, different health care professionals (e.g.,
Nurses vs. Physicians vs. Administrators, etc.)
require select access to sensitive patient data
 Physician’s Write Scripts
 Nurses Enter Patient Data (Vitals + History)
 All Access Shared Medical Record
 Access is Limited Based on Role
Security_BG-73
RBAC for OO

CSE
5810



Public Interface is Union of All Privileges for All
Potential Users No Explicit way to Prohibit Access
Customizable Public Interface of Class
Access to Public Interface is Variable and Based on
User Needs and Responsibilities
Only Give Exactly What’s Needed and No More
public class PatientRecord
{ private: Data/Methods as Needed;
public:
write_medical_history();
write_prescription();
For MDs
get_medical_history();
and Nurses
get_diagnosis();
set_payment_mode();
etc…
For MDs Only
For Admitting
Security_BG-74
Sample RBAC Hierarchy for HCA
CSE
5810
Users
Medical_Staff
Support_Staff
Etc.
Nurse
Physcian
Technician
UR:Lab
UR:Pharmacy
UR:Radiology
UR:Staff_RN
UR:Education
UR:Private
UR:Attending
UR:Director
UR:Manager
UR:Discharge_Plng
Security_BG-75
Sample RBAC Hierarchy for University
CSE
5810
Users
/ \
+---+
+-----+
/
\
non-academic-staff
academic-staff
/
\
\
/
\
\....
/
\
\
/
\
purchasing
campus-police
...
dept-staff registrar-staff
...
/
\
...
...
/
\
grade-recording transcript-issuing
Security_BG-76
Sample RBAC Hierarchy for Portal
CSE
5810
Users
Medical_Staff
Patients
Etc.
Clinical Researcher
Basic User
Provider
UR: Nurse
UR: OccTher
UR: Physician
UR: etc…
UR: ForumLeader
UR: BasicPHR
UR: Poster
UR: DataAnalyst
UR: EdMaterials
Security_BG-77
Discretionary Access Control

CSE
5810




Discretionary
 Grant Privileges to Users, Including the
Capabilities to Access Specific Data Items in a
Specific Mode
 Available in Most Commercial DBMSs
Aspects of DAC
 User’s Identity
 Predefined Discretionary “Rules” Defined by the
Security Administrator
Focus on Two Variants of this Model
 Access Matrix Model
 Lampson’s Protection System
Role Delegation and Delegation Authority
Detail DAC in SQL2
Security_BG-78
What is Role Delegation?

CSE
5810



Role Delegation, a User-to-User Relationship, Allows
an Original User (OU) to Transfer Responsibility for a
Particular Role to a Delegated User (DU)
Two Major Types of Delegation
 Administratively-directed Delegation has an
Administrative Infrastructure Outside the Direct
Control of a User Mediates Delegation
 User-directed Delegation has an User (Playing a
Role) Determining If and When to Delegate a Role
to Another User
In Both, Security Administrators Still Oversee Who
Can Do What When w.r.t. Delegation
Delegation Vital in Health Care:
 Provider on-Call, Emergent Situations, DCP …
Security_BG-79
Why is Role Delegation Important?

CSE
5810
Many Different Scenarios Under Which Privileges
May Want to be Passed to Other Individuals
 Large organizations often require delegation to
meet demands on individuals in specific roles for
certain periods of time
 True in Many Different Sectors





Health Care
Financial Services
Engineering
Academic Setting
Key Issues:
 Who Controls Delegation to Whom?
 How are Delegation Requirements Enforced?
Security_BG-80
What Can be Delegated?

CSE
5810



Authority to Do the Task, Carries the Least
Responsibility Necessary to Execute the Task, but
Does Mean the Delegated User Can Execute the
Delegated Task or Role.
Responsibility to Do a Task Implies Accountability
and a Vested Interest that a Task or Role Can Be
Executed Properly.
Duty to Perform a Task Implies that the Delegated
User is Obligated to Execute the Given Task.
Our Focus: Delegate Authority Only
Security_BG-81
Delegation/Pass on Delegation Authorities

CSE
5810
When Establishing Privileges (by the Security Officer)
there must be the Ability to Define:
 Delegation Authority (DA)
 Recall:Security Officer can Delegate a Role to User
 DA Means that the Security Officer Can Delegate the
Authority to Delegate to another User
 Role Can be Delegated by one User to Another
 However, Delegation Authority Cannot

Pass-on Delegation Authority (PODA)
 PODA Augments DA to Allow the Delegation
Authority to Also be Delegated as Part of the
Delegation of a Role to a User
Security_BG-82
Example - Role Delegation

CSE
5810

General DoBest Delegates his Role CDR_CR1
(Commander, Crisis 1) to Colonel DoGood with DA,
where DoBest, CDR_CR1, and DoGood defined as:
OU: [DoBest, [ct, ], T]
UR: [CDR_CR1, [01dec00, 01dec01], T]
UA: [DoBest, CDR_CR1, [01dec00, 01dec01]]
DA: Yes
PODA: Yes
After Delegation:
DU: [DoGood, [01dec00, 01jun01], T]
UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]
Security_BG-83
Example - Role Delegation

CSE
5810
Now, Colonel DoGood wishes to re-delegate
CDR_CR1 to Major CanDoRight, which can be
defined as:
DU: [DoGood, [01dec00, 01jun01], T]
UR: [CDR_CR1, [01dec00, 01dec01], T]
UA: [DoGood, CDR_CR1, [01dec00, 01jun01]]
DA: Yes
PODA: No

After Delegation:
DU: [CanDoRight, [01jan01, 01feb01], T]
UA: [CanDoRight, CDR_CR1, [01dec00, 01jun01]]
Security_BG-84
Role Delegation Revocation Rules

CSE
5810
User-to-User Delegation Authority Rule
 A User (OU or DU) Who is a Current Member of a
Delegatable Role (DUR), Can Delegate that User
Role to Any User that Meets the Prerequisite
Conditions of the Role:
 DU Receiving the Role is Not a Member of the Role;
 OU or DU is Identified As Having Delegation
Authority for the Role;
 DU Meets the Mandatory Access Control Constraints
(MACC).
Security_BG-85
Role Delegation Revocation Rules

CSE
5810

Delegation Revocation Authorization Rule:
 An Original User Can Revoke Any Delegated User
From a User Role in Which the OU Executed the
Delegation.
 This is a Stricter Interpretation than [Zhan01],
Which Allows Any OU of a Role Revocation
Authority Over a DU in the Delegation Path.
 In Addition, a Security Administrator Can Revoke
Any Delegation.
Cascading Revocation Rule:
 Whenever an OU or DU in the delegation path is
revoked, all DUs in the path are revoked.
Security_BG-86
Monotonicity and Permanence

CSE
5810

Definition: Monotonicity Refers to the State of
Control the OU Possesses After Role Delegation
 Monotonic Delegation Means That the OU
Maintains Control of the Delegated Role
 Non-monotonic Means That the OU Passes the
Control of the Role to DU
Definition: Permanence Refers to Delegation in
Terms of Time Duration
 Permanent Delegation is When a DU Permanently
Replaces the OU
 Temporary Delegation Has an Associated Time
Limit With Each Role
Security_BG-87
Totality and Administration

CSE
5810

Definition: Totality Refers to How Completely the
Permissions Assigned to the Role Are Delegated
 Partial Delegation Refers to the Delegation of a
Subset of the Permissions of the Role
 Total Delegation Refers to the Situation All of the
Permissions of the Role Are Delegated
Definition: Administration Refers to how Delegation
will be Administered
 User Directed is when the User Controls all
Aspects of Delegation
 Administrator-Directed (Third party, Agentdirected) is when Control is with the Security
Officer
Security_BG-88
Revocation

CSE
5810

Definition: Cascading Revocation Refers to the
Indirect Revocation of All DUs When the OU
Revokes Delegation or Administration Revokes the
OU’s Delegated Role
Definition: Grant-Dependency Revocation Refers to
Who Has Authority to Revoke a DU
 Grant-Dependent Revocation Only Allow the OU
to Revoke the Delegated Role
 Grant-Independent Revocation Allows Any
Original Member of the DUR to Revoke a
Delegated Role
Security_BG-89
Database Security Approach

CSE
5810



Software Engineers can Write Complex Programs
Limited by Intellectual Capabilities
DB Designer Must Create Protection Scheme that
Can’t be Bypassed by Current and Future Software
Users and DB Initiators
 Users have Dedicated and Shared DB Items
 DB Items Shared by User Groups vs. DB Items
Globally Shared
 Users Spawn Clients that Access DB Items
 Clients May be Local or Remote (on Another
Machine Connected via Network)
Protection System of DB Must Support Above
According to Organization’s Admin. Policy
Security_BG-90
Database Security

CSE
5810
Types of Security
 Database Security is Mainly Related with Access
Rights to the Database
 Database Security Involves Issues Such as
 Governmental or Corporate Level of Policies
 Privacy and Confidentiality Requirements

For Example - Consider a Medicine Prescription
 Physician or PA Only One Authorized to Write Drug,
Dosage, Refills, Generic vs. Brand, etc.
 Pharmacist by Law Can Enter Script, Replace Brand
with Generic, Alter “Refills” - Can’t Change the Med
 By Law - Protect the Script per Patient (MD/Insurance)

Access Control is Mechanism to Prevent Unauthorized
Access to Databases
Security_BG-91
Database Security

CSE
5810

Database Administrator (DBA) has the Privileged
Commands to Perform the Following on Databases
 Account Creation
 Privilege Granting
 Privilege Revocation
 Security Level Assignments
Elements of the Security Model
 Subjects (Principals)
 Objects (Data)
 Access Methods (How to Use)
 Policies (Application Dictated)
 Authorizations (Who Can Do What)
 Authentication and Enforcement (Runtime)
Security_BG-92
DAC in SQL2

CSE
5810



SQL2 Uses the Concept of Authorization Identifier
 User Group (could be Single User)
 References a Set of User Accounts
DBA Must Provide Selective Access by each User to
Every Relation in the DB Based on Account
Two Levels of Privilege Assignment
 Account Level - DBA Manages the Accounts for
to Authorize Users to Different DBs
 Relation/Table Level - Controlling Access to Each
Relation or View in a DB
Objective
 Manage and Administer
 Design/Realize the Security Policy
Security_BG-93
Privileges in SQL

CSE
5810
Allocated at a Relation Level
 SELECT Privilege  Gives Account Retrieval Access

MODIFY Privilege
 Gives Account Ability to Change the Database
 Subdivided into Insert, Update, and Delete
 Insert and Update can be Specialized on Different
Attributes of Relation

REFERENCES Privilege
 Gives Account the Ability re. Integrity Constraints
 Can be Restricted to Certain Attributes of Relation

Commands to both GRANT and REVOKE are
Supported
Security_BG-94
Example Schema

CSE
5810
Consider Two Database Tables:
 EMPLOYEE
 (NAME, SNN, BDATE, ADDRESS, SET, SALARY,
DNO)

DEPARTMENT
 (D#, DNAME, MGRSNN)

Consider Four Accounts/Users:
 U1, U2, U3 and U4
 Limit U1 to be Able to Create Schema
 In SQL
 GRANT CREATETAB TO U1;

In SQL2
 CREATE SCHEMA EXAMPLE AUTHORIZATION U1;

U1 Can Create Tables In Schema EXAMPLE
Security_BG-95
SQL Examples

CSE
5810
Suppose U1 Wants to Grant U2 the Ability to Insert
and Delete into EMPLOYEE and DEPARTMENT
 U1 Wants to Disallow Ability of U2 to Propagate
(Delegate) Insert/Delete to Other Users
 GRANT INSERT, DELETE ON EMPLOYEE,
DEPARTMENT TO U2;

Suppose U1 Wants to Grant U3 the Ability to Select
from EMPLOYEE and DEPARTMENT
 U1 Allows U3 to Propagate to Other Users
 GRANT SELECT ON EMPLOYEE TO U3 WITH
GRANT OPTION;

Now, U3 can:
 GRANT SELECT ON EMPLOYEE TO U4;
 U4 Cannot Propagate/Delegate this Privilege
Security_BG-96
SQL Examples

CSE
5810
Suppose U1 Wants to REVOKE U3 the Ability to
Select from EMPLOYEE and DEPARTMENT
 REVOKE SELECT ON EMPLOYEE TO U3;
Database Must Also Cascade this Revoke to U4
Since U3 No Longer has the Ability to Grant
Cascading Revokes Can be Complicated as Privileges
are Defined
Consider 100 Users and DB with 20 Tables and
Ability to Grant/Revoke Becomes Complex
Consequently, Propagation/Delegation are Usually
Only Given Very Carefully
Critical to Document Security Policy for Each
Application!





Security_BG-97
SQL Examples

CSE
5810
Suppose that U1 wants to Give Back to U3 a Limited
Capability to SELECT from EMPLOYEE
 Also Allow U3 to be able to Propagate
 U1 First Creates a View
create view U3_EMP as
select NAME, BDATE, ADDRESS
from EMPLOYEE
where DNO = 5;

U1 Now Grants the View
 GRANT SELECT ON U3_EMP TO U3 WITH
GRANT OPTION;

U1 Can also Grant Limited Update
 GRANT UPDATE ON EMPLOYEE (SAL) TO U4;
Security_BG-98
Cryptography

CSE
5810



Information can be Encoded Using a Key it is Written
(or Transferred) -- Encryption
Information is then Decoded Using a Key When it is
Read (or Received) -- Decryption
Very Widely Used for Secure Network Transmission
Mathematical Basis - Prime Number Generation
encryption
plaintext
ciphertext
decryption
Security_BG-99
More on Cryptography
CSE
5810
plaintext
plaintext
Ke
Encrypt
Side information
Kd
C = EKe(plaintext)
Invader
Decrypt
plaintext
Security_BG-100
Cryptographic Systems
CSE
5810
Cryptographic Systems
Modern Systems
Conventional or
Symmetric Systems
•Ke and Kd are
Private Key
Public Key
essentially the
same
•Ke and Kd are
•Ke is public
private
•Kd is private
Security_BG-101
Statistical Database Security

CSE
5810

Statistical Databases are used to Produce Statistics on
Various Populations
 Individual Information is Considered Confidential
 Users May be Allowed to Access Statistical
Information on the Population, i.e., Applying
Statistic Functions to a Population of Tuples
Techniques for Protecting Privacy of Individual
Information Solutions are Illustrated by Examples:
Person(name, ssn, income, address,city,
state, zip, sex, last_degree)


Suppose we are Allowed to Retrieve Only the
Statistical Information Over this Relation by Using
SUM, AVG, MIN, MAX, COUNT, Etc.
Vital for Epidemiology and other Clinical Research
Security_BG-102
Example of Statistical DB

CSE
5810
Consider Q1 and Q2:
Q1: find the total number of women
who have ph.D. and live in Calgary,
Alberta.
select COUNT(*)
from Person
where last_degree = “ph.D.”
and
sex = “F”
and
city = “Calgary”
and
state = “Alberta”;

Q1: find the average income of women
who have ph.D. and live in Calgary,
Alberta.
select AVG(income)
from Person
where last_degree = “ph.D.”
and
sex = “F”
and
city = “Calgary”
and
state = “Alberta”;
Suppose Mary Black is a Ph.D who Lives in Calgary and we
want to know her Income, which is Prohibited
 If Query Q1 Returns One Tuple, then the Result of Q2 is
the Income of Mary
 Otherwise we May Issue a Number of Subsequent Queries
Using MAX and MIN, we May Easily Obtain a Close
Range of Mary’s Income
Security_BG-103
Example Two of Statistical DB

CSE
5810


The Issue is that Even with Statistical DB Limits, it is
Possible to Infer and Discern Confidential Info.
Suppose the Query Writer (Connie) also Lives in
Calgary and has a Ph.D.
Consider Q3 (left) and Q4 (right) below:
select
from
where
and
and
and
and

SUM(income)
Person
last_degree = “ph.D.”
sex = “F”
city = “Calgary”
state = “Alberta”;
name <> “Mary”
select
from
where
and
and
and
and
SUM(income)
Person
last_degree = “ph.D.”
sex = “F”
city = “Calgary”
state = “Alberta”
name <> “Connie”;
Since Connie Knows her Own Income, by Calculating
Q4 - (Q3 - Connie’s Income), She Determinds Mary’s
Income
Security_BG-104
Statistical Database Security

CSE
5810


Thus, having Just Aggregate Operations Can Allow
the Confidentiality of DB to be Breached
A Number of Restrictions can be used to Reduce the
Possibility of Deducing Individual Information from
Statistical Queries:
 Statistical Queries are not Permitted if the Number
of Tuples in the Population Specified by the
Selection Condition Falls Below Some Threshold
 Restricting the Number of Tuples in the
Intersection of Subsequent Query Results
 Prohibiting Sequences of Queries that Refer
Repeatedly to the Same Population of Tuples
While these can help - it may Still Possible to Deduce
Information and Breach Confidentiality!
Security_BG-105
Web Based Security

CSE
5810


What are the Issues and Concerns in Web-Based
Security?
See: http://www.w3.org/Security/Faq/
Partitions Security into:
 Client Side Security
 Server Side Security
 CGI Scripts
 Protecting Confidential Documents
 Denial of Service Attacks
We’ll Briefly Review all, but Concentrate on those
Most Apropos to BMI and Associated Web-Based
Applications (e.g., Team Project)
Security_BG-106
General Web Security Issues

CSE
5810



Bugs or Configuration Problems in Web Servers that
allow Remote users able to:
 Steal Confidential Documents, Execute Commands
on Servers, Break Into Servers, Launch DoS
Browser-Side:
 Active-X or Applets Can Breach Privacy
 Misuse of Supplied Personal Info (App Side)
Network Eavesdropping:
 Network on Browser Side
 Network on Server Side
 End User ISP, Server ISP
What is the Biggest Concern for BMI?
Security_BG-107
General Web Security Issues

CSE
5810


Impact of OS on Web Security:
 Unix and NT – Powerful and Full Featured have
Many Potential Holes – most Vulnerable
 Special Purpose Web Boxes – less Vulnerable
 Bare-Bones Macintosh – least Vulnerable
Security of Web Server Software Programs
 Dependent on Services Offered
 Simple Server (Static files) Safer than Complex
Server (CGI scripts, Server-Side Processing, etc.)
 All Security Servers have Holes!
Common Gateway Interface (CGI) Scripts are Major
Source of Security Problems
 Issue Traced to Diligence in Writing Code as
Opposed to Technology Itself
Security_BG-108
General Web Security Issues

CSE
5810
General Security Precautions – Laundry List
 Who is allowed to use the system
 When they are allowed to use it
 What they are allowed to do (different groups may
be granted different levels of access)
 Procedures for granting access to the system
 Procedures for revoking access (e.G. When an
employee leaves)
 What constitutes acceptable use of the system
 Remote and local login methods
 System monitoring procedures
 Protocols for responding to suspected security
breaches
Security_BG-109
Benefits for Written Security Policy

CSE
5810



You yourself will understand what is and is not
permitted on the system. If you don't have a clear
picture of what is permitted, you can never be sure
when a violation has occurred.
Others in your organization will understand what the
security policy is. The written policy raises the level of
security consciousness, and provides a focal point for
discussion.
The security policy serves as a requirements document
against which technical solutions can be judged. This
helps guard against the "buy first, ask questions later"
syndrome.
The policy may help bolster your legal case should
you ever need to prosecute for a security violation.
Security_BG-110
Issues of Client Side Security
CSE
5810
Q1 How do I turn off the "You are submitting the contents
of a form insecurely" message in Netscape? Should I
worry about it?
Q2 How secure is the encryption used by SSL?
Q3 When I try to view a secure page, the browser
complains that the site certificate doesn't match the
server and asks me if I wish to continue. Should I?
Q4 When I try to view a secure page, the browser
complains that it doesn't recognize the authority that
signed its certificate and asks me if I want to continue.
Should I?
Q5 How private are my requests for Web documents?
Q6 What's the difference between Java and JavaScript?
Q7 Are there any known security holes in Java?
Q8 Are there any known security holes in JavaScript?
Security_BG-111
Issues of Client Side Security
CSE
5810
Q9 What is ActiveX? Does it pose any risks?
Q10 Do "Cookies" Pose any Security Risks?
Q11 I hear there's an e-mail message making the rounds
that can trash my hard disk when I open it. Is this true?
Q12 Can one Web site hijack another's content?
Q13 Can my web browser reveal my LAN login name and
password?
Q14 Are there any known problems with Microsoft IE?
Q15 Are there any known problems with Netscape Com.?
Q16 Are there any known problems with Lynx for Unix?
Q17 Is it a good idea to configure /bin/csh as a viewer for
documents of type application/x-csh.
Q18 Is there anything else I should keep in mind
regarding external viewers?
Security_BG-112
Issues of Protecting Confidential Documents
CSE
5810
Q1 What types of access restrictions are available?
Q2 How safe is restriction by IP address or domain name?
Q3 How safe is restriction by user name and password?
Q4 What is user verification?
Q5 How do I restrict access to documents by the IP
address or domain name of the remote browser?
Q6 How do I add new users and passwords?
Q7 Isn't there a CGI script to allow users to change their
passwords online?
Q9 How does encryption work?
Q10 What are: SSL, SHTTP, Shen?
Q11 Are there any "freeware" secure servers?
Security_BG-113
Web Services Security

CSE
5810



Predominately Achieved via SOAP Messaging
See: http://www.oasis-open.org/specs/index.php#wssv1.0
Enhancements to SOAP Messaging for:
 Message Integrity
 Message Confidentiality
 Single Message Authentication
General Purpose Mechanism for Associating Security
Token with messages
This is a Good Topic for Project 2 – Web Services
Security…
See also:
http://www.ibm.com/developerworks/library/specification/ws-secure/
Security_BG-114
Concluding Remarks

CSE
5810

Security is Multi-Step, Multi-Discipline Process
 Definition of Security Requirements
 Realization of Security at Web, Application, and
Database Levels
 Integration of Security from Client to Web to
Application to DB
 Rigorous Definition of Security Policy
 Dynamic Nature of Security Privileges
 Enforcement of Defined Privileges Across and
within Multiple Tiers
Overall, Security in Today’s World Integral Part of
Everyday Life - Some Key Concerns
 Confidentiality of an Individuals Data – PHR/EMR
 Identity Theft
 Protecting National Infrastructure
Security_BG-115