Securing Industrial Control Systems: A Holistic Defense-In-Depth Approach

Securing Industrial Control Systems: A Holistic Defense-In-Depth Approach

Critical infrastructure is infused with proprietary protocols and software, air-gapped networks, and robust physical security systems—an amalgam that effectuated the notion of “security by obscurity” in the industrial control systems (ICS) community. Still, business needs eventually necessitated the convergence of information technology (IT) and ICS architectures. Although this seems like a match made in heaven, from an IT perspective, designing visibility and control into a system that inherently lacks them is a challenge that can be painful.

However, IT’s “defense-in-depth” security approach could be effective for ICS security. After all, this strategy employs a holistic approach to protect all assets—people, technology, operations, and adversarial awareness—while considering its interconnections and dependencies to provide effective layers of monitoring and protection based on exposure to cybersecurity risks (Figure 1).

1. A holistic approach. A defense-in-depth security approach employs a holistic methodology to protect all assets while considering dependencies to provide effective layers of monitoring and protection based on exposure to risks. Courtesy: Kudelski Security

1. A holistic approach. A defense-in-depth security approach employs a holistic methodology to protect all assets while considering dependencies to provide effective layers of monitoring and protection based on exposure to risks. Courtesy: Kudelski Security

The following highlights plausible best-practices for securing ICS environments using a defense-in-depth approach (Figure 2).

2. Defense-in-depth framework. Application and data security are at the center of all security efforts. Courtesy: Kudelski Security

Policy, Procedures, and Training

An effective ICS security program depends on the willingness of the operations staff and management to accept security as an enabler for all computer-oriented activities, as well as their ability to apply controls from a standpoint of acceptable risk.

With this in mind, organizational leadership must clearly define and communicate cybersecurity roles, responsibilities, expectations for performance, and authorities for managers, system administrators, and users through training programs and policies, while holding individuals accountable for their performance. This minimizes the likelihood of organizational personnel inadvertently disclosing sensitive information regarding supervisory control and data acquisition (SCADA) system design, operations, or security controls. Likewise, good management practices in handling delicate situations, recognizing and rewarding employees, and looking after their well-being can help diffuse potential insider threats.

Risk Management

Designing an effective ICS security architecture requires a risk model that maps functional requirements of these complex systems and provides a holistic image of potential real-world consequences. A thorough risk analysis procedure consists of identifying all assets (including software, network elements, and people) in the organization, as well as risk drivers or threats such as disgruntled employees, terrorists, hostile countries, and more.

Establishing a “Red Team” to identify potential attack scenarios and evaluate system vulnerabilities can help detect plausible intrusion methods, which should be evaluated as risks and categorized based on their likelihood of occurrence and impact to the organization. Note that actionable policies and procedures, along with monitoring and feedback, should be part of the risk management program. Periodic review is essential to stay current with evolving threat landscapes.

Vendor and Supply Chain Management

Organizations regularly employ contractors and third-party vendors who do not have uniform cybersecurity policies and practices. This creates exploitable weaknesses in the operations chain. Therefore, it is recommended that third-party requests be reviewed by IT—as well as legal and other relevant departments—with proper documentation. Documentation should be accompanied by regularly scheduled compliance reviews/revalidation, all based on assessed risks while confining intellectual property access to a need-to-know basis only. Likewise, rigid guidelines for evaluating the purchase of new SCADA devices must be established.

Incident Response Management

A comprehensive cyber incident response plan should include both proactive (to prevent incidents) and reactive measures (to detect and manage an incident). Therefore, it is recommended to establish a 24/7 incident monitoring program with the ability to detect threats to the ICS network. Having a comprehensive response plan (such as isolation strategies and disabling affected accounts) when adversarial activity is detected is also important. As critical is having a restoration plan—including establishing system backups (redundant hardware and fault-tolerant systems)—and disaster recovery plans (fallback mechanisms).

Audit and Assess

Auditing eliminates the “paths of least resistance” that an attacker could exploit. This involves technical audits of SCADA devices and networks, physical security surveys, and assessments of all remote sites connected to the SCADA network. This will identify security concerns while maintaining compliance with standards such as NIST-80053, NERC CIP, French ANSSI, CIDX/ACC, AGA 12, API, ISA/IEC 62443, CPNI, CPNI, ISO 27001, and others.

Compliance with standards/regulations does not guarantee continuous security, but it does provide a snapshot of required controls at a point-in-time. Considering numerous factors affect the security of a system throughout its life cycle, periodic testing and verification are important in achieving optimal security.

Physical Security

Physical considerations typically refer to a ringed architecture of layered security measures that restricts access to users to fulfill their duties only. Some measures include authentication for physical access such as key cards and biometrics, facility monitoring (cameras and motion detectors), perimeter defense (fences and anti-vehicle ditches), and visitor escort procedures.

Network Management

Securing ICS against modern threats requires well-planned and implemented strategies to give network defense teams a chance to quickly and effectively detect, counter, and expel an adversary. Therefore, it is recommended to:

  • Document network architecture and identify critical systems, connections to SCADA networks, and host-to-host communications paths. Evaluate the risks and disconnect items that aren’t required.
  • Physically separate corporate and control domains. Ensure isolation of ICS networks from untrusted networks and allow real-time connectivity to external networks only if there is a defined business requirement or control function.
  • Logically segment networks and isolate critical parts of systems. Demilitarized zones (DMZ) and data warehousing provide a secure buffer zone where services and data can be shared and secure transfer of data from the SCADA network to business networks can be ensured.
  • Deploy network access control and manage authentication (preferably two-factor or more) by requiring separate credentials for corporate and control network zones, and store these in separate trust stores. Never share active directories, RSA ACE servers, or other trust stores between corporate and control networks.
  • Require any remote access to be operator-controlled and time-limited. Firewalls, virtual private networks, callback (for dial-up), multi-factor authentication, user access control, and intrusion detection can provide “secure” remote access to computer networks.
  • Engage network monitoring tools and complement them by enabling logging on all systems. Regularly audit system logs to detect suspicious activity as soon as possible.
  • Take measures to avoid “watering hole” attacks. Use a web domain name (DNS) reputation system. Get updates from authenticated vendor sites. Validate the authenticity of downloads. Insist vendors digitally sign updates and publish hashes via an out-of-bound communications path, and require they use these to authenticate.
  • Lockdown all unused ports, services on routers, switches, and network daemons. Change all default configurations and passwords.
  • Deploy deception networks to boost the odds of finding an adversary early and mitigating overall damage.

