Security Guidelines for Product Categories- OPEN POS Ver. 2.0

CCDS security guidelines WG
POS SWG

Revision history
VersionDate

Description

Ver.1.0

2016/06/08

Created a new edition

Ver. 2.0

2017/05/29

Edited and updated as guidelines for FY2016■Trademarks
・All company and product names mentioned in this book are company trademarks ortrademarks registered.
■Further notices
・All information provided in this book is stated at the time of publication and may change
without notice.
・Any copying or reprinting of the contents of this document without obtaining permission
from CCDS is prohibited.
© 2017 Connected Consumer Device Security Council ProprietaryTable of contents
1

INTRODUCTION ....................................................................................... 4

1.1

Current status of and issues relating to POS security ........................................... 5

1.2

Scope of the guidelines ........................................................................................... 6

1.3

Object of the guidelines .......................................................................................... 6

1.5

Abbreviations ........................................................................................................... 7

2

SYSTEM CONFIGURATION AND OPERATIONAL MODEL ....................... 8

2.1

POS system configuration and characters .............................................................. 8

2.2

Operation of the POS system .................................................................................123

SIGNIFICANT THREATS TO SECURITY ................................................. 13

3.1

Criminal case in the past and considerable point of view .....................................13

3.2

Limitations to existing security measures .............................................................143.2.1 Security measures against security breaches ........................................................... 14
3.2.2 Operational conditions in the security measures ....................................................... 15
3.2.3 The cost of security measures .................................................................................. 15
3.2.4 Deflection of the viewpoint of security measures ...................................................... 16

4

SECURITY GUIDELINES ......................................................................... 19

4.1 The premises that need to be made when considering security measures ...............19
4.1

4.2 Policies on security measures ............................................................................21

4.3 Security concepts for credit transactions ..................................................................29

5

THE DEVELOPMENT PHASE AND SECURITY MEASURES ................... 31

5.1 Definitions of the phases in the life cycle ..................................................................311

5.2 Action required during each phase ............................................................................32
5.2.1 Initiation phase ......................................................................................................... 32
5.2.2 Development phase .................................................................................................. 33
5.2.3 Deployment phase .................................................................................................... 34
5.2.4 Operation and maintenance phase ........................................................................... 36
5.2.5 Disposal phase ......................................................................................................... 36
5.3 Guidance of the security measures within each phase..............................................37

6

CONCLUSION ......................................................................................... 38

7

APPENDIX .............................................................................................. 39

REFERENCES .............................................................................................. 40
Figure 2-1 POS system layout and human interaction ..................................................... 8
Figure 2-2 Example of a POS system ........................................................................... 12
Figure 3-1 Flowchart of information leakage using the malware skimming technique ..... 14
Figure 3-2 Suggested security measures in the previous system .................................. 17
Figure 3-3 Pertinent issues for existing security measures ............................................ 18
Figure 4-1 Critical data that must be protected ............................................................. 24
Figure 4-2 Critical data to be protected ......................................................................... 25
Figure 5-1 Phases in the life cycle ................................................................................ 31

Table 1-1 List of abbreviations ........................................................................................ 7
Table 2-1: A description of the components of the POS system ....................................... 9
Table 2-2 Description of the characters .......................................................................... 11
Table 3-1 Summary of the concepts of risk ................................................................... 13
Table 5-1 Definition of the phases ................................................................................ 31
Table 5-2 Security measures during the initiation phase ................................................ 32
Table 5-3 Security measures during the development phase ......................................... 33
Table 5-4 Security measures during the deployment phase ........................................... 35
Table 5-5 Security measures during the operation and maintenance phase ................... 36
Table 5-6 Security measures of the abolition phase ...................................................... 36
Table 5-7 The security measures of each phase ........................................................... 372

3

1 Introduction
To date, every product industry has formulated its own safety standards. Security
standards relating to organizational administration (ISO27001) and product design security
assessment and authentication (ISO15408) have already been formulated, while recent
years have witnessed the formulation of standards targeting control systems for criticalinfrastructure (plants and facilities essential to social infrastructure) (IEC62443).
With the popularity of IoT, devices in widespread use are supporting a variety of
networking features, increasing security concerns. That said, it is undeniable that security
standards relevant to IoT products and services are not yet sufficiently in place.
In the U.S. and European nations, moves are underway to determine security standards
by using industry-specific safety standards. However, while in Japan there are tangible
security concerns that may lead to the establishment of security standards, there are few
areas where practical discussions have yet led to action.
The Connected Consumer Device Security Council (CCDS) was established in responseto this situation. The Council is committed to formulating security standards for common
devices and launching an authentication program to confirm and verify compliance withthese standards in order to reassure users of IoT products.
On August 5, 2015, the Information-technology Promotion Agency, Japan, Japan（IPA）
launched the IoT Safety/Security Development Guidelines Review WG to initiate
discussions on security at the national level. The CCDS has come together with the
IPA-WG to establish a number of proposals concerning the results of the reviews ofguidelines within the CCDS.
On March 24, 2017, the results of the reviews at the IPA-WG were compiled and released
as “IoT Safety/Security Development Guidelines - Important Points to be understood by
Software Developers toward the Smart-society エラー! 参照元が見つかりません。“. While
the IPA’s development guidelines focus on the common subjects by comprehensive
approach, the CCDS field-specific guidelines is developed for locating individual industry
specific safety and security promotion of design or development process.

4

1.1

Current status of and issues relating to POS security

With any POS other than cash, such as credit card, electronic money and gift coupons, thecoupon or the reward card are utilized, as with cash, in the storing of proceeds. Whiletransactions involving credit cards and electronic money are protected by each company’s
internal security procedures, in most cases where an operator receives and stores
payment directly in the form of cash or gift coupons, recent expansion of payment types
has lead to an increasing possibility of deliberate fraud or of customers being accidentallyshort changed by the POS cashier.
There has been progress in recent years to automate the system via POS self-service
automatic payment machines, but more needs to be done to improve the security of thesemachines, as they are vulnerable to conventional theft, and cyber crime, of which the latteris on the increase generally. In the United States, there have been many cases of
information (credit card numbers etc.) being stolen through the use of physical media
malware, which is surreptitiously installed in the POS control module. This malware is thenoperated locally or by remote control.
It is therefore clear that, as there has been an increase in cyber, physical and combined
crimes related to POS systems, protecting sales information has become even more vital.
However, while the spread of IoT technology in society means that the demand for security
measures has increased, several issues are hindering effective security management,such as a lack of investment in store operations and POS systems, insufficient training,
unavailability of staff, and employment of foreigners etc.
This form of information theft is becoming more common because of the increasingawareness of hacking techniques and the falling prices of the necessary equipment
required to perform them. As methods of information theft are becoming moresophisticated, the number and seriousness of such crimes involving malware is increasing,particularly as the criminals are sometimes company insiders. This makes it essential to
fully vet all insiders, such as developers, operators, maintenance personnel and clerks.
This measure is unnecessary for traditional security points, which are only subject toexternal attack as there are no insiders with any malicious intent.
With respect to credit transactions, there are security standards required by the operator,
such as the security measures applied by the international brands (VISA, MASTER, JCB,etc.) in the PCI (Payment Card Industry), and additional enhanced security measures(EMV standard) by the IC of the particular media type. However, a feature of our country isthat there is little progress in improving the standards of POS because of the high costs

