Wibu-Systems Blog https://www.wibu.com/blog.html Mon, 10 Dec 2018 06:30:20 +0100 Mon, 10 Dec 2018 06:30:20 +0100 t3extblog extension for TYPO3 Is the Dongle Dead? Wed, 05 Dec 2018 11:23:00 +0100 https://www.wibu.com/blog/article/is-the-dongle-dead.html post-105 https://www.wibu.com/blog/article/is-the-dongle-dead.html Daniela Previtali Secure hardware-based license dongles remain the platform of choice for the ultimate in software protection against unauthorized usage or illegal tampering. Is the Dongle Dead? by Daniela Previtali 05-12-18

In today’s ISV world, a flexible software licensing strategy is the key to successful monetization and profitability. In the past, secure hardware-based license dongles were the platform of choice for the ultimate in software protection against unauthorized usage or illegal tampering of high-end proprietary applications. Today, along with the trend towards subscription licensing and software-as-a-service in many business arenas, end users are becoming more comfortable with software-based license activations or with cloud licensing implementations. Still, dongles (aka hardware-based license containers) remain at the top of the curve in software protection both in terms of performance and sales volumes. Wherever the ISV finds himself in the global transformation, it is incumbent upon him to work with a licensing solution provider who is capable of offering license containers that easily interface with the same licensing platform and leave the final choice to the end user. So where does that leave the hardware-based license dongle?

Based on our past and most recent experiences, dongles are still prevalent in the licensing mix as many ISVs are reticent to give up on the strengths of hardware-based licensing and their customers still ask them for the associated benefits, like a portable license. Not all of our customers are interested in implementing cloud or flexible software-based activation solutions and, while they may be pursuing these licensing options in the long term, many ISVs still see the value of secure hardware dongles for the same reasons they started using dongles in the first place.

Several years ago, we surveyed our customers and found these main reasons why they preferred dongles as their security method and they still hold true today:

  • License Portability – The license is on the dongle and is easily moved from one system to another.
  • License Recovery – The end user can self-restore a license to an existing or replacement dongle.
  • License Borrowing – Licenses can be lent out (to travelling engineers and salespeople, for example)
  • License Redundancy – Important in “Mission Critical” applications (Ex: Hot and Cold Stand-by licenses).
  • License Security – Prevents employees or others to use software illegally, even if it is unintentional.

More recently, dongles have been made available with flash memory options and smart card chips that vastly increase the robust security functionality. The built-in flash memory can be accessed like any disk and includes data partitions in different sizes. Dongles are now also available in many different form factors to meet specific industry needs, such as microSD and Compact Flash cards designed for use in industrial equipment and controllers that can perform in harsh embedded environments. In our CodeMeter dongles, for example, we build in a full complement of security functionality, including symmetric and asymmetric encryption, encrypted signatures and the storage of X.509 certificates.

CodeMeter dongles also offer an interesting feature in that they are multivendor-capable. This means each dongle can store licenses from different vendors in separate areas. Thus, the user needs only a single dongle to manage multiple vendors’ licenses. This is particularly attractive to suppliers of plug-ins and extensions. Larger license storage volume, driverless installation, secure offline license transfer, and firmware updates in the field, and additional mass storage via flash memory are other reasons why many ISVs are sticking with dongles.

If you are considering dongles as a licensing option for your applications, I invite you to join us in our upcoming Webinar, The Dongle is Dead – Long Live the Dongle, on Wednesday, December 12, where we will take a deeper look into the inner workings of CmDongles as well as alternative licensing strategies. Even if you can’t make the live event, register anyway and we’ll send you access to the recorded version that you can watch on-demand at your convenience. Also, if you want to dig deeper into the advantages and specifications of secure license dongles, download our whitepaper, CmDongle with Flash Memory in Practice, and you will learn more about security functions and several specific use cases across a variety of industries.

Software Security on the Defensive Tue, 06 Nov 2018 11:11:00 +0100 https://www.wibu.com/blog/article/software-security-on-the-defensive.html post-104 https://www.wibu.com/blog/article/software-security-on-the-defensive.html Rüdiger Kügler Recent reports in the U.S. indicate that military weapons and security systems offer the same vulnerabilities found in key infrastructure Software Security on the Defensive by Rüdiger Kügler 06-11-18

