gsm sas standard v3 3

GSM Association Non-confidential

Security Accreditation Scheme - Standard

V3.3 of 28


Version 3.3

16 October 2012

Security Classification: Non-confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the

Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and

information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted

under the security classification without the prior written approval of the Association.

Copyright Notice

Copyright © 2012 GSM Association

Disclaimer

The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept

any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.

The information contained in this document may be subject to change without prior notice.

Antitrust Notice

The information contain herein is in full compliance with the GSM Association‟s antitrust compliance policy.



V3.3 of 28

Table of Contents

1 The GSM Association SAS 4

1.1 Introduction 4

1.2 Objectives of the Scheme 4

2 Introduction 5

2.1 Overview 5

2.2 Scope 5

3 Definitions 6

3.1 Common Abbreviations 6

3.2 Glossary 6

3.3 References 6

3.4 Conventions 6

4 Definition of Processes 7

5 The Process Models 8

5.1 Embedding Process 8

5.2 Personalisation Process 9

5.3 The Actors 9

6 The Assets 10

6.1 Introduction 10

6.2 Assets Classification 11

6.3 Asset Characteristics 11

6.4 Incoming Sensitive Components (ISC) 11

6.5 Partly Finished Products (PFP) 11

6.6 Finished Products (FIN) 11

6.7 Personalisation Rejects (PRJ) 12

6.8 Embedded Rejects (ERJ) 12

6.9 Sensitive information (SEN) 12

7 Security Objectives 14

7.1 Introduction 14

7.2 Security Objectives for the Sensitive Process 14

7.3 Security Objectives for the Environment 14

8 The Threats 15

8.1 Introduction 15

8.2 Direct Threats Description 15

8.3 Indirect Threats Description 16

8.4 Application of Threats in the Process 16

9 Security Requirements 17

9.1 Introduction 17

9.2 Policy, strategy and documentation 17

9.3 Organisation and Responsibility 18

9.4 Information 18

9.5 Personnel Security 19

9.6 Physical Security 20



V3.3 of 28

9.7 Production data management 21

9.8 Logistics and Production Management 22

9.9 Computer and Network Management 24

Annex A Assets 27

Annex B Document Management 28

B.1 Document History 28

B.2 Other Information 28



V3.3 of 28

1 The GSM Association SAS

1.1 Introduction

There are numerous security risks faced by every GSM operator. The supplier may

introduce certain risks, the consequences of which will be borne by the GSM operator.

Operators are dependent on suppliers to control risks, and to provide confidence that

adequate security is in place. Operator confidence is improved by the introduction of an

auditable standard, which is applied to all GSM suppliers.

SAS is a voluntary scheme whereby smart card suppliers subject themselves to a

comprehensive audit at every production site.

In the future SAS may be compatible with the banking domain criteria, thus offering the

opportunity to benefit from similar approaches.

1.2 Objectives of the Scheme

The reason why the following security standard has been prepared is:

to address the security risks introduced by suppliers and manufacturers to every

GSM operator

to provide a set of auditable security requirements to allow GSM suppliers provide

assurance to their customers that potential risks are under control and that

appropriate security measures are in place.



V3.3 of 28

2 Introduction

2.1 Overview

This standard has been created and developed under the supervision of a GSM Association

(GSMA) working group comprised of representatives from GSM network operators, smart

card suppliers participating in SAS, and the GSMA-appointed auditing companies. The GSM

Association is responsible for updating the security standards and a review with the smart

card industry and the appointed auditors will take place every 12 months during the life of

the scheme.

Functional requirements and security objectives applicable to smart card embedding sites

and personalisation sites are outlined. Sites eligible for auditing include only those where

embedding and/or personalisation takes place with all other sites being outside the remit of

the scheme. In order to be supported by a widely accepted method, the document was

developed on the basis of the Common Criteria standard, the main smart card

manufacturers being experienced in the protection profile definition and the application of

appropriate security controls. However, this document is not intended to be a smart card

production protection profile.

2.2 Scope

The scope of the document has been restricted to security issues relating to the supply and

manufacture of smart cards for the GSM/3GSM community.

Consistency of the security requirements has been achieved by defining:

Card life cycle and processes

Assets to be protected

Risk and threats

Security requirements.

To further reduce the risks for GSM/3GSM operators it is acknowledged that the security