5and operative skills required to apply the necessary measures for the individual
requirements and business operations of each particular merchant.
Strengthening of credit transaction security is addressed by measures such as
government-led initiatives, disconnecting sensitive information about credit and electronicmoney payments from the POS system, and by employing trustworthy operators. The
following guidelines are intended to outline effective security measures against direct
attack in terms of the POS operations previously mentioned.

1.2

Scope of the guidelines

These guidelines are intended to apply to the POS system, but only in terms of the POS
terminal, the POS server and the components present therein. It does not apply to theexternal connection network supporting the POS that includes an external computer.
In addition, these guidelines are not intended as a recommended standard of data andprotection requirements for the PCI (Payment Card Industry) and EMV (Europa Master
Visa) as a replacement of any existing standard. Neither are these guidelines intended tocover the protection requirements with respect to magnetic track information, etc., as thisis already covered by the PCI-DSS standard. For example, in the case of PCI-DSS(Payment Card Industry Data Security Standard), the standard is PAN (Primary AccountNumber: card number).

1.3

Object of the guidelines

These guidelines are intended to be a summary of the considerable design anddevelopment process involved during the implementation of the appropriate security
measures used in devices that utilize IoT. The guidelines are for the benefit of:1) The designers and developers of a device
2) The person in charge of the design development project3) Managers responsible for the budget and appointment of the personnel of the device
design project

6

1.5

Abbreviations

The abbreviations used in the Development Guidelines are as follows:
Table 1-1 List of abbreviations
Abbreviations

Term in fullCAT

Credit Authorization Terminal

CCDS

Connected Consumer Device Security Council

EFT

Electronic Fund Transfer

IEC

International Electrotechnical Commission

IoT

Internet of Things

IPA

Information-technology Promotion Agency

ISO

International Organization for Standardization

MICR

Magnetic Ink Character Reader

MSR

Magnetic Stripe Card

NIST

National Institute of Standards and Technology

OLE

Object Linking and Embedding

POS

Point of Sales

SWG

Sub Working Group

WG

Working Group

7

2
2.1

-

-

8

A detailed description of the components of the POS system is shown in Table 2-1, and adetailed description of the characters is shown in Table 2-2.

Table 2-1: A description of the components of the POS system
No.

Component

Function

1

ControlComputer controlling devices such as MSR or Drawer in
the POS and Windows are often equipped with an OS. A
hard disk (HDD) is often part of the Control.

2

HDD (Hard Disk Drive)

A HDD is part of the control department. The OS, adriver, middleware applications and the software formaintenance are installed on the HDD.

3

BIOS

A system such as a boot device that provides control.
Users can set a password to access the BIOS. This isrequired to prevent unauthorized access to the boot fromboot media, such as a USB memory or a CD-ROM drive,other than the HDD.

4

Display

The display function allows the transaction menu andprocessing results to be displayed on the POS.

5

Customer-side Display

Displays customer relevant transaction menus andprocessing results on a display for customers. In
addition, the function is also provided to perform
verification by inputting age limit confirmation, etc., forthe customer via the touch panel.

6

7

USB Port/

The USB/RS232C port allows personal computers andRS232C Port

peripherals to be connected via a USB / RS232C cable.

MSR (Magnetic Card

A general term for plastic devices that read magnetic

Reader)stripe cards. MSRs are mainly used to read magnetic
card information and make credit payments at the POS
when the customer provides their card. There are also
POS systems that include MSR.

8

Scanner（Barcode）

A device for reading a bar code which is mainly used toread product information at POS.

9POS Keyboard

One of the input devices at POS. The POS keyboard
works in the standard manner by transmitting character
signals to the POS through typing. It is used for theoverall operation of the POS.

10

Touch Panel

Another POS input device. The touch panel alsotransmits character signals to the POS by typing on the
keys. As with the POS keyboard, the touch panel is used9

for the overall operation of the POS.
11

Mode KeyThe name used for keys that switch the POS display.
POS functions such as discounts are often the name of amode key.

12

MICR（Sign Pad）

A magnetic ink character recognition device thatrecognizes input characters via a Sign Pad (LCD
handwriting input device) when credit cards are used.

13

ScalesThe device which weighs goods when appropriate andtransmits the weight to the cash register/POS.

14

Pin PADThe device that is used to enter a personal identification
number when an IC credit card is used in a shop.

15

IC Card Reader

The card reader device with a built-in IC chip (integrated
circuit) on which is recorded required information (data).
This device is used at a POS to read a plurality of
information such as the amount of prepaid electronicmoney remaining, credit information, point informationand other customer information. If required, the IC card
reader can be connected to the serial communication
port.

16

Receipt PrinterA device used to print hard copies of a receipt showing
the amounts of money in the registers.

17

EFT（CAT）

EFT is a POS system for electronic payments that is※Not covered by theseused to withdraw money from an account by presenting

guidelines.

a bank cash card at the checkout at a supermarket
etc.CAT is a credit inquiry

terminal which performs acredit check prior to payment. This involves confirming
the validity of the card by contacting the credit card callcenter to ask for a credit check.
18

DrawerAn actual drawer that is usually located under the cash
register and POS. It is used to hold cash, cash vouchersand complete non-electronic transactions.

19

Change Machine

The change machine, which dispenses the correctchange during transactions as specified by the POS. It isalso used to receive payments.

20

Line Display

The

customerdisplay,

which

is

set

on

a

height-adjustable telescopic pole to complement theshop environment. It can be set in four directions.

10

Table 2-2 Description of the characters
No

Character

Role

1

Checker

The operator at a two-person cash register, who ismainly in charge of recording products, and exists aspart of a two, not a one-person system register.

2

Cashier

The operator at a two-person cash register who is mainly
in charge of payment.

3

Manager (Person in

As a manager has more authority than other positions

Charge)such as the cashier and checkers, he or she is able touse all POS functions.

11

2.2
-

-

-





12

3 Significant Threats to Security
3.1

Criminal case in the past and considerable point of view
Key Features of Common Breaches of Security Situations and operational failures that

