Security and Trust

1. Security and Trust Software Architecture

2. Outline • Security • C.I.A. • Confidentiality • Integrity • Availability • Design Principles • Architectural Access Control • Access Control Models • Connector-Centric Architectural Access Control

3. Security : Building architecture • A building is designed with various structural properties • Security can be one of those but it does not have to be • Often depends on the use of the building • A Non-Functional Property • Should not affect the function of a system • Unless the systems function is security • Can be designed from the onset or added in later • The latter is often more expensive

4. Security : Software architecture • Software is designed with various properties • Security can be one of those but it does not have to be • Often depends on the software function • A Non-Functional Property • Should not affect the function of a software system • Can be included from the onset or added in later • Even if added later, the software still needs to allow such addition without compromising functionality • Timing and power constraints for example • Again, the latter is often more expensive

5. Security • Definition: “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” • National Institute of Standards and Technology (NIST) • CIA • Confidentiality • Integrity • Availability

6. Confidentiality • preventing unauthorized parties from accessing or being aware of the existence of information on a system. • Not only should a users information be protected, but the fact that the user even exists should remain hidden • Systems should take proper measures to • Protect information from being intercepted • Protect information from being accessed innappropriatelyby system users through available interfaces • Protect information by storing sensitive data such that if some security measures are compromised the data is still safe

7. Confidentiality : Cryptography • A basic measure through which data can be obfuscated • Encryption can be described with the following • Cipher = EncryptionFunction( Key, Plaintext) • PlainText = DecryptionFunction(Key, Cipher) • Key = An input to the encryption or decryption function used to scramble or unscramble a set of text • Shared or Symmetric Key – the key is the same • Is faster but weaker • Public or Asymmetric Key – There is more than one key • Is slower but stronger

8. Confidentiality : Cryptography • Symmetric or Shared Key Cryptography • There exists only 1 key, used for encryption and decryption • This key must be possessed by all users of the system • Public or Asymmetric Key Cryptography • There exists multiple keys (usually 2) • If text is encrypted by key 1, only key 2 can decrypt it • One key is made public and another is kept private • Users send messages using the recipient’s public key • Only the private key can decrypt the message • The user with the private key can authenticate his/her self using some agreed message • Only the private key can write a message that can be decrypted with the public key • A timestamp is often attached to prevent repeats

9. Integrity • Only authorized parties can manipulate the information and do so only in authorized ways. • In programming : Public & Private fields • In architecture : If an interface changes critical information, only authorized components should be able to access that interface • Authentication – the process of associating a user with a predetermined identity • Username/Password, Biometrics, etc • Can exist at different levels of granularity • Session, Method Call, Packet

10. Integrity • Authorization - “the function of specifying access rights to resources” – wikipedia • As a group – roles or groups • Individually – per user basis • Audit Trail • Deter potential intruders • By keeping a record of their actions • Prevents denial of actions • Proof of who made what change • Simplifies restoration of system files • By recording what changes were made

11. Availability • Makinga resource accessible by authorized parties • Availability is protecting users from system downtime • Malicious intent – A denial of service attack • Neutral event– An earthquake • In design : • Avoid a single point of failure • One location that, if compromised, takes the whole system offline • Distribute data across multiple systems • To prevent a flaw in a single system crash from denying access • Maintain replicas of data in different physical locations • To account for environmental disasters

12. Design Principles • Least Privilege: give each component only the privileges it requires • Prevents accidental access by unauthorized components • If a component is compromised this limits its threat • Promotes cost effective design : Components with low or no privilege are lower risk and as such often need fewer security resources. • Bank : Front door vs. Vault Door

13. Design Principles • Fail-safe Defaults: deny access if explicit permission is absent • Better to prevent malicious access and deny some safe requests then to allow some malicious access and approve all safe requests • Example : URL – It would be difficult to list all invalid forms, instead we list only accepted forms • In Design : Components should only allow communication that fits some approved set of criteria and reject all others.

14. Design Principles • Economy of Mechanism: adopt simple security mechanisms • The more complicated a mechanism the greater the likely hood of a security loophole • KISS – Keep it Simple Small (Stupid) • Complete Mediation: ensure every access is permitted • All communication should be checked regardless of who is communication • All communication must meet requirements

