Security and Trust

• Security is one of the “non-functional” properties of the system (or is it really all non-functional? ).

• While security may be added as an afterthought, it is best (e.g. cheaper) considered early in the architectural and design phase of the project. (e.g. we can enforce our windows and doors with “iron bars” after the house is completed, but it would have been better to have considered “alarm system,” “non-shattering windows” and “ metallic doors” beforehand.

• With the reality of the Web world, security is even more important:– Remote autonomous participants (unknown/trust)– Communicating and collaborative entities (interacting)

Security Definition• Definition from National Institute of Standards and

Technology(NIST):– Security is : “the protection afforded to an automated

information system in order to attain the applicable objectives of preserving the integrity, availability and confidentiality of information system resources (includes hardware, software, firmware, information/data, and telecommunications.”

– Note that security is a protection (type of capability) to preserve:

• Confidentiality• Integrity• Availability

Confidentiality• Preserving confidentiality of information requires

prevention of :– Unauthorized access to information– Unauthorized knowledge of existence of information

• Both knowledge of existence control and access control are important because one can accidentally stumble on information --- then we still want to control access– e.g. : don’t let the fact that entity-a communicates with entity-b be

known to unauthorized entities; if accidentally detected, then ensure that access to the communicated information is controlled.

• If access control is even compromised, or as part of access control, cipher is sometimes used: cipher = encryption function (encryption-key, information text) information text = decryption function (decryption-key, cipher)

Integrity• Preserving integrity of information requires that :

– only authorized entities may manipulate the information and – do so only in authorized manner.

• To require “authorized” entity, we have invented authentication techniques to establish identity based on:– User knowledge (e.g. password)– User personal/physical characteristic (e.g. finger print)– User possession (e.g. badge or token)

• Audit trail is sometimes included to “control or track” who did what to whom or to what.

• Note that from pure data integrity point of view, the initial input of information must be also be correct (the authorized “data entry clerk” although authorized do enter data may still enter an erroneous data) ---- thus our money spent on data warehousing/data cleansing!

Availability

• Preserving availability of systems requires that:– System is accessible at “all appropriate” times– To authorized users

• Denial-of-Service is a result from common security attacks on the web– One form of this is to use all authorized entities to flood

the communications channel and bring the system to a grinding halt, making it unavailable. (we need to look at other non-functional properties such as efficiency, scalability, robustness or fault-tolerance during architecture and design time to help preserve some types of availability, independent of authorization.)

Design Principles• Security “properties” should be considered from

project inception. Thus it is important to consider some design principles from the start (these are really guidelines):

1. Least Privilege2. Fail-safe Defaults3. Economy of Mechanism4. Complete Mediation5. Open Design6. Separation of Privilege7. Least common Mechanism8. Psychological Acceptability9. Defense in Depth

Design “Principles”

• Principle of Least Privilege: An entity should be given only the amount of level of privilege it needs to complete its tasks. – This allows access control or preservation of integrity and confidentiality– It also assumes that there is a “privilege” policy, and there is

authentication mechanisms

• Principle of Fail-safe Defaults: The default access policy should be denial unless the entity is granted explicit access to an object.– Connectors should not allow communications between entities, unless

there is definite satisfaction of some access criterion.– This is also a preservation of integrity and a preservation of

confidentiality

Design “Principles” (cont.)

• Principle of Economy of Mechanism: Security mechanisms should be as simple as possible.– The mechanism should be simple, rather than complex; but this does

not mean we should not have multiple defense mechanisms.– This principle is generally applicable to design because complexity

usually brings potential of making errors and actually results in defects in the security mechanisms

• Principle of Complete Mediation: All access to entities be checked to ensure that they are allowed, regardless of who is accessing.– This is related to preserving integrity (mostly) and confidentiality– This particular principle can be helped by Economy of Mechanism if

we have simple mechanisms to execute.

Design “Principles” (cont.)• Principle of Open Design: The design should not be dependent

on the secrecy of the design or implementation– Any secrecy or proprietary information is not a guarantee to no

detection; thus there should not be any reliance on secrecy.– Open design allows us to see limitations and also preserves availability

• Principle of Separation of Privilege: Sensitive operations should be separated, and no entity is given the privileges to all operations and information– If one person or entity is given full authority to everything, then there

is no checking mechanism and deterrence of that one entity if it turns malicious

– This is mostly preserving integrity and availability• Principle of Least Common Mechanism: Mechanisms used to

access separate resources should not be shared– This is to prevent any inadvertent error where a compromised

mechanism can access all the resources– This is to preserve access control and integrity

Design “Principles” (cont.)

• Principle of Psychological Acceptability: Security mechanism should not make it excessively difficult for legitimate entities to access resources than if the security mechanism were not present.– People tend to bypass or work around the security mechanism if it is

excessively difficult for them– Cryptography is an example where many users eschew the subject,

believing the topic is too mathematically deep.

• Principle of Defense in Depth: system should have multiple defensive counter-measures to discourage potential attackers– While multiple levels of defense is needed, each one should still follow

the Principle of Economy of Mechanism (keep it simple).– This is preserving confidentiality, integrity, and availability

Access Control

• It is clear that in order to preserve confidentiality, integrity, and availability, Access Control plays a major role.

• Most basic control mechanism used to enforce Access Control is a reference monitor, which should be:– Tamper-proof (can’t be altered by unauthorized personnel)– Non by-passable (every access of resource must go through this)– Relatively small (small enough so that it is error-free and checked)

• Access Control is generally based on:1. Identity of the requestor 2. The resource to be accessed3. The permission of the requestor to access that resource

DAC & MAC Access Control Models

• There are 2 major Access Control Models:– Discretionary Access Control (DAC) – access permission is based on resource

owner discretion• Classic DAC has a set of permissions (privileges) assigned to all the subjects

(people or principals) and a set of objects on which these permissions may be applied. A 2-dimensional matrix of subjects and objects where a row may represent a subject and the privileges he/she has of accessing all the objects (represented by the columns)

• Role-Based Access Control (RBAC) is an extension of the Classic DAC where a level of indirection is introduced. Roles become the entities which are authorized with permissions., and people or subjects are assigned to roles. People may be in different roles , providing different access permissions to different resources depending on the role they are playing.

– Mandatory Access Control (MAC) – access permission is based on some policy specified by a “central authority” • Multi-Level Security (MLS) is a mechanism where there is a defined set of security

level and access policy (usually hierarchical dominance relationship). Each subject and each object is given a security level label. Subjects with security label level x may access all object labeled security level x or less. Sometimes the policy is further enhanced with “need to know” even if the security level is satisfied.

Architectural Access Control

• Modeling access control at architectural level involves the following concepts :

– Subject– Principal– Resource– Privilege– Safeguard– Policy

Basic Concepts for Architectural Modeling Access Control

• Subject: this is the user on whose behalf the software executes & we must consider the subject when designing access control – Not all components are executed under one, same subject– User may be determined dynamically and can not always be determined

during architectural time– User will sometimes change during run time– When there is a user change, there may be an impact on software

architecture (especially access control)

• Principal: this is similar to “roles” the subject may take on.– Depending the type and number of principals a subject has, the accessing

of resources will vary

• Resources: this an entity for which access should be protected– Resources are not just data files; but components and connectors should

also be viewed as resources access to which should also be protected and controlled

Basic Concepts for Architectural Modeling Access Control

• Privilege: this is a description of what permissions a component may possess and it is dependent on the subject– A permission describes the operation that may be performed on a resource

(can almost replace the term, privilege)– There are privileges that handle passive resources and enumerates which

subject has what permissions (e.g. read/write) to which resources.– There are also privileges that handle active resources and enumerates

permissions to activate/deactivate (construction/destruction) components, or connecting components to connector, executing the message router, etc.

• Safeguard: this describes the required conditions to access the interfaces of the protected component and connectors– Specifies the privileges others must have before access to the protected

elements are given

• Policy: specifies what privileges a subject, with a given set of principals, must possess in order to access resources that are protected by safeguards

We must use these “basic” concepts when modeling access control at the architectural level.

Role of Architectural Component & Connectors in Access Control

• Both components and connectors play a role in access control:– Component supplies the security contract , which specifies the

privileges and safeguards of an architectural element

– Connectors play a central role in access control because they basically regulate and enforce the security contract specified by the components :• They determine the subject of the executing component (e.g. in Secure

Socket Layer connector, the server authenticate itself to the client) • They determine and connect components that have the sufficient

“privileges” to be connected and propagate “privileges” that are necessary for access control

• They regulate communications between entities and thus support secure message routing by interpreting policies and prohibiting communication with a potentially “insecure” component (e.g. off-the-shelf component).

A Simple Example of Hospital & Insurance Company Access control

Connector to insuranceData components

Connector to HospitalData components

Insurance to Hospitalconnector

Hospital to Insuranceconnector

Connector to InsurancePresentation components

Connector to HospitalPresentation components

Notification onlyNotification only

Exchange of information is guided by US HIPPA rules

Trust Management• Trust management deals with how entities

– 1) establish and – 2) maintain