In the past few years, high profile cyberattacks to key Infrastructure have raised serious security concerns around the globe. These are just a few of the more prominent attacks:

  • Massive power outages in the Ukraine, resulting from a supervisory control and data acquisition (SCADA) cyberattack, left more than 200,000 people without power for several hours
  •  Hackers (thought to be Iranian) took control of a dam in Rye Brook, New York when they succeeded in accessing the core command-and-control-system, one of the first reported attacks to infrastructure by another nation
  • Hackers from North Korea attacked the Swift Global messaging system, used by banks to move trillions of dollars each day, resulting in a cyberheist of millions of dollars
  • Cyberattacks on a number of nuclear power plants across the U.S. and Europe emphasized concerns that malicious actors could weaponize critical infrastructure against the host country

Now, recent reports in the U.S. indicate that military weapons and security systems offer the same attack surface and exhibit many of the same vulnerabilities found in key infrastructure.

The U.S. Pentagon reported in 2016 that a communications system designed to pass secure messages between the U.S. Army’s portable radios and cellular networks around the globe was found to have more than 1,000 cybervulnerabilities, half of which had “a high potential of giving system access to an intruder.”

Furthermore, a recently concluded report from the U.S. Government Accountability Office (GAO) concluded that “nearly all” of the weapons systems in the Pentagon’s $1.7 trillion dollar purchasing pipeline have glaring cybersecurity holes, and that doesn’t include the vulnerabilities that may exist with older weapons systems that are still in operation.

Today, defense companies, are not only forced to prevent unfriendly governments from reverse engineering advanced technology and stealing Intellectual Property, but are required to protect against threats from attacks that could take human lives. As is the case in most cyberattacks, weak password management and software vulnerabilities are the most frequent causes that enable malicious actors to gain access to the system or the network and execute the exploits that were unimaginable just a few years ago, but clearly a danger today.

Security-minded companies like Wibu-Systems continue to advance software protection technology to adapt and stay ahead of ever-emerging threats. For example, our CodeMeter technology enables users to replace weak password-enabled mechanisms with cryptographic login technology using private keys and certificates that are stored in an ultra-secure dongle. We also strongly encourage our developer customers to continuously check for software vulnerabilities using available tools just as we do with our CodeMeter solution to mitigate the risks of introducing potential vulnerabilities into the software during development.

Sophisticated encryption technology, anti-debugging and reverse engineering mechanisms, secure boot protections, authentication protocols and other sophisticated techniques can all be applied to deploy the necessary levels of software security for military and any other application. These advanced protection and security technologies are proven and deployable today.

Trustworthiness in Industrial System Design Tue, 23 Oct 2018 11:51:00 +0200 https://www.wibu.com/blog/article/trustworthiness-in-industrial-system-design.html post-100 https://www.wibu.com/blog/article/trustworthiness-in-industrial-system-design.html Marcellus Buchheit The Trustworthy System Status Model helps designers plan a system that proactively prevent damaged, disastrous or permanently lost system status. Trustworthiness in Industrial System Design by Marcellus Buchheit 23-10-18

Trustworthiness in the context of an industrial system is a relatively new term intended to provide a better understanding of the meaning of trust in such a system and how this trust can be approached by the operational user as well as the planner and designer of the system.

As defined by the IIC in its recently released Industrial Internet of Things Vocabulary v2.1 document: “Trustworthiness is the degree of confidence one has that the system performs as expected. Characteristics include safety, security, privacy, reliability and resilience in the face of environmental disturbances, human errors, system faults and attacks.”

While industrial systems vary greatly in their purpose and scope, their stakeholders share an important common element, and that is a deep-rooted trust. For example:

  • The owners, investors and operational users trust that these systems work as specified, are profitable and flawless during their expected lifetime.
  • Neighbors, customers and employees trust that the systems are safe and do not threaten their health or create environmental hazards.
  • The government trusts that laws and regulations are fulfilled: e.g. patient privacy standards in a hospital, clean-air directives in a fossil power plant or public safety in an urban transportation system.

With expectations high, it is quite a challenge for system engineers to fulfill all of these principles of trustworthiness in the design and operation of industrial systems.

While most experts agree that the five trustworthiness characteristics and their interaction are an important goal for any industrial system design, there are ongoing discussions about whether a design which fulfills all requirements of trustworthiness can be automatically trusted by all parties.

