Security for Distributed Computing

1
Security for Distributed Computing
Profs. Steven A. Demurjian Computer Science
Engineering Department 191 Auditorium Road, Box
U-155 The University of Connecticut Storrs,
Connecticut 06269-3155
http//www.engr.uconn.edu/steve steve_at_engr.uconn.
edu

• Security Issues for Distributed Computing
• A Proposed Distributed Security Framework
• Role-Based Security in a Distributed Resource
  Environment

2
Security Issues for Distributed Computing

• Background and Motivation
• What are Key Distributed Security Issues?
• What are Major/Underlying Security Concepts?
• What are Available Security Approaches?
• Identifying Key Distributed Security Requirements
• Focusing on Discretionary Access Control (DAC)
  and User-Role Based Security (URBS) for OO
• Propose Preliminary Security Techniques to
  Address OO and Non-OO Legacy/COTS Appls.

3
Security for Distributed Applications Comprised
of DBs, Legacy, COTS, etc.
How is Security Handled for Individual Systems?
What if Security Never Available for
Legacy/COTS/Database?
Security Issues for New Clients? New Servers?
Across Network?
What about Distributed Security?
Security Policy, Model, and Enforcement?
4
Identifying Key Security Requirements What are
Major Security Concepts?

• Authentication
• Is the Client who S/he Says they are?
• Authorization
• Does the Client have Permission to do what S/he
  Wants?
• Privacy
• Is Anyone Intercepting Client/Server
  Communications?
• Enforcement Mechanism
• Centralized and Distributed Code
• Enforces Security Policy at Runtime

5
Identifying Key Security Requirements What are
Underlying Security Concepts?

• Assurance
• Are the Security Privileges for Each Client
  Adequate to Support their Activities?
• Do the Security Privileges for Each Client Meet
  but Not Exceed their Capabilities?
• Consistency
• Are the Defined Security Privileges for Each
  Client Internally Consistent?
• Least-Privilege Principle Just Enough Access
• Are the Defined Security Privileges for Related
  Clients Globally Consistent?
• Mutual-Exclusion Read for Some-Write for Others

6
Identifying Key Security Requirements What are
Available Security Approaches?

• Mandatory Access Control (MAC)
• Bell/Lapadula Security Model
• Security Levels for Data Items
• Access Based on Clearance of User
• Discretionary Access Control (DAC)
• Richer Set of Access Modes
• Focused on Application Needs/Requirements
• User-Role Based Security (URBS)
• Variant of DAC
• Responsibilities of Users Guiding Factor
• Facilitate User Interactions while Simultaneously
  Protecting Sensitive Data

7
Identifying Key Security Requirements Three
Categories of Questions

• Questions on Information Access and Flow
• User Privileges key to Security Policy
• Information for Users and Between Users
• Questions on Security Handlers and Processors
• Manage/Enforce Runtime Security Policy
• Coordination Across EC Nodes
• Questions on Needs of Legacy/COTS Appls.
• Integrated, Interoperative Distributed
  Application will have New Apps., Legacy/COTS,
  Future COTS

8
Questions on Information Access and Flow

• Who Can See What Information at What Time?
• What Are the Security Requirements for Each User
  Against Individual Legacy/cots Systems and for
  the Distributed Application?
• What Information Needs to Be Sent to Which Users
  at What Time?
• What Information Should Be Pushed in an
  Automated Fashion to Different Users at Regular
  Intervals?

9
Questions on Information Access and Flow

• What Information Needs to Be Available to Which
  Users at What Time?
• What Information Needs to Be Pulled On-demand
  to Satisfy Different User Needs in Time-critical
  Situations
• How Are Changing User Requirements Addressed
  Within the Distributed Computing Application?
• Are User Privileges Static for the Distributed
  Computing Application?
• Can User Privileges Change Based on the Context
  and State of Application?

10
Questions on Security Handlers/Processing

• What Security Techniques Are
• Needed to Insure That the Correct Information Is
  Sent to the Appropriate Users at Right Time?
• Necessary to Insure That Exactly Enough
  Information and No More Is Available to
  Appropriate Users at Optimal Times?
