ISO/IEC 27034-6:2016

Information technology - Security techniques - Application security - Part 6: Case studies

ISO/IEC 27034-6:2016 provides usage examples of ASCs for specific applications. NOTE Herein specified ASCs are provided for explanation purposes only and the audience is encouraged to create their own ASCs to assure the application security.

Technologies de l'information — Techniques de sécurité — Sécurité des applications — Partie 6: Études de cas

General Information

• Status: Published
• Publication Date: 04-Oct-2016
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 4 - Security controls and services
• Current Stage: 9093 - International Standard confirmed
• Start Date: 19-May-2022
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 15384:2018 - Protective clothing for firefighters - Laboratory test methods and performance requirements for wildland firefighting clothing
• Effective Date: 06-Jun-2022

Overview

ISO/IEC 27034-6:2016 - part of the ISO/IEC 27034 series on application security - delivers practical case studies and usage examples of Application Security Controls (ASCs). Rather than normative prescriptions, this part provides realistic ASC examples (for instance, a Java mobile application code-review ASC), XML representation examples, and guidance on adapting ASCs to an organization’s context. The standard helps organizations implement the Application Security Framework and Organizational Normative Framework (ONF) described across ISO/IEC 27034.

Key topics and technical highlights

• Application Security Controls (ASCs): focused examples showing how to define, structure and use ASCs to address application-level threats.
• ASC representation: examples use the XML data structure recommended in ISO/IEC 27034-5-1 to enable consistent ASC exchange and implementation.
• Case studies included: Java code revision for mobile apps; privacy requirements spanning two countries; integration and implementation of third‑party ASCs; use of the Application Security Life Cycle Reference Model (ASLCRM); and integrating ASCs into a secure development life cycle (SDLC).
• Application levels of trust and information classification: practical categorization examples (e.g., baseline → private) and how ASC selection maps to those tiers.
• Secure development life cycle phases: mapped ASC activities across preparation, requirements, design, implementation, verification, release and sustainment phases.
• Annex A: informative XML examples supporting the case studies and demonstrating ASC encoding for tool or process integration.
• Audience and role guidance: targeted at domain experts, application security teams, developers, auditors and organizational ONF committees responsible for ASC creation, validation and maintenance.

Practical applications - who uses this standard

• Application security teams and developers: adopt the ASC examples (e.g., code review ASC for Java mobile apps) as starting points for project-level controls.
• Security architects and ONF committees: adapt case-study patterns to build an organizational ASC library and policy mapping.
• Tool vendors and integrators: use the XML examples to support ASC import/export and automation across SDLC tools.
• Auditors and compliance teams: validate that ASCs have been defined and implemented consistently across application lifecycles.

Related standards (if applicable)

• ISO/IEC 27034 series (general framework and other parts) - ISO/IEC 27034-1 (concepts/definitions) and ISO/IEC 27034-5-1 (ASC XML data structure) are specifically referenced in the case-study context.

By providing concrete ASC templates, XML examples and SDLC mappings, ISO/IEC 27034-6:2016 helps organizations translate application-security principles into implementable controls and repeatable processes.

Standards Content (Sample)

DRAFT INTERNATIONAL STANDARD
ISO/IEC DIS 27034-6
ISO/IEC JTC 1/SC 27 Secretariat: DIN
Voting begins on: Voting terminates on:
2015-07-27 2015-10-27
Information technology — Security techniques —
Application security —
Part 6:
Security guidance for specific applications
Technologies de l’information — Techniques de securite — Securite des applications
ICS: 35.040
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/IEC DIS 27034-6:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO/IEC 2015

ISO/IEC DIS 27034-6:2015(E)
© ISO/IEC 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
1 Contents Page
2 INTRODUCTION . VII
3 0.1 GENERAL . VII
4 0.2 PURPOSE . VII
5 0.3 TARGETED AUDIENCES . VII
6 0.3.1 General . vii
7 0.3.2 Domain experts . vii
8 1 SCOPE . 1
9 2 NORMATIVE REFERENCES . 1
10 3 TERMS AND DEFINITIONS . 1
11 4 ABBREVIATED TERMS . 1
12 5 SECURITY GUIDANCE FOR SPECIFIC APPLICATIONS . 2
13 5.1 GENERAL . 2
14 5.2 ASC EXAMPLE: JAVA CODE REVISION FOR MOBILE APPLICATIONS . 2
15 5.2.1 General . 2
16 5.2.2 Purpose . 2
17 5.2.3 Context . 2
18 5.2.4 ORGANIsation Information classification guidelines . 2
19 5.2.5 Levels of trust included in the ORGANIsation ASC Library . 2
20 5.2.6 Outcome . 3
21 5.2.7 ORGANIsation stakeholders involved in these ASCs . 4
22 5.2.8 Descriptions of sample ASCs . 6
23 5.3 CASE STUDY: DEVELOPING ASCS TO ADDRESS THE ISSUE OF PRIVACY FOR TWO COUNTRIES . 16
24 5.3.1 General . 16
25 5.3.2 Purpose . 16
26 5.3.3 Context . 16
27 5.4 CASE STUDY: INTEGRATION OF THIRD-PARTY ASCS . 18
28 5.4.1 General . 18
29 5.4.2 Purpose . 18
30 5.4.3 Context . 18
31 5.5 CASE STUDY: USING THE ASLCRM TO FACILITATE IMPLEMENTATION OF ASCS BY DIFFERENT
32 DEVELOPMENT GROUPS INSIDE AN ORGANIZATION . 20
33 5.5.1 General . 20
34 5.5.2 Purpose . 20
35 5.5.3 Context . 20
36 5.6 CASE STUDY: THIRD PARTY IMPLEMENTATION OF A SECURE DEVELOPMENT LIFE CYCLE PROCESS
37 ASCS . 22
38 5.6.1 General . 22
39 5.6.2 Purpose . 22
40 5.6.3 Context . 23
41 5.6.4 Preparation Phase (1.00) . 23
42 5.6.5 Requirements Phase (2.00) . 26
43 5.6.6 Design Phase (3.00) . 27
44 5.6.7 Implementation Phase (4.00) . 30
45 5.6.8 Verification Phase (5.00) . 33
46 5.6.9 Release Phase (6.00) . 34
47 5.6.10 Sustainment, Support and Servicing Phase (7.00) . 34
48 ANNEX A. XML EXAMPLES FOR CASE STUDIES IN CLAUSE 5.2 . 37
© ISO/IEC 2015 – All rights reserved iii

ISO/IEC DIS 27034-6
1 Figures Page
2 Figure 1 – Integrity scope of stakeholder’s electronic signatures . 5
3 Figure 2 – Code Review ASC graph . 6
5 Tables Page
6 Table 1 – ORGANIsation’s application Levels of Trust . 3
7 Table 2 – ORGANIsation’s ASCs for code review . 3
8 Table 3 – Names and responsibilities of Java Code Review ASCs Stakeholders . 4
9 Table 4 – ORGANIsation’s Level of Trust table . 18
10 Table 5 – Hackus and ORGANIsation’s Level of Trust alignment table . 19
11 Table 6 – ORGANIsation’s ACS for penetration testing . 20
12 Table 7 – ASLCRM activities alingment with ORGANIsation’s existing activities . 22
13 Table 8 – ASLCRM roles alignment with ORGANIsation’s existing roles . 22
14 Table 9 – ASC Activities and outcomes for the preparation phase . 23
15 Table 10 – ASC Activities and outcomes for the Requirements Phase . 27
16 Table 11 – ASC Activities and outcomes for the Design Phase . 28
17 Table 12 – ASC Activities and outcomes for the Implementation Phase . 31
18 Table 13 – ASC Activities and outcomes for the Verification Phase . 33
19 Table 14 – ASC Activities and outcomes for the Release Phase . 34
20 Table 15 – ASC Activities and outcomes for the Support and Servicing Phase . 35
22 Table A.1 – XML example of an ASC name written in three languages . 37
23 Table A.2 – XML example of ASC approvers and their respective signatures subset . 37
24 Table A.3 – XML example of an ASC children definition . 37
25 Table A.4 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Header . 37
26 Table A. 5 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Properties . 37
27 Table A. 6 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Properties. 37
28 Table A. 7 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Security Activity . 37
29 Table A. 8 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Verification
30 Measurement . 38
iv © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
© ISO/IEC 2015 – All rights reserved v

