security and trust security is one of the “non-functional” properties of the system (or is it...
TRANSCRIPT
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)