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
• Completion Date: 19-May-2022

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

Standards Content (Sample)

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 27034-6:2016(E)
©
ISO/IEC 2016

---------------------- Page: 1 ----------------------
ISO/IEC 27034-6:2016(E)

COPYRIGHT PROTECTED DOCUMENT
© 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

---------------------- Page: 2 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 3 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 4 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 5 ----------------------
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

---------------------- Page: 6 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 7 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 8 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 9 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 10 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 11 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 12 ----------------------
ISO/IEC 27034-6:2016(E)

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

---------------------- Page: 13 ----------------------
ISO/IEC 27034-6:2016(E)

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-
pl
...

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

---------------------- Page: 1 ----------------------
ISO/IEC DIS 27034-6:2015(E)

COPYRIGHT PROTECTED DOCUMENT
© 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

---------------------- Page: 2 ----------------------
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
49
© ISO/IEC 2015 – All rights reserved iii

---------------------- Page: 3 ----------------------
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
4
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
21
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

---------------------- Page: 4 ----------------------
ISO/IEC DIS 27034-6
1
© ISO/IEC 2015 – All rights reserved v

---------------------- Page: 5 ----------------------
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
29
vi © ISO/IEC 2015 – All rights reserved

---------------------- Page: 6 ----------------------
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.
28
© ISO/IEC 2015 – All rights reserved vii

---------------------- Page: 7 ----------------------
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
1
13 ISO/IEC 27034-2:– , Information technology — Security techniques — Application security —
14 Part 2: Organization normative framework
1
15 ISO/IEC 27034-5:– , Information technology — Security techniques — Application security —
16 Part 5: Protocols and application security control data structure
1
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

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

---------------------- Page: 8 ----------------------
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

---------------------- Page: 9 ----------------------
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.
5
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

---------------------- Page: 10 ----------------------
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”.
1
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.
7
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.
9
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

---------------------- Page: 11 ----------------------
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.
6
7 Figure 1 – Integrity scope of stakeholder’s electronic signatures
8
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.
15
© ISO/IEC 2015 – All rights reserved 5

---------------------- Page: 12 ----------------------
ISO/IEC DIS 27034-6
1
2 Figure 2 – Code Review ASC graph
3
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
9
10 See Table A.4 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Header in Annex A.
11
History (See the ASC history XML example in clause 5.2.7.)
12
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

---------------------- Page: 13 ----------------------
ISO/IEC DIS 27034-6
Children ORGANIsation-ASD-043
ORGANIsation-ASD-044
ORGANIsation-ASD-045
ORGANIsation-ASD-046
1
2 See Table A. 5 – XML example of the ASC ORGANIsation-ASD-042: Code Review, Properties in Annex A.
3
Security Activity None.
Verification
None.
Measurement
4
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
6
History (See the ASC history XML example in clause 5.2.7.)
7
Properties
Description Classify all Java classes in the packages needed by the application.
Any class
...