atsec’s Rome office is accredited by OCSI for Common Criteria evaluations

atsec is pleased to announce that the atsec Rome office has been accredited by the Italian scheme, OCSI, for performing Common Criteria evaluations.

This is in addition to the accreditations by the Italian security agency, OCSI of our atsec laboratories in the U.S., Germany and Sweden.

Garibaldi Conte: Managing Director, atsec Italy, 2019:

“I am both happy and excited for atsec's entrance into the Italian market for IT Security Evaluation and Certification. I have been in the InfoSec business for over 15 years in Italy. The reason I accepted the challenge to be the Managing Director of the atsec Italian operation, is because of atsec's level of expertise in the field, depth of knowledge, care for standards, many achievements, customer base, the technology they have evaluated and their global presence. Under those conditions, atsec Italy is not a challenge, but a gift—a gift that will strengthen Italy's role in IT Security Evaluation and Certification in Europe.”

Staffan Persson, Co-founder, Managing Director EMEA:

“atsec’s strategy is to support our customers with their information assurance needs. With a great many leading global companies in our customer portfolio, it is important that we establish a strong presence in Europe as the EU Cybersecurity Act develops to do all that long-standing regional mutual recognition arrangements such as SOG-IS have achieved and much more.”

 

Salvatore La Pietra, Co-Founder, President and CEO:

"atsec has a mission at the core: ‘information security done right.’
We have always looked at IT Security differently from others. Our customers tell us that and our people show it.
atsec Italy, together with atsec Germany and Sweden, provide a substantial European presence, and together with atsec US and atsec China increase our geographical and cultural presence, underlining our global dedication to our customers. atsec Italy is the latest to join the atsec group, but will not be the last. Stay tuned…"




The atsec Italy office is located in Rome at:

atsec information security srl

Via Tirso, 26

00198 Rome

Italy

Tel: +39-06-89232678 

www.atsec.it

The first week in Orlando

Last week we attended the CCUF meeting in Orlando. 

This meeting is co-located with the bi-annual CCDB meeting and co-locating them allows the two organizations the opportunity for cooperation. Both groups operate in closed session but for the CCMC the members are the CCRA nation representatives while the CCUF membership includes representatives from the whole community, including the national schemes. The two organizations also arranged for some joint “de-briefing” meetings.
 
In addition to the formal sessions, of course a lot of discussion also happens during the breaks, and for quite a few of us at the joint “(Un) Happy” hour.

Gossip, rumors, and innuendo are always prevalent when two groups with different objectives are juxtaposed. Here are a few from the week:

If only… “The atsec blog would go away”…  and … “Yay! for the atsec blog”  ;)

If only… We could solve the CCUF tea problem! 

Trivial? Perhaps this is a symptom; but how can the CCUF be a powerful organization if we don’t have a nice hot cup of tea? 

It's an important part of the process, accepted and enjoyed by the diverse peoples of many nations. Tea can be used to predict the future and, especially useful when discussing crypto topics, can also be used for  generating small amounts of finite improbability.

(I don’t know, perhaps the CCUF needs to be a legal entity before we can sponsor tea for ourselves?)

If only… The CCUF would represent the whole of the criteria-using community. Not just those working under one MRA (i.e., the CCRA) but also supporting those working under other mechanisms for applying the criteria such as SOGIS, commercial schemes, and even national applications – regardless of whether they use the CCDB’s CC or ISO/IEC 15408.

An observation from the Mobility Device working group: "The CCUF has just about zero direct representation from end users. This is fine (in theory) because the schemes may play the role of advocating for their end users. They don't here. At least, NIAP doesn't, who was clearly running this TC."

If only… “We’d started developing cPPs ten years ago. Using this process we would have an agreed PP for secure floppy disks ready for use very soon now.”

Does the CCMC realize that it takes at least 2-3 years for international organizations to achieve international consensus? While some TC's are being led to believe that once completed a PP can be approved in a few months (NIAP quoted 3-4 months from completion in the TC to publication during the MFP workshop today) the CCMC process can be expected to take much longer, with the complex national approvals and endorsements required by the formal process being developed as part of the USB TC. 

We must set expectations properly and communicate that in reality, following a formal process, it will take at least 5 years to produce a cPP.

In fact ISO’s JTC 1/SC 27 and the CCDB have an established special relationship, are we clever enough to leverage that relationship intelligently? Can we save some time?  