objectives must continue to be met after the personalisation phases where the supplier is

responsible for delivery.



V3.3 of 28

3 Definitions

3.1 Common Abbreviations

Term Description

SP The Sensitive Process represents the security evaluation field, covering the processes

and the assets within those processes

ISC Incoming Sensitive Components characterise the process sensitive inputs such as

information, products, files, keys, etc.

IT Information Technology

Actor Person who is involved in, or can affect, the target of evaluation

3.2 Glossary

Term Description

Key Refers to any logical key (e.g. cryptographic key)

Physical keys The keys and/or combinations used for vaults, safes and secure cabinets

Restricted

areas, high

security areas

Areas off-limits to unauthorised personnel in which assets are stored and

processed

Common

Criteria

Criteria used as the basis for evaluation of security properties. The evaluation

results help in determining whether or not the product is secure

Environment Environment of use of the sensitive process limited to the security aspects

Doubloon Two or more assets of the same nature showing a set of information that should be

individual according to the correct process

Secure storage Specific area set aside dedicated to the protection of assets.

Reject Finished or partially finished product containing sensitive information which has

been ejected from the process.

3.3 References

Ref Title

[1] GSMA SAS Methodology, latest version available at www.gsma.com/sas

[2] GSMA SAS Guidelines, available to participating sites from [email protected]

[3] GSMA SAS Audit analysis, available to participating sites from [email protected]

[4] “Key words for use in RFCs to Indicate Requirement Levels”, S. Bradner, March 1997.

Available at http://www.ietf.org/rfc/rfc2119.txt

3.4 Conventions

The key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”,

recommended”, “may”, and “optional” in this document are to be interpreted as described in

RFC2119 [4].”

http://www.gsma.com/sas

mailto:[email protected]


http://www.ietf.org/rfc/rfc2119.txt



V3.3 of 28

4 Definition of Processes

The smart card product life-cycle can be broken down into 7 phases:

# Title Description

1. Software development Basic software and operating system development; application

software development, integration and validation

2. IC design IC development; hardware development, initialisation and test

program development, integration and validation, initialisation of

identification information and delivery keys

3. Component production Component manufacturing, testing, preparation and transfer to the

site

4. Embedding process IC reception and acceptance, modules manufacture, customer

order, embedding, cutting, pre-personalisation and internal supply

to personalisation stage or supply to external parties

5. Personalisation Receipt of supplies, documents and files, processing of files,

recording of data on the card and documents, packing and delivery

of supplies and files. Each of these steps could involve a re-work

process

6. User Commences when the network operator takes responsibility for the

cards. It includes the operator‟s storage, distribution and activation

of the cards and the subsequent customer use of the card.

7. End-of-life When the card reaches a stage where it can no longer perform the

functions for which it was produced

Table 1 - Smart card product life-cycle

For the purposes of the security accreditation scheme, the standard is defined for smart card

embedding and personalising processes only.



V3.3 of 28

5 The Process Models

The life cycle is used to depict the security target implementation. The representation of the

steps within the process is based on product and data flows. All possible combinations are

not described and chronological order is not necessarily represented.

5.1 Embedding Process

The embedding process is not as important as the personalisation process from a customer

data point of view. Modules manufacture is included in the embedding process for the

purpose of conducting audits however, where this activity does not take place on site it may

be excluded and the awarded certificate will reflect this.

Embedding

IC Acceptance

Modules

manufacturing

IC (wafer) reception

Customer order

reception and

treatment

Card printing

Pre-personalization

Cutting

Supplies delivery

Figure 1 - Embedding Process



V3.3 of 28

5.2 Personalisation Process

The personalisation includes customer data in various forms throughout the process and

could include the rework process.

Supplies reception

Incoming fi les

reception

Documents reception

File treatment

Cards

personalization

Confidential

documents

personalization

Non conf idential

documents

personalization

Packaging

Supplies delivery

Outgoing fi les

delivery

Figure 2- Personalisation Process

5.3 The Actors

There are four classes of actor:

Internal Authorised – [INT_AUTH] - employees authorised to access the SP and

supporting environment

Internal Unauthorised – [INT_UNAU] - employees not authorised to access the SP.

But can access the supporting environment

External Authorised – [EXT_AUTH] - third party with authority to access the SP and


