Reflecting on IT and trust after log4j

Open source and proprietary software — what you need to consider when balancing benefits and costs. Read some tips and guidelines to be better prepared for vulnerabilities that are disclosed in the future.

Open source components have changed the way and speed companies make software, but at the same time created security challenges, as showcased by recent log4j vulnerabilities. Putting blind trust in open source is the single highest threat that companies face, but proprietary software can also be vulnerable to bad actors’ manipulation, like the Kaseya’s ransomware incident or Solarwinds’ build process’ compromise show.

Developing commercial software with some open-source components, and running a network lab with various types of devices and applications led us to create some guidelines on how to inventory and control what we use and where. Below are some ideas and tips that we have found valuable over the years.

Ready to verify what our recommendations are for existing open-source components at your network and check-points for any new software?

Existing open source project — housekeeping tips

The fact is — open-source software is to some extent in every network, be it for convenience or lack of budget, or it was configured to cater to some specific need by someone working here 5 years ago and never touched since then. The housekeeping procedure is not easy and never complete, but it is worth the time spent when any vulnerability is disclosed (and as 2021 proved, it happens multiple times a year).

Know your IT environment

Let’s start with the end.. that is, end-points. Contrary to what some folks say, you have to know all your endpoints. Here’s what your network monitoring software can do — collect data of all your devices that you have in your network.

List all network devices and workstations

The majority of firmware on your devices includes some open-source components. That’s why knowing the manufacturer’s name, device type, and the firmware version of each network device is helpful in the long run. Any changes or updates should be recorded.

As for PCs or laptops, it makes sense to know not only the OS version but also the patches and the updates’ versions they have.

Inventory all applications and their components

When drilling down and documenting the applications and business processes they support, it is helpful to understand not just what applications your company is running or using, but also the various components that go into those software applications.

Searching for components rather than full applications can be tricky — it may involve searching for filenames or even file hashes, or #include statements within applications themselves.

Keep it up to date

Finally, keep the list updated and review it every few months. Encourage each of your team members to contribute to the list, especially if they identify an application or component that has not been listed before.

Reviewing software or components for new projects

Testing and evaluating the functionality of new software is obvious. But what are other checkpoints for the software that you are planning to add to your IT team toolset? What you should consider when looking at open-source software?

Open-source

For the open-source components or applications, try to minimize the risk by checking the following:

• Scope — check if this package solves the problem you are tackling with. Isn’t the component too broad for your need? Can you contribute to the component if needed?
• Credibility — to verify it you may check how long it has existed, how many contributors there are, and whether the repository is active or has been abandoned for years. How is the repository handling issues? How fast responding?
• Quality & trust — some questions you may ask yourself would be about the code quality — does the code look safe to use? Are there any known vulnerabilities? Does the repository have tests or CI pipelines that are publicly available?

Commercial software for a new project

As we said before, trust is built on the quality of software code and quality of support. What are red flags that you should look at when reviewing proprietary software for your project?

• Scope is important for any project, so check if this software solves the problem you are trying to solve/prevent.
• Quality — unlike in the open-source applications, you cannot view the proprietary software’s code. But you can see how it works and how you can interact with the tech support team. How about going for trial install and having it running for at least a week? Look for stability issues or other performance hiccups, is the UI interaction smooth, can you find what you are looking for? Contact support, see how they can handle your questions, are they responding fast, helping in configuration or testing?
• Open-source components — check what open-source components the software is using. It should be listed in the about section of the software. It may not be a critical point of your decision process but it may be worthy to make a list. Make sure to add them to the list if you decide to purchase the product.

Final thoughts

It looks like each company will have to live with its own combination of proprietary and open-source software for the foreseeable future. Ensuring visibility into your IT ecosystem and boosting basic housekeeping hygiene as described above is how you can minimize the risks of software supply chain attacks as well as ransomware risks related to disclosed vulnerabilities.