15. Design Principles • Open Design: do not rely on secrecy for security • Someone, Somewhere, will figure out how your system works if given the time and incentive • Often revealing system design can increase security • Two heads (or many) are better than one • Separation of Privilege: introduce multiple parties to avoid exploitation of privileges • An employee approving his/her own raises • Software privileges separated among components • If one component is compromised exploitation might still be stopped

16. Design Principles • Least Common Mechanism: limit critical resource sharing to only a few mechanisms • Prevent one way to access all critical resources • Limits damage caused from a compromised mechanism • In software architecture caution must be used when designing such systems

17. Design Principles • Psychological Acceptability: make security mechanisms usable • If its too hard to use no one will use it • Example Requiring a password to be 20 characters • Defense in Depth: have multiple layers of countermeasures • Limit single point of failure • Example : 2 step authentication • Username and password as well as something else

18. Microsoft IIS : Buffer overflow Figure 13-1 Pg. 497

19. Access Control • Granting or Denying access • Kinds of Access Control • Discretionary • Uses identity, the resource, and permission to access • Role Based • Similar to discretionary • Roles have permissions • Mandatory access control • Policy based

20. Discretionary • Takes three data items into account • List of users : Bob, Jake, Jane, Alice • Resources : Payroll, Deployed Servers, Patent Server • Access for each resource • Bob : Read/write to payroll • Jake : Read to payroll and Deployed services • Jane and Alice : Read/Write/Execute on the Patent Server

21. Role Based • Takes three data items into account • Roles: Administrator, Employee, Guest user • Resources : Company Internet, User Accounts, Guest Internet • Access for each resource • Admin: Can use company internet, modify user accounts, can use guest internet • Employee: Can access company and guest internet • Guest: Can access guest internet • Multiple users can have the same role • Roles can form a hierarchy and can inherit qualities • Simplifies the administration process

22. Mandatory • Are More Strict than discretionary models • Can prevent both direct and indirect access • Example : Multi Level Security (MLS) • System composed of Subjects and Objects • Subjects have clearance • Objects have a security label • Labels have dominance • A subject can access objects at his/her level of clearance and below • In some cases a subject can only introduce content at his/her level or above • prevent leaking information to lower levels

23. Connector-Centric Architectural Access Control (AAC) • Show how Access control methods can be applied and enforced at the architectural level. • Extending Architecture to model security • Centered on connectors because connectors propagate privileges necessary to make decisions. • Core Terms • Subject – A user executing a piece of software • Often component and connectors do not take the user executing their code into account • Principal – A credential belonging to a subject • A role or identity in the system

24. Connector-Centric AAC • Core Terms (Continued) • Resource - An entity needing protected access Databases, components, and connectors • Permission, Privilege, and Safeguard • Permission – An action • Privilege – a set of permissions • Safeguard – A set of conditions that must be met in order for access to be granted • Policy – Specifies what privileges a subject with a given set of principles should have to access resources protected by a safeguard

25. AAC : Augmenting Components and Connectors • Components : Supply Security Contract • A component must specify the privileges and Safeguards of an architectural element • In xADL (chapter 6), the component type supplies interface signatures • These signatures describe the components functionality • These are the active resources to be protected • As such signatures are augmented with safeguards

26. AAC : Augmenting Components and Connectors • Connectors : Regulate and Enforce Contract • Can determine subjects for which a connected component is executing • Crucial to applying policy • Ex: an SSL connector would have the server authenticate itself, thus providing its identity • Can determine privilege of a component • Can allow or deny communication based on this • Can provide secure communication between insecure components

27. AAC: Secure xADL • Combines xADL with architectural access control as described previously • Embeds policies into xADL syntax • Uses XACML – eXtensible Access Control Markup Language • Used in an environment where requests in XACML can be accepted or denied by consulting predefined policy.

28. Checking AAC • Each component has a set of interfaces • Incoming – provided functionality; possesses safeguards • Outgoing – needed functionality; possesses privileges • Interfaces can communicate through a connector • Simple Approach : Check that the accumulated privileges of an accessing element cover the accumulated permissions of the accessed element • This allows one to include privileges and safeguards acquired from several sources • itself, component type, containing sub-architecture

29. Example : Secure Cooperation • Allows two parties, who do not fully trust each other, to share data. • Data must be subject to control of the sharing party • Example : Insurance company and a hospital • Only wish to communicate billing information • This information might be limited by certain laws • Rules can be enforced by setting policies on connectors responsible for routing messages • Communication can only occur when • Connectors are properly instantiated and connected with other elements • Policy on message routing is followed