TSB-4940: Smart Device Communications;
Security Aspects;
1
2
Contents
3
4
1
RELATED REFERENCES ......................................................................................................................................... v
5
2
INTRODUCTION ........................................................................................................................................................ 7
6
3
Definitions and Abbreviations ............................................................................................................................ 8
7
3.1
Definitions ................................................................................................................................................................ 8
8
3.2
Abbreviations ......................................................................................................................................................... 9
9
4
Purpose ...................................................................................................................................................................... 12
10
4.1
Objective ................................................................................................................................................................ 12
11
4.2
Target Audience.................................................................................................................................................. 12
12
5
13
5.1
Block Cipher ......................................................................................................................................................... 14
14
5.2
Stream Cipher ...................................................................................................................................................... 14
15
5.3
Symmetric Cryptography................................................................................................................................ 15
16
5.4
Asymmetric Cryptography ............................................................................................................................. 15
17
5.5
Key............................................................................................................................................................................ 15
18
5.6
Digital Signature ................................................................................................................................................. 15
19
5.7
Hash ......................................................................................................................................................................... 16
20
6
21
22
23
Cryptology Introduction ..................................................................................................................................... 14
Securing Data........................................................................................................................................................... 17
6.1 Data in Transit ..................................................................................................................................................... 17
6.1.1 Protocol Guidance .......................................................................................................................................... 17
6.1.2 Key Agreement ................................................................................................................................................ 18
26
6.2 Multilayer Guidance .......................................................................................................................................... 18
6.2.1 “Direct” Use Case ............................................................................................................................................ 20
6.2.2 “Multiple Hop” Use Case .............................................................................................................................. 20
27
7
24
25
28
29
30
31
32
33
34
Secure the Attack Surface ................................................................................................................................... 22
7.1 Secure Software Development ..................................................................................................................... 23
7.1.1 Access information via Privileged Code ................................................................................................ 23
7.1.2 API’s ..................................................................................................................................................................... 24
7.1.3 Type-Safe and Managed Code ................................................................................................................... 24
7.1.4 Communication endpoint vulnerabilities ............................................................................................ 24
7.1.5 Communication channel vulnerabilities .......................................................................................... 2524
7.1.6 Network access vulnerabilities................................................................................................................. 25
Contents
|
i
TSB-4940: Smart Device Communications;
Security Aspects;
3
7.2 Data at Rest........................................................................................................................................................... 25
7.2.1 Minimum Security.......................................................................................................................................... 26
7.2.2 Authorization vulnerabilities .................................................................................................................... 27
4
8
5
8.1
Risk Management............................................................................................................................................... 29
6
8.2
Risk Assessment ................................................................................................................................................. 30
7
8.3
Threats ................................................................................................................................................................... 31
8
9
1
2
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
RISK ............................................................................................................................................................................. 28
Threats Against the Architecture .................................................................................................................... 34
9.1 Operating System ............................................................................................................................................... 35
9.1.1 Security Credentials Compromised ........................................................................................................ 36
9.1.2 (Re) Provisioning the device through FOTA ....................................................................................... 37
9.1.3 Subverting Integrity Checking Procedures.......................................................................................... 38
9.1.4 Accessing the device‘s privileged code through OS and application bugs.............................. 39
9.1.5 Faking General Software Identity ............................................................................................................ 40
9.1.6 Access via (non)invasive debug ports (JTAG) .......................................................................................... 41
9.2 Application ............................................................................................................................................................. 42
9.2.1 Injection ............................................................................................................................................................... 43
9.2.2 Session Management and Broken Authentication ................................................................................ 45
9.2.3 Security Misconfiguration.............................................................................................................................. 46
9.2.4 Insecure Cryptographic Storage .................................................................................................................. 47
9.2.5 Validate Input Data ........................................................................................................................................ 48
9.2.6 Cross Scripting................................................................................................................................................. 49
9.3 User Data .......................................................................................................................................................... 5150
9.3.1 Transfer of keys via independent security element.................................................................... 5150
9.3.2 Buffer Overflows.......................................................................................................................................... 5251
28
9.4 Network ................................................................................................................................................................. 53
9.4.1 Eaves Dropping/Man In the Middle Attack .................................................................................... 5554
9.4.2 Replay Attacks ............................................................................................................................................ 5756
29
10
26
27
30
31
ii
|
Summary of Assets, Vulnerabilities and Worksheet ....................................................................... 5958
TSB-4940: Smart Device Communications;
Security Aspects;
1
Foreword
This document was formulated under the cognizance of the TIA Committee
TR-50, M2M-Smart Device Communications.
2
3
Suggestions for improvement of this document are welcome, and should be
sent to:
4
5
Telecommunications Industry Association,
Standards and Technology,
2500 Wilson Boulevard, Suite 300
Arlington, VA 22201-3834
6
7
8
9
10
11
Revision History
Designation
12
Date †
Comments
TSB-4940
2012-12-18 initial release
† date approved by Formulating Group - publication date may be later.
13
14
Foreword
|
iii
TSB-4940: Smart Device Communications;
Security Aspects;
1
SCOPE
The guidance provided in this Telecommunications Systems Bulletin (TSB) 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.
2
3
4
5
6
7
8
9
10
11
12
13
14
iv
|
Revision History
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1 RELATED REFERENCES
This TSB addresses the reference architecture contained in:
TIA-4940.005,
Architecture
Smart
Device
Communications;
Reference
This TSB is based on the general concepts, principles and practices presented
in:
National Institute of Standards and Technology (NIST) Special
Publication (SP) 800-27, Engineering Principles for IT Security,
NIST SP 800-14, Generally Accepted Principles and Practices for
Securing Information Technology Systems,
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,
20 Critical Security Controls for Effective Cyber Defense, Consensus
audit Guidelines volume 3, August 15, 2011
Digital Signatures Using Reversible Public Key Cryptography for the
Financial Services Industry (rDSA), ANSI X9.31-1988, September
1998.
20
Revision History
|
v
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
3
4
5
6
7
8
9
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
2 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.005) 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
should 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.
35
|
7
TSB-4940: Smart Device Communications;
Security Aspects;
1
3 Definitions and Abbreviations
This section contains definitions and abbreviations that are used in this
document.
2
3
4
3.1
Definitions
For the purposes of the present document, the following terms and definitions
apply:
5
6
Asymmetric Cryptography: Public key cryptography is an asymmetric scheme
that uses a pair of keys for encryption.
7
8
10
Attack Surface: All A set of vulnerabilities that, when unprotected, may
compromise a system.
11
Authentication: The process of verifying the identity of entity.
12
Certificate: A document that binds a signature to an entity.
13
Cipher: An algorithm for performing encryption (reverse is decryption).
14
Ciphertext: Encrypting plaintext results in unreadable text.
15
Cleartext: Data that can be read and understood without any special measures.
This term is used interchangeable with “plaintext” in this document.
9
16
18
Confidentiality: The assurance to an entity that no one can read a particular
piece of data except the receiver(s) explicitly intended.
19
Cryptanalysis: The science of analyzing and breaking secure communication.
20
Cryptographic algorithm/cipher: A mathematical function used in the
encryption and decryption process.
17
21
23
Cryptography: The science of using mathematics to secure data via
encrypting and decrypting data.
24
Cryptology: Study of both cryptography and cryptanalysis.
25
Data-at-rest: Data that is stored within entities in a M2M system.
26
Data-in-transit: Data moving between entities in a M2M system.
27
Decryption: The process of reverting ciphertext to its original plaintext.
28
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.
22
29
30
31
Digital Signature: Enables the recipient of information to verify the
authenticity of the information’s origin, and also verify that the information is
intact.
32
33
34
Encryption: The method of disguising plaintext in such a way as to hide the
actual content of the text.
35
36
8
|
TSB-4940: Smart Device Communications;
Security Aspects;
Hash: A one-way function takes variable-length input and produces a fixedlength output; that ensures the information has not changed in any way.
1
2
Integrity: The assurance to an entity that data has not been altered
(intentionally or unintentionally) between “there” and “here” or between
“then” and “now.”
3
4
5
Key: A value that works with a cryptographic algorithm to produce a specific
ciphertext.
6
7
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.
8
9
10
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.
11
12
13
14
15
16
Symmetric Cryptography: One secret key is used both for encryption and
decryption.
17
18
19
20
21
3.2
Abbreviations
For the purposes of the present document, the following abbreviations apply:
22
AAA: Authentication, Authorization and Accounting.
23
AES: Advanced Encryption Standard.
24
ALE: Annual Loss Expectancy
25
API: Application Programming Interface
26
ARO: Annualized Rate of Occurrence
27
CIA: Confidentiality, Integrity and Availability.
28
CERT: Computer Emergency Response Team
29
CSS: Cascading Style Sheet
30
CWE/SANS: Common Weakness Enumeration/SANS Institute.
31
D-TSL: Datagram Transport Layer Security.
32
DH: Diffie-Helman
33
DSA: Digital Signature Algorithm.
34
DoS: Denial of Service.
35
ECC: Elliptical Curve Cryptography.
36
ECDSA: Elliptic Curve Digital Signature Algorithm.
|
9
TSB-4940: Smart Device Communications;
Security Aspects;
1
ECDH: Elliptic Curve Diffie-Helman key-agreement protocol.
2
FIPS: Federal Information Processing Standards.
3
FOTA: Firmware Over the Air.
4
HTTP: Hypertext Transfer Protocol.
5
IDS: Intrusion Detection System.
6
IoT: Internet of Things.
7
IPSec: Internet Protocol Security.
8
ISE: Identity Service Engine.
9
JTAG: Joint Test Action Group.
10
L2F: Layer 2 Forwarding.
11
L2TP: Layer 2 Tunneling Protocol.
12
LDAP: Lightweight Directory Access Protocol.
13
M2M: Machine to Machine.
14
MHS: Message Handling Systems protocol.
15
MIME: Multi-Purpose Internet Mail Extensions.
16
MITM: Man in the Middle..
17
MQV: Menezes-Qu-Vanstone algorithm.
18
MOSS: Minimum Operating Security Standards
19
MSP: Managed Service Provider.
20
NIST: National Institute of Standards and Technology.
21
NLSP: Network Layer Security Protocols.
22
NTSB: National Transportation Safety Board.
23
OS: Operating System.
24
OSI: Open Systems Interconnection.
25
PCT: Private Communications Technology.
26
PEM: Privacy-enhanced Electronic Mail.
27
PGP: Pretty Good Privacy.
28
PIC: Physical Interface Card.
29
PKCS: Public Key Cryptography Standards.
30
PKI: Public-Key Infrastructure.
31
PoA: Point of Attachment.
32
PPTP: Point-to-Point Tunneling Protocol.
33
RSA: Rivest/Shamir/Adleman encryption algorithm
10
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
S/HTTP: Secure Hypertext Transfer Protocol.
2
S/MIME: Secure Multi-Purpose Internet Mail Extensions.
3
SCADA: Supervisory Control and Data Acquisition.
4
SFTP: SSH File Transfer Protocol.
5
SHA: Secure Hashing Algorithm.
6
7
SILS/SDE: Standard for Interoperable LAN Security/Secure Date
Exchange
8
SLE: Single Loss Expectancy
9
SOCKS: SOCKet Secure.
10
SPKM: Simple Public Key Management.
11
SQL: Software Query Language.
12
SSH: Secure Shell.
13
SSL: Secure Sockets Layer
14
TIA: Telecommunication Industry Association.
15
TLSP: Transport Layer Security Protocol.
16
TLS: Transport Layer Security
17
UI: User Interface.
18
URL: Uniform Resource Locator.
19
XSS: Cross-Site Scripting.
20
XPath: XML Path Language.
21
|
11
TSB-4940: Smart Device Communications;
Security Aspects;
1
4 Purpose
This document is designed to build on 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 TSB and tailor them to their environment in managing M2M
related mission risks.
2
3
4
5
6
7
8
9
10
11
4.1
Objective
The objective of creating the threat analysis 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.
12
13
14
15
16
17
18
19
20
4.2
Target Audience
23
This TSB 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.
24
These personnel include:
25

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.
30