If only… Key CCDB documents, such as the proposed new CCRA, could be open for CCUF members to review too. 
The CCUF has many very experienced members and offer potentially valuable contributions. Even though the CCUF will not be a signatory to the CCRA, the CCUF members are key stakeholders. 
Last week I heard from the MC chair that the new CCRA will be published without any review from the CCUF constituents. If these stakeholders have any issues, the CCMC may consider these for the next CCRA. – Wow!

If only… The good intentions, willingness to contribute and produce something good, enthusiasm and expertise that we find in the CCUF was not being eroded by confusing, changing, inconsistent policies, and delaying tactics from the CCMC.   

Here is one expression of opinion I heard: "There is not clear direction, everyone is concerned they will do work that won't be approved, and they constantly look around to see what others are doing to see if they comply with that, since there seems no clear directive on a way forward."

(See Edward Gibbons "The History of the Decline and Fall of the Roman Empire")

 
If only…  We understood the parameters and goals of the proposed iTC for “Apps on an OS.” That is obviously going to be one very busy iTC and will need some special management techniques.

By the way, is a virtualized OS also an “App on an OS” and will there be another sister iTC for “Apps not on an OS?”

Again, information on this proposal seems scanty, and I, for one, look forward to much more clarity from the CCMC on the scope of this item.


If only… The CCMC would adopt another message for the week other than “It is hard to co-ordinate 26 nations.” Yes, we got that. All the CCUF members I spoke with during the week agreed that it is hard to coordinate 26 nations.
Two points on this:

1. I would suggest that every time we hear this message next week we recall that some organizations have already worked this out, and have policies and procedures to deal with this problem in “reasonable” time-frames: Two examples: ISO (SC27 currently coordinates 68 nations) and ICAO (currently coordinates 191 nations). These organizations publish their procedures and it’s not easy for them either.

At least ISO’s JTC 1 process includes co-ordination with each national standards body. In turn many of these JTC 1 members include representatives from the vendor/developer community, whose expert contributions are solicited and respected.

Does the CCMC not try to learn from these mature organizations?

2. Developers working internationally also have to deal with this problem. They are selling products to a variety of national governments and have the unenviable task to understand the various regulations and policies of nations in order to develop and sell their products. That is not easy either.

If only… The CCMC paid attention to some of the project dependencies and communicated (estimated) time frames. Perhaps a simple Gantt chart might help the CCUF in their planning and coordination?
Example: New iTC’s cannot be formed until the iTC procedures and policies are complete, yet we seem to have already formed several TCs that may be put back at beginning once we know where the beginning is.

If only… The schemes paid proper attention to current weaknesses and threats.
Example: The Mobile PP requiring just TLS 1.0 rather than more recent versions that have been updated to address more recently identified weaknesses and threats.
(On this topic an interesting speculative blog article by Matthew Green, is here.) 

If only… The  national schemes would communicate between themselves more effectively.
Example: last week we heard from two major vendors in the OSPP workshops claim that a document containing "General-Purpose OS Cryptographic Requirements" had been provided to U.S. and Canadian evaluations back in April, but the OSPP pilot evaluation run by BSI has never been made aware of their existence, which shows some weird understanding of the cooperation in such pilot projects.

If only… There were no rumors…:
Next week we may find out if some are true…

• A new certificate producing nation will be announced. (It is already announced on the CC Portal)
• A new CCRA , as promised by the CCMC chair (this was announced at least a year ago in Paris) and the promise has been re-iterated this week.
• Where will the conference be held next year?
• Who is the missing Mickey?  

By Fiona Pattinson

Report on the work in ISO/IEC JTC 1/SC 27/WG 3 related to ISO/IEC 15408

Last week I was once again privileged to be able to  join ISO/IEC JTC 1/SC 27/WG 3 during the latest of their bi-annual working sessions held in April and October.

Convened by Miguel Bañón, this working group is of particular interest to atsec since it includes work on the international standards and guidance documents relating to ISO/IEC 15408, ISO/IEC 19790 and other documents closely related to evaluation and testing and the provision of assurance.

I have written in more detail on these standards in:

• ISO's work related to the Common Criteria and
• ISO's cryptographic module work

A little history on the relationship between ISO/IEC 15408 and the Common Criteria reveals that in the early 1990's, as the various national criteria , including Europe's ITSEC, The Canadian Criteria (CTCPEC) and the US Federal criteria, were brought together in order to create a single set of harmonized criteria, the intention was to publish the new set of "Common Criteria" as an ISO standard. A decision was made to create a more agile  technical community that could produce the work and present it to ISO. This was not done using the "PAS" process, but aimed to produce and submit  a substantially complete work that would allow expeditious instantiation of the work with the full involvement of the ISO community,which could then support the standard's future maintenance within ISO.

