TIA-PN-4940 - Telecommunications Industry Association

PN-4940.050: Smart Device Communications;

Capabilities Aspects; Introduction

1

2

3

4

5

6

Contents

It is convenient to omit the Table of Contents during document development. An automatically generated Table of Contents may be inserted here by updating the document custom property 'Status' to anything other than 'draft' and then updating this field.

Contents | i

PN-4974: Smart Device Communications;

Security Aspects

1

2

3

4

List of Figures

It is convenient to omit the lists during document development. An automatically generated list may be inserted here by updating the document custom property 'Status' to anything other than 'draft' and then updating this field. ii | List of Figures


Security Aspects

2

3

4

5

6

7

8

1

9

10

11

12

13

14

15

16

17

Foreword

(This foreword is not part of this Standard.)

This document was formulated under the cognizance of the TIA Committee

TR-50, Smart Device Communications.

The contents of the present document are subject to continuing work within the Formulating Group and may change following formal approval. Should the Formulating Group approve modification, the present document will be rereleased with an identifying change of release level, for example:

TIA-4940.050-A revision level part number standard number

The document contains informative annexes.

Suggestions for improvement of this document are welcome, and should be sent to:

Telecommunications Industry Association,

Standards and Technology,

2500 Wilson Boulevard, Suite 300

Arlington, VA 22201-3834

Foreword | iii


Security Aspects

1

2

8

9

10

11

12

13

14

3

4

5

6

7

15

SCOPE

The guidance provided in this publication is intended to address only the management of cyber security related risk derived from or associated with the operation and use of information technology and systems and/or the environments in which they operate. The guidance is not intended to replace or subsume other risk-related activities, programs, processes, or approaches that organizations have implemented or intend to implement addressing areas of risk management covered by other legislation, regulation, policies, programmatic initiatives, or mission and business requirements. Additionally, this guidance is not part of any regulatory framework. Rather, the cyber security risk mitigation guidance described herein is complementary to and should be used as part of a more comprehensive enterprise risk management program. iv | Foreword


Security Aspects

1

2

6

7

8

9

10

3

4

5

1 PURPOSE

The purpose of this document is to provide a guideline to the Machine to

Machine stakeholders to identify and reduce the risk of cyber related vulnerabilities in their systems according to the TIA M2M Reference

Architecture. Vulnerabilities and mitigation recommendations are presented at a high-level to provide awareness of the most common and significant security vulnerability areas.

Foreword | v


Security Aspects

1

2

3

4

5

6

7

8

9

10

11

12

13

14

2 RELATED REFERENCES

This guide is based on the general concepts presented in National Institute of

Standards and Technology (NIST) Special Publication (SP) 800-27,

Engineering Principles for IT Security, along with the principles and practices in NIST SP 800-14, Generally Accepted Principles and Practices for Securing

Information Technology Systems . In addition, US Department of Energy

Idaho National Laboratory September 2011 Vulnerability Analysis of Energy

Delivery Control Systems , US Department of Energy September, 2011 ,

Electricity Sector Cyber Security Risk Management Process Guideline.

Commercial cyber defense references include 20 Critical Security Controls for Effective Cyber Defense, Consensus audit Guidelines volume 3, August

15, 2011 vi | Foreword


Security Aspects

1

2

6

7

8

9

3

4

5

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

3 INTRODUCTION

Machine to Machine (M2M) devices are typically resource constrained devices that often have little added capacity for security. This document considers the overall security of the M2M architecture, including Data in

Transit, and Data at Rest. To understand where the security gaps exist, a thorough understanding of the TIA M2M architecture (TIA 4940) is required.

Protecting the M2M devices against specific threats is considered as a balancing act between the implementation of security versus the impact of a security breach, e.g. business’s reputation, as well as the confidence in a system. To understand the impact of including security within the devices, one must consider the increase of development time and device complexity, the decrease of the devices’ optimal performance, and the increased time involved in verifying the security.

This document is not meant to be an exhaustive detailed list of all the attacks that can and may be initiated, nor defenses to counter them. This document defines an “attack surface” with the emphasis on the possible threats against the TIA M2M architecture. It also defines a risk model, and a method to calculate a risk value by applying an annualized loss expectancy value to illustrate the financial impact that risk decisions create. Section 6, Threats against the Architecture, details a handful of possible attacks that illustrate how secure coding, understanding network vulnerabilities, and trusted secure environments contribute to securing the attack surface.

Section 6 includes a history, purpose, and scope of threat analysis. Section 7 provides a background and explanation on the terms commonly used in the study of cryptography and security management. Section 8 describes data security, including introduction of and definition of the security levels applied to device capability, as well as the multilayer protocol guidance with example use cases. Section 9 describes the attack surface that is vulnerable for compromise. Section 10 discusses and describes the process that was used to quantify the risk assessment. Section 11 presents a summary of vulnerable assets, and the resources to protect each one. Finally, section 12 summarizes general security recommendations for developers and administrators to help mitigate the risk posed by common vulnerabilities found in guidance document.

| 7


Security Aspects

2

3

4

5

1

19

20

21

22

23

24

25

26

27

14

15

16

17

18

6

7

8

9

10

11

12

13

32

33

34

35

36

28

29

30

31

4 Definitions, Symbols and Abbreviations

4.1

This section contains definitions, symbols and abbreviations that are used in this document.

Definitions

For the purposes of the present document, the following terms and definitions apply:

Cleartext : Data that can be read and understood without any special measures.

This term is used interchangeable with “plaintext” in this document.

Encryption : The method of disguising plaintext in such a way as to hide its body.

Ciphertext : Encrypting plaintext results in unreadable text.

Cipher : An algorithm for performing encryption (reverse is decryption).

Decryption : The process of reverting ciphertext to its original plaintext.

Cryptology : Study of both cryptography and cryptanalysis.

Cryptography: The science of using mathematics to secure data via encrypting and decrypting data.

Cryptanalysis: The science of analyzing and breaking secure communication.

Cryptographic algorithm/cipher : A mathematical function used in the encryption and decryption process.

Public Key Infrastructure: PKI is a set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke Digital Certificates. A Public Key Infrastructure (PKI) enables users of a basically unsecure public network such as the Internet to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority .

Key : A value that works with a cryptographic algorithm to produce a specific ciphertext.

Symmetric Cryptography: One secret key is used both for encryption and decryption.

Asymmetric Cryptography : Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption.

Digital Signature : Enables the recipient of information to verify the authenticity of the information’s origin, and also verify that the information is intact.

8 |

10

11

12

7

8

9

13

14

15

16

1

2

3

4

5

6

17

4.2

22

23

24

25

26

27

28

18

19

20

21

29

30

31

32

33

34

35


Security Aspects

Authentication: The process of verifying the identity of entity.

Integrity: The assurance to an entity that data has not been altered

(intentionally or unintentionally) between “there” and “here” or between

“then” and “now.”

Confidentiality: The assurance to an entity that no one can read a particular piece of data except the receiver(s) explicitly intended .

Non-Repudiation : Ensures that an author cannot refute that they signed or encrypted a particular message once it has been sent, assuming the private key is secured.

Hash : A one-way function takes variable-length input and produces a fixedlength output; that ensures the information has not changed in any way.

Certificate: A document that binds a signature to an entity.

Data-in-transit : Data moving between entities in a M2M system.

Data-at-rest : Data that is stored within entities in a M2M system.

Attack Surface : All vulnerabilities that may compromise a system.

Abbreviations

For the purposes of the present document, the following abbreviations apply:

CIA: Confidentiality, Integrity and Availability.

M2M : Machine to Machine.

IoT : Internet of Things.

FIPS : Federal Information Processing Standards.

ECDSA : Elliptic Curve Digital Signature Algorithm.

ECC : Elliptical Curve Cryptography.

DSA : Digital Signature Algorithm.

SHA : Secure Hashing Algorithm.

MQV : Menezes-Qu-Vanstone algorithm.

DH : Diffie-Helman is an anonymous (non-authenticated) key-agreement protocol, it provides the basis for a variety of authenticated protocols, and is used to provide perfect forward secrecy in Transport Layer Security's ephemeral modes.

SSL : Secure Sockets Layer

| 9


Security Aspects

1

12

13

14

15

16

17

18

19

20

21

22

2

3

4

5

6

7

8

9

10

11

30

31

32

33

34

27

28

29

23

24

25

26

35

36

37

5 Purpose

This guideline is designed to build on an organization’s existing cyber security policies and procedures, help organize and clarify risk management goals, and provide a consistent approach in which to make risk decisions. This document highlights common threats to embedded devices, and the vulnerabilities exposed for each threat to the TIA M2M reference architecture.

Organizations may choose to expand or abbreviate the comprehensive processes and steps suggested in this guide and tailor them to their environment in managing M2M related mission risks.

