ISO/IEC TS 27034-5-1:2018

Information technology - Application security - Part 5-1: Protocols and application security controls data structure, XML schemas

ISO/IEC TS 27034-5-1:2018 defines XML Schemas that implement the minimal set of information requirements and essential attributes of ASCs and the activities and roles of the Application Security Life Cycle Reference Model (ASLCRM) from ISO/IEC 27034-5.

Technologies de l'information — Sécurité des applications — Partie 5-1: Protocoles et structure de données de contrôles de sécurité d'application, schémas XML

General Information

• Status: Published
• Publication Date: 06-May-2018
• 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: 9060 - Close of review
• Completion Date: 03-Jun-2028

Overview

ISO/IEC TS 27034-5-1:2018 - "Information technology - Application security - Part 5-1: Protocols and application security controls data structure, XML schemas" - is a Technical Specification that defines an XML Schema implementation of the minimal information requirements and essential attributes for Application Security Controls (ASCs). It maps ASC metadata and the activities/roles of the Application Security Life Cycle Reference Model (ASLCRM) from ISO/IEC 27034‑5 into a standardized, platform-independent XML data model to support exchange, tooling and integration.

Key Topics

• XML Schema for ASCs: authoritative XML binding for ASC data model; all elements reside in the asc namespace and are schema-qualified. The official schema source is available from ISO.
• ASC data model & package: top-level element <asc:asc-package> bundles one or more ASCs for convenient exchange. Package content includes metadata (uid, date, version-number, name, objective, description, editors) and optional digital signatures.
• Global design decisions:
  • Use of XML/XML Schema for platform independence.
  • Support for grouping related ASCs into an ASC package.
  • Inclusion mechanism for Levels of Trust so ASCs are self-contained.
• Core elements and types: the schema refines ASC elements top-down (package → ASC → identification → objectives → activities, actors, information), and defines complex types for activity, actor and information elements consistent with ASLCRM.
• Interoperability and validation: schema version attributes (e.g., xml-asc-package-schema-version and xml-asc-schema-version) and namespace URIs help implementers decide document compatibility and validate ASC payloads.

Applications

ISO/IEC TS 27034-5-1 is practical for organizations and tool vendors who need a standardized exchange format for application-level security artifacts:

• Tool vendors & ASC suppliers: create, validate, sign and distribute ASCs and integrate ASC libraries into development/security tooling.
• Acquirers & integrators: import third‑party ASCs, map ASC activities to internal application lifecycles and ensure interoperability.
• ONF committees & managers: manage ASC libraries in the Organization Normative Framework (ONF), approve ASCs and ensure reusability across projects.
• Security architects & domain experts: define, validate and adapt ASC objectives, activities and actors to the organization’s context.

Practical benefits include streamlined ASC exchange, consistent metadata for ASC lifecycle management, and a machine-readable standard for automation (validation, signing, tool integration).

Related Standards

• ISO/IEC 27034-1 - Overview and concepts for application security.
• ISO/IEC 27034-5 - Protocols and ASC data structure (conceptual model that 27034-5-1 implements in XML).
• References: ISO schema files and namespace URIs cited in the specification for implementers.

Keywords: ISO/IEC TS 27034-5-1, application security, XML schema, Application Security Control (ASC), ASC package, ASLCRM, ASC data model, Organization Normative Framework (ONF).

Standards Content (Sample)

