Certifications and standards...2020/05/14 · 1 year of work experience) in 2 or more of the...

Pattern Recognition and Applications Lab

Universityof Cagliari, Italy

Department of Electrical and Electronic Engineering

Cybersecurity Certificationsand Standards

Giorgio Fumera

[email protected]

http://pralab.diee.unica.it

What is the meaning of certification?

• Defining the meaning of security– what are the characteristics of a secure system?– how to define different levels of security?

• Regulating a hierarchy of certification services– who is entitled to assign the roles for issuing certificates– characteristics of certification bodies

• Kinds of certifications– professional certification: assigning a qualification– product (hardware and software) and process certification: certifying

the presence of certain features

2


Professional Certifications

http://pralab.diee.unica.it 4

CISSP

Certified Information Systems Security Professional– https://www.isc2.org/– managed by the International Information Systems Security

Certification Consortium (ISC)² – a not-for-profit organization founded in 1989

– compliant with the ANSI ISO/IEC Standard 17024 since 2004 – current version: ISO/IEC 17024:2012 (confirmed in 2018) Conformity assessment -- General requirements for bodies operating certification of persons

– compliant with the requirements of the US Department of Defense(DoD)

https://www.isc2.org/

https://www.iso.org/standard/52993.html


CISSP target professionals

Experienced security practitioners, managers and executives, including those in the following positions:

– Chief Information Security Officer– Chief Information Officer– Director of Security– IT Director/Manager– Security Systems Engineer– Security Analyst– Security Manager– Security Auditor– Security Architect– Security Consultant– Network Architect

5


How to obtain the CISSP certification

Minimum of 5 years cumulative paid full-time work experience (4-year college degree = 1 year of work experience) in 2 or more of the following 8 domains of the CISSP CBK(Common Body of Knowledge), then pass an exam on all domains

– Security and Risk Management • security, risk, compliance, law, regulations, business continuity

– Asset Security • protecting security of assets

– Security Engineering • engineering and management of security

– Communications and Network Security • designing and protecting network security

– Identity and Access Management • controlling access and managing identity

– Security Assessment and Testing• designing, performing, and analyzing security testing

– Security Operations• foundational concepts, investigations, incident management, disaster recovery

– Software Development Security • understanding, applying, and enforcing software security


CISSP in Italy

(ISC)2 Italy chapter: https://www.isc2chapter-italy.it

Not-for-profit organization founded in 2011

Activities include the organization of courses to prepare for the CISSP exam

https://www.isc2chapter-italy.it/


Product Certification: Introduction

8


ICT product certification

Product certification– outcome of an assessment activity carried out by an independent

third party (certification body)– certification bodies have to be authorized by specific accreditation

bodies– based on standards and established methodologies

Security certificationactivity which provides a probabilistic assurance of the capability of a system to comply with security specifications related to its operation or use

9


Normative context• Reference regulations: what needs

to be certified and how• Certification scheme: rules

governing the process of applying reference regulations

• Scheme manager: local, independent body that– guarantees the correct application of

the scheme by all subjects involved– negotiates mutual acknowledgment

agreements with peer bodies in other countries

• Scheme guarantor: independent body (usually, an international one) in charge of settling disputes involving the scheme manager

Subjects involved• Accreditation body: initial accreditation

and periodic evaluation of certification bodies

• Certification body: issues certifications based on evaluation outcomes by evaluators, guarantees the correct management of certificates

• Evaluator• Client: owner of certification object,

recruits the evaluator• Object to be evaluated or certified• Certification user: the body that will

make use of the certification: the client itself (e.g., the manufacturer), a supplier or the final user

10

ICT product certification


Characteristics of product certifications

• Impartiality: accreditation body, certification body and evaluator must be an independent third party with respect to the client (no common commercial of financial interests related to the certification outcome)

• Objectivity of the evaluation: based on empirical evidence• Repeatability of the evaluation by the same evaluator on the

same product with respect to the same security requirements

• Reproducibility: same as above, by a different evaluator

11


Software Certifications


Orange Book (1985)

Trusted Computer Security Evaluation Criteria (TCSEC) – developed by the US Department of Defense (DoD) since 1985– focused on military applications– used until 2000, then replaced by Common Criteria (CC)– first document on software certification, focused on computers

and then extended to other security domains– defines criteria to probabilistically evaluate the security of

operating systems, subdivided into seven classes – outdated categorization, but still valid principles: early stage of ISO 27001 security domains• Security Policy • Identification • Labels • Documentations • Accountability • Life Cycle Assurance • Continous Protection