ISO/IEC DIS 27034-6
1 Foreword
2 ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
3 Commission) form the specialized system for worldwide standardization. National bodies that are members of
4 ISO or IEC participate in the development of International Standards through technical committees
5 established by the respective organization to deal with particular fields of technical activity. ISO and IEC
6 technical committees collaborate in fields of mutual interest. Other international organizations, governmental
7 and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
8 technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
9 International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
10 The main task of the joint technical committee is to prepare International Standards. Draft International
11 Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
12 an International Standard requires approval by at least 75 % of the national bodies casting a vote.
13 Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
14 rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
15 ISO/IEC 27034-6 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
16 Subcommittee SC 27, Security techniques.
17 This second/third/. edition cancels and replaces the first/second/. edition (), [clause(s) / subclause(s) /
18 table(s) / figure(s) / annex(es)] of which [has / have] been technically revised.
19 ISO/IEC 27034 consists of the following parts, under the general title Information technology — Security
20 techniques — Application security:
21  Part 1: Overview and concepts
22  Part 2: Organization normative framework
23  Part 3: Application security management process
24  Part 4: Application security validation
25  Part 5: Protocols and application security control data structure
26  Part 5-1: Protocols and application security controls data structure – XML Schemas
27  Part 6: Security guidance for specific application
28  Part 7: Application security assurance prediction
vi © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
1 Introduction
2 0.1 General
3 There is an increasing need for organizations to focus on protecting their information at the application level. A
4 systematic approach towards increasing the level of application security provides an organization with
5 evidence that information being used or stored by its applications is being adequately protected.
6 The ISO/IEC 27034 International Standard provides concepts, principles, frameworks, components and
7 processes to assist organizations in integrating security seamlessly throughout the life cycle of their
8 applications.
9 The Application Security Control (ASC) is one of the key components of this International Standard.
10 To facilitate the implementation of the ISO/IEC 27034 application security framework and the communication
11 and exchange of ASCs, a formal structure should be defined for representing ASCs and certain other
12 components of the framework.
13 0.2 Purpose
14 The purpose of part 6 of the ISO/IEC 27034 is to provide examples of security guidance for organizations to
15 acquire, develop, outsource and manage security for their specific applications through their life cycle.
16 0.3 Targeted Audiences
17 0.3.1 General
18 The following audiences will find values and benefits when carrying their designated organizational roles:
19 a) domain experts.
20 Editors' note: This clause will be aligned with audiences targeted by specific examples that will be included in
21 clause 5.
22 0.3.2 Domain experts
23 Domain experts contributing knowledge in application provisioning, operating or auditing, who need to
24 a) participate in ASC development, validation and verification,
25 b) participate in ASC implementation and maintenance, by proposing strategies, components and
26 implementation processes for adapting ASCs to the organization's context, and
27 c) validate that ASCs are useable and useful in application projects.
© ISO/IEC 2015 – All rights reserved vii

DRAFT INTERNATIONAL STANDARD ISO/IEC DIS 27034-6

1 Information technology — Security techniques —
2 Application security — Part 6: Case studies
3 1 Scope
4 Part 6 of this International Standard provides usage examples of ASCs for specific applications.
5 NOTE: Herein specified ASCs are provided for explanation purposes only, and the audience is encouraged to
6 create their own ASCs to assure the application security.
7 2 Normative references
8 The following documents, in whole or in part, are normatively referenced in this document and are
9 indispensable for its application. For dated references, only the edition cited applies. For undated references,
10 the latest edition of the referenced document (including any amendments) applies.
11 ISO/IEC 27034-1:2011, Information technology — Security techniques — Application security —
12 Part 1: Overview and concepts
13 ISO/IEC 27034-2:– , Information technology — Security techniques — Application security —
14 Part 2: Organization normative framework
15 ISO/IEC 27034-5:– , Information technology — Security techniques — Application security —
16 Part 5: Protocols and application security control data structure
17 ISO/IEC 27034-5-1:– , Information technology — Security techniques — Application security —
18 Part 5-1: Protocols and application security control data structure – XML Schemas
19 3 Terms and definitions
20 For the purposes of this document, the terms and definitions given in ISO/IEC 27034-1 apply.
21 4 Abbreviated terms
22 ASLC Application Security Life Cycle
23 ASLCRM Application Security Life Cycle Reference Model
24 ASC Application Security Control
25 ONF Organization Normative Framework

To be published.
© ISO/IEC 2015 – All rights reserved 1

ISO/IEC DIS 27034-6
1 5 Security guidance for specific applications
2 5.1 General
3 Guidelines play an important role for companies trying to implement any best practice or ISO standard
4 because they instruct how to institutionalize the practices or rules and, sometimes, the guidance is based on
5 common examples.
6 Companies benefit from this guidance as it demonstrates, as a practical example, how to structure ASCs for
7 specific applications using the recommended XML data structure defined in ISO/IEC 27034-5-1 and for the
8 implementation of the Organizational Normative Framework.
9 5.2 ASC example: Java code revision for mobile applications
10 5.2.1 General
11 Code review seams trivial but when an application is built from thousands of lines of code, it may be
12 unproductive and/or too expensive to revise everything.
13 This example presents an ASC designed by a fictive organization called ORGANIsation Inc. This ASC
14 implements the security activity of code review.
15 5.2.2 Purpose
16 The purpose of this clause is to provide an intuitive description of an example ASC named “Code Review” for
17 an organization developing Java mobile applications. For the sake of brevity and readability a simplified
18 subset of the ASC is presented in English only (language="EN"), but the ASC requirements defined in
19 ISO/IEC 27034-5 allows any object in an ASC to be described in any characters sets, as presented by the
20 Table A.1 – XML example of an ASC name written in three languages in Annex A.
21 5.2.3 Context
22 ORGANIsation Inc. is an international organization developing Java mobile applications for its own use and on
23 behalf of its clients. ORGANIsation software development offices are located in Montreal, Vancouver and
24 Moscow. For this reason, ORGANIsation’s policy is that any development documentation, guideline or training
25 should be available in English, French and Russian languages.
26 ORGANIsation’s implementation strategy for ISO/IEC 27034 prioritizes the design of ASCs for reducing
27 security vulnerabilities in Java mobile code. The ORGANIsation ONF committee mandates the Application
28 Security Department (ASD) to design and submit Java code review ASCs.
29 5.2.4 ORGANIsation Information classification guidelines
30 ORGANIsation utilizes approved internal classification guidelines for classifying the information into four
31 levels:
32 a) Restricted
33 b) Confidential
34 c) Secret
35 d) Top Secret
36 5.2.5 Levels of trust included in the ORGANIsation ASC Library
37 ORGANIsation had previously conducted an organization-wide security risk assessment, for the purpose of
38 which it divided its applications into 6 categories according to their impact on organizational risk. Following this,
2 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
1 domain experts mandated by the ONF committee decided to use those six categories as a template for
2 defining ORGANIsation’s application Levels of Trust. An informal definition along with a descriptive label for
3 each Level of Trust is given in Table 1.
4 Table 1 – ORGANIsation’s application Levels of Trust
LoT Name Description
0 Baseline All ORGANIsation’s applications must comply with this Level of Trust.
1 Isolated – Local network only This Level of Trust is appropriate for applications used on isolated
corporate networks, with no connection to external networks.
2 Low – Internet, public This Level of Trust is appropriate for Internet-facing applications
information only sharing public information without any privacy concern.
3 Medium – Internet, corporate This Level of Trust is appropriate for Internet-facing, transactional
users applications used by corporate users, allowing access to corporate
services, user files and/or transactions under 5,000 $.
4 High – Secure transactions This Level of Trust is appropriate for Internet-facing, transactional
and privacy protection over applications, used by corporate users, allowing access to user
Internet. private information and/or transactions from 5,000$ to 25,000$
5 Private This Level of Trust is appropriate for transactional applications
requiring highly secure transactions, privileged access and/or critical
storage security. Access to critical information and/or transactions
over 25,000$ is authorized.
6 5.2.6 Outcome
7 The application security department‘s mandate was to select and acquire an automatic source code review
8 tool suitable for the Java language, with user-configurable review rules. After analysis of vendor propositions,
9 the department selected a tool named “Efficient-Reviewer version 2.2”.
10 At the end of this project, version 1.0 of five ASCs were developed and implemented:
11 Table 2 – ORGANIsation’s ASCs for code review
ID Name Level of Trust Description
ORGANIsation- Code Review Baseline to Private This ASC is used to help developers to
ASD-042 perform a code review control for JAVA
applications.
ORGANIsation- Code Classification Baseline to Private Classify all Java classes in the
ASD-043 packages needed by the application.
Any class should inherit its classification
from the highest-classified information it
processes.
ORGANIsation- Automatic Code Baseline to Low – Internet, This ASC is used to help developers to
public information only
ASD-044 Review Light implement a code review control for
Java applications by providing an
automatic source code security review
process for Java classes classified as
“Strategic” and “Critical”.
ORGANIsation- Automatic Code Medium and Private This ASC is used to help developers to
ASD-045 Review implement a code review control for
Java applications by providing an
automatic source code security review
© ISO/IEC 2015 – All rights reserved 3