TECHNICAL ISO/IEC TS
SPECIFICATION 27034-5-1
First edition
2018-04
Information technology — Application
security —
Part 5-1:
Protocols and application security
controls data structure, XML schemas
Technologies de l'information — Sécurité des applications —
Partie 5-1: Protocoles et structure de données de contrôles de sécurité
d'application, schémas XML
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – 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 XML Schema for ASCs . 2
5.1 General . 2
5.2 Global design decisions . 2
5.3 General XML Information . 2
5.4 ASC Data Model Definition . 3
5.4.1 General. 3
5.4.2 ASC Package . 3
5.4.3 ASC Element . 8
5.4.4 ASC Identification .12
5.4.5 ASC Objective .16
5.4.6 ASC Security activity and Verification measurement .21
5.4.7 Complex type asc:activity .21
5.4.8 Complex type asc:actor .37
5.4.9 Complex type asc:information .40
5.4.10 Complex type asc:ASLCRM_activity-name .42
5.4.11 Enumeration types .55
© ISO/IEC 2018 – 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 voluntary nature of standards, 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.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee 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 2018 – 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 ISO/IEC 27034 (all parts). To
facilitate the implementation of the ISO/IEC 27034 (all parts) application security framework and the
communication and exchange of ASCs, a formally defined exchange format is required.
This documents is a Technical Specification document and defines XML Schemas of essential attributes
of ASCs and further details the Application Security Life Cycle Reference Model.
0.2  Purpose
The purpose of this document is to define XML schemas that implement the essential information and
data structure requirements for ASCs as well as the Application Security Lifecycle Reference Model
(ASLCRM). The advantages of a standardized set of essential information attributes and data structure
of ASCs include the following:
a) facilitate the exchange of application security controls (ASCs);
b) provide a formally defined reference model for tool vendors, ASC suppliers and acquirers.
0.3  Targeted audiences
0.3.1  General
The following audiences will find values and benefits when carrying their designated organizational roles:
a) managers;
b) ONF committee;
c) domain experts;
d) suppliers;
e) acquirers.
0.3.2 Managers
Managers should read this document because they are responsible for:
a) ensuring the ASCs are reusable within the organization; and
b) ensuring the ASCs are available, communicated and used in application projects with proper tools
and procedures all across the organization.
0.3.3  ONF Committee
The ONF Committee is responsible for managing the implementation and maintenance of the
application-security-related components and processes in the Organization Normative Framework.
The ONF Committee needs to:
a) implement the ASC Library;
© ISO/IEC 2018 – All rights reserved v

b) approve ASCs that correctly mitigate application security risks; and
c) manage the cost of implementing and maintaining the ASCs.
0.3.4  Domain experts
Domain experts contribute 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.
0.3.5  ASC suppliers
Suppliers contribute to develop, maintain and distribute tools and/or ASCs. They need to:
a) create, validate, sign, distribute and apply ASCs; and
b) be aligned with a common and standardized exchange protocol (structure and format) for ASCs.
0.3.6  ASC acquirers
Acquires are individuals or organizations who want to acquire ASCs. They need to:
a) integrate ASCs into their organization and ensure the interoperability of any internal and third-
party ASCs;
b) adapt and sign ASCs to enforce their integrity; and
c) ensure that the activities and tasks of acquired ASCs can be mapped to the organization’s
application lifecycle.
vi © ISO/IEC 2018 – All rights reserved

TECHNICAL SPECIFICATION ISO/IEC TS 27034-5-1:2018(E)
Information technology — Application security —
Part 5-1:
Protocols and application security controls data structure,
XML schemas
1 Scope
This document defines XML Schemas that implement the minimal set of information requirements and
essential attributes of ASCs and the activities and roles of the Application Security Life Cycle Reference
Model (ASLCRM) from ISO/IEC 27034-5.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 27034-1, Information technology — Security techniques — Application security — Part 1:
Overview and concepts
ISO/IEC 27034-5, Information technology — Security techniques — Application security — Part 5:
Protocols and application security control data structure
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 27034-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
activity
set of actions or tasks carried out by an actor during the application’s lifecycle
4 Abbreviated terms
ASC Application Security Control
ASLC Application Security Life Cycle
ASLCRM Application Security Life Cycle Reference Model
ICT Information and Communication Technology
ONF Organization Normative Framework
© ISO/IEC 2018 – All rights reserved 1

5 XML Schema for ASCs
5.1 General
The purpose of Clause 5 is to define an XML implementation of the information requirements and essential
attributes for ASC identified in ISO 27045-5. The schema source file can be downloaded from ISO.
5.2 Global design decisions
In line with the objectives and requirements defined in ISO/IEC 27034-5, the following high-level design
decisions for this implementation of the ASC data model were taken:
a) XML and XML schema: ASCs are defined in the platform-independent extensible markup language
(XML). Consequently, the data model for ASCs is defined in the form of an XML schema;
b) ASC package: The data model provides a mechanism for grouping and bundling one or many
related ASCs in form of an ASC package. This allows for the convenient exchange of related ASCs;
c) Level of Trust inclusion: Each ASC should refer to one or more levels of trust. In order to keep
the ASC self-contained the data model is designed to also include the actual definition of the levels
of trust.
5.3 General XML Information
All XML elements defined by the XML Schema for the ASC data model are part of “asc” namespace and
shall be qualified by asc. The namespace URI for this specification should be “http: //standards .iso
.org/iso -iec/ts/27034/5 -1/ed -1/en”. Applications that process ASCs should use the namespace URI to
decide whether or not they can process a given document. The XML schema implementation defined in
this subclause should be the authoritative XML binding definition for ASCs.
Table 1 — ASC Data Model — Namespace and Schema Import Definition


