The NORTIC System Security Policy addresses how the threats specified in section 3.2 shall be controlled taking into account aspects such as
• Protection of the Interests of the Public, i.e. Issue of Fairness and Privacy
• Financial Loss detection and prevention
• System design constraints (i.e. cost, functionality and technology limitations with TravelContract)
3.3.1 Protections of the interests of the public
The public interests are founded not only on quantifiable financial aspects but also on human/cultural values. Some overall principles of public interests are formulated below:
• Quality of Service:
The NORTIC system shall be used as an instrument to ensure that national/local public transport service strategic goals are met.
• Fairness of payment:
Customers shall be convinced that everyone is paying the correct amount according to valid charging tables.
• Public Trust:
Customers shall be convinced that they pay the correct amount for the desired service.
• Public Moral:
Deliberate sabotage and fraud should be discouraged and is considered illegal. This is related to the principles of fairness and public trust.
• Privacy:
Misuse of information generated by the NORTIC system shall not be possible.
These principles are of general nature and may not be further specified in specific requirements within this document, but should nevertheless be encountered for and followed within any organisation responsible for public transport services.
3.3.2 Detection and prevention of financial loss
Based on the threat analysis made, many viable attack strategies might be attempted by customers possessing variable skills (various attack classes) that might lead to security compromises. The following strategies to minimise financial loss shall be adopted:
1. Unjustifiable denial of used services shall be discouraged. Routines shall be defined that address the management of disputes between customer and service operator. Due to the different sizes of the various systems accepting a TravelContract, each system
implementation is free to define the control of valid TravelContracts.
2. Sabotage against service operator’s MAD shall be discouraged and is regarded as an offence.
Requirements for sabotage detection (diagnostics) on the MAD shall be detailed.
3. Masquerade attempts against TravelContracts shall be discouraged and are regarded as an offence. Furthermore successful masquerade attacks, such that they lead to financial loss in the ticketing system, shall not be economically viable for the customers. The NORTIC system shall be prepared to countermeasure extensive attempt to conduct masquerade.
4. Cloning attempts of TravelContracts for unauthorised reselling are regarded as an offence and potentially detrimental to the integrity of the NORTIC system. Therefore, within reasonable cost boundaries, maximum technical efforts should be considered to avoid cloning of the TravelContract.
3.3.3 Trust Levels
The NORTIC system implementations may be of different levels of magnitude and cover different regions. Also the exposure levels of the threat may vary not only due to geographical limitations but also might be time dependent. The trust level can be expressed as the goodwill that exists between entities in the NORTIC system that no human imposed anomalies disrupt the behaviour of the NORTIC system. The trust level may vary with time, magnitude and geographical location of the NORTIC system. Finally the implementation of a NORTIC system will reflect the fact that trust levels determine security requirements.
For example, due to the fact that there is a limited number of ProductTC Owners in Norway resulting into a high trust level between them, it is recommendable that ProductTC Owner share a common set of master keys. A Trusted Third Party (TTP) serves as a notary between ProductTC Owners in case of any conflict.
Another example, due to the exposure level due the amount of customers and the financial consequences in case of successful fraud (say reselling cloned TravelContracts) it may be recommendable (but not required) to introduce online verification of TravelContracts.
3.3.4 System specific constraints Performance factors
The NORTIC system shall ensure maximum revenues for the Product owners/Retailers and correct service to the customers having a valid TravelContract.
This includes performance factors such as (but not limited to)
• MAD Capacity of handling number of customers with valid TravelContracts
• Flawless implementation of system functions
• Available system modules
• TravelContract Transaction time (with ProductLP Retailer MAD)
These factors provide important constraints for formulation of security requirements, most notably those related to real time verification of the authenticity of the TravelContract.
System Cost
With system cost, is meant the total ownership costs of the NORTIC System including the costs related to:
• Purchase/ implementation/ installation/ distribution
• Maintenance / operation
• Financial Loss (due to security compromises or non-available system modules and services) Naturally, system costs are highly related to the magnitude of the system (and expected revenues).
The relevance of considering the system costs within the security policy considerations is that a best possible compromise must be searched in each implementation. The level of trust between the entities in a NORTIC system implementation and the system magnitude will in each case determine the security level.
Therefore, and due to the fact that different implementation scenarios of this specification are indeed foreseen, the security requirements must cater for the fact that actual NORTIC system
implementations might focus on minimising implementation costs whereas others might focus on maximising the income flow.
Cost and Technology limitations
As pointed out in the last section, implementation costs may be the most important economical factor in some systems to meet profitability requirements. Some security relevant critical factors are listed below:
• TravelContract media will have a maximum data communication speed and processing capabilities (mainly related to encryption speed and product data access times). Applicable technology may range from dedicated media accommodating for a minimum set of
NORTIC functions – to multi-application supporting media accommodating for both TravelContract and other, possibly non-transport, applications.
• TravelContract Medium Accepting Device (MAD) will have a limited memory capacity for Products and transaction data, limited processing capabilities and it may or may not have support for Secure Application Modules (SAM).
• TravelContract SAM may have limited capacity for supporting different Products and will have a maximum data communication speed and limited processing capabilities
The security requirements shall cater for the above constraints.
It shall be noted that it is not mandatory to include a SAM in the Service Operator MAD.
Critical Roles and Responsibilities within the NORTIC System
The following roles/responsibilities have been identified as the most critical for the security policy.
1. Issuing of TravelContract and TravelContract SAM shall be possible by ProductTC Owner.
However it has been recommended restricting the TravelContracts to share a common TravelContract master key set. This TravelContract Master Key set will be generated and distributed through a Trusted Third Party (TTP) to each authorised ProductTC Owner.
2. Distribution of TravelContract, TravelContract SAM and MAD shall be done in a secure way in the sense that the ProductTC Owner or corresponding entity is responsible that the concerned modules do not fall into the hands of unauthorised parties. This includes:
• TravelContract must only be distributed to customers identified under a valid contract. The ProductTC Owner is responsible for the security of the
TravelContract, including the detection of un-authentic TravelContracts, ensuring adequate measures (such as security listing and introduction of TravelContract SAM for online verification). Furthermore the ProductTC Owner is responsible for recovery from related financial loss towards Retailer(s)/Clearinghouse(s).
• TravelContract SAM must be installed in MAD or at a centralised office of the ProductTC Owner. The ProductTC Owner is responsible for the administration and logistics of each individual SAM (including keeping them protected against theft).
• MAD must only be distributed and installed at locations intended for control and/or validation of TravelContracts. The ProductTC Owner is responsible for the
administration and logistics of each individual MAD (including keep them protected against theft).
3. Management of sensitive data and modules (keys, TravelContract SAM, TravelContracts) involves the following processes:
• Generation
• Distribution
• In/Revalidation
• Destruction
Due to the criticality and nature of the threats to the concerned system modules, security requirements to all these modules and the related processes must be formulated.
4. Authentication of TravelContract is under the responsibility of the ProductLP Owner or ProductLP Retailer respectively, which also might choose to trust TravelContract on his own risk.
5. Authentication of Transaction Messages is under the responsibility of the ProductTC Owner and/or Clearing House, which also might choose to trust TravelContract on its own risk.
6. Verification of disputes between Customer and ProductTC Owner/RetailerTC shall be enabled through electronic proofs contained in the TravelContract and Transaction Messages resided in the system. The ProductTC Owner/ ProductTC Retailer is responsible of providing such services to the public.
7. Verification of disputes between Product Owners/Retailer/Clearing Houses shall be enabled through electronic proofs contained in the Transaction Messages resided in the
system. A duly appointed notary / TTP is responsible of providing such services between Product Owners.