ISO/IEC DIS 27034-6
ID Name Level of Trust Description
process for all of the application's Java
classes.
ORGANIsation- Manual Code High and Private This ASC is used to help developers to
ASD-046 Review implement a code review control for
Java applications by providing a manual
source code security review process for
Java classes classified as “Strategic”
and “Critical”.
2 NOTE The ASC with ID “ORGANIsation-ASD-042” is the root of the code-review ASC hierarchy.
3 5.2.7 ORGANIsation stakeholders involved in these ASCs
4 For each of these ASCs, the following responsibilities were determined.
5 NOTE The following clauses consist of informal descriptions of ASC data elements, followed by the formal
6 description of same using XML notation.
8 Table 3 – Names and responsibilities of Java Code Review ASCs Stakeholders
Role / Responsibility Name Notes / ORGANIsation directives
Author Jules Vernes
Owner Douglas Adams • M. Adams requested to start numbering
ORGANIsation’s ASCs from 42.
Creation Request: Herbert George Wells • A PDF version of the creation request, explaining
why this ASC is required by the organization will
be included in each ASC.
• The PGP signature of M. Wells will be required to
seal the ASC.
• The date when this activity will be completed
must be specified.
Design Jules Verne
Validation Arthur C. Clarke
Development Frank Herbert
Verification Ray Bradbury
• The security activity and the measurement and
William Gibson verification activity must both be verified in both
languages.
Approval Robert Heinlein • The PGP signature of M. Heinlein will be required
to seal the ASC.
Final Owner approval Douglas Adams • The PGP signature of the owner is required to
seal the ASC.
Published for training Isaac Asimov
Active Mary Shelley
Expired Not defined.
10 Additional information recorded in each ASC includes coordinates of each actor (department, e-mail address,
11 phone number, physical address), and the completion date for each activity.
4 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
1 The ASC structure allows each version of an ASC to be electronically signed for integrity purposes.
2 ORGANIsation directives in Table 3 specify which electronic signatures are mandatory. This provides
3 assurance that critical stages of the ASC’s life cycle were performed and verified according to
4 ORGANIsation’s policy.
5 In Figure 1, the cloud-shaped region illustrates the part of the ASC protected by electronic signatures.
7 Figure 1 – Integrity scope of stakeholder’s electronic signatures
9 See Table A.2 – XML example of ASC approvers and their respective signatures subsetin Annex A.
10 “ASC ORGANIsation-ASD-042 - Code Review” is a “Head ASC” and does not contain any security activity or
11 verification and measurement activity. Instead, it refers to four children ASCs, which are required to implement
12 code review in the organization’s Java development process. Figure 2 illustrates this concept of ASC
13 hierarchy. It is also to be noted that the “Head ASC” omits some of the mandatory ASC attributes defined by
14 Figure 6 in ISO 27034-1. These will be provided by the child ASCs.
© ISO/IEC 2015 – All rights reserved 5

ISO/IEC DIS 27034-6
2 Figure 2 – Code Review ASC graph
4 See Table A.3 – XML example of an ASC children definition in Annex A.
5 5.2.8 Descriptions of sample ASCs
6 This section describes the head ASC (Code review) and its four children ASCs developed and implemented in
7 the ORGANIsation ASC Library.
8 5.2.8.1 ASC ORGANIsation-ASD-042: Code Review
ASC Code Review
ASC ID ORGANIsation-ASD-042
Header
ASC name Code Review
Version 1.0.0.0
10 See Table A.4 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Header in Annex A.
History (See the ASC history XML example in clause 5.2.7.)
Properties
Description This ASC is used to help developers to perform a code review control for JAVA
applications.
Objective Top-level ASC whose objective is to group the various leaf ASCs related to code
review in Java.
Recommended Baseline to Private
Level of trust
Requirements
addressed
6 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
Children ORGANIsation-ASD-043
ORGANIsation-ASD-044
ORGANIsation-ASD-045
ORGANIsation-ASD-046
2 See Table A. 5 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Properties in Annex A.
Security Activity None.
Verification
None.
Measurement
5 5.2.8.2 ASC ORGANIsation-ASD-043: Code Classification
ASC Code Classification
ASC ID ORGANIsation-ASD-043
Header
ASC name Code Classification
Version 1.0.0.0
History (See the ASC history XML example in clause 5.2.7.)
Properties
Description Classify all Java classes in the packages needed by the application.
Any class should inherit its classification from the highest-classified information it
processes.
Objective Define the scope of the code review.
Recommended Baseline to Private
Level of trust
Requirements ORGANIsation Development guidelines v2.1, Section 5.6 – Application components
addressed classification.
Parents ORGANIsation-ASD-042
9 See Table A. 6 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Properties in Annex
10 A.
Security Activity
Complexity COMPLEX
Who Application Architect
Responsibility Responsible
© ISO/IEC 2015 – All rights reserved 7