5.1

Objective

The objective of creating the threat analysis paper is to enable organizations to increase security in their missions. To help understand and mitigate risk in the

M2M implementation, a vulnerability level is defined through known best practices from NIST, DOE, and the NSA and calculated based on the criteria of likelihood multiplied by impact. The vulnerability level can be used to determine the amount of counter measure to employ, thereby mitigating the risk to an acceptable level.

5.2

Target Audience

This guide provides a common foundation for experienced and inexperienced, technical and non-technical personnel who support or use the risk management process for their IT systems.

These personnel include:



Senior management, the mission owners, who make decisions about the IT security budget.



Chief Information Officers, who ensure the implementation of risk management for agency IT systems and the security provided for these IT systems.



The IT security program manager, who implements the security program.



Information system security officers (ISSO), who are responsible for IT security.

10 |

1

2

3

4

5

6

7


Security Aspects



IT system owners of system software and/or hardware used to support IT functions.



Technical support personnel (e.g., network, system, application, and database administrators; computer specialists; data security analysts), who manage and administer security for the IT systems.



IT system and application programmers, who develop and maintain code that could affect system and data integrity

| 11


Security Aspects

1

32

33

34

35

26

27

28

29

30

31

20

21

22

23

24

25

36

14

15

16

17

18

19

6

7

8

9

10

11

12

13

2

3

4

5

6 Cryptology Introduction

To familiarize the reader with cryptology concepts and terminology that are used within this document, the following introductory section attempts to provide easily understandable definitions and explain cryptology concepts.

Data that can be read and understood without any special measures is called plaintext or cleartext . The method of disguising plaintext in such a way as to hide its content is called encryption. Encrypting plaintext results in unreadable text that is called ciphertext . Encryption ensures that information is hidden from anyone for whom it is not intended, even those who can see the encrypted data. The process of reverting ciphertext to its original plaintext is called decryption .

Cryptography is the science of using mathematics to encrypt and decrypt data.

Cryptography enables entities to store sensitive information or transmit it across insecure networks (like the Internet) so that it cannot be read by anyone except the intended recipient.

While cryptography is the science of securing data, cryptanalysis is the science of analyzing and breaking secure communication. Classical cryptanalysis involves an interesting combination of analytical reasoning, application of mathematical tools, pattern finding, patience, determination, and luck. Cryptology embraces both cryptography and cryptanalysis.

A cryptographic algorithm , or cipher , is a mathematical function used in the encryption and decryption process. A cryptographic algorithm works in combination with a key

—a word, number, or phrase—to encrypt the plaintext.

Encrypting plaintext with different keys produces different ciphertext. The security of encrypted data is entirely dependent on two things: the strength of the cryptographic algorithm and the secrecy of the key.

One of the main categorization methods for encryption techniques commonly used is based on the form of the input data they operate on. The two types are

Block Cipher and Stream Cipher.

12 |

1

2

3

4

5

6

6.1

6.2

7

8

9

10

11

12

13

14

6.3

15

16

17

18

19

20

21

6.4

27

28

29

30

31

32

22

23

24

25

26

33

34

35

36

37

6.5

38

39

40


Security Aspects

Block Cipher

In this method data is encrypted and decrypted if data is in the form of blocks.

In its simplest mode, you divide the plain text into blocks which are then fed into the cipher system to produce blocks of cipher text.

Stream Cipher

Stream cipher functions on a stream of data by operating on it bit by bit.

Stream cipher consists of two major components: a key stream generator, and a mixing function. Mixing function is usually just an XOR function, while key stream generator is the main unit in stream cipher encryption technique. For example, if the key stream generator produces a series of zeros, the outputted ciphered stream will be identical to the original plain text.

Symmetric Cryptography

In conventional cryptography, also called secret-key or symmetric-key encryption, one key is used both for encryption and decryption. The key must be kept secret in order for this type of cryptography to work. Example usage includes email, http, IPsec. Symmetric cryptography is magnitudes faster than asymmetric cryptography.

Asymmetric Cryptography

Public key cryptography is an asymmetric scheme that uses a pair of keys for encryption: a public key , which encrypts data, and a corresponding private, or secret key for decryption. You publish your public key to the world while keeping your private key secret. Anyone with a copy of your public key can then encrypt information that only you can read. It is computationally infeasible to deduce the private key from the public key. Anyone who has a public key can encrypt information but cannot decrypt it. Only the person who has the corresponding private key can decrypt the information. Encryption using asymmetric key algorithms is very slow, Asymmetric encryption techniques are almost 1000 times slower than Symmetric techniques, because they require more computational processing power especially when the data size is large; hence, they are not used when doing bulk encryption. For bulk encryption, symmetric algorithms should be used. The asymmetric algorithms can be used to do key exchange.

Key

A key is a value that works with a cryptographic algorithm to produce a specific ciphertext. In public key cryptography, the bigger the key, the more secure the ciphertext.

| 13

13

14

15

16

17

18

1

2

6.6

6

7

8

9

10

11

3

4

5

12

6.7


Security Aspects

Digital Signature

A major benefit of public key cryptography is that it provides a method for employing digital signatures . Digital signatures enable the recipient of information to verify the authenticity of the information’s origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity . A digital signature also provides non-repudiation , which means that it prevents the sender from claiming that he or she did not actually send the information. These features are every bit as fundamental to cryptography as privacy, if not more.

Hash

A one-way hash function takes variable-length input—in this case, a message of any length, even thousands or millions of bits—and produces a fixed-length output; say, 160-bits. The hash function ensures that, if the information is changed in any way—even by just one bit—an entirely different output value is created.

14 |


Security Aspects

1

23

24

29

30

31

32

33

34

25

26

27

28

35

36

37

38

39

40

41

7

12

13

14

15

16

17

18

19

20

21

8

9

10

11

2

3

4

5

6

22

7 Securing Data

Securing data is not encryption. Encryption is a component of an overall security strategy. Breaches occur, not because the modern cryptography is broken, but, because of ways around the cryptography, namely holes in the attack surface.

Understanding the key concepts of Encryption, Digital Signatures, Keys, and hashes we can create guidelines to transfer data securely across a network medium based on a devices’ capability level. In order to create a comprehensive security framework, the notion of all devices are created equal, must be dispelled. All devices are not created equal, devices range the spectrum from 8, 16, 32 bit microcontrollers with as little as 1 kB of memory with or without wireless capabilities, occupying a few square millimeters. For this reason, standards are required to provide guidance on a framework implementing collaborative security architecture with each device category in mind. By leveraging well-established security mechanisms and networking standards and adapting them appropriately for resource constrained environments we enhance the security for M2M devices, their data, and the networks in which they participate.

7.1

Data in Transit

7.1.1

Protocol Guidance

In securing the network, the guidance from this document suggests the use of

FIPS certified cryptographic software, along with maximizing the use of the link layer security, for a multilayer approach. Additional guidance suggests that the security packages that are implemented on the device are sourced from different vendors, reducing the possibility that one error from a manufacturer compromises the entire device. Design choices for securing a system affect performance, scalability and usability. There is usually a tradeoff between security vs. performance and usability. The more secure a system is, the more it is compromised in terms of performance and usability.

When designing a secure system, you should determine all the possible threats, vulnerabilities, and attacks and choose the techniques to implement security based on threat mitigation first and performance second.

Authentication schemes, hashing algorithms, and cryptography techniques carry varying amounts of overhead, and therefore have vastly different performance characteristics. The size of data being passed to hashing algorithms, as well to cryptography techniques, is also significant.

| 15

26

27

28

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

20

21

22

23

24

25

16

17

18

19

7.1.2


Security Aspects

When designing a secure system, the implementation techniques should be chosen based on threat mitigation first and performance second. For instance, basic authentication without SSL could be used for better performance but, no matter how fast it is, the system is still vulnerable to attacks.

Key Agreement

During key agreement (where both parties contribute to the shared secret and, therefore, the derived secret keying material), the secret keying material to be established is not sent directly; rather, information is exchanged between both parties that allows each party to derive the secret keying material. Key agreement schemes may use either symmetric key or asymmetric key (public key) techniques.

Understanding the capabilities of the device, a category table is defined providing guidance on algorithms to align with the triad of Confidentiality,

Integrity and Availability (CIA). Although some device may not have the processing power to implement the triad completely, the encryption strength is tied to multiple factors e.g. entropy, as well as key length. Cryptography with a longer key will likely ensure higher levels of security at the expense of higher energy consumption. Table 1 shows an example of recommended PKI security level guidance .

29

7.2

16 |

Security

Category

Encryption

& Key Size

Level 1 (weakest) NULL

Level 2 ECC 80

Level 3

Level 4

Level 5

Level 6

ECC 112

AES 192

ECC 256

AES 256

Signature