• Required to Allow As Much Information As Possible
  to Be Available on Demand to Authorized Users?

11
Questions on Security Handlers/Processing

• How Does the Design by Composition of a
  Distributed Computing Application Impact on Both
  the Security and Delivery of Information?
• Is the Composition of Its Secure Components
  Also Secure, Thereby Allowing the Delivery of
  Information?
• Can We Design Reusable Security Components That
  Can Be Composed on Demand to Support Dynamic
  Security Needs in a Distributed Setting?
• What Is the Impact of Legacy/cots Applications on
  Delivering the Information?

12
Questions on Security Handlers/Processing

• How Does Distribution Affect Security Policy
  Definition and Enforcement?
• Are Security Handlers/enforcement Mechanisms
  Centralized And/or Distributed to Support
  Multiple, Diverse Security Policies?
• Are There Customized Security Handlers/enforcement
  Mechanisms at Different Levels of Organizational
  Hierarchy?
• Does the Organizational Hierarchy Dictate the
  Interactions of the Security Handlers for a
  Unified Enforcement Mechanism for Entire
  Distributed System?

13
Questions on Legacy/COTS Applications

• When Legacy/cots Appls. Are Placed Into
  Distributed, Interoperable Environment
• At What Level, If Any, Is Secure Access
  Available?
• Does the Application Require That Secure Access
  Be Addressed?
• How Is Security Added If It Is Not Present? What
  Techniques Are Needed to Control Access to
  Legacy/COTS?
• What Is the Impact of New Programming Languages
  (Procedural, Object-oriented, Etc.) And Paradigms?

14
Focusing on DAC and URBS

• Weve Explored DAC/URBS for OO Systems and
  Applications
• Potential Public Methods on All Classes
• Role-Based Approach
• User Role Determines which Potential Public
  Methods are Available
• Automatically Generate Mechanism to Enforce the
  Security Policy at Runtime
• Allow Software Tools to Look-and-Feel Different
  Dynamically Based on Role
• Approaches have Employed Inheritance, Generics,
  and Exceptions in C/Ada95 Languages
• Leverage Results as Starting Point

15
Legacy/COTS Applications

• Interoperability of Legacy/COTS in a Distributed
  Environment
• Security Issues in Interoperative, Distributed
  Environment
• Can DAC/URBS be Exploited?
• How are OO Legacy/COTS Handled?
• How are Non-OO Legacy/COTS Handled?
• How are New Java/C Appls. Incorporated?
• Can Java Security Capabilities be Utilized?
• What Does CORBA/ORBs have to Offer?
• What about other Middleware (e.g. JINI)?
• Explore Some Preliminary Ideas on Select Issues

16
Security for OO Legacy/COTS

• For OO Legacy/COTS, High Likelihood of Class
  Based Programming Interface
• Utilize Reviewed DAC/URBS Approaches

17
Security for Non-OO Legacy/COTS

• For Non-OO Legacy/COTS, Programming Interface
  Likely a Set of System Functions
• Utilize Reviewed DAC/URBS Approaches

18
A Distributed Security Framework Motivation and
Issues

• What is Needed for the Definition and Realization
  of Security for a Distributed Application?
• How can we Dynamically Construct and Maintain
  Security for a Distributed Application?
• Application Requirements Change Over Time
• Seamless Transition for Changes
• Transparency from both User and Distributed
  Application Perspectives
• What are Parts of Distributed Security Framework?

19
A Distributed Security Framework

• Distributed Security Policy Definition, Planning,
  and Management
• Exactly Define Security Policy
• Manage Policy in Changing Environment
• Formal Security Model w. Reusable Components
• Formal Realization of Security Policy
• Reusable Security Components
• Security Handlers Enforcement Mechanism
• Run-time Techniques and Processes
• Allows Dynamic Changes to Policy to be Seamless
  and Transparently Made

20
A Distributed Security FrameworkInteractions and
Dependencies
Enforcement Mechanism Collection of SHs
Reusable Security Components
Distributed Security Policy
21
Distributed Security Policy Definition, Planning,
and Management

• Interplay of Security Requirements, Security
  Officers, Users, Components and Overall System