ISO/IEC DIS 27034-6
Qualifications
1. Passed an examination on the ORGANIsation coding best practices in Java
required
2. minimum 5 years experience in Java Development
3. Active CSSLP Certification
When AFTER the detailed application architecture is completed.
What Classify the application classes to be developed or maintained in this project.
1. Identify contexts, roles, and information involved with the application module.
2. Realize or update the Application Security Risk Analysis.
3. Classify all classes in the packages needed by the application in the
Application Class Classification section of the Application design document.
Attached files
1. ORGANIsation Development guidelines v2.1.PDF
2. ORGANIsation Code Classification Guide, v1.4.PDF
3. Application Class Classification section – Template v2.3.RTF
Outcomes
1. The section Application Module Classification, in the Application design
document, describing for all application modules, their class classification
value between: “Not critical” to “Critical”.
2. The classification method, templates and examples are described in the
classification Guide, referenced within this ASC.
Estimated effort Average of 60 minutes to classify and document 10 Java classes.
Average of 15 hours to update the Application Security Risk Analysis.
2 See Table A. 7 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Security Activity in
3 Annex A.
Verification
Measurement
Complexity COMPLEX
Who Application Security Architect
Responsibility Accountable and responsible
Qualifications
1. Passed an examination on the ORGANIsation coding Best practices in Java.
required
2. Passed an examination on the secure application architecture.
3. Owned an active CSSLP Certification.
When Before starting the coding.
What Revise and approve section Application Module Classification, in the Application
design document:
1. Validate the contexts, roles and information involved with this module.
2. Revise the application risk analysis.
3. For each class, reject or approve the classification and mark accordingly.
Attached files
1. ORGANIsation Code Classification Guide, v1.4.PDF
8 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
Outcomes
1. An Application security risk analysis document up to date.
2. An approved section Application Module Classification, in the Application
design document.
Estimated effort An average of 6 hours to validate the contexts and revise the risk analysis,
An average of 6 minutes to approve/reject each class.
2 See Table A. 8 – XML example of the ASC ORGANIsation-ASD-043: Code Classification, Verification
3 Measurement in Annex A.
4 5.2.8.3 ASC ORGANIsation-ASD-044: Basic Automatic Code Review
ASC Automatic Code Review
ASC ID ORGANIsation-ASD-044
Header
ASC name Automatic Code Review
Version 1.0.0.0
History (See the ASC history XML example in clause 5.2.7.)
Properties
Description This ASC is used to help developers to implement a code review control for Java
applications by providing an automatic source code security review process for Java
classes classified as “Strategic” and “Critical”.
Objective Defines the activities (and their verification) involved in basic automatic code review.

Recommended Baseline,
Level of trust Low – Local network only, and
Low – Internet, public information only
Requirements Two business requirements are addressed by this ASC.
addressed
1. This control is required to be compliant with PCI-DSS 2.0, section xx.xx.
Parents ORGANIsation-ASD-042
Security Activity
Complexity MEDIUM
Pre-condition The application “Efficient-Reviewer version 2.2” must have been installed and
configured on the user’s station.
Who Developer
Responsibility Responsible
Qualifications 1. More than 3 months experience in Java programming.
required 2. Passed an examination on CR tools utilization.
3. Passed an examination on the ORGANIsation coding best practices in Java.
When BEFORE: Application Layer, Realization stage, Development activity area, Coding
activity, compile code.
© ISO/IEC 2015 – All rights reserved 9

ISO/IEC DIS 27034-6
ASC
Automatic Code Review
ASC ID ORGANIsation-ASD-044
What For all java classes classified as “Strategic” and “Critical”, developed by the developer,
run the security code review tool as a unit test activity.
1. After the developer has completed coding and compiling the class without any
error.
2. Start the security code review tool and load rules file XXXY-053-JAVA
3. Perform the automatic code review.
4. Save the report produced by the code review tool.
5. Analyze the report and correct all “errors” and "warning" detected.
6. Generate a single hash code from the Java code and the produced report
files.
7. Check-in the hash code and the report with the Java code.
Attached files XXXY-053-JAVA.rules
Outcomes 1. A security report without any error or warning.
2. A check-in including the verified code, the report produced by the tool and the
hash code of these two files.
Estimated effort An average of 20 working minutes per class.
Verification
Measurement
Complexity EASY
Pre-condition The application module “Efficient-Reviewer version 2.2 – Hash code validation” must
have been installed configured on the user’s station.
Who Auditor
Responsibility Responsible
Qualifications Should have followed the ORGANIsation components migration training.
required
When BEFORE, Application supply level, Transition stage, Module migration in Test
environment.
10 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
ASC
Automatic Code Review
ASC ID ORGANIsation-ASD-044
What Check the reports produced by the code review tool for all classes that were classified
as “Strategic” and “Critical” for this application project module and migrate them in
"preliminary tests" environment.
With the Code Revision tool " Efficient-Reviewer version 2.2"
1. Identify packages to migrate.
2. For each package
a. Verify that each class has a log report
b. Verify that each log report contains no error or warning
If so
i. Verify that the hash code associated with the package file and
the report file produced with the code revision tool is correct.
ii. If so, set the flag associate with the package file as "Verified" in
the versioning system.
If not
iii. Set the class Flag associate with the package file as "Rejected"
in the versioning system
iv. Send an email to the programmer
3. Are all package files flagged as "Verified”?
If so
a. Migrate the module
b. Send an email to the project manager
If not
a. Cancel the migration
b. Send an email to the project manager
Outcomes List of application project packages in this module, with their updated flag status.
How much Average of 4 hours per migration.
2 5.2.8.4 ASC ORGANIsation-ASD-045: Advanced Automatic Code Review
ASC Automatic Code Review
ASC ID ORGANIsation-ASD-045
Header
ASC name Automatic Code Review
Version 1.0.0.0
History (See the ASC history XML example in clause 5.2.7.)
Properties
Description This ASC is used to help developers to implement a code review control for Java
applications by providing an automatic source code security review process for all of
the application's Java classes.
Objective Defines the activities (and their verification) involved in advanced automatic code
review.
Recommended Medium – Internet, corporate users,
Level of trust High – Secure transactions and privacy protection over Internet, and
Private
Requirements 1. This control is required for compliance with PCI-DSS 2.0, section xx.xx.
addressed
© ISO/IEC 2015 – All rights reserved 11

ISO/IEC DIS 27034-6
ASC
Automatic Code Review
ASC ID ORGANIsation-ASD-045
Parents ORGANIsation-ASD-042
Security Activity
Complexity MEDIUM
Pre-condition Application “Efficient-Reviewer version 2.2” must have been installed and configured
on the user’s station.
Who Developer
Responsibility Responsible
Qualifications 1. More than 3 month experience in Java programming.
required 2. Passed an examination on CR tools utilization.
3. Passed an examination on the ORGANIsation coding best practices in Java.
When BEFORE: Application Layer, Realization stage, Development activity area, Coding
activity, compile code.
What For all Java classes developed by the developer, run the security code review tool, as
a unit test activity.
1. After the developer has completed coding and compiling the class without any
error.
2. Start the security code review tool and load rules file XXXY-053-JAVA
3. Perform the automatic code review.
4. Save the report produced by the code review tool.
5. Analyze the report and correct all “errors” and "warnings" detected.
6. Generate a single hash code from the Java code and the produced report
files.
7. Check-in the hash code and the report with the Java code.
Attached files
1. XXXY-053-JAVA.rules
Outcomes 1. A produced security report without any error or warning.
2. A check-in including the verified code, the report produced by the tool and the
hash code of these two files.
How much An average of 20 minutes per class.
Verification
Measurement
Complexity EASY
Pre-condition The application “Efficient-Reviewer version 2.2 – Hash code validation module” must
have been installed and configured on the user’s station.
Who Auditor
Responsibility Responsible
Qualifications Should have received the ORGANIsation components migration training.
required
When BEFORE, application supply level, Transition stage, Module migration in Tests
environment.
12 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
ASC
Automatic Code Review
ASC ID ORGANIsation-ASD-045
What Check the reports produced by the code review tool for all classes for this application
project module and migrate them in "preliminary tests" environment.
With the Code Revision tool " Efficient-Reviewer version 2.2"
1. Identify packages to migrate.
2. For each package
a. Verify that each class has a log report
b. Verify that each log report contains no error or warning
If so
i. Verify that the hash code associated with the package file and
the report file produced with the code revision tool is correct.
ii. If so, set the flag associate with the package file as "Verified" in
the versioning system.
If not
i. Set the class Flag associate with the package file as "Rejected"
in the versioning system
ii. Send an email to the programmer
3. Are all package files flagged as "Verified”?
If so
a. Migrate the module
b. Send an email to the project manager
If not
a. Cancel the migration
b. Send an email to the project manager
Outcomes List of application project packages in this module, with their updated flag status.
How much Average of 10 hours per migration.
2 5.2.8.5 ASC ORGANIsation-ASD-045: Manual Code Review
ASC
Manual Code Review
ASC ID ORGANIsation-ASD-045
Header
ASC name Manual Code Review
Version 1.0.0.0
History (See clause 5.2.7 in this Annex.)
Properties
Description This ASC is used to help developers to implement a code review control for Java
applications by providing a manual source code security review process for Java
classes classified as “Strategic” and “Critical”.
Objective Defines the activities (and their verification) involved in manual code review.
Recommended
1. High – Secure transactions and privacy protection over Internet, and
Level of trust
2. Private
Requirements This control is required for compliance to the ORGANIsation Critical Application
addressed Security Policy, section 12.6.
Parents ORGANIsation-ASD-042
© ISO/IEC 2015 – All rights reserved 13