External Unauthorised – [EXT_UNAU] - third party not authorised to access the SP or




V3.3 of 28

6 The Assets

6.1 Introduction

Within the processes described above assets are highly regarded and their security must be

protected. Most assets are located in the personalisation process. However, customer

specific requirements may make certain chips more sensitive if the production cycle involves

additional steps prior to the personalisation process.

This document is limited to the production of smart cards for a single issuer. Other products

are not part of the subject matter. The assets are laid on in tabular form below.

Incoming sensitive components

(ISC)

Incoming files (ISC_INF)

Wafers (ISC_WAF)

Algorithms (ISC_ALG)

Keys (ISC_KEY)

IMSI (ISC_IMS)

Partly finished products (PFP)

ICs (PFP_MIC)

Modules (PFP_MOD)

Smart cards not completely

personalised (PFP_SIM)

Finished products(FIN)

Smart cards (FIN_SIM)

PIN mailers (FIN_PMA)

Outgoing files (FIN_OUF)

Sensitive information (SEN)

Customer Information (SEN_CUI)

Management Data (SEN_MAD)

Personalisation Rejects (PRJ)

Smart cards (PRJ_SIM)

PIN Mailer (PRJ_PMA)

Embedding Rejects (ERJ)

IC (ERJ_MIC)

Module (ERJ_MOD)

Smart card (ERJ_SIM)

Table 2: Assets



V3.3 of 28

6.2 Assets Classification

The assets that require protection are in various forms within the embedding and

personalisation processes therefore the protection required can be complex unless arranged

logically in classes. A classification table is contained in Annex A.

6.3 Asset Characteristics

Files and data are transmitted, stored and used in many media and transport forms.

Finished products and partly finished products may be used as examples that only follow the

same security rules as the corresponding assets when they contain customer data.

6.4 Incoming Sensitive Components (ISC)

Incoming sensitive components such as algorithms, products, files and keys are supplied to

the manufacturing sites and can be sent between production sites.

Incoming sensitive components include:

Wafers [ISC_WAF_2], must be protected in availability and integrity. Traceability

must be ensured.

Incoming files containing classified information which must be protected in terms of

integrity, confidentiality, and availability commensurate with the highest class of

information contained in the file [ISC _INF_]

Keys [ISC _KEY_1] whose confidentiality, integrity and availability must be protected

Algorithms [ISC_ALG_1] which must be protected in terms of availability,

confidentiality, and integrity.

6.5 Partly Finished Products (PFP)

Partly finished products come from ISC transformations or ISC usage inside the same

production site.

Partly finished products include:

ICs [PFP_MIC_2]

Modules [PFP_MOD]

Smart cards not completely personalised [PFP_SIM_2]

PIN mailers not yet packaged [PFP_PMA]

These assets must be protected in terms of availability and integrity. Traceability must also

be ensured.

6.6 Finished Products (FIN)

Finished products are made up of:

Smart cards [FIN_SIM_1]

PIN mailers [FIN_PMA]

Outgoing files [FIN_OUF]



V3.3 of 28

[A_OUT_FIL1] must be protected in availability, integrity and confidentiality as

they contain sensitive information eg. Ki

[A_OUT_FIL2] must be protected in availability and integrity. They do not contain

sensitive information eg. PIN and PUK

[A_OUT_FIL3] only need to have the integrity preserved as they do not contain

sensitive information eg. MSISDN

In all cases, if the files contain different classes of data the higher class shall prevail.

6.7 Personalisation Rejects (PRJ)

Personalisation rejects are:

Smart cards [PRJ_SIM], confidentiality must be protected

Pin mailers [PRJ _PMA], confidentiality must be protected

The integrity and traceability of these assets must be assured until they are destroyed.

6.8 Embedded Rejects (ERJ)

IC, module or smart card rejects, during the embedding process, have no specific security

requirements except their destruction.

6.9 Sensitive information (SEN)

Sensitive information is:

Customer information [SEN_CUI], information from the personalisation site that is

created or can be obtained inside or by a third party attack. Customer information can

be recorded in the following devices:

Security elements [DE_SEC] such as mother cards, batch cards, security

modules etc.

Random number generators [DE_RNG]

Transmission and ciphering systems [DE_TRA]

Testing systems [DE_TST]

Printing Ribbons [DE_RIB]

