Secure Systems Requirements and Construction with Security Patterns - PowerPoint PPT Presentation

Loading...

PPT – Secure Systems Requirements and Construction with Security Patterns PowerPoint presentation | free to download - id: 7d1fd7-YTNkO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Secure Systems Requirements and Construction with Security Patterns

Description:

Secure Systems Requirements and Construction with Security Patterns Eduardo B. Fernandez Dept. of Computer Science and Engineering Florida Atlantic University – PowerPoint PPT presentation

Number of Views:145
Avg rating:3.0/5.0
Slides: 248
Provided by: EdFe5
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Secure Systems Requirements and Construction with Security Patterns


1
Secure Systems Requirements and Construction
with Security Patterns Eduardo B. Fernandez
  • Dept. of Computer Science and Engineering
    Florida Atlantic UniversityBoca Raton, FL, USA
  • http//www.cse.fau.edu/ed
  • ed_at_cse.fau.edu

2
Abstract
  • Patterns combine experience and good practices to
    develop basic models that can be used to build
    new systems and to evaluate existing systems.
    Security patterns join the extensive knowledge
    accumulated about security with the structure
    provided by patterns to provide guidelines for
    secure system requirements, design, and
    evaluation. We consider the structure and purpose
    of security patterns, show a variety of security
    patterns, and illustrate their use in the
    construction of secure systems. These patterns
    include among others Authentication,
    Authorization/Access Control, Firewalls, Secure
    Broker, Web Services Security, and Cloud
    Security. We have built a catalog of over 100
    security patterns. We introduce Abstract Security
    patterns (ASPs) which are used in the
    requirements and analysis stages. We complement
    these patterns with misuse patterns, which
    describe how an attack is performed from the
    point of view of the attacker and how it can be
    stopped. We integrate patterns in the form of
    security reference architectures. We introduce
    patterns in a conceptual way, relating them to
    their purposes and to the functional parts of the
    architecture. Example architectures include a
    financial system and a cloud computing system.
    The use of patterns can provide a holistic view
    of security, which is a fundamental principle to
    build secure systems. The patterns and reference
    architectures are shown using UML models and
    examples are taken from my two books on security
    patterns as well as from my recent publications.
    The patterns are put in context that is, we do
    not present a disjoint collection of patterns but
    we present a logical architectural structuring
    where the patterns are added where needed. In
    fact, we present a complete methodology to apply
    the patterns along the system lifecycle.For this
    conference we emphasize the early lifecycle
    stages but also show the effect of the
    requirements in the later stages.

3
About me
  • Professor of Computer Science at Florida Atlantic
    University, Boca Raton, FL., USA
  • At IBM for 8 years (L.A. Scientific Center).
  • Wrote the first book on database security
    (Addison-Wesley, 1981).
  • Author of many research papers
  • Consultant to IBM, Siemens, Lucent,
  • MS EE Purdue U, PhD CS UCLA

4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
Outline
  • Security concepts
  • Threats
  • Approaches to security
  • The design of secure systems
  • Security patterns
  • Principles and policies
  • Using the patterns
  • Architectural layers and patterns, Abstract
    security patterns
  • Security models and their patterns---policies,
    access matrix, multilevel models, RBAC
  • Conceptual models in applications
  • Operating systems patterns
  • Network layer patterns
  • Patterns for web services and cloud computing,
    misuse patterns

8
Outline II
  • A methodology for building secure architectures
  • Defining authorizations from use
    cases---nonfunctional aspects of use cases, RBAC
    and security policies. Security Logging/Auditing.
    Authentication.
  • Security reference architectures (SRAs), a SRA
    for cloud systems, a financial SRA
  • Coordination across levels---mapping of
    authorizations across architectural levels
    relating threats to use cases.
  • Secure semantic analysis patterns
  • Case studies a financial system, a cloud system
  • Conclusions---the future

9
Objectives
  • Get a panorama of security patterns and their use
  • Study some specific patterns in detail
  • Consider a systematic approach to build secure
    systems based on patterns and UML

10
Security concepts
  • Motivation and Objectives
  • Countermeasures
  • Security architectures

11
The value of information
  • Individuals and enterprises rely on information
    for credit, health, professional work, business,
    education,
  • Illegal access (reading or modification) to
    information can produce serious problems
  • Because of its value, information is a growing
    target of attacks

12
Cost of data breaches
  • An attack on Google cost that company about
    500,000 in 2005.
  • In a recent study (Ponemon Institute), the
    average cost of a data breach for a company was
    3.75 M in 2014, and the average cost for each
    stolen or lost record was 154.

13
Security is the protection against
  • Unauthorized data disclosure (confidentiality or
    secrecy).
  • Unauthorized data modification (integrity).
    Unauthorized modification of data may result in
    inconsistencies or erroneous data. Data
    destruction may bring all kinds of losses.
  • Loss of availability (Denial of service)Users or
    other systems may prevent the legitimate users
    from using their system.
  • Lack of accountabilityUsers should be
    responsible for their actions and should not be
    able to deny what they have done
    (non-repudiation).

14
The meaning of security
  • Security implies providing these objectives in
    the presence of attacks
  • Security requires technical, managerial, and
    physical countermeasures (defenses)
  • We only consider technical aspects here
  • A related aspect is privacy, a legal and ethics
    concern

15
Countermeasures I
  • Identification and Authentication
    (IA)Identification is a user or system action
    where the user provides an identity.
    Authentication implies some proof that a user or
    system is the one he/it claims to be.
  • Authorization and Access control (A
    A)Authorization defines permitted access to
    resources depending on the accessor (user,
    executing process), the resource being accessed,
    and the intended use of the resource. Access
    control requires some mechanism to enforce
    authorization
  • Logging and Auditing (LA)These functions imply
    keeping a record (log) of actions that may be
    relevant for security and analyzing it later.
    They can be used to collect evidence for
    prosecution (forensics) and to improve the system
    by analyzing why the attack succeeded.

