Proprietary versus Open-Source Software Tools and What They Mean for your CyberSecurity Agenda

One rapidly emerging theme observed among organizations is seeking to understand the underlying features (and challenges) of adopting open-source software tools and the way they will shape their cyber-security agenda. With the rise of prominent open-source IoT platforms like DeviceHive, Macchina, Eclipse IoT, and ThingSpeak, among many other platforms and a myriad of open-source programming tools, organizations are still unclear about the security and protection liabilities of open-source software.

Before assessing the quality of open-source software, it is important to highlight some of the key benefits of the proprietary solutions.  First, the client can (ideally) expect regular updates in a streamlined manner and in tune with the evolving cyber-threat horizon. The vendor is liable and responsible for said security updates. On the other hand, this also means that clients are vendor locked to receive the updates at a frequency usually pushed by the proprietary vendor and have little control over what will happen. Second, it is expected that the level of security would be compliant with the clients’ requirements. However, it is the client that is ultimately responsible (and liable) for ascertaining the level of compliance required for their solution in their geographic location and in accordance with regional regulatory measures. Third, there is an expectation of “quality of life” improvements, regular bug fixes, reliable maintenance, and assistance from the vendors for almost all support issues related to their product. Unfortunately, certain proprietary software is marketed in such a manner that is impossible to test it beforehand. This means that clients must accept a company’s claim about the security of their code without any option to access its source code to evaluate it.

Open-source software often conflicts with the definition for free software, which, as adopted by the Free Software Foundation (FSF), defines free software “as a matter of liberty, not price”; note that a price tag can be added in the form of subscription fees. Open-source means that the source code is freely available to be reviewed, judged, evaluated, and often times improved upon by the developer community. This is the flagship argument in favor of the open-source movement since it allows software tools to evolve organically over time, as it can rely on a sizable knowledge base of contributors and on a “crowd-developed” basis. However, there might or might not be an entity behind it to provide support, and certain customization options or additional functionalities may be locked behind paywall subscription options. There may not be regular updates, bug fixes, scheduled maintenance or patches, among other options available in the proprietary world, but on the other hand, the users can benefit from a larger pool of knowledge.

So what is the best option? Trust a proprietary software tool from a trusted vendor (i.e., trusting its track record) but the code is kept secret and cannot be evaluated? Or would is an OSS (open-source software) be more steadfast in its approach since it can (in theory) crowdsource security from multiple sources and tackle issues in a more expansive manner? The answer, unfortunately, is… it depends.

A powerful advantage to using open-source that many organizations fail to see is that it forces developers of software tools and contributors to various programming language modules and libraries to adhere to certain security standards and clean code practices. By having the code open to be critically judged and improved upon by the larger development community makes all subsequent software tools safer (at least in theory). This means that the effect to which open-source code is more secure works due to this factor: the community which actively contributes and improves upon that code, thus hammering and tempering the steel, improving the software tool, right?

That is all well in practice, however, until it becomes clear how many people are actually taking on the challenge to explore that software tool. This means rummaging through its source code, running multiple simulations, testing it repeatedly, finding flaws (or to be more precise finding reproducible flaws), then either fixing or reporting them properly. If most of these crucial steps do not occur, then there aren’t any proper measures of the effectiveness and improvement of open-source software. For example, having an open-source anti-virus systems means nothing unless the community actively takes on the task to improve upon it. With open-source, there are of course fewer restrictions, but there might not be any support, quick fixes, or a dedicated managed security service to assist a client patch a serious vulnerability specifically tailored to their system. In some cases, all of this depends upon the in-house talent, who must also reach out to the greater developer community in order to solve a problem for its organization. An organization that is monetary-driven means that every hour a service is down, it is losing money and client reputation. Some free and open-source software tools may even deny liability as part of their user agreement, and may add additional data or software services under a paid or subscription model in order to complement the free nature of the original, standard, baseline tool or platform.

Certain tools are often judged by their very nature of being either closed/proprietary or open-source. Any company that keeps an algorithm, code, or software tool closed is protecting its own intellectual property but can also be seen as a negative variable in the security equation, or sometimes as a clandestine measure to conceal information about how the algorithm works—this can apply to a plethora of applications: from retail to tech to government. For example, Google has a number of Google Open Source tools for its search engine, Intel has open sourced its SDO (secure device onboarding) to FIDO (now renamed FDO), but certain companies and, of course, governments have, naturally, declined any requests to make their algorithms public.

Below are a few important recommendations on how to deal with open-source security issues:

1. Know your dependencies by understanding where exactly the borders are drawn, the manner that your open-source tools are interlinked, to which sources, their dependencies, and how a chain reaction may affect your core operation.
2. Have backups, data repositories, failsafe mechanisms, data and operation restoration mechanisms in case something goes wrong.
3. Understand how your customers and your circle of partners will be affected should something happen to your system due to open-source tools—will you be liable to your customers or partners? Will you need to reimburse them for any losses?
4. Be prepared and scout ahead. If you are determined to avoid any managed security services then make use of open databases and web-scraping data, or otherwise access any malware or cybersecurity repositories that list attack statistics on open-source tools and applications, in order to understand how these may affect your services. You can use both government databases, e.g., from the National Vulnerability Database (NVD), or from proprietary sources, e.g., Symantec or Kaspersky, should they include any databases that meet your criteria.
5. Make sure there is some sort of quality assessment for OSS and, if possible, make use of any automated tools and design your own custom playbooks to potentially even instruct the system to perform certain security protocols just in case a critical operation is affected. Since full security automation is rather challenging it may be difficult to resort to that, but at the very least have certain software tools monitor your open-source applications if possible (contrary to just having them run unsupervised in case there is no organization between them or no one that is liable).