ISO/IEC DIS 27034-6
ASC
Manual Code Review
ASC ID ORGANIsation-ASD-045
Security Activity
Complexity DIFFICULT
Pre-condition The last version of the application “PGP Desktop Home” must have been installed and
configured on the user’s workstation.
Who Programmers Team Leader
Responsibility Responsible
Qualifications
1. Passed an examination on the ORGANIsation coding best practices in Java
required
2. minimum 5 years experience in Java development
3. Active CSSLP certification
When AFTER a developer checks a Java module in
What
1. Retrieve the template for the manual code review report (attached to this
ASC).
2. Retrieve the best practice guide for Java secure programming (attached to this
ASC).
3. Identify classes that have been classified
4. For each strategic and critical class:
a. verify that the code conforms with the ORGANIsation Java secure
programming best practices;
b. complete the code review report, using the template;
c. flag class as either “verified” or “rejected”;
d. sign the class and associated report; and
e. check-in the class and associated report.
5. If any class was flagged as “Rejected”,
a. Open correction requests for rejected classes
b. Send a list of rejected classes to the programmer
Attached files
1. Template of manual code review report, v5.6.docx
2. ORGANIsation Java secure programming best practices guide v2012.PDF
Outcomes
1. Checked-in classes, signed by reviewer, with updated status, with code review
report
2. Correction requests
3. List of rejected classes
Estimated effort An average of 14 hours per module.
Verification
Measurement
Complexity MEDIUM
Pre-condition The last version of the application “PGP Desktop Home” must have been installed and
configured on the user’s station.
14 © ISO/IEC 2015 – All rights reserved

ISO/IEC DIS 27034-6
ASC
Manual Code Review
ASC ID ORGANIsation-ASD-045
Who Auditor
Responsibility Responsible
Qualifications
1. Passed an examination on the ORGANIsation coding best practices in Java
required
2. minimum 5 years experience in Java development
3. Active CISA certification
When BEFORE, application supply level, Transition stage, Module migration
...

INTERNATIONAL ISO/IEC
STANDARD 27034-6
First edition
2016-10-01
Information technology — Security
techniques — Application security —
Part 6:
Case studies
Technologies de l’information — Techniques de sécurité — Sécurité
des applications —
Partie 6: Études de cas
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Security guidance for specific applications . 1
5.1 General . 1
5.2 ASC example: Java code revision for mobile applications . 2
5.2.1 General. 2
5.2.2 Purpose . 2
5.2.3 Context . 2
5.2.4 ORGANIsation Information classification guidelines . 2
5.2.5 Levels of trust included in the ORGANIsation ASC Library . 2
5.2.6 Outcome . 3
5.2.7 ORGANIsation stakeholders involved in these ASCs . 4
5.2.8 Descriptions of sample ASCs . 6
5.3 Case study: Developing ASCs to address the issue of privacy for two countries .19
5.3.1 General.19
5.3.2 Purpose .19
5.3.3 Context .19
5.4 Case study: Integration of third-party ASCs .21
5.4.1 General.21
5.4.2 Purpose .21
5.4.3 Context .21
5.5 Case study: Using the ASLCRM to facilitate implementation of ASCs by different
development groups inside an organization .24
5.5.1 General.24
5.5.2 Purpose .24
5.5.3 Context .24
5.6 Case study: Implementation of third-party ASCs in a secure development life
cycle process .26
5.6.1 General.26
5.6.2 Purpose .26
5.6.3 Context .26
5.6.4 Preparation phase (1.00) .27
5.6.5 Requirements phase (2.00) .30
5.6.6 Design phase (3.00) . .31
5.6.7 Implementation phase (4.00) .34
5.6.8 Verification phase (5.00).36
5.6.9 Release phase (6.00).37
5.6.10 Sustainment, support and servicing phase (7.00) .38
Annex A (informative) XML examples for case studies in 5.2 .41
Bibliography .70
© ISO/IEC 2016 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the
Technical Barriers to Trade (TBT) see the following URL: www.iso.org/iso/foreword.html.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 27,
IT Security techniques.
A list of all parts in the ISO/IEC 27034 series can be found on the ISO website.
iv © ISO/IEC 2016 – All rights reserved

Introduction
0.1  General
There is an increasing need for organizations to focus on protecting their information at the application
level. A systematic approach towards increasing the level of application security provides an
organization with evidence that information being used or stored by its applications is being adequately
protected.
ISO/IEC 27034 (all parts) provides concepts, principles, frameworks, components and processes to
assist organizations in integrating security seamlessly throughout the life cycle of their applications.
The application security control (ASC) is one of the key components of this document.
To facilitate the implementation of ISO/IEC 27034 (all parts) application security framework and the
communication and exchange of ASCs, a formal structure should be defined for representing ASCs and
certain other components of the framework.
0.2  Purpose
The purpose of this document is to provide examples of security guidance for organizations to acquire,
develop, outsource and manage security for their specific applications through their life cycle.
0.3  Targeted Audiences
0.3.1  General
The following audiences will find values and benefits when carrying their designated organizational roles:
a) domain experts.
0.3.2  Domain experts
Domain experts contributing knowledge in application provisioning, operating or auditing, who need to
a) participate in ASC development, validation and verification,
b) participate in ASC implementation and maintenance, by proposing strategies, components and
implementation processes for adapting ASCs to the organization’s context, and
c) validate that ASCs are useable and useful in application projects.
© ISO/IEC 2016 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 27034-6:2016(E)
Information technology — Security techniques —
Application security —
Part 6:
Case studies
1 Scope
This document provides usage examples of ASCs for specific applications.
NOTE Herein specified ASCs are provided for explanation purposes only and the audience is encouraged to
create their own ASCs to assure the application security.
2 Normative references
There are no normative references cited in this document.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27034-1 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at http://www.iso.org/obp
4 Abbreviated terms
ASC application security control
ASLC application security life cycle
ASLCRM application security life cycle reference model
ONF organization normative framework
5 Security guidance for specific applications
5.1 General
Guidelines play an important role for companies trying to implement any best practice or ISO standard
because they instruct how to institutionalize the practices or rules and, sometimes, the guidance is
based on common examples.
Companies benefit from this guidance as it demonstrates, as a practical example, how to structure ASCs
for specific applications using the recommended XML data structure defined in ISO/IEC 27034-5-1 and
for the implementation of the Organizational Normative Framework.
© ISO/IEC 2016 – All rights reserved 1

