CSCE 727 Program Security - PowerPoint PPT Presentation

1 / 49
About This Presentation
Title:

CSCE 727 Program Security

Description:

The first is the written description of system behavior regarding a business ... It is highly suitable to use a spreadsheet for planning software development. ... – PowerPoint PPT presentation

Number of Views:39
Avg rating:3.0/5.0
Slides: 50
Provided by: far1
Category:
Tags: csce | first | is | name | of | program | security | spreadsheet | the | what

less

Transcript and Presenter's Notes

Title: CSCE 727 Program Security


1
CSCE 727 Program Security
2
Reading
  • Reading for this lecture
  • B. Littlewood, P. Popov, L. Strigini, "Modelling
    software design diversity - a review", ACM
    Computing Surveys, Vol. 33, No. 2, June 2001, pp.
    177-208, http//portal.acm.org/citation.cfm?doid3
    84192.384195
  • T. Loderrstedt et al. SecureUML A UML-Based
    Modeling Language for Model Driven Security,
    http//kisogawa.inf.ethz.ch/WebBIB/publications-so
    ftech/papers/2002/0_secuml_uml2002.pdf
  • Ian Alexander Initial Industrial Experience of
    Misuse Cases in Trade-Off Analysis,
    http//easyweb.easynet.co.uk/iany/consultancy/mis
    use_cases/misuse_cases_in_tradeoffs.htm
  • Ian Alexander Use Cases Use Cases with Hostile
    Intent, http//www.nku.edu/waldenj1/classes/2006/
    spring/csc593/papers/IEEE_Software_2003_MisuseCase
    s.pdf

3
Program Flaws
  • Taxonomy of flaws
  • how (genesis)
  • when (time)
  • where (location)
  • the flaw was introduced into the system

4
Security Flaws by Genesis
  • Genesis
  • Intentional
  • Malicious Trojan Horse, Trapdoor, Logic Bomb,
    Worms, Virus
  • Non-malicious
  • Inadvertent
  • Validation error
  • Domain error
  • Serialization error
  • Identification/authentication error
  • Other error

5
Flaws by time
  • Time of introduction
  • During development
  • Requirement/specification/design
  • Source code
  • Object code
  • During maintenance
  • During operation

6
Reliability
  • Common approach replicate
  • Cheaper than highly reliable components
  • Performance
  • Availability
  • Hardware Reliability
  • Faulty HW, wear out, etc.
  • Software Reliability
  • Errors/bugs, obsolete

7
Software Reliability
  • Design diversity
  • Assumption software programs built differently
    will fail differently
  • Reliability models estimate the probability of
    coincident failures in multiple versions
  • Need empirical data

8
Software Engineering
  • Software can be designed in different ways
  • Systematic software development
  • Software development life cycle
  • Requirements
  • Specifications
  • Design
  • Coding
  • Prototype
  • Testing

9
SW Development Errors
  • Design errors
  • Specification errors
  • Program logic

10
N-version Programming
  • Same specification but number of different
    versions
  • Many different types of diversity process,
    product, product failure behavior
  • Critical software applications when to accept?
  • Problem dependent failure
  • How to test independence?

11
Recovery Blocks
  • Force diversity starting from specification
  • E.g., different algorithms
  • Sequential execution of redundant versions
  • Limited real time application

12
  • Software Security

13
Consistent and Complete Access Control Policies
in Use Cases
  • Duminda Wijesekera
  • Center for Secure Information Systems
  • George Mason University, USA
  • Khaled Alghathbar
  • George Mason University, USA and
  • King Saud University, Riyadh,
  • Saudi Arabia

The following slides are used with the
permission of D. Wijesekera
14
Current situation
  • Most security requirements come to light only
    after functional requirements have been
    completed. Devanbu and Stubblebine

15
Why security is considered after functional
requirement?
  • Security is considered a non-functional
    requirements (NFRs) which describes how the
    software will do the requirement not what the
    software will do. Chung et al.
  • None functional requirements (NFR) are generally
    more difficult to express in a measurable way,
    making them more difficult to analyze. In
    particular, NFRs tend to be properties of system
    as a whole. Nuseibeh and Easterbrook.

16
What if non-functional requirements have been
ignored?
  • Low quality and inconsistent software.
  • Unsatisfied softwares stakeholders.
  • More time and cost to reengineer.

17
What cause the difficulties/obstacles when
considering security requirements?
  • Lack of unified modeling notations for security.
  • Lack of tools.
  • Lack of security expertise.