(per ANS X.931)

Key Agreement

NULL NULL

DSA/RSA/ECDSA DH (static)

DSA/RSA/ECDSA DH (static)

DSA/RSA/ECDSA ECDH

DSA/RSA/ECDSA ECDH 256

DSA/RSA/ECDSA ECDH 384

Level 7 (strongest) ECC 386 DSA/RSA/ECDSA ECDH 384

Table 1

Digest

NULL

SHA 160

SHA 160

SHA 224

SHA 256

SHA 386

SHA 386

Multilayer Guidance

1

2

3


Security Aspects

Implementing multilayer guidance at the appropriate OSI layer conforming to a visual architecture such as Figure 1 is taken from the table of recommended though not exhaustive security protocols in Table 2.

Security Vendor A

Device

Transport or Application Layer e.g. SSL

Network Layer e.g.IPSEC

Aggregation Point

6

7

8

9

10

11

12

4

5

Security Vendor B

Figure 1

Security

OSI Layer

Data Link

Confidentiality Integrity

Network

SILS/SDE,

PPTP, L2TP

PIC,IPSEC,

NLSP

Transport SOCKS, TLSP,

SSL, D-TLS,

TLS, PCT, SSH

Application S/HTTP, SPKM,

MHS,MSP,PEM,

SFTP,

PGP/MIME,

MOSS, S/MIME,

PKCS#7

SILS/SDE,

L2TP

PIC, IPSEC,

NLSP

SOCKS, TLSP,

SSL, D-TLS,

TLS, PCT, SSH

S/HTTP, SPKM,

MHS,MSP,PEM,

SFTP,

PGP/MIME,

MOSS, S/MIME,

PKCS#7

Entity

Authentication

PPTP, L2TP,

L2F

PIC, IPSEC,

NLSP

SOCKS, TLSP,

SSL, D-TLS,

TLS, PCT, SSH

S/HTTP,

SPKM, SFTP

Table 2

Data Origin

Authentication

SILS/SDE, L2TP

PIC, IPSEC,

NLSP

TLSP

S/HTTP, SPKM,

MHS,MSP,PEM,

SFTP,

PGP/MIME,

MOSS, S/MIME,

PKCS#7

Non-

Repudiation of Origin

Non

Repudiation of Receipt

SPKM, PEM,

MHS,MSP,

SFTP,

S/MIME,

ESS

SPKM,

MHS,MSP,

SFTP,

S/MIME,

ESS

Described below are two use cases that illustrate the collaborative nature that implements end to end security. Demarcation points for an end to end solution are shown in Figure 2. There are several demarcation points that leverage each device’s computing platform, as well as provide a threat to the system if compromised.

| 17


Security Aspects

Service Provider

“Cloud Enabled”

Regional Data

Aggregation Point

MACRO

NETWORK

Home Data

AggregationPoint

Device

3

4

5

6

11

12

13

14

15

7

8

9

10

16

1

2

7.2.1

25

26

27

28

29

30

31

32

17

18

19

20

21

22

23

24

Device

Figure 2

The following use cases draw from figure 2 and illustrate (1) a direct connect from a device to the home service provider, and (2) a multi hop transfer of data utilizing a security proxy (data aggregation point).

The service agreement between the end user and the service provider provides the ultimate level of security required for data in transit. Often the devices are not able to meet the requirement and may need to use a security proxy closest to the device in order to meet the requirements. If the device has enough compute power and resources to meet the requirements, the device may be able to bypass the proxy and connect directly to the service provider at the required security level. In the following use cases, security levels tie back into the PKI security guidance from Table 1.

“Direct” Use Case

Actor: M2M Device is required to transmit the collected data to a service provider directly, at a “High” security level. The device has sufficient compute power to execute at a “High” security level of 5, as does the service provider.

Service Provider

Regional Data


Home Data


B

Device

A

A.

The device creates a secure link following the multilayer

Service Provider’s minimum security level willing to accept

Multilayer Guidance 2 Layers of

Security from different vendors

“DIRECT” Use Case guidance (Figure 1) utilizing

2 separate vendor security stacks populated with values from Table 2

B.

The service provider binds, and accepts the connection request, securing the session. Application session takes place within a secure pipe.

18 |

1

25

26

27

28

29

30

31

32

33

34

35

17

18

19

20

21

22

23

24

2

8

9

10

11

12

13

3

4

5

6

7

14

15

16

7.2.2


Security Aspects

“Multiple Hop” Use Case

Actor: M2M Device is required to transmit the collected data to a service provider directly, at a

“High” security level. The device does not have sufficient compute power to execute at a “High” security level of 5. The Device will require the use of a security proxy (i.e. Data Aggregation

Point) to achieve the service level agreement of security level 5.

Service Provider Regional Data


Home Data


H

G

F

E D

C

B

Device

A

Service Provider’s minimum security level willing to accept

Multilayer Guidance 2 Layers of

Security from different vendors

“MULTIHOP” Use Case

A.

The device creates a secure link following the multilayer guidance

(Figure 1) utilizing 2 separate vendor security stacks populated with values from Table 2

B.

The home data aggregation point binds, and accepts the connection request, securing the session.

C.

The home data aggregation point, in turn creates an additional connection at a higher security level to the regional data aggregation point, in essence creating a security ladder achieving stronger security architecture.

D.

The home data aggregation point negotiates keys, session parameters at a higher security plane.

E.

The regional data aggregation point binds, and accepts the connection request, securing the session at an escalated security level. Application session takes place within a secure pipe.

F.

The regional data aggregation point, in turn creates an additional connection at a higher security level to the service provider, satisfying the security requirements set out by the service provider.

G.

The regional data aggregation point transmits the device data at a higher security plane to the service provider’s infrastructure.

H.

End to end application session takes place within a secure pipe between the device and service provider

| 19


Security Aspects

1

2

3

4

5

6

7

8

9

10

11

12

13

8 Secure the Attack Surface

An “attack surface” comprises all possible entry points that may compromise a system. The security of a system is inversely proportional to the number of entry points available. A “trusted computing base” is the set of all hardware, software and procedural components that enforce the security policy. This means that in order to break security, an attacker must subvert some combination of hardware, software or procedural elements.

The guidance in this document discusses data at rest, data in transit and implementation of secure software based code within the operating system, and applications.

22

23

24

25

14

15

16

17

18

19

20

21

20 |

Figure 3

Several ways to mitigate the attack surface include:



Design and implement secure code to protect against vulnerabilities, such as buffer overflow, structured query language (SQL) injection, cross-site scripting (XSS), and directory traversal



Replace potentially dangerous functions with safe counterparts



Validate input data



Minimize the number of open ports, installed services and applications

14

15

16

17

18

19

20

21

22

23

24

25

1

2

3

4

5

6

7

8

9

10

11

12

13

8.1


Security Aspects

New vulnerabilities in computer applications and services are found every day. Some are published shortly after their discovery; others are kept a closed secret by those who discover them. These remain un-patched and can be exploited at will by their discoverers. To help mitigate this vulnerability:



Implement effective patch management



Remove all unneeded applications and services

The following subsections discuss activities that a system encounters in the normal day to day operation of a modern application, and the ways to mitigate some of the vulnerabilities.

Secure Software Development

Common attacks and attack patterns have been widely studied and well documented for operating systems, network devices, database management systems, web applications, and web services, but have not yet been well established for software-specific based attacks. The root cause for the majority of the application, network, and operating system vulnerabilities exists in flaws inherent in the software code itself. Software security attack patterns are currently being researched and developed, and are being designed to expose exploited code development flaws and to describe the common methods, techniques, and logic that attackers use to exploit software. For example listed in Figure 3 below are the vulnerabilities found in a sample of SCADA based systems researched and documented by the NSTB.

26

27

28

29

30

31

Figure 4

Listed below are categories that attackers look to exploit in software based systems that the reader should be aware.

| 21

Access information via Privileged Code


Security Aspects

8.1.1

30

31

32

33

34

35

36

37

38

39

40

41

27

28

29

8.1.2

21

22

23

24

25

26

15

16

17

18

19

20

8.1.3

1

2

7

8

9

10

11

12

3

4

5

6

13

14

Applications that are considered “secure” often limit the use of Privileged code; in particular best practices recommend privileged code access only to read system properties, opening sockets, reading and writing files. Privileged code is system calls that escalate into the kernel mode. Operating Systems use a memory management unit in the CPU to enforce code and data isolation which provide security to ‘privileged’ features within the operating system.

Once any rogue code executes in a privileged state, it is very possible that keys, certificates, numbers or security functionality will be breached, thus the issue around securing the privilege code is a high priority and the usually the first attempt by a hacker trying to gain access to the device.

API’s