Production file systems [DE_PRD]

Management Data [SEN_MAD], information on the management of batches and

smart cards. This can consist of:

[SEN_PRD] production data which, if it contains classified information, must be

protected in terms of integrity, confidentiality, and availability.

[SEN_MAT] traceability information which should allow the supplier identify the

person, or group of persons, who worked on a batch

[SEN_MAU] audit information which should be available in relation to the

recorded production history of a card/batch of cards for up to 12 months, subject

to local laws.



V3.3 of 28

The integrity of sensitive information must be assured and the confidentiality protected.

Sensitive information includes all files, particularly working, temporary or safeguarded files

that contain the information outlined above.



V3.3 of 28

7 Security Objectives

7.1 Introduction

As assets are exposed to risks which the smart card suppliers have to manage to ensure

they are protected according to the security objectives. It is this protection that provides

assurance to the GSM operators. The security objectives relate to both the sensitive process

and its environment. All the objectives must be addressed but higher levels of assurance are

needed depending on the asset classification.

7.2 Security Objectives for the Sensitive Process

# Objective Threat Description

1 The SP must control the

production process

T_DOUB_TEC

T_DOUB_REW

T_DOUB_REU

T_LOSS T_MODIF

To prevent clone, mismatch, anomalies

2 The SP must control,

manage and protect data

against loss of integrity

and confidentiality

T_DOUB_REU

T_LOSS T_DISC

T_MODIF

To prevent:

any disclosure of assets

any non-conforming finished product

due to loss of integrity

3 The SP must guarantee a

secure product flow

T_DOUB_REU

T_LOSS T_DISC

T_SEF

To prevent theft, loss, misappropriation of

assets

4 The SP must manage the

elements that are specified

as auditable

T_MODIF To look for possible or real security

violation

5 The SP must be designed

in such a way that

independence of different

customer files (asset) is

always achieved

T_DISC To prevent one customer‟s data being

disclosed to another customer

Table 3 - Security Objectives for the Sensitive Process

7.3 Security Objectives for the Environment

# Objective Threat Description

1 The SP environment must

manage the elements that

are specifically auditable

T_SEF To look for possible or real security

violation

2 The SP environment must

guarantee a secure product

flow

T_SEF To prevent theft, loss or misappropriation

of assets

Table 4 - Security Objectives for the Environment



V3.3 of 28

8 The Threats

8.1 Introduction

The threat analysis has been completed to identify the main threats to the smart card

supplier. The list is not intended to be exhaustive.

The main threats to data are loss of availability, confidentiality and integrity.

The threats are listed 8.2 and 8.3 independently of the process step concerned. In 8.4 each

threat is associated to a step in the production process.

In the threat description, data means all type of data assets described above.

8.2 Direct Threats Description

Threats Actors Assets Description

T_DOUB_TEC

PFP_SIM, PFP_PMA,

FIN_PMA, FIN_SIM,

SEN_MAD

Physical doubloon or mismatch

creation resulting from a technical

mistake/bug

T_DOUB_REW INT_AUTH

INT_UNAU

EXT_AUTH

PFP_SIM, PFP_PMA,

FIN_PMA, FIN_SIM,

SEN_MAD, PRJ_SIM,

PRJ_PMA

Physical doubloon creation resulting

from non destroyed material after a

rework (error or malevolence)

T_DOUB_REU INT_AUTH

INT_UNAU

PFP_SIM, PFP_PMA,

FIN_PMA, FIN_SIM,

SEN_MAD, PRJ_SIM,

PRJ_PMA

Physical doubloon creation resulting

from reused sensitive information

(error or malevolence)

T_LOSS INT_AUTH

INT_UNAU

EXT_AUTH

EXT_UNAU

ALL SENSITIVE ASSETS Loss or theft of classified assets (1,

2, 3) excluding the wafer and IC and

module during the embedding

process

T_DISC INT_AUTH

INT_UNAU

EXT_AUTH

EXT_UNAU

ALL ASSETS

CONTAINING

CLASSIFIED

INFORMATION

Disclosure of classified information

T_MODIF INT_AUTH

INT_UNAU

EXT_AUTH

ALL ASSETS

CONTAINING

CLASSIFIED

INFORMATION

Unauthorised modification of

classified information causing loss

of integrity through error or

malevolence

Table 5 - Direct Threats Description