Host Management

Asset inventory is an accurate baseline for identifying necessary security controls. Having identified the assets, lock down all unused ports and services on the host, and restrict privileges to only those needed. Also, manage authentication (preferably multi-factor) with secure password policies—stressing length over complexity—which should be unique and changed at least every 90 days. Harden the host by methods that include application dynamic whitelisting, memory protection, write protection and read protection.

Implement change management policies and procedures for protection against improper modifications prior to, during, and after commissioning. Have a configuration/patch management program centered on the safe importation and implementation of trusted patches. Monitor host activity and alert unauthorized changes.

Application and Data Management

Applications and data are critical elements of ICS environments. Avoid embedding hard-coded passwords in ICS applications. Also, demand that vendors disclose any backdoors or vendor interfaces to your SCADA systems and expect them to provide systems that are capable of being secured.

Conduct an initial assessment (static and dynamic analysis) and ensure compatibility of the application with the host operating system before deploying it. Restrict access to the application and data only to intended users. Finally, it is recommended to use cryptographic controls and data sanitation techniques to maintain the integrity and authenticity of the data collected.

3. ICS threat spectrum. State-sponsored actors have the motivation, capabilities, and means to be especially disruptive, but defense-in-depth security solutions are particularly effective against those threats. Courtesy: Kudelski Security

No environment is 100% secure. A threat-actor, through intent, capability, and opportunity, will always pose a threat to an ICS network by trying to compromise an organization’s systems through its operations, personnel, technology, and other vulnerabilities. Implementing the strategies and controls presented in this article can greatly improve the security posture of ICS.

This said, the determination of a security control is context-based, and there might arise a situation where ICSs have functional or operational properties that disallow application of a security control. In such cases, it is recommended to identify, assess, and implement necessary compensatory controls and ensure the SCADA security policies and standards complement the organization. IT security policies should also evolve to meet changing threat profiles and be scalable to accommodate different standards and regulations.

It needs to be foremost in everyone’s mind that in the SCADA world, availability, reliability, and stability are the most important criteria to be considered.

Vishruta Rudresh is senior cybersecurity researcher at Kudelski Security

Courtesy of Power Magazine. Read the original article here.

Blockchain Security: Part 2

Blockchain Security: Part 2

Current blockchain technologies expose institutions to security risks that plague current business processes and much more. Early demonstrations of vulnerabilities in blockchain implementations have helped us compile the following list of security risks.

Integrity Risks

While blockchain does provide integrity, it does not, however, entirely prevent the possibility of unrelated data being added to the blockchain. The phrase ‘ holds true in a blockchain system of records, just as is with a centralized database. This trustless nature of blockchain could be leveraged to buy and sell malware between anonymous persons. At Black Hat Asia 2015, Interpol demonstrated a proof of concept malware that subverted the underlying blockchain of Bitcoin. In another instance, researchers from the University of Newcastle also introduced a botnet command and control to send messages to bots on the Bitcoin network.

One might argue that there are several processes that enable specific transactions to be verified by specific nodes (validators) in a blockchain network, thereby uploading the integrity of the transaction and the trustful nature of the Blockchain. However, such processes seem to have inherent flaws. For instance,

  • Sharding: a process that requires the use of transaction receipts for one shard to communicate with the next can introduce significant faults (i.e. reversion of subsequent transactions) if a specific subset of validators was to wrongly validate transactions to which other members of the same blockchain refer to.
  • Blockchain pruning: a process that involves downloading block headers (a hashed version of past data) and the underlying data of the most recent blocks and then cross-referencing them with other nodes (rather than downloading the entire database) has some serious security challenges – if an attacker were to convince a user/node that the fraudulent block headers they verify are genuine, the malicious header would then become part of the Blockchain network and hence, all subsequent transactions can/would be corrupted.

Confidentiality Risks

The caveat with blockchains is that their pseudo-anonymous nature can help protect the identity of malicious persons as well. Furthermore, blockchains, if designed to be a public, some data (public keys used by the persons involved in the transaction, personal data, etc.) on the blockchain are made available for the public to glean information and determine the identity of a person. In addition, blockchain data being foremost in the functioning of smart contracts provided they are not designed or implemented as per the best security practices, stand to pose the potential risk of sensitive data leakage as well.

Smart Contract Risks

Smart contracts are essentially programs that run on the distributed ledger. As is with any software, the more complex a smart contract, the more prone it is to errors. Generally, the function and the security of smart contracts code depends on the coder’s abilities. A review by Peter Vessenes found that large numbers of template contracts available on the web for the Ethereum scripting system contained significant vulnerabilities. In June 2016, approximately US$50 million in assets was drained from a newly formed digital venture capital fund, the DAO, due to an unintentional flaw in its smart contract code.

Distributed Risks

The distributed nature of blockchain architecture makes it difficult to shut down a malicious program. An instance of this is the presence of rogue wallets (a very large number of malicious wallets) that push large amounts of spam transactions to the blockchain network. This increases the processing time, resulting in a potential denial of service (nodes will be checking the validity of the fraudulent transactions)

Cryptography Risks

