Software component evaluation A developer’s perspective Sony Corporation’s presentation for the 6 th International Common Criteria Conference.

Slides:



Advertisements
Similar presentations
Testing Relational Database
Advertisements

Presentation by Prabhjot Singh
Chapter 2 – Software Processes
CS 411W - Notes Product Development Documentation.
GCSE PROJECT GUIDELINES Use this presentation to make sure you have the correct content for you project - click on.
Policies vs Threats by Albert Dorofeev, Sony Corporation 10 th International Common Criteria Conference, 2009.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Chapter 10 – Digital System Projects Using HDL Copyright © 2011, 2007, 2004, 2001, 1998 by Pearson Education, Inc. Upper Saddle River, New Jersey
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
Structured Programming structured programming: A technique for organizing and coding computer programs in which a hierarchy of modules is used, each having.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
Design, Implementation and Maintenance
Introduction to Computer Technology
DCT 1123 PROBLEM SOLVING & ALGORITHMS INTRODUCTION TO PROGRAMMING.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
2 1 Chapter 2 Data Model Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
PROGRAMMING LANGUAGES The Study of Programming Languages.
Chapter 7 Software Engineering Objectives Understand the software life cycle. Describe the development process models.. Understand the concept of modularity.
Database System Development Lifecycle © Pearson Education Limited 1995, 2005.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Managing Software Quality
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Software Testing Life Cycle
ITEC 3220M Using and Designing Database Systems
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Chapter 3 Developing an algorithm. Objectives To introduce methods of analysing a problem and developing a solution To develop simple algorithms using.
CSE 219 Computer Science III Program Design Principles.
Database System Development Lifecycle 1.  Main components of the Infn System  What is Database System Development Life Cycle (DSDLC)  Phases of the.
Software Metrics and Reliability. Definitions According to ANSI, “ Software Reliability is defined as the probability of failure – free software operation.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Chapter 1 Program design Objectives To describe the steps in the program development process To introduce the current program design methodology To introduce.
IT Essentials: PC Hardware and Software v4.0. Chapter 4 Objectives 4.1 Explain the purpose of preventive maintenance 4.2 Identify the steps of the troubleshooting.
Software component evaluation A developer’s perspective Sony Corporation’s presentation for the 6 th International Common Criteria Conference.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public ITE PC v4.0 Chapter 4 1 Chapter 4: Basics of Preventive Maintenance and Troubleshooting IT.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
The Software Development Process
PROGRAM DEVELOPMENT CYCLE. Problem Statement: Problem Statement help diagnose the situation so that your focus is on the problem, helpful tools at this.
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Software Requirements Specification Document (SRS)
1)History of water fall model. 2)Features of water fall model. 3)Phase of water fall model. 4)Brief description of phases. 5)Advantages. 6)Disadvantages.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
WATERFALL METHOD Robbie Campbell WHAT IS IT  Considered the classic approach to the SDLC.  It is a linear method with goals for each development phase.
Course: Software Engineering – Design I IntroductionSlide Number 1 What is a specification Description of a (computer) system, which:  is precise;  defines.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
PROGRAMMING FUNDAMENTALS INTRODUCTION TO PROGRAMMING. Computer Programming Concepts. Flowchart. Structured Programming Design. Implementation Documentation.
 Programming methodology: ◦ is a process of developing programs that involves strategically dividing important tasks into functions to be utilized by.
Algorithms and Problem Solving
SYSTEM ANALYSIS AND DESIGN
Systems Analysis and Design
Requirements Analysis and Specification
Decomposition.
INFORMATION SYSTEMS PLAN
CS310 Software Engineering Lecturer Dr.Doaa Sami
Algorithms and Problem Solving
DEPLOYING SECURITY CONFIGURATION
Presentation transcript:

Software component evaluation A developer’s perspective Sony Corporation’s presentation for the 6 th International Common Criteria Conference

ICCC PresentationCopyright © 2005 Sony Corporation2 Contents The discussion of disparity between the hardware and software evaluations The discussion of disparity between the hardware and software evaluations The discussion of the complexity of software and components The discussion of the complexity of software and components The discussion of the modularity of systems versus the modularity of software The discussion of the modularity of systems versus the modularity of software A preview of what is coming A preview of what is coming

ICCC PresentationCopyright © 2005 Sony Corporation3 Current state Lots of experience in evaluating hardware and hardware-based products Lots of experience in evaluating hardware and hardware-based products Even complex composite products are evaluated without much trouble Even complex composite products are evaluated without much trouble Software is far behind and seemingly cannot stand on its own Software is far behind and seemingly cannot stand on its own

ICCC PresentationCopyright © 2005 Sony Corporation4 What is so peculiar about software? Much higher complexity Much higher complexity Much easier to develop using logically separated components Much easier to develop using logically separated components Quick development of the functionality but long time to get the details right Quick development of the functionality but long time to get the details right Infinite stability Infinite stability

ICCC PresentationCopyright © 2005 Sony Corporation5 Components The purpose is to make components self-contained The purpose is to make components self-contained The functionality of a component is not affected by the functionality of other components The functionality of a component is not affected by the functionality of other components A component can be fully tested and relied on to keep the set functionality A component can be fully tested and relied on to keep the set functionality

ICCC PresentationCopyright © 2005 Sony Corporation6 Complexity Software is much easier to develop compared to hardware Software is much easier to develop compared to hardware Therefore we make very complex things in software Therefore we make very complex things in software The way we deal with the increasing complexity is to split the software into components The way we deal with the increasing complexity is to split the software into components Components, in turn, get increasingly complex Components, in turn, get increasingly complex

