1. 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)

2. 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

3. 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)

4. 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!

5. 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.)

6. 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 Privilege 2.Fail-safe Defaults 3.Economy of Mechanism 4.Complete Mediation 5.Open Design 6.Separation of Privilege 7.Least common Mechanism 8.Psychological Acceptability 9.Defense in Depth

7. 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

8. 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.

9. 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

10. 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

11. 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 accessed 3.The permission of the requestor to access that resource

12. 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.

13. Architectural Access Control Modeling access control at architectural level involves the following concepts : – Subject – Principal – Resource – Privilege – Safeguard – Policy

14. 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

15. 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.

16. 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).

17. A Simple Example of Hospital & Insurance Company Access control Connector to insurance Data components Connector to Hospital Data components Insurance to Hospital connector Hospital to Insurance connector Connector to Insurance Presentation components Connector to Hospital Presentation components Notification only Exchange of information is guided by US HIPPA rules

18. 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.

19. 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

20. 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

21. 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.

22. 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 ?

23. 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

24. 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.

25. 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

26. 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?

27. 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

28. 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)