increase the risk of breaches of POS-security are listed below:
Table 3-1 Summary of the concepts of risk
No.

Security Breaches

1

Unauthorized Intrusion

Notes
Breaches of malicious intent are possible. These may
involve the use of USB devices that are hard to trace.
The publishing of interface specifications on line that

2

Leak of information

can lead to the development of engineered malware,
generally suggests that the source has been company
leaked information.
There is a risk of malware becoming installed on a3

Operation Inadequacy

POS system due to operational deficiencies that need
to be targeted, such as overt USB ports.

4

Unauthorized modification

A risk of unauthorized remodeling can occur due to aregular device distributing in the circulation market.
As

5

the

networkvia‘smart-society’

expands,itSpread of the damage caused

increases the chance of exposure to malware that has

by IoT

to be installed on the

POS system physically atpresent. In that case, an existing risk is doubled.

Figure 3-1 is an example of a security breach using malware
In the above case, the product specifications, such as software, are uploaded to aninternet site by someone considered to be a regular developer, and then downloaded by amalware developer to develop malware. This is then installed to a POS system with
operational media deficiencies, such as allowing USB memory access by a local operator.
As with other installation methods, malware is usually downloaded/installed throughmalicious Web links and E-mail attachments that are opened by the end user when the
POS is connected to an Internet or email enabled PC.
Another example of a technique is skimming by connecting an unauthorized device to a
POS terminal system physically to obtain card data. This data, which is then leaked out via
malware and skimming, is bought and sold by fraudsters to create forged credit-debit cards,
etc.

13

-

3.2













14





an unauthorized device must have been physically connected to a POS system by USB
etc.
In terms of “information leakage”, interface specifications must have been published on
the Web by a developer.
In terms of “deficiencies in the operation”, the possibility that the criminal must have
known the vulnerability of the POS that had been targeted must be considered.
It is therefore imperative that POS security measures be considered in terms of internal,
as well as external attacks. For example, it needs to be understood that instances of“unauthorized intrusion” must involve an insider.

3.2.2 Operational conditions in the security measures
Due to the difficulties encountered nowadays when trying to hire suitable staff, it cannot
be assumed that cashiers or POS operators will always be highly skilled and extremely
honest. This means that it is extremely difficult to force staff to conform to complicatedoperational techniques and security measures through excessive management. In addition,
the way that a POS is used varies according to factors such as the store and how busy it is,so the best ways to rectify failures in security measures vary from case to case. No matter
how good security measures are, they will not be effective if they are not adapted to actual
on-site operational conditions.
It is therefore necessary for security measures to be flexible if they are to be of practicaluse. There is also the problem of constraints placed on an operation serving to complicate
effective implementation of POS security measures.
Since security measures should be considered under such circumstances, acceptablesecurity measures in a store cannot be implemented by only conducting conventional
threat analysis and by not considering all possible risks. Thus, new analysis methods thattake into account all relevant threats and risks, as well as being suitable for the nature of
the operation, are required.

3.2.3 The cost of security measures
Despite effective implementation of security measures often being expensive underdifficult situations, such as those described in Section 3.2.1 and 3.2.2, allocated budgets
are often limited. However, security is a necessary expense that needs to be considered in
the use and maintenance of POS.

15

When allocating security budgets, the subsequent enforcement and checking of
measures also needs to be considered along with the initial cost of introducing themeasures.
As shown in Figure 2-1, it is necessary to check and supervise the results of work
performed with POS because the cashier, checker or manager may have malicious intent.
Although the verification and management of work should be reduced by taking security
measures, it may be reduced but can never be eliminated, so this also needs to be
included in the costs and risks. In addition, it is also necessary to consider the turnaroundtime required for repairing and replacing service parts.
In order to effectively implement security features on a component of the system, it should
be considered unacceptable for security overhauls of that component to have to take placein special locations, such as in “a secure room”. In other words, if advanced security
features such as tamper-resistance are added to components, overhauling of the systemcannot only take place in the secure room, as that may create a situation where repair
parts are not readily available during maintenance and operation. It is therefore necessary
to consider that it is undesirable to accept security that limits practical use in terms of time,
as well as in cost.

3.2.4 Deflection of the viewpoint of security measures
Figure 3-2 relates to the case described in Section 3.1, and shows the contents of the
security measures proposed by US-Cert (United States Computer Emergency ReadinessTeam).
The measures on the right side of the figure, and measures such as “access restriction
to BIOS” and “boot prohibited from USB” under the right side of the figure, are all designed
to protect the information on the hard disk drive.

16

-

-

17

-

18

4 Security Guidelines
As described in Chapter 3, it is vital to consider the best security measures against risks
such as information leaks and connection of an unauthorized device due to the constantthreat of internal crime and the unknown level of sophistication of any attack on thesystem.
In terms of the ultimate goal being to protect the information assets in the HDD, which is
the usual scenario, listed below are some of the main problems of ensuring effective
security measures:(a) Since there are usually a large number of items that need to be protected, managers
may be unable to perform this task effectively. The problem is compounded if a system hasa large number of terminals.
(b) OS and firmware are based on package software such as Microsoft Windows. While OSsecurity patches or updated versions of the OS are released periodically, it is very difficult
to update them for local use.
(c) Due to the difficulties of updating OS, software and firmware, the increased necessity
for re-inspection and re-certification are often not considered.
(d) There may be inadequate protection against system failure and the inability to recover
lost data.
(e) Proposed security measures may not be applicable for the system being used.

It can be seen that for measures to be effective, the operational realities, in terms of theactual purposes of the system, must be considered. The following guidelines list thepremises that need to be made to ensure adequate security.

4.1 The premises that need to be made when considering secur
ity measures
Premise 1: Developers, operators, users and maintenance personnel cannot be
trusted (The ethical view that human nature is basically evil).
In the case described in Chapter 3, it is assumed that malware developers referred to

specifications related to the POS system that must have been internally leaked. There isalso the possibility that an insider might be involved because it is necessary for the19unauthorized device or devices to be physically connected to the POS terminal system.
In developing security measures with the presence of possible internal frauds that could
threaten security taken into consideration, it would be necessary to start by assuming thatdevelopers, users and operators are all untrustworthy.
Premise 2: The operators, users and maintenance personnel involved in POS
operation are incompetent and immoral.

As described in Premise 1, it is necessary to presume that the connection of anunauthorized device to the POS terminal system by insiders was due to either an immoral
or an incompetent act. In addition, it also needs to be assumed that the staff has not been
properly trained in many cases amid increasingly diversified work patterns in recent years,
posing the risks of information leakage caused by errors if not malicious. Allowance should
also be made for measures to prevent human errors from occurring and for protecting
security when errors occur. It would be important in the first place to avoid burdening POS
operators with operational or procedural complexities.


