Effective banking products CC evaluations. 8 th I.C.C.C. Rome, September 26th, 2007. CHIOCCA Martine Banking products Security Risk Manager.

Slides:



Advertisements
Similar presentations
A Systems Approach To Training
Advertisements

Quality assurance Kari Kuulasmaa 1 st EHES Training Seminar, February 2010, Rome.
Module 1 Evaluation Overview © Crown Copyright (2000)
© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite.
University of Tulsa - Center for Information Security Common Criteria Dawn Schulte Leigh Anne Winters.
Common Criteria Evaluation and Validation Scheme Syed Naqvi XtreemOS Training Day.
2009 – E. Félix Security DSL Toward model-based security engineering: developing a security analysis DSML Véronique Normand, Edith Félix, Thales Research.
Practical experience of CC3.1 applied on smartcard hardware Wouter Slegers
Computer Science CSC 474Dr. Peng Ning1 CSC 474 Information Systems Security Topic 5.2: Evaluation of Secure Information Systems.
The 7 Year Itch - Time To Commit Or Time To Move On? Shaun Lee Security Evaluations Manager, Global Product Security.
Ch 3: Unified Process CSCI 4320: Software Engineering.
Software Process Models
1 norshahnizakamalbashah CEM v3.1: Chapter 10 Security Target Evaluation.
The Common Criteria Cs5493(7493). CC: Background The need for independently evaluated IT security products and systems led to the TCSEC Rainbow series.
ITIL: Service Transition
1 Evaluating Systems CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute May 6, 2004.
POS/ATM Protection Profile for a Common European Banking Industry Approval Scheme Common Approval Scheme POI Working Group SRC Security Research & Consulting.
© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 2 Software Processes.
CS 501: Software Engineering
Business Plug-In B2 Business Process.
“Consorzio RES and IT Security Certifications” 1/22.
SOFTWARE QUALITY ASSURANCE Maltepe University Faculty of Engineering SE 410.
LEARN. NETWORK. DISCOVER. | #QADexplore Implementing Business Process Management: Steps to Success WCUG – November 18, 2014.
Mantova 18/10/2002 "A Roadmap to New Product Development" Supporting Innovation Through The NPD Process and the Creation of Spin-off Companies.
Smartcard Evaluation TM8104 – IT Security Evaluation Linda Ariani Gunawan.
Practical IS security design in accordance with Common Criteria Security and Protection of Information 2005 František VOSEJPKA S.ICZ a.s. June 5, 2005.
S/W Project Management
© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite.
1 CMPT 275 Software Engineering Software life cycle.
Test Organization and Management
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
Information Systems Security Computer System Life Cycle Security.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
1 MDWE'2008, Toulouse, France, September 30, 2008 A Comparative Analysis of Transformation Engines for User Interface Development Juan Manuel González.
1 Omissions and errors in the CC Who got it right? 8ICCC Denise Cater.
WELNS 670: Wellness Research Design Chapter 5: Planning Your Research Design.
Background. History TCSEC Issues non-standard inflexible not scalable.
Software Engineering Management Lecture 1 The Software Process.
16 1 Installation  After development and testing, system must be put into operation  Important planning considerations Costs of operating both systems.
The Value of Common Criteria Evaluations Stuart Katzke, Ph.D. Senior Research Scientist National Institute of Standards & Technology 100 Bureau Drive;
Methodologies. Contents Waterfall Model Evolutionary Models Incremental Development.
Formal Methods in Software Engineering
Common Criteria V3 Overview Presented to P2600 October Brian Smithson.
© 2014 Pearson Education, Inc., Upper Saddle River, NJ. All rights reserved. This material is protected by Copyright and written permission should be obtained.
© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite.
European Conference on Quality in Official Statistics Session 26: Census 2011 « Helsinki, 6 May 2010 « Census quality control with BSC: the Portuguese.
1 CS 501 Spring 2004 CS 501: Software Engineering Lecture 2 Software Processes.
1 Common Evaluation Methodology for IT Security Part 2: Evaluation Methodology chapter 5-8 Marie Elisabeth Gaup Moe 06/12/04.
1 Using Common Criteria Protection Profiles. 2 o A statement of user need –What the user wants to accomplish –A primary audience: mission/business owner.
Chapter 2: Testing in Software Life Cycle MNN1063 System Testing and Evaluation.
Copyright (C) 2007, Canon Inc. All rights reserved. P. 0 A Study on the Cryptographic Module Validation in the CC Evaluation from Vendors' point of view.
STRATEGY FOR DEVELOPMENT OF ISIS AND IT STRATEGY IN THE NSI-BULGARIA Main principles, components, requirements.
TM8104 IT Security EvaluationAutumn Evaluation - the Main Road to IT Security Assurance CC Part 3.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
======!"§==Systems= Technical Guidance for CC Evaluation Wolfgang Killmann T-Systems GEI GmbH.
Copyright atsec information security, IBM, 2007 How To Eat A Mammoth Experiences With the Evaluation of Complex Software Products Under the Common Criteria.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
High Assurance Products in IT Security Rayford B. Vaughn, Mississippi State University Presented by: Nithin Premachandran.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Chapter 21: Evaluating Systems Dr. Wayne Summers Department of Computer Science Columbus State University
OCTAVE By Matt White. OCTAVE  OCTAVE® (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is a risk-based strategic assessment and planning.
9 th International Common Criteria Conference Report to IEEE P2600 WG Brian Smithson Ricoh Americas Corporation 10/24/2008.
P3 Business Analysis. 2 Section F: Project Management F1.The nature of projects F2. Building the Business Case F4. Planning,monitoring and controlling.
ITIL: Service Transition
Software Engineering Management
Software life cycle models
9th International Common Criteria Conference Report to IEEE P2600 WG
Final Conference 18 Set 2018.
Presentation transcript:

Effective banking products CC evaluations. 8 th I.C.C.C. Rome, September 26th, CHIOCCA Martine Banking products Security Risk Manager

Gemalto Public Context of efficient CC evaluations  French Banking products required security evaluation since 1995 and annual certificate survey:  : ITSEC xxxxx,  2000-now : CC EAL 4 + (VLA.4,..)  Scope of the evaluation : all payment applications on the card:  National & International EMV Payment  Legacy Payment  National purse Monéo  Protection profiles :  PP/9911 (payment) & PP/0101(purse)  New European CAS Security Target

Gemalto Public Security Target Certificate Survey FOURNITURES Certificat EAL4+ Smart Card S/W developer IC manufacturer Sponsor or Observer Preparation DCSSI CESTI Evaluation & Certification processes Evaluation Technical Report (ETR)

Gemalto Public Gemalto evaluation strategy  Capitalize working with the same evaluation laboratory for each banking products’ type : native, java, contactless,…  Advantages:  Parallelize as much as possible product design & evaluation  Capitalize on laboratory’s knowledge of the product  Better chance to get productive lab’s feedback  Reusability of assurance deliverables  Quicker and less expensive security evaluation

11 End Eval.. Development and Evaluation processes Development Process Emulator Testing. DevelopmentSpecification Card Testing Analysis Imp., Code. Devpt.Method. & Environment Target & Devpt. specifications Card Testing & VLA Evaluation Process 2 to 3 months Generic process Card roming

Gemalto Public Synchronizes design and evaluation  First step of evaluation : ASE, ADV deliveries,to reach the source code review  An card emulator and associated tools are given to the laboratory  Goal => get as much comments before Roming  Second step : others deliveries ACM, ADO, ATE,  During roming most deliveries are updated  Last step: AVA deliveries and penetration testing  Duration : 2-3 months after the deliveries of the first cards  Cards characteritics : –With & without “coating” to gain time in preparation –With known & unknown data

Gemalto Public Security : Ever moving target  What do we learn from the evaluations:  All code review gave feedback taken into account before roming.  Most penetration tests reveals us investigation tracks that could be enhanced in future products to make those tracks even less accessible  Certification is a GOOD…. starting point……  Annual survey : required by French baking organizations  Each year the same laboratory re-assesses the product resistance  Second evaluation derivates from exiting certified product => 50% less on Cost and Duration.

Gemalto Public SmartCard Security : Still keep ahead  ONLY WAY TO IMPLEMENT EFFICIENT SECURITY MECHANISMS => Internal Gemalto laboratory:  Equivalent technical level as external ITSEF  State of the Art at attacks techniques  More 10 experts investigating in S/W and H/W attacks  New security mechanisms efficiency.  Privately evaluated to assess robustness  Internally and externally evaluated

Gemalto Public Conclusion of our CC evaluation experiences  Effective CC evaluations  Operational way of practicing CC evaluation  Efficient CC evaluations  All CC evaluated products gets certified at once.  All our banking customers are confident in the security level of the products.  Our experience in security proved our products do resist over time.

The end… Questions ? Contact : Tel : 33(1)

11 © CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 2007 Effective smartcard evaluations process - Jean- Pierre KRIMM Effective Smartcard Evaluations Process Jean-Pierre KRIMM Technical Manager of CESTI-LETI th ICCC, Rome, September 26 th, 2007.

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 12 Effective smartcard evaluations process - Jean-Pierre KRIMM Context Smartcard evaluations In the French Scheme of Certification Using a composition scheme with CC v2 Based on the experience of a developer (Gemalto) and an evaluator (CESTI-LETI) The goal wishes is To reduce time and cost of an evaluation Keeping the same efficiency as usually This part presents the evaluator point of view

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 13 Effective smartcard evaluations process - Jean-Pierre KRIMM Presentation Outline Smartcard evaluations General presentation of the composition scheme Description of the standard evaluation tasks sequencing How to save time: 4 recipes Adaptation of the standard tasks sequencing The entire source code is provided An IC emulator is kept available The scheme is deeply involved in the evaluation Conclusion

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 14 Effective smartcard evaluations process - Jean-Pierre KRIMM Smartcard Evaluation Process A typical smartcard architecture (closed) The composition scheme First, the IC is evaluated and certified Then, the whole product is evaluated, using the results of the IC evaluation These steps are not necessary performed by the same lab. Integrated Circuit (IC) Applications OS

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 15 Effective smartcard evaluations process - Jean-Pierre KRIMM Standard evaluation tasks sequencing The path in red is the critical one In practice Conformity tasks are performed first for acquiring the knowledge of the TOE, i.e. ADV, ACM, ALC, ADO, AGD Efficiency ones are performed in last, i.e. AVA Some of them shall be performed on the TOE suitable for testing i.e. ATE_IND, AVA_VLA, ADO_IGS, ACM_CAP, AVA_MSU

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 16 Effective smartcard evaluations process - Jean-Pierre KRIMM How to save time in the evaluation Identifying vulnerabilities or anomalies earlier to correct them as soon as possible Penetration testing will be divided in two sub-sets A standard made of state of the art’s attacks related to a well known application A specific which refines the standard one, and adds new ones strongly dependent to the implementation and the IC vulnerabilities To achieve this goal, 4 recipes: 1. Adaptation of the standard tasks sequencing: a code review and standard attacks will be performed in advance 2. The entire source code is provided 3. An IC emulator is kept available 4. The scheme is deeply involved in the evaluation

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 17 Effective smartcard evaluations process - Jean-Pierre KRIMM 1 - Adaptation of the standard tasks sequencing Context reminded: applications are well known French banking applications: legacy, EMV, e-purse Some evaluation tasks can be performed in advance A partial code review can be performed on its finale version. => a first feedback on the quality of the implementation can be provided to the developer The standard sub-set of attacks can be performed in advance, in each banking application, as soon as samples are available => a first feedback on the resistance of the product can be provided to the developer this leads to identify common vulnerabilities earlier and thus allows corrections earlier The standard evaluation tasks sequencing will be completed, performing the complete code analysis (ADV_IMP) and the specific sub-set of attacks

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 18 Effective smartcard evaluations process - Jean-Pierre KRIMM 2- The entire source code is provided The entire application source code is provided To the lab. premises Including cryptographic implementations Including the generated assembler Benefits The evaluator has the source code always available Guarantee the independence of the evaluator Both levels of language are necessary for attacks, i.e. the high level to identify a vulnerability, and the low level for its exploitation

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 19 Effective smartcard evaluations process - Jean-Pierre KRIMM 3 - An IC emulator is kept available An IC emulator is kept available In the case the evaluator needs it Helpful to understand both H/W and S/W behaviors, To save time simulating the feasibility of attacks Due to the composition scheme The IC is usually not well known by the lab. Some H/W countermeasures are not fully explained The IC is seen as a “grey box”

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 20 Effective smartcard evaluations process - Jean-Pierre KRIMM 4 - The scheme is deeply involved in the evaluation The French Scheme is deeply involved in each evaluation Benefits It allows an earlier detection of evaluation anomalies, which are taken into consideration when they appear It allows to find a solution quickly when a problem occurs It guarantees the level of the evaluation in real time, for a specific way to work

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 21 Effective smartcard evaluations process - Jean-Pierre KRIMM Conclusion It is possible to improve an evaluation process in terms of time (and cost) for a well-known specific domain, i.e. smartcard experience driven, for both developer and evaluator through a specific scheme without a specific interpretation of the CEM keeping the same level of evaluation

© CEA Tous droits réservés. Toute reproduction totale ou partielle sur quelque support que ce soit ou utilisation du contenu de ce document est interdite sans l’autorisation écrite préalable du CEA All rights reserved. Any reproduction in whole or in part on any medium or use of the information contained herein is prohibited without the prior written consent of CEA 22 Effective smartcard evaluations process - Jean-Pierre KRIMM Thank you for your attention Contact : Tel: +33 (0)