Application Programming Interfaces or API’s are the external interface to a code function and enable libraries, drivers, and host resident code to communicate with each other creating an application. API’s are designed without security considerations. They are often optimized for speed and functionality. Operating Systems often have 100’s of API‘s that cross the user and privilege space boundaries. The action of securing the API may break legacy code and remove backwards compatibility. Hackers often attempt to misuse the API to provide information that is not necessarily meant for public consumption. Misusing the API’s is one of the routes to escalate into privileged kernel mode.

Type-Safe and Managed Code

When code is type safe, the runtime's security enforcement mechanism ensures that it does not access native code unless it has permission to do so.

Type-safe code cannot read values from another object's private fields. It accesses types only in well-defined, allowable ways.

Although verification of type-safe code is not mandatory to run managed code, type safety plays a crucial role in assembly isolation and security enforcement. When code is type-safe, the common language runtime can completely isolate assemblies from each other and not leak data through API misuse. Type-safe components can execute safely in the same process even if they are trusted at different levels. When code is not type safe, unwanted side effects can occur. For example, the runtime cannot prevent unmanaged code from calling into native (unmanaged) code and performing malicious operations (buffer overflow breaking the privileged/user boundary).

22 |


Security Aspects

26

27

28

29

30

31

32

33

34

35

36

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

1

6

7

2

3

4

5

8.1.4

8.1.5

8.1.6

Communication endpoint vulnerabilities

Network services at communication end-points listen for messages to accept, and can be exposed to attacks that exploit input and output validation vulnerabilities to gain unauthorized access to their host.

Communication channel vulnerabilities

As systems become increasingly connected to company intranets and to the external Internet, they can also become more exposed to attack. System communication channels may use common IT communication protocols that provide common IT functionality in systems, as well as system communication protocols to transmit system data and command messages.

They often connect different network security zones and may provide access to processes that manipulate the system.

Recommendations:





Rigorously protect authentication credentials during transmission

Implement secure communications best practices.



Detect data corruption or manipulation by performing system data integrity checks



Consider the benefits and challenges of implementing data encryption for the M2M systems.

Network access vulnerabilities

Attackers can search for vulnerabilities in firewalls, routers, and switches and use those to gain access to sensitive data and target networks, redirect traffic on a network to a malicious or compromised system masquerading as a trusted system, and to intercept and alter information during transmission.

Recommendations:



Segment networks



Implement strong firewall rules



Secure connections across security zones



Implement intrusion detection

| 23


Security Aspects



Implement secure access to network devices

1

2

3

8.2

Data at Rest

9

10

11

12

13

14

15

16

17

18

4

5

6

7

8

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

8.2.1

Data at Rest for this guidance is defined as any data that is stored on a storage device, including, but not limited to, thumb drives, hard drives. Protecting

Data at Rest requires a minimum of two objectives:

1.

2.







Implementing Secure Encryption algorithms, and the

Management of the cryptographic keys that unlock the encrypted data.

Data at Rest security is only as strong as the encryption algorithm and the key management architecture being used. If the algorithm is strong but the key management is weak, the data is still not sufficiently protected. While the key management strategy must be strong, it must also be operationally simple so as not to impede the mission. Failing to protect data at rest places the device at risk including:

Additional systems can be compromised

Entire network can be compromised

Control of organization data, including network storage devices can be lost

Implementing strong encryption and key management policies are the corner stone of data at rest security, though additional considerations should also include software that can “zeroize” or “brick” the device leaving it useless, as well some type of location or tracking of the device to recover if stolen or misplaced. The policies that recommend these technologies are created by the organization based on each organizations requirement to secure the data at rest. The overwhelmingly majority use as a baseline for data at rest guidelines based on the NIST FIPS 140-2 guidance.

Minimum Security

The minimum security requirements cover seventeen security-related areas with regard to protecting the confidentiality, integrity, and availability of federal information systems and the information processed, stored, and transmitted by those systems. The security-related areas include:

1.

access control;

24 |

9

10

7

8

11

12

13

4

5

6

1

2

3

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

8.2.2


Security Aspects

2.

awareness and training;

3.

audit and accountability;

4.

certification, accreditation, and security assessments;

5.

configuration management;

6.

contingency planning;

7.

identification and authentication;

8.

incident response

9.

maintenance;

10.

media protection;

11.

physical and environmental protection;

12.

planning;

13.

personnel security;

14.

risk assessment;

15.

systems and services acquisition;

16.

system and communications protection; and

17.

system and information integrity.

The seventeen areas represent a broad-based, balanced information security program that addresses the management, operational, and technical aspects of protecting federal information and information systems.

Policies and procedures play an important role in the effective implementation of enterprise-wide information security programs within the federal government and the success of the resulting security measures employed to protect federal information and information systems. Thus, organizations must develop and promulgate formal, documented policies and procedures governing the minimum security requirements set forth in this standard and must ensure their effective implementation .

Authorization vulnerabilities

Authorization is the act of validating access rights through controls that restrict access to entities in a network, host, or software system and can be incorporated into system components to help prevent and contain compromise. If an attacker gains full access to a host, all functions that the server can execute can be under the attacker’s control. In addition, host access

| 25

5

6

7

8

9

1

2

3

4


Security Aspects gives the attacker access to the resources of the compromised server, including communications with other devices and servers.

Recommendations:



Implement least-privilege access control



Limit functionality only to that required, which enables the ability to implement least-privilege access control



Implement a secure design of system components that compartmentalizes functionality

26 |

20

21

22

23

24

25

26

27


Security Aspects

1

7

8

9

10

11

12

13

14

2

3

4

5

6

15

16

17

18

19

9 RISK

Many vulnerability assessment models and methodologies have been reviewed, including some developed and used, to varying degrees, in certain selected sectors (electric power, gas, other standards groups). The following framework approach was agreed upon for generalized best practices.

Risk management is defined as the program and supporting processes used to manage security risk to an organization’s operations. In order to effectively perform risk management, an organization must have a thorough understanding of their people, processes, and technology, as well as an understanding of how they enable the mission and communication throughout the organization. It is critical to not only understand the processes but also to enable the communications that facilitate information sharing.

Attackers can potentially use many different paths to do harm to the business or organization. As seen in Figure 5, each of these paths represents a risk that may, or may not be serious enough to warrant attention.

Threat Agents Attack Vectors

Attack

Security Weaknesses

Mitigate

Security Controls

Weakness Controls

Technical Impacts Business Impacts

KABOOM!!!

Asset

Weakness Controls

Attack

Impact

Impact

Attack

Weakness Controls

Asset

Weakness Controls

Function

Weakness

Understanding Weaknesses one can put controls in place to mitigate Impacts

Figure 5

Sometimes, these paths are trivial to find and exploit and sometimes they are extremely difficult. Similarly, the harm that is caused may range from none to failure of the business. To determine the risk to the organization, evaluate the likelihood associated with each threat agent, attack vector, and security

| 27

1

2

3

4

5

10

11

12

6

7

8

9

9.1


Security Aspects weakness and combine it with an estimate of the technical and business impact to the organization. Together, these factors determine the overall risk.

Risk Management

The risk management cycle is not static but a continuous process, constantly re-informed by the changing risk landscape as well as by organizational priorities and functional changes. The risk management cycle provides four elements that structure an organization’s approach to risk management, as represented in Figure 6. This document will provide guidance only for two of the four elements, Frame and Assess; the remaining two elements are highly specific to how each individual company values the risk assessment.

29

30

31

32

33

24

25

26

27

28

13

14

15

16

17

18

19

20

21

22

23

28 |

Figure 6

The risk management cycle is a comprehensive process that requires organizations to (i) frame risk (i.e., establish the context for risk-based decisions), (ii) assess risk, (iii) respond to risk once determined, and (iv) monitor risk on an ongoing basis. Risk management is carried out as an organization-wide activity that addresses risk from the strategic level to the tactical level, ensuring that risk-based decision-making is integrated into every aspect of the organization.

The output of the risk management cycle is a risk management strategy that addresses how an organization intends to frame, assess, respond to, and monitor risk. The risk management strategy makes explicit and transparent the risk perceptions that an organization routinely uses in making investment and operational decisions.

The risk-framing element describes the environment in which risk-based decisions are made. Establishing a realistic and credible risk frame requires that organizations, identify:

9

10

11

5

6

7

8

1

2

3

4

12

28

29

30

31

32

33

34

35

36

37

38

13

19

20

21

22

23

24

14

15

16

17

18

25

26

27

9.2


Security Aspects



Assumptions about threats, vulnerabilities, consequences, impacts, and likelihood of occurrence;



Constraints imposed by legislation, regulation, resource limitations, and other factors identified by the organization;



Risk tolerance which identifies levels of risk, types of risk, and the degree of risk uncertainty that is acceptable;



Priorities within mission and business functions, and trade-offs among different types of risk across those functions; and