Premise 3: Interface specifications have been published.
As described in Chapter 3, it is supposed that any malware introduced to a POS

peripheral device via the connection of an unauthorized device to a POS terminal has
utilized the interface specifications of the POS peripheral device that have been referred toonline by the malware developer.
Interface specifications are standardized for international unification by an OPOS
technology conference to allow open access, a variety of POS terminals, and developmentof POS production and applications. This means that interface specifications which can be
integrated into a POS system easily, such as OLE for Retail POS, are freely available on
the Web.
In addition, because these specifications may evolve at any time, and the standard
specifications of the interfaces for all devices mostly used by POS have been determined,
it is extremely difficult to conceal specifications from malware developers as they havebeen published, distributed and are in general use.
Premise 4:

An illegally remodeled and unauthorized device may be connected to thesystem.

20

As described in Chapter 3, it is physically possible to connect an unauthorized device forthe following reasons:・There have been cases of stolen card information being obtained by connecting anunauthorized device to the POS system as part of the skimming process.
・It is physically possible to connect the unauthorized device because the POS terminal
has a multi-purpose port (such as a USB or serial port).
Therefore, when considering security measures, it is necessary to allow for theconnection of a variety of devices and systems, including tampered, unauthorized orunintended devices.



Premise 5: There are unacceptable operational constraints on the implementation of
security measures.

As explained in Section 3, although a virus check may be proposed as a security
countermeasure, it might not be able to be implemented due to limitations of the use of the
POS. Therefore, when reflecting on operational constraints, it is necessary to accept thepremise that there are security measures that cannot be applied.

4.1

4.2 Policies on security measures

Following the premises as described in the previous section, the policies for performing
security measures are described below.
The measures are presented by comparing the 17 sections of the “IoT Safety/Security
Development Guidelines” document, which was published by IPA in advance of thisdocument. and also, this document and the “IoT Security Guidelines” published by the IoTConsortium.

21

Table 4-1 Corresponding part of this book that corresponds to “IoT Safety/Security
Development Guidelines”"Smart-society development guidelines"
Major item

Guideline
Makingcorporate

PolicyGuideline 1 Formulating the basic policies
for Safety/Security

efforts for the

Guideline 2 Reviewing systems and humanof the Smart-

Guideline 3 Preparing for internal frauds

societyand mistakes

Safety/Security resources for Safety/Security

Guideline 4 Identifying the objects to beprotected

Corresponding part of this document
Chapter No.

Overview
The formulation of the basic policies is not applicable in this book.

n/a

The reviewal of the structure and human resources is not

n/aapplicable in this book.

Guideline 5
Guideline 1

It is described how to detect internal fraud or mistakes.
It is describe for prioritization of the information and assets to beprotected, and selection of the objects to be protected.
Assuming the risks caused by connections, it is described for

Guideline 5 Assuming the risks caused by
Understanding
Analysisconnections

Guideline 6 Assuming the risks spreadthrough connections
Guideline 7 Understanding physical security
risks
Guideline 8 Designing to enable bothindividual and total protection
Guideline 9 Designing so as not to cause

Considering thedesigns toprotect theobjects to beprotected

trouble in other connected entities
Guideline 10 Ensuring consistency
between the designs of safety and security

Guideline 12 Verifying/validating thedesigns of safety and security
Considering the Guideline 13 Implementing the functions
designs toto identify and record own status

Guideline 8

releaseAssuming the physical risks, it is described for strengthen the
traceability for the device.
As an example of implementation, it is described for the scope of

Guideline 2〜6

the measures, the level of the measures and measures
examination.

Guideline 5,7,8

As an example of implementation, it is described the abnormal
detection and the study on countermeasure.
It is described for securement of the flexibility and the ease of

Guideline 6

carrying out of management by implementing the security
measures at the lower layer.

Guideline 4

Guideline 6

It is described for the study of the mechanism that does not fatal if
specifications are published.

Same as Guidelines 10
It is described for mechanism to detect the program which is

Guideline 5,7Maintenan ensure

after market

prioritization for the object to be protected and localization of thedomain that is to be protected.

unspecified entities

protection evenobjects to be protected, and impact of unexpected at the time ofAssuming the risks spread through connections, it is described for
Guideline 1,2

Guideline 11 Designing to ensure
Safety/Security even when connected tocestrengthening of traceability depending on prioritizing of theconnection.

the risks of theSmart-society

DesignGuideline 1,5,8

being executed, identify and record own statusor functions, ormaintain safety/security after the own status the passage of timewith the introduction of traceability.