16
Countermeasures II
  • Hiding of informationHiding the contents of
    information is usually performed by the use of
    cryptography but steganography is another option.
    The idea is to make the information unreadable to
    an attacker.
  • Intrusion detectionIntrusion Detection Systems
    (IDS) alert the system when an intruder is trying
    to attack the system.

17
Basic secure architecture
  • Authentication must happen first
  • Authorization rules define what is allowed or not
    allowed (who can see what and how)
  • Lower architectural levels enforce
    authentication and authorization
  • Cryptography protects messages in transit and
    stored data, and provides non-repudiation and
    authentication
  • Continuous logging for later auditing

18
Security environments or contexts
  • Early systems were isolated and single user --few
    security problems
  • Mainframes brought many users but we knew them
    (registered)complexity and attacks increased
  • Distributed systems increased the problem by
    scattering the users

19
Environments II
  • The Internet opened up our systems to unknown
    usersexponential growth in attacks
  • Wireless devices increase the problem because of
    their number and ubiquity
  • The widespread use of sensors will make security
    even worse
  • The cloud brings new problems

20
(No Transcript)
21
Threats
  • We need to understand the threats to the system
    to decide how to defend it
  • Excess of security mechanisms results in loss of
    performance, extra complexity, and higher costs
  • The objective is to provide an appropriate
    defenses according to the value of our assets

22
Attacks and defenses
  • Generic attacks are realized in two basic ways
    by direct attacks from a person trying to exploit
    a vulnerability or flaw in the system, or using
    malware, software that contains code that
    exploits one or more of these flaws
  • Security defenses may operate in one or more of
    three modes and we need to combine them
  • Prevent or mitigate an attack. Prevention means
    completely stopping the attack while mitigation
    implies partial defense or reducing its effects
  • If we cannot stop or mitigate the attack, at
    least we should be able to know that an attack is
    happening, i.e., we should detect the attack.
    Detection is also useful to stop an attack
    because it can alert other mechanisms to take
    action
  • After the attack has happened we need to have
    ways to recover from its effects and analyze it
    so we can improve the system

23
Types of Threats
  • Direct attacks to the operating system
  • Direct attacks to the database system
  • Directs attacks to the application
  • Denial of service
  • Almost no attacks to the messages in the network
  • Malware Trojan horses, viruses, worms
  • Repudiation

24
(No Transcript)
25
Approaches to security
  • Formal models do not prove security because they
    make many assumptions which may not be true in
    practice. Also have size limitations.
  • Cryptographic methods are effective but only for
    specific aspects system or message
    authentication, secure transmission of messages,
    storage protection. They cannot stop attacks
    based on code or system flaws.
  • Code-based methods cannot find all
    vulnerabilities because many attacks exploit
    system interactions, not code flaws.
  • Model-based security can build a strong structure
    where parts of the system may be compromised but
    the essential parts of the system can be
    protected (submarine effect).

26
Approaches to security
Model checking and composability of systems
Verification
Theoretical Analysis of
Security
UML/OCL models Security patterns
Certification
Model-driven Security
Vulnerability analysis Code examination Best
practices
Code-based Security
Certification
27
Current situation
  • The Internet is an insecure place and attacks
    keep occurring
  • One of the main reasons is the poor quality of
    the software used in systems and application
    software
  • Software engineering neglected security for a
    long time

28
A possible remedy
  • Help designers build secure systems using a
    systematic approach
  • Provide units of security (packed solutions to
    specific problems)
  • Build security together with the functional part
    of the application
  • Use a model-based approach

29
Security Patterns
Software Engineering
30
Security patterns
  • Idea
  • Anatomy of a pattern
  • Classifications

31
Patterns
  • A pattern is a solution to a recurrent problem in
    a specific context
  • Idea comes from architecture of buildings (C.
    Alexander)
  • Applied initially to software and then extended
    to other domains
  • Appeared in 1994 and are increasingly being
    accepted by industry

32
Value
  • Reusable solutions, but maybe not directly,
    usually require tailoring
  • Encapsulate experience and knowledge of designers
    (best practices)
  • Free of errors after a while
  • Need to be catalogued to be useful
  • Used as guidelines for design
  • Good to evaluate systems and standards
  • Useful for teaching

33
Why security patterns?
  • Analysis patterns can be used to build conceptual
    models of software, design patterns can be used
    to make software more flexible and reusable, and
    security patterns can be used to build secure
    systems, including hardware or organizational
    problems.
  • Security has had a long trajectory, starting from
    the early models of Lampson and Bell/LaPadula in
    the early 70s, and resulting in a variety of
    approaches to analyze security problems and to
    design security mechanisms. It is natural to try
    to codify this expertise in the form of patterns.
  • Security patterns describe mechanisms to stop
    some attacks and apply principles of good design

34
Value of security patterns
  • Can describe security principles (Single Point of
    Access) or security mechanisms (Firewalls)
  • Can guide the design and implementation of the
    security mechanism itself
  • Can guide the use of security mechanisms in an
    application (stop specific threats)
  • Can help understanding and use of complex
    standards (XACML, WiMax)
  • Good for teaching security principles and
    mechanisms

35
POSA template (Buschmann)
  • Intent (thumbnail)
  • Example
  • Context
  • Problem and forces
  • Solution in words, UML models (static and
    dynamic)
  • Implementation
  • Example resolved
  • Known uses
  • Consequences
  • See also (related patterns)

36
Anatomy of a security pattern
  • Every pattern starts with a thumbnail of the
    problem it solves and a brief description of how
    it solves the problem.
  • The Packet Filter Firewall filters incoming and
    outgoing network traffic in a computer system
    based on packet inspection at the IP level.