• Minimal Effort in Distributed Setting - CORBA Has
  Services for
• Confidentiality, Integrity, Accountability, and
  Availability
• But, No Cohesive CORBA Service Ties Them with
  Authorization, Authentication, and Privacy
• Difficult to Accomplish in Distributed Setting
• Must Understand All Constituent Systems
• Interplay of Stakeholders, Users, Sec. Officers

22
Formal Security Model with Reusable Components

• Constructive Means to Capture Distributed
  Security Policy
• Transitional Intermediate Form to Actual
  Reusable Security Components
• Possible Approach
• Upgrade URDH/Role-Based OO Work to Distributed
  Service-Based Approach
• Utilize DRE for Analyzing Reusability of Security
  Components
• Change/Extend DRE for Analyzing Security
  Dependencies - e.g., Chaining of Calls

23
Security Handlers and Enforcement Mechanism

• Provide Concrete Means That Distributed Security
  Policy As Captured by the Formal Security Model
  Is Dynamically Attained in Runtime Setting
• Can our Prior Approaches be Leveraged?
• URSA, UCLA, BEA, GEA, etc.
• Agent-Based URBS
• Security Capabilities of Java
• What are Potential Middleware Solutions?
• CORBA
• JINI
• XML (XMI)

24
Contributions of the Framework

• Integration of URBS Techniques and Reusability
  Analysis May Lead to
• Security Components That Are Reusable Within an
  Organizations Domain
• Security Components Proven Correct When Reused,
  Carry Correctness to Other Settings
• Assurance to Security Officers That the Defined
  Policy Continues to Be Enforced
• Modifications to Dependency Analysis (DRE) to
  Include Security Requirements and Roles Offers
  Another Dimension on Reusable D D

25
Role-Based Security in a Distributed Resource
Environment
Dr. Paul Barr The MITRE Corp 145 Wyckoff
Road Eatontown, New Jersey 07724 poobarr_at_mitre.org

Profs. Steven A. Demurjian and T.C. Ting J.
Balthazar, H. Ren, and C. Phillips Computer
Science Engineering Dept. 191 Auditorium Road,
Box U-155 The University of Connecticut Storrs,
Connecticut 06269-3155
http//www.engr.uconn.edu/steve steve_at_engr.uconn.
edu
This work presented at IFIP WG 11.3 on DB
Security in August 2000, and supported in part by
a research contract from the Mitre Corporation
(Eatontown, NJ) and a research grant from AFOSR
26
Overview

• Motivation and Goals of Our Research Effort
• Suns JINI Technology
• A Software Architecture for Role-Based Security
• Proposed Software Architecture
• Security Resources and Services
• Security Client and Resource Interactions
• Client Interactions and Processing
• Experimental Prototypes
• JINI Prototype of Role Based Approach
• Security Client Prototype
• Related Work
• Conclusions and Future Work

27
Overview of the Security Process for a
Distributed Application

• Focus on Role-Based Security Within Application
• Clients Play Role
• Role Dictates Look and Feel of Client Software
• Role Passed Along to Systems that Comprise
  Distributed Application
• Distributed Application Must
• Contain Security Software
• How is Security Captured?
• How is Security Enforced?
• How Do Clients Interact with Distributed
  Application?

28
Goals of Our Research Effort

• Incorporation of Role-Based Approach within
  Distributed Resource Environment
• Highly-Available Distributed Applications
  Constructed Using Middleware Tools
• Demonstrate Use of JINI to Provide Selective
  Access of Clients to Resources Based on Role
• Propose Software Architecture and Role-Based
  Security Model for
• Authorization of Clients Based on Role
• Authentication of Clients and Resources
• Enforcement so Clients Only Use Authorized
  Services (of Resource)
• Propose Security Solution for Distributed
  Applications for Clients and Services (Resources)

29
Suns JINI Technology

• Construct Distributed Applications Using JINI by
• Federating Groups of Users
• Resources Provide Services for Users
• A Resource Provides a Set of Services for Use by
  Clients (Users) and Other Resources (Services)