Let’s take a brief look of why the notion of trustworthiness in industrial systems can be so complex in relation to the five trustworthiness characteristics as shown in the Trustworthiness Target Model above:

Humans are protected by privacy and safety, while security, reliability and resilience have no direct relationship in this area.

The Environment is exclusively protected by safety without other considerations involved.

The System is protected by security and to some degree by reliability to protect the system against damage or loss of components.

Finally, the system in Operation is manly shielded by security and reliability, while partially protected by resilience.

One of the key challenges to trustworthiness design is that none of the trustworthiness characteristics can be implemented as a separate technology and that the trustworthiness of an industrial system cannot be implemented by simply combining such technologies as the characteristics may support or interfere with each other.

One approach to addressing these challenges in industrial design is to employ a new classification of Trustworthiness Methods that are assigned to the system characteristics rather than the trustworthiness characteristics. In my article in the Fall issue of the IIC’s Journal of Innovation, I provide an in-depth look at these Trustworthiness Methods and introduce a new concept, the Trustworthy System Status Model (TSSM), to help designers plan a system that goes beyond the “normal” status and proactively prevent, by using specific Trustworthiness Methods, a system that has reached “disrupted” status from slipping into a “damaged or disastrous” status or even permanently lost.

I would enjoy your feedback on the concept.

The Security of DLTs Tue, 09 Oct 2018 16:36:00 +0200 https://www.wibu.com/blog/article/the-security-of-dlts.html post-103 https://www.wibu.com/blog/article/the-security-of-dlts.html Andreas Schaad The next frontier in DLTs is developing reliable interactions between events and data pushed into a distributed ledger and the physical world. The Security of DLTs by Andreas Schaad 09-10-18

On the 20th and 21st of September, the new "Secure Distributed Ledger and Contracts" Research Center was inaugurated by Prof. Sadeghi at the University of Darmstadt, Germany.

In his role as external research advisor to WIBU-SYSTEMS AG, Prof. Dr. Andreas Schaad represented Wibu-Systems among the 190 participants at this invitation only event.

With over 60% industry participation, this event targeted the core question about current business models using distributed ledger technologies (DLTs) as well as how to improve on the security of DLTs.

After the opening of the event by the Hessian state secretary Burghardt, talks were given by representatives from the German Federal Reserve Bank, the German BSI and Daimler Trucks on the current readiness level of DLTs. Overall, the perception was that there is still a long way to go. The German BSI pointed out that DLTs may violate current EU Data Regulation Policies by publicly storing data in an immutable fashion.

Prof. Asokan (Aalto University), Prof. Capkun (ETH Zurich) and Michael Steiner (Intel Labs) provided talks on hardware-assisted trust (Trusted Execution Environments - TEEs) to enhance DLTs. For example, SGX could be used to replace the current proof-of-work solving hash puzzles with a proof-of-elapsed time. Another practical example would be to use a TEE to address the problem of compromised wallets.

Representatives from Commerzbank and Bosch provided examples of current proof of concepts. Not surprisingly, these are still dominated by supporting scenarios from the banking domain (e.g. a real trading system based on the CORDA framework) as well as how to share identity management data between participants (e.g. based on Sovrin Technology, Verimi or Hyperledger Indy). In particular, Bosch addressed the economy of things (initially coined by IBM) and how DLTs could address the problem of platform monopolies by means of competition. One presented project was how CERTIFICAR uses Blockchain technology to store mileage data as well as other projects in the autonomous vehicle R&D space. However, overall there is a feeling that current DLTs are not ready yet to be used to build systems that have to remain stable for a an extended period.

The European Space Agency investigates using DTLs for securing the procurement and supply chain process as well as document management. More importantly, the question addresses how science data gathered from space crafts can be distributed in a controlled, transparent and ultimately public process. On a more futuristic scale, ESA is investigating with TU Darmstadt on using DTLs for advanced satellite communication protocols (e.g. to verify identities) - still keeping in mind the current practical limitations (i.e. CPU and memory consumption).

Another highlight was the talk by Michele Mosca (University of Waterloo / evolutionQ Inc.) on quantum attacks on blockchains - essentially pointing out that we need a next generation of quantum-safe algorithms as soon as possible as we may see the first real practical quantum computers to attack standard RSA as soon as 10 years (with a 1 in 6 chance of this prediction).