13Giorgio Giacinto 2014Certificazione


Orange Book (1985)


Currently available at:• http://www.dynamoo.com/orange• https://csrc.nist.gov/csrc/media/publica

tions/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf

http://www.dynamoo.com/orange

https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc-1998/documents/early-cs-papers/dod85.pdf


Orange Book categorization

• D: Minimal Protection– OSs that fail to meet the requirements for a higher evaluation class,

e.g.: MS-DOS, Windows 95/98/ME

• C: Discretionary Protection– administrators can apply protection mechanisms to objects– the OS provides some basic logging capabilities

• C1 – Discretionary Security Protection, e.g.: users – data separation in early UNIX versions

• C2 – Controlled Access Protection: fine-grained access control, e.g., IBM OS/400, Win NT/2000/XP, Novell Netware



Orange Book categorization

• B: Mandatory Protection– the OS requires to assign protection levels to each object

• B1 – Labeled Security Protection (process, file, device, etc.), e.g.:HP-UX, Cray Research Trusted Unicos 8.0, Digital SEVMS

• B2 – Structured Protection: formal security policy model, e.g.:Honeywell Multics, Cryptek VSLAN, trusted XENIX

• B3 – Security Domains: mediation of accesses of subjects to objects, e.g.: Getronics/Wang Federal XTS-300

• A (A1): Verified Protection– trustworthiness of the OS is verified through formal methods, e.g.:

Boeing MSL LAN, Honeywell SCOMP



Information Technology Security Evaluation (ITSEC)The European analogous of US's TCSEC

– developed by France, Germany, UK and The Netherlands– published in 1991– the "father" of modern evaluation criteria for IT products and systems– widely used in the military sector and for digital signature– now replaced by Common Criteria (CC)

17


Common Criteria (CC)

A common set of criteria for evaluating the security of computer systems, developed by the national security authorities of USA, Canada and Europehttps://www.commoncriteriaportal.org

Common Criteria Recognition Agreement (CCRA)– product evaluation by independent, licensed laboratories– documents defining the certification process– certifications issued by Certificate Authorizing Schemes (subset of

CCRA members)– certifications recognized by all CCRA members


https://www.commoncriteriaportal.org/


Common Criteria

• First version: 1996

• Used in ISO/IEC 15408-3:2008 standardInformation technology -- Security techniques -- Evaluation criteria for IT security -- Part 3: Security assurance componentspublicly available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

• Current version: 3.1 Release 5 (April 2017)– Part 1: Introduction and general model– Part 2: Security functional requirements– Part 3: Security assurance requirements


https://www.iso.org/standard/46413.html

https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html


Common Criteria members

• 18 Certificate Authorizing Members (schemes)– Australia– Canada– France– Germany– India– Italy (since 5 October 2009)– Japan– Malaysia– Norway

• 12 Certificate Consuming MembersAustria, Czech Republic, Denmark, Ethiopia, Finland, Greece, Hungary, Indonesia, Israel, Pakistan, Poland, Qatar

20

– New Zealand– Netherlands– Singapore– South Korea– Spain– Sweden– United Kingdom – Turkey– USA

Giorgio Giacinto 2014Certificazione


Common Criteria members – Italy

• Organismo Certificazione Sicurezza Informatica (OCSI)http://www.ocsi.isticom.it/

• OCSI is in charge of maintaining the National Scheme for the evaluation and certification of the security of systems and products in the ICT sector (DPCM 30.10.2003 - G.U. n.98 27.04.2004)

• OCSI is within ISCOM (Istituto Superiore delleComunicazioni e delle Tecnologie dell’Informazione) of the Ministry for the Economic Development (MISE)

• Currently six laboratories in Italy provide services for system and product evaluation for the assignment of the Evaluation Assurance Level (see below)

http://www.ocsi.isticom.it/


CC: Evaluation Assurance Level (EAL)

• EAL1 – functionally tested (lower level)• EAL2 – structurally tested• EAL3 – methodically tested and checked• EAL4 – methodically designed, tested and reviewed• EAL5 – semiformally designed and tested• EAL6 – semiformally verified design and tested• EAL7 – formally verified design and tested (upper level)


CC: Protection Profiles

Document describing a category of products to identify the elements

subject to evaluation for the CC certification

– Access Control Devices and Systems (3 PP)

– Biometric Systems and Devices (2 PP)

– Boundary Protection Devices and Systems (11 PP)

– Data Protection (7 PP)

– Databases (1 PP)

– ICs, Smart Cards and Smart Card-Related Devices and Systems (67 PP)

– Key Management Systems (4 PP)