• A Service is Similar to a Public Method
• Exportable - Analogous to API
• Any Entity Utilized by Person or Program
• Samples Include
• Computation, Persistent Store, Printer, Sensor
• Software Filter, Real-Time Data Source
• Services Concrete Interfaces of Components
• Services Register with Lookup Service

30
Suns JINI TechnologyKey JINI Concepts and Terms

• Registration of Services via Leasing Mechanism
• Resource Leases Services to Lookup Service
• Resources Renew Services Prior to Expiration
• If not, Services Become Unavailable
• Lookup Service Maintains Registry
• Services as Available Components
• Leasing Supports High-Availability
• Registration and Renewal Process
• Upon Failure, Services Removed from Registry
• Clients, Resources, Lookup Can Occupy Same or
  Different Computing Nodes

31
Suns JINI TechnologyJoin, Lookup, and Service
Invocation
Lookup Service
Registry of Entries
Client
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
32
Security within JINI Limitations and Potential

• Provides Minimal Support for Application Level
  Security
• Registration Process by Resources of Services
  Doesnt Allow Who Can Use Which Service
• Consequently, Resources Using JINI Would Require
  Programmatic Solution for Security
• Requires Code-Level Changes
• Recompilation and Rebuild
• Cant Adjust Dynamically When Privileges Must be
  Changed
• Can a Distributed Resource Environment (JINI) be
  Exploited to Allow Role-Based Security Consistent
  with its Philosophy and Use?

33
Role-Based Security within JINI A Proposed
Solution Approach

• Define Resources to Manage and Control Security
• Role-Based Privileges
• What are the Defined User Roles (e.g. URDH)?
• Which Role can Use Which Service(s) of Each
  Resource?
• Allow Access Down to Method Level
• Authorization List
• Who are the Users?
• What are Their Authorized Role(s)?
• Security Registration
• Who are Active Users?
• How is User Uniquely Identified?

34
Proposed Software Architecturefor Role-Based
Security
Resources Provide Services
Clients Using Services
Figure 3.1 General Architecture of Clients and
Resources.
35
Security Resources and Services

• Role-Based Privileges Resource
• Define User-role
• Grant/Revoke Access of Role to Resource
• Register Services
• Authorization List Resource
• Maintains Client Profile (Many Client Types)
• Client Profile and Authorize Role Services
• Security Registration Resource
• Register Client Service
• Identity Registration at Startup
• Uses IP Address
• Security Client
• Allow Security Officer to Set, Change, Monitor,
  and Manage the Three Security Resources

36
Defining a Base Line Security Model for
Distributed Computing

• Definition 1 A Resource Is a System (E.G., A
  Legacy, COTS, Database, Web Server, Etc.) That
  Provides Functions for the Distributed
  Application Via a Collection of N Services.
• Definition 2 A Service Is Composed of Multiple
  Methods
• Each Method Is Akin to OO Method
• Each Method Represents a Subset of the
  Functionality Provided by the Service
• Definition 3 A Method of a Service Is
  Characterized by a Signature

37
Defining a Base Line Security Model for
Distributed Computing

• Definitions 4
• Each Resource Has a Unique Resource Identifier to
  Differentiate Between Replicated Resources
• Definitions 5
• Each Service Has a Unique Service Identifier to
  Distinguish Services Within a Particular Resource
  
• Definitions 6
• Each Method Has a Unique Method Signature to
  Distinguish Methods of a Service

38
Defining a Base Line Security Model for
Distributed Computing

• Definition 7 A User Role, UR, Is a Uniquely
  Named Entity for a Specific Set of
  Responsibilities Against an Application With
  Privileges Are Granted and Revoked As Follows
• UR Can Be Granted Access to Resource R, Implying
  It Can Utilize All of R's Services, and Their
  Methods
• UR Can Be Granted Access to a Subset of the
  Services of Resource R, Denoting That UR Can
  Utilize All of the Methods Defined by That Subset
• UR Can Be Granted Specific Access to Individual
  Methods Via Triple ltResource Id, Service Id,
  Method Signaturegt

39
Role-Based Privileges Resource

• Define User-role, Grant/revoke Access of Role to
  Resource, and Registration of Resources Services