Hence the CCDB and ISO established a close liaison relationship, the Common Criteria were submitted to ISO by the CCDB and the first edition of  ISO/IEC 15408 was published in December of 1999.  Since then the CCDB have continued to liaise with ISO enabling the content  ISO/IEC 15408 and the "Common Criteria" to remain synchronized. It's a two way relationship allowing for changes and innovations to be brought to WG 3, and vice versa.

ISO brings to the table a breadth and depth of constituents far beyond that of the CCDB. SC 27 (Security Techniques) currently brings together 50 participating nations, a further 27 observing nation and is in liaison with many industry groups and standards organizations.
(At the SC 27 level these currently include CCDB, CCETT, Cloud security alliance, ECBS, ENISA, EPC, ETSI, Ecma International, ISACA/ITGI, ISSEA, ITU, MasterCard, and Visa, and organizations in direct liaison with WG 3 include the CCDB, CSNISG, ENISA, FIRST, ISCI, ISA99, ITU-T, ISO SC 7, ISO SC 37, ISO TC 65/WG 10, ISO TC 247. TCG and The Open Group.)

The various national bodies and liaison organizations represented in WG 3 work closely within their home fields to garner the participation of, and to  represent the interests of, their own constituents.

The CCDB was initially comprised of representatives from those  countries contributing their own national criteria, today the CCDB is still a subset of  the  13 members of the CCRA certificate issuing signatory nations and development efforts  focus on the needs of the government agencies which they represent. From the perspective of commercial industry and the wider group of CCRA it is a closed group, a little disconcerting when you realize that at least in the U.S., the stated policy is to adopt COTS products as a means of making government systems, more timely and cost-effective  and the US government emphasizes the benefits of public-private partnership.

What does this mean in practice? WG 3 have focused on the open development of supporting standards and guidance. My earlier blogs detailed much of the work the WG 3 has established or that in progress. During  our  last WG 3 meeting  we heard from both The Open Group Real Time Embedded Systems forum and from our hosts at ETSI that work on High-assurance is an important topic to them and so WG 3 has initiated a study period on High-assurance - asking for contributions on this topic from it's national bodies and liaison organizations. WG 3 is also calling for contributions on the study period for predictive assurance, in which we hope to  understand the needs of industry and the  nations for this important topic.

As a result of  our last meeting WG 3:

• Proposed a new work item - A Catalogue of Architectural and Design Principles for Secure products, Systems and Applications 
• Resolved  to revise the existing standard ISO/IEC 19791: Security assessment of operational systems in the light of progress that has been made in the few years since it was published and expected findings from the study of predictive assurance
• Resolved to send the final corrigenda for  ISO/IEC 15408 and ISO/IEC 18045 for ballot by the ISO members. (These corrections to the standards reflect the changes that were introduced by Common Criteria V3.1 release 4.)
• Initiated a study period on high-assurance
• Extended the study period on predictive assurance

If you are interested in contributing to these or other developments within SC 27 then you can do so either through your national body, or through one of the liaison organizations to SC 27.

By, Fiona Pattinson

ISO's work related to The Common Criteria

Updated November 9th, 2016

In 1990  ISO/IEC JTC 1 sub committee 27 was formed in order to deal with ICT security, Not long afterwards SC 27 initiated Working Group 3 "Security Evaluation Criteria". This working group focuses on security evaluation, testing and specification. 

At that time, Common Criteria was in development and the need to have these standards internationally recognised was an important point of the strategy. The goal, which has been achieved, was that the standards should be available to the world, regardless of the formal Common Criteria Recognition Arrangement which was the formal arrangement between nations.

SC27's business plan mentions that "The CCDB and SC 27/WG 3 have had a long-standing technical liaison on projects related to IT Security Evaluation Criteria. Thus, Working Group 3 has been working in close co-operation with the CCDB on the development of the Common Criteria, which has been simultaneously published as ISO/IEC 15408. The co-operation has been extended to also involve the work on 18045 “Evaluation methodology for IT security”.

This liaison allows ISO's member national bodies, especially those not represented directly in the CCDB, an opportunity to review, comment and contribute to the project. In many cases it also provides a vehicle for industry experts from the commercial sector (vendor) community to have a place to contribute more directly.