The security of the blockchain is limited to the strength of the cryptographic algorithms used and implemented. For instance, blockchains (Bitcoin) are known to use ECSDA as one of their underlying cryptographic algorithms, however, ECSDA is vulnerable to fault attacks. Furthermore, some blockchain implementations rely on software solutions to generate and manage cryptographic keys. However, software solutions tend to have weakened random number generators, making them susceptible to brute force attacks

In foresight, it can be stated that blockchains face quantum computing risks as well. Quantum computing is being advocated to threaten the very premise of asymmetric cryptography. Popular security algorithms that are used for securing information through a complicated challenge (e.g. RSA, ElGamal) is said to be resolved in a shorter period of time through the use of quantum computing. Thereby incentivizing attackers who otherwise would have refrained from breaking a cryptographic algorithm.

Design Risks

Some consensus protocols are slow to compute, providing a window of opportunity for an attacker to creep into the network. Few other protocols do not have the concept of penalties to the participating nodes, making it easier for a malicious user to attack. There is also the possibility of Consensus Hijack or the 51% attack – if more than half of the computers working as nodes to service the network tell a lie, the lie will become the truth.

‘51% attack’ was highlighted by Satoshi Nakamoto when he launched Bitcoin. This enables a group of attackers to achieve consensus in their favor. Another consequence of such an attack is in the perspective of adoption. Any chain coming under attack might see an outflow of participants, leading to the question of which chain should be considered as the “main” one to follow (due to the potential fork of the “main” chain) as well as potentially crippling the value of that chain.

Forking Risks

This risk is associated with upgrading the blockchain software. Nodes which do not get upgraded in a timely manner run the risk of working on an outdated chain, resulting in an ordinary chain to be forked into two chains (new and old chains). This, however, could be mitigated by implementing a fixed-time notice period prior to regulator-issued major protocol updates being made effective.

Sidechain Risks

Sidechains (mechanism that allows tokens from one blockchain to be securely used within a completely separate blockchain but still moved back to the original chain if necessary), in certain cases, pose the risk of a user not contributing the relevant mining power to secure that chain because the user no longer has an interest in tracking the data and maintaining the operation of a sidechain. Furthermore, there is also the potential risk of a sidechain gateway, a mechanism used to transfer assets and messages between chains, being invalidated. An instance of this can be illustrated in the case of a Bitcoin sidechain where a user will “lock” Bitcoins in an address on the main Bitcoin Blockchain  and then issue proxy tokens for these on the sidechain, allowing users to exchange sidechain tokens for the original token and also transact with others on that sidechain (this mechanism is called a 2-way peg). If, however, the initial “locking” transaction is later considered invalid, then subsequent proxy-token transactions would also be affected. Additionally, owners of proxy tokens that had been affected would not be able to convert these back to the original asset via the pegging mechanism.

A benefit, however, is that fraudulent transactions or attacks on a sidechain do not affect the validity of data held in the parent chain. But, in the event that a sidechain was to be put out of service, the benefit becomes an unmanageable bane on the parent chain, subjecting it to high-stress levels as the sidechain users migrate their transaction volumes to the parent chain.

Implementation Risks

Error in logic and poor implementation of blockchain, smart contracts, or identity management enables attackers to obtain access to the blockchain and steal personally identifiable information. It can also result in fraudulent transactions such as:

  • Double-spending: This involves sending two transactions, one of which will cancel the other.
  • Hacked key: This type of transaction is broadcast to the network but has not been conducted by the true owner. This happens when a third party obtains unauthorized access to a key.
  • Non-compliant transaction: This type of transaction is mainly applicable to permissioned, regulated networks. It involves broadcasting a message either from an unauthorized address or against predefined business rules (Note: Hyperledger solves this issue with a blend of enrolment (authorization) certificates and single-use transaction certificates to allow transactions).

Furthermore, misconfigurations or absence of patches can help attackers compromise security vulnerabilities in the code that operates the Blockchain or the application built on Blockchain. There have been several instances of these reported over the years – In August 2016, the Hong Kong-based Bitfinex cryptocurrencies exchange suffered a breach when security vulnerabilities within individual organizations and service providers were exploited. In this attack, almost 120,000 Bitcoin were removed from customer accounts and similarly, in November 2017, a single user involuntarily triggered a software flaw that froze roughly 70 crypto-purses worldwide.


From the hoard of security risks posed by blockchain technology, it would be a misstep to state that “Blockchain s are inherently secure.” They do pose the risks and threats associated with traditional software solutions and do require a comprehensive framework to identify and respond to security threats and risks related to any blockchain implementation.


Blockchain Challenges: Part 1

Blockchain Challenges: Part 1

Blockchain, the technology underlying cryptocurrencies like Bitcoin, Blockstream, Ethereum, Ripple, is considered a phenomenon by its proponents and is touted as a solution to all of the inefficient information processing systems. Critics, however, remain wary of its applications and socio-economic benefits. Either way, Blockchains and their applications are expected to grow exponentially, thereby urging us to question their security challenges and risks.

Blockchains are in part a computing infrastructure, a transaction platform, a decentralized or distributed accounting ledger, and a peer-to-peer network. They are considered to be reliable, transparent (to an extent), autonomous, and immutable. Blockchain also evokes trust among its users via mass validation and secure authentication, while providing integrity and confidentiality.

In summary, blockchains seem to pose the capabilities that could disrupt the Internet as we know it (IPFS as a replacement for HTTP). However, as with any technology, there are grave challenges and risks associated with it. In part two of our series, we’ll delve into specific security challenges and risks that blockchains face.

In part one, we’ll illustrate the security challenges that plague blockchains. While each specific implementation or use case of a blockchain brings its own security challenges and risk implications, there are, however, some common challenges.

