Software engineering for security a roadmap
1 / 13

Software Engineering for Security: a Roadmap - PowerPoint PPT Presentation

  • Updated On :

Software Engineering for Security: a Roadmap. By: PremKumar T. Devanbu (UC Davis) Stuart Stubblebine (CertCo). Overview. Paper tries to highlight Interactions between SE and Security. Structured like waterfall approach Main points of focus include: Security Policy & Requirements

Related searches for Software Engineering for Security: a Roadmap

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Engineering for Security: a Roadmap' - thora

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Software engineering for security a roadmap

Software Engineering for Security: a Roadmap


PremKumar T. Devanbu (UC Davis)

Stuart Stubblebine (CertCo)


  • Paper tries to highlight Interactions between SE and Security.

  • Structured like waterfall approach

  • Main points of focus include:

    • Security Policy & Requirements

    • Re-engineering for security and related challenges

    • Software Piracy & Protection issues

    • Trusting Software Components

    • Verification of Systems

    • Secure Software Deployment

Requirements and policies
Requirements and Policies

  • Security, like beauty, is in the eye of beholder.

  • Policy = Requirements ?

  • Security Models and Policies

    • Mandatory Access Control (MAC)

    • Discretionary Access Control (DAC) e.g Capabilities in Amoeba

    • Multilevel Security model

  • Challenges:

    • Unifying Security with Systems Engineering

    • Unifying Security and system Models

      • Unified system and security policy design

      • Modularity, compactness and reuse in policy representation

      • Leverage of existing standards based tools

Re engineering for security
Re-engineering for security

  • Security is an afterthought

  • Challenges:

    • Legacy Security Mismatches

      • E.g. UNIX and CORBA ?

      • Wrappers and sandboxes

    • Separating the Security “Aspect”

      • AOP / Crosscutting concerns / Aspect Weavers

      • Component/Connectors

Software piracy and protection
Software Piracy and Protection

  • Adversary Economics

Cost of one item

Cost of first hack the copy protection

Cost of each item after hacked

Risks of getting caught(prosecution Prob.)

Possibly subjective cost of each item(fine)

Good things in life are for free

For rest, you pay a license fee !

Piracy approaches to protection contd
Piracy: Approaches to Protection(Contd..)

  • Hardware and Software Tokens

    • Dongle/Dynamic tokens ( raise Ch )

    • Problems: Code Patching

  • Dynamic Decryption of Code

    • Problems: Memory monitoring / nobody uses it

  • Watermarking – Stealth and Resilience

    • Static and Dynamic approaches

    • More successful in digital image and sound

  • Code Partitioning

    • ROM (address Instruction map)

    • Secure Server (Performance and Privacy)

    • Smart Cards (Space/Processor)

  • Challenge: Attacker Cost Model

Trusting software components
Trusting Software Components

  • Related to increasing use of COTS

  • Black box Approaches

  • Grey Box Approaches

    • Cryptographic Coverage Verification

      • Unbiased Coin Flip

    • Tamper Resistant Hardware

      • Proof Checker on a smart card

  • Challenge: More Grey box approaches

Verification of systems
Verification of Systems

  • Important due to increase in use of COTS

  • Formal methods:

    • Significant human labour  Expensive

    • Based in specs rather then implementation

    • Hence, “confidence subjected to fidelity and completeness of specs and their relation to final implementation”

    • Don’t guarantee complete elimination of defects

  • Challenge: Implementation-based verification methods

Secure software deployment
Secure Software Deployment

  • Post Deployment Configuration Management (PDCM)

  • Challenges:

    • Controlled Delegation

      • Multiple sites with varying levels of trust

      • User may rely upon PDCM admin to identify trusted sources

    • Privacy Protection

Secure computation
Secure Computation

  • Test Oracle required - Proof of Correctness of test results

  • Proof Checkers

  • Quorum’s for distributing trust – Performance Issues

  • Secure Data Structures

  • Proof carrying answers – either prove correct or prove violation

Strengths weaknesses

  • Strengths

    • Merges the two fields of SE and Security well by pointing various commons grounds and challenges

    • Brings to focus imp issue of security being after thought

  • Weaknesses

    • Inconsistent at times (Formal proofs and verification)

    • Some approaches suggested not practical (Smart cards)

    • All sections not very clear (Secure Computing)

Relevance to embedded systems
Relevance to Embedded Systems

  • Security always a general concern.

  • Afterthought may not be possible in Embedded systems

  • Talks of Smart Cards / Temper resistant hardware as solution to many problems

  • Formal Verification methods are imp for safety critical embedded software