The IT security program manager, who implements the security program.
31

Information system security officers (ISSO), who are responsible for IT
security.

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.
21
22
26
27
28
29
32
33
34
35
36
37
12
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
2

IT system and application programmers, who develop and maintain code
that could affect system and data integrity
|
13
TSB-4940: Smart Device Communications;
Security Aspects;
1
5 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.
2
3
4
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.
5
6
7
8
9
10
11
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.
12
13
14
15
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.
16
17
18
19
20
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.
21
22
23
24
25
26
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.
27
28
29
30
31
5.1
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.
32
33
34
35
36
5.2
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
37
38
14
Stream Cipher
|
TSB-4940: Smart Device Communications;
Security Aspects;
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.
1
2
3
4
5
6
5.3
Symmetric Cryptography
In conventional cryptography, also called secret-key or symmetric-key
encryption, one key is used both for encryption and decryption. The key is
assumed to be secret in order for this type of cryptography to work. Example
usage includes email, http, IPsec. Symmetric cryptography is magnitudes
faster than asymmetric cryptography.
7
8
9
10
11
12
13
5.4
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.
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
5.5
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.
30
31
32
33
34
35
36
37
38
39
40
5.6
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
|
15
TSB-4940: Smart Device Communications;
Security Aspects;
he or she did not actually send the information. These features are every bit as
fundamental to cryptography as privacy, if not more.
1
2
3
4
5.7
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.
5
6
7
8
9
10
16
Hash
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
6 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.
2
3
4
5
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, any assumption that all devices are
created equal, is not valid. 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.
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
6.1
Data in Transit
21
6.1.1
Protocol Guidance
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
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 versus 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.
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.
42
|
17
TSB-4940: Smart Device Communications;
Security Aspects;
1
6.1.2
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.
2
3
4
5
6
7
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.
8
9
10
11
12
13
14
15
16
Security
Category
Encryption
& Key Size
Signature
Key Agreement
Digest
(per ANS X.931)
Level 1 (weakest)
NULL
NULL
NULL
NULL
Level 2
ECC 80
DSA/RSA/ECDSA
DH (static)
SHA 160
Level 3
ECC 112
DSA/RSA/ECDSA
DH (static)
SHA 160
Level 4
AES 192
DSA/RSA/ECDSA
ECDH
SHA 224
Level 5
ECC 256
DSA/RSA/ECDSA
ECDH 256
SHA 256
Level 6
AES 256
DSA/RSA/ECDSA
ECDH 384
SHA 386
Level 7 (strongest)
ECC 386
DSA/RSA/ECDSA
ECDH 384
SHA 386
Table 1
17
18
19
6.2
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.
20
21
22
18
Multilayer Guidance
|
TSB-4940: Smart Device Communications;
Security Aspects;
Security Vendor A
Transport or Application Layer e.g. SSL
Network Layer e.g.IPSEC
Aggregation Point
Device
Security Vendor B
1
Figure 1
2
Confidentiality
Integrity
Entity
Authentication
Data Origin
Authentication
Data Link
SILS/SDE,
PPTP, L2TP
SILS/SDE,
L2TP
PPTP, L2TP,
L2F
SILS/SDE, L2TP
Network
PIC,IPSEC,
NLSP
PIC, IPSEC,
NLSP
PIC, IPSEC,
NLSP
PIC, IPSEC,
NLSP
Transport
SOCKS, TLSP,
SSL, D-TLS,
TLS, PCT, SSH
SOCKS, TLSP,
SSL, D-TLS,
TLS, PCT, SSH
SOCKS, TLSP,
SSL, D-TLS,
TLS, PCT, SSH
TLSP
Application
S/HTTP, SPKM,
MHS,MSP,PEM,
SFTP,
PGP/MIME,
MOSS, S/MIME,
PKCS#7
S/HTTP, SPKM,
MHS,MSP,PEM,
SFTP,
PGP/MIME,
MOSS, S/MIME,
PKCS#7
S/HTTP,
SPKM, SFTP
S/HTTP, SPKM,
MHS,MSP,PEM,
SFTP,
PGP/MIME,
MOSS, S/MIME,
PKCS#7
Security
OSI Layer
3
4
5
6
7
8
NonRepudiation
of Origin
Non
Repudiation
of Receipt
SPKM, PEM,
MHS,MSP,
SFTP,
S/MIME,
ESS
SPKM,
MHS,MSP,
SFTP,
S/MIME,
ESS
Table 2
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.
9
|
19
TSB-4940: Smart Device Communications;
Security Aspects;
Service Provider
“Cloud Enabled”
MACRO
NETWORK
Regional Data
Aggregation Point
Home Data
AggregationPoint
Device
Device
1
Figure 2
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).
3
4
5
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.
6
7
8
9
10
11
12
13
14
15
6.2.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.
Home Data
Service Provider Regional Data
Device
16
17
18
19
Aggregation Point Aggregation Point
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
20
21
22
23
24
25
27
28
29
30
20
Service Provider’s minimum
security level willing to accept
A
Multilayer Guidance 2 Layers of
Security from different vendors
B. The service provider binds,
“DIRECT” Use Case
and accepts the connection
request, securing the session. Application session takes place within a
secure pipe.
26
31
B
6.2.2
|
“Multiple Hop” Use Case
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
3
4
5
6
7
8
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
Home Data
Service Provider Regional Data
Device
Device will require the use of a
Aggregation Point Aggregation Point
security
proxy
(i.e.
Data
Aggregation Point) to achieve the
F
service level agreement of
H
G
C
security level 5.
E
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
D
A. The device creates a
B
A
secure link following the
Service Provider’s minimum
Multilayer Guidance 2 Layers of
multilayer
guidance
security level willing to accept
Security from different vendors
(Figure 1) utilizing 2
“MULTIHOP” Use Case
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
33
|
21
TSB-4940: Smart Device Communications;
Security Aspects;
1
7 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 would subvert some
combination of hardware, software or procedural elements.
2
3
4
5
6
7
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.
8
9
10
11
12
Figure 3
13
14
Several ways to mitigate the attack surface include:
15

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
19