Stefan Teis from Brainbot Technologies AG talked about how to practically implement Blockchain technology and integrate it with the physical world (e.g. by means of collateralized tokens). A specific focus was put on Hyperledger Fabric as a private / consortium Blockchain as well as comparison with other frameworks such as Ethereum.

Final talks were provided by speakers from the Stuttgart Stock exchange and European Central Bank, who, for example, pointed out that with DLTs a stock exchange could focus again on its core expertise: that of an exchange. Banks in the future could act as quality gates, but overall this implies that the current players change their business models.

What should these talks, opinions and observations imply for the adoption of DLTs at Wibu-Systems? Overall, with its proven and trusted CodeMeter technology, Wibu-Systems could provide the missing link between interaction of DLTs with the physical world. This is a problem for which, so far, no adequate solution appears to be available:


  • How are events and data from a distributed ledger pushed to and reliably executed by a physical actor (machine)?
  • How is physically observed data pushed into a distributed ledger while maintaining its integrity?

These are some of the questions being addressed by Wibu-Systems and Prof. Schaad in a joint R&D engagement.


Encryption, Cybersecurity & Privacy Tue, 02 Oct 2018 08:03:00 +0200 https://www.wibu.com/blog/article/encryption-cybersecurity-privacy.html post-102 https://www.wibu.com/blog/article/encryption-cybersecurity-privacy.html Daniela Previtali A never-ending discussion between law enforcement and their ability to obtain useful crime evidence and the need for personal data to be protected. Encryption, Cybersecurity & Privacy by Daniela Previtali 02-10-18

BSA | The Software Alliance, a global software industry advocate, recently asserted their opinion on communications legislation being considered by the Australian Government. The Telecommunications and Other Legislation Amendment (Assistance and Access) Bill 2018 proposes new provisions that would allow Australian law enforcement and security agencies to gain assistance from key providers in the communications supply chain to increase their ability to collect evidence from electronic devices under Crimes Act search warrants. At the crux of the matter is the ability for law enforcement to break encryption code designed to protect personal data for the purpose of obtaining incriminating evidence useful to identify and arrest lawbreakers.

BSA Director Darryn Lim said, in a statement to itwire.com, that “BSA has urged the Australian Government to include in its encryption bill a judicial oversight and challenge mechanism in order to ensure that any new powers given to law enforcement are not abused.” In their submission to the Australian Government, the BSA further urged “continued engagement between the Australian government, policy-makers, and industry to ensure that the solution eventually adopted would balance the legitimate rights, needs, and responsibilities of the government, citizens, providers of critical infrastructure, third-party stewards of data, and innovators.”

The issue brought to the table in Australia shines a spotlight on a controversial topic with global implications. Undoubtedly, these discussions conducted by International governments, advocacy groups and technology companies will become more urgent as new cyberattacks and data breaches unfold.  BSA is encouraging the establishment of standards to govern how personal data is used. In their recently released Privacy Framework guidance for policymakers, BSA supports making collection and use of personal data more transparent, giving consumers more control over their personal data, enabling governance over data collection and use, providing robust security, and promoting the use of data for legitimate business purposes.

The Privacy Framework incorporate ten components:

  1. Transparency: Organizations should provide clear and accessible explanations of their practices for handling personal data, including the categories of personal data they collect, the type of third parties with whom they share data, and the description of processes the organization maintains to review, request changes to, request a copy of, or delete personal data.
  2. Purpose specification: Personal data should be relevant to the purposes for which it is collected and obtained by lawful means.
  3. Informed Choice: Organizations should provide consumers with sufficient information to make informed choices and, where practical and appropriate, the ability to opt out of the processing of personal data.
  4. Data Quality: Personal data should be relevant to the purpose for which it is used and, to the extent necessary for those purposes, should be accurate, complete, and current.
  5. Consumer Control: Consumers should be able to request information about whether organizations have personal data relating to them and the nature of such data.
  6. Security: Organizations should employ reasonable and appropriate security measures designed to prevent unauthorized access, destruction, use, modification, and disclosure of personal data based on the volume and sensitivity of the data, size and complexity of the business, and cost of available tools.
  7. Facilitating Data Use for Legitimate Business Interests: Privacy frameworks should facilitate the use of data for legitimate business purposes.
  8. Accountability: Organizations should develop policies and procedures that provide the safeguards outlined in this framework.
  9. Legal Compliance and Enforcement: Organizations that determine the means and purposes of processing personal data should have primary responsibility for satisfying legal privacy and security obligations.
  10. International Interoperability: Privacy frameworks should enable and encourage global data flows, which underpin the global economy.