Blockchains and their applications have uncertain legal and compliance requirements due to their distributed nature. No known nation has any defined rules or regulations regarding them. Additionally, current security standards and regulations also seem ambiguous in a blockchain ecosystem and pose a formidable challenge in implementing the same technically. For instance, GDPR (General Data Protection Regulation) requires companies to implement “right to be forgotten” regarding data collected from EU citizens. This, however, can be grueling to implement considering its distributed nature (multiple parties have the data from the ledger and would be difficult to track and delete all concerned data).

Also, security policy implementations such as incident response management, vulnerability management, etc. would be hard to document and implement considering the distributed nature of blockchains. For instance, ensuring timely patching of all instances of the blockchain in a consistent manner would be difficult and poses unique risks to organizations that implement blockchains.

Finally, with increasing range of blockchain offerings, there exists the unique challenge of constructing a detailed threat model on which organizations can perform a risk assessment. The extent to which a compromise can impact the overall blockchain ecosystem is still quite unclear considering it also lacks the clarity of oversight and auditability that most traditional centralized systems offer.

Technical Challenges

  • Blockchain harbors unique operational constraints. For instance, centralized logging and monitoring are essential for enterprise environments but have not been addressed in blockchains.
  • Blockchains have inherent issues pertaining to scalability, latency, storage, and performance in their current form.
  • Blockchains have a large attack surface. Their distributed nature allows confidential information like payment data to be replicated in a number of places, potentially offering hackers more places to get their hands on it.
  • Blockchains have interoperability challenges. Using different distributed ledgers will likely bring the need for data sharing between them. Exchanging data will require translation of formats and protocols, which currently are in the nascent stages.
  • Unlike traditional systems, where a server administrator is capable of tracking attempted break-ins into a customer or user account, in blockchains, a malicious user can try limitlessly to decrypt or try to reproduce a private key associated to a given ledger. Tracking attempted break-ins with blockchain is close to impossible, and one is not aware until after the hacker has succeeded.
  • The veracity of each entry in blockchain rests on who controls the private key for each compromise of the private key can jeopardize portions of the blockchain and the data it holds.
  • Lack of tools to combat illegal activity. Though it might be possible to identify who owns an address used for money laundering, despite attempts at obfuscating the transaction, it is not possible to block these types of transactions in advance.
  • The consensus-based nature of adoption combined with the cross-application and industry aspirations of blockchain technology means protocols may not evolve sufficiently fast or in correlation with more complex business needs.
  • Another challenge that arises with users is that the blockchain network could be more trustworthy than the machine used to access it. Though the record of the transactions would be verifiable, the intent to perform that transaction might not be.
  • Reverting previous actions or fraudulent transactions in a decentralized chain is not easy, and its ramifications are uncertain as well.

Keeping in the mind the challenges that blockchains bode, it is recommended that organizations determine if their application truly requires a blockchain implementation or not. If it does, it is best to follow known security implementation standards for applications and cryptographic implementations. Additionally, ensure to use multiple signatures for authorizing and processing transactions; use standardized libraries for smart contracts (Smart contract security best practices), and use post-quantum crypto such as SPHINCS as a future-proof solution against quantum computing.


Winning the Cyber Battle: Trusting Your Digital Assets

Winning the Cyber Battle: Trusting Your Digital Assets

Digital assets are mission-critical elements of combat environments. They could be as complex as a modern fighter jet, as simple as an air purity sensor, or as commonplace as the cell phone that soldiers carry on them. From their role in communication and intelligence gathering, to their presence inside weapon systems that assist critical-missions cannot be disregarded. However, over the years, these digital assets have become complex ecosystems that are cumbersome to manage and protect against the risks of interference and exploitation from third-parties.

In this article, we explore the factors that catalyze the wariness among the armed forces in adapting to digital assets in combats, discern the critical need to trust and adopt digital assets in critical-missions, and the necessary precautions the equipment manufacturers and the military can adopt to ensure trust in digital assets.


In this epoch of robotics and artificial intelligence, digital assets (electronic systems that rely on digital logic and an embedded circuit to perform a task) have made in-roads into almost every aspect of our lives-from communication and transportation, to medical care and home automation. Their influence in combat environments has also evolved commensurately.

Lenk, chief of service strategy and innovation, NATO Communications and Information Agency predicts that in 5 or 10 years from now, the military world will be full of devices that are talking to each other, talking to command and control systems and talking to everything! [1]

When you think about it, the benefits of using digital devices in combat is fairly obvious: – improved situational awareness and logistics support, expert medical assistance (anywhere-anytime), enhanced accuracy in intelligence gathering and surveillance, secure communication, etcetera. Indeed, in modern warfare with its asymmetrical dimension, it does seem difficult to imagine military successes without the aid of digital assets.

Nevertheless, the adaption to these digital devices in the armed forces hasn’t been easy. It seems that our dependence on digital technologies is at odds with the level of trust we can place in them.

Why the distrust?

Various factors have contributed to the wariness among the armed forces for adopting digital devices in combats:

Erstwhile exploitations: There are diverse reasons why an adversary would want to compromise a device, as part of the overarching aim to gain a strategic or tactical advantage. If they can disrupt its functionality, deny its services to legitimate users, degrade its performance, deceive its users into performing unintended actions or destroy it completely, their position becomes stronger. Adversaries can do so by compromising vulnerabilities present in the devices. In recent times, this has been realized in various digital weapons and devices. For instance, drones -digital devices used by the military to generate interference in enemy signals and for long range surveillance- have been the subject of exploitation by enemies and insurgents over the years:

  • In 2009, insurgents in Iraq compromised drones using a software available on the Internet for $26 a piece. They intercepted live video feeds that were relayed back to a US controller from the drones. The information leakage revealed potential targets targeted by the US and aided the insurgents in taking evasive actions. [2]
  • In 2011, a computer virus infected the drone control center of Predator and Reaper drones and monitored keystrokes during missions carried out in Afghanistan and other war-zones. The monitoring and relaying of the keystrokes during missions potentially revealed classified information to the enemy. [3]
  • At the 2015 DEF CON event, security researchers successfully compromised a Parrot A. R. Drone using open WIFI and an open Telnet port to remotely terminate the process that makes it hover [4]. Thereby, providing a proof of concept for a possibility of a compromise while in combat.
  • In early 2016, hackers at AnonSec claimed to have developed a method for gaining partial control over one of the Global Hawk drones used by NASA [5]. But, NASA has completely denied that its drones were hijacked [6].