– Mobility (2 PP)

– Multi-Function Devices (1 PP)

– Network and Network-Related Devices and Systems (10 PP)

– Operating Systems (2 PP)

– Other Devices and Systems (41 PP)

– Products for Digital Signatures (19 PP)

– Trusted Computing (5 PP)

23


CC: Certified products by category

24


CC: Certified products by EAL

25


CC: Certified products by country

26


CC: examples of certified products

EAL 7+– Fort Fox Hardware Data Diode, versie FFHDD2+

EAL 7– Virtual Machine of Multos M3 G230M mask with AMD 113v4– Memory Management Unit des microcontrôleurs SAMSUNG S3FT9KF/

S3FT9KT/ S3FT9KS en révision 1

EAL6+– Green Hills Software INTEGRITY-178B Separation Kernel, comprising:

INTEGRITY-178B Real Time Operating System (RTOS), version IN-ICR750-0101-GH01_Rel running on Compact PCI card, version CPN 944-2021-021 with PowerPC, version 750CXe

– Infineon Security Controller M7893 B11 with optional RSA2048/4096 v1.03.006, EC v1.03.006, SHA-2 v1.01 libraries and Toolbox v1.03.006 and with specific IC dedicated software (firmware)



CC: examples of certified products

EAL4+– Red Hat Enterprise Linux Version 7.1– SUSE Linux Enterprise Server Version 12– JBoss Enterprise Application Platform 6 Version 6.2.2– Microsoft SQL Server 2014 Database Engine Enterprise Edition x64– FINX RTOS Security Enhanced (SE) v3.1

EAL4– Microsoft Windows 10 Anniversary Update Home Edition, Pro Edition

and Enterprise Edition (32 and 64 bits), and Microsoft Windows Server 2016 Standard Edition and Datacenter Edition

– IBM z/OS Version 2 Release 1

28


Process Certifications

29


Limits of Common Criteria

• CC evaluation process requires– long time– high costs

• Product evaluation through the CC schema is suitable to– equipment for military forces – critical infrastructures (nuclear and chemical plants, etc.)

• The "connection of everything" to the network requires novel certification schemes– fast enough to cope with the release of new versions– larger base of certification laboratories

30


Public-private initiatives

• USA and UK established public-private working groups to define novel certification schemes– USA: NIST– UK: Home Office

• In Europe: European Cyber Security Organisation (ECSO)https://www.ecs-org.eu/

31

https://www.ecs-org.eu/


NIST Cybersecurity Framework

Framework for Improving Critical Infrastructure CybersecurityVersion 1.1 – April 2018

32


NIST Cybersecurity Framework

Framework for Improving Critical Infrastructure CybersecurityVersion 1.1 – April 2018

33


Italian Cybersecurity Framework

Public-private-partnership promoted by– Research Center of Cyber Intelligence and Information Security (CIS) of

the University of Rome – Sapienza– Cybersecurity National Laboratory of the National Interuniversity

Consortium for Informatics (CINI)

http://www.cybersecurityframework.it

Main facts– established in February 2016– based on the NIST Cybersecurity framework– focus on small and medium enterprises (SMEs)

34

http://www.cybersecurityframework.it/


UK Cyber Essentials

• UK Government – First proposed in June 2014https://www.cyberessentials.ncsc.gov.uk/

• Cyber EssentialSelf certification

• Cyber Essential Plus Certified by an external organization

• Essential requirements– boundary firewalls and internet gateways– secure configuration– access control– malware protection– patch management

35

https://www.cyberessentials.ncsc.gov.uk/


Italian Cybersecurity Essentials

• Managed by CIS (Italian Cybersecurity Framework)http://www.cybersecurityframework.it/csr2016

• Established in February 2017

• 15 essential security measures in 8 areas– Inventory of devices and software (4 Measures)– Governance (1 Measure)– Malware Protection (1 Measure)– Password and Account Management (3 Measures)– Training and Awareness (1 Measure)– Data Protection (2 Measures)– Network Protection (1 Measure)– Prevention and Mitigation (2 Measures)

36

http://www.cybersecurityframework.it/csr2016


Web App Certification


OWASP Security Verification Standard

• Application Security Verification Standard 4.0 (March 2019)https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

• Security Verification Layers

– Level 1: low assurance levels, completely penetration testable

– Level 2: applications with sensitive data, recommended for most apps

– Level 3: most critical applications, requiring the highest level of trust

(high value transactions, sensitive medical data)

OWASP Application Security Verification Standard 4.0 9