5.2 ASC example: Java code revision for mobile applications
5.2.1 General
Code review seams trivial but when an application is built from thousands of lines of code, it may be
unproductive and/or too expensive to revise everything.
This example presents an ASC designed by a fictive organization called ORGANIsation Inc. This ASC
implements the security activity of code review.
5.2.2 Purpose
The purpose of 5.2 is to provide an intuitive description of an example ASC named “Code Review” for an
organization developing Java mobile applications. For the sake of brevity and readability, a simplified
subset of the ASC is presented in English only (language=”EN”), but the ASC requirements defined in
ISO/IEC 27034-5 allows any object in an ASC to be described in any characters sets, as presented by the
Table A.1.
5.2.3 Context
ORGANIsation Inc. is an international organization developing Java mobile applications for its own
use and on behalf of its clients. ORGANIsation software development offices are located in Montreal,
Vancouver and Moscow. For this reason, ORGANIsation’s policy is that any development documentation,
guideline or training should be available in English, French and Russian languages.
ORGANIsation’s implementation strategy for ISO/IEC 27034 (all parts) prioritizes the design of ASCs for
reducing security vulnerabilities in Java mobile code. The ORGANIsation ONF committee mandates the
Application Security Department (ASD) to design and submit Java code review ASCs.
5.2.4 ORGANIsation Information classification guidelines
ORGANIsation utilizes approved internal classification guidelines for classifying the information into
four levels:
a) restricted;
b) confidential;
c) secret;
d) top secret.
5.2.5 Levels of trust included in the ORGANIsation ASC Library
ORGANIsation had previously conducted an organization-wide security risk assessment, for the purpose
of which it divided its applications into six categories according to their impact on organizational risk.
Following this, domain experts mandated by the ONF committee decided to use those six categories as
a template for defining ORGANIsation’s application levels of trust. An informal definition along with a
descriptive label for each level of trust is given in Table 1.
2 © ISO/IEC 2016 – All rights reserved

Table 1 — ORGANIsation’s application levels of trust
Level of
Name Description
trust
0 Baseline All ORGANIsation’s applications shall comply with this Level of Trust.
1 Isolated — Local network This Level of Trust is appropriate for applications used on isolated
only corporate networks, with no connection to external networks.
2 Low — Internet, public This Level of Trust is appropriate for Internet-facing applications
information only sharing public information without any privacy concern.
3 Medium — Internet, corpo- This Level of Trust is appropriate for Internet-facing, transactional
rate users applications used by corporate users, allowing access to corporate
services, user files and/or transactions under $5 000.
4 High — Secure transactions This Level of Trust is appropriate for Internet-facing, transactional
and privacy protection over applications, used by corporate users, allowing access to user pri-
Internet vate information and/or transactions from $5 000 to $25 000.
5 Private This Level of Trust is appropriate for transactional applications
requiring highly secure transactions, privileged access and/or se-
cure critical storage. Access to critical information and/or transac-
tions over $25 000 is authorized.
5.2.6 Outcome
The application security department was mandate to select and acquire an automatic source code
review tool suitable for the Java language, with user-configurable review rules. After analysis of vendor
propositions, the department selected a tool named “Efficient-Reviewer version 2.2”.
At the end of this project, version 1.0 of five ASCs were developed and implemented.
Table 2 — ORGANIsation’s ASCs for code review
ID Name Level of trust Description
ORGANIsa- Code Review —  Baseline This ASC is used to help developers
tion-ASD-042 to perform a code review control for
—  Isolated – Local network only
JAVA applications.
—  Low – Internet, public
information only
—  Medium – Internet,
corporate users
—  High – Secure transactions and
privacy protection over Internet
—  Private
ORGANIsa- Code Classification —  Baseline Classify all Java classes in the
tion-ASD-043 packages needed by the application.
—  Isolated – Local network only
—  Low – Internet, public Any class should inherit its
information only classification from the highest-classi-
fied information it processes.
—  Medium – Internet,
corporate users
—  High – Secure transactions and
privacy protection over Internet
—  Private
© ISO/IEC 2016 – All rights reserved 3

Table 2 (continued)
ID Name Level of trust Description
ORGANIsa- Basic Automatic —  Baseline This ASC is used to help developers
tion-ASD-044 Code Review to implement a code review control
—  Isolated – Local network only
for Java applications by providing an
automatic
—  Low – Internet, public
source code security review process
information only
for Java classes classified as “Strate-
gic” and “Critical”.
ORGANIsa- Advanced —  Medium – Internet, This ASC is used to help developers
tion-ASD-045 Automatic corporate users to implement a code review control
Code Review for Java applications by providing an
—  High – Secure transactions and
automatic
privacy protection over Internet
source code security review process
—  Private for all of the application’s Java classes.
ORGANIsa- Manual Code —  High – Secure transactions and This ASC is used to help developers
tion-ASD-046 Review privacy protection over Internet to implement a code review control
for Java applications by providing a
—  Private
manual source code security review
process for Java classes classified as
“Strategic” and “Critical”.
NOTE The ASC with ID “ORGANIsation-ASD-042” is the root of the code-review ASC hierarchy.
5.2.7 ORGANIsation stakeholders involved in these ASCs
For each of these ASCs, the following responsibilities were determined.
NOTE This subclause consist consist of informal descriptions of ASC data elements, followed by the formal
description of same using XML notation.
Table 3 — Names and responsibilities of Java code review ASCs stakeholders
Role/responsibility Name Notes/ORGANIsation directives
Author Jules Vernes
Owner Douglas Adams —  M. Adams requested to start numbering
ORGANIsation’s ASCs from 42.
Creation Request: Herbert George Wells —  A PDF version of the creation request, explaining
why this ASC is required by the organization will be
included in each ASC.
—  The PGP signature of M. Wells will be required to
seal the ASC.
—  The date when this activity will be completed
shall be specified.
Design Jules Verne
Validation Arthur C. Clarke
Development Frank Herbert
Verification Ray Bradbury —  The security activity and the measurement and
verification activity shall both be verified in both
William Gibson
languages.
Approval Robert Heinlein —  The PGP signature of M. Heinlein will be required
to seal the ASC.
Final Owner approval Douglas Adams —  The PGP signature of the owner is required to
seal the ASC.
4 © ISO/IEC 2016 – All rights reserved

Table 3 (continued)
Role/responsibility Name Notes/ORGANIsation directives
Published for training Isaac Asimov
Active Mary Shelley
Expired Not defined.
Additional information recorded in each ASC includes coordinates of each actor (department, e-mail
address, phone number, physical address) and the completion date for each activity.
The ASC structure allows each version of an ASC to be electronically signed for integrity purposes.
ORGANIsation directives in Table 3 specify which electronic signatures are mandatory. This provides
assurance that critical stages of the ASC’s life cycle were performed and verified according to
ORGANIsation’s policy.
In Figure 1, the cloud-shaped region illustrates the part of the ASC protected by electronic signatures.
Figure 1 — Integrity scope of stakeholder’s electronic signatures
See Table A.2.
“ASC ORGANIsation-ASD-042 - Code Review” is a “Head ASC” and does not contain any security activity
or verification and measurement activity. Instead, it refers to four children ASCs, which are required to
implement code review in the organization’s Java development process. Figure 2 illustrates this concept
of ASC hierarchy. It is also to be noted that the “Head ASC” omits some of the mandatory ASC attributes
defined by ISO/IEC 27034-1:2011, Figure 6. These will be provided by the child ASCs.
© ISO/IEC 2016 – All rights reserved 5

Figure 2 — Code review ASC graph
See Table A.3.
5.2.8 Descriptions of sample ASCs
5.2.8.1 General
This subclause describes the head ASC (Code review) and its four children ASCs developed and
implemented in the ORGANIsation ASC Library.
5.2.8.2 ASC ORGANIsation-ASD-042: Code review
ASC Code Review
ASC UID ORGANIsation-ASD-042
Identification
ASC UID ORGANIsation-ASD-042
ASC name Code Review
Version 1.3.6.0
Date 2016-01-04
Description This ASC is used to help developers to perform a code review control for JAVA applications.
Author Jules Verne
Application Security Department
ORGANIsation inc.
1234 Street ave W, Beautiful city, Quebec, Canada
Email office: [e-mail]
Phone office: +1.234.567.8901
6 © ISO/IEC 2016 – All rights reserved

