Security and TrustSoftware Architecture

Security ◦ C.I.A.

Confidentiality Integrity Availability

Design Principles Architectural Access Control

◦ Access Control Models◦ Connector-Centric Architectural Access Control

2

Outline

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

3

Security : Building 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

4

Security : Software architecture

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

5

Security

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

innappropriately by system users through available interfaces

◦ Protect information by storing sensitive data such that if some security measures are compromised the data is still safe

6

Confidentiality

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

7

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

8

Confidentiality : Cryptography

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

9

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

10

Integrity

Making a 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

11

Availability

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

12

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.

13

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

14

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

15

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

16

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

17

Design Principles

18

Microsoft IIS : Buffer overflow

Figure 13-1 Pg. 497

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

19

Access Control

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

20

Discretionary

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

21

Role Based

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

22

Mandatory

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

23

Connector-Centric Architectural Access Control (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

24

Connector-Centric AAC

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

25

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

26

AAC : Augmenting Components and Connectors

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.

27

AAC: Secure xADL

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

28

Checking AAC

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 29

Example : Secure Cooperation

30