Guideline 14 Implementing the functions
to maintain Safety/Security even after the(Same as above）

Same as Guidelines 13

passage of time
It is described for strengthening of traceability that is required after
Guideline 15 Identifying IoT risks andproviding information after market release

Operation

Protecting with
relevant parties

Guideline 8

Guideline 16 Informing relevant businessapplicable in this book.

after market releaseconnections known to general users

The transmission of information is not applicable in this book.

Thorough to the well-known to relevant business operators is notoperators of the procedures to be followed n/a

Guideline 17 Making the risks caused bymarket release.

Thorough to the well-known to general users is not applicable inn/athis book.

22

Table 4-2 Corresponding part of this book that corresponds to “IoT Safety/Security
Guidelines”
IoT Security Guidelines
Major item
Policy and

Policy 1 Establish basic

Corresponding points in this document
Chapter

Guideline

Overview

numberPoint 1 Managers commit to IoT security

Managemen policy considering the

Point 2 Preparing for internal fraud andtnature of IoT

error

Policy 2 Recognize thePoint 3 Identify what you should protect

risk of IoT

n/a
Guidelines 5
Guideline 1

Point 4 Assume risks due to connecting

The formulation of the basic policies is not applicable in this book.
Describes the mechanism to detect internal fraud and errors
Describes the prioritization of information and assets to beprotected and the selection of the objects to be protected.
Describes how to prioritize the objects to be protected against

Guidelines 1, the possible risks of connection and to augment traceability, with
5, 8

unexpected behaviors upon connection and other factors taken
into consideration.

Analysis

Point 5 Assume the risk of spreading

Guidelines 1,

through links

2

Point 6 Recognize physical risks

Guideline 8

Point 7 Learn from past cases
protect something torisks of connection.
Describes how to augment device traceability against physicalrisks.

Guidelines 2 Exemplifies the method of implementation with regard to its
to 6

Point 9 Design that does not disturb

scope, action level and action review.

Guidelines 5, Exemplifies the method of implementation with regard to error

opponent

7, 8

Point 10 Take integrity of design to realize
safety and security

Designlocalize the domains to be protected by allowing for the pervasive

Guideline 5 Same as Guideline 2

Policy 3 Review designs to Point 8 Identify what you should protect
protect

Describes how to prioritize the objects to be protected anddetection and action review.
Describes how to maintain flexibility and assure the ease of

Guideline 6 management by taking security actions at an as low a level as
possible.

Point 11 Design to ensure safety andsecurity even when connected with

Guideline 4

unspecified opponent
Point 12 Verify and evaluate designs thatrealize safety and security
Policy 4 Consider

Point 13 Provide the function to grasp andcountermeasures on therecord what kind of condition it is itself

network

Describes how to explore a framework of avoiding criticalsituations when specifications are published.

Guideline 6 Same as Guideline 10
Describes a function for assuring safety and security over
Guidelines 5, extended periods of time even when changes occur in the own
7state based on a scheme of detecting active programs andtraceability.

Construction

Point 14 Appropriate network connection
depending on function and application
Point 15 Take note of initial settings

Guidelines 7, Describes traceability upon network connection and the start of8

Point16 Introducing authentication

Guideline 4

function
Policy 5 Sending andPoint17 Maintaining safe and secure state Guidelines 5,

sharing information

after shipment and release7

Point 18 Grasp the IoT risk even after
Operation
andmaintenance

use to verify a successful network connection.

Guideline 8 Added considerations for initialization in augmenting traceability.
Same as Guideline 11

Same as Guideline 13
Describes how to augment traceability, which is required after

shipping/release and tell people what they Guideline 8 shipment. Announcement to personnel concerned is out of thewant to protect

scope of this document.

Point 19 Have the general user know
about the risk of connecting
Point20 Recognize the roles of person
concerned in IoT system services

n/aInformation dissemination/sharing to person concerned is notcovered by this document

Point 21 Grasp vulnerable functions andraise appropriate attention
Rule 1 We refrain from purchasing/using equipment and services thatFor general

Rule 2 Be aware of the initial setting

users

Rule 3 Turn off the power for devices that no longer use

n/aRule 4 Erase data when letting go of equipment

23

Thorough notice to general users is not covered by this document





24





25



Policy 5: To adopt a mechanism for replacing security measures that cannot beapplied.
As mentioned in Premise 5 of Section 4.1, there may be measures that cannot beapplied due to operational constraints. In such cases, alternatives to these measures need
to be considered.
For example, if a virus check cannot be applied, it would be necessary to substitute thevirus check with another mechanism of virus (malware) detection (Execution program
monitoring) that is equally effective.
One alternative is to introduce a white list structure for detecting a program (execution
program monitoring) that is not permitted to run. A scheme of assuring an equivalent ofsafety by blocking any software other than that listed on the white list from launchingshould be explored. In addition, if there is a deficiency in the registration process of thewhite list, due to the risk of the malware not being correctly registered on the list, themanagement man-hours for detection and verification are expected to be included as
acceptable costs. In addition, a scheme of monitoring active programs in the POS terminal
and detecting the drivers of illegally connected peripheral devices, such as optic devices
or USB memory devices, shall be explored. It is also necessary to consider taking
appropriate actions, such as aborting the execution of abnormal programs or illegal drivers
and separating them from other networks when any abnormal conditions are detected,
because they could exert a ripple effect on other IoT devices and systems.


Policy 6: To ensure flexibility of the existing specifications and operations as much as
possible
Normally, risks occurring in a POS system are traceable to internal frauds, illegal

accesses, attacks or external interfaces, or an entry point of malfunctioning data fromother devices. Measures that target risks beyond control of an individual POS system are
typically explored on the upper POS system. However, in a multi-level POS system design,
it is preferable for the lower layer to have versatility and a simple functional structure thatallows security restrictions to be imposed at that level. This is because if a multitude of
constraints has to be implemented in the upper layer, then there are excessive restrictions
that have to be imposed to specifications and practical use, and flexibility is lost. In otherwords, it is much easier to implement security measures at the lower layers than at theupper ones.

26



Policy 7: To keep the costs of implementing measures as low as possible
Security measures cannot be effective for the whole of society if the cost of

implementing measures and operational maintenance is not low. This is achieved byclearly classifying the information and assets to be protected, minimizing the domain size
to be protected as much possible, and realizing the protection at a lower level.
On the other hand, if all the security countermeasures are completed by a particular pieceof software, or device, etc., this is disadvantageous not only in cost, but also in the ease ofan omission being made. Such an approach will also make it difficult to ensure theflexibility of specification and operation.
As described in the Premise 4 of Section 4.1, it is necessary to prevent tampered or
unauthorized devices being connected. However, if the security measure is applied only tothe regular device with a tamper-resistant mechanism, this will increase not only the costof the POS terminal, but it will mean that it can only be repaired at a repair center withadvanced security measures. As a result, not only the maintenance cost rises, but also its
lead time becomes longer, and the flexibility of the use of the terminal becomes greatly
diminished.
Therefore, a more effective method is considered to be the introduction of traceability inorder to compensate for the security deficiencies of software and devices. Including theappropriate traceability function isn’t a significant obstacle in terms of practical use andmaintenance, and it also maintains flexibility.
The advent of the age of IoT is expected to be advantageous as a future effective
security measure, since it can be expected that the infrastructure needed for traceability
will be greater and the costs will be lower.
As a final point about traceability, not only the operational phase, but also the destruction
phase should be considered.



Policy 8: Strengthen traceability.
In the P OS field, we will consider strengthening the traceability from the viewpoints (1)to (4) below.
When using POS, strengthening of traceability is required in the following four areas.
Further, where traceability is augmented, a scheme of recording and retaining POS states(firewall policy settings, anti-virus software installation, engine and pattern file versions,network settings and more) shall be explored.

27

(1) Traceability in implementing and networking POS systems
POS systems traditionally used on special-purpose machines or leased lines havebecome increasingly open to encompass general-purpose tablet terminals and wirelessLANs and other public networks. From a viewpoint of store network threats, a schemeof initializing POS networks and recording and retaining POS network operation
settings shall be explored in implementing and networking POS systems.
[Examples of network setup items that need to be confirmed and recorded on a
general-purpose POS system]- Browser settings- Email settings- Remote connection settings- telnet and FTP server function settings (legacy service feature settings, protocols)- ssh server function settings- File sharing function settings and more

(2) Traceability of information properties for important devices
It is usually the case with POS operations related to the processing of returned-goods
that once the receipts for the returned-goods are collected from a customer, and theprocessing of the returned-goods is performed after checking the past transactions, it ispossible to complete return processing without a receipt on-site. This means that even if
there have been no previous transactions, it is possible to remove money, coupons, etc.
via a bogus return processing operation.
For essential devices that contain sensitive physical or information assets inside, suchas card readers and change dispensing machines, a scheme of retaining credit
transactions or payment/receipt processing logs shall be explored to reject possibly illegal
payment/receipt requests that have no previous records of transactions.

(3) Traceability of important devices for maintenanceAs described in Premise 4 of Section 4.1, the traceability of important devices to be
managed needs to take into account the possibility of “an illegally remodeled andunauthorized device that may be connected to the system”.
This means that a mechanism to record in order to notify and inspect the removal of eachdevice is required because leakage or loss of critical information and assets can be28caused by connecting an unauthorized device.
(4) Traceability of maintenance work
The following possibilities must be considered in terms of the traceability of maintenancework.
1) The security may be compromised due to a mistake that occurs during key encryption,even if the task is completed with critical devices in the manner described in the above
section “(1) Traceability of assets in critical devices”.
2) Loss or leakage of critical information initiates unnecessary maintenance work, suchas a change machine becoming locked due to the physical key being lost by a person ofmalicious intent.
It is necessary to pursue traceability and verification in order to guarantee thatmaintenance tasks such as encryption key configuration and a regular change of thephysical key in the encrypted communication are properly executed.