Replace potentially dangerous functions with safe counterparts
20

Validate input data
21

Minimize the number of open ports, installed services and applications
16
17
18
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:
22
23
24
25
22
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
2

Implement effective patch management
3

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.
4
5
6
7
8
7.1
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.
9
10
11
12
13
14
15
16
17
18
19
20
Figure 4
21
22
Listed below are categories that attackers look to exploit in software based
systems that the reader should be aware.
23
24
25
26
27
28
29
7.1.1
Access information via Privileged Code
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
|
23
TSB-4940: Smart Device Communications;
Security Aspects;
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.
1
2
3
4
5
6
7
8
9
7.1.2
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.
10
11
12
13
14
15
16
17
18
19
20
21
7.1.3
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.
22
23
Type-safe code cannot read values from another object's private fields. It
accesses types only in well-defined, allowable ways.
24
25
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).
26
27
28
29
30
31
32
33
34
35
7.1.4
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.
36
37
38
39
24
Type-Safe and Managed Code
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
7.1.5
Communication channel vulnerabilities
8
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.
9
Recommendations:
2
3
4
5
6
7
10

Rigorously protect authentication credentials during transmission
11

Implement secure communications best practices.
12

Detect data corruption or manipulation by performing system data
integrity checks

Consider the benefits and challenges of implementing data encryption
for the M2M systems.
13
14
15
16
17
7.1.6
Network access vulnerabilities
21
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.
22
Recommendations:
18
19
20
23

