Major Gaps in Existing Work
 Are existing access control models good enough?
 Most commonly used mechanisms
 Access control list (like in Linux systems)
 Role based access control
 Attribute based access control

C
r/w
A
x
r/w

B
A
B
x
d
C
x’
x’’
y
“benign but undesired” information flow
Major Gaps in Existing Work
 Are existing access control models good enough?
 Mandatory access control = multi-level access control
 Can assure information flow control
 Privilege escalation
 Confidentiality-integrity conflict
 How to maintain consistent H/L labels cross all domains?
Top Secret
Top Secret
Secret
Confidential
Unclassified
Write up
Integrity
Secret
Confidential
Unclassified
Write down
Read down
Confidentiality
Integrated ACDP Model
 Access control + Data provenance (ACDP)
 Default information flow control policy
 Global IFC policy: Maintain the contributor list for each object,
always check the local IFC policy of each contributor
 Contributor list for x”: x” created by c in C; x’ created by b in B; x
created by a in A
 When d access x”  Need to check to see whether d can access x” +
whether B’s local IFC allows x’ to flow to d through C + whether A’s
local IFC allows x to flow to d through B-C
d
 The global IFC policy can be altered
A
B
x
?
C
x’
Can achieve what traditional models cannot!!!
Control information flow + Avoid inflexibility
x’’
Major Gaps in Existing Work
 Data provenance
 Data provenance can support data quality assessment
  Help make data usage decisions
 From data quality to decide whether a data object is usable and the
confidentiality of the decision if the data is used
 Two missing elements in current data provenance works
 “Who” specification in data provenance is ad hoc
 Provenance information should include “who”, “what”, and “how”
 Who performed the action, what actions were performed, and how the
actions were performed
 Data provenance research has well established what and how models,
but the “who” model is simply user name
 No specific mechanisms to determine contributors
 In an application, how to know whether an output object is derived from
a certain input object?
Our Solution
 Access control + Data provenance (ACDP)
 “Who” specification in data provenance is ad hoc
 Who in access control models have to be very well defined
 E.g.: Role of the user in RBAC can be useful in provenance
 E.g.: Attributes of the user in ABAC can be useful in provenance
  Enable more informed data quality assessment
 No specific mechanisms to determine contributors
 Information flow control techniques can derive dependencies of data
objects and establish the contributor link for the output data
 Can greatly enhance existing data provenance models
Enhanced “who” specification to achieve better data quality assessment
Help determine the contributors to data objects
Potential Applications of ACDP
 Large-scale net-centric collaborative systems
 E.g., planning for emergency response
 Military plans its rescue mission and annotate the area map M
(becomes M’), M’ may reveal some sensitive information of the
military, but it is ok to share with the police department
 Police department plans evacuation according to M’ and further
annotate M’ into M”, share the information to volunteers
  Potential information leakage
 Distributed design
 Designers from multiple domains collaboratively accomplish
some design tasks (reuse design components)
 X designs some parts, Y modifies X’s design
 I integrates Y and other components
 Define policy on sharing from Y or I with other parties
Potential Applications of ACDP
 Healthcare information
 Patient information shared by doctors for diagnosis
 Can be access by analyst for data mining
 Data mining outcome can be shared with researchers to
develop better treatment
 Need to define information flow control policies
 SaaS
 Applications above can be put into SaaS paradigm
First Issue: Access Control Model
 Which access control model to use
 RBAC + DP
 Permissions for resource accesses are issued to roles
 Users are assigned to roles
 Support inheritance, separation of duty and delegation of rights
d
 Advantages
 Very appealing “who” model for DP
 Widely used in industry
A
B
x
?
C
x’
x’’
 Problems in RBAC for information flow control
 No means to handle dynamic data objects
 Access rights to a resource is specified in advance, not dynamically
 Cannot specify permission based on provenance information
 If y of B depends on x of A, when c accesses y, system can check back
with A to see whether A allows the access
 What if x is already deleted, what would be the basis for the check
First Issue: Access Control Model
 Which access control model to use
 ABAC + DP
 Subjects and objects are specified by attributes and access rights are
defined on attributes  Very flexible + A feasible solution
 But: ABAC also has some disadvantages
 More powerful, role can always be an attribute
 Easier policy specification (generally less attributes)
 There may be much more roles than attributes
 Difficult to track who has what privilege
 E.g., users who has taken x training can access data object y  Who
exactly has the right on y?
 If we wish to revoke user u’s access right to a data  How to? Should