• Maintains Following Information
• Resource List Indexed by ltResource Identifiergt
  and All of URs Granted Access to Resource
• Service List Indexed by ltResource Identifier,
  Service Identifiergt and All URs Granted Access to
  Service
• Method List Indexed by ltResource Identifier,
  Service Identifier, Method Signaturegt and All URs
  Granted Access to Each Method
• User-role List Indexed by ltRole Name, Role
  Identifiergt, and for Each UR All Resources,
  Services, Methods, Granted Access

40
The Services of theRole-Based Privilege Resource
41
Authorization List Resource

• Maintains Client Profile (Many Client Types) and
  Ability to Authorize Role Services
• Definition 8
• A Client Profile, CP, Characterizes All of the
  Pertinent Information on Client (User, Tool,
  Software Agent, Etc.)
• A CP Used by Resource to Dynamically Verify
  Whether a Client Can Access the Desired Triple of
  ltResource Identifier, Service Identifier, Method
  Signaturegt
• Addresses Issues Such As Has Client Registered?
  Is Client ID Accurate? Etc.

42
The Services of theAuthorization-List Resource
43
Security Registration Resource

• Utilized to Register Client Service, Identity
  Registration at Startup, and Uses IP Address
• Usage by Client
• When Client First Begins Session
• Establish Client Id, IP Address, and User Role
• Usage by Resource to Determine If a Client Has
  Registered
• Usage by Security Client to Maintain and Query
  Privileges

44
The Services of theSecurity Registration Resource
45
Security Client and Resource Interactions
Security Registration
Find_Client(C_Id, IP_Addr) Find_All_Active_Clie
nts()
Grant_UR_Client(UR_Id, C_Id)
Revoke_UR_Client(UR, C_Id) Find_AllUR_Client(C
_Id) Find_All_Clients_UR(UR)
Create_New_Client(C_Id) Delete_Client(C_Id)
Find_Client(C_Id)
Find_All_Clients()
Authorization List
Lookup Service
Create_New_Role(UR_Name, UR_Disc, UR_Id)
Delete_Role(UR_Id) Find_UR_Name(UR_Name)
Find_UR_Id(UR_Id) Grant_Resource(UR_Id
, R_Id) Grant_Service(UR_Id, R_Id,
S_Id) Grant_Method(UR_Id, R_Id,
S_Id, M_Id) Revoke_Resource(UR,
R_Id) Revoke_Service(UR, R_Id,
S_Id) Revoke_Method(UR, R_Id,
S_Id, M_Id)
Find_AllUR_Resource(UR,R_Id)
Find_AllUR_Service(UR,R_Id,S_Id)
Find_AllUR_Method(UR,R_Id,S_Id,M_Id)
Find_UR_Privileges(UR
)
Discover Service Return Proxy
Register_Resource(R_Id) Register_Service(R_Id,
S_Id) Register_Method(R_Id, S_Id,
M_Id) UnRegister_Resource(R_Id) UnRegister_Servi
ce(R_Id, S_Id) UnRegister_Method(R_Id, S_Id,
M_Id)
Role-BasedPrivileges
Figure 3.3 Security Client and Database Resource
Interactions.
46
Client Interactions and Processing
1. Register_Client(C_Id, IP_Addr,UR)
Security Registration
2. Verify_UR_Client(UR,C_Id)
4. Registration OK?
3. Client OK?
6.IsClient_Registered(C_ID)
Authorization List
10. Modification OK?
Lookup Service
7. Registration OK?
Discover Service Return
Proxy
5. ModifyAttr(C_ID,UR,Value)
8. Check_Privileges(UR,R_Id,S_Id,M_Id)
Database Resource
Role-BasedPrivileges
9. Privileges OK?
Figure 3.4 Client Interactions and Service
Invocations.
47
Two Experimental Prototypes

• JINI Prototype of Role Based Approach
• University Database (UDB)
• Initial GUI for Sign In (Authorization List)
• Student/faculty GUI Client (Coursedb)
• Access to Methods Limited Based on Role (Ex
  Only Student Can Enroll in a Course)
• Security Client Prototype
• Generic Tool
• Uses Three Resources and Their Services
• Role-Based Privileges
• Authorization-List
• Security Registration