37
Context section
  • We define the context or environment where the
    pattern solution is applicable
  • Context
  • Computer systems on a local network connected to
    the Internet and to other networks with different
    levels of trust. A host in a local network
    receives and sends traffic to other networks.
    This traffic has several layers or levels. The
    most basic level is the IP level, made up of
    packets consisting of headers and bodies
    (payloads). The headers include the source and
    destination addresses as well as other routing
    information, the bodies include the message
    payloads.

38
Problem Section I
  • Now a generic description of what happens when we
    dont have a good solution We also indicate the
    forces that affect the possible solution. We may
    list all attacks that we want to stop with this
    solution.
  • Problem
  • Some of the hosts in other networks may try to
    attack the local network through their IP-level
    payloads. These payloads may include viruses or
    application-specific attacks. We need to identify
    and block those hosts.

39
Forces
  • We need to communicate with other networks so
    isolating our network is not an option. However,
    we do not want to take a high risk.
  • The protection mechanism should be able to
    reflect precisely the security policies of the
    institution. A too coarse defense may not be
    useful.
  • Any protection mechanism should be transparent to
    the users. Users should not need to perform
    special actions to be secure.
  • The cost and overhead of the protection mechanism
    should be relatively low or the system may become
    too expensive to run.
  • Network administrators deploy and configure a
    variety of protection mechanisms hence it is
    important to have a clear model of what is being
    protected.
  • The attacks are constantly changing hence it
    should be easy to make changes to the
    configuration of the protection mechanism.
  • It may be necessary to log input and/or output
    requests for auditing and defense purposes.

40
Solution section
  • The solution section describes the idea of the
    pattern. A descriptive figure may help to
    visualize the solution.
  • Solution
  • A Packet Filter Firewall intercepts all traffic
    coming/going from a port P and inspects its
    packets (Figure 1). Those coming from or going to
    untrusted addresses are rejected. The untrusted
    addresses are determined from a set of rules that
    implement the security policies of the
    institution. A client from another network can
    only access the Local Host if a rule exists
    authorizing traffic from its address. Rules may
    be positive (allow traffic from some address) or
    negative (block traffic). Additionally, if a
    request is not satisfied by any of the Explicit
    Rules, then a Default Rule is applied.

41
Idea of the solution
42
Structure of the solution
43
Filtering a clients request
44
Implementation section
  • What one should consider when implementating the
    pattern is the objective of the next section.
    This can be a set of general recommendations or a
    sequence of what to do to use the pattern. It may
    include some sample code if appropriate.
  • Implementation
  • Define an institution policy about network
    access, classifying sites according to our trust
    in them.
  • Convert this policy into a set of access rules.
    This can be done manually, which may be complex
    for large systems. An alternative is using an
    appropriate commercial product. .
  • Note that the idea of a single point of access is
    virtual, there may be several physical firewalls
    deployed at different places. This means it is
    necessary to install firewalls at all external
    boundaries (routers or gateways).
  • Write the rules in each firewall. Again, products
    such as Solsoft and others automatically
    propagate the rules to each registered firewall.
  • Configure the corresponding firewalls according
    to standard architectures. A common deployment
    architecture is the Demilitarized Zone (DMZ)
    Sch06.

45
Known uses section
  • To accept this solution as a pattern we should
    find at least three examples of its use in real
    systems.
  • Known Uses
  • This architecture can be found in commercial
    firewall products such as ARGuE (Advanced
    Research Guard for Experimentation), OpenBSD
    Packet Filtering Firewall (the basic firewall
    architecture for the Berkeley Software
    Distribution system) and the Linux Firewall, the
    basic firewall architecture used with the Linux
    operating system.

46
Consequences--advantages
  • The Consequences section indicates the advantages
    and disadvantages of the solution embodied in
    this pattern. The advantages should match the
    forces in the Problem section.
  • Consequences
  • The Packet Filter Firewall Pattern has the
    following advantages
  • A firewall transparently filters all the traffic
    that passes through it, thus lowering the risk of
    communicating with potentially hostile networks.
  • It is possible to express the institution
    filtering policies through its filtering rules,
    with different levels of protection for different
    parts of the network.
  • It is easy to update the rule set to counter new
    threats.
  • Because it intercepts all requests, a firewall
    allows systematic logging of incoming and
    outgoing messages. Because of this, a firewall
    facilitates the detection of possible attacks and
    helps to hold local users responsible of their
    actions when interacting with external networks.
  • Low cost, it is included as part of many
    operating systems and simple network devices such
    as routers.
  • Good performance. It only needs to look at the
    headers of IP packets, not at the complete
    packet.
  • It can be combined with Intrusion Detection
    Systems (IDS) for greater effectiveness. In this
    case, the IDS can tell the firewall to block
    suspicious traffic. This can also be useful to
    control Distributed Denial of Service (DDoS)
    attacks.

47
Consequences--disadvantages
  • The firewalls effectiveness and speed may be
    limited due to its rule set (order of
    precedence). Addition of new rules may interfere
    with existing rules in the rule set hence, a
    careful approach should be taken in adding and
    updating access rules.
  • The firewall can only enforce security policies
    on traffic that goes through the firewall. This
    means that one must make changes to the network
    to ensure that there are no other paths into its
    hosts.
  • An IP-level firewall cannot stop attacks coming
    through the higher levels of the network. For
    example, a hacker could put malicious commands or
    data in header data not used for routing and in
    the payload.
  • Each packet is analyzed independently, which
    means that it is necessary to analyze every
    packet. This may reduce performance.
  • A packet filter cannot recognize forged addresses
    (IP spoofing) because it only examines the header
    of the IP packet. This can be corrected (at some
    extra cost) using Link Layer filtering, where
    each IP address is correlated to its hardware
    address Fra01.