Segment networks
24

Implement strong firewall rules
25

Secure connections across security zones
26

Implement intrusion detection
27

Implement secure access to network devices
28
29
30
31
32
7.2
Data at Rest
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:
33
1. Implementing Secure Encryption algorithms, and the
34
2. Management of the cryptographic keys that unlock the encrypted data.
|
25
TSB-4940: Smart Device Communications;
Security Aspects;
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 needs to be strong, it should also be operationally simple
so as not to impede the mission. Failing to protect data at rest places the
device at risk including:
1
2
3
4
5
6
7

Additional systems can be compromised
8

Entire network can be compromised
9

Control of organization data, including network storage devices can be
lost
10
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.
11
12
13
14
15
16
17
18
19
20
7.2.1
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:
21
22
23
24
25
1. access control;
26
2. awareness and training;
27
3. audit and accountability;
28
4. certification, accreditation, and security assessments;
29
5. configuration management;
30
6. contingency planning;
31
7. identification and authentication;
32
8. incident response
33
9. maintenance;
34
10. media protection;
35
11. physical and environmental protection;
36
12. planning;
37
13. personnel security;
26
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
14. risk assessment;
2
15. systems and services acquisition;
3
16. system and communications protection; and
4
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.
5
6
7
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
should develop and promulgate formal, documented policies and procedures
governing the minimum security requirements set forth in this standard and
should ensure their effective implementation.
8
9
10
11
12
13
14
15
16
7.2.2
Authorization vulnerabilities
23
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
gives the attacker access to the resources of the compromised server,
including communications with other devices and servers.
24
Recommendations:
17
18
19
20
21
22
25

Implement least-privilege access control
26

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
27
28
29
|
27
TSB-4940: Smart Device Communications;
Security Aspects;
1
8 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.
2
3
4
5
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 needs 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.
6
7
8
9
10
11
12
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.
13
14
15
16
Mitigate
Threat Agents
Attack Vectors
Attack
Security Weaknesses
Weakness
Security Controls
Technical Impacts
Business Impacts
Controls
KABOOM!!!
Weakness
Controls
Weakness
Controls
Weakness
Controls
Asset
Attack
Attack
Impact
Asset
Impact
Function
Weakness
Understanding Weaknesses one can put
controls in place to mitigate Impacts
17
Figure 5
18
19
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
weakness and combine it with an estimate of the technical and business
impact to the organization. Together, these factors determine the overall risk.
20
21
22
23
24
25
26
28
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
3
4
5
6
7
8
8.1
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.
9
Figure 6
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
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:

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;
28
29
30
31
32
|
29
TSB-4940: Smart Device Communications;
Security Aspects;
1

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.
2
3
4
5
6
8.2
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:
7
8
9
10
11
12
13
14
15
16
17
•
Threats (to operations, assets, or individuals);
18
•
Vulnerabilities (to operations, assets, or individuals);
19
•
Impact (consequence or opportunity); and
20
•
Likelihood (probability or frequency an event will occur).
To support the risk assessment element, organizations identify:
21
•
Tools, techniques, and methodologies that are used to assess
risk;
24
•
Assumptions related to risk assessments;
25
•
Constraints that may affect risk assessments;
26
•
Roles and responsibilities related to risk assessment;
27
•
Risk assessment information to be collected, processed, and
communicated;
•
Threat information to be obtained.
22
23
28
29
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.
30
31
32
33
34
35
36
37
38
30
|
TSB-4940: Smart Device Communications;
Security Aspects;
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.
1
2
3
4
5
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.
6
7
8
9
10
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.
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
39
40
8.3
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
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.
|
31
TSB-4940: Smart Device Communications;
Security Aspects;
Criteria assigning likelihood levels include assessing the attacker, motivation,
opportunity, and capability. Quantifying each of the following classes within
the likelihood category individually:
1
2
3
4