You can read the entire framework document here.

Permeation of Trust in IIoT Systems Tue, 25 Sep 2018 11:51:00 +0200 https://www.wibu.com/blog/article/permeation-of-trust-in-iiot-systems.html post-99 https://www.wibu.com/blog/article/permeation-of-trust-in-iiot-systems.html Marcellus Buchheit Trustworthiness is the degree of confidence that the IIoT system performs as expected in terms of safety, security, privacy, reliability, and resilience. Permeation of Trust in IIoT Systems by Marcellus Buchheit 25-09-18

In 2016, the Industrial Internet Consortium gained agreement upon an understanding of the term “trustworthiness” and its effect on design and operation of an industrial system. At the core of that understanding was a definition of trustworthiness and the designation of five characteristics that define trustworthiness.

As defined by the IIC in its recently released Industrial Internet of Things Vocabulary v2.1 document: “Trustworthiness is the degree of confidence one has that the system performs as expected. Characteristics include safety, security, privacy, reliability and resilience in the face of environmental disturbances, human errors, system faults and attacks.”

Let’s take a deeper look at the 5 foundational characteristics at the core of trustworthiness:

  • Safety ensures that a system operates without causing unacceptable risk of physical injury or damage to the health of people. This protection of humans is focused either directly or indirectly, as the result of damage to property or to the environment.
  • Security protects a system from unintended or unauthorized access, change or destruction while Information Technology (IT) security ensures availability, integrity and confidentiality (AIC model) of data at rest, in motion or in use.
  • Reliability describes the ability of a system or component to perform its required functions under stated conditions for a specified period of time.
  • Resilience describes the ability of a system or component to prevent or at least reduce any serious impact of a disruption while maintaining an acceptable level of service.
  • Privacy protects the right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.

Achieving trustworthiness in industrial IoT systems requires recognition that a complex IoT system is comprised of subsystems and the integral components of the subsystems. The trustworthiness of the overall system depends upon the trustworthiness of each of the subsystems and each of the components, how they are integrated, and how they interact with each other. Trustworthiness must be pervasive in IoT systems, which means there must be trustworthiness by design and a means to achieve assurance that the trustworthiness aspects have been addressed properly. Permeation of trust is the flow of trust within a system from its overall usage down to its smallest components and requires trustworthiness of all aspects of the system. Trustworthiness requires ongoing effort over time as systems and circumstances change.

As such, the IIC Trustworthiness Task Group, in close cooperation with the IIC Security Working Group, is tasked to frequently enhance and redefine the definition and role of trustworthiness in industrial systems as the IIoT continues to evolve. Ultimately, their goal is to moves system designers from traditional safety thought processes into a new paradigm for system design that takes into consideration all 5 of the trustworthiness characteristics and their interactions within the system.  

You can read more about trustworthiness and its relationship with industrial systems and the convergence of IT/OT in the Fall 2018 issue of ICC’s Journal of Innovation.

Cyber-Security 4.0 Wed, 05 Sep 2018 11:51:00 +0200 https://www.wibu.com/blog/article/cyber-security-40.html post-101 https://www.wibu.com/blog/article/cyber-security-40.html Daniela Previtali The report by RUSI showed that nearly half of the manufacturers and companies do not have the right tools to estimate potential cyber risk. Cyber-Security 4.0 by Daniela Previtali 05-09-18

Much has been written about the unbridled optimism brought on by the so called 4th Industrial Revolution (a.k.a. Industry 4.0) and the unprecedented cyber-related risks facing manufacturers given the increasing digitization of industry. The story was reported once again as a result of a recent survey conducted by EEF, a trade organization representing the manufacturing and engineering sectors in the UK and the EU, in partnership with AIG and conducted by The Royal United Services Institute (RUSI).

According to the report, nearly half of manufacturers surveyed have been victims of cyber-crime, with the manufacturing sector now being the third most targeted for attack after the government and financial sectors. The report revealed that 41% of companies do not believe they have access to enough information to even assess their true cyber risk, and 45% feel that they do not have access to the right tools for the job.  Furthermore, 12% of manufacturers admitted that they have no technical or managerial processes in place to even start assessing the true risks.