xmlns:asc="http://iso.org/ISO27034/ASC-structure"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:aslcrm="http://iso.org/ISO27034ASLCRM"
targetNamespace="http://iso.org/ISO27034/ASC-structure"
elementFormDefault="qualified"
attributeFormDefault="qualified"
version="1.0RC">
...

NOTE 1 ASC developers align their vocabulary with ISO/IEC 19770 (all parts) when they need to describe assets.
NOTE 2 Explicit indication of an inheritance hierarchy is not implemented in the ASC structure, but can be
implemented in future versions.
2 © ISO/IEC 2018 – All rights reserved

5.4 ASC Data Model Definition
5.4.1 General
The purpose of 5.4 is to present an overview of all structural elements defined by the XML schema for
the ASC structure. The elements are presented in a top-down manner where high-level elements are
successively refined into lower-level elements. All XML elements defined in this XML Schema are part of
the “asc” namespace and shall be qualified by asc:
5.4.2 ASC Package
5.4.2.1 General
Figure 1 — ASC Package
The top-level element mechanism for grouping and bundling one or many
related ASCs in form of an ASC package (Figure 1). This allows for the convenient exchange of related
ASCs. It consists of the following sub-elements:
a) is actual payload of the package. It consists of package meta-data
and one or more ASCs ;
© ISO/IEC 2018 – All rights reserved 3

b) optionally contains digital signatures to validate
the source and integrity of the entire package.
NOTE The ASC package object and the ASC object both have a schema version number value defined in the
XML-Schema used to identify their data structure. It consists of the following attributes:
a) ; and
b) .
Table 2 shows the implementation of the element in the XML Schema.
Table 2 — element













type="xs:string" minOccurs="0">



type="asc:information" minOccurs="0">

type="asc:information" minOccurs="0">

minOccurs="0" maxOccurs="unbounded">
4 © ISO/IEC 2018 – All rights reserved

Table 2 (continued)












maxOccurs="unbounded">







default="1.0.0.0">



5.4.2.2 ASC Package Content
The elements consists of meta-data information about its contents and
one more more ASCs. It consists of the following sub-elements.
a) defines meta-date information about the package contents
such uid, date, version, name, objective, description and editor;
b) defines a particular ASC. Each ASC package is required to have one or more
elements.
Table 3 shows the implementation of the element in the XML Schema.
© ISO/IEC 2018 – All rights reserved 5

Table 3 — element










minOccurs="0">



minOccurs="0">

minOccurs="0">

maxOccurs="unbounded">









5.4.2.3 ASC Package identification
The element contains meta-data information about the ASC
package. It consists of the following elements:
a) is a unique identifier of the ASC package;
b) is the date the package was created (combined date and time in UTC following
ISO 8601);
c) optionally denotes the version of the package;
6 © ISO/IEC 2018 – All rights reserved

d) is the name of the package. This element has the custom type asc:information
(defined in 5.4.9) used to specify the localization (i.e. language, area, organization) of the
information contained by this element;
e) optionally describes the objective or theme of the package;
f) optionally provides an informal (localized) description of the package;
g) optionally defines the editor of the package. This element has the custom type
asc:actor (defined in 5.4.8) used to specify the name and coordinates of the author.
Table 3 shows the implementation of the element in the XML Schema.
5.4.2.4 ASC Package e-signature
The element contains digital signatures of the
element. Each digital signature consists of one or more e-signature
parameters and the actual e-signature.
a) defines relevant parameters about the e-signature such as signature
algorithm, key size, hashing algorithm and the public key used to validate the signature; and
b) contains the actual digital signature of the asc-package.
Table 4 shows the implementation of the element in the
XML Schema.
Table 4 — element