5
Threat Agents of which can be detailed as:
6
0. No agent present
7
1. Individual criminal
8
2. Competitor
9
3. Extremist, Organized Crime
4. Terrorist or Nation State
10
11

12
13
Motivation; including financial, political, emotional, revenge as well
as constraints such as detection, and risk involved.
14
0. No motivation
15
1. Low
16
2. Moderate
17
3. Substantial
18
4. High

19
Opportunity; including proximity, security, standards
20
0. No Opportunity
21
1. Little
22
2. Limited
23
3. Substantial
24
4. High
25

26
27
Capability, including education, knowledge, access, specialized
equipment and reverse engineering.
28
0. None
29
1. Little
30
2. Limited
31
3. Substantial
32
4. High
33
Impact or Magnitude is calculated by the seriousness of a successful attack,
with the following levels:
34
35
32
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
1. Minor impact or no effect to the stakeholder
2
2. Serious impact, including impacting revenue streams, processes,
support systems
3
3. Widespread impact, causing irreparable damage to key systems and
processes
4
5
4. Severe impact causing damage to systems and processes that support
infrastructure requirements.
6
7
Risk assessment level is the product of impact and likelihood, generally the
larger the risk assessment, the more urgent the counter measure:
8
9
10
11
RANGE
CATEGORY
REMARKS
0≤3
Minor
Counter Measures Optional
4≤8
Major
Counter Measures Required As Soon As Possible
9 ≤ 16
Critical
Counter Measures Required Immediately
Table 3
12
|
33
TSB-4940: Smart Device Communications;
Security Aspects;
1
9 Threats Against the Architecture
2
PoA
applications
admin
node
applications
admin
home
applications
application
management
admin
device
management
PoA
devices
Data In Transit
application
domain
smart
device
protocol
smart
device
protocol
smart
device
protocol
convergence
convergence
convergence
PoA
node
server
device
domain
authentication, authorization
and accounting
AAA-SD
network management
core IP
3
Figure 7
4
5
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.
6
7
8
9
10
11
12
13
14
15
16
To help prevent exploitation or limit damage from cyber-attack surface
vulnerabilities, it is recommended that additional precautions be implemented,
such as:
17
18
19
20

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
21
22
23
24
34
|
TSB-4940: Smart Device Communications;
Security Aspects;
1

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
2
3
4
5
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.
6
7
8
9
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:
10
11
12
13

Operating System
14

Applications
15

User Data
16

Network
17
18
9.1
Operating System
19
PoA
applications
admin
node
applications
admin
home
applications
admin
device
management
PoA
devices
smart
device
protocol
application
management
smart
device
protocol
smart
device
protocol
device
domain
authentication, authorization
and accounting
AAA-SD
convergence
convergence
convergence
PoA
node
server
network management
core IP
20
21
Figure 8
22
23
This section drills down in to the operating system threats and vulnerabilities.
|
35
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
9.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.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Assessment
17
Likelihood (2): Moderate

Threat Agent (2): Competitors, criminal, hacker, and disgruntled
employees.
20

Motivation (2): Financial, Reputation
21

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.
18
19
22
23
24
25
26
Impact (2): Serious
27
28

Localized inconvenience
29

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.
30
31
32
33
34
35
36
Risk (4): Likelihood x Impact = 4 Major Risk
37
Counter Measures:
36
|
TSB-4940: Smart Device Communications;
Security Aspects;

Store M2M Security Keys in a tamper resistant secure environment
which protects against discovery by either logical or physical
means
4

Bind a device to a secure environment by physical/logical means
5

Secure environment does not provide stored values to anyone.
1
2
3
6
7
9.1.2
(Re) Provisioning the device through FOTA
12
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.
13
The attack may also:
8
9
10
11

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.
18

Commit fraud by reporting incorrect readings.
19

Break Privacy Rules
20

May camouflage attacks elsewhere on the network by falsely
reporting an attack on itself.
14
15
16
17
21
22
23
24
This attack can be accomplished remotely, and can completely change a
device’s operation.
25
26
Assessment
27
Likelihood (4): Severe Likelihood

Threat Agents (4): Competitors, criminal, hacker, Nation States,
and disgruntled employees.
30

Motivation (3): Financial, Reputation, Political
31

Opportunity (3): Devices/Nodes are IP addressable, with Servers
(hopefully) behind firewalls.

Capability (4): Assume knowledge of Protocols.
28
29
32
33
34
35
36
Impact (4): Compromised Infrastructure

Major effect on stakeholders; viruses may make the infrastructure
unreliable, thereby denying accurate reporting
|
37
TSB-4940: Smart Device Communications;
Security Aspects;
1

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.
2
3
4
5
6
Risk (16): Likelihood x Impact =16 Critical Risk
7
Counter Measures:

Create a secure connection between entities providing for mutual
authentication and confidentiality
10

Place all devices, nodes and servers behind a firewall.
11

Create a ‘modern’ secure connection between entities providing for
mutual authentication and confidentiality that is known to be
acceptable.
8
9
12
13
14
15
9.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.
16
17
18
19
20
21
22
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.
23
24
25
26
27
28
This attack is enabled through poorly written code, interfacing between the
user/privileged boundary or by hardware techniques.
29
30
31
32
Assessment
33
Likelihood (3): Substantial Likelihood

Threat Agents (3): Competitors, criminal, hacker, and disgruntled
employees.
36

Motivation (3): Financial, Political
37

Opportunity (2): Has architecture, protocol knowledge though only
access 1 device at a time.
34
35
38
38
|
TSB-4940: Smart Device Communications;
Security Aspects;

1
2
Capability (3): Architecture knowledge and expertise, access to
standards/procedures.
3
Impact (4): Compromised Infrastructure
4
5