The empirical hacks, proof-of-concept hacks and the blatant denial of hacks from trusted parties, has implanted a sense of suspicion in drones and other digital devices among the armed forces.

Prevalent Device Vulnerabilities: lack of adequate security measures or improper implementation of the security measures in devices accompany loopholes that can be compromised by malicious persons. Exploitations of these vulnerabilities/loopholes can result in leakage of sensitive, classified information from the devices, putting combatants at a strategic disadvantage on the battlefields as stated earlier. Some common hardware vulnerabilities and attacks that require a mention are:

  • Hardware Trojan [7]: is a malicious modification of the circuitry of an integrated circuit (IC). Hardware Trojans could be placed into the system by the manufacturer for debugging and maintenance tasks. However, an adversary would place a Hardware Trojan on the target hardware to cause subtle disturbances or catastrophic system failures; like accept inputs that should otherwise be rejected, such as co-ordinates over a no-fly zone, leak cryptographic keys used for secure communication, perform Denial of Service attacks, etcetera.


  • Hardware backdoors [8]: are similar to Hardware Trojans, but involves code that could reside in the firmware of a computer chip. Hardware backdoors can be deliberately placed by the manufacturer for testing, debugging and maintenance purposes or could be placed by an enemy after a device has been compromised to enable them to control the system remotely [9]. Hence, their effect is as catastrophic or maybe even more so, than that of a Hardware Trojan.


  • Unified Extensive Firmware Interface (UEFI) vulnerabilities [10]: UEFI is a specification that defines a software interface between the operating system and platform firmware. Existing vulnerabilities in UEFI can be exploited to install highly persistent malwares on to the device that would allow the enemy to control the entire system to their will [11], regardless of any security measures that might be in place.


  • Semiconductor doping: is the process of adding impurities to silicon-based semi-conductors to change or control their electrical properties. Chemicals such as phosphorous and arsenic are used to alter the properties and are widely and easily available. Doping performed by an adversary on the device aids malicious Trojans to pass build-in tests that are primarily designed for reporting manufacturing or operational defects in the devices [12].


  • Hardware devices, in general, are susceptible to hardware side-channel attacks such as timing attacks, power analysis and fault injection that could be used to steal sensitive in- formation, eavesdrop, etcetera [13].

It is interesting to note that the vulnerabilities and subtle modifications of chips in the devices are virtually impossible to detect in a timely manner on the battlefield. Also, these vulnerabilities being pervasive, completely undermines the trust the soldiers have in these systems.

Poor response to vulnerabilities: Delayed remediation of vulnerabilities in devices has been a consistent concern among the armed forces. The flaw in the 2009 drone attack by the Iraqi insurgents on US drones is said to be dated back to the 1990s according to a military technology analyst, Peter Singer [14] and another US official stated that the flaw was finally identified and fixed over a period of 12 months [2]. Though the military was aware of the flaw, it assumed that its adversaries would not be able to take advantage of it.

The inaptness in handling the vulnerabilities and “security by obscurity” attitude has persisted over the years and with increasing complexity of devices and the confusion over legal responsibility for security with no single party (either manufacturer, integrator or end user) assuming this role has undermined the confidence the soldiers have in the system as a whole.

Globally sourced technology: Nations that lack the ability to fulfill the capacity requirements needed to manufacture computer chips for classified systems are moving offshores. Nonetheless, nations are also concerned about the risks generated from using globally sourced technology for implementing and manufacturing digital devices. Counterfeit computer hardware components are viewed as a significant problem by private corporations and military planners [15].

A recent White House review also noted that there had been several “unambiguous, deliberate subversions” of computer hardware components. The specter of subversion causing weapons to fail in times of crisis, or secretly corrupting crucial data, has come to haunt American military planners. This problem has grown more severe as most American semiconductor manufacturing plants have moved offshore (to countries such as China) [16], [17] and resulting in countries like China to acquire a monopoly over manufacturing and implementation of chips and device.

Furthermore, the Chinese government has been noted to include hardware backdoors in some commercial components manufactured in China on the pretext of prevention and investigation of terrorists’ activities. Thereby, putting third-party nations at a risk of being snooped or digitally hacked by the Chinese [18], [19], [20], [21], [22]. The risk of being hacked is a concern that subverts trust in any globally sourced device.

Opaque decision making: Digital devices can make many thousands or millions of decisions each second that govern its operation and actions. Users and operators often have no visibility into the reasoning behind these decisions, so it becomes difficult to evaluate their accuracy and outcome. There have been numerous occasions where devices have malfunctioned while in practice.

One instance is the malfunctioning of an antiaircraft cannon (Oerlikon GDF-005). The anti-aircraft weapon used by the South African National Defense Force is computerized and designed to use passive and active radar to obtain its target data. The malfunctioning killed 9 persons and injured 14 others. It is believed that a software glitch in the machine caused its malfunctioning [23].

Another instance is the malfunctioning of G36 assault rifles used by the Germans in combat. The German troops reported that the rifles lost accuracy after sustained firing in hot environments [24]. Likewise, during an Indonesian Navy exercise on September 14, 2016, two Chinese made C-705 missiles failed to hit their targets after launching from two KCR-40 attack ships [25].

The uncertainty in determining if a device would make the “right” decision on the battlefield is a matter of concern in the military.

