/*
The Age of IoT Is Here – Is Your Enterprise Secure?

The Age of IoT Is Here – Is Your Enterprise Secure?

Whether you were ready for it or not, your network is likely supporting hundreds if not thousands of connected endpoints at this very moment. When we talk about IoT, especially in the enterprise, we’re not just talking about connected refrigerators anymore. IoT is powering manufacturing lines, medical devices, and entire cities.

The possibilities for IoT have never been greater, and neither have the stakes. Just look at what happened in 2016 when Mirai, the infamous IoT botnet, took down major websites like Netflix, Twitter, and Amazon via a massive distributed denial-of-service attack using hundreds of thousands of compromised IoT devices.

Nonetheless, 2018 will be the tipping point for IoT in the enterprise with nearly half expected to deploy IoT solutions by the end of the year. What has made the explosion of IoT adoption possible is also its Achilles heel? The diversity and volume of device manufacturers, platforms, and use cases have made it nearly impossible to standardize any type of security controls. Many device manufacturers don’t even prioritize security, often because their customers don’t. The onus, therefore, is and will likely continue to be on the consumer – whether that’s an individual or an enterprise.

A lack of standard security controls isn’t the only thing standing in the way of securing IoT environments. IoT environments look different than traditional enterprise networks. They’re inherently more complicated and fragmented, requiring a different approach to security architecture. This also makes it much more difficult to have visibility and control over every connected device. Industry standards and regulations are just as fragmented and obscure. Many organizations have published their own set of best practices, but there is not a universally agreed upon standard as of yet.

To that end, Kudelski Security has spent the last year researching the current state of IoT in the enterprise and the best practices for securing it. The findings are presented in our IoT Security Reference Architecture, which is designed to help enterprise security teams build a strategy for secure IoT deployments using a combination of people, process, and technology.

Inside the architecture, the team provides an overview of the differences between IoT and traditional network environments; the IoT security threats, challenges, and business impacts enterprises face; IoT security best practices at the people, process, and policy level; and the security controls and technical measures IoT enterprises should have in place.

The reference architecture takes into account numerous security guidelines and standards, with the two primary sources of inspiration being ENISA’s Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures and the Industrial Internet Consortium’s Industrial Internet of Things Volume G4: Security Framework. (A full list of IoT guidelines is available in the report.)

This guide is best-suited to organizations who already have IoT devices deployed in their environment. We recommend comparing the best practices presented in the architecture with existing security controls to identify security gaps or complementary technology solutions to improve IoT security efforts.

To download the IoT Security Reference Architecture, click here.

 

Operational Technology: The Next Cyber Battlefront

Operational Technology: The Next Cyber Battlefront

Critical infrastructure sectors are vital to the functioning of modern societies and are vulnerable to damage from natural disasters, and physical incidents. However, ever since its consolidation with IT networks, Operational Technology (OT) threat landscape has increasingly evolved to accommodate cyber-attacks similar to that of IT networks as well; the same categories of malware that attack IT computers have become relevant to OT computers and systems and the isolation of OT networks can no longer seem to be considered an effective protective measure to OT networks.

Furthermore, international fragmentation regarding cybersecurity policies and procedures and misalignment of incentives for cybersecurity best practices act as formidable hindrances, placing OT practitioners in a difficult position of balancing the market pressures of rapid innovation and sustained investments.

Building upon our success in digital security, our study into the OT threat landscape has helped us summarize that misconfiguration, vulnerable hardware and software components, poor cybersecurity practices by subcontractors, outdated network components, and lack of cybersecurity awareness have been the predominant features easing the OT threat actors’ efforts over the years. Furthermore, IT-based security mechanisms in OT environments have been far less than optimal – firewalls causing excessive latency, undependable threat quarantining techniques, labor-intensive patch/update mechanisms, and unsuitable restore mechanisms. Hence, while we cannot assume that the current IT controls can transition to OT networks, defense-in-depth mechanisms can act as guiding points for securing OT environments – effective policies and procedures revolving around risk management, training and awareness, audits and assessments act as enablers to apply security controls from a standpoint of acceptable risk and prioritize safety and reliability. Physical security, network and host monitoring, and application management complement the efforts of OT security personnel.

Therefore, Kudelski Security believes in weaving together science, technology, and policy to develop sophisticated, yet practical, solutions that will help secure information, computer and network assets in various critical infrastructure sectors. Our Embedded Security Suite provides a three-pronged approach that ensures security is integrated throughout the OT product and system lifecycle and helps guarantee long-term confidentiality, integrity, availability, and safety.

Did this blog interest you or your organization? To better understand your OT risk posture and protection mechanisms that can be applied, click here to read our Operational Technology white paper.

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 www.kudelskisecurity.com.

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.

Conclusion

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.

References

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.

References