48
Related patterns section (See also)
  • Finally, we relate our pattern to other known
    patterns. Those may be complementary patterns,
    variations of our pattern, or extensions of it.
  • The Authorization pattern Fer01 defines the
    standard security model for the Packet Filter
    Firewall Pattern. This pattern is also a special
    case of the Single-Point-of-Access Sch06 and it
    is the basis for other, more complex, types of
    firewalls (described in the other patterns in
    this language). The DMZ pattern Sch06 defines a
    way to configure this pattern in a network. This
    pattern can also be combined with the Stateful
    Inspection Firewall Sch06.

49
The design of secure systems
  • Security should be applied where the application
    semantics is understood
  • Security is an all-levels problem
  • High-level policies can be mapped to the lower
    levels
  • We need precise models to guide system
    development

50
Secure Design II
  • A unified system is easier to understand better
    design, better administration
  • Easier to analyze effect of new hardware or
    software
  • Apply principles of good design
  • Start from principles, policies, and models
  • Apply security throughout the lifecycle

51
Principles of design for security
  • Closed system. Anything not explicitly allowed is
    forbidden. The policy is applied to application
    rights and to process resource access during
    execution. This policy can be considered a
    special case of fail-safe defaults (see below).
  • Open design. When the mechanism is subject to
    public scrutiny it is easier to find flaws and
    with time it becomes increasingly secure. Some of
    the data used in the security system could be
    secret though, e.g., passwords, keys.
  • Least privilegeAssign only the necessary rights
    to perform functions
  • Economy of mechanism. The security mechanisms
    should be as simple and small as possible. This
    makes comprehension, testing, and analysis
    easier.

52
Principles II
  • Complete mediation. Every request for access must
    be validated.
  • Minimal trust. The parts of the system that must
    be trusted should be minimal.
  • Separation of privilege. Critical actions may
    need two independent mechanisms to agree before
    being performed.
  • Least common mechanism. Do not mix security with
    other functions.
  • Ease of use or transparency. Users must accept
    the security system or they will not use it.
    Security functions must be transparent or at
    least easy to use.
  • Information hiding and encapsulation.
    Implementation details should not be exposed,
    only a clear, functional interface should be
    shown.

53
Security principles III
  • Holistic approach--Cover all architectural levels
    and all units
  • Highest levelsecurity constraints must be
    defined where their semantics are clear and
    propagated down
  • Defense in depthhave more than one line of
    defense
  • Separate and compartmentalize (submarine
    principle)
  • Secure defaults

54
(No Transcript)
55
Policies
  • Institution policies
  • Security policies
  • Example

56
Need for policies
  • The policies of an institution define its way of
    accomplishing its objectives
  • Security policies define a way to protect its
    information applying principles
  • Without policies we dont know what we should
    protect
  • Policies can be realized by tactics applied to
    the system architecture

57
Some security policies
  • Open/closed systems--In a closed system
    everything is forbidden unless explicitly allowed
  • Need-to-know (Least privilege)-- Give enough
    rights to perform duties
  • Information belongs to the institution versus
    private ownership
  • Authorization-- access types, small units of
    access

58
Security policies II
  • ObligationWhat has to be done before accessing
    data
  • Separation of dutySeparate critical functions
    into parts to be done by different people or
    systems
  • Content-dependent access controlAccess decision
    are based on the values of the data
  • Authenticate all transactionsneeded for
    accountability and access control

59
Use of policies
  • Secure systems must be closed but sometimes open
    access to information is more important, e.g.,
    libraries, data warehouses,
  • The least privilege principle must be applied
    with an appropriate granularity, many attacks
    happen because of too many rights

60
Example of university policies
  • An instructor can look at all the information
    about the course he is teaching.
  • An instructor can change the grades of the
    students in the course he is teaching
  • A student may look at her grades in a course she
    is taking
  • The department head can add/delete course
    offerings
  • The registrar can add/delete students from course
    offerings
  • Faculty members can look at information about
    themselves

61
Using the patterns
  • Catalogs of patterns are not enough, designers
    must be given guidance in their use
  • There are many patterns (growing in number) and
    the task of selecting them gets harder
  • A first approach is to classify the patterns
    according to some criteria

62
Pattern diagrams
  • Show relationships between patterns
  • Nodes are patterns
  • Links are relationships
  • Links are labeled with type of dependency or
    contribution
  • Useful to guide the designer in the selection of
    patterns
  • Can go in Introduction to a set of patterns, or
    in Context, or in See also

63
Pattern diagram
64
How to classify security patterns?
  • Avgeriou and Zdun classified architectural
    patterns using the type of concerns they address,
    e.g. Layered Structure, Data Flow, Adaptation,
    User Interaction, Distribution.
  • Security patterns can be classified according to
    type of mechanism, e.g. access control,
    authentication,
  • A computer system is a hierarchy of layers, where
    the application layer uses the services of the
    database and operating system layers, which in
    turn, execute on a hardware layer.
  • We combine these two classifications

65
(No Transcript)
66
More advanced classifications
  • Use a multidimensional matrix
  • Dimensions may include architectural level,
    lifecycle stage, concern, type of pattern,
    domain,
  • Example XACML

67
(No Transcript)
68
Layers pattern
  • Its main idea is the decomposition of a system
    into hierarchical layers of abstraction, where
    the higher levels use the services of the lower
    levels.
  • We saw two examples earlier
  • Some of the layers shown can be further
    decomposed into sub-layers or the decomposition
    can be done along slightly different aspects,
    e.g., emphasizing the DBMS
  • Among the advantages of the Layers pattern we
    have the flexibility to make changes to the lower
    levels without affecting the higher levels and
    the possibility of hiding sensitive aspects of
    the system
  • Among its disadvantages we have the extra
    overhead due to indirection.

69
Security principles for layers
  • Security constraints should be defined at the
    highest layer, where their semantics are clear,
    and propagated to the lower levels, which enforce
    them.
  • All the layers of the architecture must be
    secure.
  • We can define patterns at all levels. This allows
    a designer to make sure that all levels are
    secured, and also makes easier propagating down
    the high-level constraints.

