Security and Trust
description
Transcript of Security and Trust
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
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