4.3 Security concepts for credit transactions
Security measures for credit information relating to credit transactions should implement
measures on the basis of the “Action plan for the strengthening of security measures incredit card transactions, 2016” (H28.2.23 publication) of the “Credit Transaction Security
Council”. These have been defined separately below:(1) POS credit transactions must be separate from credit processing functions
To enable protection during credit processing, the following items are required as
security information:- Card information (magnetic/IC)- Personal identification number (PIN)
Handling of this sensitive information should be separated from POS physically andfunctionally, as specified in the implementation plan.
(2) Non-retention of security information
The purpose of separating the payment procedures from the settlement procedures of
the POS is to remove unnecessary card information being retained on the POS system.
This is achieved by not recording the card information from the terminal dedicated tosettlements.

29

(3) Dedicated security standards for credit transactions
Security standards for credit processing, as well as international and othercertification standards have been established and defined by each international brand of
credit card. These standards are in addition to the policies that are listed in (1) and (2),since the certification for international brands is required to be based on EMV and PCI
standards.

30

5 The Development Phase and Security Measures
5.1 Definitions of the phases in the life cycle
The system development has a life cycle that continues from planning to disposal. It is
important to consider security during every phase of development.
This chapter provides an overview of a typical system development life cycle (SDLC),
and the action on security that takes place during each phase. More details can be found in
the following publication: NIST SP800-64 “Security Considerations in the System
Development Life Cycle”.
The system development life cycle can be roughly divided into the following five phases.

Initiation

Develop-ment

Deployment

Operation
andmaintenanceDisposal

Figure 5-1 Phases in the life cycle

Table 5-1 Definition of the phases
Phase

Description

Initiation

During this phase, the system requirements are clarified and purposes are
documented.
Taking security into consideration is very important in the first phase of
SDLC.
Security activity in this phase includes the following:• Clarifying the outline of business requirements in terms ofconfidentiality, integrity and feasibility.
•Classification of information and clarification of handling requirements
such as transmission and preservation of personal information etc.
• Clarification of the privacy requirements.
Evaluating the security of the whole project from the start will lead tosavings in cost and time by creating the appropriate risk management planin the early stage of development and allowing concerned parties to be
notified in advance.

Development

Design and development of the system takes place in this phase.
The main security activities in this phase are as follows:• Performing a risk assessment study to obtain results that will
supplement the baseline security measures.
• Analyzing security requirements.
• Performing functional and security testing.

31• Providing documentation for system and practical use approval.
• Designing security architecture.
Deployment

During this phase, further development of the system takes placefollowing an acceptance test.
The main security activities in this phase are as follows:・Adaptation of the security measures to the system’s parameters.
・Planning and executing activities suitable for the system.
During this phase, it is usual to conduct a test of adherence to security
management policies.
・Complete authorization procedures for managers of the system.

Operation andmaintenanceThis phase represents standard operation of a system, which can bechanged at any time by adding new hardware and software.
The main security activities in this phase are as follows:・ Establishing the steps and procedures for safety operations andproviding continuous monitoring of the security management
measures for the system.
・Implementing reauthorization, if necessary.

Disposal

The final phase occurs if it is necessary to provide a controlled
shutdown of a system, protect important information and transfer data
to a new system.
The main security activities in this phase are as follows:・Purging media records
・Discarding the hardware and deleting the software

5.2 Action required during each phase
Below is a description of the security measures that need to be taken in each phase of
the life cycle of system development outlined in the previous section.
Since the POS is the target of development, the word “system” in “system development”
has been replaced with the word “product”.

5.2.1 Initiation phase
In the initiation phase of the life cycle of product development, the following security
measures are required:

Table 5-2 Security measures during the initiation phase
No

Life cycle of product development32

１

Formation of a security plan
As the initiation phase is the first step of the product development cycle, it is vital to
make a plan for security from the outset. The following procedures are normally
carried out in a security plan.
・Determination of the important role security will play in product development,
especially in terms of the information about the system security that will bedisseminated to the staff.
・Establishing the basis of security requirements (laws, regulations and standards,etc.).
・Coming to an agreement with all of the main people concerned in the implications,considerations and requirements of the system’s security.
・Devising an overall security projection (draft level).

2

Classification of security level by the product type.
Classification of the type of product to be developed to determine the security level
required.

3

Evaluation of the possible impact of security issues on the business.
Clarification of what the effects on the business might be if a security problem occurs
with respect to the product.

4

Formation of a policy on personal information
Consideration of whether or not to convey, store and create information related topersonal information for the product targeted for development.
If it is decided that the product targeted for development requires the use of personal
information, appropriate protective measures and a security management plan must
be carried out.

5

Implementation of the secure product development process
The primary responsibility for security in the early stages lies with the development
team. They have the greatest understanding of every detail of the product’s features,and thus are best able to identify the security flaws in functionality and businesslogic. Utilization of this team is the key to planning the construction of the protective
environment to the source code level and successful implementation of the team’splan can only be achieved by conveying what is expected of them.

5.2.2 Development phase
In the development phase of the life cycle of product development, the following security
measures are required.

Table 5-3 Security measures during the development phase
No.

Life cycle of product development

１

Risk assessment
The purpose of risk assessment is to evaluate the system’s design, system andsecurity requirements, as well as estimate the effect of these measures in reducing

33

the risks assumed.
The results of the evaluation normally show clearly whether the security
countermeasures concerned will be enough, or if further consultation is required.
To perform a successful evaluation, the participation of the relevant person (user,
engineer, or system operators, etc.) who is familiar with each field of the systemdomain is required.
Before the design specification is approved, a security risk evaluation should be put
into effect. This indicates if subsequent revisions or additional measures should be
included.
2