ICCC PresentationCopyright © 2005 Sony Corporation7 Development cycle There are different models for managing the complexity of development There are different models for managing the complexity of development In the end, there are always two phases: In the end, there are always two phases: –Development of the functionality –Getting the functionality exactly right The second stage may take longer The second stage may take longer A fully understood, tested and verified software can be easily reused A fully understood, tested and verified software can be easily reused

ICCC PresentationCopyright © 2005 Sony Corporation8 Software stability As opposed to the hardware, the software is not subject to wear and tear As opposed to the hardware, the software is not subject to wear and tear Software does not need the maintenance or protection required for the hardware Software does not need the maintenance or protection required for the hardware Software will keep performing the required function indefinitely Software will keep performing the required function indefinitely

ICCC PresentationCopyright © 2005 Sony Corporation9 What is the point? Software, once written, stays functional forever Software, once written, stays functional forever Software can be evaluated once and for all Software can be evaluated once and for all The total sum of software in a product is usually split into building blocks – components The total sum of software in a product is usually split into building blocks – components A product may be created by using infinitely stable, evaluated components A product may be created by using infinitely stable, evaluated components

ICCC PresentationCopyright © 2005 Sony Corporation10 Software evaluation interesting points Hardware is built from real-world matter while software is built of ideal mathematical objects with behaviour defined precisely with abstract rules Hardware is built from real-world matter while software is built of ideal mathematical objects with behaviour defined precisely with abstract rules Hardware can fail, software cannot Hardware can fail, software cannot

ICCC PresentationCopyright © 2005 Sony Corporation11 Dependencies Hardware can have dependencies that would be absurd for the software Hardware can have dependencies that would be absurd for the software The dependencies in the software are much easier to identify and analyze. The dependencies in the software are much easier to identify and analyze.

ICCC PresentationCopyright © 2005 Sony Corporation12 More interestingly Hardware does not know how it will be used, software knows exactly what it needs to do and how it will use the hardware. Hardware does not know how it will be used, software knows exactly what it needs to do and how it will use the hardware. Hardware is operated according to the plan that is the software. Hardware is operated according to the plan that is the software.

ICCC PresentationCopyright © 2005 Sony Corporation13 Software summary Software is the master plan of function Software is the master plan of function High level of complexity High level of complexity Precisely defined behaviour Precisely defined behaviour Infinite stability Infinite stability No possibility of failure No possibility of failure Dependencies are easy to define Dependencies are easy to define

ICCC PresentationCopyright © 2005 Sony Corporation14 What all this leads to? The software should be the basis of the evaluation The software should be the basis of the evaluation We are used to evaluating the hardware first and then seeing how it is used by the software We are used to evaluating the hardware first and then seeing how it is used by the software We should do the other way around We should do the other way around

ICCC PresentationCopyright © 2005 Sony Corporation15 Compare with the evaluation flow In a CC evaluation, we start from ST to see what has to be done and we proceed downwards to see how it is supported In a CC evaluation, we start from ST to see what has to be done and we proceed downwards to see how it is supported The current state is like starting from the code to see what it can do and proceeding upwards to check that ST does not break the security of the code The current state is like starting from the code to see what it can do and proceeding upwards to check that ST does not break the security of the code Let’s start from the logical beginning – the software that rules the functionality! Let’s start from the logical beginning – the software that rules the functionality!

ICCC PresentationCopyright © 2005 Sony Corporation16 System security Current approach is to evaluate “finished products” Current approach is to evaluate “finished products” Those products are later used as components to build secure systems Those products are later used as components to build secure systems Security of the system depends more on the overall security policy and system design than on the product security Security of the system depends more on the overall security policy and system design than on the product security Products specify how they should be used to remain secure even inside a system Products specify how they should be used to remain secure even inside a system Most of the time, systems are never evaluated Most of the time, systems are never evaluated

ICCC PresentationCopyright © 2005 Sony Corporation17 Product security Products consist of components Products consist of components At the system level, we can evaluate individual components At the system level, we can evaluate individual components At the product level, we may not evaluate individual components? At the product level, we may not evaluate individual components? There is an obvious disparity between the approaches to the security at different levels There is an obvious disparity between the approaches to the security at different levels Product security should be looked at from the point of view of a system and components that go into this system Product security should be looked at from the point of view of a system and components that go into this system

ICCC PresentationCopyright © 2005 Sony Corporation18 What is the problem then? Software requires some hardware to be able to run for testing. Software requires some hardware to be able to run for testing. Hardware introduces dependencies. Hardware introduces dependencies. Software is much more complex and big, it takes a lot of time to analyze. Software is much more complex and big, it takes a lot of time to analyze.

ICCC PresentationCopyright © 2005 Sony Corporation19 And what is the solution? The solution is to use the component evaluation. The solution is to use the component evaluation. The solution is two-fold: The solution is two-fold: –Make sure the components are self-contained for the most part and contain a clearly defined and stable functionality –Make sure the component describes clearly what it will expect from the environment and how the hardware will be used.

ICCC PresentationCopyright © 2005 Sony Corporation20 What do we need? An agreed way to provide the description of the software and hardware dependencies An agreed way to provide the description of the software and hardware dependencies –SFR –Developer documentation –… ? An agreed evaluation methodology An agreed evaluation methodology

ICCC PresentationCopyright © 2005 Sony Corporation21 Who is at the forefront? Certification body: CESG of UK Certification body: CESG of UK Evaluation labs: LogicaCMG and SiVenture Evaluation labs: LogicaCMG and SiVenture Developer: Sony Corporation Developer: Sony Corporation The “guinea pig” product: Sony FeliCa The “guinea pig” product: Sony FeliCa

Thank you for your attention and your time. Albert Dorofeev General Manager Sony Secure Communications Europe