Localized inconvenience
6

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.
7
8
9
10
Risk (12): Likelihood x Impact = 12 Critical Risk
11
Counter Measures:
12

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.
13
14
15
16
17
18
9.1.4
Accessing the device‘s privileged code through OS and application
bugs
28
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
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.
29
Examples of operating system API calls that may lead to vulnerabilities:
19
20
21
22
23
24
25
26
27
30

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
31
32
33
34
35
36
37
Assessment
38
Likelihood (4): Great Likelihood
|
39
TSB-4940: Smart Device Communications;
Security Aspects;

Threat Agents (4): Competitors, criminal, hacker, and Nation
States.
3

Motivation (4): Financial, Political
4

Opportunity (4): Has architecture, protocol knowledge, physical
and electrical proximity.

Capability (4): Architecture knowledge & expertise, access to
standards/procedures and financial backing
1
2
5
6
7
8
Impact (4): Compromised Infrastructure
9
10

Major inconvenience loss of confidence in vendor, system
11

Detectable: Difficult if not impossible if there are no countermeasures
for detecting.

Recoverable: Nearly impossible without countermeasures
12
13
14
Risk (16): Likelihood x Impact = 16 Critical Risk
15
Counter Measures:
16

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
17
18
19
20
21
22
23
9.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.
24
25
26
27
28
29
30
31
Assessment
32
Likelihood (4): Great Likelihood
33

Threat Agents (4): Competitors, criminal, hacker, and Nation States.
34

Motivation (4): Financial, Political
35

Opportunity (4): Has architecture, protocol knowledge, physical and
electrical proximity.
36
40
|
TSB-4940: Smart Device Communications;
Security Aspects;

1
2
Capability (4): Architecture knowledge & expertise, access to
standards/procedures and financial backing
3
Impact (4): Compromised Infrastructure
4
5

Major inconvenience loss of confidence in vendor, system
6

Detectable: Difficult if not impossible if there are no countermeasures
for detecting.

Recoverable: Nearly impossible without countermeasures
7
8
Risk (16): Likelihood x Impact = 16 Critical Risk
9
Counter Measures:
10

11
None identified in the current document
12
13
14
15
16
17
18
19
20
9.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.
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.
21
22
Assessment
23
Likelihood (4): Great Likelihood
24

Threat Agents (4): Competitors, criminal, hacker, and Nation States.
25

Motivation (4): Financial, Political
26

Opportunity (4): Has architecture, protocol knowledge, physical and
electrical proximity.

Capability (4): Architecture knowledge & expertise, access to
standards/procedures and financial backing
27
28
29
30
31
Impact (4): Compromised Infrastructure
32

Major inconvenience loss of confidence in vendor, system
33

Detectable: Difficult if not impossible if there are no countermeasures
for detecting.

Recoverable: Nearly impossible without countermeasures
34
35
36
Risk (16): Likelihood x Impact = 16 Critical Risk
|
41
TSB-4940: Smart Device Communications;
Security Aspects;
Counter Measures:
1

2
Disable debug capability in a production
3
4
9.2
Application
5
node
applications
PoA
applications
admin
admin
home
applications
application
management
Application
admin
device
management
PoA
devices
smart
device
protocol
smart
device
protocol
smart
device
protocol
convergence
convergence
convergence
PoA
node
server
authentication, authorization
and accounting
AAA-SD
network management
core IP
6
Figure 9
7
8
Secure coding guides and standards are available in a wide range of languages
and software types. Some examples include:
9
10
11

CERT Secure Coding Standards
12

SAFECode Secure Coding Standards
13

20 Critical Security Controls: Critical Control 7: Application Software
Security
14
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:
15
16
17

18
19
All stakeholders follow secure development standards when developing new
products
22
o Implement secure coding practices that enforce rigorous input data
validation in system and services, database applications, and web
services
23
o Validate input and output data
20
21
42
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
o Use safe string and buffer functions
2
o Use robust integer operations and data types for memory operations.
3

4
5
During software development, including thorough code reviews via
manual and automated processes
o Using automated static analysis tools
6
o Using dynamic tools and techniques such as fuzz testing,
robustness testing, and fault injection
7
8
o Using a qualified third part that performs additional security
testing
9
10
11

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
12
13
14
15
16
17
18
o Conduct a security audit of a product
19
o Determine appropriate mitigations to meet specified security
levels
20
21
o Require and validate that products are delivered with secure
configurations
22
23
24

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
9.2.1
Injection
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
|
43
TSB-4940: Smart Device Communications;
Security Aspects;
flaws are easy to discover when examining code, but more difficult via
testing. Scanners and fuzzers can help attackers find them.
1
2
3
4
Assessment
5
Likelihood (3): Substantial Likelihood
6

Threat Agents (2): disgruntled employee, competitor
7

Motivation (2): Financial, emotional,
8

Opportunity (3): substantial
9

Capability (2) : knowledge, specialized access
10
Impact (3): wide spread
11

12
13
Data can be exposed even when the user has proper authentication and
authorization credentials.
Risk (9): Likelihood x Impact = 9 Major Risk
14

15
16
17
Injection can result in data loss or corruption, lack of accountability, or
denial of access. Injection can sometimes lead to complete host
takeover.
18
Counter Measures:
19

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
35

Validate input and output data
36

Use safe string and buffer functions
37

Use robust integer operations and data types for memory operations
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
44
|
TSB-4940: Smart Device Communications;
Security Aspects;

1
2
During software development, including thorough code reviews via
manual and automated processes
o Using automated static analysis tools
3
o Using dynamic tools and techniques such as fuzz testing,
robustness testing, and fault injection
4
5
o Using a qualified third part that performs additional
security testing
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
9.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.
21
22
Assessment
23
Likelihood (3): Substantial Likelihood
24

Threat Agents (2): Competitors.
25