Dependence on insecure third-party communication channels: On April 8, 2010, state-owned China Telecom rerouted U.S. and other foreign Internet traffic, causing 15 percent of the all internet traffic to travel through Chinese servers for nearly 20 minutes [26]. Although the long-term impact of this rerouting remains unknown, there is a gaping possibility of military information leakage during this incidence.

While heeding to the above incidence, it can be stated that third-party network providers are inherently insecure and susceptible to attacks such as man-in-the-middle attacks, snooping, sniffing, etcetera [27]. Moreover, lack of knowledge or use of cryptographic primitives in communication channels only adds to military’s concerns.

Why the need for trust and adaption?

Digital assets may be a strong target during Phase Zero, or pre-conflict operations. In the Internet age, controlling information is as important as influencing opinions on an international platform such as the United Nations (UN). For instance, network attacks widely believed to have originated in China have targeted diplomats from the United States and partners, politicians, human-rights campaigners, military networks, and corporations to glean confidential information to influence in matters of interests to China. [28]

The Chinese government acknowledges the strategic culture of defeating an enemy prior to the onset of hostilities. Its intentions are to bend the will of an adversary nation without having to resort to force [29]. In accordance with its philosophy, the Chinese government has carried out not only sophisticated computer-network operations [30], but that it has also been taking measures to target embedded devices. In 2007, Jonathan Evans, the Director „General of the UK Security Service, MI5, stated that the Chinese “continue to devote considerable time and energy trying to steal our sensitive technology on civilian and military projects and trying to obtain political and economic intelligence at our expense.” [31]

Another instance of Phase Zero operations is the injection of Trojan horses by the United States in the 1980s. The American Intelligence added a Trojan to a gas pipeline control software to ensure that the machine – being shipped through Canada to Russia – would work erratically and could be disabled remotely. The machine was bought by the Soviet Union from Canadian suppliers to control a Trans-Siberian gas pipeline. However, the doctored software failed, leading to an explosion in 1982, an outcome that met the interests of the United States [32], [33]. Similarly, Crypto AG, a Swiss maker of cryptographic equipment (Enigma) is believed to have colluded with NSA to rig the equipment provided to certain countries. The Swiss reputation for secrecy and neutrality lured Iranians and other nations to buy the equipment. In the aftermath, NSA’s access to the hardware back door in the company’s encryption machine made it possible to read electronic messages transmitted by many governments [34], [35].

However, other nations focus on building capacity-of-partners and influencing potential adversaries to avoid wars. Such nations do not engage in tactical approaches as the Chinese do. As a result, these nations lack the strategic advantage that the Chinese government possesses. Therefore, in order to stand side-by-side on international platforms such as the UN without being tactically coerced by adversary nations, these nations need to adapt and trust their devices. They need to employ trust measures to safeguard their devices and eventually their will.

What does it mean to trust a digital asset?

The word “trust” in this context means relying on a device to effectively perform a functionality. In other words, devices should not function to aid the enemy. Examples of device abuse include:

  • Spying on behalf of the enemy to glean confidential information to undermine the efforts of the armed forces using the device.
  • Providing false or dated information to allies that could jeopardize a mission. An instance of this could be providing wrong location co-ordinates for the launch of a missile. The outcome of the launch could potentially kill innocent civilians.
  • Inadvertently revealing confidential information to the enemy. This can be attributed to employing insecure communication channels where-in the data is not encrypted or that the enemy possesses the encryption key to the encrypted data transmitted over the communication channel.
  • Acting as a launch-pad for enemy attacks or take false inputs from an adversary to mar the outcome of a critical functionality. An instance of this could be the use of the kill switch by the enemy at their will, thereby undermining the efforts of the armed forces in a mission.
  • Revealing its location or the location of other assets to the enemy in the event of stealth operations. This is made possible either by insecure communication methods or by com- promising the device by a Trojan.
  • Performing in a reduced capacity so as to disrupt the sup- ply-chains. Thereby, drastically impacting the performance of the military due to shortages of food, water, ammunition and other basic supplies.

How to ensure trust in digital devices?

Securing a device can be daunting, complexity of the chips and device functions only add to the difficulty of providing robust security controls. However, security can be ensured.

While presuming that the hackers/insurgents/enemy have the technical prowess to hack into digital devices remotely or exfiltrate information from the devices when in possession of it, some measures that could be employed for ensuring trust include (Figure 1):

                      Figure 1: Ensuring trust in digital devices

  • Establishing an effective threat intelligence and monitoring operation can inform operators of vulnerabilities before they impact a mission. Although not specific to device security, these operations are vital to ensure proper countermeasures are developed and deployed without undue delay.
  • Adopting secure device update mechanisms can rectify vulnerabilities in a timely and secure manner. Inherently, no system is resilient against all future threats at inception. Digital devices must be developed to provide provisions for secure updating of its software and firmware. This act will allow for countermeasures against new threats.
  • Ensuring a comprehensive device security assessment can alleviate the mistrust in digital devices. Hardware is the crux of any digital asset. If the hardware is compromised, all components -firmware, software- stand compromised. Establishing advanced labs for hardware and software evaluations that identify and address security vulnerabilities is a necessity and a step towards ensuring trust. Recruiting expertise in embedded security, white box cryptography, Security on chip (SOC), and IoT-enabled devices is critical as well. An assessment may include:

–  Evaluation of communication protocols for man-in-the-middle attacks, sniffing, etc.

– Source code analysis for buffer over-flow attacks, information leakage, etc.

– Cryptography analysis for leakage of secret keys, implementation errors etc.

– Hardware Analysis for side channel attacks, fault injection attacks, imaging and IC modification attacks, backdoors and Trojans, etc.