70
We can use patterns at all levels
  • Patterns for models define the highest level
  • At each lower level we refine the patterns at the
    previous level to consider the specific aspects
    of each level
  • Well analyze some patterns from each layer

71
Security layers
72
Abstract security patterns (ASPs)
  • Describe a conceptual security mechanism that
    realizes one or more security policies able to
    handle (stop or mitigate) a threat or comply with
    a security-related regulation or institutional
    policy.
  • Some of the ASPs correspond to basic security
    mechanisms, e.g., Access control (Authorization
    and Reference Monitor), Security Logger/Auditor,
    and Authenticator.
  • Others specify more detailed aspects, e.g. Access
    Control/Authorization models include the Access
    Matrix, Role-Based Access Control (RBAC), and
    Multilevel models .
  • Starting from ASPs, when building the lifecycle
    of a complete application we can use a hierarchy
    of patterns going from abstract security patterns
    to platform-oriented versions of these patterns
    and their code realizations.

73
Authenticator
  • How to verify that a subject is who it says it
    is? Use a single point of access to receive the
    interactions of a subject with the system and
    apply a protocol to verify the identity of the
    subject.

74
Class diagram of Authenticator ASP
75
Authentication
76
Authenticator hierarchy
77
Authorization models
  • Used in conceptual models of an application
  • Propagated to the lower levels

78
Access control
  • Authorization rules that specify who has access
    to what and how
  • Different models define rules appropriate for
    specific environments
  • Enforcement intercept access requests and verify
    that they are authorized
  • Enforcement is embodied in a Reference Monitor

79
(No Transcript)
80
Applic. Layer Access control models
  • Authorization. How do we describe who is
    authorized to access specific resources in a
    system? A list of authorization rules describes
    who has access to what and how.
  • Role-Based Access Control (RBAC). How do we
    assign rights to people based on their functions
    or tasks? Assign people to roles and give rights
    to these roles so they can perform their tasks.
  • Multilevel Security. How to decide access in an
    environment with security classifications.

81
More access control
  • Metadata-Based Access Control, later renamed
    Attribute-Based Access Control (ABAC). Allow
    access to resources based on the attributes of
    the subjects and the properties of the objects
  • Reference Monitor. Enforces the rules defined by
    any of these models

82
Access matrix authorization rules
  • Basic rule ( s, o, t ) , where s is a subject
    (active entity), t is an access type, and o is an
    object
  • Extended rule ( s, o , t , p, f) , where p is a
    predicate (access condition or guard) and f is a
    copy flag
  • This, and the other models, can be described by
    patterns

83
Authorization/Access Matrix
84
Access Matrix
85
(No Transcript)
86
Reference Monitor
  • Each request for resources must be intercepted
    and evaluated for authorized access
  • Abstract concept, implemented as memory access
    manager, file permission checks, CORBA adapters,
    etc.

87
Reference Monitor idea
88
Reference monitor pattern
89
(No Transcript)
90
Role-Based Access Control
  • Users are assigned roles according to their
    functions and given the needed rights (access
    types for specific objects)
  • When users are assigned by administrators, this
    is a mandatory model
  • Can implement least privilege and separation of
    duty policies

91
(No Transcript)
92
Growing models
  • We can grow models by adding classes, e.g. from
    Authorization to RBAC we add a Role class.
  • We can add sessions as execution context
  • We can add hierarchies of roles and of objects
    (Composite pattern)
  • Subroles inherit role rights from superclass
    roles.
  • Access to an object gives implicit access to its
    subobjects

93
Extended RBAC
  • Concept of session
  • Separation of administrative roles
  • Composite roles
  • Groups of users

94
(No Transcript)
95
Extended RBAC pattern
96
Attribute-Based Access Control
  • In the Internet we need to deal with
    non-registered users
  • Determine effective subjects and objects based on
    attribute values

97
Mandatory models
  • In a mandatory model users are assigned to
    classifications by administrators
  • Need trusted processes to perform administrative
    functions
  • Typically use data labels (tags) to enforce
    security
  • It is the most secure model but it is rigid

98
Multilevel model
  • In this model users and data are assigned
    classifications or clearances
  • Classifications include levels (top secret,
    secret,), and compartments (engDept,
    marketingDept,)
  • For confidentiality, access of users to data is
    based on rules defined by the Bell-LaPadula
    model, while for integrity, the rules are defined
    by Bibas model

10/15/2016
98
99
Multilevel security model
100
Multilevel properties
  • Simple security (ss) property. A subject s may
    read object o only if its classification
    dominates the objects classification, i.e., C(s)
    gt C(o). This is the no read-up property.
  • -Property. A subject s that can read object o is
    allowed to write object p only if the
    classification of p dominates the classification
    of o, i.e., C(p) gt C(o). This is the no
    write-down property.

101
(No Transcript)
102
Conceptual models in applications
  • We can apply the abstract models to define
    application constraints and policies
  • Example of medical policies

103
Some policies for medical information
  • Patients can see their records, consent to their
    use, must be informed of their use
  • A doctor or other medical employee is responsible
    for use of record (custodian)
  • Records of patients with genetic or infectious
    diseases must be related

104
(No Transcript)
105
Analogy Sarbanes Oxley policies
106
OCL (Object Constraint Language)
  • Similar to Z and SQL, 1st order predicate
    calculus
  • Adds precision to UML constraints
  • Implementation oriented
  • Important for safety-critical applications

107
Operating system layer
  • OS architectures
  • OS security features
  • Virtualization

108
Operating systems functions
  • Controls system resources
  • In direct contact with hardware
  • Process and processor management
  • Memory management --executing programs
  • Data management persistent data
  • I/O devices -- disks, communications ,
  • Controls login

