Bài giảng Computer Security - 7. Using Trust for Role-Based Access Control (RBAC)

7. Using Trust for Role-Based Access Control (RBAC)Prof. Bharat BhargavaCenter for Education and Research in Information Assurance and Security (CERIAS)andDepartment of Computer SciencesPurdue University bb@cs.purdue.eduCollaborators in the RAID Lab ( Leszek Lilien (former Post Doc)Dr. Yuhui Zhong (former Ph.D. Student) This research is supported by CERIAS and NSF grants from IIS and ANIR.Using Trust for Role-Based Access Control - Outline1) Access Control in Open Systems2) Proposed Access Control Architecture2.1) Basics2.2) RBAC & TERM server3) TERM server3.1) Basic3.2) Evidence Model3.3) ArchitectureCredential Management (CM)Evidence Evaluation (EE)Role Assignment (RA)Trust Information Management (TIM)3.4) Prototype TERM server1) Access Control in Open Systems (1)Open environment (like WWW, WiFi networks)User who may not be known in advanceStill must determine the permission set for an unknown userCommon approach: Grant access based on user’s properties demonstrated by digital credentialsProblems with credentialsHolding credentials does not assure user trustworthinessEvidence provided by different credential issuers should not be uniformly trusted (apply “degrees of trust”)A solution for problems with credentials:Trust should be used by access control mechanismsTo limit granting privileges to potentially harmful usersHow to establish trust ?In particular with “newcomer” devicesWhat do we need to know about a pervasive device, in order to make a trust decision?Using trust for attribute-based access controlIdentity-based access control is inadequate in open environments (e.g., vulnerable to masquerading)Multi-dimensional attribute set to determine trust level1) Access Control in Open Systems (2)2.1) Proposed Access Control Architecture - BasicsInformationSystemAuthorized UsersOther UsersAccess ControlMechanism Authorized Users Validated credentials (first-hand experience and second-hand recommendations) AND Trust based on history of cooperative and legitimate behavior Other Users Lack of required credentials OR Lack of trust resulting from history of non-cooperative or malicious behavior2.2) Proposed Access Control Architecture - RBAC & TERM ServerRole-based access control (RBAC)Trust-enhanced role-mapping (TERM) server cooperates with RBACuserTERM ServerSend rolesRBAC enhanced Web ServerRequest rolesRequest AccessRespond3.1) TERM Server - Basic Concepts (1)EvidenceCredentialsStatement about some properties of a subjectExamples: X.509, PICS ratingIssuer’s opinionAllows issuer to express confidence w.r.t. her statement (recommendation)Widely used in daily lifeExample: Reviewer’s familiarity with topic on review formsNot supported by current credentialsEvidenceAssociate issuer’s opinion with credentialsReliability of evidenceTrust w.r.t. evidence from the viewpoint of the relying entity (i.e. TERM server) Combination of the trust w.r.t. the issuer and the issuer’s opinion3.1) TERM Server - Basic Concepts (2)Trust based on interpretation of observations of users behaviorsInherently uncertainUser’s behavior affected by multiple reasons Example: Reasons why a user provides incorrect information Dishonesty / Error / Other reasonsTrust contextTrust is context-specificExample: Bob trusts his doctor w.r.t. health problems but not w.r.t. flying with himDifferent trust characteristics are emphasized in different contextsTrust characteristisc may have different meanings in different contextsResearch questions:How to represent contexts?How to propagate trust among contexts?Trust in a user and issuer (of recommendations)Trusting a user: belief that user is cooperativeTrusting an issuer: believe evidence provided by issuer3.2) TERM Server – Evidence Model (1)Direct experienceUser’s or recommendation issuer’s behavior observed by TERMFirst-hand informationRecommendationRecommender’s opinion w.r.t. trust in a user/issuerSecond-hand information3.2) Evidence Model (2)Design considerations: Accommodate different forms of evidence in an integrated frameworkSupport reliability evaluation Evidence typeSpecify information required by this kind of evidence(et_id, (attr_name, attr_domain, attr_type) *) E.g.: (student, [{name, string, mand}, {university, string, mand}, {department, string, opt}])EvidenceEvidence is an instance of an evidence type3.2) Evidence Model (3)Opinion (belief, disbelief, uncertainty)Probability expectation of OpinionBelief + 0.5 * uncertaintyCharacterizes the degree of trust represented by an opinion Alternative representationFuzzy expressionUncertainty vs. vaguenessEvidence statement 3.3) TERM Server Architecture (1)assigned rolesusers’ behaviors credentialmgmtrole-assignment policies specified by system administratorscredentials provided by third parties or retrieved from the internetrole assignmentevidencestatementevidence statement, reliabilityevidenceevaluationissuer’s trust user/issuer information databaseuser’s trust trust informationmgmtComponent implementedComponent partially implementedCredential Management (CM) – simply transforms different formats of credentials to evidence statementsEvidence Evaluation (EE) - evaluates reliability of evidence statementsRole Assignment (RA) - maps roles to users based on evidence statements and role assignment policiesTrust Information Management (TIM) - evaluates user/issuer’s trust information based on direct experience and recommendationsa) CM - Credential Management Transforms different formats of credentials to evidence statementsb) EE - Evidence EvaluationDevelop an algorithm to evaluate reliability of evidenceIssuer’s opinion cannot be used as reliability of evidence Two types of information used:Evidence Statement Issuer’s opinionEvidence typeTrust w.r.t. issuer for this kind of evidence typeEvidence Evaluation AlgorithmInput: evidence statement E1 = Output: reliability RE(E1) of evidence statement E1Step1: get opinion1 = and issuer field from evidence statement E1Step2: get the evidence statement about issuer’s testify_trust E2 = from local database Step3: get opinion2 = from evidence statement E2Step4: compute opinion3 = (1) b3 = b1 * b2(2) d3 = b1 * d2(3) u3 = d1 + u1 + b2 * u1Step5: compute probability expectation for opinion3 = PE (opinion3) = b3 + 0.5 * u3Step6: RE (E1) = PE (opinion3)c) RA - Role AssignmentDesign a declarative language for system administrators to define role assignment policiesSpecify content and number of evidence statements needed for role assignmentDefine a threshold value characterizing the minimal degree of trust expected for each evidence statementSpecify trust constraints that a user/issuer must satisfy to obtain a roleDevelop an algorithm to assign roles based on policiesSeveral policies may be associated with a role The role is assigned if one of them is satisfiedA policy may contain several units The policy is satisfied if all units evaluate to TrueRA Algorithm for Policy EvaluationInput: evidence set E and their reliability, role AOutput: true/falseP ← the set of policies whose left hand side is role Awhile P is not empty{q = a policy in Psatisfy = truefor each units u in q{if evaluate_unit(u, e, re(e)) = false for all evidence statements e in E satisfy = false }if satisfy = truereturn trueelse remove q from P }return falseRA Algorithm for Unit EvaluationInput: evidence statement E1 and its reliability RE (E1), a unit of a policy UOutput: true/falseStep1: if issuer does not hold the IssuerRole specified in U or the type of evidence does not match evidence_type in U then return falseStep2: evaluate Exp of U as follows: (1) if Exp1 = “Exp2 || Exp3” then result(Exp1) = max(result(Exp2), result(Exp3))(2) else if Exp1 = “Exp2 && Exp3” then result(Exp1) = min(result(Exp2), result(Exp3))(3) else if Exp1 = “attr Op Constant” then if Op  {EQ, GT, LT, EGT, ELT} then if “attr Op Constant” = true then result(Exp1) = RE(E1) else result(Exp1) = 0 else if Op = NEQ” then if “attr Op Constant” = true then result(Exp1) = RE(E1) else result(Exp1) = 1- RE(E1)Step3: if min(result(Exp), RE(E1))  threshold in U then output true else output falsed) TIM - Trust Information ManagementEvaluate “current knowledge”“Current knowledge:”Interpretations of observationsRecommendationsDeveloped algorithm that evaluates trust towards a userUser’s trustworthiness affects trust towards issuers who introduced userPredict trustworthiness of a user/issuerCurrent approach uses the result of evaluation as the predictionDefining role assignment policiesLoading evidence for role assignmentSoftware: Prototype TERM ServerOur Research at PurdueWeb Site: http/www.cs.purdue.edu/homes/bbOver one million dollars in current support from: NSF, Cisco, Motorola, DARPASelected PublicationsB. Bhargava and Y. Zhong, "Authorization Based on Evidence and Trust", in Proc. of Data Warehouse and Knowledge Management Conference (DaWaK), Sept. 2002. E. Terzi, Y. Zhong, B. Bhargava, Pankaj, and S. Madria, "An Algorithm for Building User-Role Profiles in a Trust Environment", in Proc. of DaWaK, Sept. 2002 .A. Bhargava and M. Zoltowski, “Sensors and Wireless Communication for Medical Care,” in Proc. of 6th Intl. Workshop on Mobility in Databases and Distributed Systems (MDDS), Prague, Czechia, Sept. 2003.B. Bhargava, Y. Zhong, and Y. Lu, "Fraud Formalization and Detection", in Proc. of DaWaK, Prague, Czech Republic, Sept. 2003. THE END