Additional threats can result from combinations of those threats listed above.



V3.3 of 28

8.3 Indirect Threats Description

Threats Actors Assets Description

T_SEF ANY ANY Accidental or deliberate security

failure.

Table 6 - Indirect Threats Description

8.4 Application of Threats in the Process

T_D

OU

B_T

EC

T_D

OU

B_R

EW

T_D

OU

B_R

EU

T_

LO

SS

T_D

ISC

T_M

OD

IF

T_S

EF

T_D

OU

B_T

EC

IC Reception

IC Acceptance

Modules Manufacturing

Customer Order Reception

Embedding

Cutting

Pre personalisation

Supplies delivery to personalisation

Supplies reception

Documents reception

Incoming files reception

File treatment

Card personalisation

Confidential document personaliastion

Non-confidential document personaliastion

Packaging

Supplies delivery (finished products)

Outgoing files delivery

Transport between sites

Table 7 - Application of Threats in the Process



V3.3 of 28

9 Security Requirements

9.1 Introduction

In order to consider the card manufacturing and personalisation processes secure certain

requirements must be met. These requirements, which are outlined below, are considered

as minimum-security requirements applying to the environment in which the SP is used.

The requirements of the Standard should be met by established processes / controls for

which evidence of correct operation exists.

It is recognised that it is possible to use any other mechanisms or tools other than those

described in this section if they achieve the same security objective. For a worked example

of how the standard could be achieved refer to the “GSM Association SAS – Security

Guidelines” which is available from the GSM Association headquarters.

9.2 Policy, strategy and documentation

The security policy and strategy provides the business and its employees with a direction

and framework to support and guide security decisions within the company.

9.2.1 Policy

9.2.1.1 A clear direction should be set and supported by a documented security policy

which defines the security objectives and the rules and procedures relating to the

security of the SP, sensitive information and asset management.

9.2.1.2 Employees should understand and have access to the policy and its application

should be checked periodically.

9.2.2 Strategy

9.2.2.1 A coherent security strategy must be defined based on a clear understanding of

the risks. The strategy should use periodic risk assessment as the basis for

defining, implementing and updating the site security system. The strategy should

be reviewed regularly to ensure that it reflects the changing security environment

through ongoing re-assessment of risks.

9.2.3 Business Continuity Planning

9.2.3.1 Business continuity measures must be in place in the event of disaster.



V3.3 of 28

9.2.4 Internal audit and control

9.2.4.1 The overall security management system should be subject to a rigorous

programme of internal monitoring, audit and maintenance to ensure its continued

correct operation.

9.3 Organisation and Responsibility

9.3.1 Organisation

9.3.1.1 To successfully manage security, a defined organisation structure should be

established with appropriate allocation of security responsibilities.

9.3.1.2 The management structure should maintain and control security through a cross-

functional team that co-ordinates identification, collation, and resolution, of

security issues, independent of the business structure.

9.3.2 Responsibility

9.3.2.1 A security manager should be appointed with overall responsibility for the issues

relating to security in the SP.

9.3.2.2 Clear responsibility for all aspects of security, whether operational, supervisory or

strategic, must be defined within the business as part of the overall security

organization.

9.3.2.3 Asset protection procedures and responsibilities should be documented

throughout the SP.

9.3.3 Contracts and liabilities

9.3.3.1 In terms of contractual liability responsibility for loss should be documented.

Appropriate controls and insurance should be in place.

9.4 Information

The management of sensitive information, including its storage, archiving, destruction and

transmission, can vary depending on the classification of the asset involved.

9.4.1 Classification

9.4.1.1 A clear structure for classification of information and other assets should be in

place with accompanying guidelines to ensure that assets are appropriately

classified and treated throughout their lifecycle.



V3.3 of 28

9.4.2 Data and media handling

9.4.2.1 Access to sensitive information and assets must always be governed by an

overall „need to know‟ principle.

9.4.2.2 Guidelines should be in place governing the handling of data and other media,

including a clear desk policy. Guidelines should describe the end-to-end „lifecycle

management‟ for sensitive assets, considering creation, classification,

processing, storage, transmission and disposal.

9.5 Personnel Security

A number of security requirements should pertain to all personnel working within the SP.

9.5.1 Security in job description

9.5.1.1 Security responsibilities should be clearly defined in job descriptions.