Both ISO/IEC JTC 1/SC 27/WG 3 and the CCDB produce supporting documents, those produced by the CCDB are listed on the CC portal at the bottom of the supporting publications page and cover smartcard and IC technology as well as documents directly related to supporting the CCRA.
   
Additional documents related to ISO/IEC 15408 produced by WG 3 are described below.

2016 Study Period on Information Assurance

2016: The Study Period, which has been run by ISO, in close liaison with the CCDB, in regard to determining appropriate future developments of ISO/IEC 15408, ISO/IEC 18045 and other IT Assurance standards closed after a year. 

The Fall  2016 WG 3 meeting enjoyed a summary of the two calls for comments and the rapporteurs presented a proposal for revising the ISO/IEC 15408 and ISO/IEC 18045 standards, as well as proposing some changes to the structure of ISO/IEC 15408.

The proposed changes are shown in the diagram below. They include the specification of two new parts to ISO/IEC 15408 and an additional document that will be guidance supporting the transition and explaining the changes to the standard.

 

Evaluation criteria and Methodology for IT security evaluation

These are the "equivalent standards" to those published by the CCDB on the CC Portal. Minor revisions of the CC standards are usually addressed in ISO through the publication of corrigenda.

These ISO standards are available from ISO for free (as in beer). The first three are equivalent to the first three parts of the CC, the fourth in the list is the equivalent of the CEM.

ISO/IEC 15408-1:2009: Evaluation criteria for IT security -- Part 1: Introduction and general model

ISO/IEC 15408-2:2008: Evaluation criteria for IT security -- Part 2: Security functional components

ISO/IEC 15408-3:2008: Evaluation criteria for IT security -- Part 3: Security assurance components

ISO/IEC 18045:2008: Methodology for IT security evaluation

Developing security and privacy functional requirements based on ISO/IEC 15408

ISO/IEC TS 19608: Guidance for developing security and privacy functional requirements based on ISO/IEC 15408

This Technical Report provides guidance for developing privacy functional requirements as extended components based on privacy principles defined in ISO/IEC 29100 through the paradigm described in ISO/IEC 15408-2, for selecting and specifying Security Functional Requirements from ISO/IEC 15408-2 to protect Personally Identifiable Information and to specify a procedure to define both privacy and security functional requirements in a coordinated manner.

 2016/11: This new Technical Specification is currently being published by ISO.

Guidance for the production of Protection Profiles and Security Targets

ISO/IEC TR 15446: Guide for the production of Protection Profiles and Security Targets

This technical report provides much needed guidance to PP authors and ST writers. Although ISO/IEC 15408-1 provides the technical information about writing a PP or an ST, The member nations of ISO supported that some practical guidance in writing these documents was needed and that this work should be completed. 

2016/11: The third edition of ISO/IEC 15446 is currently being published by ISO. 

Security assessment of operational systems

ISO/IEC TR 19791: Security assessment of operational systems.

ISO/IEC TR 19791:2010 provides guidance and criteria for the security evaluation of operational systems. It provides an extension to the scope of ISO/IEC 15408 by taking into account a number of critical aspects of operational systems not addressed in ISO/IEC 15408 evaluation. The principal extensions that are required address evaluation of the operational environment surrounding the target of evaluation, and the decomposition of complex operational systems into security domains that can be separately evaluated.
ISO/IEC TR 19791:2010 provides:

1. a definition and model for operational systems;
2. a description of the extensions to ISO/IEC 15408 evaluation concepts needed to evaluate such operational systems;
3. a methodology and process for performing the security evaluation of operational systems;
4. additional security evaluation criteria to address those aspects of operational systems not covered by the ISO/IEC 15408 evaluation criteria.

ISO/IEC TR 19791:2010 permits the incorporation of security products evaluated against ISO/IEC 15408 into operational systems evaluated as a whole using ISO/IEC TR 19791:2010.
ISO/IEC TR 19791:2010 is limited to the security evaluation of operational systems and does not consider other forms of system assessment. It does not define techniques for the identification, assessment and acceptance of operational risk.

This document was initially produced as a technical report with the goal of gaining experience in the subject sufficient to be able to codify a standard. It defines extensions to ISO/IEC 15408 in order to enable the security assessment (evaluation) of operational systems. Since ISO/IEC 15408, does not capture certain critical aspects of an operational system that must be precisely specified in order to effectively evaluate such a system. 