Manufacturing is considered to be an attractive target as there are vulnerabilities in both operating systems and industrial control systems that can be easily exploited. The report cited two well publicized breaches where production systems were infiltrated and severely disrupted after hackers gained access to their IT systems via unprotected office software.

The first incident cited occurred in August 2017, when a petrochemical manufacturer in Saudi Arabia was infected with malware that investigators believe was not simply designed to steal data or shut down operations but potentially to cause a catastrophic explosion. The attacker targeted operational technology in the form of industrial control systems rather than the more traditional focus on information technology. The malware overrided the facility’s safety system that was designed to stop automated equipment from going beyond safe operating conditions. The attack was not intercepted by the existing cyber security measures and failed only because the developers of the malware had made an error in the code that caused the systems to simply shut down safely.

The second representative incident occurred in late 2014 when an attacker used sophisticated social engineering and spear-phishing tactics to hack into a German steel mill’s office computer network. Attackers took control of production software and made it impossible to turn off a blast furnace, resulting in massive damage to the foundry. The attacker, who is believed to be an industry insider or someone working with an insider, had specific knowledge of the production processes involved so that maximum damage could be done to the mill. The company’s systems were specifically vulnerable because the office network was connected to the industrial control system, allowing the attackers to effectively take control of production.

Statistics brought forth in EEF’s report, like many others before it, continue to raise awareness of vulnerabilities inherent in the Internet-connect Industry 4.0 environment and the need for manufacturers to put cyber-security measures in place.

An interesting side-note in the report was the recognition that stakeholders along the supply chain as well as end users are becoming increasingly aware of cyber-risks as well. 59% of manufacturers reported that they have already been asked by a customer to demonstrate or guarantee the robustness of their cyber-security processes, and 58% have asked the same of a business within their own supply chain. Increasingly, the report notes that cyber-protection measures are becoming part of contractual arrangements. That doesn’t bode well for the 37% of manufacturers who reported that – as of today - they could not demonstrate good cyber-hygiene to arm themselves with the tools necessary to provide such assurances.

One of those tools, however, is readily available today. Wibu-Systems’ CodeMeter technology provides protective measures for software-driven industrial controllers. Manufacturing equipment, from entire plants to individual machines, rely on the use of individual or multiple integrated control systems, typically including a combination of both hardware and software that plant engineers use to program the desired application. You can learn more about these industrial controllers and mechanisms to protect them in our white paper, CodeMeter in the Automation Industry: A Win-Win Opportunity for Producers of Machinery and Control Systems.

Beware the Software Supply Chain Tue, 14 Aug 2018 21:56:00 +0200 https://www.wibu.com/blog/article/beware-the-software-supply-chain.html post-98 https://www.wibu.com/blog/article/beware-the-software-supply-chain.html Daniela Previtali With modern software applications being a combination of public software libraries and custom code, software supply chain security risks are on the rise. Beware the Software Supply Chain by Daniela Previtali 14-08-18

“Threat actors don’t have to defeat a company’s security measures, they only have to compromise a third-party supplier that it works with or relies on.” CSOonline

That seems to be the case with a new wave of software supply chain security breaches. For example, a destructive malware called “NotPetya” was deployed using a legitimate software package employed by organizations operating in the Ukraine. The attack was perpetrated using a mechanism to provide updates distributed by that vendor to their customers. In another attack, hundreds of thousands of computers were infected by a deliberately corrupted version of a free security software utility, CCleaner. Similarly, another group of hackers added deliberately corrupted Python libraries of Python’s public package repository, which were unknowingly incorporated into applications by thousands of Python programmers.

These types of attacks are not new, but the frequency with which they have been taking place are cause for renewed concern.

According to a technical note from The Software Engineering Institute, software supply chain security risk exists at any point where organizations have direct or indirect access to the final product or system through their contributions as a supplier. Security risks can be introduced into the supply chain in several ways:

  • coding and design defects incorporated during development that allow the introduction of code by unauthorized parties when the product or system is fielded. In addition, there are those defects that compromise security directly by allowing unauthorized access and execution of protected functionality.
  • improper control of access to a product or system when it is transferred between organizations (failures in logistics), allowing the introduction of code by unauthorized parties.
  • insecure deployed configuration (e.g., a deployed configuration that uses default passwords).
  • operational changes in the use of the fielded product or system that introduce security risks or configuration changes that allow security compromises (configuration control and patch management).
  • mishandling of information during product or system disposal that compromises the security of current operations and future products or systems.

Most developers build modern software applications with a combination of public software libraries and custom code. According to an article in Forbes magazine, the average web application has hundreds of these libraries, which are comprised of tens of millions of lines of code. The vast majority of these libraries come in the form of freely available software that can be downloaded from the internet.

The Software Engineering Institute points out that supply chain security risks will remain a growing concern as outsourcing and expanded use of commercial off-the-shelf (COTS) and open source software products increase and end users exploit opportunities to reconfigure or make limited additions to deployed products and systems. Common software defects can be readily exploited by unauthorized parties to alter the security properties and functionality of the software for malicious intent. Such defects can be accidentally or intentionally inserted into the software at any point in its development or use, and subsequent acquirers and users have limited ways of finding and correcting these defects to avoid exploitation.

Because it is so important for developers to fully understand all of the public libraries they may be using in conjunction with their own custom code, Wibu-Systems maintains complete transparency of the open source software components and versions that we integrate into our CodeMeter protection and licensing tools. That way, both ISVs and end users can monitor for any new issues that may arise with these components and address them quickly

The Gravity of IIoT Endpoint Security Mon, 30 Jul 2018 10:11:00 +0200 https://www.wibu.com/blog/article/the-gravity-of-iiot-endpoint-security.html post-97 https://www.wibu.com/blog/article/the-gravity-of-iiot-endpoint-security.html Daniela Previtali Endpoints are ubiquitous across the IIoT landscape and the 2018 SANS IIoT Survey reveals that IIoT endpoint security is the leading concern. The Gravity of IIoT Endpoint Security by Daniela Previtali 30-07-18

IIoT endpoint security was the leading concern of respondents to the 2018 SANS IIoT Survey: Shaping IIoT Security Concerns. The SANS Institute is a cooperative research and education organization and a leading source for information security training and security certification. More than 200 respondents participated in the survey, spanning various industries including energy/utilities, cyber security, government/public sector, technology and education/training.

There are many interesting insights in the survey report and if you are a stakeholder in the IIoT economy, I highly recommend that you read it. Among the many findings that have confirmed Wibu-Systems’ IIoT security recommendations in the past few years, several points stood out. The first is the fact that the definition of an IIoT endpoint and its relationship to an IIoT device is still being debated. The Industrial Internet Consortium (IIC) Vocabulary Report defines an endpoint as a “component that has computational capabilities and network connectivity.” The SANS report points out that a device manufacturer may consider the single, embedded sensor or actuator as the IIoT endpoint, while a system integrator may define that endpoint as a collection of such devices serving a particular function within a larger subsystem. The asset owner may consider an endpoint as a more complex system that is masked behind a gateway or edge device, such as a wind turbine or cooling tower.

The definition and the agreement on the definition by all industry participants is important because endpoints are ubiquitous across the entire IIoT landscape. The report also points out that an endpoint should be characterized specific to the IIoT system of which it is a part, especially if the endpoint requires configuration or programming based on its intended use in the system. This is essential for developing appropriate protective mechanisms against known and, in some cases, unknown attack vectors. The IIoT community is embracing the development of best practices around endpoint security, as described by the IIC white paper, “Endpoint Security Best Practices,” published March 12, 2018.

Another point in the report that stood out was the differing viewpoints around ownership of the development and enforcement of endpoint security mechanisms. Does it reside within the realm of IT or OT? IIoT has blurred traditional IT and OT infrastructure boundaries and added a level of confusion to the inevitable convergence of the two realms, particularly in regards to security.

The report notes that within each of the responsible segments, the perception of what part of the IIoT is most vulnerable and at risk depends on where the responsibility for managing IIoT risk lies:

  • The IT team, company leadership and management tend to emphasize data accessibility, reliability, availability and integrity.
  • Department managers emphasize networking and infrastructure appliances.
  • The OT team emphasizes the specific systems related to the IIoT endpoints and then the devices.

Where responsibilities for endpoint security lie is also confused by the fact that perceived and actual responsibilities differ within each group. The survey indicates that the IT team is most concerned with the protection of data, guarding against financial loss and compliance with industry regulations, while the OT team emphasizes increases in reliability, availability, efficiency and production, safety inside the organization, and protection of equipment and systems.