Trust relationships, such as physical interconnections, third-party billing organizations, reciprocity agreements, or device vendors.

Risk Assessment

The risk assessment element identifies, prioritizes, and estimates risk to an organization’s operations, assets, individuals, and other interconnected organizations. We create a risk framework by researching the frameworks in the public domain. We have assembled a framework using FIPS 199 risk assessment for information systems, Federal Security Risk Management methods, The OSI+ (Open System Interconnect) threat and vulnerability analysis methodology incorporates business and technology elements to provide a holistic view of threats to information infrastructure. This is done through the risk context created in the risk-framing element. The purpose of the risk assessment element is for organizations to identify and evaluate:

•

Threats (to operations, assets, or individuals);

• Vulnerabilities (to operations, assets, or individuals);

•

Impact (consequence or opportunity); and

•

Likelihood (probability or frequency an event will occur).

To support the risk assessment element, organizations identify:

• Tools, techniques, and methodologies that are used to assess risk;

•

Assumptions related to risk assessments;

•

Constraints that may affect risk assessments;

• Roles and responsibilities related to risk assessment;

•

Risk assessment information to be collected, processed, and communicated;

| 29

12

13

14

15

16

17

18

1

2

9

10

11

6

7

8

3

4

5

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

9.3


Security Aspects

•

Threat information to be obtained.

Risk Management, a quantitative approach is a mathematical calculation based on security metrics of the asset. One approach that exemplifies this method is referred to as the annualized loss expectancy or ALE. This approach takes in consideration the calculation of single loss expectancy,

SLE; along with the number of incidents expected over a period of time to arrive at the ALE described as a monetary value. The variables that make up the SLE can be numerous and complex, the calculations in this document are for example only illustrating potential cost value to the vulnerability if no counter measures are taken.

The cost of a counter measure includes the costs of including security within the devices, including but not limited to the increased development time, and device complexity the decrease of the devices optimal performance, as well as the time involved in the quality assurance of installing and verifying the security.

As described previously, these values are for example purposes only, the reader is encouraged to use quantitative analysis in managing risk, though using their corporate data including additional variables and weights one may use in deriving the value for counter measures against the vulnerability and consideration for the level of risk the company is willing to accept.

Risk Assessment is a qualitative analysis of system assets and vulnerabilities that establish a risk level from attacks based on estimated probabilities of the occurrence of such an attack. The purpose of a risk assessment is to determine if the counter measures in place are adequate to reduce the probability of loss or the impact to an acceptable level. The acceptable level is highly dependent on the company. The acceptable level of risk is generally correlated to a monetary value.

Threats

A threat is the combination of an asset, vulnerability and a threat agent. We identify the asset that needs to be protected, and the quantities that need protecting. We need the quantities to assign a monetary value in order to gauge, financially, the degree of mitigating the threat costs, as well as the appropriate amount of money we should outlay to protect that asset or service.

Vulnerabilities (known and unknown) against an asset are listed, and counter measures to the vulnerability are described that mitigate the risk to a lesser

30 |

29

30

31

26

27

28

32

33

22

23

24

25

34

35

36

37

9

10

11

12

13

14

15

16

17

18

19

20

21

1

2

3

4

5

6

7

8


Security Aspects degree. The attacker, or threat agent are quantified 1 – 4 based on their affiliation.

In order to quantify vulnerability, we assign numeric values to classes in each category. Vulnerability is calculated based off likelihood multiplied by impact. Likelihood or Probability ranges from 1 through 4 with the following levels:

1.

“Low Likelihood” being the least likely due to little motivation, opportunity and/or capability

2.

“Moderate Likelihood” being of moderate likelihood, with average motivation, opportunity and/or capability

3.

“Substantial Likelihood” being substantial likelihood, with high motivation, opportunity and/or capability

4.

“Severe Likelihood” being the most likely as an agent with high motivation, opportunity and capability.

Criteria assigning likelihood levels include assessing the attacker, motivation, opportunity, and capability. Quantifying each of the following classes within the likelihood category individually:



Threat Agents of which can be detailed as:

0.

No agent present

1.

Individual criminal

2.

Competitor

3.

Extremist, Organized Crime

4.

Terrorist or Nation State



Motivation; including financial, political, emotional, revenge as well as constraints such as detection, and risk involved.

0.

No motivation

1.

Low

2.

Moderate

3.

Substantial

4.

High

| 31

14

15

16

17

18

19

10

11

12

13

20

21

22

23

24

25

26

27

28

29

1

2

3

4

5

6

7

8

9

30

31


Security Aspects



Opportunity; including proximity, security, standards

0.

No Opportunity

1.

Little

2.

Limited

3.

Substantial

4.

High



Capability, including education, knowledge, access, specialized equipment and reverse engineering.

0.

None

1.

Little

2.

Limited

3.

Substantial

4.

High

Impact or Magnitude is calculated by the seriousness of a successful attack, with the following levels:

RANGE

0 ≤ 3

4 ≤ 8

9 ≤ 16

1.

Minor impact or no effect to the stakeholder

2.

Serious impact, including impacting revenue streams, processes, support systems

3.

Widespread impact, causing irreparable damage to key systems and processes

4.

Severe impact causing damage to systems and processes that support infrastructure requirements.

Risk assessment level is the product of impact and likelihood, generally the larger the risk assessment, the more urgent the counter measure:

CATEGORY REMARKS

Minor Counter Measures Optional

Major

Critical

Counter Measures Required As Soon As Possible

Counter Measures Required Immediately

Table 3

32 |

17

18

19

20

21

22

23

6

7

8

9

10

11

12

13

14

15

16

3

4

5

24

25

26

1

Threats Against the Architecture

2


Security Aspects

PoA applications node applications home applications application management application domain admin admin admin device management device domain

PoA devices smart device protocol convergence

PoA smart device protocol convergence node smart device protocol convergence server core IP

Figure 7 authentication, authorization and accounting

AAA-SD network management

The high level system architecture is described as a distributed cooperative computing system; as such, applications on each component provide a unique capability that creates the overall system, or solution. Within the architecture you have servers that maintain the business logic and processing indicated by label “Home Applications”. Intermediary nodes that help facilitate communication, security levels and provide additional adjunct business logic to offload processing or either the Server or M2M Device. Point of

Attachment provides resources to the node, server or even additional PoA applications residing on the device. A device may have multiple PoA’s, each

PoA may connect to multiple Nodes, and Nodes may connect to multiple servers.

To help prevent exploitation or limit damage from cyber-attack surface vulnerabilities, it is recommended that additional precautions be implemented, such as:



Vendors, and possibly owners, thoroughly assess, secure and test products, starting with the most exposed and powerful functions



Vendors use compiler options to detect some types of buffer overflows; however, an attack could still cause a DoS, since the typical mitigation is to exit the application

| 33

22

23

24

25

15

16

17

18

19

7

8

9

10

4

5

6

11

12

13

14

1

2

3

20

21


Security Aspects



Vendors and owners if possible, can use as part of a defense in depth solutions, a CPU and OS that offers protection against buffer overflow attacks



Owners identify critical components and develop corresponding risk analysis and mitigation strategies for both operations and security

Attackers typically don’t break the cryptography. They exploit the system by finding the security breach that wasn’t mitigated properly, such as find keys, capturing cleartext copies of data, or access data through channels that automatically decrypt data.

The following sections will provide several common threats to the M2M architecture, it is not meant to be all inclusive of the threats against the TIA reference architecture. The sections will be compartmentalized into 4 groups:



Operating System



Applications



User Data



Network

10.1

Operating System

PoA applications node applications home applications application management admin admin admin

PoA devices device management device domain smart device protocol convergence

PoA smart device protocol convergence node smart device protocol convergence server authentication, authorization and accounting

AAA-SD network management core IP

Figure 8

This section drills down in to the operating system threats and vulnerabilities.

34 |


Security Aspects

22

23

24

25

26

27

28

29

18

19

20

21

30

31

32

33

34

35

36

37

38

39

40

3

7

8

9

10

4

5

6

11

12

13

14

15

16

17

1

2

10.1.1

Security Credentials Compromised

" glitching attack ". This kind of hardware attack involves sending a carefullytimed voltage pulse in order to cause the hardware to misbehave in some useful way. It has long been used by smart card hackers to unlock cards.

Typically, hackers would time the pulse to target a loop termination condition, causing a loop to continue forever and dump contents of the secret ROM to an accessible bus. Contents may include keys of node, servers and PoA devices.

The clock line is often glitched but some data lines are also a useful target.

The pulse timing does not always have to be precise since hardware is designed to tolerate some out-of-spec conditions and the attack can usually be repeated many times until it succeeds. The keys are copied, and used to impersonate M2M devices throughout the network, which can update/remove keys from additional M2M architectural elements.

Assessment

