Industrial case study: Zero defect secure software for the National Security Agency



Similar documents
Rigorous Methods for Software Engineering (F21RS1) High Integrity Software Development

Introducing Formal Methods. Software Engineering and Formal Methods

Procedure for Assessment of System and Software

Software Engineering Reference Framework

SoMA. Automated testing system of camera algorithms. Sofica Ltd

CSE4213 Lecture Notes

Correctness by Construction: Developing a Commercial Secure System

Software Processes. Coherent sets of activities for specifying, designing, implementing and testing software systems

Sofware Requirements Engineeing

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

Introducing the Dezyne Modelling Language

Software Development Kit

Card Management System Integration Made Easy: Tools for Enrollment and Management of Certificates. September 2006

How To Develop Software

Sample Exam Syllabus

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

Lecture 3 Software Development Processes

Requirements-Based Testing: Encourage Collaboration Through Traceability

Roadmap. Software Engineering. Software Engineering. Project Life Cycle. Database. Project Lifecycle

FROM SAFETY TO SECURITY SOFTWARE ASSESSMENTS AND GUARANTEES FLORENT KIRCHNER (LIST)

SW: from Craftsmanship to Industry. The role of code generation in the industrialisation of software development

The Convergence of IT Security and Physical Access Control

Die wichtigsten Use Cases für MISRA, HIS, SQO, IEC, ISO und Co. - Warum Polyspace DIE Embedded Code-Verifikationslösung ist.

This interpretation of the revised Annex

ABB Automation Days, Madrid, May 25 th and 26 th, Patrik Boo What do you need to know about cyber security?

(Refer Slide Time: 01:52)

The SPES Methodology Modeling- and Analysis Techniques

Methodology: Agile development of safety critical systems Annex D1.1.d to deliverable D1.1

White paper December IBM Tivoli Access Manager for Enterprise Single Sign-On: An overview

An Introduction to the ECSS Software Standards

Requirements Engineering: A Roadmap

Re-Design an Operational Database Author: Sovan Sinha (Business Intelligence Architect) May 4 th, 2009

Automatic vs. Manual Code Analysis

Software testing. Objectives

Biometrics, Tokens, & Public Key Certificates

Formal Software Testing. Terri Grenda, CSTE IV&V Testing Solutions, LLC

Static Analysis of Dynamic Properties - Automatic Program Verification to Prove the Absence of Dynamic Runtime Errors

Standard for Software Component Testing

Agile Model-Based Systems Engineering (ambse)

Trends in Embedded Software Development in Europe. Dr. Dirk Muthig

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Vetting Smart Instruments for the Nuclear Industry

OpenSSO: Simplify Your Single-Sign-On Needs. Sang Shin Java Technology Architect Sun Microsystems, inc. javapassion.com

Continuous???? Copyright 2015 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Seven Practical Steps to Delivering More Secure Software. January 2011

Web Applications Access Control Single Sign On

Effective Software Verification for Medical Devices

An Oracle White Paper December Leveraging Oracle Enterprise Single Sign-On Suite Plus to Achieve HIPAA Compliance

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change?

Smart Card- An Alternative to Password Authentication By Ahmad Ismadi Yazid B. Sukaimi

TLSA Consultancy Training elearning

CA SiteMinder SSO Agents for ERP Systems

Examination SUBJECT. Version:

WebSphere Business Monitor

Writers: Joanne Hodgins, Omri Bahat, Morgan Oslake, and Matt Hollingsworth

Project Audit & Review Checklist. The following provides a detailed checklist to assist the PPO with reviewing the health of a project:

Analysis and Implementation of Workflowbased Supply Chain Management System

SCADA Compliance Tools For NERC-CIP. The Right Tools for Bringing Your Organization in Line with the Latest Standards

Requirements engineering

Data Analysis 1. SET08104 Database Systems. Napier University

Difference Between Model-Driven and Traditional Iterative Software Development

WHITE PAPER. Let s do BI (Biometric Identification)

Fundamentals of Measurements

Specification and Analysis of Contracts Lecture 1 Introduction

SAMAY - Attendance, Access control and Payroll Software

Keywords: SQA,Black Box Testing( BBT), White Box testing(wbt).

Use service virtualization to remove testing bottlenecks

Testing in a Mobile World

White Paper On Pilot Method Of ERP Implementation

Business Operations. Module Db. Capita s Combined Offer for Business & Enforcement Operations delivers many overarching benefits for TfL:

Software Test Plan (STP) Template

DO-178B compliance: turn an overhead expense into a competitive advantage

Level 2 Process: Customer Management Version 2

2. Each server or domain controller requires its own server certificate, DoD Root Certificates and enterprise validator installed.

SERVICE DEFINITION G-CLOUD 7 SECURE FILE TRANSFER DIODE. Classification: Open

Health Insurance Portability and Accountability Act Enterprise Compliance Auditing & Reporting ECAR for HIPAA Technical Product Overview Whitepaper

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.

AP1000 European 18. Human Factors Engineering Design Control Document