48
Experimental Prototype One JINI Prototype of
Role Based Approach
Role-Based Privileges Sec. Reg.
Role-Based Privileges Sec. Reg.
Java GUI Client1
Java GUI Client2
DBServer Service GetClasses()
PreReqCourse() GetVacantClasses()
EnrollCourse() AddCourse() RemoveCourse()
UpdateCourse().
JINI Lookup Service
Author. List Res. (copy 2)
Author. List Res. (copy 1)
CourseDB Resource (copy 1)
CourseDB Resource (copy 2)
Figure 4.1 An Architecture of URBS based on JINI
Technology.
49
Experimental Prototype OneExecution Process
1a. Discover Register_Client Service 1b.
Return Service Proxy 2. Register the Client 3a.
Is Client Authorized? 3b. Succeed - return
Role 4. Return Success or Failure 5a. Discover
CourseDB Service 5b. Return Service
Proxy 6. Invoke a Method, e.g., Invoke
EnrollCourse() 7a. Discover Role-Based Priv.
Sec. Reg. Services 7b. Return Service
Proxies 8a. Is Client Registered? 8b. Return Yes
or No 9a. Can Client Invoke Method? 10.
addCourse() or do nothing
Role-Base Privileges Sec. Reg.
2
Java GUI Client1
4
1a, 5a
1b, 5b
JINI Lookup Service
8a 9a
8b 9b
10
6
3aa
3b
7b
7a
Author.List Res.
CourseDB Resource
Figure 4.2 Execution Process for Architecture.
50
Experimental Prototype TwoThe Security Client
Prototype
51
RecallSecurity Resources and Services
52
Experimental Prototype TwoRole-Based Privilege
Resource Services
Figure 4.4 The Role-Based Privileges Services
Screen
53
Experimental Prototype Two Authorization List
Resource Services
Figure 4.5 The Authorization-List Services
Screen.
54
Experimental Prototype Two Security Registration
Resource Services
Figure 4.6 The Security Registration Services
Screen.
55
Related Work

• Security Policy Enforcement (OS Security)
• Security Filters and Screens
• Header Encryption
• User-level Authen.
• IP Encapsulation
• Key Mgmt. Protocols
• Browser Security
• Use of Encryption
• Access Control
• Securing Comm. Channel
• Establishing a Trusted Computer Base
• Network Services
• Kerberos Charon

• Security Mobile Agents
• Saga Security Architecture
• Access Tokens
• Control Vectors
• Security Monitor
• Concordia
• Storage Protection
• Transmission Protection
• Server Resource Protection
• Other Topics
• Trust Appraisal
• Metric Analysis
• Short-lived Certificates
• Seamless Object Authentication

56
Conclusions

• For a Distributed Resource Environment
• Proposed Explained a Role-Based Approach
• Authorize, Authenticate, and Enforce
• Presented an Software Architecture Containing
• Role-Based Security Model for a Distributed
  Resource Environment
• Security Registration, Authorization-List, and
  Role-based Privileges Resources
• Developed Two Independent Prototypes
• JINI-Based Prototype for Role-Based Security
  Model that Allows Clients to Access Resources
  Based on Role
• Security Client for Establishing Privileges

57
Future Work

• Negative Privileges
• Chaining of Resource Invocations
• Client Uses S1 on R1 that Calls S2 on R2
• Client Authorized to S1 but Not S2
• Multiple Security Clients
• What Happens When Multiple Security Clients
  Attempt to Modify Privileges at Same Time?
• Is Data Consistency Assured?
• Leasing Concept available with JINI
• Leasing Allows Services to Expire
• Can Role-Based Privileges Also Expire?

58
Future Work

• Location of Client vs. Affect on Service
• What if Client in on Local Intranet?
• What if Client is on WAN?
• Are Privileges Different?
• Tracking Computation for Identification Purposes
• Currently Require Name, Role, IP Addr, Port
• How is this Tracked when Dynamic IP Addresses are
  Utilized?
• Integration of the the Two Prototypes
• Combining Both Prototypes into Working System
• Likely Semester Project during Fall 2000