Likelihood (2): Moderate



Threat Agent (2) : Competitors, criminal, hacker, and disgruntled employees.



Motivation (2) : Financial, Reputation



Opportunity (2) : Requires physical and electrical proximity, and knowledge of the architecture and protocols.



Capability (2) : If commercial competitors have knowledge and expertise of standards, will know how to debug, reverse engineer the devices, and will have the financial means to carry out the attack.

Impact (2): Serious



Localized inconvenience



Detectable: The attacker is only required to be present at the device to initiate the attack, once initiated the attacker is not required to be at site. Lack of alarms, auditing on device will decrease the ability to detect this attack.



Recoverable: Recovery is possible for a small number of devices.

However, if node of server keys are not unique and are compromised recovery will not be possible.

Risk (4): Likelihood x Impact = 4 Major Risk

| 35


Security Aspects

32

33

34

35

36

37

19

20

21

22

11

12

13

14

15

16

17

18

23

24

25

26

27

28

29

30

31

1

2

3

4

5

6

7

8

9

10

Counter Measures:



M2M Security Keys should be stored in a tamper resistant secure environment which protects against discovery by either logical or physical means



Secure environment must be bound to device by physical/logical means



Secure environment does not provide stored values to anyone.

10.1.2

(Re) Provisioning the device through FOTA

Firmware over the air (FOTA) update works by replacing one version of the operating system with another by placing the rogue OS in a privileged area on the device, which will be installed as the device executes the boot sequence. It requires the update server’s message to be fabricated or to place an FOTA update package on the device through other methods.

The attack may also:



Contain non-legitimate server and node keys to access M2M devices, nodes and servers throughout the application domain



Provision non usable keys for a denial of service attack against a wide population of M2M application domains.



Commit fraud by reporting incorrect readings.



Break Privacy Rules



May camouflage attacks elsewhere on the network by falsely reporting an attack on itself.

This attack can be accomplished remotely, and can completely change a device’s operation.

Assessment

Likelihood (4): Severe Likelihood



Threat Agents (4) : Competitors, criminal, hacker, Nation States, and disgruntled employees.



Motivation (3) : Financial, Reputation, Political



Opportunity (3) : Devices/Nodes are IP addressable, with Servers

(hopefully) behind firewalls.

36 |

4

5

6

7

1

2

3

12

13

14

8

9

10

11

15

16

17

18

19

20

21

22

31

32

33

34

35

36

37

38

23

24

25

26

27

28

29

30


Security Aspects



Capability (4) : Assume knowledge of Protocols.

Impact (4): Compromised Infrastructure



Major effect on stakeholders; viruses may make the infrastructure unreliable, thereby denying accurate reporting



Detectable: Difficult if not impossible if there are no countermeasures for detecting unauthorized software.



Recoverable: The recovery is possible for a handful of devices, though, if node, server are compromised loss of privacy, confidentiality, and integrity.

Risk (16): Likelihood x Impact = 16 Critical Risk

Counter Measures:



Create a secure connection between entities providing for mutual authentication and confidentiality



Place all devices, nodes and servers behind a firewall.

 Create a ‘modern’ secure connection between entities providing for mutual authentication and confidentiality that is known to be acceptable.

10.1.3

Subverting Integrity Checking Procedures

This attack targets the integrity checking procedure of a M2M device while booting, allowing or disabling the capability to detect rogue software, or data on a device. To subvert software, the integrity checking may return a positive return value, or for a Denial of Service type attack, the integrity checking may return a false value inhibiting the device to come online. If an attacker could replace the file loader with a rogue piece of code, the rogue software would be able to circumvent much of the OS security.

The operating system performs integrity and access control checks when it loads libraries and files into the system. The file loaders is the piece of code that allocates the memory and loads the code from mounted media, or long term storage for execution as an executable, a dynamically linked library or even as a driver. The file loader may also broadcast to the entire system details of the API, including rights, for that piece of code.

| 37


Security Aspects

5

6

7

8

1

2

3

4

15

16

17

18

19

20

21

22

23

9

10

11

12

13

14

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

This attack is enabled through poorly written code, interfacing between the user/privileged boundary or by hardware techniques.

Assessment

Likelihood (3): Substantial Likelihood



Threat Agents (3) : Competitors, criminal, hacker, and disgruntled employees.



Motivation (3) : Financial, Political



Opportunity (2) : Has architecture, protocol knowledge though only access 1 device at a time.



Capability (3) : Architecture knowledge and expertise, access to standards/procedures.




Localized inconvenience



Detectable: Difficult if not impossible if there are no countermeasures for detecting.



Recoverable: Nearly impossible without countermeasures, the integrity validation process cannot detect faults within itself.


Counter Measures:



Ensure that the measurement part of the integrity validation check occurs in a secured environment.



Sensitive Data needs to be integrity protected, stored in a secure environment .

10.1.4

Accessing the device‘s privileged code through OS and application bugs

Drivers are typically written by third parties and these drivers are haphazardly updated at different times to the device. This makes it very difficult to implement integrity/validation checks against a whole system. The attack occurs when an operating system is forced to allow changes to privileged code because of a driver update. The driver software is such that an OS typically has privileged access to handle interrupts from the peripherals. In addition, known vulnerabilities against OS are published frequently, often requiring

38 |

8

9

10

11

12

13

14

18

19

20

21

22

23

24

15

16

17

25

26

27

28

29

30

31

32

33

34

35

36

37

4

5

1

2

3

6

7


Security Aspects system patches to secure the system. Use of this information can be implemented against a broad range of unpatched devices, leading to breaches due to poor device patching policy.