– Supply chain evaluation.

  • Adopting anti-tampering technology and compromise/threat detection mechanisms in the device. This involves countermeasures that enable the detection of a compromise or a break-in. Encryption Wrappers, Code obfuscation, software watermarking and fingerprinting, Trusted Execution Environments (aids in detection and reporting of unauthorized changes to the operating system or programs, detects rootkits), etc. [36] are few techniques that help achieve threat detection and prevention. In conjunction, access control mechanisms and identity management systems also help prevent the emergence of rogue devices and impersonation.
  • Developing fail-safe mechanisms. These mechanisms enable devices to fail (in a safe and predictable manner) in the event of an attack or on tamper detection. Once such mechanism is the implementation of hidden kill switches in devices. Switches enable to disable computer-controlled military equipment from a distance if the device fell into enemy hands.
  • Implementing cryptographic primitives can ensure secure communication (authentication, integrity and confidentiality of the information in transit) over third-party communication channels, and secure over-the-air patching and updates to the devices. It is increasingly important in today’s combat environment to use cryptographic primitives because enemies and potential adversaries are rapidly acquiring “jamming” and “hacking” technologies; giving them an ability to interfere with and compromise device operations. To achieve secure communication, device manufacturers can embed secure elements like Trusted Platform Module (TPM) into the device. Secure elements are specialized chips on an end- point device that stores encryption keys, performs cryptographic computations, and authenticates the devices.
  • Implementing trusted computing. This involves computing involves the development of a Trusted Computing Base (TCB) into the device. TCB is the set of all hardware, firmware, and/or software components that are critical to the devices’ security, in the sense that bugs or vulnerabilities occurring inside the TCB might jeopardize the security properties of the entire system. It contains four primary security mechanisms – a security policy, identification and authentication, labeling, and auditing. TCBs are usually accompanied by Trusted Execution Environments (TEE), a secure area of the main process that evaluates the code and data loaded onto the chip for confidentiality and integrity. TEE also provides hardware root of trust functionality. Root of trust supports features such as:
    • Secure boot and secure access control.
    • Secure identification and authentication.
    • Firmware integrity assurance.
    • Secure storage for the rest of the chip.
    • Secure debug and test access control.
    • Runtime protection.
o Secure field updates.


War zones are being digitized. In addition to the undisputable benefits that these digital devices provide, the low cost of much of these technologies (sensors, drones, etc.) is facilitating their permeation in to the military and industry at a rapid pace. While the security of much of these devices seem obscure, nation states across the world are researching [37] vehemently the utility, risks and challenges of deploying digital assets in war zones. Nevertheless, additional responsibilities need to be adopted to ensure trust.

All parties – from device manufacturers to end users need to make an effort to enforce trust measures in digital devices. Security needs to be enforced throughout the lifecycle of the device – from procurement to design, development to deployment, and maintenance to retirement. Supply chain must enforce accountability and responsibility. Policies and laws need to be enacted by nation states to support the same.

Finally, discretion in ensuring that the established-trust remains consistent across all domains of device operation via practical demonstrations and comprehensive evaluations of risks vs benefits can greatly alleviate the concerns of soldiers and help them adapt to new digital devices. 



[2]  https://www. theguardian. com/world/2009/dec/17/sky-grabber-american-drones-hacked

[3]  https://www. wired. com/2011/10/virus-hits-drone-fleet/







[10] veral-uefi-vulnerabilities;

[11] fi-flaws-can-be-exploited-to-install-highly-persistent-ran-somware.html












[19] http://gizmodo. com/5897493/all-chinese-made-electro-














[25] dent-watches-failed-firings-of-chinese-made-c-705-missi-








[29] Phase Zero: How China Exploits It, Why the United States

Does Not Scott D. McDonald, Brock Jones, and Jason M. Frazee ( abe7-4410-adaf-d78d085d933e/Phase-Zero–How-China- Exploits-It,-Why-the-United-)

[30] ber-attacks-on-u-s-to-chinas-military

[31] na/8597485/China-and-Britain-locked-in-cyber-war.html

[32] ligence/csi-publications/csi-studies/studies/96unclass/fa- rewell.htm

[33] html?_r=1&ref=science&pagewanted=all


[35] the-nsa-attempting-to-insert-backdoors-into-encrypted- data