Motivation (2): Financial
26

Opportunity (1): limited
27

Capability (2) : knowledge, specialized access
28
29
Impact (2): Serious Impact
30

Data can be stolen or altered
31

Impersonation.
32
33
34
35
36
37
Risk (6): Likelihood x Impact = 6 Major Risk

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:
|
45
TSB-4940: Smart Device Communications;
Security Aspects;

Put in place encryption and/or strong session management
security controls.

Implement secure coding practices that enforce rigorous input
data validation in system and services, database applications,
and web services
6

Validate input and output data
7

Use safe string and buffer functions
8

Use robust integer operations and data types for memory
operations
1
2
3
4
5
9
10
11
9.2.3
Security Misconfiguration
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.
12
13
14
15
16
17
18
Assessment
19
Likelihood (3): Substantial Likelihood
20

Threat Agents (2): No agent, disgruntled employee, competitor
21

Motivation (2): Financial, emotional,
22

Opportunity (1): limited
23

Capability (2) : knowledge, specialized access
24
Impact (2): Serious Impact
25
26

Data can be stolen or altered
27

Impersonation.
28
Risk (6): Likelihood x Impact = 6 Major Risk
29

30
31
32
Such flaws frequently give attackers unauthorized access to some
system data or functionality. Occasionally, such flaws result in a
complete system compromise.
33
Counter Measures:
34

35
36
46
|
A repeatable hardening process that makes it fast and easy to deploy
another environment that is properly locked down. Development, QA,
TSB-4940: Smart Device Communications;
Security Aspects;
and production environments should all be configured identically. This
process should be automated to minimize the effort required to setup a
new secure environment.
1
2
3
4

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
5
6
7
8
9
10
11
12
13
o Conduct a security audit of a product
14
o Determine appropriate mitigations to meet specified security
levels
15
16
o Require and validate that products are delivered with secure
configurations
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
9.2.4
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 will exploit something else first to gain the
needed access.
32
33
Assessment
34
Likelihood (3): Substantial Likelihood
35

Threat Agents (2): No agent, disgruntled employee, competitor
36

Motivation (2): Financial, emotional,
37

Opportunity (1): limited
38

Capability (2) : knowledge, specialized access
39
|
47
TSB-4940: Smart Device Communications;
Security Aspects;
Impact (2): Serious Impact
1

2
Data can be stolen or altered
3
Risk (6): Likelihood x Impact = 6 Major Risk
4

5
6
7
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.
8
Counter Measures:
9
10

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.
11
12
13
14
15
16
17
18
19
20
21
9.2.5
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.
22
23
24
25
26
27
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.
28
29
30
31
32
33
34
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
message is valid, and that the message is valid given the state of the
35
36
37
38
39
48
Validate Input Data
|
TSB-4940: Smart Device Communications;
Security Aspects;
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
1
2
3
4
Assessment
5
Likelihood (3): Substantial Likelihood
6

Threat Agents (2): No agent, disgruntled employee, competitor
7

Motivation (2): Financial, emotional,
8

Opportunity (1): limited
9

Capability (2) : knowledge, specialized access
10
Impact (2): Serious Impact
11

12
Data can be stolen or altered
13
Risk (6): Likelihood x Impact = 6 Major Risk
14
Counter Measures:

15
16
17
Establish processes 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.
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
9.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.
33
34
Assessment
35
Likelihood (3): Substantial Likelihood
36

Threat Agents (2): No agent, disgruntled employee, competitor
37

Motivation (2): Financial, emotional,
|
49
TSB-4940: Smart Device Communications;
Security Aspects;
1

Opportunity (1): limited
2

Capability (2) : knowledge, specialized access
3
Impact (2): Serious Impact
4

5
Data can be stolen or altered
6
Risk (6): Likelihood x Impact = 6 Major Risk
7

8
9
10
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.
11
Counter Measures:
12
14
Preventing XSS requires keeping untrusted data separate from active
browser content.
15

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 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.
13
16
17
18
19
20
21
22
23
24
25
26
50
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
9.3
User Data
User Data
node
applications
PoA
applications
admin
admin
home
applications
application
management
admin
device
management
PoA
devices
smart
device
protocol
smart
device
protocol
smart
device
protocol
authentication, authorization
and accounting
AAA-SD
convergence
convergence
convergence
PoA
node
server
network management
core IP
2
Figure 10
3
4
5
6
7
8
9
10
11
12
9.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.
13
14
Assessment
15
Likelihood (3): Substantial Likelihood
16

Threat Agents (3): Competitors, criminal, hacker.
17

Motivation (3): Financial, Political
18

Opportunity (2): Requires physical access and product knowledge.
19

Capability (3): No technical knowledge required
20
21
22
Impact (2): Serious

Major inconvenience and financial loss
|
51
TSB-4940: Smart Device Communications;
Security Aspects;
1

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: Countermeasures
2
3
4
5
6
Risk (6): Likelihood x Impact = 6 Major Risk
7
8
Counter Measures:
9
10

Sensitive Data needs to be bound to the device itself
11

Fraud detection system within the M2M environment
12
13
14
9.3.2
Buffer Overflows
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)
15
16
17
18
19
20
21
22
23

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

24
Assessment
25
Likelihood (4): Great Likelihood
26

Threat Agents (4): Competitors, criminal, hacker, and Nation States.
27

Motivation (4): Financial, Political
52
|
TSB-4940: Smart Device Communications;
Security Aspects;
1

Opportunity (4): Has architecture, protocol knowledge, physical and
electrical proximity.

Capability (4): Architecture knowledge & expertise, access to
standards/procedures and financial backing
2
3
4
5
Impact (4): Compromised Infrastructure
6
7

Major inconvenience loss of confidence in vendor, system
8

Detectable: Difficult if not impossible if there are no countermeasures
for detecting.