Examples of operating system API calls that may lead to vulnerabilities:

 open(“DBG:”) – legitimate use, though may provide information in lower levels of the OS.

 open( http://localhost/config-as SimUnlock ) legitimate use, though may provide information in the lower level of the OS

 open(“%c%c”) may crash the system and display stack and data information

Assessment

Likelihood (4): Great Likelihood



Threat Agents (4) : Competitors, criminal, hacker, and Nation

States.






Opportunity (4) : Has architecture, protocol knowledge, physical and electrical proximity.



Capability (4) : Architecture knowledge & expertise, access to standards/procedures and financial backing




Major inconvenience loss of confidence in vendor, system






Recoverable: Nearly impossible without countermeasures


Counter Measures:



Sensitive data needs to be integrity protected, stored in a secure environment



If integrity check of the data is cryptography based, then the keys need to be stored in the secured environment.



Authenticate and authorization of the party requiring access to the secured environment

| 39

12

13

14

15

16

3

9

10

11

4

5

6

7

8

21

22

23

17

18

19

20

24

25

26

27

28

29

30

31

32

33

34

35

36

37

1

2


Security Aspects

10.1.5

Faking General Software Identity

This type of attack is moderately hard and easily reproducible. Operating systems have a process in which it can identify an application running within the system. When applications use Security API’s the strength maybe compromised by fooling the security API as to the identity of a process that has a higher credentials, thereby accessing keys or other privileged information.

Assessment




Threat Agents (4) : Competitors, criminal, hacker, and Nation States.





















Counter Measures:



None identified in the current document

10.1.6

Access via (non)invasive debug ports (JTAG)

This type of attack is moderately hard and moderately reproducible. Critical code, as well as data is often held in memory. If that memory is accessible to the processor, then a (non) invasive debug port can be used to breach the system and extract secure information.

40 |


Security Aspects

8

9

10

11

12

13

14

6

7

1

2

3

4

5

18

19

20

21

22

23

24

25

15

16

17

26

Invasive debugging sets breakpoints, or interrupts the flow of the program, while Noninvasive doesn’t alter the program and is used to observe the processor, gaining access via the embedded trace port.

Assessment

























Counter Measures:



Disable debug capability in a production

10.2

Application

| 41


Security Aspects

6

7

3

4

5

15

16

17

18

19

20

21

22

23

8

9

10

11

12

13

14

1

2

42 |

PoA applications admin node applications admin home applications admin



Figure 9 application management

Application device management authentication, authorization and accounting


Secure coding guides and standards are available in a wide range of languages and software types. Some examples include:



CERT Secure Coding Standards



SAFECode Secure Coding Standards



20 Critical Security Controls: Critical Control 7: Application Software

Security

To find and remediate attack surface vulnerabilities in the system, such as insecure code, input validation, buffer overflow, SQL injection, XSS, and directory traversal, it is recommended that:



All stakeholders follow secure development standards when developing new products o Implement secure coding practices that enforce rigorous input data validation in system and services, database applications, and web services o Validate input and output data o Use safe string and buffer functions o Use robust integer operations and data types for memory operations.

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

8

9

10

11

4

5

6

7

1

2

3

28

29

30

31

32

33

34

35

36

37

38

39

10.2.1

Injection


Security Aspects



During software development, including thorough code reviews via manual and automated processes o Using automated static analysis tools o Using dynamic tools and techniques such as fuzz testing, robustness testing, and fault injection o Using a qualified third part that performs additional security testing



All stakeholders redesign or patch current products to remediate vulnerabilities



All stakeholders redesign system specific protocols to include strong authentication and integrity checks



Vendors carefully test and evaluate internally developed and thirdparty application software:



Owners work with vendors to explicitly address the security of products during the procurement and acceptance processes o Conduct a security audit of a product o Determine appropriate mitigations to meet specified security levels o Require and validate that products are delivered with secure configurations



Owners verify that third-party application software vendors have conducted detailed security testing of their products



Owners verify that IT products deployed on the network pass a security review

Send inappropriate queries to the application-level server that will exploit vulnerabilities of the query interpreter in order to gain un-authorized access.

This attack is easily exploitable. Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources. Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

| 43

1

4

5

6

7

8

2

3

13

14

15

16

17

9

10

11

12

18

19

26

27

28

29

30

31

32

20

21

22

23

24

25

33

34

35

36

37

44 |


Security Aspects

Assessment




Threat Agents (2) : disgruntled employee, competitor



Motivation (2) : Financial, emotional,



Opportunity (3) : substantial



Capability (2) : knowledge, specialized access

Impact (3): wide spread



Data can be exposed even when the user has proper authentication and authorization credentials.




Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.

Counter Measures:



Preventing injection requires keeping untrusted data separate from commands and queries.



The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Beware of

APIs, such as stored procedures that appear parameterized, but may still allow injection under the hood.



If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter



Positive or "whitelist" input validation with appropriate canonicalization also helps protect against injection, but is not a complete defense as many applications require special characters in their input.



Implement secure coding practices that enforce rigorous input data validation in system and services, database applications, and web services



Validate input and output data



Use safe string and buffer functions



Use robust integer operations and data types for memory operations



During software development, including thorough code reviews via manual and automated processes

26

27

28

29

30

31

32

22

23

24

25

8

14

15

16

17

18

19

20

21

9

10

11

12

13

33

34

35

36

37

38

39

1

2

3

4

5

6

7


Security Aspects o Using automated static analysis tools o Using dynamic tools and techniques such as fuzz testing, robustness testing, and fault injection o Using a qualified third part that performs additional security testing

10.2.2

Session Management and Broken Authentication

Consider anonymous external attackers, as well as users with their own accounts, who may attempt to steal accounts from others. Also consider insiders wanting to disguise their actions. Exploitation spoof this type is of average difficulty, Attacker uses leaks or flaws in the authentication or session management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc.

Finding such flaws can sometimes be difficult, as each implementation is unique.

Assessment




Threat Agents (2): Competitors.



Motivation (2): Financial



Opportunity (1): limited




Impact (2): Serious Impact



Data can be stolen or altered



Impersonation.




Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.

Counter Measures:



Put in place encryption and/or strong session management security controls.

| 45

4

5

1

2

3

6

7

8

9

29

30

31

32

33

34

35

36

37

38

26

27

28

22

23

24

25

18

19

20

21

10

11

12

13

14

15

16

17

10.2.3

Security Misconfiguration


Security Aspects













Consider anonymous external attackers as well as users with their own accounts that may attempt to compromise the system. Also consider insiders wanting to disguise their actions. Easy to exploit, Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system.

Assessment




Threat Agents (2) : No agent, disgruntled employee, competitor






Opportunity (1) : limited










Impersonation.




Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.

Counter Measures:



A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically. This process should be automated to minimize the effort required to setup a new secure environment.

46 |

5

6

7

8

1

2

3

4

9

10

11

12

13

14

15

16

17

18

10.2.4

33

34

35

36

37

38

39

19

24

25

26

27

28

29

20

21

22

23

30

31

32


Security Aspects



A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.

This need to include all code libraries as well, which are frequently overlooked.



A strong application architecture that provides good separation and security between components.



Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches.



Owners work with vendors to explicitly address the security of products during the procurement and acceptance processes o Conduct a security audit of a product o Determine appropriate mitigations to meet specified security levels o Require and validate that products are delivered with secure configurations

Insecure Cryptographic Storage

Consider the users of your system. Would they like to gain access to protected data they aren’t authorized for? What about internal administrators?.

Attackers typically don’t break the cryptography. They break something else, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt. The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access.

Assessment















| 47


Security Aspects

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

16

17

18

19

20

12

13

14

15

9

10

11

4

5

6

7

8

1

2

3







Failure frequently compromises all data that should have been encrypted. Typically this information includes sensitive data such as health records, credentials, personal data, credit cards, etc.

Counter Measures:



Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.



Ensure offsite backups are encrypted, but the keys are managed and backed up separately.



Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.



Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.



Ensure all keys and passwords are protected from unauthorized access.

10.2.5

Validate Input Data

Input data validation is used to ensure that the content provided to an application does not grant an attacker access to unintended functionality or privilege escalation. Improper input validation is a high-level root cause of many types of vulnerabilities. All of the weaknesses in the CWE/SANS Top 25

Most Dangerous Programming Errors can be associated with improper input validation.

Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, and XSS code to gain control over vulnerable machines. An attacker may be able to impose a DoS, bypass authentication, access unintended functionality, execute remote code, steal data and escalate privileges. While some input validation vulnerabilities may not allow exploitation for remote access, they might still be exploited to cause a crash or a DoS attack.

Input validation vulnerabilities were found in server applications written to process system protocol traffic. Most result in unauthorized access to the host on which the server was running. Sanity checks of incoming messages can ensure that the lengths and counts seem reasonable, that the data in the

48 |


Security Aspects

13

14

15

16

17

10

11

12

18

19

20

21

22

8

9

6

7

1

2

3

4

5

33

34

35

36

37

38

39

23

28

29

30

31

24

25

26

27

32 message is valid, and that the message is valid given the state of the connection. The impact of these vulnerabilities can be reduced by limiting the server’s privileges. The attacker will inherit the rights of the exploited process

Assessment



















Counter Measures:



Processes must be put in place to protect the storage so it is recommended that least-privileges be implemented so that service privileges are minimized as much as possible to reduce risk.

10.2.6

Cross Scripting

Secure coding practices protect a system web applications and services against cross-site scripting vulnerabilities (XSS). The root cause of XSS vulnerability is the same as that of an SQL injection, lack of input data validation.

However, a XSS attack is unique in the sense that the Web application itself unwittingly sends the malicious code to the user. It is dangerous because it allows attackers to inject code into the Web pages generated by the vulnerable

Web application. Attack code is executed on the client with the privileges of the Web server.

Cross-site scripting takes advantage of Web servers that return dynamically generated Web pages or allow users to post viewable content to execute arbitrary Hypertext Markup Language (HTML) and active content such as

JavaScript, ActiveX, and VBScript on a remote machine that is browsing the site within the context of a client-server session.

Assessment

| 49


Security Aspects

8

9

10

5

6

7

11

12

13

14

15

16

17

3

4

1

2

22

23

24

25

26

18

19

20

21

27

28

29

30

31

32



















 Attackers can execute scripts in a victim’s browser to hijack user sessions, deface web sites, insert hostile content, redirect users, hijack the user’s browser using malware, etc.

Counter Measures:

Preventing XSS requires keeping untrusted data separate from active browser content.



The preferred option is to properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. Developers need to include this escaping in their applications unless their UI framework does this for them.

 Positive or “whitelist” input validation is also recommended as it helps protect against XSS, but is not a complete defense as many applications must accept special characters. Such validation should decode any encoded input, and then validate the length, characters, and format on that data before accepting the input.

 Consider employing Mozilla’s new Content Security Policy that is coming out in Firefox 4 to defend against XSS.

10.3

User Data

50 |


Security Aspects

User Data

PoA applications node applications home applications application management admin admin admin

PoA devices device management smart device protocol convergence

PoA smart device protocol convergence node smart device protocol convergence server authentication, authorization and accounting


15

16

17

18

19

20

21

22

23

24

4

5

6

7

8

9

10

11

12

13

14

1

2

3 core IP

Figure 10

10.3.1

Transfer of keys via independent security element

The attack is carried out by an attacker who gains unauthorized possession of a set of viable keys and credentials by removing them from a legitimate M2M device. The attacker will then use the element in different, possibly unauthorized devices. The devices may attach to a network and consume non

M2M network services, in which the charge will be passed to a legitimate

M2M user. Additionally, a denial of service to the legitimate user may occur when the unauthorized device is online, the unauthorized device may use legitimate M2M services, though the cost is passed on to the legitimate user.

Assessment




Threat Agents (3) : Competitors, criminal, hacker.






Opportunity (2) : Requires physical access and product knowledge.



Capability (3) : No technical knowledge required

Impact (2): Serious



Major inconvenience and financial loss



Detectable: The attacker is only required to be present at the device to initiate the attack, once initiated the attacker is not required to be at

| 51

23

24

25

26

27

28

29

30

52 |

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

10.3.2




Counter Measures:



 detect this attack.

Recoverable: Countermeasures

Buffer Overflows


Security Aspects site. Lack of alarms, auditing on device will decrease the ability to

Sensitive Data needs to be bound to the device itself

Fraud detection system within the M2M environment

This type of attack is moderately hard and easily reproducible. This type of attack is present when the use of non-type safe API’s are exposed. Buffers of data + ‘N’ are passed through an API where it is known that the API is designed to have length constraints. The N bytes overflow into an area that was being utilized by other storage (heap overflow) or precipitates the return address to be corrupt (stack overflow). Stack overflows are indicated by the return code jumping to a random location, and as a consequence, incorrect code is executed and may change local data (rights of code or a file)



Buffer Copy without Checking Size of Input ('Classic

Buffer Overflow')



Buffer Access with Incorrect Length

Value



Improper Validation of Array Index



Integer Overflow or Wraparound



Incorrect Calculation of Buffer Size



Assessment














3

4

5

1

2

6

7

8

9

10

11

12

13

14

15

16

17

18

22

23

24

25

26

27

19

20

21

28

29

30

31

32

33

34

35

36


Security Aspects












Counter Measures:



All stakeholders follow secure development standards when developing new products















During software development, including thorough code reviews via manual and automated processes o Using automated static analysis tools o Using dynamic tools and techniques such as fuzz testing, robustness testing, and fault injection o Using a qualified third part that performs additional security testing

10.4

Network

To minimize the attack surface within the network, such as possible access paths in unnecessary ports and services, it is recommended that:



Restrict the ports, installed services and applications used to support their systems to the minimum necessary



Identify and disable all OS or third-party application services not explicitly needed for the system to operate



Vendors identify and document

| 53

10

11

12

8

9

1

2

3

4

5

6

7

13

14

15

16

17

18


Security Aspects



All OS or third-party application dynamic port services and respective port ranges



The services needed by each system component and the port ranges that each needed service uses, and also explicitly identify each device that is allowed to initiate a connection with one of these ports



Vendors include ports and services documentation and secure configuration as part of the product deliverable



Validate the necessity of services installed before they are deployed



Remove unneeded applications and services with great care



Owners document the way each system components use the network so that effective firewall and IDS rules can be created

PoA applications node applications home applications application management application domain admin admin admin



Figure 11 device management device domain authentication, authorization and accounting


Figure 12 below, provides reference markings between the interfaces layers within a TIA M2M system.

54 |


Security Aspects home application

B1 A1

B2/B2'

B4

B5/B5'

B3/B3'

PoA application/device node application

A2

A3/A3'

18

19

20

8

9

10

11

12

13

14

15

16

17

21

22

23

24

25

26

27

28

29

4

5

6

1

2

3

7 authentication, authorization and accounting

AAA-SD

Figure 12

Within the network, there are many active attacks; the following list provides a non-exhaustive sample of attacks against the TIA architecture.

10.4.1

Eaves Dropping/Man In the Middle Attack

Consider anyone who can monitor the network traffic of your users. If the application is on the internet, who knows how your users access it. Don’t forget back end connections. Keys and other sensitive Information can be discovered by eavesdropping on messages at the transport layer. Monitoring users’ network traffic can be difficult, but is sometimes easy. The primary difficulty lies in monitoring the proper network’s traffic while users are accessing the vulnerable site. This attack description assumes that the transport layer does not provide any protection. The attack occurs in the:



Local Area Network which connect the devices to each other, as well as nodes and servers. (B5)



WAN which connects Devices to Nodes and Servers (B1, B2)



WAN which connects provisioning and AAA servers, as well as network management servers (A2, B1, A3)

Applications frequently do not protect network traffic. They may use

SSL/TLS during authentication, but not elsewhere, exposing data and session

IDs to interception. Expired or improperly configured certificates may also be used.

Detecting basic flaws is easy. Just observe the site’s network traffic. More

| 55

9

10

11

7

8

4

5

6

1

2

3

25

26

31

32

33

34

35

27

28

29

30

36

37

38

12

13

14

15

16

17

22

23

24

18

19

20

21

56 |


Security Aspects subtle flaws require inspecting the design of the application and the server configuration. The attack exploits lack of security protection while data is in transit, or vulnerabilities in the protocol that was chosen to protect the communication pipe.

Assessment










Opportunity (2) : Requires monitoring IP communication but attack is limited to 1 device per time.



Capability (2) Architecture knowledge & expertise, access to standards/procedures and financial backing

Impact (3): Wide Spread



Minor localized inconvenience



Detectable: Minimal



Recoverable: The recovery is possible for a handful of devices, though, if node, server keys are compromised and not unique recovery will not be possible.


Counter Measures:



Secure Communication Link



Secure Communications Link with modern cryptographic algorithms

 Such flaws expose individual users’ data and can lead to account theft.

If an admin account was compromised, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.



Providing proper transport layer protection can affect the site design.

It’s easiest to require SSL for the entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on

‘critical’ pages, but this can expose session IDs and other sensitive data. At a minimum, do all of the following:



Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL page.

 Set the ‘secure’ flag on all sensitive cookies.

26

27

28

29

30

31

32

33

34

35

36

17

18

19

20

21

22

23

24

25

9

10

11

12

13

14

15

16

1

2

3

4

5

6

7

8


Security Aspects



Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.



Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.



Backend and other connections should also use SSL or other encryption technologies.

10.4.2

Replay Attacks

Keys and other sensitive Information can be discovered by replaying portions of transport layer messages between PoA and Nodes, and Servers. The attack may enable fraud within the network.. This attack description assumes that the transport layer does not provide any protection. The attack occurs in the:



Local Area Network which connect the devices to each other, as well as nodes and servers. (B5)



WAN which connects Devices to Nodes and Servers (B1, B2)



WAN which connects provisioning and AAA servers, as well as network management servers (A2, B1, A3)

The attack exploits lack of security protection while data is in transit, or vulnerabilities in the protocol that was chosen to protect the communication pipe.

Assessment










Opportunity (2) : Requires monitoring IP communication but attack is limited to 1 device per time.



Capability (2) Architecture knowledge & expertise, access to standards/procedures and financial backing

Impact (3): Wide Spread



Minor localized inconvenience



Detectable: Minimal

| 57

8

9

10

5

6

7

1

2

3

4


Security Aspects



Recoverable: The recovery is possible for a handful of devices, though, if node, server keys are compromised and not unique recovery will not be possible.


Counter Measures:



Secure Communication Link



Secure Communications Link with modern cryptographic algorithms

58 |


Security Aspects

1

2

3

Application

Network

11 Summary of Assets, Vulnerabilities and

Worksheet

ASSET

Operating System

GOAL

System Integrity

System

Availability

VULNERABILITY

(Re)provision Device

Subvert Integrity Checking

OS/Application Bugs

Impersonating Software

Identity

Buffer Overflow

Discovery Attack

SLE

(Re)provision Device

Comprised Keys


OS/Application Bugs

Buffer Overflows

Data

Confidentiality

Data Integrity

Availability

Integrity

Data

Comprised Keys

Subverting

Checking

Integrity

(Re)provisioning Device

Access via JTAG/Debug

Buffer Overflow

Transfer of Data via ISE

Compromised Keys



Man In The Middle

Replay

Eaves Dropping

Man in the Middle

Replay

Spoofing

Comprised Keys

ARO ALE

| 59

1

User Data

Confidentiality

Data Integrity


Security Aspects

Subverting

Checking

Integrity


Access via JTAG/Debug

Buffer Overflow

Transfer of Data via ISE

Compromised Keys



60 |

TIA-PN-4940 - Telecommunications Industry Association

Contents

List of Figures

Foreword

SCOPE

1 PURPOSE

2 RELATED REFERENCES

3 INTRODUCTION

4 Definitions, Symbols and Abbreviations

4.1

Definitions

4.2

Abbreviations

5 Purpose

5.1

Objective

5.2

Target Audience

6 Cryptology Introduction

6.4

6.5

Block Cipher

Stream Cipher

Symmetric Cryptography

Asymmetric Cryptography

Key

6.6

6.7

Digital Signature

Hash

7 Securing Data

7.1

Data in Transit

7.2

Multilayer Guidance

8 Secure the Attack Surface

8.1

Secure Software Development

8.2

Data at Rest

9 RISK

9.1

Risk Management

9.2

Risk Assessment

9.3

Threats

Threats Against the Architecture

10.1

Operating System

10.3

User Data

10.4

Network

11 Summary of Assets, Vulnerabilities and

Worksheet

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib