THE HOUSE OF SEKHON - YOUR PARTNER IN CAPITAL ASSETS CREATION. USING FREE MARKETS TO CREATE A RICHER, FREER, HAPPIER WORLD !!!!!

RIL Forays Into 350 Bn Cybersecurity Future Powered by Hardware

  • The cybersecurity market was valued at USD 156.24 billion in 2020, and it is expected to reach USD 352.25 billion by 2026, registering a CAGR of 14.5% during 2021–2026.
  • The Market is Segmented by Product Type (Solutions and Services), Deployment (On-cloud and On-premise), End-user Industry (Aerospace, Defense and Intelligence, Banking, Financial Services and Insurance (BFSI), Healthcare, Manufacturing, Retail, Public Utility, IT, and Telecommunication), and Geography.
  • Adoption of M2M/IoT connections demands strengthened for cybersecurity in enterprises. This is driving the market, as the emerging business models and applications are coupled with the reducing device costs, which have been instrumental in driving the adoption of IoT, and consequently, the number of connected devices, such as connected cars, machines, meters, wearables, and consumer electronics. On the other hand, several other smart city projects and initiatives are ongoing, and by 2025, it is expected that there may be around 30 global smart cities and 50% of these may be located in North America and Europe, which may demand high cybersecurity for prevention.
  • High reliance on traditional authentication methods and low preparedness are challenging the market to grow. In a market scenario, where security professionals are recommending identity-management solutions, such as facial recognition and biometric identification, most of the companies in the region (over 80%) still use usernames and passwords as the exclusive means of logging in.
  • Due to the ongoing COVID-19 outbreak, the countries across the world have implemented precautionary measures. While schools are being closed and communities are asked to stay at home, and many organizations are finding a way to enable their employees to work from their homes. This has resulted in a rise in the adoption of video communication platforms. In the past four months, the new domain registration on these video communication platforms, including Zoom, has rapidly increased. According to the Checkpoint Security, since January 2020, more than 1700 new domains have been registered, 25% of which have been registered in the first week of March 2020.
  • The US Department of Homeland Security (DHS) Cybersecurity and the Infrastructure Security Agency (CISA) and the United Kingdom’s National Cyber Security Centre (NCSC) mentioned that they are experiencing a huge rise in phishing and Malware distribution using COVID-19- themed lures, registration of new domain names containing wording related to coronavirus or COVID-19, and attacks against newly and rapidly deployed remote access and teleworking infrastructure.

Challenge

  • The current challenges related to cybersecurity stem from the fact that for the most part, until now, in both products and software, security has been an afterthought. Capabilities like the Internet, new forms of applications, and all sorts of distributed computing devices have arrived, become useful, and then have been discovered to be insecure.
  • In one way, this was inevitable. It would have been impossible to do a great job building a secure Internet before we knew what the Internet was, how it would be used, and how many things would be connected.
  • But now that we know, we have to recognize that we can do a better job. There is one huge problem, however, that faces those attempting to design a secure Internet: the amount of computing power required.
  • The question we want to examine is can this huge demand for computing power with security built-in be delivered in software? Or will purpose-built hardware be required?

Why cybersecurity has a huge appetite for computing

Cybersecurity requires looking inside packets of information, not just controlling their flow across the network. So far we have only focussed on firewalls and perimeter security, keeping the bad guys out, rather than what happens if and when they get in.

When he started looking more deeply into how he would execute this new vision for cybersecurity, we came to two key realizations:

  1. Much more computing power would be necessary to secure against emergent threats — For security today, on average, companies need about 50 to 100 times more computing power to handle the same support compared to the networking. Today, you have to open up the content and look at whether there’s malware, there’s an intrusion, there’s phishing in an email or there’s bad web content and check off so many different policies. And that’s making security very costly and very slow.
  2. Security must be embedded in the end-to-end computing and networking infrastructure. There must be a much larger footprint for security because there are so many new devices and ways to access the Internet that it is much harder for companies and security personnel to maintain perimeter defenses. With the perimeter in many respects gone, they’d have to figure out a way to secure all of their infrastructure. That’s the main reason we need a hardware based solution because, whether email or the Web, it’s no longer just plain text. It’s executable content that can do a lot of damage. You need a way to stop that.
  • Because examining all this content at all points in the computing and networking fabric requires so much computing power, we believe that the only way to handle the challenge is through optimized hardware.

The case for hardware acceleration

  • Hardware acceleration will be essential is not in any way intended to downgrade the importance of software. In our view, cybersecurity vendors must use the flexibility of software to get the architecture and algorithms right. The tasks of protecting the network with a next-generation firewall, searching email for viruses and other threats, keeping endpoints secure, and many other tasks require different approaches. While some of these problems may solved in software, they must be accelerated through specialized chips that offer built-in security protections.
  • Our approach is to create dedicated hardware at the ASIC chip level so that performance can be improved by 10 to 100 times. A Google study recently showed how computing power was improved by this amount with hardware. Since that time, we have been focused on creating chips that perform this larger work in hardware.

Performance will force the transition to hardware-based security

  • We feel that the growing costs of software-based security will force companies to adopt hardware solutions.
  • When we started RIL cybersecurity years ago, security spending only counted for about 2–3% of the IT spend in the US. Now it’s over 10%. As the security footprint grows, performance will matter even more because every interaction will incur a large amount of security processing. A software-only approach can’t handle the computing load. It cannot handle the content and traffic.
  • We think that eventually, the cost of security could account for 20–40% of the total IT spend and there will be a new type of Internet based on application networking. The massive costs of infrastructure and the need for performance will mean that computing will have to take place at the fastest pace and the lowest cost. To us the only solution for this is hardware and an Internet 2.0 that is more secure on its own.

An Integrated Cybersecurity Portfolio: Horizontal then vertical integration

  • The strategy driving the integrated cybersecurity portfolio is creating is based on horizontal and then vertical integration. It is becoming increasingly important for CISOs to have a strategy for using the smallest number of vendors to solve their problems. We believe that the cybersecurity market has now reached the peak of growth of point solutions and CISOs will start pruning and consolidating their portfolios over the next few years.
  • In our view, cybersecurity vendors must take responsibility for integration and consolidation. Vendors first need to perform a horizontal integration of all of the point solutions needed to secure email, desktops, laptops, mobile devices, and their networks. Then, because performance will become a problem, vendors will need to run everything on a vertically integrated stack with a chip that can support this. The only way to do this in is using optimized hardware.
  • We believe that this integrated picture is the basis for evolution, an Internet 2.0 that will have both network and application based security built into it through the entire processing chain. The horizontal integration will make everything work smoothly and automatically. The vertical integration will ensure performance.
  • Horizontal and vertical integration will in effect create a new Internet 2.0 that will have tremendous customer benefits. When you’re building all these new systems and applications, security is always a challenge. Embedding security in the fabric of the Internet will make application and system development much easier, and will also dramatically improve the end-user experience.

Cost and the IoT will force the integration

  • This integration will also be driven by the needs of the IoT domain, as connected devices and vehicles will demand it. Currently, many industries, such as the auto industry, are only using the IoT for simple things, like audio-visual connectivity. But eventually they’ll be linking the IoT to more important things and every system in a car or vehicle will need to be able to communicate. As a result, they’ll need security that’s stronger and integrated.
  • The marginal cost of hardware to secure a car’s IoT can be added into the cost of the car. That enables the car to have the same level of security that handles your credit card, PCI or the HIPAA healthcare standard. A car has a lot of personal data that needs to be handled in a secure way. When you connect the whole car to the Internet, there’s a lot of issues there. Without a dedicated chip, it’s more difficult.

How will this work in the cloud?

We also see the cloud as needing hardware to become secure. Right now, the cloud cybersecurity market is still small. But, eventually, companies will demand this type of security is built-into the cloud. We see this happening in two ways:

  • Cloud providers build security into the infrastructure. Some are already doing so.
  • You’ll also have the emergence of cloud APIs and services that are powered by hardware-based security available from cloud providers directly.

The spend on cloud security today is still low compared with overall network security. You see a lot of companies talk about it, but so far the estimates are only probably like 1 to 2% of total revenue. This will change.

  • We are headed for a massive security slowdown because few cybersecurity vendors are focused on hardware acceleration. We are betting that the ones who do will have an advantage as the need for an Internet 2.0 that has both horizontal and vertical cybersecurity integration becomes clear.
  • Hardware security primitives play an important role in ensuring trust, integrity, and authenticity of integrated circuits (ICs) and electronic systems. Primitives, such as physical unclonable functions (PUFs) and true random number generators (TRNGs) produce device-intrinsic electronic fingerprints and random digital signatures, respectively, to generate cryptographic keys and IDs commonly used for device authentication, cloning prevention, generating session keys, nonce, and many more. Further, designs, such as combating die and IC recycling (CDIR) sensors offer countermeasures against IC counterfeiting (recycling), which is of a significant concern in the modern electronic supply chain. In this chapter, common hardware security primitives and designs for countermeasures against various threats, and vulnerabilities are discussed. First, the device-intrinsic properties are briefly discussed as these features play key roles in designing various security primitives. Following, hardware security primitives-namely PUF and TRNG-and designs for anticounterfeit (DfAC) are explained in detail with multiple examples and relevant applications. The chapter ends with a brief look at post-CMOS security primitives designs equipped with emerging nanoscale electronic devices.

Attack Vectors

  • Attack vectors-as they relate to hardware security-are means or paths for bad actors (attackers) to get access to hardware components for malicious purposes, for example, to compromise it or extract secret assets stored in hardware. Example of hardware attack vectors are side-channel attacks, Trojan attacks, IP piracy, and PCB tampering. Attack vectors enable an attacker to exploit implementation level issues (such as, side-channel attacks and PCB tampering) or take advantage of lack of control on hardware production cycle (such as, Trojan attacks).

Introduction

  • In modern computing systems, the hardware and software stack coordinate with each other to implement the system functionality. Whereas the previous chapters have focused on security issues of the hardware itself, they have not covered another important aspect of hardware security that concerns with providing an infrastructure for secure software execution. In particular, the role of hardware in protecting the assets stored in a chip or PCB from malicious software have not been described in detail. Similarly, protection of the data/code of one application from another potentially malicious one, have not been addressed. The hardware needs to support security against software attacks, considering all levels of the software stack, from the operating system to application software. These attacks can be mounted through either functional or side-channel vulnerabilities. In this chapter, we will discuss various scenarios of software-induced attacks on hardware and possible countermeasures.
  • The software stack in a system runs on a central processing unit (CPU), which is most commonly implemented, nowadays, as an System on Chip (SoC) that integrates a processor IP. These systems increasingly integrate, along with a CPU, FPGAs and GPUs, which act as an accelerator for specific applications. This phenomenon has introduced increasingly complex hardware-hardware and hardware-software interactions, ultimately raising the question, “How do we secure our systems?” In this chapter, we first look into the security issues present in an SoC. Next, we focus on some requirements for designing a secure SoC. But before we move into system-level security issues, we need to understand the architecture of modern SoCs, and how hardware-software interaction takes place inside an SoC. We also need to understand the current practices for SoC security. The remainder of the chapter provides relevant background for SoC security, discusses various vulnerabilities and attack scenarios that can be mounted through hardware-software interactions, and presents various solutions.

Insufficient Skills

  • There are currently not enough skills available to build and run IoT products, systems, and services at maximum efficiency-or even get good ideas to market at all. Multiple attempts have gone through the US government 17to try to fund or mandate the type of advanced networking skills needed to support not only the IoT today but the Internet generally. These attempts have generally died on the vine, unable to get to the top of priorities that lawmakers decide even to vote on, let alone enact.

This skill deficit results in failure to use the resulting big data effectively for competitive advantage and value-added services. Failure to acquire and foster the skills necessary for the IoT hinders the ability:

  • to differentiate products and service based on security
  • to demonstrate security through good reporting and audit results and by applying standards
  • to manage supply change effectively through contract management and security assessment for partners within the ecosystem, minimizing assumptions to demonstrate due care for the client.

Approaching this skills deficit is a long-term problem and represents systemic risk to all IoT business. One way to manage this risk is through a simple framework to assess the problem. Next fig is such a framework, which might be used to express what types of security skills an IoT service provider will require, or if they do not require such skills, to understand specifically why they feel that they are not required.

Starting from the bottom:

  • Hardware security will be a major element of IoT systems and indispensable in some use cases, where software-based security is too expensive. Skills related to accessing the security features available in both x86 (Intel) and Advanced RISC Machine (ARM) based architectures are the rarest of the security skills. This is clearly a shortcoming in the education system, where practically no attention is given to this foundation element in IoT security. Perhaps this is the case because hardware security was considered the hard way to do things in the age of laptops, servers, and smartphones with plenty of power and processing resources.
  • Infrastructure security is really about networking and virtualization skills, and the two together in the form of NFV (previously discussed and more to come on this topic). In the age of enterprise IT and conventional Internet security, much of the network is dumb and just passes packets around. Much of the network is also composed of simple elements that do one thing well, but never anything more. In the IoT, networks will become smart and flexible and security will become pervasive from end to end. Virtualizations (NFV) will make this possible in gateways, transport networks, clouds, and DCs. The tools and products that make this possible are emerging now-this is new technology. A significant risk is that colleges and universities take years to integrate these technologies into curricula, and engineering professions take ages to integrate them into common practice and bodies of knowledge. This is what happened with the Internet, where even today in 2016 it is difficult to find an engineering school with more than a handful of courses on the most important communications technology in the world-the Internet!-let alone a degree program.
  • Platforms refers to the clouds that increasingly serve as the only basis for IoT services-the born in the cloud companies that more and more underpin IoT services. Cloud technology is definitely related to the virtualization being used in the infrastructure of networking in the IoT, but is tuned for data management, processing, and storage the way a network element is not. It includes a massive focus on heterogeneous operating systems capable of running just about any application. Automation and expansion is a hallmark of cloud technology and the security applied inside clouds has even evolved its own security standards. 18Furthermore, modern cloud infrastructures for enterprise and IoT service providers alike will not be based on one cloud platform, but many. They will be a patchwork of services from different public cloud providers combined with some private cloud infrastructure. The cloud workloads will need to be coordinated and secured using skills that did not exist even a few years ago. As a result, IoT risk managers should expect that colleges and universities will not be graduating adequately trained workers for a while. This means that other sources will be resources (poaching from across the industry) or taught to new hires from scratch.
  • Software security refers to the skill of developing and managing software and applications in a secure manner. Bugs that lead to security vulnerabilities are fewer and less catastrophic if developers have tools and training to support security application development. Similarly, systems administrators will be different from platform and infrastructure administration skills, and will have a different view on security requirements and responsibilities. Software security is in slightly better shape than platform, network, infrastructure, and hardware security in the sense that it has been around longer as a defined domain. There are tools and methodologies to support secure code development and industries around this practice have grown up (though they are not large). This means that risk managers in the IoT should have no reason other than ignorance or risk acceptance for implementing application code with serious security flaws. Good security practice in systems administration is another area that is fairly well understood from conventional Internet and enterprise practices and should translate well to the IoT. The main risk around software security is that previous good work is not applied by IoT service providers in the rush to get to market.
  • Risk management is the last skill domain that IoT executives should be aware of as a distinct skill that should be accessible during the development and operational phases of any IoT system. Risk management skills can be composed of soft skills and hard skills. The soft skills side of risk management especially cannot necessarily be taught, because they involve a lot of judgment and take into account cross-disciplinary considerations-like this book-such as risks associated with regulations as well as financial, competitive, and internal policy issues. Risk management is typically not taught in technical engineering or computer science courses, though it is found in business schools and as a theme in degrees such as Masters in Business Administration (MBA). But not always. Perhaps the risk management skill resides directly in management? There are established methodologies for managing risk and established libraries of security and privacy controls that serve as a guide for what might be expected from a well-managed system. For instance, there are a variety of excellent, formal processes for conduction Threat-Risk Assessments (TRAs). This review itself is a superset of requirements and controls for IoT security.
  • Why do we graduate doctors with specializations in ailments that afflict less than 1% of humanity, but not engineers with specializations in the technology that touches 100% of the population and is the platform for personal prosperity and their way of life?
  • On the hard side of risk management professionalism is the security evaluation and testing practitioners; Those who will look at the very granular technical elements of an IoT device: code reviewers, component testing, performance analysis, and testing. Like softer risk management, security evaluation is done according to well-defined methodologies can can often result in certifications against specific assurance criteria. The Common Criteria 19scheme is a good example of a form of professional risk management provided by security assessment and evaluation. Common Criteria as an IT assurance scheme is recognized by over a dozen Organization for Economic Cooperation and Development (OECD) and other countries, including the United States, United Kingdom, Canada, Australia, and New Zealand (aka “the five eyes”).
  • As before, it is okay to accept risks as long as you know what you are accepting. In this case, the risk is adequately understanding what types of skills are required to create a secure IoT service or application and comparing that to the skills that are actually available in-house or within the service provider ecosystems (transferring the skills-risks to providers).

Chips for wireless connectivity standards

  • Several manufacturers supply chips and modules designed for specific connectivity standards. These standards are Bluetooth, Wi-Fi, and various derivatives of IEEE 802.15.4 including Zigbee and other industry variants. Also available are chips and modules that are the basis of dual systems, usually Bluetooth and Wi-Fi. Bluetooth and Wi-Fi products are aimed for installation in smartphones, while devices in all three categories are promoted for connectivity of Internet of things (IoT) networks. Some examples are given below.

Texas Instruments

  • The TI CC2564 is a complete Bluetooth BR (basic rate), EDR (extended data rate) and low energy chip with self contained physical layer functions. Multiple profiles contained in firmware in a coupled microcontroller are supported for a complete Bluetooth product solution. Chip hardware is designed to meet the RF specifications of Bluetooth version 4.2. TI also offers a CC2564MOD module that includes the microcontroller. Two variants are available, with integrated chip antenna and with interface for external antenna. Module footprint is 7 mm × 7 mm × 1.4 mm (typical).
  • A SOC product for 2.4 GHz IEEE 802.15.4 is the TI CC2538. It combines a powerful microcontroller with an IEEE 802.15.4 radio and can handle complex network stacks with security and over-the-air download. The chip supports Zigbee application profiles, and has hardware security accelerators to enable efficient authentication and encryption. It comes in an 8 × 8 mm SMD package.

Microchip

  • Microchip offers a wide range of Bluetooth chips and modules with varied capabilities to suit a range of applications including sensor devices, smart appliances health and fitness trackers, retail beacons and asset tracking. One example is IS1870 SOC for Bluetooth low energy (BLE) applications. The chip is designed to work with an external host microcontroller. However, the flexibility of the chip also enables the user to create a hostless implementation where a full application can be embed into the IS1870. Package size is 4 × 4 × 1 mm. Fig. 8.4 is a block diagram of the IS1870.
  • Microchip also offers compact modules for Zigbee on the 800/900 MHz bands as well as 2.4 MHz. Its ATZBX02564 module has Zigbee RF below 1 GHz and baseband functions, and an on board chip antenna. It is compatible with an IEEE 802.15.4/Zigbee stack that supports a self-healing, self-organizing mesh network while minimizing power consumption. Among applications stated for the product are building automation and monitoring, inventory management, environmental monitoring, water metering, industrial monitoring, including machinery condition and performance monitoring. and automated meter reading (AMR). Its under 1 GHZ frequency range gives it long range-over 6 km outdoor line-of-sight is claimed by the manufacturer. The board measures 18.8 × 13.5 × 0.2 mm.

Murata

  • Murata Bluetooth modules incorporate chips from other vendors. For example, Type MBN52832 module, shown in Fig. 8.5 is based on Nordic chipset nRF52832. This BLE module has an on-board antenna with provision for an external antenna. It is controlled by an ARM Cortex-M$ microprocessor and its size is 7.4 × 7.0 × 0.9 mm. This module supports Bluetooth version 5.0 Low Energy.
  • The company’s Type 1EU module is designed for industrial automation wireless standard ISA100.11a at 2.4 GHz which is based on IEEE 802.15.4. The module, shown in Fig. 8.6, includes a radio transceiver, microcontroller and networking software.

Taking Full Responsibility for Security

  • The security management and day-to-day operation of the environment are relegated to internal IT or to a third party with contractual SLAs. The risks faced by internal IT departments still remain. Private cloud security should be considered from different perspectives:
  • Infrastructure security: This perspective includes physical access and data leakage concerns (loss of hard drives), energy supply security, facility security, network security, hardware security (hardware cryptography modules, trusted protection modules), compute security (process, memory isolation), storage security, operation system security, virtualization security, and update security (hypervisor, virtual machines).
  • Platform security: This perspective includes user experience security, application framework security, data security, development environment security, and update security.
  • Software security: This perspective includes application security (multitenant partitioning, user permissions), and update security.
  • Service delivery security: This perspective includes connection security (SSL, authentication), and service end-point security (traditional network security).
  • User security: This perspective includes making sure that the users and the systems they are using to access the private cloud are trusted and secured.
  • Legal concerns: This perspective includes governance issues, compliance issues (PCI DSS, HIPPA), data protection (personally identifiable information), and legal agreements (SLA, terms of use, user license agreements).

The advantages of a private cloud in the context of security become apparent mostly when compared to a public cloud implementation.

Managing the Risks of Public Clouds

  • Though a public cloud deployment is suitable for most uses that are nonsensitive, migrating sensitive, mission critical, or proprietary data into any cloud environment that is not certified and designed for handling such data introduces high risk. A customer should first select a cloud deployment model and then make sure that sufficient security controls are in place. These actions should be followed by a reasonable risk assessment:
  • Data and encryption: If the data is stored unencrypted in the cloud, data privacy is at risk. There is the risk for unauthorized access either by a malicious employee on the cloud service provider side or an intruder gaining access to the infrastructure from the outside.
  • Data retention: When the data is migrated or removed by the cloud provider or customer, there may be data residues that might expose sensitive data to unauthorized parties.
  • Compliance requirements: Various countries have varying regulations for data privacy. Because some public cloud providers don’t provide information about the location of the data, it is crucial to consider the legal and regulatory requirements about where data can be stored.
  • Multitenancy risks: The shared nature of public cloud environments increases security risks, such as unauthorized viewing of data by other customers using the same hardware platform. A shared environment also presents resource competition problems whenever one of the customers uses most of the resources either due to need or due to being exposed to targeted attacks, such as DDoS.
  • Control and visibility: Customers have restricted control and visibility over the cloud resources because the cloud provider is responsible for administering the infrastructure. This introduces additional security concerns that originate from the lack of transparency. Customers need to rethink the way they operate as they surrender the control of their IT infrastructure to an external party while utilizing public cloud services.
  • Security responsibility: In a cloud the vendor and the user share the responsibility of securing the environment. The amount of responsibility shouldered by each party can change depending on the cloud model adopted.

Identifying and Assigning Security Tasks in Each SPI Service Model: SaaS, PaaS, and IaaS

Security-related tasks tend to be the highest for the cloud provider in a SaaS environment, whereas an IaaS environment shifts most of the tasks to the customer. Please see the following:

  • SaaS
  • Attack types: Elevation of privilege, cross-site scripting attack (XSS), cross-site request forgery (CSRF), SQL injection, encryption, open redirect, buffer overflows, connection polling, canonicalization attacks, brute force attacks, dictionary attacks, token stealing.
  • Provider security responsibilities: Identity and access management, data protection, security monitoring, security management, authentication, authorization, role-based access control, auditing, intrusion detection, incident response, forensics.
  • Consumer security responsibilities: Other than assessing the risk of being in a cloud environment, the customer has little to do in SaaS environment.
  • PaaS
  • Attack types: Data tampering, buffer overflows, canonicalization attacks, SQL injection, encryption, disclosure of confidential data, elevation of privilege, side-channel attacks (VM-to-VM)
  • Provider security responsibilities: Security monitoring, security management, authentication, authorization, role-based access control, auditing, intrusion detection, incident response, forensics
  • Customer security responsibilities: Identity and access management, data protection
  • IaaS
  • Attack types: Data tampering, side-channel attacks (VM-to-VM, VM-to-host or host-to-VM), encryption, network traffic sniffing, physical access, brute force attacks, dictionary attacks
  • Provider security responsibilities: Role-based access control, auditing, intrusion detection, incident response, forensics
  • Customer security responsibilities: Identity and access management, data protection, security monitoring, security management, authentication, authorization

RIL Forays Into 350 Bn Cybersecurity Future Powered by Hardware was originally published in Exponential Technologies / Industrial Revolutions Based Infrastructure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Liquid error (layout/theme line 205): Could not find asset snippets/jsonld-for-seo.liquid
Subscribe