maxOccurs="unbounded">






© ISO/IEC 2018 – All rights reserved 7

5.4.3 ASC Element
5.4.3.1 General
Figure 2 — ASC Top Level Structure
The element holds all information pertinent to one application security control (ASC). The
element contains the attribute xml-asc-schema-version. It identifies the version of
the XML schema the (instance) XML document is compatible with. It also contains the following two
sub-elements:
a) contains the actual ASC information contents;
b) optionally contains the actual digital signature and related
information to clarify and to protect the ASC contents.
5.4.3.2 ASC Content
The element defines the actual ASC (see Figure 2). It consists of the following
elements:
a) defines information related to the identity of the ASC such as uid, name,
version, date, author and owner (defined in 5.4.4);
b) defines key attributes including description, addressed security requirements,
assigned levels of trust, relationships to other ASCs, etc (defined in 5.4.5);
c) defines the activity that needs to be carried out to address the security
requirements associated with the ASC. High-level ASCs may not explicitly define a security activity.
In such a case the definition of the activity is deferred to a lower-level ASC. The activity> element is assigned the complex type asc:activity (defined in 5.4.7);
8 © ISO/IEC 2018 – All rights reserved

d) defines the activity that needs to be carried out to verify
the security activity. High-level ASCs may not explicitly define a verification measurement. In such
a case the definition of the activity is deferred to a lower-level ASC. The measurement> is assigned the complex type asc:activity (defined in 5.4.7).
Table 5 shows the implementation of the element in the XML Schema.
Table 5 — element




...


...


...


...




5.4.3.3 ASC approval-e-signatures
The element contains the digital signature of the
which can be signed at different ASC life-cycle stages (e.g., design,
development, verification, final approval, etc). For each signed stage, a separate signature is provided
(see Figure 2). Therefore the element consists of one ore more elements —
each contains the signature for one particular ASC lifecycle stage and consists of the following elements:
a) denotes the date when the ASC was signed;
b) denotes the lifecycle stage of the ASC for which the signature
was generated. It is assigned the custom enumeration type asc:life-cycle-stage (defined in
5.4.11);
c) contains information about the actor that has approved and signed the ASC.
This element has the custom type asc:actor (defined in 5.4.8) used to specify the name and
coordinates of the author;
d) optionally contains optional additional information provided by the
approver of the ASC;
© ISO/IEC 2018 – All rights reserved 9

e) optionally contains the actual digital signature of the ASC
contents.Similar to the e-signature at package level, it consists of the following sub-elements:
1) defines relevant parameters about the e-signature such
as signature algorithm, key size, hashing algorithm and the public key used to validate the
signature;
2) contains the actual digital signature of the asc-package.
Table 6 shows the implementation of the element in the
XML Schema.
10 © ISO/IEC 2018 – All rights reserved

Table 6 — element


Optionally contains the actual digital signature
of the ASC contents.







type="asc:life-cycle-stage"/>

minOccurs="0"/>
type="asc:information" minOccurs="0"/>



type="xs:string" maxOccurs="unbounded"/>
type="xs:string"/>









© ISO/IEC 2018 – All rights reserved 11

5.4.4 ASC Identification
Figure 3 — ASC Identification
The element defines global aspects for one ASC. It contains the following
subelements in sequential order:
a) assigns a unique identifier to the ASC;
b) denotes the name of the ASC;
c) provides a high-level qualitative and localized description of this ASC
purpose;
12 © ISO/IEC 2018 – All rights reserved