Recoverable: Nearly impossible without countermeasures
9
10
11
Risk (16): Likelihood x Impact = 16 Critical Risk
12
13
Counter Measures:
14

All stakeholders follow secure development standards when
developing new products

Implement secure coding practices that enforce rigorous input data
validation in system and services, database applications, and web
services
20

Validate input and output data
21

Use safe string and buffer functions
22

Use robust integer operations and data types for memory operations
23

24
During software development, including thorough code reviews via
manual and automated processes
25
o Using automated static analysis tools
15
16
17
18
19
o Using dynamic tools and techniques such as fuzz testing,
robustness testing, and fault injection
26
27
o Using a qualified third part that performs additional security
testing
28
29
30
31
32
33
34
35
36
9.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
|
53
TSB-4940: Smart Device Communications;
Security Aspects;

Identify and disable all OS or third-party application services not
explicitly needed for the system to operate
3

Vendors identify and document
4

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
11

Validate the necessity of services installed before they are deployed
12

Remove unneeded applications and services with great care
13

Owners document the way each system components use the network
so that effective firewall and IDS rules can be created
1
2
5
6
7
8
9
10
14
15
PoA
applications
admin
node
applications
admin
home
applications
application
domain
application
management
admin
device
management
PoA
devices
smart
device
protocol
smart
device
protocol
smart
device
protocol
convergence
convergence
convergence
PoA
node
server
device
domain
authentication, authorization
and accounting
AAA-SD
network management
core IP
16
Figure 11
17
18
Figure 12 below, provides reference markings between the interfaces layers
within a TIA M2M system.
19
20
21
54
|
TSB-4940: Smart Device Communications;
Security Aspects;
home application
B1
B2/B2'
A1
B4
node application
B5/B5'
B3/B3'
A2
PoA application/device
A3/A3'
authentication, authorization and accounting
AAA-SD
1
Figure 12
2
3
Within the network, there are many active attacks; the following list provides
a non-exhaustive sample of attacks against the TIA architecture.
4
5
6
7
8
9
10
11
12
13
14
15
9.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)
18

WAN which connects Devices to Nodes and Servers (B1, B2)
19

WAN which connects provisioning and AAA servers, as well as
network management servers (A2, B1, A3)
16
17
20
21
22
23
24
25
26
27
28
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
subtle flaws require inspecting the design of the application and the server
configuration. The attack exploits lack of security protection while data is in
|
55
TSB-4940: Smart Device Communications;
Security Aspects;
transit, or vulnerabilities in the protocol that was chosen to protect the
communication pipe.
1
2
3
4
Assessment
5
Likelihood (3): Substantial Likelihood
6

Threat Agents (2): Competitors, criminal, hacker.
7

Motivation (2): Financial, Political
8

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
9
10
11
12
Impact (3): Wide Spread
13
14

Minor localized inconvenience
15

Detectable: Minimal
16

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.
17
18
19
Risk (9): Likelihood x Impact = 9 Critical Risk
20
21
Counter Measures:
22
23

Secure Communication Link
24

Secure Communications Link with modern cryptographic algorithms
25

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:
26
27
28
29
30
31
32
33
35
o Require SSL for all sensitive pages. Non-SSL requests to these
pages should be redirected to the SSL page;
36
o Set the ‘secure’ flag on all sensitive cookies;
34
56
|
TSB-4940: Smart Device Communications;
Security Aspects;
o Configure your SSL provider to only support strong (e.g., FIPS
140-2 compliant) algorithms;
1
2
o Ensure your certificate is valid, not expired, not revoked, and
matches all domains used by the site;
3
4
o Backend and other connections should also use SSL or other
encryption technologies.
5
6
7
8
9
10
11
12
9.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:
13

Local Area Network which connect the devices to each other, as well
as nodes and servers. (B5)
16

WAN which connects Devices to Nodes and Servers (B1, B2)
17

WAN which connects provisioning and AAA servers, as well as
network management servers (A2, B1, A3)
14
15
18
19
20
21
22
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.
23
24
Assessment
25
Likelihood (3): Substantial Likelihood
26

Threat Agents (2): Competitors, criminal, hacker.
27

Motivation (2): Financial, Political
28

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
29
30
31
32
33
Impact (3): Wide Spread
34

Minor localized inconvenience
35

Detectable: Minimal
|
57
TSB-4940: Smart Device Communications;
Security Aspects;

1
2
3
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.
4
Risk (9): Likelihood x Impact = 9 Critical Risk
5
6
Counter Measures:
7
8

Secure Communication Link
9

Secure Communications Link with modern cryptographic algorithms
58
|
TSB-4940: Smart Device Communications;
Security Aspects;
1
2
10 Summary of Assets, Vulnerabilities and
Worksheet
3
ASSET
GOAL
VULNERABILITY
SLE
ARO
ALE
(Re)provision Device
System Integrity
Subvert Integrity Checking
OS/Application Bugs
Impersonating
Identity
Software
Buffer Overflow
Discovery Attack
Operating System
(Re)provision Device
System
Availability
Comprised Keys
Subvert Integrity Checking
OS/Application Bugs
Buffer Overflows
Comprised Keys
Subverting
Checking
Data
Confidentiality
Integrity
(Re)provisioning Device
Access via JTAG/Debug
Buffer Overflow
Application
Transfer of Data via ISE
Data Integrity
Compromised Keys
|
59
TSB-4940: Smart Device Communications;
Security Aspects;
Subvert Integrity Checking
(Re)provisioning Device
Availability
Man In The Middle
Replay
Network
Eaves Dropping
Man in the Middle
Integrity
Replay
Spoofing
Comprised Keys
Subverting
Checking
Data
Confidentiality
Integrity
(Re)provisioning Device
Access via JTAG/Debug
Buffer Overflow
User Data
Transfer of Data via ISE
Compromised Keys
Data Integrity
Subvert Integrity Checking
(Re)provisioning Device
1
60
|