9.5.2 Recruitment screening

9.5.2.1 An applicant, and employee, screening policy should be in place where local laws

allow

9.5.3 Acceptance of security rules

9.5.3.1 All recruits should sign a confidentiality agreement.

9.5.3.2 Employees should read the security policy and record their understanding of the

contents and the conditions they impose.

9.5.3.3 Adequate training in relevant aspects of the security management system should

be provided on an ongoing basis.

9.5.4 Incident response and reporting

9.5.4.1 Reporting procedures should be in place where a breach of the security policy

has been revealed. A clear disciplinary procedure should be in place in the event

that a staff member breaches the security policy.

9.5.5 Contract termination

9.5.5.1 Clear exit procedures should be in place and observed with the departure of each

employee.



V3.3 of 28

9.6 Physical Security

A building is part of the site where smartcards or components are produced, personalised

and/or stored. Buildings in which sensitive assets are processed should be strongly

constructed. Constructions and materials should be robust and resistant to outside attack as

manufacturers must ensure assets are stored within high security areas and restricted areas

by using recognised security control devices, staff access procedures and audit control logs.

9.6.1 Security plan

Layers of physical security control should be used to protect the SP according to a clearly

defined and understood strategy. The strategy should apply controls relevant to the assets

and risks identified through risk assessment.

9.6.1.1 The strategy should be encapsulated in a security plan that:

defines a clear site perimeter / boundary

defines one or more levels of secure area within the boundary of the site

perimeter

maps the creation, storage and processing of sensitive assets to the secure

areas

defines physical security protection standards for each level of secure area

9.6.2 Physical protection

9.6.2.1 The protection standards defined in the security plan should be appropriately

deployed throughout the site, to include:

deterrent to attack or unauthorized entry

physical protection of the building and secure areas capable of resisting attack

for an appropriate period

mechanisms for early detection of attempted attack against, or unauthorized

entry into, the secure areas at vulnerable points

control of access through normal entry / exit points into the building and SP to

prevent unauthorized access

effective controls to manage security during times of emergency egress from

the secure area and building

mechanisms for identifying attempted, or successful, unauthorized access to,

or within the site

mechanisms for monitoring and providing auditability of, authorised and

unauthorised activities within the SP

9.6.2.2 Controls deployed should be clearly documented and up-to-date.

9.6.2.3 Controls should be subject to a rigorous programme of internal monitoring, audit

and maintenance to ensure their continued correct operation.



V3.3 of 28

9.6.3 Access control

9.6.3.1 Clear entry procedures and policies should exist which cater for the rights of

employees, visitors and deliveries to enter the SP. These considerations should

include the use of identity cards, procedures governing the movement of visitors

within the SP, delivery/dispatch checking procedures and record maintenance.

9.6.3.2 Access to each secure area should be controlled on a „need to be there‟ basis.

Appropriate procedures should be in place to control, authorise, and monitor

access to each secure area and within secure areas. Regular audits should be

undertaken to monitor access control to the secure area.

9.6.4 Security staff

9.6.4.1 Security staff are commonly employed by suppliers. Where this is the case the

duties should be clearly documented and the necessary tools and training shall

be supplied.


9.6.5.1 Physical security controls should be subject to a rigorous programme of internal

monitoring, audit and maintenance to ensure their continued correct operation.

9.7 Production data management

Suppliers will be responsible for lifecycle management of class 1 data used for

personalisation. Information and IT security controls must be appropriately applied to all

aspects of lifecycle management to ensure that data is adequately protected. The overall

principle should be that all data is appropriately protected from the point of receipt through

storage, internal transfer, processing and through to secure deletion of the data.

9.7.1 Data transfer

9.7.1.1 Suppliers should take responsibility to ensure that electronic data transfer

between themselves and other third parties is appropriately secured.

9.7.2 Access to sensitive data

9.7.2.1 Suppliers should prevent direct access to sensitive production data. User access

to sensitive data should be possible only where absolutely necessary. All access

must be auditable to identify the date, time, activity and person responsible.

9.7.3 Data generation

9.7.3.1 As part of the personalisation process secret data may be generated and

personalized into the smart card. Where such generation takes place:



V3.3 of 28

The quality of the number generator in use should be subject to appropriate

testing on a periodic basis. Evidence of testing, and successful results, should