10/15/2016
108
109
Processes
  • A process is defined by its Process Control Block
    (PCB), a data structure containing its id, and
    references to its context.
  • A process should receive a separate address space
    for its execution.
  • A thread is a lightweight process (faster context
    switching than a process) and shares its address
    space with other threads. A thread includes a
    program counter, a register set, and a stack.
  • Because of its shared address space, an error or
    attack from another thread can corrupt its
    memory. Thread stacks can be protected if they
    are kept in the system address space using
    separated segments or pages.
  • Most modern operating systems allow several
    threads to be bundled in one process this
    protects the thread group as a whole from other
    processes.
  • User processes and threads can be created with
    special packages, e.g., Posix in Unix, or through
    the language.
  • The operating system defines kernel threads as
    units of concurrent execution. For the reasons
    discussed above, kernel threads usually dont
    have much protection against each other.

110
Process interaction
ordersProcess
kernel
system calls
messages po(par)
Fulfilled Orders
shippingProcess
kernel mode
user mode
Pending Orders
Bills
Customers
Customer List
111
Process communication
  • Process communication also has an effect on
    security. Systems that use explicit message
    passing have the possibility of checking each
    message to see if it complies with system
    policies.
  • A security feature that can be applied when
    calling another process is protected entry
    points. A process calling another process can
    only enter this process at pre-designed entry
    points. This prevents bypassing entry checks
  • The number and size of arguments in a gate
    crossing can also be controlled (this may protect
    against some types of buffer overflow attacks)

112
Execution states or modes
  • At least two modes of operation are needed to
    have any security.
  • Most hardware architectures use a supervisor and
    a user mode. In the user mode some instructions,
    called privileged instructions, cannot be
    executed directly. In supervisor mode all the
    instructions can be executed.
  • The state of a process is kept in a Program
    Status Word.

113
(No Transcript)
114
Protection rings
  • Some architectures define in their hardware a set
    of rings (4 to 32) that correspond to domains of
    execution with hierarchical levels of trust.
    Rings are a generalization of the concept of mode
    of operation.
  • Crossing of rings is done through gates that
    check the rights of the crossing process. A
    process calling a segment in a higher ring must
    go through a gate.

115
(No Transcript)
116
Protected Entry Point pattern
117
Patterns for OSs
118
Android architecture
Extended Application


Applications
Reference Monitor
Component Framework
Middleware
JVM
Policy Set
Linux OS
119
Symbian
  • Symbian Os is a hard RTOS
  • Symbian OS is an open system and is based on a
    micro kernel architecture which implements full
    multitasking and multithreading
  • The micro kernel uses client/server session based
    IPC in which servers mediate access to shared
    resources and services, and the kernel deals with
    memory allocations and IPCs
  • System services such as telephony, networking
    middleware and application engines all run in
    their own processes
  • Symbian OS v9.1 provides a proactive defense
    mechanism against malware. The platform security
    infrastructure uses a capability-based model,
    which ensures that sensitive operations (for
    example modifying user data, making calls, using
    network connections) can only be accessed by
    applications, which have been certified by an
    appropriate signing authority
  • Data caging is a new feature provided by the
    Symbian OS v9, which allows applications to have
    their own private data partition. This allows for
    applications to guarantee a secure data store.
    This can be used for e-commerce, location
    applications and others.

120
Symbian layered microkernel
121
Patterns for secure process management
Secure Process
lightweight execution
create Objects
creation
Secure Thread
Controlled Object Factory
Controlled Process Creator
enforce Rights
Controlled Object Monitor
Reference Monitor
define Rights
check Rights
define Rights
Authorizer
122
Secure Process/Thread
  • How do we make sure that a process does not
    interfere with other processes or misuse shared
    resources?
  • A process is a program in execution, a secure
    process is also a unit of execution isolation as
    well as a holder of rights to access resources.
  • A secure process has a separate virtual address
    space and a set of rights to access resources.
  • A thread is a lightweight process. A variant,
    called secure thread is a thread with controlled
    access to resources.

123
Secure process
124
Controlled address space
  • Also called Execution domain or sandbox
  • Access is controlled through descriptors or
    capabilities
  • As a process executes it creates one or more
    Domains. Domains can be recursively composed
  • The descriptors used in the process domains are
    a subset of the Authorizations that the Subject
    has for some Protection Objects (defined by an
    instance of the Authorization pattern of Chapter
    3).
  • ProtectionObject is a superclass of the abstract
    Resource class and ConcreteResource defines a
    specific resource.
  • Process requests go through a ReferenceMonitor
    that can check the domain descriptors for
    compliance.
  • Used in Java, in Haiku, and others

125
The Controlled Execution Environment pattern 
  • Intent To control access to all operating system
    resources by processes, based on user, group, or
    role authorizations.
  • Context A process executes on behalf of a user
    or role (a subject). A process must have access
    rights to use these resources during execution.
    The set of access rights given to a process
    define its execution domain. Processes must be
    able to share resources in a controlled way. The
    rights of the process are derived from the rights
    of its invoker.

126
Process/domain rights
127
(No Transcript)
128
Secure Boot
129
Firefox OS
130
Patterns in Firefox OS
  • Layers
  • Controlled VAS (sandbox)
  • Digital Signature
  • Controlled Process Creator
  • Multilevel Access Control
  • Authorizer (ACL)
  • Whitelisting
  • Credential

131
Tizen OS
132
Patterns in Tizen OS
  • Layers
  • Controlled VAS (Sandbox)
  • Multilevel Access Control (Mandatory)
  • Digital Signature

133
Forces of VM OS
  • Each operating system needs to have access to a
    complete set of hardware features to support its
    execution.
  • Each OS has its own set of machine dependent
    features, e.g., interrupt handlers. In other
    words, each operating system uses the hardware in
    different ways.
  • When an OS crashes or it is penetrated by a
    hacker, the effects of this situation should not
    propagate to other OSs in the same hardware.
  • There should be no way for a malicious user in a
    VM to get access to the data or functions of
    another VM.