Owner Douglas Adams
Application Security Department
ORGANIsation inc.
1234 Street ave W, Beautiful city, Quebec, Canada
Email office: [e-mail]
Phone office: +1.109.876.5432
Parents None
Children ORGANIsation-ASD-043
ORGANIsation-ASD-044
ORGANIsation-ASD-045
ORGANIsation-ASD-046
See Table A.4.
Approval-stages (See the ASC approval-stages XML example in 5.2.7.)
Objective
Objective description Top-level ASC whose objective is to group the various leaf ASCs related to
code review in Java.
Requirements addressed -- Content removed for simplification --
Assigned Levels of trust 0, 1, 2, 3, 4, 5
Context of use Technological context
Levels of trust range Level of Name Description
Trust
0 Baseline All ORGANIsation’s applications shall
comply with this Level of Trust.
1 Isolated – Local This Level of Trust is appropriate for
network only applications used on isolated corporate
networks, with no connection to external
networks.
2 Low – Internet, This Level of Trust is appropriate for
public information Internet-facing applications sharing
only public information without any privacy
concern.
3 Medium – Internet, This Level of Trust is appropriate for
corporate users Internet-facing, transactional applica-
tions used by corporate users, allowing
access to corporate services, user files
and/or transactions under $5 000.
4 High – Secure trans- This Level of Trust is appropriate for In-
actions and privacy ternet-facing, transactional applications,
protection over used by corporate users, allowing access
Internet to user private information and/or trans-
actions from $5 000 to $25 000.
© ISO/IEC 2016 – All rights reserved 7

5 Private This Level of Trust is appropriate for
transactional applications requiring
highly secure transactions, privileged
access and/or secure critical storage.
Access to critical information and/or
transactions over $25 000 is authorized.
(See Table 2)
Pre-conditions -- Content removed for simplification --
See Table A.5.
Security Activity None.
Verification None.
Measurement
5.2.8.3 ASC ORGANIsation-ASD-043: Code classification
ASC Code Classification
ASC ID ORGANIsation-ASD-043
Identification
ASC UID ORGANIsation-ASD-043
ASC name Code Classification
Date 2015-12-25
Description Classify all Java classes in the packages needed by the application.
Any class should inherit its classification from the highest-classified information it
processes.
Version 2.6.1.1
Author -- Content removed for simplification --
Owner -- Content removed for simplification --
Parents ORGANIsation-ASD-042
Children None
Approval-stages (See the ASC approval-stages XML example in 5.2.7.)
Objective
Objective description Define the scope of the code review.
Requirements addressed Business requirements: ORGANIsation Development guidelines v2.1, Section
5.6 – Application components classification.
Assigned Levels of trust 0, 1, 2, 3, 4, 5
Levels of trust range (See Table 2)
Pre-conditions -- Content removed for simplification --
8 © ISO/IEC 2016 – All rights reserved

See Table A.6.
Security activity
Name (what) Classify classes and packages
Description Identify and categorize the application’s Java classes and packages.
Target information Application Data (see ISO/IEC 27034-1:2011, 6.3)
group
Target information Development documentation
sub-group
Target information Application’s Java code architecture
group name
Outcome general Categorized classes and packages information merged in the application’s Java
description code architecture documentation.
Supporting expert Orson Scott Card
ressource
ORGANIsation inc.
Email: [e-mail]
Complexity COMPLEX
Complexity description This activity should be performed by someone able to identify, from the appli-
cation architecture documents, what information is manipulated by each Java
class and to identify security risks that may threaten sensitive information.
Global estimated —  Average of 1 h to classify and document 10 Java classes.
effort (how much)
—  Average of 15 h to update the Application Security Risk Analysis.
Role (who) APPLICATION ARCHITECT
Responsibility RESPONSIBLE
Required qualifications  1.  Passed an examination on the ORGANIsation Java coding best practices.
2.  Minimum 5 years experience in Java Development.
3.  Active CSSLP Certification.
Pre-condition —  The application classes and packages identification section of the Applica-
tion design document is completed.
—  A list of categorized information groups involved by the application al-
ready exists.
Security activity Classify the application classes to be developed or maintained in this project.
description (how)
1.  Identify contexts, roles, and information involved with the application
module. Ref.: ORGANIsation Development guidelines v2.1.
2.  Realize or update the Application Security Risk Analysis.
3.  Classify all classes in the packages needed by the application in the Ap-
plication Class Classification section of the Application design document. Ref.:
ORGANIsation Code Classification Guide, v1.4, and Application Class Classifica-
tion section – Template v2.3.
Localization (where) —  Application development environment
© ISO/IEC 2016 – All rights reserved 9

Moment (when) AFTER: The detailed application architecture is completed.
Supporting documents  1.  ORGANIsation Development guidelines v2.1.PDF.
2.  ORGANIsation Code Classification Guide, v1.4.PDF.
3.  Application Class Classification section – Template v2.3.RTF.
Artefacts (what)  1.  Document: The Application Module Classification section, in the Applica-
tion design document, describing for all application modules, their class classi-
fication value from “Not critical” to “Critical”.
2.  Document: The classification method, templates and examples are de-
scribed in the classification Guide, referenced within this ASC.
See Table A.7.
Verification
measurement
Name (what) Classes and packages classification verification.
Description Verify if the application’s Java classes and packages produced or modified were
adequatly categorized.
Target information Application Data (See ISO/IEC 27034-1:2011, 6.3)
group
Target information Application development documentation
sub-group
Target information Application’s Java code architecture
group name
Outcome general These two documents are produced or updated: the Application security risk
description analysis and the Application design document.
Supporting expert Ray Bradbury
ressource
Email: Ray.Bradbury @ORGANIsation.com
Complexity COMPLEX
Complexity description This activity should be done by someone who is able to validate, from applicaton
architecture documents, what information is manipulated in every Java classes
and to validate security risks that may threaten sensitive information.
Global estimated —  An average of 6 h to validate the contexts and revise the risk analysis and
effort (how much) an average of 10 min to approve/reject each class and package.
—  Around 12 h/project.
Activity specification —  Classify application’s classes and components.
Ref.: ORGANIsation Code Classification Guide, v1.4
Role (who) APPLICATION SECURITY ARCHITECT
Responsibility ACCOUNTABLE and RESPONSIBLE
Qualifications required  1.  Passed an examination on the ORGANIsation Java coding best practices.
2.  Passed an examination on the secure application architecture.
3.  Active CSSLP Certification.
Pre-condition —  The Application’s Java code architecture documentation includes a complete
categorized classes and packages information.
10 © ISO/IEC 2016 – All rights reserved

Verification- Revise and approve Application Module Classification section, in the Application
measurement design document:
activity
1.  validate the contexts, roles and information involved with this module;
description (how)
2.  revise the application risk analysis;
3.  for each class, reject or approve the classification and mark accordingly.
Localization (where) —  Application development environment
Moment (when) Before coding.
Supporting documents  1.  ORGANIsation Code Classification Guide, v1.4.PDF
Artefacts (what)  1.  Updated Application security risk analysis document.
2.  Approved Application Module Classification section, in the Application
design document.
See Table A.8.
5.2.8.4 ASC ORGANIsation-ASD-044: Basic automatic code review
ASC Basic Automatic Code Review
ASC ID ORGANIsation-ASD-044
Identification
ASC UID ORGANIsation-ASD-044
ASC name Basic Automatic Code Review
Version 1.3.0.0
Date 2015-12-25
Description This ASC is used to help developers to implement a code review control
for Java applications by providing an automatic source code security re-
view process for Java classes classified as “Strategic” and “Critical”.
Author -- Content removed for simplification --
Owner -- Content removed for simplification --
Parents ORGANIsation-ASD-042
Children None
Approval-stages (See the ASC approval-stages XML example in 5.2.7.)
Objective
Objective description Defines the activities (and their verification) involved in basic automatic
code review.
Requirements addressed  1.  This control is required for compliance with PCI-DSS 2.0, section xx.xx.
Assigned Levels of trust 0, 1, 2
Context of use Technological context
Levels of trust range (See Table 2)
Pre-conditions Java classes in the packages needed by the application are categorized.
Security Activity
Name (what) Automatic code review (basic)
Description Run an automatic code review only on Java classes classified as “Strate-
gic” and “Critical”.
Target information group Application data
Target information Source code
sub-group
© ISO/IEC 2016 – All rights reserved 11