we change u’s attribute value (if so, which attribute(s) actually provided
the right?) and if an attribute value is changed, will u’s other access
rights get impacted
First Issue: Access Control Model
 Solution
 Hybrid RBAC and ABAC
 Subjects are specified in the role model
 Data are specified by the attributes
 Policies specify the permission of roles for accessing data objects
based on their attributes
 Can be considered as constrained ABAC, only allow role attribute for
the subjects
 Advantages
 Facilitate DP based information flow control
 Solve the problems with “dynamics” and “provenance” in RBAC
 Attributes for data can be semantically meaningful, like roles for users
 Facilitate cross domain accesses
 Will be clarified in cross domain access model
First Issue: Access Control Model
 ABAC for data
 Require the separation of data and data containers
 Data containers
 Can be a variable, a DB cell/table, a file, etc.
 Always local to a domain
 Whether to also consider access rights to data containers?
 E.g., RBAC generally refers to the data containers (or both)
 Data
 The actual content of the data (values of the data containers)
 Only the data flow through different domains
 Provenance information is for data, not data containers
 ABAC is applied to data and its provenance information
 Physical resources do not have information flow issue
First Issue: Access Control Model
 Resource hierarchy
 Resource by nature from a hierarchy
 DB – tables – rows/columns – cells
 Directories and files
 Consider a subtree in the resource hierarchy
 All children resources inherit the attributes of their parent
 Children have finer-grained attributes
 All children resources inherit the permissions of their parent
 When a resource is accessed, how to find the policy
 Propagate permission down  Too many policies, slow reasoning
 Use closest parent that has all permissions as an attribute (ACRN)
 Benefits
 Reduce the effort in permission assignment
 Easier to manage the authorization structure
Second Issue: Cross Domain Access
 How to decide the access rights for cross domain users
in open net-centric systems?
 No global entity to maintain
information of all users
 Role mapping
r1
r2
 Map roles from domain A
to roles in domain B
 One way mapping
 Can be fully decentralized
or federated
r13
r14
r15
r16
r17
r3
r4
r7
r12
r5
r8
r6
r9
m1
r18
r10
m2
r11
Domain A
Subordinate-to-superior
relationship
r19
Domain B
Cross-domain role
mapping
Second Issue: Cross Domain Access
 How to decide the access rights for cross domain users
in open net-centric systems?
 In our hybrid model
 Perform role mapping for subjects
 How about ABAC for objects
  No need to map attributes for objects
 Once role mapping is done, the access rights can be determined
locally within the domain
 The same for information flow control
 Simply use the mapped role to check against data attributes that are
local in the corresponding domain
d
A
B
x
C
x’
x’’
Second Issue: Cross Domain Access
 Mapping complexity
 In attribute-based model
 How to understand cross domain attributes?
 Need to align attributes
 But it is difficult because there is no standard set of attributes
 Need to align the values for the attributes
 In role-based model
 Only need to perform cross domain role mapping
 How to understand cross domain roles?  Easier, because we only
concentrate on a single attribute, the roles
 Role mapping is essentially to align the values for the roles
 There are existing research works addressing role mapping issues
Role Mapping
 Role mapping
 How to perform role mapping
 Current literature
 Implicitly assumes the security officer defines role mappings
 Too time consuming and can be tedious
 Cannot handle dynamic situations
 Focus on conflict analysis and resolution
 Desirable: Automated role mapping recommendation
 Not secure to have a fully automated approach
 Have automated analysis and recommendation and require security
officer to approve the role mappings
 But security officers cannot always be online to approve dynamic role
mappings
 Have emergency role mapping approval policies and potential
damage containment
Role Mapping Model
 Automate role mapping recommendations
 Consider role similarities
 Entirely new domain
 Use role descriptions, role names, historical role activities to perform
similarity analysis and determine similar roles in different domains
 Use role hierarchy structure to further enhance similarity analysis
 Consider role mapping policies
 When role are unlikely to be similar (very different domains)
 Define role mapping policies to guide automated mapping
 Consider emergency situations
 Need to define the model for defining emergency role mappings and
define the containment policy for the information propagation
 Need to perform propagation and damage analysis and recovery if
final approval by security officer is to deny the mapping
Role Mapping Reasoner Framework
Role Mapping Generator
Security Officer
Conflict Analyzer
validate
Role Mapping
Policies
Role Similarity
Analyzer
Role Mappings
validation
Role Mapping
Database
Access Control Module
Access Control
Policies
Role Mapping
Reasoner
r1
r2
r3
r4
r5
r6
r12
r13
r14
r15
Access
control
decision
Access attempt
r21
Access
r7
r8
r9
r16
r17
r11
Domain A
r22
r18
r10
resource
r23
r19
Domain B
r24
Domain C
Role Mapping Model
 How to perform role mapping?
 Security officer defines policies on how to map the roles of
