Tag: operational technology

  • Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk Adds Hub to Extend Observability to Edge Computing Platforms

    Splunk today launched a platform for ingesting data from sensors, industrial equipment and internet-of-things (IoT) platforms so that it can be analyzed alongside data collected from IT environments.

    Announced at the company’s .conf23 conference, the Splunk Edge Hub extends the reach of the troubleshooting platform Splunk provides that increasingly involves various types of edge computing platforms.

    Tom Casey, senior vice president for products and technology at Splunk, said Splunk Edge Hub is designed to be deployed in those edge computing environments and reduce the total amount of data that needs to be transferred back to an instance of the Spunk analytics platform running in a data center or in the cloud.

    That approach makes it possible to remotely monitor everything from environmental conditions to identifying anomalies indicative of an outage that might be prevented. The overall goal is to unify visibility across IT and operational technology (OT) environments as these systems and applications become more integrated, said Casey.

    It’s not clear how quickly that integration is occurring, given the historic cultural divide that has existed between IT and OT teams. But with the rise of digital business transformation initiatives, the data collected from edge computing platforms is increasingly being incorporated into a wide range of applications deployed at the edge, in local data centers and in the cloud.

    In general, observability tools are being used to not only improve processes but identify and block suspicious activity. Of course, OT teams have been monitoring edge computing platforms for decades, but observability platforms make it feasible to interrogate logs, metrics and traces to hopefully discover issues before there is a disruption to services. The challenge, of course, is that not everyone on either the OT or IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue. The Splunk approach essentially leverages the skillset of IT professionals that have mastered its platform to address that issue; something most OT professionals are not going to be able to do using their existing tools and platforms.

    One way or another, DevOps teams will soon need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than responding after a metric that OT teams are monitoring has already exceeded its threshold.

    In the event there is still an issue, observability platforms should also reduce mean-time-to-remediation (MTTR) as visibility into IT environments, including edge computing platforms, is improved.

    It’s not likely that OT and IT teams will ever be completely unified, but as observability platforms continue to evolve, there will be much greater opportunities for collaboration.

  • 4 Things to Do When Running the Iot Zoo

    4 Things to Do When Running the Iot Zoo

    Zoos are fascinating places. In just a few acres you can encounter all kinds of interesting, rare and exotic animals from different parts of the world and from different ends of the food chain. But, what keeps the tigers from eating the zebras or even the visitors? Segmentation. Walls, fences, cages and other barriers that keep every critter safe and well behaved. The same concept is vital to the proper security of Internet of Things (IoT) and operational technology (OT) devices. As these devices proliferate, it is segmentation that keeps them all safe and well behaved.

    Here’s what I mean.

    The modern enterprise consists of a huge variety of network-connected devices that play different roles in making the network operate properly, provide services to customers and partners, and that allow employees to do their jobs quickly and efficiently. Once deployed, however, it can be difficult to track and monitor IoT devices—and you can’t manage what you can’t see.

    Using the zoo analogy, if your devices are allowed to roam freely, some will be forgotten and others will act in unexpected ways. There will be unmanageable chaos. But, if the animals are categorized, monitored, segmented and cared for, the zookeeper can keep things operating in an orderly manner.

    If you are among those struggling to keep your IoT and OT device menagerie in line, I have bad news. Your challenges aren’t getting any easier. According to some estimates, there will be between 41.6 billion and 83 billion IoT devices connected to networks by 2025. Those estimates were made before the outbreak of the COVID-19 pandemic. Now that a Pandora’s box of remote work has been opened, there’s a strong chance trends like distributed workforce, manufacturing automation and mobility will result in a sharp acceleration in the use of IoT devices, pushing those numbers higher. Making matters worse, many of those devices will connect to networks unnoticed, unmanaged and unsecured.

    Healthcare is already among the industries feeling the effects of most sharply. Healthcare organizations rely on connected devices to perform their jobs and deliver the highest quality of care possible. It’s not just medical devices like insulin pumps, EKG machines and ventilators. Sophisticated healthcare facilities rely on connected devices for security monitoring and access control, administration, environmental control and IT operations management. The health, security and usage of non-medical devices can impact patient care so, for instance, IP-enabled elevator systems are needed to transport patients while HVAC systems can impact air quality in operating rooms. Protecting and managing IoT and OT devices is especially important in healthcare organizations post COVID-19, as we will be dealing with the aftermath of a surge of new devices being deployed.

    Right now, roughly 15 million IoT devices are being used by healthcare professionals worldwide. Hospitals use an average of 10-15 devices per bed, collecting and communicating highly sensitive protected health information (PHI). It’s no surprise, then, that 82% of healthcare organizations have had their IoT devices targeted. The risk increases when devices used by medical personnel cross from professional to personal use. A tablet used to enter a patient’s PHI and check email makes the network it’s connected to more vulnerable to phishing scams and ransomware. Unfortunately, with hospitals focused on responding to the pandemic, some malicious actors see it as an opportune time to strike.

    What can be done to mitigate the risk? If I ran the IoT zoo, there are four steps I’d take to figure out what was running wild and wrangle everything into its pen.

    Discover and Inventory

    You can’t manage what you can’t see, so complete, real-time discovery of IoT devices is critical. Step four of segmentation is unachievable without proper visibility and classification of devices. The fidelity of visibility and classification of devices is key, and needs to consider ephemeral assets that may go online and be brought up in a different physical or network location. We’ve seen this situation be exacerbated during the COVID-19 pandemic as new network-connected devices are rushed into service. 

    Baseline and Monitor Behavior

    Once you’ve taken inventory, you need to map how devices communicate and with what. Devices use a variety of protocols and communication patterns. Baselining what is normal is crucial to identify when devices start behaving badly. For example, without proper traffic monitoring, we won’t know that the baboons are attacking the pangolins every night. 

    Identify Risks

    With a baseline for recognizing bad behavior, you can identify anomalies that signal potential compromise, high-risk devices such as those running obsolete operating systems and devices with medical or FDA-advisories. The fragile, rare or highly valuable animals can be managed differently than a common “low value” asset, like a sparrow. Look out for solutions that tout their cybersecurity prowess with threat alerts but without providing ways to resolve the issues.  

    Segment and Secure

    Finally, with devices visible and categorized, and associated risks identified, your next step is to secure them. Since you cannot deploy endpoint agents, devices need to be properly secured using appropriate segmentation policies. The key is doing this in an automated manner that is scalable and operationally feasible, and uses the infrastructure that the organization has already invested in—networking products, firewalls and network access controls (NAC).

    And, with apologies to Dr. Seuss, I’ll leave you with a final thought:

    It’s an IoT zoo, said the young CIO, but the people who run it, don’t know what to do. 

    If I ran this zoo, said the young CIO, I’d make a few changes. That’s just what I’d do. 

    The monitors, HVACs and all of that stuff, are not secure or well managed. It’s not good enough! 

    I’d ID and segment, assign policies, too. The old ways just don’t cut it. Time for something new!

  • LF Edge Moves Open Networking Push Forward

    LF Edge Moves Open Networking Push Forward

    A vendor-neutral initiative dubbed the State of the Edge was acquired this week by LF Edge, an arm of The Linux Foundation focused on defining an open source stack of software for edge computing applications.

    The State of the Edge project will be merged with the existing Open Glossary of Edge Computing initiative that LF Edge already had in place. That combined initiative will now be known as the State of the Edge project within the larger umbrella of LF Edge projects.

    State of the Edge was launched by Vapor IO, Arm, Rafay Systems, Packet by Equinix and Edge Gravity by Ericsson to provide free research reports. Arpit Joshipura, general manager for networking, edge and Internet of Things (IoT) for The Linux Foundation, said that mission will continue as part of a larger effort to advance open software-defined networking software.

    The goal is to define stacks of software and implementation blueprints that will make it simpler for both telecommunications carriers and enterprise IT organizations to implement open source networking software both at the edge and in the cloud, said Joshipura.

    That’s critical because as IoT continues to evolve it’s apparent that IT and operations technology (OT) teams will converge, he added, noting the challenge is enabling organizations to achieve that goal around using a suite of programmable open source platforms that are truly interoperable with one another.

    Existing LF Edge projects include Akraino Edge Stack, an edge computing platform; Baetyl, a cloud-based management platform; EdgeX Foundry; a framework for sharing data between devices; Fledge, a set of application programming interfaces (APIs) for common administrative tasks; Home Edge, a platform for deploying consumer applications; and Project EVE, a virtualization engine.

    Interest in building and deploying applications at the network edge is on the rise in anticipation of 5G wireless networking services becoming widely available. Most of the organizations building those applications will be relying on best DevOps practices to achieve that goal. Less clear for now is the degree to which traditional network operations will be rolled up into those DevOps practices. The more programmable the networking environment becomes the more control each developer theoretically can have over the network services being accessed by their applications. However, network bandwidth is often a finite resource; there most likely will need to be some governing mechanism that determines how much network bandwidth any one application would be allowed to access at any given time.

    Of course, the open source community is not the only entity eyeing the rise of edge computing. Providers of commercial networking platforms ranging from Cisco Systems to VMware are all focused on enabling edge computing applications. Historically, open source platforms such as OpenStack have been embraced by carriers. However, within enterprise IT environments open source networking platforms have not gained much traction. The open source community will need to galvanize around a set of platforms and blueprints for edge computing platforms quickly. Otherwise, many organizations will most likely turn once again to commercial networking platforms to provide services to edge computing applications.

    — Mike Vizard

  • IoT Future-Proofing for the Long Haul

    IoT Future-Proofing for the Long Haul

    Think about this: The IoT application your DevOps team is developing right now, if successful at scale, will likely be the longest-living application in your shop. It may even outlive the tenure of many of your team members with your company. Is IoT future-proofing possible over a life cycle of 10 years or more? Yes, with some insight for the long haul borrowed from industrial and defense computing experience.

    That may sound counterintuitive for DevOps because those industries aren’t exactly known for agile processes. They’re designed around minimizing change and containing risk in mission-critical situations. IoT technology is evolving rapidly and it’s difficult to say what things may look like in a year or two, much less 10. What IoT applications have in common with industrial and defense systems is that they are often complex. Your operational technology (OT) people probably appreciate how complex their existing production environments have been. IoT applications add elements of wireless connectivity, cloud architecture, real-time performance, end-to-end security and algorithmic sophistication.

    At-scale IoT applications will require mastery of complexity, and lessons learned can help. The objective is not to avoid change but rather to “build the airplane while flying.” The core DevOps concept of continuous application release and testing needs to extend beyond just the application code. Teams will need to be detail oriented, looking at device configurations, interoperability, data integrity and how analytic insights evolve as data accumulates.

    Device Configurations

    Buying an enterprise server usually means selecting a commodity: Pick a processor model and frequency, memory size, number of Ethernet and USB ports, storage interfaces and packaging. In the cloud, selections in elastic instances are even easier. As long as the box fits and runs the desired operating system, the details of what’s inside aren’t that important. If you have to buy another one in two or three years, there are likely higher performance choices available.

    In long-lifecycle computing for IoT applications, boxes aren’t commodities. Real-time performance drives differences in processor and board architecture. If you have to buy another one in two or three years, that could be a problem. Vendors often offer industrial and defense customers revision control services, ranging from notification of changes to extended availability of specific configurations. Assuring supply sometimes means a lifetime purchase of components, perhaps as bonded inventory for a customer.

    Interoperability

    Even simple IoT devices, such as wireless sensors, can present a problem on a 10-year scale. Connectivity specifications evolve, with both major changes and minor revisions. Cellular standards reach sunset as mobile subscribers leave them behind. Vendor support for older gear is often given reluctantly, frequently expensive and sometimes non-existent unless an upgrade is executed.

    Choosing interoperable frameworks with robust ecosystems will be critical for success in the long haul. Teams should be prepared with a “plan B” if a vendor is acquired and stops offering a specific configuration, or if they cease operations altogether. Devices with over-the-air (OTA) programming help keep pace with specification changes and alleviate security concerns as they arise.

    Data Integrity

    Teams won’t be able to just stop the IoT plane and work on it. Data collected on day 1 will be just as valuable as data collected on day 3650, if it’s handled correctly through IoT future-proofing tactics. Often, IoT devices connect to networks easily. The real test of an IoT application comes when data starts flowing, perhaps from thousands of devices. Is the data from an authorized device? Is all the data in the correct format? Is it time-stamped properly? Is it checked for errors and missing frames?

    Presumably, when an IoT application succeeds, the temptation to scale quickly sets in. Suppose a new group of sensors is added with the same class of information in a slightly different format. The system should abstract formats and sanitize data at the edge, so all data reaching the cloud is ready for algorithmic processing. For example, JSON is one tool that can help with abstraction. Edge computing may also use generative models to reduce data transmitted to the cloud, forwarding only out-of-bounds conditions for further analysis.

    Analytic Insights

    At the onset of an IoT project, teams have an idea of what they have set out to accomplish. Inevitably, as projects mature new insights come out of analytics. The architecture may not be optimized to deliver those insights in real-time, and changes may be necessary to speed up delivery of algorithmic results. Workflow optimization is an ongoing process for IoT teams. This is the ultimate instance of rebuilding the plane while in flight, extracting more value from an in-place system.

    The Ethos of IoT Future-Proofing

    IoT future-proofing is possible by embracing both the longevity and the complexity of the application. Shifting your team ethos from maintaining a static configuration to developing a living application architecture, helps overcome events certain to happen over a 10-year life cycle and beyond.

    — Don Dingee