IoT E-mag June 2015 by OpenSystems Media

embedded-computing.com/topics/iot

E M A G

2015 Volume 2 Number 1

Q&A with Gareth Noyes, Wind River

»»

Focusing on the ‘Things’ and their manufacturers

»»

Hyperconnecting the IoT

»»

Protecting the IoT – Are you building with security in mind?

»»

Providing secure connected products

»»

Mastering Industry 4.0 connectivity

Sponsored by Wind River, Ayla Networks, Kontron, KORE Telematics, ThingWorx, Congatec AG, Sealevel

E M A G

FEATURING Leveraging the Internet of Things to transform your business Q&A with Gareth Noyes, Wind River

Focusing on the ‘Things’ and their manufacturers By Ayla Networks

Hyperconnecting the IoT – Realizing the full potential of large-scale, end-to-end IoT applications with public and private cloud infrastructure By Kontron

Protecting the IoT – Are you building with security in mind? By KORE Telematics

Providing secure connected products By ThingWorx, a PTC Business

Mastering Industry 4.0 connectivity By congatec AG

Sponsored By ™

© 2015 OpenSystems Media, © Embedded Computing Design. All registered brands and trademarks trademarks within the Medical E-mag are the property of their respective owners. within the Internet of Things E-mag are the property of their respective owners.

NO COMPROMISE COMPUTING SOLUTIONS COM Express Modules Give your application the solution it deserves. Sealevel’s Computer on Module system designs combine the advantages of custom design with the convenience of COTS. COM Express modules offer a selection of processors ranging from powerful multi-core Intel i7 and i3 to the popular Atom. Low power designs eliminate the need for cooling fans, greatly enhancing system reliability. Extended temperature models are available offering -40C to +85C operating temperature range. COM Express modules contain the core computer functionality most affected by changing technology. Since the modules are based on an industry standard speciﬁcation, COM Express systems are easily updated to stay current with the latest technology. • Variety of Processors and Form Factors • Application Speciﬁc I/O • Rugged, Solid State Operation • Vibration Resistance • Extended Operating Temperature • Long-term Availability • Superior Life Cycle Management

COM EXPRESS QUICKSTART KIT The 121004-KT provides everything you need to get your COM Express project off to a fast start. Powered by a 1.8GHz Intel Atom N2800 CPU with 4GB RAM and integrated heatsink, the QuickStart kit includes an installed 2.5" 32GB SATA solid-state disk. Standard features include ﬁve USB 2.0, two RS-232, one RS-485, dual Gigabit Ethernet, SATA, DisplayPort and audio interfaces. To interface the RS-485 port, a 10-pin IDC to DB9M serial cable is included. The carrier board and module are powered by the included 100-240VAC to 24VDC external power supply with US power cord. The QuickStart kit simpliﬁes software development and prototyping while the target application carrier board is designed. Take advantage of Sealevel’s carrier board development services for the fastest time to market.

sealevel.com • 864.843.4343 • sales@sealevel.com

Leveraging the Internet of Things to transform your business Q&A with Gareth Noyes, Wind River

In this interview with Gareth Noyes, Chief Strategy Officer at Wind River, we discuss the current state of Internet of Things (IoT) rollouts, and project how industry standards and technologies such as Agile DevOps are poised to help companies overcome challenges like IT/OT convergence, scalability, and data structures over the next five years. eâ&#x20AC;&#x2122;ve been talking about the Internet of Things (IoT) for some time, but are only now starting to see glimpses of usable frameworks and working deployments. What trends or challenges have you noticed in the IoT market that are either fostering or inhibiting growth?

NOYES: There are several factors that are fostering growth in the IoT market. There is recognition from large industrial and manufacturing customers that IoT can transform their business and unlock value by improving efficiencies and lowering OPEX, and they are making significant investments (both brownfield as well as greenfield) to capitalize on this recognition. Venture capitalist (VC) money is flowing and the IoT startup scene is exploding. In parallel, the cost of hardware (processors, sensors, etc.) is dropping, networks are getting faster 4

and more reliable, and cloud technology and application-level innovations mean that technology doesnâ&#x20AC;&#x2122;t have to be built from scratch. It has been very exciting to see the introduction of usable common deployment frameworks like the Intel IoT Platform, which includes Wind River software for cloud connectivity (Figure 1). In terms of challenges restricting growth, the sheer magnitude of the IoT, along with the introduction of unattended devices (devices with no or limited human interaction), have presented challenges to nearly all existing standards for connectivity, management, and security. Standards need to evolve to account for the non-homogeneous nature of IoT. Systems that were not designed to communicate with each other are being connected through IoT gateways, which has the potential of increasing security vulnerabilities. In addition, data semantics may not be compatible between systems,

Transform Business on the IoT

••• Figure 1 The Intel IoT Platform is an end-to-end reference model that includes the Wind River Edge Management System for cloud connectivity, McAfee Enhanced Security, and various Intel Architecture (IA) technologies for Internet of Things developers. leading to costly data or protocol conversion processing in order to normalize the data for use by analytics software in the datacenter. Standards leadership is needed to understand how we can combine standalone systems into systems of systems in a secure and cost-effective way in order to foster the faster innovation promise of the IoT. We’re definitely seeing movement here with groups like the Open Interconnect Consortium (OIC) and Industrial Interconnect Consortium (IIC).

technology (IT). Given that these two domains often represent two very different types of vendor (embedded versus network), what would you prescribe as the best method of ensuring successful product launches once they hit the “wild” of the IoT?

ou have touched on both the cyber and physical domains of the IoT, which in a traditional business sense have been separated as operational technology (OT) and information

1. Focus on the business outcomes you want to achieve. With all the hype around IoT, it is tempting to get carried away with the technology transition. However, IoT has the potential to transform businesses

NOYES: We recommend companies take into consideration the following to get IT/OT convergence right:

in two dimensions: business optimization (by maximizing existing infrastructure or lowering OPEX) or driving new revenue sources (for example by enabling new services or business models). Focusing on the tangible outcome you are trying to achieve will allow you to frame the opportunity at a sufficiently strategic level so that cross-organizational silos can be broken down. 2. When upgrading OT infrastructure, adopt equipment offered with nonproprietary IT technology such as standard high-speed communications links and operating systems that include standard communications stacks and security protocols. 3. Recognize and embrace the fact that IT and OT functions share fundamentals in network and device infrastructure, but differ in talent (IT specialists versus process specialists), objectives (keeping production running versus managing to SLAs), and security standards (â&#x20AC;&#x153;winging itâ&#x20AC;? versus complying with approved policies). Given the nature and scale of IoT, IT is best equipped to handle convergence projects. Insist that IT adopt a methodical, no-heroics approach to IT/OT convergence projects through standard project frameworks that incorporate stakeholder analyses and swim lane process flows that anticipate and work around the failure modes of OT 6

devices (less frequent patches from vendors, harder and non-standard maintenance procedures, etc.). 4. Harvest your convergence investment by looking at your new business processes. See where you can reduce costs by acting on OT data that is combined with IT data (such as weather and equipment uptime information).

nother issue facing both embedded and network vendors is that of scale, which in turn becomes an issue of agile development/continuous integration. How do you see both embedded OEMs and network providers approaching the issue of scalability, and where does agile DevOps fit in for each?

NOYES: IoT is predicted to create a significant scalability challenge, one however we believe can be solved with well-defined end-to-end system architectures that embrace standard components, protocols, container technologies, and the flexibility of cloud and microservice architectures. The notion of lifecycle, whether applied to devices or IoT apps, takes center stage as OEMs create new device categories and network operators are expected to handle increased data traffic. Network infrastructure will have to evolve and provide performance and latency guarantees required by IoT use cases. Agile/

Transform Business on the IoT minimum viable product (MVP) methods are well-suited to help drive convergence between IT and OT domains, with IoT app developers building distributed applications that link device data to IT-driven business logic. The implementation of agile methods needs to be done in the context of device, application, and system lifecycles. IoT deployments (where the term scalability takes on a new meaning with exponential increases in the number of end points) impose additional challenges with significantly increased requirements for testing, support, compatibility, and traceability. The way to tackle all this complexity is through automation, and we believe Agile DevOps (which will evolve) has the foundations for what it takes.

ne area of the IoT that certainly is not restricted by scalability is the cloud. But while the cloud is an extremely powerful tool at the backend of the IoT, that in some cases can stretch close to the edge, there are still a lot of question marks surrounding the structuring and management of edge device data in a format that is interpretable and actionable for both machines and humans. What developments do you see in terms of cloud data structures, and how do you see edge data management progressing as the IoT evolves?

NOYES: Today we are living in a very heterogeneous IoT world, especially when you look at brownfield IoT applications. In the near term, protocol translation and some normalization near the edge is going to be important to the successful “scaling” of IoT, otherwise there will be too many “siloed” solutions and limited economies of scale. In the long run, to aggregate the edge data and make the edge device data actionable, especially across domains, there will need to be agreed-upon data normalization. This normalization was relatively easy in the IT world as the range of log files and other IT data was much narrower. In the IoT world the range is much broader, however the same technologies apply. It is more of how to apply these technologies rather than inventing something different. IoT device management platforms help with the normalization processing, and eventual standardization via organizations like the OIC and the IIC will accelerate this process. As this normalization becomes pervasive, the ultimate IoT vision of autonomous and distributed control loops will be fully enabled.

hat are your projections for the IoT 12-18 months from now? 5 years from now? Help us predict the future.

NOYES: 12-18 months from now: Businesses: õõ A few companies that are making early IoT investment decisions will start to see ROI õõ Businesses will start moving from 7

õõ

connecting their equipment to the realm of proactive monitoring and intelligent usage analytics and predictive maintenance Companies will start to experiment with connecting IoT systems with enterprise systems; many integration challenges will be unearthed in this process

Technologies: õõ Intelligence will start to move closer to the edge with more capable sensing devices, faster gateways, and device management software õõ Data issues will start to get sorted out through several emerging technologies: smarter databases, in-memory computing, and smart command/control algorithms õõ The cloud as a backend will become table stakes for IoT platform offerings; most development and deployment will be cloud based õõ Apps will start to become even more easy to write and deploy through containerization and related technologies õõ Security will enjoy renewed focus but technology will not have converged Five years from now: Businesses: õõ The IoT investment ROI will be clearly understood; OPEX savings and productivity improvements will start to get realized õõ Supply chains get connected and manufacturing becomes 8

õõ

cleaner, less wasteful, and more orchestrated to drive even higher productivity gains Companies will start to realize the business value of connecting IoT systems with enterprise systems, and they will start to innovate and act upon new information to further optimize their business (for example, combining sensor data with business cycle timing and macroeconomic factors to drive investment decisions) and better utilize their assets as labor gets more and more servitized

Technologies: õõ Hardware starts to get specialized and reconfigurable on a justin-time (JIT) basis through programmable logic õõ Software becomes even easier to write, and security standards will converge and be interwoven into each layer of software/hardware õõ We will see the rise of virtualized machine functions (the move away from custom, fixed-function machines on factory floors to those that can be customized/ programmed from off-the-shelf machine parts); this ‘Machine Function Virtualization’ movement will mirror the datacenter virtualization phenomenon õõ The convergence of wearables, context-aware algorithms, and augmented reality will enable environment personalization to enable productivity gains

Transform Business on the IoT

Gareth Noyes is Chief Strategy Officer at Wind River Systems. Wind River  www.windriver.com

@WindRiver  www.linkedin.com/company/wind-river  www.facebook.com/WindRiverSystems  www.youtube.com/user/windriverchannel

Watch Video

Focusing on the ‘Things’ and their manufacturers By Ayla Networks

The promise of the Internet of Things (IoT) is usually presented as benefits to end consumers: Safety and security devices that can send an alert to the user when smoke is detected in the home or a door is opened when nobody is home; HVAC and water heating systems that adjust to residents’ individual comfort levels; Lighting that automatically illuminates where and when needed for optimal visibility, ambience, or safety. But this consumer-focused view skips a crucial step: Manufacturers of traditional products such as refrigerators and water heaters and lights first need to design and manufacture connected versions of their products. In other words, they need to create the ‘Things’ of the Internet of Things (IoT). IoT connectivity takes expertise plus experience The step from unconnected to connected products is a daunting one. Unlike the computers and smartphones and tablets we use to connect to the Internet of Computers, the devices of the IoT were rarely designed with connectivity in mind. Turning traditional products into connected products requires specialized, deep knowledge and expertise in networking, software development, cloud computing, and other technologies. In addition, it turns out that the expertise to build connected devices comes only from experience actually building connected devices. The Ayla IoT Platform was born from deep expertise gained by hard-won experience. The essence of the Ayla platform architecture cannot be captured by a single feature or technology. Instead, it can best be understood as a series of decisions and design choices that interact and coalesce into a singular solution that enables manufacturers of all kinds to get to market quickly and easily with connected versions of their products. Then, once their connected products enter the world, manufacturers can use the data generated by their products to enhance the products themselves, forge deeper ties 10

IoT Security Considerations

with their end-user customers, improve warranty and maintenance processes, and generate new revenue streams. Let’s look at each of these characteristics in a bit more detail.

It works with any device or product

Some of the most important goals and characteristics that define the Ayla IoT Platform õõ

It works with any device or product

From the outset, Ayla has taken the ‘Things’ part of the IoT very seriously.

õõ

It encompasses device, cloud, and mobile app software

Fragmentation is a fact of life for the IoT. Each category of product connected to the IoT has its own domain, which likely has nothing to do with the technologies, ecosystems, or expertise required for IoT connectivity. The devices now being connected have different processing capabilities, they use different protocols, they comply with different standards, and they have radically different needs and goals from connectivity.

õõ

It aims for optimal flexibility, business agility, and customer choice

õõ

It lets manufacturers get to market with connected products – without having to write any code or learn any of the technologies required for connectivity or participation in the IoT

õõ

It scales: In kind, in volume, in performance and reliability, over distance, over time

Ayla designed its IoT platform to be generic, meaning it is able to work with essentially any kind of product. For Ayla, it is important that its platform supports an air conditioner just as easily as a thermostat, a medical device, a coffee maker, or an oil rig.

õõ

It transcends arguments about where intelligence should reside in the IoT

õõ

It provides manufacturers with inherent incentives to create connected devices

õõ

It plays well with others, and it keeps the future in mind

Manufacturers are experts in their domains, but rarely are they also experts in making IoT-connected versions of their products. The Ayla architecture is built to take care of the IoT connectivity portion of the equation for

manufacturers, no matter what kinds of products they make (Figure 1).

It encompasses device, cloud, and mobile app software The Ayla IoT Platform ••• Figure 1 architecture takes an endThe Ayla IoT Platform can be described as “energetic,” working to-end approach, offering with virtually any type of device to add connectivity for products software that spans all the in any industry. elements of the IoT itself: device, cloud, and mobile app. flexibility, business agility, and customer choice the cloud makes possible – in Across this full spectrum, Ayla handles mind (Figure 2). security, performance, latency, and communications handoffs everywhere. It also SOA, defined as a technique involving takes care of keeping the software, firm- the interaction between loosely couware, and security of connected prod- pled services, enables a divide-anducts updated and current. conquer approach to whatever functionality is needed. Each function gets Security is one of manufacturers’ big- a separate service, and each service gest concerns when contemplating or is architected to run independently of implementing connected versions of other services. their products. Ayla believes strongly that, in the IoT, security must be handled Ayla offers a particularly comprehensive comprehensively at all levels, including SOA implementation that includes: the handoffs among devices, clouds, and apps. õõ Device services, such as templates, notifications, time and location, It aims for optimal flexibility, image services, and over-the-air business agility, and customer updates

choice

Ayla does not take a one-size-fits-all approach to IoT connectivity architecturally. The Ayla platform is a service-oriented architecture (SOA) implementation engineered with the cloud – and the 12

õõ

User services, including security (authentication/authorization/ accounting, role-based access control, etc.), triggers and alerts, OEM dashboards, and developer websites

õõ

Application services, such as a rules engine, third-party integrations, and custom rules

õõ

Data and analytics services, such as logging and metrics, statistics, reports and data discovery, and ETL (extract/transform/load data)

Application programming interfaces (APIs) provide the common language among the services in Ayla’s SOA-based architecture, allowing the Ayla cloud to communicate easily with the APIs of various other secure clouds and services.

Security capabilities IoT Security that theConsiderations Ayla platform makes available õõ

Authentication/authorization/ accounting (AAA) at both the user and device levels

õõ

Role-based access control (RBAC), including the ability to define multiple roles to limit who, when, and what can reach the Ayla server

õõ

Token-based authentication, which stores personalized information (e.g., username, password, etc.) in the end user’s service, making available a secured token rather than personal information itself to authenticate the user whenever he or she wants to access a piece of data

õõ

Encryption of data in transit (HTTPS, AES-128-bit encryption) and data at rest (encryption keys, backups)

õõ

Customer-configurable temporal encryption keys

õõ

Passwords that use salted hashing

õõ

SSL tunneling for solid device security out of the box

õõ

Deployment over AWS, which is ISO 27001 certified

õõ

Security groups

õõ

Virtual private cloud deployment over private subnets

The Ayla platform is communication protocol-agnostic, allowing manufacturers to take advantage of Wi-Fi, Ethernet, ZigBee, or other networking protocols they choose.

••• Figure 2 The Ayla IoT Platform’s service-oriented architecture (SOA) implementation allows it to be molded to the requirements of each individual use case.

Also important to the Ayla architecture’s flexibility is that its services are stateless, meaning that all its data or state is maintained in a database in the cloud rather than on Ayla application servers. As a result, Ayla can add or remove a server without the concern that a particular server is servicing a particular product. Servers do not need to keep track of clients; it’s all handled in the cloud.

Ayla’s embedded agent comes preloaded into the communication chip that is designed directly into the product, providing all of the code needed for connectivity. Because the Ayla black box code is already tested and production-ready, it means that manufacturers do not need to expend time or resources writing any connectivity-related custom code themselves. Instead, they can focus on what they do best.

It lets manufacturers get to market with connected products –without having to write any code or learn any of the technologies required for connectivity or participation in the IoT

The black-box approach also enables OEMs to create very efficient product development pipelines for similar kinds of connected products because they don’t have to recreate custom code for each kind of device.

One of the most important design directives for the Ayla Platform is that it does not require manufacturers to write any custom code, no matter what kind of products they make. Through its generic platform approach, Ayla delivers production-quality software that is production-ready and usable by manufacturers of any device or product.

It scales: In kind, in volume, in performance and reliability, over distance, over time

Ayla offers a ‘black box’ solution that encompasses nearly all the code needed to create and deploy a connected product.

For instance, it scales:

For most manufacturers, the host application functionality already exists and might have existed for years. The Ayla solution delivers everything necessary to turn any kind of host application into a connected product. 14

The term “scale” most often is associated with growing in capacity or number. But because the Ayla platform is built on the cloud, it can scale dynamically in multiple directions.

õõ

In kind: To support different use cases, different markets, different kinds of products and devices – without knowing ahead of time what particular features or functionality will be needed – by connecting via the Ayla cloud rather than by connecting directly to multiple devices or services

Scalable IoT Connectivity

õõ

In volume: To support millions or billions of connected products and users by adding servers as opposed to getting a bigger server (i.e., horizontal rather than vertical scaling)

stay on indefinitely. Ayla architected its platform so that users can configure the schedule in the cloud, but then the cloud downloads the schedule to the device and the device executes the schedule without needing to be connected.

õõ

In performance and reliability: Through secure over-the-air updates that keep connected products performing reliably and securely

õõ

Over distance: By connecting Ayla clouds to other secure clouds, globally

õõ

Over time: By learning and evolving – yet remaining “generic” to any kind of device type – as needed to serve the evolving needs of manufacturers

Another example is determining the local time of a device, which can be important for many kinds of daily or seasonal controls. The Ayla platform has three different methods to figure out the location of a device, and an algorithm determines which of these three methods provides the most accurate location for that particular device.

It transcends arguments about where intelligence should reside in the IoT In the Ayla architecture, the cloud is the master. As a result, devices can be smart or they can be dumb – in which case they can “catch” intelligence from the cloud as needed. One example is the concept of scheduling. Many IoT connected devices require a schedule, and there are many parameters that must be considered for effective scheduling. For instance, if an IoT-connected sprinkler system is on and the system loses connectivity, it is important that the sprinkler doesn’t

Business logic is retained in the cloud. The Ayla cloud includes a rules engine, enabling a device- or cloud-based event to influence another event, which is important because it enables the manufacturers to automate certain conditions and events, some of which can also be configurable (within pre-determined parameters) by end users. For example, the manufacturer of a kitchen range can set a rule that if an oven door is left open for minutes during the cook cycle, the range sends a message to the user’s mobile app to close the oven door. The Ayla cloud also includes a statistics engine that can automatically generate particular statistics on a connected product, without requiring custom code to be written for either the device or the cloud. Manufacturers can, for 15

instance, count the average, maximum, minimum, and/or frequency at which a user performs some kind of behavior with their product.

It provides manufacturers with inherent incentives to create connected devices For some device manufacturers, connectivity is a given. For many other manufacturers, however, it might not be obvious why they need to turn their perfectly well-performing products into connected products. By lowering the barriers to connectivity, Ayla greatly reduces the risk, expense, and hassle of turning a traditional product into an IoT-connected product. In some cases, this might be enough incentive for a manufacturer. Longer term, however, Ayla sees benefits to manufacturers that go well beyond appealing to consumers’ desires for IoT products. When manufacturers gain real-world knowledge about how their products are actually being used – possible only through data generated by connected devices – they can improve multiple aspects of their business. For example, they might:

õõ 16

Redesign warranty programs to be better for themselves and their customers

õõ

Improve service and maintenance by replacing parts before they fail

õõ

Iterate the actual design of their products over time to more closely match what consumers want to buy

õõ

Change their business models to be more efficient and attractive to consumers

õõ

Generate new revenue streams through additional services or features

It plays well with others, and it keeps the future in mind As a company, Ayla adopts a cooperative rather than a competitive approach when it comes to connectivity. Ayla supports industry standards and participates in consortiums important for IoT connectivity. Ayla is also building a rich ecosystem of partners in areas compatible with all aspects of IoT. In Ayla’s view, cloud-tocloud integration is the natural way to add service offerings to an IoT solution. The company continues to invest in building out its ecosystem and having technology that makes it very easy for third parties to talk to Ayla services, and for Ayla to talk to others’ services. No one has a crystal ball to see what kinds of technologies and market opportunities will be important in the future. To future-proof its platform,

Scalable IoT Connectivity

Ayla includes support for all the protocols and standards important for its current customers, and monitors new

protocols and standards and adds support as needed.

Ayla Networks provides the industry’s first Agile IoT Platform, accelerating development, support, and ongoing enhancements of connected products for the Internet of Things. Ayla’s software fabric runs across devices, cloud, and apps to create secure connectivity, data analytics, and feature-rich customer experiences. Offered as a cloud platform-as-a-service (PaaS), Ayla’s flexibility and modularity enables rapid changes to practically any type of device, cloud, and app environment. Ayla Networks  www.aylanetworks.com

@aylanetworks  www.linkedin.com/company/ayla-networks  www.facebook.com/pages/Ayla-Networks/478621938884489

Watch Video

Hyperconnecting the IoT – Realizing the full potential of largescale, end-to-end IoT applications with public and private cloud infrastructure By Kontron

With projects on the Internet of Things (IoT) gaining speed, developers are now facing new territory in creating the infrastructure. Where does data acquired from sensors go, and what is the right architecture to analyze it? The simple answer would be “the cloud.” Scalability and connectivity found in the cloud are certainly desirable features for an IoT platform, but not enough. A successful IoT application design requires an end-to-end approach, drawing on expertise from both information technology (IT) and operational technology (OT) disciplines. Public cloud infrastructure provides low-cost processing and storage capability, but can pose many unforeseen risks in integration and operation as IoT applications grow. Security is one of the biggest concerns in a public cloud; safeguarding valuable IoT data streams and analytics is essential for trust of IoT applications. Hybrid cloud environments offer a better, safer solution for end-to-end enablement of IoT deployments. Making the task of infrastructure design for the IoT simpler and more flexible are converged modular servers.This new breed of commercial-off-the-shelf (COTS) modular server hardware incorporates the best characteristics of rackmount and blade servers, integrating high-density compute, storage, and network switching into one platform. Walking through some of the aspects of IoT design from sensors to analytics shows how a converged, modular server-based approach scales to meet the demands of critical infrastructure designed around hybrid clouds. 18

IoT Network Infrastructure

Basics of IoT topology Regardless of the network topology connecting individual nodes, IoT implementations usually fall into a three-tier model. Architectural decisions within each tier establish how IoT applications integrate, scale, and deliver value. At the outermost tier lies the edge, where end points of the IoT meet the real world. Here, a cluster of sensors and actuators translate physical characteristics to digital data. Sensor networks can be monolithic, with sensors of the same type and interface capturing data from different physical locations. Many applications deploy multiple sensor types with the intent of fusing the data to derive context. For example, GPS, accelerometers, gyroscopes, and magnetometers combined with sensor fusion algorithms provide indoor navigation capability. Sensors often have long lifecycles, and as networks grow, updated versions of sensors with better capability appear. Gateways at the second tier provide protocol conversion, data aggregation and formatting, and real-time analysis capability. A key role of gateways is accepting a variety of highly optimized protocols for sensors, and converting them to Internet Protocol (IP) for sharing with the cloud and enterprise networks. One example of a gateway is a typical smartphone. With Bluetooth, Wi-Fi, and 3G or 4G connections, a smartphone can connect with sensors, gather data, and upload it to the cloud. Applications using smartphones typically have fewer sensors and

lower sample rates, and less-critical realtime requirements. For more advanced needs, small form factor embedded computers with specialized software serve as gateways. These platforms can scale, aggregating many sensor data streams and making decisions on data locally in real-time if needed. Application services come from the third tier, an IoT infrastructure in an enterprise datacenter or distributed across the cloud. Many IoT applications run dark, capturing and processing data and executing analytics automatically. This implies a higher level of trust for sensors and software in IoT deployments. Asset management services help provision

â&#x20AC;˘â&#x20AC;˘â&#x20AC;˘ Figure 1 The basic Internet of Things (IoT) topology consists of a three-tier model, with embedded engineers usually familiar with systems at the edge and gateway level, but less knowledgeable with the network infrastructure itself. 19

sensors, making sure they are installed and operating correctly, and preventing unauthorized tampering in the sensor/ gateway tiers. Storage services can record both raw data streams and processing results. Advanced analytics capability can examine data, looking for trends and anomalies and even predicting events, and distribute the information across the enterprise network.

the effect across multiple clusters each with their own gateway, can change the situation quickly. An infrastructure unable to keep up with the sum total of data flowing into it risks soft failure. Even brief periods of congestion can result in dropped data, missed events, and faulty analytics results. How should IoT infrastructure design prevent this, while still meeting all the other requirements? IT and OT teams are turning more and more to cloud implementations. By distributing computer resources, platforms share loads, and connectivity, the cloud provides resilience to single-point hard failures and reduces bottlenecks due to processing power or network traffic. Achieving scale means adding “instances,” classes of server platforms for particular tasks.

Where does data acquired from sensors go, and what is the right architecture to analyze it? The simple answer would be “the cloud.” Flying into the cloud Most embedded computing engineers are familiar with designing solutions in the outer two IoT tiers – sensors and gateways. The majority of value in IoT applications comes from analytics, powered in the infrastructure tier. Realizing the full potential of a large-scale IoT application depends on infrastructure design choices. For example, a popular fallacy is IoT applications are low bandwidth. Depending on the sensor type and required sampling rates, bandwidth from an individual end point may in fact be low. Aggregating sensors at the gateway, then multiplying 20

The most popular public cloud platform today is the Amazon Elastic Compute Cloud (EC2). Amazon EC2 provides a wide-ranging set of instance choices, with different platforms and availability-based pricing. Platforms range from compute-intensive to instances with GPUs and transactional platforms with SSD storage. Amazon provides a streaming data service, Kinesis, for big data processing. Public cloud resources like EC2 can be helpful in presenting backend analytics results, or archiving

IoT Network Infrastructure

IoT data, or providing users an overview of what kind of data is coming from where. While these are a breakthrough in a web-user context, they can fall short in a mission-critical IoT context. For high-performance IoT applications with many sensors, faster data rates, and splitsecond decision making, public clouds leave many concerns unaddressed:

õõ

Determinism: Most public clouds offer few assurances of latency or quality of service (QoS). They handle web interaction measured in seconds, with a person in the loop. On the IoT, latency of more than a few milliseconds can throw a carefully orchestrated process out of control. In normal big data analytics tasks, “real time” might mean hourly or daily. IoT analytics are often looking for sub-second exceptions. Symmetry: Unless a truly dedicated instance is purchased, most public cloud instances are on virtualized servers. When the application scales, a second instance could be on another processor on the same server – or on an entirely different machine hundreds or thousands of miles away with different latency. A class of instance may provide the same type of resource, but what else is running on that virtual server? Trusted execution: IoT applications likely take steps to authenticate sensors and gateways to prevent intrusion or hacking. A public cloud

instance can introduce a random server into the mix, weakening the trust chain considerably. Even reputable cloud vendors can be subject to spoofing, DDoS, or other attacks targeting instances that are loosely trusted.

õõ

Data security: Where, exactly, is the data in the cloud? For example, to deal with compliance issues, Amazon introduced AWS GovCloud – an isolated, quasi-public region with specialized security and monitoring tools. Public instances often lack control over the physical location where data is stored. Is data encrypted, how is it encrypted, and is it protected end-to-end or just at the point of storage?

õõ

Protocols, ports, and programming environments: The basic transport layer is usually TCP/IP or UDP/IP, but other protocols are of interest. Unless a fully dedicated network interface exists on a public cloud instance, supporting middleware can become challenging if port numbers are controlled or unavailable. Installing environments such as Java may be non-trivial, but they also may be unsupported by the cloud vendor.

For most IoT applications of significant size, the best answer is a scalable hybrid cloud. This coordinates dedicated private servers handling asset management, real-time streaming, traffic switching, 21

processing and analytics, security, and trusted execution with public cloud resources for presentation and data archiving.

Inside converged modular servers

••• Figure 2

Converged modular servers provide a scalable approach to Internet of A new architecture is Things (IoT) network infrastructure through multiple server classes that driving the scalable IoT allow performance to be scaled out within and between platforms. hybrid cloud: the converged modular server. Compared to a traditional server using connects multiple processors via a a scaled-up processor such as the Intel fast, low-latency, configurable fabric Xeon processor E5 with up to 18 cores, within a single enclosure. Integrated converged modular servers are reaching fabric enables low-latency load balinto the manycore realm to deliver denser, ancing between processor cores. An more flexible compute resources. Ethernet-based platform can drop into an existing enterprise network, distribRather than splitting a large workload uting and shaping traffic. across several cores, the converged server approach is best for many threads Redundant, integrated IP switching proof execution – exactly the right model vides more control over latency and QoS, for IoT infrastructure (Figure 2). By using and guarantees each node its allocated lower power multicore processors, mod- bandwidth. Traffic shaping also segreular servers can reduce overall power gates management traffic from data, consumption and space while enabling providing continuous network integrity scale-out performance increases within under all loading conditions. and between platforms. Also borrowed from blade servers is the Many of these modular servers fea- idea of hot swappable modules. Instead ture the Intel Xeon processor E3 family, of a unified design, many converged moddesigned specifically for lighter, web- ular servers are implemented in a compact scale workloads. rackmount chassis, with self-contained modular server subsystems each having Fabric interconnect is common in their own fabric connection, cooling, and blade-based servers. A converged monitoring. Adding or replacing tool-less modular server architecture also subsystem modules with the platform 22

Hybrid cloud IoT infrastructure demands a platform that delivers quality of service (QoS) for years under any conditions. Kontron’s SYMKLOUD Series brings converged modular servers onto the IoT, with unique support for IT/OT integration and mission-critical applications.

Key features of the SYMKLOUD Series: õõ

2U height, 21” (533.4 mm) depth

õõ

Ethernet fabric interconnect, GigE (MS2900) or 10GigE (MS2910)

Up to nine Intel Xeon E3-1265 Lv2 quad-core processors – up to a total of 36 cores

õõ

Integrated, redundant L4 to L7 switching

Up to 18 Intel Core i7-4860EQ GT3e Iris Pro processors – up to a total of 72 cores

õõ

Up to 2 load balancer subsystems

õõ

All modules hot-swappable

Up to nine Intel Core i7-4860EQ processors combined with PCIe expansion slot

õõ

Up to 13.5 TB storage (HDD or SSD)

õõ õõ

The ruggedized SYMKLOUD Series borrows design philosophy from NEBS telecom-grade infrastructure. It is able to endure higher temperatures and more shock and vibration. Packing 36 cores in a 2U rackmount is remarkable, but depth is also critical. A 21” chassis allows SYMKLOUD into both datacenters and environments such as transportation and industrial. IT-style platform management features include 1-click updates, BMC with advanced options, SNMP, and IPMI, and remote management for diagnostics and provisioning. The SYMKLOUD Series has 5 to 7 year lifecycle support, reducing CAPEX, development, and maintenance costs compared to typical servers.

••• SYMKLOUD MS2900 Media

powered on makes for easier maintenance and upgrades. An advantage some modular servers have in power consumption is dynamic idle, managing power on a per-server basis. Careful task partitioning means processors can sleep, or even completely power down, until needed. For example, if a modular server were dedicated to asset management or analytics, it could be idled if there were no pending tasks – without affecting incoming IoT data streams handled by other servers in the same platform. Converged modular servers bring greater rackspace density, better scalability, and lower power consumption. For example, the Kontron SYMKLOUD Series currently packs up to 36 Intel Xeon processor E3 cores or up to 72 Intel Core i7 processor cores in a 2U enclosure – leading to perhaps 756 or 1512 cores in a 42U rack. Near term, new processors will push core counts over 100 per 2U. This framework introduces many new possibilities for partitioning a server optimized for IoT infrastructure use.

Handling IoT workloads At the sensor tier, calculating data rates for a given sensor and sampling frequency is straightforward. Most IoT applications scale out by adding sensors. This can be more sensors of the same type at a location, new sensors at a new geographic location, or new sensor types for capturing different variables. 24

Gateways present more complexity at the second tier. They can scale out as new geographic locations are added, supporting entirely new sensor clusters. As sensors multiply on an existing gateway, they may surpass its processing capability, creating a scale-up need for a larger platform. Adding sensors of varying protocols requires more protocol conversion. More pre-processing or localized sensor fusion algorithms also increase workload. Another factor is the role of advanced middleware, such as publish-subscribe (pub-sub). Physical connections for sensors are usually in hub or mesh topology, aggregated into a gateway. Virtual connections between sensors, gateways, and infrastructure may be more complex. Pub-sub networks such as DDS and MQTT are suited for event-driven models, where a sensor publishes readings to any number of interested subscribers anywhere on the network. Pub-sub models usually feature guaranteed message delivery and low latency. Aggregated IoT traffic might suggest a scale-up server approach for the infrastructure, with bigger platforms to handle more streaming from gateways. Converged modular servers offer a unique approach to scale. Dozens of processor cores with each added platform create more architectural possibilities for dealing with varied workloads.

õõ

Rather than an incidental task run occasionally, a core dedicated to

IoT Network Infrastructure

provisioning, management, and security can constantly check on the integrity and health of the IoT network.

õõ

Dedicated cores can service a gateway, processing of incoming data.

õõ

Even finer granularity is possible with cores dedicated to individual sensor data streams.

õõ

Mixing core types, including CPU, GPU, and DSP, enables more effective signal processing.

Any of these steps could help with realtime responsiveness to data or events on the IoT network. The most intriguing possibility for the infrastructure tier is dedicating clusters of cores for realtime, predictive analytics. Instead of simply acting on events as they unfold and analyzing data later, predictive analytics can look for trends and patterns that suggest a future event. For instance, instead of scheduled maintenance on running equipment, condition monitoring may suggest the likelihood of an upcoming failure or determine that all is well and postpone maintenance until necessary. Big data platforms also enter the picture. Hadoop is an open-source, scalable framework for distributed data processing and storage. Its key benefit in an IoT context is that data can be stored flexibly, either in a single, very

large file or in many smaller files – and processed with system-wide visibility. It scales linearly with processing nodes, and with a low-latency fabric interconnect Hadoop shines for non-CPU-intensive tasks. Hadoop is also adept at dealing with both structured and unstructured data. Real-time IoT data streams are often structured data, a flow of sensor readings and timestamps. Enterprise data such as ads triggered by beacons, item purchase history, warranty information, maintenance diagrams, mapping data, photos and video, user manuals, and more is often unstructured. Combining the two enables rich analysis providing breakthrough insights and delivery of information tied to the context of events. Microsoft has evaluated Hadoop scale-up versus scaleout for IT infrastructure. Their findings are that most actual jobs are sub-terascale instead of petascale, and scale-up performance becomes a competitive option. One conclusion is more snugly-coupled cores in a single server perform better, as opposed to the same number cores distributed loosely in clusters across a cloud. What they describe as a scale-up server could in fact be a modular server featuring up to 72 cores – such as the Kontron SYMKLOUD Series – with Ethernet fabric interconnect. For an IoT infrastructure, a hybrid cloud built around converged modular servers helps scaling in all directions. 25

Redrawing boundaries A hybrid cloud approach to IoT infrastructure featuring modular servers also helps free application developers from many other boundaries.

õõ

On a private modular server, virtualization environments are fully controlled – everything running on the platform is known. This opens the potential for network functions virtualization (NFV), reducing both capital expenditures and lifecycle costs as appliances are consolidated.

õõ

Developers can select and deploy the right software approach. Operating systems can mix and match between real-time, Linux, or Windows. Installing and configuring middleware such as OSGi, DDS, MQTT, or other services is unconstrained on a private platform in the hybrid cloud.

õõ

õõ 26

Manycore processing and fabric interconnect mean the ability to ingest and process more IoT data and provide faster and more detailed analytics. This can lead to improvements or cost reduction in existing services, or incremental revenue from new service offerings. The highest potential of the IoT lies in monetizing analytics and

data, and creating powerful new business models. With a hybrid cloud in place, data assets can be developed and shared or fully protected. Ability to grow and adapt the infrastructure quickly means improved competitiveness. All these benefits apply not only to OEMs developing IoT applications, but also to cloud service providers (CSPs) looking to extend their existing machine-tomachine (M2M) offerings or break into IoT services. A hybrid cloud running on converged modular servers offers better scalability, improved rackspace density, reduced power consumption and cooling requirements, and flexibility to target IoT application needs more precisely.

Hyperconnecting the IoT The deployment of converged modular servers in hybrid clouds is just part of Kontron’s overall strategy in hyperconnecting the IoT. With unique experience in both industrial computing and telecom/datacenter solutions, Kontron teams have experience with all the aspects needed for end-to-end success in IoT applications. Kontron is a Premier Member of the Intel Internet of Things Solutions Alliance. This means Kontron’s customers have access to the latest Intel technology combined with extended lifecycle support for embedded applications.

IoT Network Infrastructure

About Kontron Kontron, a global leader in embedded computing technology and trusted advisor in IoT, works closely with its customers, allowing them to focus on their core competencies by offering a complete and integrated portfolio of hardware, software, and services designed to help them make the most of their applications. With a significant percentage of employees in research and development, Kontron creates many of the standards that drive the world’s embedded computing platform, bringing to life numerous technologies and applications that touch millions of lives. The result is an accelerated time-to-market, reduced total cost of ownership, product longevity, and the best possible overall application with leading-edge, highest reliability embedded technology. Kontron is a listed company. Its shares are traded in the Prime Standard segment of the Frankfurt Stock Exchange and on other exchanges under the symbol “KBC.” For more information, please visit: www.kontron.com. Kontron  www.kontron.com

@Kontron  www.linkedin.com/company/kontron  www.facebook.com/kontron  plus.google.com/+kontron/posts  www.youtube.com/channel/UCXkp_1gJbG0Um1vzdowlqww  blog.kontron.com

References:

1. Amazon Elastic Compute Cloud. aws.amazon.com/ec2/. 2. Banerjee, Ari. “Why Hybrid Cloud Makes Sense.” Light Reading, October 30, 2014. 3. OMG Data Distribution Service Portal. portals.omg.org/dds.

Protecting the IoT â&#x20AC;&#x201C; Are you building with security in mind? By KORE Telematics

The Internet of Things (IoT) has taken center stage in our increasingly technological world. Connected devices are becoming more practical and affordable for mainstream consumers, as well as an integral part of many businesses. We trust machineto-machine (M2M) applications to transmit confidential and personal information, monitor valuable assets, and control mission-critical devices. However, as we are beginning to witness the limitless potential to save time, cut costs, increase efficiency, and improve quality of life, we are also made aware that with all these potential benefits, there is also potential for new instances of data vulnerability and security breaches. 28

IoT Security Considerations A recent study released by HP Security Research reviewed 10 of the most popular IoT devices that included some form of cloud service and mobile applications. The results revealed that an alarming 70 percent were subject to serious security vulnerabilities. Some of these concerns included insufficient authentication/password strength, lack of transport encryption, weak web interface credentials, and insecure software updates. As a growing number of players enter the market with new connected devices and applications, security will not be viewed as a point of differentiation – it will be an expectation. We want you to understand what you can do to meet, and even exceed that expectation. The following are five questions to consider prior to deployment that can help secure a connected application:

1. Data encryption – Is your data protected? The aforementioned report suggests that up to 90 percent of M2M devices collect some kind of personal information, which makes it critical that applications are able to keep this information confidential. Encryption is necessary for any M2M application transmitting confidential information through the network such as POS system (credit card information), mHealth (patient data) or usagebased insurance (GPS coordinates and vehicle information). While encryption may be widely practiced in many Internet applications, M2M

presents some unique challenges. At a glance, many developers may be inclined to use SSL for secure communications. However, this can be problematic in an M2M application due to the additional processing power and memory required in a device to support SSL, and the increased wireless data costs that are a product of the increase in network communications overhead.

90 percent of M2M devices collect some kind of personal information. One might also attempt to create a VPN tunnel from the device side in devices running a fully featured operating system (OS) like Linux. Unfortunately, device-side encryption may not always be practical in M2M. The most practical solution is to create a site-to-site VPN tunnel from the M2M operator to the backend server’s network. This allows for encrypted data transmission across the most vulnerable segment of the network path – the Internet. A site-to-site VPN also creates efficiencies by not increasing the amount of wireless data consumed and by offloading all encryption and decryption processing to powerful network appliances. 29

Before choosing a site-to-site VPN tunnel, a developer must assume that the networks of the mobile network operator (MNO) and M2M operator are trusted (more on that later), and be comfortable with the encryption algorithms used to secure wireless communications between the connected endpoint and the MNOâ&#x20AC;&#x2122;s systems.

that the SIM is not easily accessible. A stolen SIM could result in unexpected wireless data charges, or even worse, allow a hacker to have direct access to your backend application servers. In addition to secure hardware, you should also take steps to prevent access to your software systems. Consider

Even the best preventive security systems are not foolproof. 2. Controlling access â&#x20AC;&#x201C; Who can access your data/system? While encryption is demanded for private information, in some instances confidentiality may be far less important than access and authentication. For example, the data transmitted with a wireless command to open your car door may not be confidential, but it is critical that no unauthorized parties have access to unlock the door through that system. Security requires a methodical approach that leverages every element in the technology stack. Beginning with the OS and down through the hardware level, it is critical to understand that no single line of defense is sufficient for complete protection. M2M hardware should be designed with internal components that allow for wireless connectivity to be enclosed and protected. Ensure that devices with a removable SIM card have taken measures so 30

using secure over-the-air application updates. Data signing can also be used to ensure authenticity and integrity of transmitted data.

3. Monitor at every layer â&#x20AC;&#x201C; Do you know when something goes wrong? Even the best preventive security systems are not foolproof. It is important to have monitoring systems in place when an event has occurred. Once the event has been detected, a responsive action must be triggered to prevent any malicious use of the device or active SIM. A backend application should have functionality in place that can log abnormalities in the data it is receiving. If, for example, a device is programmed to intermittently send sensor data but inexplicably breaks pattern, the system should notify administrators and, if possible, block the device from communicating with the server. One

IoT Security Considerations

advantage of having the site-to-site VPN tunnel in place between the application server and the M2M operator is that the misbehaving device will have a fixed IP address, making it easier to isolate and block. Your M2M operator should offer alerting tools that can be used by the solution provider to assist with fraud detection and prevention. You may choose to correlate GPS with location and timestamp information to verify positioning data received in the backend system.

Some possible questions that should be asked as part of the security due diligence for an MNO or Internet provider include: 1. Are all servers and network components within the organizationâ&#x20AC;&#x2122;s network updated with the latest security patches and updates? 2. Is there a process in place to apply new patches and updates in a timely manner? 3. What model firewalls are used?

You might also consider monitoring for malicious interference using digitally signed data messages between a mobile device and an M2M server to identify altered messages, scanning frequency spectrum for international mobile subscriber identity (IMSI) catchers, or setting tampering alerts on hardware to trigger a server notification.

4. Is there an intrusion prevention system (IPS) in place?

4. Network Partners â&#x20AC;&#x201C; Are your network partners secure?

7. Are all security events logged? How long are those logs kept?

A successful and secure M2M application requires quality partners. The majority of M2M applications that rely on cellular connectivity transmit data over three networks: the MNO, the M2M operator, and the Internet â&#x20AC;&#x201C; which are usually managed by three separate organizations. Application developers should perform their own due diligence to verify any networks managed by third parties meet the necessary security requirements.

8. Is there a SIEM solution in place to provide analysis and correlation of security events?

5. Is there a DDoS defense system in place? 6. Are background checks performed on all individuals with root access to servers and network devices?

9. How often are root passwords changed? 10. What systems are in place to secure and authorize access to physical servers and network components (PIN code, ID badge, biometrics, etc.)? 31

5. Secure Foundation – Are you building with security in mind? Make sure your M2M application has a strong foundation by building with security in mind. Decide early that security will be a priority. If possible, assign at least one member of the development team to be focused on the security of the application. This person should work to identify risks and recommend solutions to avoid them. It is recommended that this individual obtain an industry standard security certification such as the certified secure software lifecycle professional (CSSLP) certificate.

of your web interface, reviewing your network traffic, analyzing the need of physical ports, as well as assessing authentication and interaction of devices with the cloud and mobile applications.

It is also important to establish good protocol for internal security and regular testing. Testing might include scanning

Security should be a key element of your product design and management. If you have any questions on how to improve your overall level of IoT security, contact KORE Wireless at contact@korewireless.com. KORE Wireless  www.koretelematics.com

@KORETelematics  www.linkedin.com/company/kore-telematics  www.facebook.com/korewireless  plus.google.com/+Koretelematics/videos  www.youtube.com/user/KORETelematics 32

IoT EVOLUTION IoT Security Considerations

Developers Conference Powered by Embedded Computing Design

August 17-20, 2015 Caesars Palace Las Vegas, Nevada

Design and Develop IoT Solutions to Transform Your Business It is estimated that there will be nearly 5 Billion connected devices in 2015. As the IoT continues to evolve, unprecedented demand will be created for developers who can design and develop systems that monitor and manage these devices.

•

IoT Security

•

IoT for Automotive

•

Industrial IoT

•

Wearables

•

M2M

•

Cloud

•

Microcontrollers

Providing secure connected products By ThingWorx, a PTC Business

The ThingWorx platform delivers the highest levels of security, performance, and availability, helping customers with best practices for an overall security design.

Security is a primary concern of ThingWorx customers â&#x20AC;&#x201C; especially device manufacturers and end customers that deliver and use connected products. These customers demand a proven solution that protects them and their customers against hackers, malware, and unsafe operations. In addition, they require a solution that supports interaction with their deployed intelligent devices in an IT friendly fashion, and extends their current network security model so that they can meet critical certification and compliance requirements. Since the manufacturerâ&#x20AC;&#x2122;s devices are connected to their customer networks, the end customers also need to be assured that the connected product supports their security model, provides granular control over user access, and offers easy-to-use audit and tracking capabilities.

commitment to the security of our services for our customers. The ThingWorx Platform addresses the end-to-end security requirements of manufacturers and their end-customers while enabling them to grow revenue, reduce costs, increase customer satisfaction, and manage risk without additional IT burden and investment.

Leading device manufacturers across many industries are delivering business-critical connected products with the ThingWorx Platform delivered either on their own premises, or via our SSAE 16/SOC 2 audited on-demand centers with an ISO 27001:2013-certified systems and operations group that has a

ThingWorx incorporates an end-to-end security strategy covering all levels, including network, application, user, and data security, as well as through security training for its employees and by having dedicated certified information systems security professional (CISSP) personnel on staff. The primary ThingWorx

Because customersâ&#x20AC;&#x2122; devices may track patient records, financial data, and other types of private and protected information, security and compliance capabilities are among the most important requirements evaluated in any connected product solution. IoT projects are particularly sensitive to security issues because an attacker can spy on unprotected machines and cause physical damage by executing malicious commands.

IoT Data Security

datacenters are ISO 27001:2013 and SafeHarbor certified. As more and more of your infrastructure is plugged into the LAN/WAN/Internet, security must be one of the foremost tenets of the design of your systems. An overall security design must be a combination of software and hardware infrastructure, plus pervasive security policies enforced by business practices. This white paper discusses the security measures built into the ThingWorx Platform and best practices for a secure implementation to help you fit ThingWorx solutions into your overall security design.

Overview The ThingWorx Platform was built from the ground up with security in mind. While collaboration implies value creation through open interaction amongst members of a community, the business focus of the platform requires strict security and privacy. This is needed to comply not only with business requirements, but regulatory constraints as well. By incorporating the latest in Internet standards and architecture, the ThingWorx Platform succeeds in creating a real-time, context-based collaboration environment while still maintaining a high level of data and user security. ThingWorx strives to address all of the key security concerns that are discussed in this document. To understand the security provisions of the platform, it is best to look at the individual components of the ThingWorx Platform and how they interact.

Two primary components of the ThingWorx Platform are the ThingWorx Server and ThingWorx Edge components, including the Edge MicroServer (EMS) and various software development kits (SDKs) referred to collectively as the EMS in the rest of this document. The Server handles user and device authentication, brokers communication between systems, people, and things in the solution landscape, and handles data transformation, data persistence, and business logic as necessary for the end user application. The EMS enables devices to securely communicate with the ThingWorx Server and be full participants in the solution landscape. The EMS, as indicated by its name, is not a simple â&#x20AC;&#x153;connector,â&#x20AC;? but allows intelligence and pre-processing of data to be moved to the edge.

Processes and Technology ThingWorx has a strong commitment to continued development and support of security processes and technology to ensure that it stays ahead of security issues and threats to data, intellectual property, and operations. ThingWorx has robust internal application security testing capabilities with a large team of trained security staff in-house. Frequent security testing is executed at the network and application level, for both the platform and the edge components. Additionally, network and application vulnerability testing using both internal and external tools are conducted, along with periodic internal and external security audits. 35

Secure design principles The ThingWorx development process follows secure software development best practices, which include:

õõ

A risk assessment – Initially, a high-level assessment to identify major risks, followed by other iterations examining all other risks. The security risk assessment reviews begin during the design phase and engagement lasts through launch to ongoing operations.

õõ

Security requirements definition – Conducted during inception and elaboration phases of projects to ensure that the resulting product will be highly secure to meet all customers’ security needs.

õõ

Formal design reviews – Conducted during and at the end of the design phase to determine whether established security requirements, security design concepts, and security-related specifications have been satisfied.

õõ

Security code reviews – Conducted throughout development to ensure that the code is implemented in conjunction with software development best practices, and that implementation does not stray from design.

ThingWorx Platform security features Authentication and authorization The ThingWorx Platform has an extremely granular security model to enable data isolation and service execution at any required level. The ThingWorx Platform supports HTTP authentication, which requires a user to establish a web session using a username and password. If desired, the ThingWorx Platform can delegate the authentication of credentials to a Lightweight Directory Access Protocol (LDAP) system, allowing the LDAP system to manage password policies such as password expiration, account lockout, password dictionary use, password history, and password strength. In addition, the ThingWorx Platform has a pluggable authentication model, which allows customers and partners to implement their own business process-specific authentication model. This extensibility also enables the ThingWorx Platform to release new authentication modules independently of major releases. The ThingWorx Platform can support standard industry mechanisms such as the Security Assertion Markup Language (SAML), and single sign-on (SSO) integration from other tools such as Salesforce.com, SAP, and others. 36

IoT Data Security

The ThingWorx Platform has an access control list (ACL) model that allows the administration of ThingWorx Platform authorization to a very granular level. The ThingWorx Platform has overlaying levels of security that can be applied. Access control can be granted or denied at the most granular level, such as specific read or write access to a single Thing Property. In case of a conflict, the most restrictive security setting is honored. There are separate permission settings for Design-Time and for Run-Time. Both Design-Time and Run-Time permissions can be set for any entity in the system. All entities follow essentially the same model. Design-Time permission settings are as follows:

õõ õõ õõ õõ

Create entity Read entity Update entity Delete entity

Run-Time permission settings are as follows: (Figure 1)

õõ õõ õõ õõ õõ

Property Read Property Write Event Execute Event Subscribe Service Execute

••• Figure 1 Pictured here are the Run-Time permission settings of the ThingWorx Platform. 37

Both Design-Time and Run-Time permissions can be set at the following levels:

õõ

At the collection level. For example, it is possible to grant the ability to read all properties for all Things in the system. This can then be overridden at lower levels.

õõ

At the ThingTemplate level. ThingTemplates are a way to combine shapes (multiple sources of data) that allows you to add additional property services, subscriptions, and events to create a unique template that allows for the rapid creation of any new thing. ThingTemplates are unique in that there are also ThingTemplate Instance permission settings that may be set and inherited by all Things that are implemented Server Security using that Template. These also can õõ Uses standard PKI infrastructure for be overridden at the Thing level. certificate validation

õõ

At the Thing Level. For example, Property Read access can be given for all Properties of a Thing.

õõ

At the specific Thing Property, Service, or Event level. For example, a specific grant or deny can be assigned for a specific Thing Property Read or for a specific Thing Service Execution.

Matrix multi-tenancy

õõ

TLS 1.x support

õõ

Supports both client and server certificate validation

õõ

128-bit AES encryption or higher (configurable set of ciphers supported)

õõ

FIPS-validated ciphers supported

õõ

Fine-grained visibility, access, and permissions model

Matrix Multi-tenancy is a patent pending õõ Integration into LDAP/Active Directory innovation that allows entity visibility or other authentication backends to be defined in a series of overlapping “Organizations.” Organizations are strucõõ AES-encrypted data fields supported tures that allow isolation of parts of the ThingWorx Model. An organization is made up of a hierarchical set of organization units (Figure 2). The hierarchy looks like an organization chart. You can then assign a special type of permission, named Visibility, to entities in the Model (Figures 3a and 3b, page 40). Visibility is a key form of access control. If an entity is visible to members of an organizational unit, then only those members have access to the entity, and the underlying, granular security model determines what specific interaction any users that are members of that organization unit may have with a specific asset. If a user in the system is not granted Visibility, then that asset essentially does not exist within that user’s domain. That user cannot see the asset, cannot list it, cannot interrogate that asset’s namespace, or know that it exists at all. 38

••• Figure 2 Organization view is a hierarchical set of organizational units that can be assigned various permissions using the ThingWorx Matrix Multi-tenancy solution. It is possible to define the Visibility rules in a way so that you can make specific Things (such as specific physical assets) only visible to a single organization, or you can allow two or more organizations to be able to see an asset.

Security logging subsystem The ThingWorx Platform has a full set of logging services for the application layer, the script engine, for configuration changes, and for security. All logins, successful or not, are logged and can be monitored. In addition to the standard security logging, there are a number of security-related events that may be used to capture additional information on system usage. These are in addition to other types of events that can be triggered within the ThingWorx Platform that are more application oriented, such as data change events or threshold violation events. Users can log related event data for monitoring purposes. There are separate events for file transfers between edge devices and the server, and for remote desktop sessions to edge devices. For each event, you can create a subscription to log data. Each event data package has the initiator (from), receiver (to), time, data size, bytes transferred, event type, and error message, if any, plus additional transport information. Each file transfer has the following different types of event messages that may be subscribed to and logged:

õõ õõ õõ õõ

Start of file transfer Receiving of file File sent File transfer completed 39

••• Figures 3a and 3b ThingWorx Matrix Multi-tenancy (3b) is a permissions-based visibility solution that differs from traditional multi-tenancy (3a) by providing more fine-grained access control over specific members of an organization or organizations. Each remote desktop, or tunnel session, has the following types of event messages that may be subscribed to and logged:

õõ

Start of remote desktop session

õõ

End (complete) of remote desktop session

Encrypted storage of all sensitive data The ThingWorx Platform uses encrypted storage for sensitive data. Passwords are stored encrypted at all components within the ThingWorx solution. This includes passwords stored at the platform for user accounts, and passwords

IoT Data Security at the edge components for use in connecting back to the server. Additional data can be encrypted for persistence, if desired, through available encryption functions.

Recommended and supported application backup strategy ThingWorx has specific services to support complete application backup. In addition, there are content services to export configuration, model, and data objects, promote them through the landscape, and import those objects onto other servers. Customers running in the ThingWorx datacenter will have backups run periodically without the need to manage them.

Protection against common vulnerabilities

due to the use of prepared statements and parameter validation. As demonstrated in other sections of this paper, ThingWorx follows best practices to ensure that other common vulnerabilities such as broken authentication, missing access control, and sensitive data exposure do not occur. ThingWorx has procedures in place to identify security vulnerabilities in then-current releases of a commercial product, and provided a customer maintains a current maintenance/support plan, ThingWorx will provide updates for security flaws that require remediation in standard product releases or maintenance updates. Customers then need to implement the latest release or update following documented guidelines in order to apply security updates.

Backdoor protection

ThingWorx software products are designed based upon industry secure coding practices (such as Microsoft’s Software Development Lifecycle, Cigital Software Security Touchpoints, OWASP standards, or SANS Top 10, where relevant). ThingWorx proactively protects against the exhaustive list of items that includes injection attacks and cross-site scripting (XSS). Statements passed into the ThingWorx backend are parameterized. Internal commands cannot be submitted through a URI call, protecting your IoT infrastructure.

All ThingWorx API calls are public, utilizing well-established security processes. There are no secret “backdoor” APIs utilized for administrative use. All APIs require authentication and there is no ability to turn off encryption and convert encrypted data to plaintext. ThingWorx applications utilize the same APIs as ThingWorx customers do, following security best practices to not have secret ways to access data.

SQL injection and other similar attacks are mitigated in the ThingWorx architecture

The standard communication protocol recommended for clients to the web server

Support for Transport Layer Security

is HTTPS (Secure Sockets Layer (SSL)), so that all data transmission over the wire is encrypted. The standard communication protocol from the EMS component to the server is the industry standard WebSockets protocol (RFC 6455), which runs on top of the secure and encrypted Transport Layer Security (TLS) protocol. The EMS components also support HTTPS if that communication is required for specific scenarios (note: ThingWorx follows industry best practices and utilizes TLS exclusively over the insecure SSL protocol).

Additional security features In addition to the transport layer encryption, all files that are transferred between the edge and the platform (bi-directional) are encrypted before transfer and then decrypted after receipt. File MD5 hashes are calculated to ensure complete and successful file transfers, as well as that the file has was not tampered with.

(AES) 128- or 256-bit encryption, which are the same standards used in online banking applications. FIPS-compliant encryption algorithms are supported for certain regulated environments.

õõ

Multilevel authentication is built into the underlying ThingWorx AlwaysOn binary protocol – Once a WebSocket is established, the connecting device must provide credentials in order to be allowed to communicate with any other entities in the system.

õõ

Firewall Transparency – The only connection required is a single established connection from the EMS to port 443 on the ThingWorx server. That connection can be direct to on site HTTP proxies and authenticating proxies for an additional layer of end customer monitoring and control. No listening ports need to be opened to the outside world from the edge device.

õõ

Auditing – All file transfers and application tunneling (such as remote desktop) sessions are audited both at the server and on the edge device.

ThingWorx Edge MicroServer The EMS and associated SDK components act as an interface between intelligent devices and the ThingWorx server. The EMS shares information and data with the server using the Internet Engineering Task Force (IETF) standard WebSockets protocol. The key security highlights of ThingWorx edge connectivity are as follows:

õõ 42

Based on well-known industry standards including TLS 1.2 with Advanced Encryption Standard

The EMS also includes a set of SDKs for device software component development. The support languages/platforms include Java, C, .NET, and native SDKs for iOS and Android, with additional language SDKs to be provided over time. These SDKs allow customers and partners to leverage the security, efficiency,

IoT Data Security

and communication management available in the ThingWorx WebSocket-based EMS while providing their own device- or business process-specific functionality.

File transfer and application tunneling with the ThingWorx EMS The ThingWorx Platform supports file transfer and application tunneling in a similar fashion. By using the encrypted WebSocket channel to establish a onetime use, dedicated channel between two users, it ensures a secure, audited connection. Unlike other remote desktop or application tunneling solutions, the ThingWorx Platform uses end-to-end 128-bit encryption of the application or file data being transferred between the server and the edge device. In addition, the one-time use encryption keys are independently calculated at each end of the connection, ensuring that the keys are never transferred over the Internet. Because it uses the same WebSockets communication model, all communications are firewall-transparent. The connections are initiated from the edge device inside the firewall out to the ThingWorx server, thereby removing the need for any open listening ports on either end of the connection. Finally, all tunnel connections are audited with the initiator, target, and start and end times and can be logged as desired. Remote desktop applications offer additional security. The remote access server

can be set up such that inbound remote desktop requests must be acknowledged and approved by an operator at the device in question, and the entire session can be recorded for later playback.

Secure and scalable ondemand centers ThingWorx on-demand center operations team’s process is certified to meet the ISO Standard 27001 Information Security Management System (ISMS) framework. These well-documented operational standards include the typical components of:

õõ

Incident management

õõ

Security monitoring

õõ

External audits validating our security methodology and processes

õõ

Security awareness and training programs

õõ

Risk management and business continuity planning Change and configuration management

õõ õõ

Capacity planning

õõ

Proactive threshold monitoring of core resources

Given each of these processes is governed by the ISO Standard 27001 ISMS and aligned with Information Technology Service Management (ITSM) 43

best practices, ThingWorx customers can be assured their products and data are secure. The ITSM process has been thoughtfully designed as a component of the Information Technology Infrastructure Library (ITIL) standard. ThingWorx’ secure hosting partner, CenturyLink, delivers the following advantages:

õõ

Auditable security SSAE 16-certified – Your valuable IT assets are safeguarded against manmade and natural disasters. Our datacenter locations are designed to withstand extreme weather events and prevent unauthorized contacts from accessing your datacenter space. CenturyLink offers a wide range of managed security services that help your organization prevent potential data compromises, network breaches, and unauthorized system access.

õõ

Robust protection from physical harm – CenturyLink prides itself on building advanced, cutting-edge, multi-level physical security into every datacenter to ensure that your infrastructure isn’t compromised. CenturyLink also provides an extensive array of sophisticated managed security services that supplement our standard security measures.

õõ

Standard datacenter physical security measures.

õõ

On-premise security guards.

õõ

Security systems on the building exterior – Including cameras, false entrances, vehicle blockades, customized parking lot designs, bulletproof glass/walls, and unmarked buildings

õõ

Biometric systems – Including palm scanners

õõ

Numerous security cameras with digital recorders

õõ

Portals and person traps – Authenticate only one person at a time

õõ

Power – To protect your technology investment and deliver the infrastructure availability you require, we utilize power management, power monitoring, advanced fire suppression, and HVAC systems.

CenturyLink datacenters are designed to prevent “single points of failure” that can reduce the availability of your infrastructure and impact the quality of end users’ experiences. CenturyLink’s most critical responsibility to customers is to keep their infrastructure functioning despite potential disruptions, such as lengthy power outages. 44

IoT Data Security To maintain power availability, all of CenturyLink’s datacenters utilize high-capacity, redundant generators that guarantee power availability even during metro-wide power outages. And, due to short-notice diesel generator refueling contracts with multiple vendors at each datacenter location, the electricity backup capabilities are extensive. This permits CenturyLink to supply necessary power to organizations that require around-the-clock infrastructure availability, such as online retailers, global financial services companies, and healthcare providers.

õõ

HVAC. The CenturyLink datacenters allow for proper heat dissipation, permitting their sites to operate within an acceptable temperature range. To maintain the flow of air conditioning to the datacenter infrastructure, CenturyLink employ’s redundant (N+1) HVAC units within each of their locations. The HVAC units are powered by normal and emergency electrical systems in order to maintain their availability. Additionally, cold water tanks are installed that keep air conditioning units functioning when there is a requirement to transition from direct power to generator power during emergencies.

Connectivity Security õõ Standard PKI infrastructure for certificate validation

õõ

TLS 1.x support

õõ

Supports both client and server certificate validation

õõ

Password-protected PEM key file storage

õõ

128-bit AES encryption or higher

õõ

Fire suppression. CenturyLink employs the õõ FIPS-validated ciphers supported latest fire suppression methods. To detect smoke from the earliest stage of combustion, õõ Encrypted configuration file entries fire suppression systems are installed at each of Savvis’ datacenter locations. The systems utilize state-of-the-art “sniffer” systems, augmented by heat detection and dry-pipe sprinkler systems.

õõ

Seismic engineering. CenturyLink has performed extensive seismic engineering to keep potential disasters from interrupting business operations. In regions that are prone to seismic activity, they provide the necessary level of bracing. Seismic isolation equipment is installed to cushion facilities against movement, in addition to installing earthquake bracing on all equipment racks. And, racks at all of CenturyLink’s datacenters — not just those in traditional earthquake zones — are anchored to the concrete slab below the site’s raised floor.

õõ

Network connectivity. CenturyLink high-availability network and carrier connections provide strong global reach, allowing customers quick and convenient access. Colocation services are offered in North America, Europe, 45

and Asia, permitting the addressing of specialized business continuity and disaster recovery objectives. CenturyLink leverages geographical diversity to provide customers with failover and redundancy capabilities with many of their services.

õõ

Industry leadership. CenturyLink been offering secure hosting services to companies for more than a dozen years, and continues to build on this expertise in areas such as cloud computing and beyond. This includes membership in:

õõ

International Standards Organization (ISO)

õõ

PCI Standards Council

õõ

Information Security Audit and Control Association (ISACA)

õõ

Information Systems Security Association (ISSA)

õõ

Institute of Electrical and Electronics Engineers (IEEE)

õõ

Computer Security Institute (CSI)

Application security perspective – Above the infrastructure Manufacturer’s requirements for connected product security The ThingWorx Platform meets stringent security requirements of manufacturers and end customers so that they can achieve broad adoption and maximum use of connected products, instilling confidence that their connections are secure and private. Some of the most common manufacturer requirements include:

õõ

Enterprise-proven design – Connecting any computer to the Internet raises security concerns, and connecting intelligent devices is no different. Whether hackers are trying to harm a device with corrupt data or viruses, steal data traveling between the device and manufacturer, or gain unauthorized access to critical information, a connected product solution must guard against these and other threats.

õõ

Support for multiple devices – Manufacturers need to securely support a nearly infinite number of device types and complex customer configurations without requiring major end user changes.

IoT Data Security

End-customer requirements for connected products Intelligent devices are connected to your customers’ networks. Each customer has their own security policy and network protection in the form of firewalls, proxy servers, and addressing schemes. A device connected to their network will be protected behind these layers of security. If a connected product offering requires changes to your customer’s network protection, it will likely fail to gain acceptance. Because of this, it is important to consider the requirements of the end customer, including:

õõ

Maintain current security model – The manufacturer’s device must support the way that the organization manages security operations, policies, or procedures, and should adhere to accepted industry standards.

õõ

Control user access – In line with the customer’s security model, the manufacturer’s device must provide the customer — not the manufacturer — with granular control and set policies on what actions can be performed on the device, such as data collection and software updates, and when those actions can be performed. These policies need to be centrally defined for all devices at a customer location.

õõ

Audit and track activity – Policy and regulatory compliance requirements dictate that the system must make auditing and tracking all user and administration activity easy.

The ThingWorx Platform delivers the performance, flexibility, and scalability required to meet the needs of the broadest range of device manufacturers by providing the widest range of data protection safeguards and security features

ThingWorx, a PTC Business  www.thingworx.com

@ThingWorx  www.linkedin.com/company/thingworx  www.facebook.com/PTC.Inc 47

Mastering Industry 4.0 connectivity By congatec AG

Currently around 85 percent of industrial embedded systems are standalone systems without Industry 4.0 connectivity. congatec, a leading manufacturer of computer-on-modules (COMs) and ODM partner of many industrial OEMs, has developed an Industry 4.0 definition for COM Express modules to make it easier for machine and plant manufacturers to provide Industry 4.0 connectivity. 48

Standards for Industry 4.0

Industry 4.0 merges modern information and communication technologies with industrial processes, devices, and products. This means that the processes, devices, and products need to either integrate ICT technology or have access to ICT systems. Today, many industrial devices and machines are already operated and controlled via IT-based embedded systems. However, up to 85 percent are still missing a communication interface with the cyber-virtual cloud systems that convert the individual bits and bytes into the big data value-add promised to the users of Industry 4.0.

Gateway standardization required At the device, machine, and plant level, OEM application developers therefore often call for the migration from embedded IT systems to embedded ICT systems. This requires an embedded computing platform that is also able to master Industry 4.0 communications tasks. At present, there are no embedded boards that offer standardized integration of industrial-grade wireless interfaces. OEMs that have opted for COM standards because of their specific interface requirements now benefit from a major advantage of the modular design: SIM card slots or a Mini-PCIe slot for suitable SIM expansion cards that are relatively simple to integrate into carrier boards. Important connectivity standards such as Wi-Fi, Bluetooth, ZigBee, SIM, RFID, and NFC can be integrated directly or via Mini-PCIe expansion cards on the carrier board.

COM Express for Industry 4.0 The COM Express standard is particularly well suited for Industry 4.0 applications because it is not only optimized for industrial use, but it is also suited for many other

â&#x20AC;˘â&#x20AC;˘â&#x20AC;˘ Figure 2 This concept platform represents a 5th generation Intel Core processor-based COM Express Compact module and carrier board. 49

embedded solutions. In addition, most industrial OEM designs utilizing COMs are currently based on this world-leading specification. COM Express also supports all major x86 interfaces, covers an extremely wide performance bandwidth ranging from low-power x86 Intel Atom or AMD Embedded G-Series SoCs to Intel Core processors, and offers maximum security thanks to differential signals and robust high-frequency connectors. The PICMG module standard was first released in 2005, comes in three different sizes (Basic, Compact, and Mini), and has evolved to its current version, 2.1. Key milestones are the release of the new Type 6 and Type 10 pinout specifications (including USB 3.0 and DDI) and the official adoption of the credit card-sized COM Express Mini format (84 mm x 55 mm) in 2012. Two highly useful sources of information for designers include the COM Express Carrier Design Guide, which specifies many details of carrier board development, and the Embedded Application Programming Interface (EAPI) specification, which sets out how to address the boards. Together the two provide a high degree of standardization for communication at the board level. This level of standardization is something that has yet to be developed and agreed upon in many other areas of Industry 4.0, machine-to-machine (M2M), or Internet of Things (IoT) communications.

Unified communications The COM Express specification offers the essential building blocks needed to develop Industry 4.0-ready embedded designs. A core task is to regulate the communication and data exchange in Industry 4.0 applications. Many points, such as inventory, health, and maintenance management, are in principle covered by the EAPI specification, including GPIO management, for example. However, additional elements are required to develop reliable Industry 4.0 gateways. Manufacturers such as Intel have recognized this and dedicated resources towards the creation of the Intel Gateway Solutions for the IoT. This comprises a validated Linux-based software package from Intel, Wind River, and McAfee that gives OEMs access to a set of functions for embedded device connectivity, communication, and management. The package includes McAfee Embedded Control, which among other things includes dynamic whitelisting to prevent the execution of unapproved code while at the same time allowing policy-based updates. Such an integrated package provides OEMs with a complete software solution all the way through to the operating system level. 50

Standards for Industry 4.0

IP protection By adding protection for their own application software, via a hardware-based encryption engine, for example, developers can also protect their own code against piracy and misuse. The Sentinel HL Chip from Gemalto (formerly SafeNet) can be integrated onto COM Express carrier boards to provide what is currently the highest level of protection against malicious hardware attacks like differential power analysis (DPA) and reverse engineering using electron microscopy. To integrate the customized interfaces and devices generally referred to as peripherals by IT experts, OEMs will need a variety of additional functions from specific COM Express-based designs. The combination of reliable hardware and a consistent software package, starting with the firmware and operating system, forms a “root of trust” for all types of Industry 4.0 and IoT applications. Ultimately, however, it is up to the hardware developer to integrate all the desired functions into their specific design. Access to the appropriate specifications and design guides considerably helps facilitate these design-in tasks.

Market leader shows the way With the COM Express Industry 4.0 definition, congatec brings a new dynamic to COM Express and is setting the direction for carrier board designs. The objective is to offer an alternative to proprietary solutions for Industry 4.0 connectivity, and to increase the COM Express clout by further developing the specification further to make it the leading industrial module standard. congatec AG  www.congatec.com/us

 www.facebook.com/Congatec  plus.google.com/108340862355356349827/posts  www.youtube.com/user/congatecAE

E M A G