a trust relationship with each other

– This is especially important for decentralized and distributed environment where no information or only incomplete information exist about the communicating entities; each entity must adopt the appropriate measure to safeguard itself.

– It is important to pick an “appropriate” trust management scheme for decentralized and distributed systems.

Trust

• “Trust” is a broad term that has many definitions and has been studied by multiple disciplines because it is one of the fundamental element for our social existence.

• Diego Gambetta, professor of sociology at Oxford University, states trust as: “--- a particular level of the subjective probability with which

an agent assesses that another agent or group of agents will perform a particular action, both before he can monitor such action and in a context in which it affects his own action.”

a) Trust is a subjective and depends on the perspective of individualsb) Trust in the same person may vary and depends upon the contextc) Trust is conceived before the real action

Trust (cont.)• Gambetta introduced the notion of assigning “metric”

values to the property Trust such as:– Continuous real number (may not have a limit)– Binary value of (trust, no trust)– Set of discrete values

• The application of the metric depends on the application context:– Binary values may be used for either an entity is to be trusted or

not (give access or not); no partial trust or partial access.– A set of discrete, ordered values may be used if we need to

compare the trustworthiness (amount of trust?)of entities or provide a set of different levels of access

• Trust relationship may not be transitive– A trusts B and B trusts C does not imply A trusts C (because we

may switch context of the trust. e.g. A trusts B because they have worked before, B trust C because

they are friends. A does not trust C because A never worked with C nor are they friends

Trust Model

• A trust model describes the relationships among entities based on the defined property of trust.

A Trust Model includes and describes: a) the trust information that is used to establish the trust