Choice of security measures
The security measures adopted during the product development stage are a
combination of measures common to this type of development process and theresults of the above-mentioned risk evaluation.

3

Security documentation
Create security documentation from the following viewpoints to cut the cost of
systems development activity and to have security requirements precisely
integrated into the design and development process:- Configuration management plan
- Emergency response plan (including business impact analyses)- Continual monitoring plan
- Security awareness enhancement, training and education (SATE) plan
- Incident response plan
- Privacy impact assessment (PIA)

4

Security design
It is important for all parties to understand how security will be included in a
product. Security is therefore incorporated into the product at the design stage.

5

Development of security design and measures
Suitable security measures are designed and incorporated.

6

Implementation of the developmental, functional and security testing
Tests must be conducted within the system, software, hardware, andcommunication channels to determine if there needs to be further developments ormodifications.
The purpose of the tests is to verify that the system meets functional and security
requirements.

5.2.3 Deployment phase
The following security measures are required during the deployment phase of the life
cycle of product development.

34

Table 5-4 Security measures during the deployment phase
No.

Life cycle of product development

1

Security approval and operation authorization planning
The system operation authorizer, responsible for approving the risks of system
operations, shall plan a review with the development team with regard to security
impacts.

2

Integration of security measures within the environment or system in which
probability has been carried out
In an operational site, products are integrated as a system. Integration testing andacceptance testing are carried out when the product has been delivered anddeployed.
Security measures are put into effect according to the vendor’s directions, available
guidance on security implementation and documented security specifications.

3

Evaluation of product security
Evaluation is carried out to verify that the product meets functional and security
requirements.
Before an organization begins to use a product, security approval should be put into
effect to estimate whether measures have been properly introduced, and how wellthey operate as intended.

4

Approval of the information within the system
According to the results of the previous system evaluation, checks and approval
determine whether security measures are achieving the level that had beenpreviously agreed upon, or whether residual risks fall within the tolerance level.

355.2.4 Operation and maintenance phase
During the operation and maintenance phase of the life cycle of product development,
the following security measures are required.

Table 5-5 Security measures during the operation and maintenance phase
NOLife cycle of project development

1

Verification of the state of readiness to migrate to the system production
environment
If system changes associated with migration to the system production environment
are involved, evaluate the security impact at this stage to ease risks.
Implementation of configuration management

2

The management of the system’s layout is very important in terms of maintenance,
as it is necessary to confirm that the initial constitution of hardware, software and thefirmware components related to the data within the system and product are working
as intended, and change the current system and product if they are not.
Implementation of ongoing monitoring

3

Monitoring of the effectiveness of security measures needs to be maintained
continuously, even if there is an unavoidable change in the environment where a
product is being managed.

5.2.5 Disposal phase
During the abolition phase of the life cycle of product development, the following security
measures are required.

Table 5-6 Security measures of the abolition phase
No.

Life cycle of system development

1

Abolition/migration planning
Create an abolition/migration plan to share the system and information with all
personnel concerned. Planning should allow for key components, services andinformation abolition/migration status records.

2

Information storage
In storing information, fully consider whether that information may be needed in the
future or will be available. Allow also for legal requirements in the event of abolition.

3

Erasure of media data
The organization ensures that all appliances/procedures function correctly by meansof tracking, documenting and verifying media data erasure and other destructive
procedures.
Periodical
tests
are
also
performed
ondata
erasing
apparatus/procedures.
Data erasure and destruction prior to discarding the digital media of the information

36

system, or re-using it outside the organization, prevents unauthorized access anduse of any of the information included in the media.
4

Disposal of hardware/software
The software is disposed in accordance with the license, developer, or othercontracts/regulations. In terms of hardware, destruction and disposal is required ifclassified information remains even after the media has been removed.

5

System closure
Verify the documents needed to close the system.

5.3 Guidance of the security measures within each phase
This section summarizes which action items for security guidelines are described in
Chapter 4.
The life cycle of each system development shown in Table 5-7 corresponds to the numbersof the policies to be applied as listed in these POS guidelines.

Table 5-7 The security measures of each phase
Phase

Initiation

Development

No.

Life cycle of system

POS policy

development11

Formation of a security
plan

●

2

Classification of the
product type●3

Evaluation of impacts on
the business●4

Formation of a policy on
personal information●

5

Implementation of the
secure productdevelopment process

1

Risk assessment

2

Choice of security
measures

●

●

●

●

3

Createadocument

●

●

●

●

●

4

Security conception
design

●

●

●

●

●

5

Development of security
design and measures

●

●

●

●

6

Implementation ofdevelopmental,functional and security
testing

●

●

●

●

2

3

4

5

6

7

8

●
●

security

37

●

1

Plan for security
approval, operation
approval●

2

Integration of security
measures for theestablished environmentor system●

3

Evaluation of productsecurity●

4

Approval of theinformation within thesystem●1

System Preparation
status confirmation forthis environmenttransition●

2

Implementation ofconfiguration
management●

3

Implementation of
ongoing monitoring●

1Create a discontinuation/ transition plan2

Deployment

Maintenanceandoperation

Disposal

●

●

●

●

●

●

●

●

Save information

●

●

●

3

Erasure of media data

●

●

●

4

Disposal
software

●

●

●

5

Close the system

●

●

●

of

hardware/

6 Conclusion
This book of security guidelines was published with the intention for application in the fieldof open POS.
However, it is believed that the guidelines can be applicable in other areas, such as action
on security when threats are assumed to exist in other forms of life cycles.
It is hoped that the guidelines will be used widely to consider the security measuresrequired in the development process of a variety of products. It is intended that further
revisions of these guidelines will be produced based on feedback from inspection results
and further insights that arise from the utilization of the security measures described inthese guidelines.

38

7 Appendix
Security Requirements Self-Check List
Review process
No.

Check item

Perspective: clarification of information to be protected· Is the study and countermeasures compliant with the security countermeasureguidelines of "Security Guidelines for Product Categories - OPEN POS -"?
Threat example:· Open POS security measures remain missing, and there is risk of information leakage,eavesdropping, impersonation and so on.

□ Review and take action on the basic policy that conforms to thesecurity measures guidelines.

12

Perspective: continued use· Are you considering the operation of security measures such as updating OS andupdating antivirus software?
Threat example:· Potential security holes will remain.

□ Analyze information to be protected and consider measures.
□ Consider a design that will not become fatal even if it is attacked.
□ Connect to the Internet only when necessary.
□ Update the update file manually.

3

Perspective: peripheral device□ Control so that it can not be used in applications.
· Is there a free USB port on the POS?
□ Disable USB port at BIOS level.
Threat example:□ Attach a cover to the USB port.
・Leading to data extraction, information leakage. (Security aspect)· Immediately after inserting, unexpected screen becomes active, and operation becomesdisabled. (Operation surface)· There is a possibility of virus infection from USB memory.

