Wibu-Systems Blog https://www.wibu.com/blog.html Tue, 23 Oct 2018 18:40:50 +0200 Tue, 23 Oct 2018 18:40:50 +0200 t3extblog extension for TYPO3 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.

]]>
A Shift to the Left for Application Security Tue, 10 Jul 2018 16:01:00 +0200 https://www.wibu.com/blog/article/a-shift-to-the-left-for-application-security.html post-94 https://www.wibu.com/blog/article/a-shift-to-the-left-for-application-security.html Daniela Previtali The speed in which development teams are releasing new software is making it difficult for the security operations team to keep up. A Shift to the Left for Application Security by Daniela Previtali 10-07-18

A recent article in SD Times gave light to the trend that more and more aspects of software development are being forced to “shift left” in the development lifecycle, meaning that the speed at which development teams are releasing new software is making it difficult for the security ops team to keep up. As a result, the responsibilities for creating and enforcing security policies are being shifted back towards the devops teams.

Rani Osnat, VP of product marketing at Aqua Security, noted in the article that “because of the speed at which code is updated and delivered, security can no longer be thought of as an afterthought… Operations teams can no long accept an application as is and plan on securing it once it is deployed in the runtime environment.”

Osnat went on to point out that what’s happening is that “developers are developing more applications faster and delivering code faster than security can catch up to. That’s something where really the only way to address it is not to just give more work to security, but to move some of the burden to the developers in using best practices to secure applications when they are developed.”

From the standpoint of Wibu-Systems, of course, we have devoted ourselves to communicating to ISVs the importance of implementing security by design strategies and providing mechanisms to protect software from even the most unscrupulous hackers.

One of the most secure software protection mechanisms that we recommend is a technique we call CodeMoving. In this case, the application code is moved into a dongle (CmDongle) and executed within that safe environment, making it impossible for a hacker to discern anything about the code and its function.

CodeMoving allows the developer to create as many code fragments as desired for execution in the CmDongle. To move the code, the application is encrypted with our AxProtector tool; all functions to be moved are compiled by AxProtector and encrypted within the application. During runtime, the block in question is moved into the CmDongle, decrypted, and executed with the right input parameters. The output parameters are then returned back to the application.

An internal CodeMoving-API, which provides AES and SHA cryptographic functions, can be used to increase the protection level. Data can be saved temporarily and used again when the next function is called up. Hidden data can also be accessed, although security dictates that this can only be done within the product item that the code fragment is decrypted with.

Given the expectations and demands for accelerated software development cycles it is unrealistic to expect ISVs to understand and keep up with state-of-the-art software security practices. That’s why so many developers are turning to security experts like Wibu-Systems to fill that gap. You can read more about the CodeMoving technique and other software licensing and protection mechanisms in our most recent KEYnote magazine.

]]>
The Future of Industrial System Monetization Mon, 18 Jun 2018 10:31:00 +0200 https://www.wibu.com/blog/article/the-future-of-industrial-system-monetization.html post-93 https://www.wibu.com/blog/article/the-future-of-industrial-system-monetization.html Daniela Previtali The Dynamic Monetization model proposes to move the payment for industrial systems from upfront to the time of usage with revolutionary consequences. The Future of Industrial System Monetization by Daniela Previtali 18-06-18

The software industry’s move towards pay-as-you-go and subscription licensing is fueled by the success of Microsoft, Adobe, Salesforce and others who have revamped their business models to take advantage of the flexibility of cloud-based services and give their customers usage-based options. That trend will no doubt continue as ISVs scramble to retool their packaging and delivery models to take care of their customer preferences while keeping sight on the monetization of their software offerings.

But what about the software driving millions of devices in the IoT, or more specifically, the industrial IoT where connected machines, artificial intelligence, massive data exchange, machine learning and other Internet-driven technologies are shaping the smart factories envisioned in the next industrial revolution, now called Industry 4.0? Would a usage-based monetization scheme work in such a complex environment across the entire industrial supply chain? Quite possibly, but first let’s take a look at the conventional payment model and the challenges it presents.

Industrial systems are expensive to build. The operational user typically pays for the entire system upfront, while there is yet any revenue generated to offset the expense. It could take years for the operational user to realize a substantial ROI on the investment. At this point, all of the financial risks rest upon the operational user. If the operational user requires a loan to initially finance the capital equipment purchase, the risk is even higher. If the system fails or is not profitable, the operational user is at further risk of financial loss or even bankruptcy. This process can be a roadblock to innovation, as banks are more restrictive with loans in what might be considered a high-risk system with no successful track record behind it. This scenario becomes even more complex when the relationship between the machine builders and component suppliers comes into play, considering factors like system pricing and discounts and their impact on profits.

The aforementioned scenario is a simplistic example yet begs the question whether a usage-base monetization method could exist in a modern industrial environment. The potential benefits to usage-based monetization of industrial systems are readily identifiable: reduction of large upfront payments for expensive machinery by the operational users; shared risks and rewards between machine builders, component suppliers and operational users; and revenue generation based on operational usage providing for more equitable distribution of profit.

Among the many challenges to a usage-based model, two stand out:

  1. Industrial systems typically incorporate many thousands of components from hundreds to thousands of different suppliers. No efficient tracking method currently exists capable of delivering accurate usage payments to all these providers.
  2. Some components require payment upon delivery and it is simply not realistic to pay for such components as a result of usage.

To be successful, an efficient pay-per-use monetization model will require a standardized process for all components and the ability to function autonomously and automatically. The Industrial Internet Consortium (IIC) is currently looking into modern monetization methods for industrial systems that could, in fact, change the traditional payment paradigm to a universal dynamic usage-based model that will take advantage of the systems connectivity to the Internet.

As a starting point for discussion, the IIC has drafted the Industrial Internet Monetization Model (I2M2) which presents various monetization scenarios and how they might fit within a world of varying business models, components and systems and the relationships with different participants like Operational Users, Component and System Builders. One of the promising scenarios is the Dynamic Monetization method, which proposes to move the payment for industrial systems from upfront to the time of usage.

You can learn more about these new proposed monetization methods in an article published in the ICC’s Journal of Innovation. The article, I2M2 – the Future of Industrial System Monetization, was written by Marcellus Buchheit, President and CEO of Wibu-Systems USA, co-chair of the IIC Trustworthiness Task Group, and contributor to the IIC’s Industrial Internet Security Framework.

]]>