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