other domains to the local domain
 When a new domain joins the system and wishes to perform
role mapping with some existing domains
 Automated role mapping is performed based on the given policies
 Automated tool is used for consistency check to ensure that there is
no cyclic relations being created
 If so, security officer is informed to resolve the conflicts
 Security office checks the role mappings to ensure their correctness
 Managing role mapping
 A domain maintains the mapped roles from other domains
 Should indicate direct mapping or indirect with propagation history
 Each direct mapping should specifies the constraints for propagation
Third Issue: Flow Tracking
 Information flow tracking
 Use data provenance technique
 Current literature only helps with provenance data management
 Existing data provenance techniques do not specifically
provide data flow information
 How to know whether a data created by a service s is a new data or is
created based on some input data
 Existing provenance tools rely on annotation, and there is no
systematic method provided for such annotation
 Existing data flow and information flow analysis techniques
 A lot of works in the literature
 Need adaptation to fit the ACDP goal
 Same technique can be used to help DP maintain provenance info even
if it is not used in ACDP paradigm
Third Issue: Flow Tracking
 Information flow tracking
 Adapt existing data flow analysis techniques
 Combine static analysis and dynamic information flow tracking
 Minimize the requirement of dynamic tracking
 Use operational profile to minimize the activation of loggers
 Define semantic based data flow model
 For each category of code, define semantic rules for data flow
analysis
 E.g., for database accesses, define the dependency at the query level
(e.g., assume that data are not used beyond the query) (dependencies
can be defined for each type of query)
 E.g., for image processing, define code patterns for image processing
and then define dependencies based on code patterns
 Is this meaningful if it is not fully trustable?
Third Issue: Flow Tracking
 Information flow tracking
 Develop external flow tracking methods
 Define flow externally based on semantics of the input/output
variables
 Perform external comparisons on the input/output objects
 Develop other methods to determine the input/output dependencies
Fourth Issue: IFC Policies
 How to use the provenance data to assist access and
information flow control?
 Basic model: A global IFC policy, each domain can have its
own local IFCs
 Basic global IFC
 Check the access rights for
for each contributing objects
 Any other global IFC policies?
 E.g.: Can we ignore some earlier
contributors when the provenance
chain is long?
…
Local IFC Policy
Local in each domain
can have an action of “flow”
 Potential improvement
Global IFC Model
How to use provenance data
for Information Flow Control
Local IFC Policy
Local in each domain
can have an action of “flow”
 Need a policy specification model
for the specification of the local IFCs
Fourth Issue: IFC Policies
 Example global IFC policy modification
 E.g.: For optimization
 Confidentiality
 If C reveals x” to d and
d
A
B
C
x
x’
x’’
the client cannot derive x or
x’ from x”  Can ignore A’s and B’s contributions
 Define transformation factor: how much the data object is
transformed (e.g., from x to x’) and use transformation factor
to define access control policies
 How to define the transformation factor
 How to compose the transformation factors
 Can the transformation factors given by another domain be trustable?
Fourth Issue: IFC Policies
 Integrity
 If x is a bad data, then it may impacts x” and make x” bad
 But successive modifications may have minimized the impact
 Define impact factor: How much a data object has impact to
another data object (x” is created from x and other objects)
A
B
x
C
x’
d
x’’
Fifth Issue: Better Data Provenance
 Data provenance system considerations
 Interoperability of the provenance data
 Existing provenance techniques only consider the federated model;
all provenance data are understood
 In cross domain environment, how to align provenance data?
 Current: include common info, data attributes, user, role, domain
 Trustability of the provenance data
 Are the provenance data from another domain trustable?
 Security of the provenance data
 Provenance data may have integrity and confidentiality concern, how
to ensure that?
 Data provenance performance
 How to minimize the overhead: Distributed versus centralized
 Our solution: distributed, but important information flow with data
Fifth Issue: Better Data Provenance
 Data quality derivation
 Based on the provenance information, a mechanism should
be developed to derive the quality of the data
 Based on the trustworthiness of all the contributing entities
 Contributors: other data objects used to derive the target data
 Creator: domain-role-user who created a certain data
 Contributing entities: creators of the data objects which were used to
derive the target data