[36] A Survey of Anti-Tamper Technologies by Dr. Mikhail J. Atallah, Eric D. Bryant, and Dr. Martin R. Stytz (https://pdfs. daf5751d17.pdf)

[37] https://www. cso. nato. int/ACTIVITY_META. asp?ACT=8647

Senate bill to secure Internet of Things (IoT)

Senate bill to secure Internet of Things (IoT)

The Internet of Things, and now the U.S federal government along with it, have a problem. Devices are smart enough to impact the world around them, but aren’t built smart enough to protect themselves.  In the recent past, these devices have been maliciously commandeered to bring down large swathes of the Internet, steal sensitive information, send spam emails, spy on individuals, and bring a whole city to its knees.

The first step in solving a problem is admitting you have one, and the Senate took this step with the introduction of the “Internet of Things Cybersecurity Improvement Act of 2017”.

The new legislation introduced by Sen. Mark Warner and Sen. Cory Gardner, sets minimum standards for the manufacturing, deployment and maintenance of IoT devices purchased by the U.S federal government. It received inputs from technology experts at the Atlantic Council and Harvard University to address cyber attacks that leverage IoT devices. The bill is aimed at responding to the “obvious market failures,” said Warner in an interview with Reuters and also to prevent further intrusions into federal systems “without halting the life-changing innovations that continue to develop in the IoT space,” said Gardner.

The key provisions of the bill are:

  • The manufacturer or the contractor of the device to the federal government must provide a written certification bearing, but not limited to the following:
    • No known vulnerabilities are to be present at the time of delivery of the device. If present, mitigation strategies are to be disclosed to the agency in detail.
    • Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as digital signatures.
    • The devices are to use only non-deprecated industry-standard protocols and technologies.
    • The devices will not have fixed or hard-coded credentials such as usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update.
  • The U.S federal government and associated agencies are to outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties.
  • Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry.

Assuming this bill passes, what does this mean for enterprises purchasing IoT devices? In theory, the purchasing power of the federal government should lead large IoT manufacturers to start following these minimum security standards, which would benefit all companies by default. However, an enterprise should not assume this to be the case. Companies should use the key provisions in the Senate bill as guidelines to discuss with their device manufacturers before a purchase. Ask your suppliers if they meet these provisions, and if not, where they have gaps and what their plan is to fill them.

For device manufacturers, this bill will affect your approach to security. Let’s look at each requirement and its possible ramifications:

  1. No known vulnerabilities are to be present at the time of delivery of the device to the federal government:

There are several nuances in this point that should be explored. First, a vulnerability must be known to be covered by this provision.  It’s not perfectly clear if it is specifying if the word ‘known’ means ‘publicly known’ or just ‘known by the company’, but I would guess the latter. Assuming it’s known, the company has two options: fix it or report it at procurement time along with mitigation strategies. Taking this into account, what is the incentive for manufacturers to perform detailed security testing? This is where the provision on cybersecurity research comes in. Since cybersecurity research is encouraged, it is likely someone will find vulnerabilities in your products. It is generally in the company’s best interest to find vulnerabilities internally and patch them rather than have a vulnerability exposed publicly.

Finding vulnerabilities in IoT devices includes software vulnerabilities, but there are also key hardware tests that should be performed. IoT hardware testing involves attacks such as side channel attacks, fault injection, imaging and IC modification. The testing process also involves source code audit, deobfuscation testing, fuzzing, cryptography implementation audit, software vulnerability verification, assessment of long-range wireless IoT protocols and of short-range communication protocols. The assessment process can be daunting to device manufacturers, but some IoT security solutions companies have the skills and experience to perform advanced hardware penetration testing (device, application, network) while leveraging proprietary security schemes and security intelligence.

Remember that device manufacturers do have the option to mitigate vulnerabilities without fixing the root cause. The vulnerability and mitigation strategy need to be disclosed at the time of delivery. In general, the manufacturer should continue to work on mitigating the vulnerability completely and integrate it into their future upgrades to the device, if applicable.

  1. Any updates to the device (inclusive of hardware, software and firmware) are to be properly authenticated by means such as: digital signatures: This provision is relatively straightforward: updates should be authorized and authenticated before they are applied to the device. There is no language that indicates this is a reference to over–the-air updates only, so even locally initiated updates need to be secure. Generally, authentication uses digital signatures, which can be challenging to implement correctly at scale. Device manufactures that lack expertise to implement or assess the implementation of PKI could rely on security solution companies to provide key management solutions that involve online and secure generation of device keys. Alternatively, device manufacturers can use third-party solutions to manage their updates that provide authentication.
  2. The devices are to use only non-deprecated industry-standard protocols and technologies: The federal government expects the device manufactures to adhere to industry security best practices for the manufacturing of the devices and hence, on those grounds, the device manufactures would need to stay abreast with the current trends and practices in the field of cybersecurity. Although it is best practice to use the latest version of protocols and technology if possible, this provision only prohibits deprecated technology (such as the MD5 algorithm). Device manufacturers could rely on technology consulting or security advisory companies for guidance in implementing these solutions.
  3. The devices will not have fixed or hard-coded credentials such as – usernames, passwords, tokens, cryptographic keys and other authentication primitives and that these credentials will not be modified or revoked by the user or manufacturer, except via an authenticated firmware update: Hard coded and global credentials have been the root of many IoT security incidents in the last two years. This provision ensures that keys and credentials can be changed or rotated, and hopefully are not set globally on all devices (although this isn’t technically in the provision). It also mandates that any changes to credentials be done in a secure fashion. Rotating device secrets securely at scale is a challenging undertaking, and should be approached with care. There are IoT platform vendors that provide this service today, and unless a manufacturer already has an infrastructure to support this, they should consider using third-party support.
  4. To outline policies and procedures for conducting cybersecurity research on Internet-connected devices and safeguards for such well-meaning and good-intended researches from criminal liabilities or penalties: Cybersecurity research usually involves breaking into things (this involves open source and proprietary devices, protocols, softwares, hardwares, etc.) and anything that requires breaking without prior notice or permission may be considered a crime. While the procedures to obtain permission can be rigid and expensive, it leaves little room for cybersecurity researchers to perform experiments and studies and to provide the best security measure to safeguard devices. This in turn, results in limited knowledge among device manufacturers about the best way to secure the devices. By being more open to cybersecurity research on IoT, the device manufactures could invest into cybersecurity research and the IoT community as a whole stands to benefit from the outcomes of the research as has been in the field of digital media (robust watermarking and anti-piracy technologies have morphed and evolved through over decades of research and experiments)
  5. Finally, that if an existing third-party security standard for Internet-connected devices provides an equivalent or greater level of security, an executive agency may allow a contractor to demonstrate compliance with that standard in lieu of the requirements followed by a written certification that the device complies with the security requirements of the industry: This provision allows the device manufacturers to employ third-party institutes to evaluate and certify their devices from a security perspective. One example of a device certification is the CSPN from ANSSI (L’Agence Nationale de la Sécurité des Systèmes d’Information).

Though the proposals and guidelines will later be detailed by NIST and other related federal agencies (provided the bill is passed), it is a safe bet to say that IoT security is imminent. Through rapid and educated investments in advanced labs and strong R&D base, device manufacturers can be uniquely placed to meet current and future security requirements of this fast-growing industry. Alternatively, device manufacturers also have several options to partner with IoT security solution companies that provide in-depth security assessments and evaluations of IoT products allowing the device manufacturers to identify and address security vulnerabilities before products go to market, and helping ensure their company doesn’t become the next big cyberattack headline.