134
VM execution
135
VM operating system
136
UC Execute a system call
137
Known uses
  • IBM VM/370 Cre81. This was the first VMOS, it
    provided VMs for an IBM370 mainframe.
  • VMware Nie00. This is a current system that
    provides VMs for Intel x86 hardware.
  • Solaris10 Sun04 calls the VMs containers and
    one or more applications execute in each
    container.
  • Connectix Con produces virtual PCs to run
    Windows and other operating systems.
  • Xen is a VMM for the Intel x86 developed as a
    project at the University of Cambridge, UK
    Bar00. Used by VMWare and others

138
Advantages
  • The VMM intercepts and checks all system calls.
    The VMM is in effect a Reference Monitor and
    provides total mediation on the use of the
    hardware. This can provide a strong and secure
    isolation between virtual machines.
  • Each environment (VM) does not know about the
    other VM(s), this helps prevent cross-VM attacks
  • There is a well-defined interface between the VMM
    and the virtual machines.
  • The VMM is small and simple and can be checked
    for security and correctness.

139
Liabilities
  • All the VMs are treated equally. If one needs
    different categories of VMs it is necessary to
    build specialized versions
  • Extra overhead in use of privileged instructions.
  • It is rather complex to let VMs communicate with
    each other (if this is needed).
  • Security attacks are possible (to be seen)
    because of implementation additions

140
Microkernels
141
The Microkernel pattern (www.vico.org)
  • "The Microkernel architectural pattern applies to
    software systems that must be able to adapt to
    changing system requirements. It separates a
    minimal functional core from extended
    functionality and customer-specific parts. The
    microkernel also serves as a socket for plugging
    in these extensions and coordinating their
    collaboration." (Buschmann, F., R. Meunier, H.
    Rohnert, P. Sommerlad, and M. Stal.
    Pattern-Oriented Software Architecture A System
    Of Patterns. West Sussex, England John Wiley
    Sons Ltd., 1996)
  • The microkernel includes functionality that
    enables other components running in separate
    processes to communicate with each other. It is
    also responsible for maintaining system-wide
    resources such as files or processes. In
    addition, it provides interfaces that enable
    other components to access its functionality.
  • It uses an Adapter pattern to let clients
    interface with its functions

142
Microkernel
10/15/2016
142
143
Reducing kernel mode execution
  • If only a few critical functions run in kernel
    mode security and reliability improve
  • Hypervisors and microvisors run in kernel mode
    but all other programs run in user mode
  • Applies principle of Least privilege and also
    improves performance
  • Can act as a Reference Monitor

144
(No Transcript)
145
The network layers
  • Firewalls
  • Intrusion Detection Systems
  • Network layer defenses

146
Internet layers
  • Layer 7 (HTTP),
  • Layer 4 (TCP, Transmission Control Protocol),
  • Layer 3 (IP, Internet Protocol),
  • Layer 1.
  • At the higher levels, the sub-protocols used are
    TCP (a connection-oriented protocol), and UDP
    (User Datagram Protocol)

147
(No Transcript)
148
Patterns for firewalls
  • Packet Filter Firewall. Filter incoming and
    outgoing network traffic in a computer system
    based on network addresses.
  • Application/Proxy Firewall . Inspect (and filter)
    incoming and outgoing network traffic based on
    the type of application they are accessing.
  • Stateful firewall Filter incoming and outgoing
    network traffic in a computer system based on
    network addresses and the state information
    derived from past communications.

149
Firewall patterns
150
Application layer (proxy) firewall
  • Uses security proxies to represent services
  • A variety of the Proxy pattern
  • Prevents direct access
  • Analyzes application commands
  • Keeps logs for later auditing

151
(No Transcript)
152
(No Transcript)
153
In summary
  • Firewalls are examples of the Reference Monitor
    pattern applying a simple Access Matrix model
  • Packet filter and proxy firewalls complement each
    other
  • Can be further complemented with intrusion
    detection

154
Application firewall
  • Controls input/output from distributed
    applications
  • Enforces access control according to application
    restrictions, can understand application
    semantics
  • Can also filter wrong operations, wrong type or
    length parameters, wrong sequences of operations

155
(No Transcript)
156
XML firewall
  • Controls input/output of XML applications
  • Well-formed documents (schema as reference)
  • Harmful data (wrong type or length)
  • Encryption/decryption
  • Signed documents

157
(No Transcript)
158
(No Transcript)
159
(No Transcript)
160
TLS (SSL) protocol pattern
161
UC Request service
162
(No Transcript)
163
Patterns for web services and cloud computing
  • Approaches
  • Authentication
  • Distribution
  • Identity
  • Web services
  • Cloud Computing

164
Authentication patterns
  • Remote Authenticator /Authorizer. Provide
    facilities for authentication and authorization
    when accessing shared resources in a
    loosely-coupled distributed system.
  • Credential. Provide portable means of recording
    authentication and authorization information for
    use in distributed systems

165
Web services security
  • Application Firewall Del04. The application
    firewall filters calls and responses to/from
    enterprise applications, based on an institution
    access control policies.
  • XML Firewall Del04. Filter XML messages to/from
    enterprise applications, based on business access
    control policies and the content of the message.
  • XACML Authorization Del05. Enable an
    organization to represent authorization rules in
    a standard manner.
  • XACML Access Control Evaluation Del05. This
    pattern decides if a request is authorized to
    access a resource according to policies defined
    by the XACML Authorization pattern. .
  • WSPL Del05. Enable an organization to represent
    access control policies for its web services in a
    standard manner. It also enables a web services
    consumer to express its requirements in a
    standard manner.

166
Use of web services
167
Standards for web services security
168
(No Transcript)
169
XACML
  • Special technical committee of OASIS
  • Specification of policies for information access
    over the Internet and their enforcement
  • Combines work of IBM Tokyo and University of
    Milano, Italy.
  • Implemented by Sun in early 2003