relationship, b) how that trust information is obtained, c) how that trust information is combined to determine

trustworthiness, and d) how that trust information is modified (and reintroduced

into the trust relationship system) in response to personal and reported experiences.

Reputation Based “Trust model”• One way to address “trust” is to consider the sub-attribute,

“reputation”, and measure trust by reputation. That is the better the reputation of an entity, the more trustworthy is that entity.

• Reputation is an expectation about an individual’s behavior based on i) information about or ii) observations of

its past behavior.

• Reputation may be gathered either in a “centralized” fashion or in a “distributed” fashion.

• Reputation may be measured in many ways, too. Any suggestion ?

2 Sample Reputation Based Trust Model• E-bay and Amazon model:

– This is a centralized scheme– E-bay and Amazon acts as the central “keeper” and reputation– Participants of transactions on these sites may rate or evaluate their

transaction partners, by assigning a +1, 0 , or -1 to their partner after the transaction (with limitations such as only once a week)

– The ratings of the participant-profiles (as sellers or buyers) may be viewed by others.

• XRep model:– This is decentralized scheme– Proposed by E. Damiani (Univ. of Milan, Italy)– A P2P protocol that allows establishment of reputation in distributed

systems • query of reputation(searching others),• polling of reputation (from others), • vote evaluation of others’ inputs • Picking the “reputable” partner• Conduct business (e.g. download file) with that partner

Architectural Approach to Decentralized Trust Management

• Decentralized system is prone to attacks and it is especially important to design these systems carefully. There are 3 main steps to consider:

– Understanding and assessing the “threats” or damages that can result from security attacks

– Designing countermeasures against these “threats” or attacks

– Incorporating these guidelines corresponding to the countermeasures into the architectural style

Note the above usage of the term “threat” is a bit fluid.

Understanding and Assessing the various “threats”

Some thoughts on understanding and assessing threats:

• Impersonation: concealing the identity or misrepresenting the identity• Fraudulent action: acting in bad faith without impersonation• Misrepresentation: misrepresenting “trust” or other relationships• Collusion: joining together to subvert the system or trust relationships• Denial of Service: attacking a peer or group of peers to disable the system

from normal operation• Addition of unknowns: not knowing new entrant into the distributed

system and “bootstrapping” trust relationship• Deciding whom to Trust: what should be the model ---reputation? • Out of Band knowledge: information communicated outside of the system

or normal channel

Addressing “Threats”• Some thoughts on countermeasures to address threats:– Use of authentication: use some form of mechanism to uniquely

identify the message sender/receiver– Separation of internal beliefs and externally reported

information: internal perceptions may not be accurate for all contexts; thus it is important to separate that from externally reported information

– Making trust relationship explicit: without a “controlling” authority, the information provided by peers must be explicit and clear.

– Comparable trust: trust information should be comparable in semantics or it is very difficult to make evaluations on the multiple information

- How to Lessen Exposure: consider exposure of system internals

- My addition- Better fit for next slide?

Incorporating Guidelines into Architecture

• The earlier thoughts need to be incorporated into the architecture and design:– Digital identity: both physical and digital identity need to

be established in order to establish meaningful trust relationships

– Separation of internal and external data: clear separation of internal and external information establishes clear boundary and less confusion and exposure

– Making trust visible: publish the trust relationship to lessen misunderstanding and abuse

– Expression of trust: trust syntax and corresponding semantics should be comparable to allow broader usage and understanding

A Sample Architecture Style with 4“functional” layers for decentralized system

Communication Layer(handles interactions with other entities)

Information Layer(handles persistent storing/retrieval of information)

Trust Layer(computes “trustworthiness” and guides trust decisions)

Application Layer(performs application specific functionalities)