containers, CI/CD and DevSecOps, federation and more, we cannot continue to ignore modern application architecture. Modern applications are designed very differently to those built when the original ASVS was released in 2009. The ASVS must always look far into the future so that we provide sound advice for our primary audience - developers. We have clarified or dropped any requirement that assumes that applications are executed on systems owned by a single organization.

Due to the size of the ASVS 4.0, as well as our desire to become the baseline ASVS for all other ASVS efforts, we have retired the mobile section, in favor of the Mobile Application Security Verification Standard (MASVS). The Internet of Things appendix will appear in a future IoT ASVS care of the OWASP Internet of Things Project. We have included an early preview of the IoT ASVS in Appendix C. We thank both the OWASP Mobile Team and OWASP IoT Project Team for their support of the ASVS, and look forward to working with them in the future to provide complementary standards.

Lastly, we have de-duped and retired less impactful controls. Over time, the ASVS started being a comprehensive set of controls, but not all controls are equal at producing secure software. This effort to eliminate low impact items could go further. In a future edition of the ASVS, the Common Weakness Scoring System (CWSS) will help prioritize further those controls which are truly important and those that should be retired.

As of version 4.0, the ASVS will focus solely on being the leading web apps and service standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture.

Using the ASVS ASVS has two main goals:

• to help organizations develop and maintain secure applications.

• to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

Application Security Verification Levels The Application Security Verification Standard defines three security verification levels, with each level increasing in depth.

• ASVS Level 1 is for low assurance levels, and is completely penetration testable

• ASVS Level 2 is for applications that contain sensitive data, which requires protection and is the recommended level for most apps

• ASVS Level 3 is for the most critical applications - applications that perform high value transactions, contain sensitive medical data, or any application that requires the highest level of trust.

Each ASVS level contains a list of security requirements. Each of these requirements can also be mapped to security-specific features and capabilities that must be built into software by developers.

Figure 1 - OWASP Application Security Verification Standard 4.0 Levels

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project


Level 1

First steps, automated, or whole of portfolio view– bare minimum that all applications should strive for– the application adequately defends against easy to discover

vulnerabilities included in the OWASP Top 10– also useful as a first step in multi-phase efforts or when applications

do not store or handle sensitive data– ensured either by automatic tools or simply manually without access

to source code– threats to the application will most likely be from attackers who are

using simple and low effort techniques to identify easy-to-find and easy-to-exploit vulnerabilities

39


Level 2

Most applications– the application adequately defends against most of the known risks– security controls are in place, effective, and used within the

application– appropriate for applications that handle significant business-to-

business transactions, including those that process healthcare information, or process other sensitive assets

– threats will typically be skilled and motivated attackers focusing on specific targets using tools and techniques that are highly practiced and effective at discovering and exploiting weaknesses within applications

40


Level 3

High value, high assurance, or high safety– applications that require high levels of security verification

• military, health and safety, critical infrastructure, etc. – in depth analysis, architecture, coding, and testing– a secure application is modularized in a meaningful way,e ach module

takes care of its own security responsibilities (defense in depth), through controls to ensure• confidentiality (e.g., encryption)• integrity (e.g., transactions, input validation)• availability (e.g., handling load gracefully)• authentication (also between systems)• non-repudiation, authorization, and auditing (logging)

41


Verification requirements

V1. Architecture, Design and Threat Modelling

V2. Authentication

V3. Session management

V4. Access control

V5. Validation, Sanitization and Encoding

V6. Stored Cryptography

V7. Error Handling and Logging

V8. Data Protection

V9. Communications

V10. Malicious Code

V11. Business Logic

V12. File and Resources

V13. API and Web Service

V14. Configuration

42


Verification requirements and levels

For each level, the requirements changeexample for V1 – Architecture Design and Threat Modelling:

43

...


Other certifications

44


ISO 27000 standardsInformation security management

45

IES/IEC 27000

27001

27002

27034

Family of standards for the management of information security – not limited to computer security

Secure management of information, regardless of the technology used

Security measures to mitigate the risk in information management, each measure being related to the specific technology used

Application security controls


Financial sector

• PCI (Payment Card Industry) Security Standard– PCI-DSS (Data Security Standard)

Standard for merchants that process card payments– PA-DSS (Payment Application DSS)

Standard for software developers of applications that process card payments

• SWIFT (Society for Worldwide Interbank Financial Telecommunication)– standardizes the messages exchanged by financial players to perform

common business processes, such as making payments or confirming trades

– maintains ISO 20022

46

Date post:	03-Oct-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Certifications and standards...2020/05/14 · 1 year of work experience) in 2 or more of the...

Documents