Target information group Java class and packages
name
Outcome general Code review reports produced by the tool.
description
Supporting expert Team leader
ressource
Complexity MEDIUM
Complexity description The developer shall verify the version of the rules file loaded in the tool
before running the automatic review on the Java code.
Global estimated effort An average of 20 min per class.
(how much)
Role (who) DEVELOPER
Responsibility RESPONSIBLE
Required qualifications  1.  More than 3 months experience in Java programming.
2.  Passed an examination on CR tools utilization.
3.  Passed an examination on the ORGANIsation Java coding best
practices.
Pre-condition The application “Efficient-Reviewer version 2.2” is installed and config-
ured on the user’s station.
Security activity For all java classes classified as “Strategic” and “Critical”, developed by
description (how) the developer, run the security code review tool as a unit test activity.
1.  After the developer has completed coding and compiling the class
without any error.
2.  Start the security code review tool and load rules file XXXY-053-JAVA.
3.  Perform the automatic code review.
4.  Save the report produced by the code review tool.
5.  Analyze the report and correct all errors and warnings detected.
6.  Generate a single hash code from the Java code and the produced
report files.
7.  Check-in the hash code and the report with the Java code.
Localization (where) Developper workstation
Moment (when) BEFORE: APPLICATION LAYER, REALIZATION STAGE, DEVELOPMENT
ACTIVITY AREA, CODING ACTIVITY, COMPILE CODE.
Supporting documents  1.  File: XXXY-053-JAVA.rules
Artefacts (what)  1.  A security report without any error or warning.
2.  A check-in including the verified code, the report produced by the
tool and the hash code of these two files.
Verification Measurement
Name (what) Basic automatic code review verification
Description Check the reports produced by the code review tool for all classes that were
classified as “Strategic” and “Critical” for this application project module
Target information group Application data
Target information Source code
sub-group
Target information group Signed Java class and packages
name
Verification tools report
12 © ISO/IEC 2016 – All rights reserved

Target information group Once the code review is completed, the tool will sign the source code and
description save the signature in the report. The source code file, the report and the
signature will have to be verified.
Outcome general Target code modules are verified or rejected. When verified, they are
description
migrated to the “preliminary tests” environment.
Supporting expert res- Team leader
source
Complexity EASY
Complexity description Make sure the tool report is in the same folder of its related source code
before starting the verification.
Global estimated effort Average of 4 h per migration.
(how much)
Role (who) AUDITOR
Responsibility RESPONSIBLE
Required qualifications Should have followed the ORGANIsation components migration training.
Pre-condition The application module “Efficient-Reviewer version 2.2 – Hash code
validation” shall have been installed configured on the source code server
for the project.
Security activity description Check the reports produced by the code review tool for all classes that
(how) were classified as “Strategic” and “Critical” for this application project
module and migrate them in “preliminary tests” environment.
With the Code Revision tool “Efficient-Reviewer version 2.2”
1.  Identify packages to migrate.
2.  For each package
a.  verify that each class has a log report, and
b.  verify that each log report contains no error or warning.
If so,
i.  Verify that the hash code associated with the package file and the
report file produced with the code revision tool is correct.
ii.  If so, set the flag associate with the package file as “Verified” in
the versioning system.
If not,
iii.  Set the class Flag associate with the package file as “Rejected” in
the versioning system.
iv.  Send an email to the programmer.
3.  Are all package files flagged as “Verified”?
If so,
a.  Migrate the module, and
b.  Send an email to the project manager.
If not,
a.  Cancel the migration, and
b.  Send an email to the project manager.
Localization (where) Development environment, project source code server
Moment (when) BEFORE, APPLICATION SUPPLY LEVEL, TRANSITION STAGE, MODULE
MIGRATION IN TEST ENVIRONMENT.
Artefacts (what) List of application project packages in this module, with their updated
flag status.
© ISO/IEC 2016 – All rights reserved 13

5.2.8.5 ASC ORGANIsation-ASD-045: Advanced Automatic Code Review
ASC Advanced Automatic Code Review
ASC ID ORGANIsation-ASD-045
Identification
ASC UID ORGANIsation-ASD-045
ASC name Advanced Automatic Code Review
Date 2015-12-25
Description This ASC is used to help developers to implement a code review control for Java
applications by providing an automatic source code security review process for
all of the application’s Java classes.
Version 1.0.0.0
Author -- Content removed for simplification --
Owner -- Content removed for simplification --
Parents ORGANIsation-ASD-042
Children None
Approval-stages (See the ASC approval-stages XML example in 5.2.7.)
Objective
Objective description Defines the activities (and their verification) involved in advanced automatic
code review.
Requirements addressed This control is required for compliance with PCI-DSS 2.0, section xx.xx.
Assigned Levels of trust 3, 4, 5
Levels of trust range (See Table 2)
Pre-conditions Java classes in the packages needed by the application were classified.
Security Activity
Name (what) Automatic Code Review (advanced)
Description Run a full automatic code review on all Java classes written by the developer.
Target information Application data
group
Target information Source code
sub-group
Target information Java class and packages
group name
Outcome general Code review reports produced by the tool.
description
Supporting expert Team leader
ressource
Complexity MEDIUM
Complexity description The developer shall verify the version of the rules file loaded in the tool before
running the automatic review on the Java code.
Global estimated effort An average of 20 min per class.
(how much)
Role (who) DEVELOPER
Responsibility RESPONSIBLE
Required qualifications  1.  More than 3 months experience in Java programming.
2.  Passed an examination on CR tools utilization.
3.  Passed an examination on the ORGANIsation Java coding best practices.
14 © ISO/IEC 2016 – All rights reserved

Pre-condition Application “Efficient-Reviewer version 2.2” is installed and configured on the
user’s station.
Security activity For all Java classes developed by the developer, run the security code review
description (how) tool, as a unit test activity.
1.  After the developer has completed coding and compiling the class without
any error.
2.  Start the security code review tool and load rules file XXXY-053-JAVA.
3.  Perform the automatic code review.
4.  Save the report produced by the code review tool.
5.  Analyze the report and correct all errors and warnings detected.
6.  Generate a single hash code from the Java code and the produced report files.
7.  Check-in the hash code and the report with the Java code.
Localization (where) Developper’s workstation
Moment (when) BEFORE: APPLICATION LAYER, REALIZATION STAGE, DEVELOPMENT ACTIVITY
AREA, CODING ACTIVITY, COMPILE CODE.
Supporting documents  1.  File: XXXY-053-JAVA.rules
Artefacts (what  1.  A produced security report without any error or warning.
outcomes)
2.  A check-in including the verified code, the report produced by the tool and
the hash code of these two files.
Verification
Measurement
Name (what) Advanced automatic code review verification
Description Check the reports produced by the code review tool for all classes that were
classified as “Strategic” and “Critical” for this application project module
Target information Application data
group
Target information Application data
group name
Target information Source code
sub-group
Target information Signed Java class and packages
group description
Verification tools report
Target information Once the code review is completed, the tool will singed the source code and save
group classification the signature in the report. The source code file, the report and the signature
will have to be verified.
Outcome general Target code modules are verified or rejected. When verified, they are migrated
description to the “preliminary tests” environment.
Supporting expert Team leader
ressource
Complexity EASY
Complexity description Make sure the tool report is in the same folder as its related source code before
starting the verification.
Global estimated effort Average of 10 h per migration.
(how much)
Role (who) AUDITOR
Responsibility RESPONSIBLE
Required qualifications Should have received the ORGANIsation components migration training.
© ISO/IEC 2016 – All rights reserved 15

Pre-condition The application “Efficient-Reviewer version 2.2 – Hash code validation module”
is installed and configured on the user’s station.
Security activity Check the reports produced by the code review tool for all classes for this ap-
description (how) plication project module and migrate them in “preliminary tests” environment.
With the Code Revision tool “ Efficient-Reviewer version 2.2”
...