170
(No Transcript)
171
Reified Reference Monitor
172
RRM
  • In the RRM the decision, instead of being yes
    or no, is a class to which we can apply
    operations (reification)
  • There is zero or one decision per request
  • Information about the context or any other
    information can be used to produce the decision

173
(No Transcript)
174
Abstraction in the use of patterns
  • We can see the Composite and Authorization
    patterns in XACML Authorization
  • We can see the Reference Monitor in XACML
    Evaluation
  • Abstraction helps model understanding

175
Use of encryption in the architecture
176
XML Encryption
  • The XML Encryption standard describes the syntax
    to represent XML encrypted data and the process
    of encryption and decryption. XML Encryption
    provides confidentiality by hiding selected
    sensitive information in a message using
    cryptography.

177
(No Transcript)
178
Encrypting elements
179
. Secure Shell (SSH) 
  • Intent
  • Provide an authenticated environment where users
    may utilize programs and securely exchange
    information with remote locations. This
    environment provides confidentiality via
    symmetric encryption, authentication via public
    key encryption, and non-repudiation via digital
    signatures.
  • Solution
  • First, the use of an Internet Key Exchange (IKE)
    mechanism Kau05 is employed in order to set up
    a shared private key. In this mechanism, each
    system first calculates half of a shared key
    using an exchange algorithm. The two systems
    then exchange their half of the key with the
    other system. Finally, each system runs the
    algorithm on the received portion of the key.
    The result for both systems is a matching value
    that is then used in a later mechanism.
  •  

180
(No Transcript)
181
The design of secure systems
  • We not only have to satisfy functional specs but
    nonfunctional specs.
  • Security is a nonfunctional aspect
  • We cannot show absence of security flaws
  • We must use good development methods and hope for
    the best
  • Add-on security is not very secure

182
Use patterns at all levels
  • Patterns for models define the highest level
  • At each lower level we refine the model patterns
    to consider the specific aspects of each level
  • Patterns for file systems, web documents,
    cryptography, distributed objects, J2EE components

183
How to apply the patterns?
  • A good catalog and classifications of patterns
    help a designer select among alternatives.
  • However, there is still the problem of when to
    apply a pattern during system development
  • We need some systematic approach to decide when
    we need to use a pattern, a secure systems
    methodology

184
Security principles for application design
  • Security constraints must be defined at the
    highest layer, where their semantics are clear,
    and propagated to the lower levels, which enforce
    them.
  • All the layers of the architecture must be
    secure.
  • We can define patterns at all levels. This allows
    a designer to make sure that all levels are
    secured, and also makes easier propagating down
    the high-level constraints.
  • We must apply security at all development stages
    (tactic-based approaches start from design)

185
A methodology for building secure architectures
  • Stages
  • Financial institution example

186
Security along the life cycle
187
A methodology for secure systems design I
  • Domain analysis stage A business model is
    defined. Legacy systems are identified and their
    security implications analyzed. Domain and
    regulatory constraints are identified. Policies
    must be defined up front, in this phase.
  • Requirements stage Use cases define the required
    interactions with the system. Applying the
    principle that security must start from the
    highest levels, it makes sense to relate attacks
    to use cases. We study each action within a use
    case and see which threats are possible. We then
    determine which policies would stop these
    attacks. From the use cases we can also determine
    the needed rights for each actor and thus apply a
    need-to-know policy. 

188
Requirements stage
  • Use cases are determined
  • Activity diagrams for use cases or sequences of
    use cases
  • Define level of security needed
  • Identify attacks
  • Select attacks based on risk analysis

189
Identifying attacks
  • We need to know what kind of attacks to expect.
  • We relate attacks to attacker goals
  • We study systematically all the possible attacks
    to each activity in a use case
  • Use cases define all functional interactions

190
Attacker goals
  • Attacker is not interested in changing a few bits
    or destroying a message
  • Attacker wants to accomplish some objective,
    e.g., steal money, steal identity
  • This is applying the principle of defining
    security at the semantic levels
  • We also need to comply with standards

191
Example Applying security policies to stop
threats
  • Consider a financial company that provides
    investment services to its customers. Customers
    can open and close accounts in person or through
    the Internet. Customers who hold accounts can
    send orders to the company for buying or selling
    commodities (stocks, bonds, real estate, art,
    etc.). Each customer account is in the charge of
    a custodian (a broker), who carries out the
    orders of the customers. Customers send orders to
    their brokers by email or by phone. A government
    auditor visits periodically to check for
    application of laws and regulations.

192
A financial institution
193
From threats to policies
  • A systematic way to identify system threats, and
    determining policies to stop and/or mitigate
    their effects
  • Analysis of the flow of events in a use case or a
    group of use cases, in which each activity is
    analyzed to uncover related threats. This
    analysis should be performed for all the system
    uses cases
  • Then we select appropriate security policies
    which can stop and/or mitigate the identified
    threats.

194
(No Transcript)
195
(No Transcript)
196
Threats
  • T1.The customer is an impostor and opens an
    account in the name of another person
  • T2.The customer provides false information and
    opens an spurious account
  • T3.The manager is an impostor and collects data
    illegally
  • T4.The manager collects customer information to
    use illegally
  • T5.The manager creates a spurious account with
    the customers information
  • T6.The manager creates a spurious authorization
    card to access the account
  • T7.An attacker tries to prevent the customers to
    access their accounts
  • T8.An attacker tries to move money from an
    account to her own account

197
Misuses for this use case
  • Use Cases 1 and 2 Customer is an impostor.
    Possible confidentiality and integrity
    violations.
  • Manager impersonation. Can capture customer
    information. Confidentiality attack.
  • Use Cases 3 and 4. Broker impersonation. Possible
    confidentiality violation.
  • Customer can deny giving a trade order.
    Repudiation. Customer impersonation.
    Confidentiality or integrity attacks.
  • Stockbroker embezzling customers money.
  • Use Case 5. Impersonation of auditor.
    Confidentiality violation.

198
Use case analy
About PowerShow.com