4

Perspective: unknown equipment· Do you deal with the connection of peripheral devices not related to the POS system tothe network?
Threat example:· It is connectable to equipment that steals information□ Register the hardware that can be connected to the network.
□ Do not set the key for connecting to the network to a vulnerable
number (such as 1234).
□ Manage keys for connecting to the network.

5

Perspective: Storage of data
· Have you saved transaction data in clear text?
Threat example:· Transaction data is stolen and abused.

6

Perspective: Storage of data
· Have you left transaction data in POS?
Threat example:· Transaction data is stolen and abused.

7

Perspective: wiretapping of wired communication data
· Do you handle telegrams of credit transactions in plain text in in-store LAN?
Threat example:· Credit transaction information is stolen from communication messages on the networkand exploited.

□ Design with no data saving.
□ Build a function to encrypt data. (It can not be seen even if it isstolen)□ Erase the data on the basis of the period and quantity. (Reduce theamount of leakage)□ Design with no data saving.
□ Build a function to encrypt data. (It can not be seen even if it isstolen)□ Erase the data on the basis of the period and quantity. (Reduce theamount of leakage)□ Design a mechanism to encrypt communication.
□ Construct a configuration that can not be tapped by restricting thedevices connected to the network.

8

Perspective: wiretap of wireless communication data
· Do you consider security measures when wirelessly using the in-store LAN?
Threat example:· Easy to see from the outside for wireless. If security is weak, the contents of LAN
communication may be seen from the outside.

□ Use a wired LAN.
□ Encrypt LAN communication.
□ Make sure not to see the access point.

9

Perspective: communication port
· Is an unnecessary port open?
Threat example:· If an unnecessary port is open, there is a possibility of receiving an external attack.

□ Close unnecessary ports.
□ List and monitor the services to be operated.

10

Perspective: Rights Management Vulnerability·Is there any danger that any management tool can be used by anyone?
Threat example:· Password of highly authorized login ID (store manager etc) can be changed.
· You can change (enlarge) your usage authority.

□ Design to limit users such as setting user authority functions.
□ Management system tools are not placed in POS used by generalusers.
□ Management tools are only accessible to authorized users.

Perspective: Disability investigation· Does the minimum log output necessary for recovery be output even at the time of thelocal defect investigation?
Threat example:· Information unnecessary for investigation is output, resulting in information leakage.

□ Design that takes into consideration that defects can beinvestigated without including personal information.
□ Perform designs that allow for decryption and investigation after
acquiring local data.
□ At the time of investigating the problem, decrypt it offline andencrypt again before online.

12

Perspective: Disability investigation· When a failure occurs during trading, are you outputting transaction information at thetime of failure to printing or log?
Threat example:· In order to recover the transaction information, it is possible to peep at the informationby printing or logging the information that was originally encrypted in the non-encryptedstate.

□ Take measures to ensure that only certain authorized persons canread the transaction information.
□ Following the rules guaranteed security, discard the output printing
and logs.

13

Perspective: Password vulnerability· Are you taking countermeasures when your usage password is weak (such as 1234)?
Threat example:· Login ID of managerial level with high authority is impersonated as a regular clerk orpart time job is used.

□ It is designed to lead input from the password initialization stage sothat it becomes a complicated password.
□ Define operational rules to periodically change passwords.
□ Educate users not to set an easy password.

Perspective: Services· Is not unnecessary service (function) activated?
Threat example:· When an unnecessary service (function) is activated, there is a possibility of receiving
an external attack.

□ Stop unnecessary services (functions).
□ List and monitor the services to be operated.

14

15

Perspective: unknown application· Do you deal with actions of applications not related to work?
Threat example:· Infect with malware and steal data.
· Unnecessary load is applied to hardware.

□ Monitor running applications and consider preventing operation of
applications not related to work.
□ Set POS so that applications can not be installed.
□ Educate and instruct user not to install applications.

16

Perspective: User's POS operation status
Perspective: external access· Do you looke at a website not related to work on POS?
Threat example:· There is a possibility of virus infection by connecting to the external website.

□ Restrict communication of POS going outside the local network.
□ Establish operational rules that do not browse the homepage at
POS.
□ Educate and instruct user not to browse the homepage.
□ Define operational rules to log off when you leave.
□ If there is no operation for a few minutes, activate the screen saver
and provide a password request function to restore.

17

Perspective: User's POS operation status· Are you considering correspondence, assuming a situation where you are away from
POS while logged on?
Threat example:· A person different from the user who logged on to the POS can be used and can bemasqueraded.
·It can tamper with data and perform fictitious transactions.

18

Perspective: User's POS operation status· Are not you using one POS login ID in multiple?
Threat example:· When trouble occurs, it is impossible to judge who used it.

□ Have an individual ID.
□ Ban multiple simultaneous use with one login ID.
□ Do not use another person's ID, do not let it use.

Perspective: User's POS operation status· Have you logged in with a barcode?
Threat example:· Once the login ID is known, a third party can copy the barcode, and it can be used byothers (impersonation).

□ Establish operational rules such as manually entering passwords.
□ Do not use bar codes for POS login.

19

11

Measure example

Maintenanc
User
PolicyConstre
educatioManag Analysis Design
uctionement
Operation
n

●

39

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

●

Remarks(fill in at
check)

References[1] H. Takada, A. Goto and et al., "IoT Safety/Security Development Guidelines,"
Information-technology Promotion Agency, Japan (IPA), First Edition, 2016,
https://www.ipa.go.jp/english/sec/reports/20160729-02.html[2] The Council on Measures for Security in Credit Transactions, "Compilation of an Action
Plan for the Strengthening of Measures for Security in Credit Card Transactions -2016-,"2016,
http://www.meti.go.jp/english/press/2016/0223_02.html[3] NIST, "Special Publication 800-64 Revision 2: Security Considerations in the System
Development Life Cycle," National Institute of Standards and Technology (NIST),First
Edition, 2008,https://csrc.nist.gov/publications/detail/sp/800-64/rev-2/final[4] US-CERT, "Alert (TA14-002A): Malware Targeting Point of Sale Systems," UNITEDSTATES COMPUTER EMERGENCY READINESS TEAM (US-CERT), First Edition, 2014,
https://www.us-cert.gov/ncas/alerts/TA14-002A[5] IoT Security Guidelines, Basic Items to be Approached to Assure Security, IoT
Acceleration Consortium, Ministry of Internal Affairs and Communications, Ministry of
Economy, Trade and Industry
http://www.meti.go.jp/english/press/2016/0705_01.html

40