be available.

Clear, auditable, controls should be in place surrounding the use of the

number generator to ensure that data is taken from the appropriate source.

9.7.4 Encryption keys

Encryption keys used for data protection should be generated, exchanged and stored

securely.

9.7.5 Auditability and accountability

9.7.5.1 The production process should be controlled by an audit trail that provides a

complete record of, and individual accountability for:

data generation and processing

personalisation

re-personalisation

access to sensitive data

production of customer output files

9.7.5.2 Auditable dual-control and 4-eyes principle should be applied to sensitive steps of

data processing.

9.7.6 Data integrity

9.7.6.1 Controls should be in place to ensure that the same, authorized, data from the

correct source is used for production and supplied to the customer.

9.7.7 Duplicate production

9.7.7.1 Controls should be in place to prevent duplicate production.


9.7.8.1 Production data controls should be subject to a rigorous programme of internal


9.8 Logistics and Production Management

9.8.1 Personnel

9.8.1.1 Clear security rules should govern the manner in which employees engaged in

such activities should operate within the SP. Relevant guidelines should be in

place and communicated to all relevant staff.



V3.3 of 28

9.8.2 Order management

9.8.2.1 The ordering format should be agreed between operator and supplier and rules to

preserve the integrity of the ordering process should be in place.

9.8.3 Raw materials

9.8.3.1 Raw materials used in smartcard production (plastic sheets, GSM generic

components, blank mailers, etc.) are not considered to be security sensitive.

However, appropriate controls should be established for stock movements. The

availability of these assets must be ensured.

9.8.4 Design media

9.8.4.1 Design media such as films, plates, etc. should be under appropriate control to

prevent counterfeiting.

9.8.5 Control, audit and monitoring

9.8.5.1 The production process should be controlled by an audit trail that:

ensures that the numbers of class 1 and 2 assets created, process, rejected

and destroyed are completely accounted for

ensures that the responsible individuals are traceable and can be held

accountable

demands escalation where discrepancies or other security incidents are

identified.

9.8.5.2 The stock of all Class 1 and 2 assets must be subject to end-to-end reconciliation

in order that every element can be accounted for.

9.8.5.3 Auditable dual-control and 4-eyes principle should be applied to sensitive steps of

the production process, including:

control of the quantity of assets entering the personalisation process

control of the quantity of assets packaged for dispatch to customers

destruction of rejected assets

9.8.5.4 Application of 4-eyes principle should be auditable through production records

and CCTV.

9.8.5.5 Regular audits should be undertaken to ensure the integrity of production controls

and the audit trail.

9.8.5.6 Suppliers must demonstrate an ability to prevent unauthorised duplication within

the production process during personalisation and re-personalisation.



V3.3 of 28

9.8.6 Destruction

9.8.6.1 Rejected cards must always be destroyed according to a secure procedure and

logs retained.

9.8.7 Storage

9.8.7.1 Personalised cards should be stored securely prior to dispatch to preserve the

integrity of the batches. Where personalised cards are stored for extended

periods additional controls should be in place.

9.8.8 Packaging and delivery

9.8.8.1 Packaging of goods should be fit for the intended purpose and strong enough to

protect them during shipment. Appropriate measures should be in place to

ascertain whether or not goods have been tampered with.

9.8.8.2 Secure delivery procedures should be agreed between the customer and the

supplier which should include agreed delivery addresses and the method of

delivery.

9.8.8.3 Collection and delivery notes must be positively identified. Goods should only be

handed over following the production of the appropriate authority documents. A

receipt should be obtained.


9.8.9.1 Production security controls should be subject to a rigorous programme of

internal monitoring, audit and maintenance to ensure their continued correct

operation.

9.9 Computer and Network Management

The secure operation of computer and network facilities is paramount to the security of data.

In particular, the processing, storage and transfer of Class 1 information, which if

compromised, could have serious consequences for the Operator, must be considered.

Operation of computer systems and networks must ensure that comprehensive mechanisms

are in place to preserve the confidentiality, integrity and availability of data.

9.9.1 Policy

9.9.1.1 A documented IT security policy should exist which should be well understood by

employees.



V3.3 of 28

9.9.2 Segregation of roles and responsibilities

9.9.2.1 Responsibilities and procedures for the management and operation of computers