18
What are the advantages of considering security
earlier in the software development process?
  • Integrating security requirements with functional
    to reduce conflict.
  • Attention to quality in the early in the life
    cycle of a project leads to defect detection and
    avoidance Devanbu and Stubblebine

19
What is needed?
  • A unified language for representing security
    features such as access control policy in the
    early phases of the software development life
    cycle A.
  • Formally analysis and validate the requirements
    to make sure that the specification is consistent
    with requirements definition B.

A According to Devanbu et al., Chung et
al. B According to Nuseibeh et al. , Pfleeger
, Rushby
20
Alghathbar Wijesekera Work
  • Proposes several design artifacts that specify
    the details of access control policies formally
    and precisely in the requirement and analysis
    phases.
  • Extending the Use Case, with access control
    schemas and tables.
  • Methodology to resolve several issues such as
    consistency and completeness of access control
    specifications that are not totally resolved
    before.
  • Khaled Alghathbar and Duminda Wijesekera,
    Incorporating Access Control Policies in
    Requirements Engineering, in the Journal of
    Computer and Information Science (IJCIS). Vol. 5,
    no. 3, Mar. 2004.

21
Related Work
  • Fernandez and Hawkins proposed to extend use
    cases with rights. The extension is by means of a
    stereotype that states the access constraints.
  • Sendall and Strohmeier introduced the concept of
    operation schemas to describe the effect of
    system operation and its functionality.
  • Fernandez-Medina et al proposed an extension to
    the use case and Class models.
  • Brose et al extended UML to support the automatic
    generation of access control policies in order to
    configure a CORBA-based infrastructure.

22
Use Case
  • In UML, requirements are specified with use cases
    at the beginning of the life cycle. Use cases
    specify actors and their intended usage of the
    envisioned system.
  • A use case is a description of the possible
    sequences of interaction between the system under
    discussion and external actors, related to the
    goal of one particular actor. Cockburn.
  • Use cases are written in an informal natural
    language. Thus, different people may write
    varying degrees of details for the same use case.
  • Use case diagram visualizes actors and their
    relationships with scenarios.

23
Use Cases example
Discretionary Access Control (John,
purchase-order, read) (John, purchase-order,
write) (John, purchase-order, -sign) (Pete,
purchase-order, read) (Pete, purchase-order,
write) (Pete, purchase-order, sign). Assuming
that John is a clerk and Pete is a purchasing
officer
24
(No Transcript)
25
Syntax and Semantics
  • More than 20 predicates
  • rel-predicates
  • hie-predicates
  • con-predicates
  • Extension of FAF (ASL)
  • E.g.,
  • cando (Clerk , prepare order)
  • cando (Purchasing Officer , Place order)

26
Flow Control
Flowatt(Xa,Xatt,Xobj,Xobj,Xt, Xuc, Xop) There
is a simple flow of Xatt initiated by actor Xa
from object Xobj to object Xobj at time Xt in
use case Xuc using operation Xop e.g.,
Flowatt(Clerk, att1, Clerk, Obj1, 1, Prepare
order, read)?
27
Misuse Cases
  • Review of two articles by Ian Alexander
  • 1.Misuse Cases Use Cases with Hostile Intent
  • 2. Initial Industrial Experience of Misuse Cases
    in Trade-Off Analysis
  • Presenter Ani Starrenburg

28
Use Cases
29
Traditional Value of Use Cases
  • The first is the written description of system
    behavior regarding a business task or
    requirement. This description focuses on the
    value provided by the system to external entities
    such as human users or other systems.
  • The second is the position or context of the use
    case among other use cases. As an organizing
    mechanism, a set of consistent, coherent use
    cases promotes a useful picture of system
    behavior, a common understanding between the
    customer/owner/user and the development team.

30
Relating Use Cases
  • ltltincludesgtgt
  • ltltextendsgtgt
  • Generalization/Specialization

31
1. Use Case Relationships - ltltincludesgtgt
ltltincludesgtgt
Garnish
32
2. Use Case Relationships - ltltextendsgtgt (has
exception)
ltltextendsgtgt
Describe Specials
33
3. Use Case Relationships Generalization/Special
ization
Serve Children
34
Use Case Narrative
  • Brief A brief use case consists of a few
    sentences summarizing the use case. It is highly
    suitable to use a spreadsheet for planning
    software development. A brief use case can be
    easily inserted in a spreadsheet cell, and allows
    the other columns in the spreadsheet to record
    business priority, technical complexity, release
    number, etc .
  • Casual A casual use case consists of a few
    paragraphs of text, covering the items mentioned
    above, elaborating the use case in the form of a
    summary or story.
  • Detailed A detailed or complex use case is a
    formal document based on a long template with
    fields for various sections and it is the most
    common understanding of the meaning of a use
    case.

