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,” “nonshattering 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.
2.
3.
4.
5.
6.
7.
8.
9.
Least Privilege
Fail-safe Defaults
Economy of Mechanism
Complete Mediation
Open Design
Separation of Privilege
Least common Mechanism
Psychological Acceptability
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.
2.
3.
Identity of the requestor
The resource to be accessed
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-theshelf component).
A Simple Example of Hospital & Insurance Company Access control
Connector to insurance
Data components
Insurance to Hospital
connector
Connector to Insurance
Presentation components
Connector to Hospital
Data components
Hospital to Insurance
connector
Connector to Hospital
Presentation components
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 individuals
b) Trust in the same person may vary and depends upon the context
c) 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
- My addition
- Better fit for next slide?
- How to Lessen Exposure: consider exposure of system internals
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)