and networks should be established. Security related duties should be

segregated from operational activities to minimise risk.

9.9.3 Access control

9.9.3.1 Physical access to sensitive computer facilities should be controlled.

9.9.3.2 An access control policy should be in place and procedures should govern the

granting of access rights with a limit placed on the use of special privilege users.

Logical access to IT services should be via a secure logon procedure.

9.9.3.3 Passwords should be managed effectively and strong authentication should be

deployed where remote access is granted.

9.9.4 Network security

9.9.4.1 Systems and data networks used for the processing and storage of sensitive data

should be housed in an appropriate environment and logically or physically

separated from insecure networks. Data transfer between secure and insecure

networks must be strictly controlled according to a documented policy defined on

a principle of minimum access.

9.9.5 Virus controls

9.9.5.1 Comprehensive virus detection and prevention measures should be deployed

across all vulnerable systems.

9.9.6 System back-up

9.9.6.1 Back-up copies of critical business data should be taken regularly. Back-ups

should be stored appropriately to ensure confidentiality and availability.

9.9.7 Audit and monitoring

9.9.7.1 Audit trails of security events should be maintained and procedures established

for monitoring use.

9.9.8 Insecure terminal access

9.9.8.1 Unattended terminals should timeout to prevent unauthorised use and

appropriate time limits should be in place.



V3.3 of 28

9.9.9 External facilities management

9.9.9.1 If external facilities management services are used appropriate security controls

should be in place.

9.9.10 Systems development and maintenance

9.9.10.1 Security requirements of systems should be identified at the outset of their

procurement and these factors should be taken into account when sourcing them.


9.9.11.1 IT security controls should be subject to a rigorous programme of internal




V3.3 of 28

Annex A Assets

Code Asset Class

Products FIN_SIM Finished smart cards 1

PRJ_SIM Personalised rejected smart 1

Info

rma

tio

n

ISC_ALG Incoming algorithms 1

ISC_KEY_Ki Personal key 1

ISC_KEY_ADM Administration key 1

ISC_KEY_OTA Key for personalising smart cards Over The Air. 1

ISC_KEY_KT Transport key – key used to encrypt Ki 1

ISC_KEY_LK Local key – Key used by manufacturer to manage access to

incoming and outgoing information 1

SEN_CUI Customer information 1

Pro

ducts

ISC_WAF Incoming wafers 2

PFP_MIC Partly finished IC 2

PFP_MOD Partly finished module 2

PFP_SIM Partly finished smart card 2

ERJ_SIM Embedding reject smart card 2

PFP_PMA Not completely personalised PIN mailer 2

FIN_PMA Personalised PIN mailers 2

PRJ_SIM Personalised rejected PIN mailer 2

Info

rma

tio

n

SEN_MAD

Management data. Information on the management of

batches and smart cards. This may contain:

Production data, which may contain classified

information

Traceability information, which should allow the

supplier to identify the person(s) who, worked on a

batch

Audit information related to the recorded production

history of a card or batch of cards.

If a file managed Class 1 information, these information

have to be Class 1 protected and the file Class 2 protected

2

ISC_INF Incoming files. If the file contains class 1 information, it

needs to be protected as a class 1 2

FIN_OUF Outgoing files. If the file contains class 1 information (E.g

Ki), this information has to be Class 1 protected. 2

ISC_KEY_PIN Smart card PIN 2

ISC_KEY_PUK Unblocking PIN 2

ISC_IMS International Mobile Subscriber Information 2



V3.3 of 28

Annex B Document Management

B.1 Document History

Version Date Brief Description of Change Editor / Company

3.1.0 24 Jul

2003 Stable version in use. James Moran, GSMA

3.2.2 16 Nov

2006

Significant clarifications added to security

requirements to aid interpretation by

auditees. New coversheet.

James Messham,

FML

3.2.4 11 Sep

2008

New logo

Minor updates

Appendix B removed

James Messham,

FML

3.3 16 Oct

2012

Applied updated GSMA document

template and version numbering.

David Maxwell,

GSMA

B.2 Other Information

Type Description

Document Owner SAS Certification Body

Editor / Company David Maxwell, GSMA

It is our intention to provide a quality product for your use. If you find any errors or omissions,

please contact us with your comments. You may notify us at [email protected]

Your comments or suggestions & questions are always welcome.