d) data structure including:
1) assigns a version number to the ASC using legal
numbering (encoded as xs:string). The most recent ASC version shall be assigned the
highest version number;
2) required to define the creation date
of the ASC version;
3) use="required"> used to identify the current ASC's stage within its life cycle, such as:
Development, Verification, Approval, Published for training, or Active;
4) minOccurs="0"> used to provide a maturity level indication of this version;
5) minOccurs="0"> used to provide a description of how the ASC evolved from the previous
version;
e) defines the author of this ASC. This element has the custom type asc: actor (defined
in 5.4.8) used to specify the name and coordinates of the author;
f) opionally defines the owner of this ASC. This element has the custom type asc: actor
(defined in 5.4.8) used to specify the name and coordinates of the owner;
g) optionally defines a list of super-ordinate ASCs. It consists of a sequence of zero
or more elements which in turn contain a sequence of the following subelements:
1) contains a reference to the ‘uid’ of the super-ordinate ASC; and
2) qualifies the relationship to the super-ordinate ASC.
h) optionally defines a list of sub-ordinate ASCs. It consists of a sequence of zero
or more elements which in turn contain a sequence of the following subelements:
3) contains a reference to the ‘uid’ of the sub-ordinate ASC;
4) qualifies the relationship to the sub-ordinate ASC.
Table 7 shows the implementation of the element in the XML Schema.
Table 7 — element










© ISO/IEC 2018 – All rights reserved 13

Table 7 (continued)


type="asc:information" minOccurs="0">

type="asc:information" minOccurs="0">






type="asc:life-cycle-stage" use="required">



maxOccurs="unbounded">

maxOccurs="unbounded">




maxOccurs="unbounded">



type="asc:information" minOccurs="0"/>




14 © ISO/IEC 2018 – All rights reserved

Table 7 (continued)




maxOccurs="unbounded">



type="asc:information" minOccurs="0"/>









© ISO/IEC 2018 – All rights reserved 15

5.4.5 ASC Objective
Figure 4 — ASC Objective
The element is used to further contextualize the security and verification
activities defined by the ASC. It consists of a sequence of the following subelements:
a) provides a high-level qualitative and localized description of this ASC
purpose.
16 © ISO/IEC 2018 – All rights reserved

b) defines a set of security requirements that will be addressed
by performing the security activity of this ASC. It consists of one or more
elements which in turn consists of a sequence of the following subelements:
1) defines the originating context of the requirement (e.g., REGULATORY_
CONTEXT, BUSINESS_CONTEXT, etc.). It has the custom enumeration type
asc:requirements-context (defined in 5.4.11, Table 62);
2) defines the type of the requirements (e.g., BUSINESS_REQUIREMENT,
FUNCTIONAL_REQUIREMENT, etc.). It has the custom enumeration type asc:requirements-
type (defined in 5.4.11, Table 63);
3) provides a (localized) name for the requirement;
4) provides a (localized) qualitative description of the requirement; and
5) specifies the source document from which the requirement originates.
c) provides the levels of trust which are supported by this
ASC. This elements consists of a sequence of elements which in
turn contain the identifier of a element.
d) optionally provides definitions for a range of levels of trust. At
a minimum the range shall include the levels of trust supported by the ASC. The range is defined
by one or more elements which in turn contain the following sequence of
subelements:
1) optionally defines a unique identifier for the level of trust;
2) defines a numeric denomination for the level of trust;
3) defines a qualitative (localized) label for the level of trust; and
4) provides an informal (localized) description of the level of trust.
e) optionally defines one more preconditions that shall be fulfilled for
applying the ASC.
f) s optionally specifies that the correctness of the ASC can be verified through prediction instead of
performing the verification activity of the ASC.
Table 8 shows the implementation of the element in the XML Schema.
© ISO/IEC 2018 – All rights reserved 17

Table 8 — element











type="asc:requirements-context"
minOccurs="0">

type="asc:requirements-type"
minOccurs="0">



type="asc:information">

minOccurs="0">








18 © ISO/IEC 2018 – All rights reserved

Table 8 (continued)


maxOccurs="unbounded">





























© ISO/IEC 2018 – All rights reserved 19

Table 8 (continued)





type="xs:string"/>


type="asc:information"/>











type="asc:condition-type"
use="required"/>


minOccurs="0">




20 © ISO/IEC 2018 – All rights reserved

5.4.6 ASC Security activity and Verification measurement
Figure 5 — ASC Security and Verification measurement activities
and elements share the same
custom type asc:activity (defined in 5.4.7) to describe an activity.
Table 9 shows the implementation of elements and
in the XML Schema.
Table 9 — and elements




5.4.7 Complex type asc:activity
5.4.7.1 General
Figure 6 — ASC Activity
The complex type is used to define a common structure of the elements
an
...