The report further points out that members of the OT department, the individuals who are likely the most knowledgeable about IIoT implementation, appear to be the least confident in their organization’s ability to secure these devices, while company leadership and management, including department managers, seem to be the most assured.

One of the conclusions in the report indicated the necessity to harmonize the viewpoints of IT and OT teams and any third-party product and service providers, especially as related to IIoT security requirements, threats and risks. Both IT and OT need to understand the risks imposed by new or existing IIoT devices connecting to the Internet and the corporate network. And, both need to know how to track and manage these risks as a team.

You can learn more from security experts and editors of IIC’s Industrial Internet Security Framework in an on-demand Webinar, IIoT Endpoint Security – The Model in Practice. The presenters outline in detail the significance of data protection, physical security, root of trust, endpoint identity, access control, monitoring and analysis, secure configuration and management, and integrity protection of IIoT endpoints

Just Another Brick in the Wall Tue, 17 Jul 2018 09:03:00 +0200 https://www.wibu.com/blog/article/just-another-brick-in-the-wall.html post-95 https://www.wibu.com/blog/article/just-another-brick-in-the-wall.html Daniela Previtali "Bricking" in software license management translates into the ability to lock down a license if an appropriate or illegal use of the software is detected. Just Another Brick in the Wall by Daniela Previtali 17-07-18

"Bricking” is a widely used term describing an electronic device, such as a smartphone, game console, router, or tablet computer that has been rendered useless due to severe physical damage, a serious misconfiguration, corrupted firmware, or a hardware problem.

Techpedia explains that bricking can occur for a number of reasons. The most common occurrence is when an attempt to update firmware of the device is interrupted by a power outage, user intervention or some other disruption that stops the update process, which inadvertently causes the existing firmware to be overwritten and rendered useless. Bricking can also be caused by the introduction of malicious or incompatible software, such as when firmware intended for a different hardware version of the device is installed.

In some cases, however, it has been speculated that electronics manufacturers may integrate software that intentionally bricks a device as a way of penalizing users who unlock their device for unauthorized use. For example, a recent report from Vice notes that Apple’s recent iOS 11.3 update appears to be bricking iPhone 8 units with screens provided by third party repair shops. It is assumed that the bricking is an attempt to discourage use of third-parties for repairs, which may be a more convenient or less expensive solution for a user than going through an Apple dealer.

More recently, software updates for the popular Nintendo Switch gaming console are said to have included code that appear to be bricking consoles that are illegally using third-party accessories. The speculation suggests that Nintendo is trying to stop users from exploiting the Switch with hacks to make it run software other than intended. Nintendo later issued a statement recommending that Switch owners should only buy officially licensed Switch products as others don’t undergo Nintendo’s rigorous testing and evaluation process.

From an end user standpoint, bricking is a tough lesson learned, whether the root cause be an inadvertent occurrence or an intentional act, and an approach not to be taken lightly should an ISV find an enterprise customer using their software illegally. There may be many reasons why an end user organization may be inadvertently using unlicensed copies of software – they may not have the internal resources to adequately monitor software downloaded on end user computers for licensing compliance; end users may bring their own devices with illegal software installed; or network managers simply don’t completely understand the licensing policies of the ISV. On the other hand, there are those who outright pirate software without regard for legal consequences or monetary damages to the ISV.

Either way, short of bricking, it behooves an ISV to have the ability to lock down a license if an appropriate or illegal use of the software is detected. Here are a few scenarios where an ISV would want the capability to lockdown their software:

  • A hacker is attacking the software in the background with plenty of time for reverse engineering. The ISV can integrate mechanisms to identify the attempted hack and put a limit on the number of recognizable attempts the hacker can try before locking down the software.
  • A dongle containing a valid license may be lost or stolen, or the customer is attempting to mislead the ISV to get a new license for free. In that case, the ISV can lock down the original license associated with the dongle before shipping a new one.
  • A software installed license is no longer accessible, whether the PC was undergoing maintenance and the user could not disable the license before the maintenance, or the customer is simply vying for a new license to install on another computer. The original license can be locked down before issuing a new license and rendering the original license invalid in case it gets “discovered” again.

There are many ways ISVs can manage license entitlements and take action when necessary, short of bricking the computer at any sign of irregularity. This one hour on-demand webinar, Setting Licenses Free vs. Locking The Down, will take you through the various scenarios and action steps that are available with the CodeMeter protection and licensing platform.