• Ingen resultater fundet

Security Objectives

In document Security in POS Systems (Sider 37-41)

2.4. SECURITY OBJECTIVES CHAPTER 2. PP

It indirectly counters T.ACCESS and T.MODIFICATION because if attackers successfully compromise the security of the TOE, administrators are able to see what the attackers have been doing and thereby maybe reducing the damage done. This, of course, presumes that the attacker have not managed to change the security audit as well.

O.DATA_FLOW For attached input/output devices a data ow control policy based on a threat analysis shall be made for each identied data ow. This is done to accommodate the dierent demands to secure communication of the devices.

This security objective is identied to counter the threat T.DATA_FLOW.

It assures that a threat analysis of each identied data ow is conducted in order to be able to make a data ow control policy. This ensures that the suit-able level of protection of the data ows is implemented. The threat analysis and data ow control policy is discussed in section 2.2.3.

O.SESSION A session shall only be active when an authorized user is interacting with the TOE interface. Therefore, the TOE shall provide functionality for the user to lock the current interactive session. It should also be possible for the TOE to automatically lock the session if the user is considered inactive. The user must re-authenticate to unlock the session. Furthermore, the user should re-authenticate before each sale and/or payment transaction.

This objective is mainly identied to counter T.UNATTENDED_SESSION.

By assuring that a session is only active when an authorized user is at the TOE interface the threat of an attacker taking advantage of an unattended session is eliminated. When the user leaves the TOE an automatic lockout procedure shall be initiated. This may be in form of a timeout interval or it can be by re-moving a smart card used for identication and authenticating. A session is in this context dened as the execution of a complete sales transaction including registration of goods and payments.

By demanding that the user shall re-authenticate before each sales transac-tion, P.ACCOUNTABILITY is also addressed because one operator can not overtake another operators session between sales transactions. This will be the case even if the TOE interface was not considered as unattended by the operator during the intervening period.

O.BACK-UP The TOE shall provide functionality for administrators to back up the data in the system in order to make it possible to restore, as a minimum, the audit trail in case of hacking, hardware failure, re, theft, force majeure, etc.

This security objective is identied to counter T.PHYSICAL. It ensures that

CHAPTER 2. PP 2.4. SECURITY OBJECTIVES

the TOE supports a backup mechanism so, at least, the audit trail can be re-stored in case of physical loss.

Also, if the audit trail is maliciously modied or deleted, e.g. in connection with unauthorized modication by an attacker, the security objective may be restored from the backup and by that countering T.MODIFICATION.

2.4.1 Security Objectives for the Environment

The above described security objectives are those to be complied with by the TOE itself. The security objectives described in this section are those to be complied with by the TOE environment. Normally, these objectives will be divided into security objectives for the IT and non-IT environment respectively. As the generalized model of the POS system is supposed to be self-contained as an IT system it will not have any security objectives for the IT environment. For the general non-IT environment the following security objectives are identied:

OE.TRAIN The overall responsible for the TOE shall arrange training for all au-thorized users of the TOE including the administrators.

This objective is mainly identied to address A.NO_EVIL and P.TRAIN.

It assures that users, including administrators, are trained in secure use of the TOE and thereby staying competent. In addition, the objective counters T.INCOMPETENCE and thereby also T.UNATTENDED_SESSION as secure use of the TOE includes that a session shall not be be left unattended.

OE.ADMIN_VETTING The overall responsible for the TOE shall perform vet-ting of administrators to ensure that they are competent and non-hostile.

This objective has been identied solely to address A.NO_EVIL. It assures that administrators are selected after thorough screening of candidates, thereby signicantly reducing the risk of an administrator being incompetent and hos-tile.

OE.PHYSICAL The TOE shall be physically protected in such a way that attackers cannot remove the TOE or parts of the TOE which are critical to the security of the TOE, or in other ways physically compromise the TOE and the data it contains, i.e. the audit trail, security attributes, etc.

This objective has been identied solely to counter T.PHYSICAL. It assures that the TOE is physically protected, e.g. by keeping the audit trail in a locked and perhaps re-proof location.

Table 2.1 illustrates the relations between assumptions, threats, and OSPs on one side, and the stated security objectives for the TOE and TOE environment on the other side. It demonstrates that the relations are internally consistent as required.

2.4. SECURITY OBJECTIVES CHAPTER 2. PP

O.IA O.MANAGE O.AUDIT O.DATA_FLOW O.SESSION O.BACK-UP OE.TRAIN OE.ADMIN_VETTING OE.PHYSICAL

A.NO_EVIL x x

T.ACCESS x x x

T.MODIFICATION x x x x

T.PHYSICAL x x

T.UNATTENDED_SESSION x x

T.INCOMPETENCE x

T.DATA_FLOW x x

P.AUTHORIZED_USERS x x

P.ACCOUNTABILITY x x x x

P.TRAIN x

Table 2.1: Assumptions, threats, and OSPs in relation to the security objectives.

In document Security in POS Systems (Sider 37-41)