The contents are fairly exhaustive with discussions of

• The technical approach to operational systems assessment used in this Technical Report.
• The extension of ISO/IEC 15408 evaluation concepts for use in operational system evaluation.
• The relationship between this Technical Report and other security standards which have been used in its development.
• requirements for specification of security problems, security objectives, security requirements, SST contents and periodic reassessment which are needed in order to evaluate operational systems.

Annexes provide further supportive material including operational system:

• Security Targets and System Protection Profiles, which defines the security requirement specifications needed for operational systems.
• Functional control requirements, which defines the additional security functional requirements needed for operational systems
• Assurance requirements, which defines the additional security assurance requirements needed for operational systems.
• evaluation methodology, which defines additional actions to be performed by an evaluator conducting the evaluation of an operational system.

This TR has been used in practice, with an early trial evaluation being reported from Japan.

Competence requirements for information security testers and evaluators

DRAFT ISO/IEC TR 19896-1: Competence requirements for information security testers and evaluators: Part 1: Introduction, concepts and general requirements.

Provides the fundamental concepts related to the topic of the competence of the individuals responsible for performing IT product security evaluations and conformance testing. Provides the framework and the specialised requirements that specify the minimum competence of individuals performing IT product security evaluation and conformance testing using established standards.
This will support the goals of ISO CASCO conformity assessment by contributing standardized requirements for competency supporting ISO/IEC 17024.

DRAFT ISO/IEC TR 19896-3: Competence requirements for information security testers and evaluators: Part 3: Knowledge, skills and effectiveness requirements for ISO/IEC 15408 evaluator.

Provides the specialised requirements to demonstrate competence of individuals in performing IT product security evaluations in accordance with ISO/IEC 15408 and ISO/IEC 18045.

Vulnerability analysis and penetration testing for ISO/IEC 15408

ISO/IEC TR 20004-1:2016: Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045

ISO/IEC TR 20004-2:Detailing software penetration testing under ISO/IEC 15408 and ISO/IEC 18045 vulnerability analysis

Vulnerability Handling

ISO/IEC 30111  Vulnerability handling processes 

Describes processes for vendors to handle reports of potential vulnerabilities in products and online services. It is related to ISO/IEC 29147. It interfaces with elements described in ISO/IEC 29147 at the point of receiving potential vulnerability reports, and at the point of distributing vulnerability resolution information.This standard takes into consideration the relevant elements of ISO/IEC 15408-3, 13.5 Flaw remediation (ALC_FLR).

ISO/IEC 29147 Vulnerability disclosure

Gives guidelines for the disclosure of potential vulnerabilities in products and online services. It details the methods a vendor should use to address issues related to vulnerability disclosure.  This standard

1. provides guidelines for vendors on how to receive information about potential vulnerabilities in their products or online services,
2. provides guidelines for vendors on how to disseminate resolution information about vulnerabilities in their products or online services,
3. provides the information items that should be produced through the implementation of a vendor's vulnerability disclosure process, and
4. provides examples of content that should be included in the information items.

ISO/IEC 29147 has recently been published and is currently available for free.

Biometrics 

Delving into technology specific areas of evaluation, biometrics were seen by the community as an area in need of standardization. So far WG 3 has produced two standards in this area.

ISO/IEC 19792 Security evaluation of biometrics

Relevant to both evaluator and developer communities as it addresses biometric-specific aspects and principles to be addressed during a security evaluation of a biometric system.
It does not address the non-biometric aspects which might form part of the overall security
evaluation of a system using biometric technology (e.g. requirements on databases or communication channels).
Neither does this standard aim to define any concrete methodology for the security evaluation of biometric systems but instead focuses on the principal requirements. 
As such, the requirements in this International Standard are independent of any evaluation or certification scheme and will need to be incorporated into and adapted before being used in the context of a concrete scheme. The standard includes:

• an overview of all terms, definitions and acronyms used,
• an introduction of the overall concept for a security evaluation of a biometric system,
• a description of the statistical aspects of security-relevant error rates,
• vulnerability assessment of biometric systems and
• the evaluation of privacy aspects.

 ISO/IEC 24745: Biometric information protection

Provides guidance for the protection of biometric information under various requirements for confidentiality, integrity and renewability/revocability during storage and transfer. Additionally, ISO/IEC 24745 provides requirements and guidelines for the secure and privacy-compliant management and processing of biometric information. ISO/IEC 24745 specifies the following:

• analysis of the threats to and countermeasures inherent in a biometric and biometric system application models;
• security requirements for secure binding between a biometric reference and an identity reference;
• biometric system application models with different scenarios for the storage of biometric references and comparison; and
• guidance on the protection of an individual's privacy during the processing of biometric information.

ISO/IEC 24745: does not include general management issues related to physical security, environmental security and key management for cryptographic techniques.

DRAFT IS 19989-1: Criteria and methodology for security evaluation of biometric systems: Part 1: Framework

DRAFT IS 19989-2: Criteria and methodology for security evaluation of biometric systems: Part 2: Biometric recognition performance

DRAFT IS 19989-3: Criteria and methodology for security evaluation of biometric systems: Part 3: Presentation attack detection

Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408

DRAFT ISO/IEC  TR 20543:Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408.

Physically unclonable functions (PUFs)

DRAFT: ISO/IEC  20897:Security requirements, test and evaluation methods for physically unclonable functions (PUFs) for generating non-stored security parameters

Cryptographic Protocols 

IS 29128: Verification of cryptographic protocols: 

Establishes a technical base for the security proof of the specification of cryptographic protocols. It specifies design evaluation criteria for these protocols, as well as methods to be applied in a verification process for such protocols. It also provides definitions of different protocol assurance levels consistent with evaluation assurance components in ISO/IEC 15408.

Physical Security Attacks, Mitigation Techniques and Security Requirements

ISO/IEC  30104:2015 Physical Security Attacks, Mitigation Techniques and Security Requirements

This technical report provides guidance and addresses the following topics:

• a survey of physical security attacks directed against different types of hardware embodiments including a description of known physical attacks, ranging from simple attacks that require little skill or resource, to complex attacks that require trained, technical people and considerable resources;
• guidance on the principles, best practices and techniques for the design of tamper protection mechanisms and methods for the mitigation of those attacks; and
• guidance on the evaluation or testing of hardware tamper protection mechanisms and references to current standards and test programs that address hardware tamper evaluation and testing.

Secure System Engineering

ISO/IEC TS 19249: Catalogue of Architectural and Design Principles for Secure Products, Systems, and Applications

Provides a catalogue of architectural and design principles that can be used in the development of secure products, systems, and applications together with guidance on how to use those principles effectively. Each architectural and design principle is described using a common structure, identifying the purpose and advantage of the design principle, how it can contribute to develop a secure product, system, or application, its dependency on other principles described in the catalogue.

Examples are provided for each principle on how it may be implemented, how it may contribute to security properties and functions and what other aspects have to be taken into account in the example provided to also address non-security related requirements like usability and performance.

It gives guidelines for the development of secure products, systems and applications and is aiming for a more effective assessment with respect to the security properties they are supposed to implement.

ISO/IEC TS 19249 is related to IS 15408 and IS 18045 and addresses both developers and evaluators of secure products, systems, and applications.

This Technical Specification does not establish any requirements for the evaluation or the assessment process or implementation.

ISO/IEC TR 29193: Secure system engineering principles and techniques

This  technical report, ISO/IEC TR 29193 offers guidance on secure system engineering for Information and Communication Technology systems or products, and emphasizes security engineering aspects within the scope of the development stages of the system lifecycle described in ISO/IEC 15288.

Drawing on the notion that it is better to build a system or product securely in the first place than to spend much resource after its instantiation this technical report begins to offer guidance on how the use of these principles and techniques will support a system engineering process to obtain results consistent with the system security characteristics and objectives determined for the ICT system or product. 

ISO/IEC 21827:2008: Systems Security Engineering -- Capability Maturity Model® (SSE-CMM®). 

This standard was submitted through the Publicly Available Specification (PAS) process by ISSEA and remains in the ISO catalogue.

ISO/IEC 15443  ("FRITSA")

ISO/IEC TR 15443-1:2012:  Security assurance framework -- Part 1: Introduction and concepts

ISO/IEC TR 15443-2:2012: Security assurance framework -- Part 2: Analysis

Substantially revised in 2012. Part one gives a discussion of the nature of security assurance, providing a framework for further discussions and documents. Part 2 of this technical report describes the "criteria for criteria". It discusses security assurance schemes, and how these themselves can be evaluated. While some schemes are of high quality, others may not be. What criteria can be used to tell?

Study Period on the Security requirements, test and evaluation methods for White Box Cryptography (WBC).

WG 3 is currently investigating the above topic.

~By Fiona Pattinson.