-.% . /(.0/ ) 53%/( (01 (%((. * 7071 (%%2 $,( . 8 / 9!0/!1 . # (3(0 31.%::((. ;.!0.!1 %2% . ".(0.1 $) (%+"",(%$.(6

Information Technology Security Evaluation Criteria. ITSEC Joint Interpretation Library (ITSEC JIL)

DigitalPersona Pro Enterprise

Oracle Insurance Policy Administration System Quality Assurance Testing Methodology. An Oracle White Paper August 2008

Performance Testing Uncovered

Secure Software Architecture Description using UML Jan Jürjens Competence Center for IT Security Software & Systems Engineering TU Munich, Germany

Software Testing. Knowledge Base. Rajat Kumar Bal. Introduction

French Justice Portal. Authentication methods and technologies. Page n 1

The Performance Management Process How to establish goals, objectives and KPI s

FIRST IMPRESSION EXPERIMENT REPORT (FIER)

Transcription:

p Industrial case study: Zero defect secure software for the National Security Agency Martin Croxford CEng MBCS Praxis High Integrity Systems Bath, UK Copyright Praxis High Integrity Systems Limited 2006 Slide 0

p Management summary EAL5+ viewed as too difficult, too expensive or both. But EAL5+ standard applications increasingly in demand. NSA evaluated CbyC to determine its effectiveness at EAL5+ NSA reported CbyC Produces code more quickly and reliably and at lower cost than traditional methods CbyC represents state of the art secure software engineering practice. CbyC can be learnt by competent engineers. Copyright Praxis High Integrity Systems Limited 2006 Slide 1

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 2

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 3

p The MULTOS CA System This project has provided further evidence for the benefits of formality, in terms of rigour and predictability - MXI Head of Security System to support smart card security Demanding requirements: Security: ITSEC Level E6 (EAL 7) Availability: 6 months non-stop (24x7) COTS h/w and s/w (eg NT) plus bespoke h/w and s/w Key metrics: 0.04 defects/ksloc; 28 SLOC/day; 1 year warranty Copyright Praxis High Integrity Systems Limited 2006 Slide 4

p Project Goals Demonstrate that Common Criteria requirements for EAL5 are achievable in a cost effective manner Show how the Praxis Correctness by Construction approach matches up to EAL5. Measure productivity and defect rates under controlled conditions. Copyright Praxis High Integrity Systems Limited 2006 Slide 5

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 6

p Tokeneer Identification Station Background Tokeneer originally developed by NSA Demonstrates use of smart cards and biometrics for access control ID Station One component of Tokeneer Provides user authentication Copyright Praxis High Integrity Systems Limited 2006 Slide 7

p What is TOKENEER? Attribute Authority (AA) Protected Enclave Workstation Admin Token Reader Alarm Certificate Authority (CA) Enrolment Station Workstation Workstation ID Station (TIS) Portal Fingerprint Reader Display Token Reader Provides protection to secure information held on a network of workstations situated in a physically secure enclave. Demonstrates use of Smart Cards and Biometrics Copyright Praxis High Integrity Systems Limited 2006 Slide 8

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 9

p What is Correctness by Construction? A process, techniques and tools for developing high-integrity software Has been applied by Praxis and its customers for fifteen years, on projects in aerospace, defence, transportation, telecomms and finance Philosophy: make it difficult to introduce defects And: eliminate defects as early as possible Possible ONLY by introducing precision and logical reasoning about each step in the development of the software Demonstrate correctness through the way it is produced not JUST on observing operational behaviour (or test results) Avoids the code/test/debug bottleneck Consistent with SW01, ESARR 6, (00-55), (DO-178C), Common Criteria EAL5+ Copyright Praxis High Integrity Systems Limited 2006 Slide 10

p The seven principles of CbyC Write right (use sound, formal notations) Step, don t leap (small semantic steps) Say something once, why say it again? (avoid repetition) Check here before going there (verify early) Argue your corner (document justifications) Screws: use a screwdriver, not a hammer (use the tool appropriate for the job) Brains R Us (don t turn the handle) Generate evidence as you go Copyright Praxis High Integrity Systems Limited 2006 Slide 11

p Summary of key aspects of Correctness by Construction Industrial strength requirements engineering (REVEAL) Understand underlying business objectives Understand domain: environment/context Explicitly address conflict and change Cost-effective, pragmatic application of mathematical methods Eg completeness of specification, proof of absence of deadlock in design Emphasis on static analysis Both tool-supported (SPARK) and manual Eg proof of absence of run-time errors High Level Design Test Spec Requirements Software Spec Detailed Designs Module Spec Code Software Build Copyright Praxis High Integrity Systems Limited 2006 Slide 12

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 13

p TIS Development Process Copyright Praxis High Integrity Systems Limited 2006 Slide 14

p 1. Requirements Analysis Praxis REVEAL Process Identify system boundaries Clarify dependencies on the environment Key scenarios identified Copyright Praxis High Integrity Systems Limited 2006 Slide 15

p 2. Security Analysis Security Target and Security Policy Model using Protection Profile Identify key properties to ensure security Specify security properties using Z Copyright Praxis High Integrity Systems Limited 2006 Slide 16

p 3. Specification Abstract Model of System using Z Notation Defines and documents functional requirements includes interfaces and observable behaviour excludes internal detail (such as what was audited and format of certificates) Assurance Customer feedback validation that specification meets security properties rigorous checks on initial state and operation preconditions Copyright Praxis High Integrity Systems Limited 2006 Slide 17

p 4. Design (Formal) Concrete Model of System using Z Notation Refinement of Formal Specification Introduces internal detail Concrete model of certificates and audit log Resolved all non-determinism in Spec Assurance Sample of Refinement proofs (inc. audit log) Copyright Praxis High Integrity Systems Limited 2006 Slide 18

p 4. Design (INFORMED) Defines structure of implementation modules Identify and locate state, types and operations Relates Abstract SPARK state to Z state Relates SPARK types to Z types Relates SPARK Ops to Z operation Schemas Other Design issues Constraints not modelled in Z Detailed file formats Copyright Praxis High Integrity Systems Limited 2006 Slide 19

p 5. Implementation SPARK Ada for core Static analysis using SPARK Examiner Flow and proof annotations Data-Flow / Information-Flow Analysis Run-time Error checking done before code review Thin layer of Ada interfacing to support software Assurance Proof of some security properties 93% VCs discharged automatically Copyright Praxis High Integrity Systems Limited 2006 Slide 20

p 6. System Testing System Testing only Incremental builds with increasing functionality Tests derived from refined specification Specified as test scenarios with expected results (visual and audited events) Coverage analysis 100% statement coverage 100% branch coverage Static analysis removes need for expensive module testing Copyright Praxis High Integrity Systems Limited 2006 Slide 21

p Assurance process Security Properties Formal Specification Proof of Formal Specification (Z) Proof of Security Properties (Z) Formal Design Refinement Proof of Formal Design (Z) System Test Specification Proof of Security Properties (SPARK Proof) INFORMED Design Proof of Functional Properties (SPARK Proof) Key System Test SPARK Implementation Static Analysis Assurance Activity Copyright Praxis High Integrity Systems Limited 2006 Slide 22

p Development Statistics Ada Source Lines SPARK LOC/day coding LOC/day overall Core 9,939 16,564 203 38 Support 3,697 2,240 182 88 Total effort - 260 man days Team - 3 people part-time Total schedule - 9 months elapsed Copyright Praxis High Integrity Systems Limited 2006 Slide 23

p Independent Assessment Performed by SPRE Inc. Developed Reliability Requirements Automated test Environment simulated 1-year s activity. Analysis of Results Copyright Praxis High Integrity Systems Limited 2006 Slide 24

p Reliability Demonstration Chart (minor failures) Reliability objectives for TIS were met 2 minor failures in user documentation. No major or critical failures (i.e. zero defects) Copyright Praxis High Integrity Systems Limited 2006 Slide 25

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 26

p Customer s View Using Z Early step from English to Z is crucial part of process Customer must validate that this step has been achieved correctly Experience indicates that with good instruction a reading knowledge of Z can be acquired in a few days. Good explanatory English important Plan access to a Z expert Copyright Praxis High Integrity Systems Limited 2006 Slide 27

p Customer s View Other steps Review of later development output simplified by: small steps taken at each stage preservation of structure Required SPARK expertise Need a reading knowledge of SPARK Familiarity with SPARK tools to perform spot-checking of proofs. Copyright Praxis High Integrity Systems Limited 2006 Slide 28

p NSA on Correctness by Construction Produces code more quickly and reliably and at lower cost than traditional methods Reasonable learning curve Correctness by Construction is proven and practical Randolph Johnson, National Security Agency Copyright Praxis High Integrity Systems Limited 2006 Slide 29

p Agenda Project Goals Tokeneer Identification System What is Correctness by Construction? CbyC applied to TIS Feedback from NSA Conclusions Copyright Praxis High Integrity Systems Limited 2006 Slide 30

p National Cyber Security Partnership - Secure software task force report Formed in response to the White House National Strategy to Secure Cyberspace A primary cause of security problems is software with vulnerabilities caused by defects Practices leading to low-defect software are to be encouraged Only three effective practices identified: Praxis s Correctness by Construction Team Software Process Cleanroom www.cyberpartnership.org/sdlcfull.pdf Copyright Praxis High Integrity Systems Limited 2006 Slide 31

p Conclusions from NSA case study CbyC Produces high quality, low defect software Is cost effective Conforms to Common Criteria EAL5+ Can be learnt quickly and effectively EAL5 and above is achievable and cost effective using current best practice software engineering There is no longer any excuse for avoiding EAL5+ Copyright Praxis High Integrity Systems Limited 2006 Slide 32

p Praxis High Integrity Systems Limited 20 Manvers Street Bath BA1 1PX United Kingdom Martin Croxford CEng MBCS Business Manager Email: martin.croxford@praxis-his.com Cell: +44 (0) 7881 516750 Telephone: +44 (0) 1225 8237941 Facsimile: +44 (0) 1225 469006 Website: www.praxis-his.com Copyright Praxis High Integrity Systems Limited 2006 Slide 33