35
Detailed Use Case Narrative
  • Typical sections are
  • Use Case Name
  • Iteration
  • Summary
  • Preconditions
  • Triggers
  • Basic course of events
  • Alternative paths
  • Postconditions
  • Business rules
  • Notes
  • Author and date

36
Extra-functional Requirements
  • It is common practice to create supplementary
    specifications to capture requirement details
    that lie outside the scope of use case
    descriptions. Examples of these topics include
    safety, security, performance, usability,
    scale/management issues, or standards compliance.

37
Why Misuse Cases?
  • There is a need to address security
    (extra-functional requirements) early in the
    development cycle.
  • Traditional methods for security engineering are
    heavyweight and hard for stakeholders to
    understand.
  • Stakeholders grasp use case diagrams and
    narrative.
  • Use cases can be used to express extra-functional
    requirements as well as functional requirements.
  • Misuse Cases help elicit extra-functional
    requirements.
  • Use/Misuse Case diagrams can concisely show the
    relationships among functional and
    extra-functional requirements (use cases) and
    misuse cases

38
Misuse Case Terms
  • Misuse (Abuse) Case A series of actions which
    negatively impacts the performance of the system
    or parts of the system.
  • Misuser The actor who initiates a misuse case.
    Initiation of misuse can be accidental or
    intentional.
  • Security Use Case A use case which palliates a
    misuse case in some way (protect pin code).

39
Detailed Misuse Case Narrative
  • Typical sections are
  • Use Case Name
  • Iteration
  • Summary
  • Preconditions
  • Triggers
  • Basic course of events
  • Alternative paths
  • Postconditions
  • Mitigation Points
  • Notes
  • Author and date

40
Misuse Case Example 1 - Security
41
Misuse Case Example 1
  • Example 1 shows that threat and mitigation can
    form a balanced zigzag pattern of play and
    counter play (Chess or Go).
  • New relationships defined
  • Threatens Misuse Case A aggravates Misuse Case
    B if achieving the goal of A reduces the systems
    ability to achieve the goal of B.
  • Mitigates Use Case A mitigates Misuse Case B
    if it reduces Bs effect on the Use Cases it
    threatens.

42
Misuse Case Example 2 - Safety
43
Misuse Case Example 3 - Usability
D
Drive the hybrid
Threatens
Allow hybrid to sit idle
Extends
Mitigates
Inform Driver
44
Other Reasons to Depict Misuse Cases
  • Eliciting Exceptions - Misuse cases are one way
    to hunt down possible exceptions.
  • Eliciting Test Cases Any scenario can lead to
    a test case. Good testing goes beyond happy-day
    scenarios to explore boundary conditions and
    exceptionsThe habit of thinking out negative
    scenarios is arguably an essential skill for the
    test engineer.
  • Analyzing Trade-offs (It) is a systematic
    examination of each proposed requirement and/or
    design approach for a system. This analysis is
    recursively performed.

45
Misuse Case Example 4 Trade Off Analysis
46
Misuse Case Example 4
  • An important element of system design is to
    satisfy conflicting user demands. The situation
    is complicated by the fact that each choice opens
    up new possibilities for use and misuse.
    Designers must therefore trade off one option
    against another.
  • New relationships defined
  • Aggravates Use or Misuse Case A aggravates
    Misuse Case B if it increases the probability of
    success or the seriousness of the damage that B
    threatens.
  • Conflicts with Use Case A conflicts with Use
    Case B if achieving As goal makes achieving Bs
    goal more difficult (or impossible). This also
    holds true for Bs effect on A.

47
Misuse Case Example 5 Industrial Experience in
Trade Off Analysis
48
Misuse Case Example 5
  • Combined domain knowledge of stakeholders is
    critical for successful trade-off analysis.
  • Misuse case diagrams are only a part of an
    integrated approach. Participative workshop
    methods such as integrated inquiry cycle methods,
    cooperative inquiry, or Scenic were recommended
    by the author.
  • Tool support is also important. Author suggests
    Scenario Plus.

49
Sources
  • Ian Alexanders web site (with complete
    bibliography of papers written)
    http//easyweb.easynet.co.uk/iany/consultancy/pap
    ers.htm
  • Wikipedia web site use cases and mis-use
    cases
Write a Comment
User Comments (0)
About PowerShow.com