Log4Shell Part 2: 3 Best Practices for Software Security

Security is as important a topic as ever! Organizations everywhere are grappling with their approach to cybersecurity. In my previous post, I addressed some basics about the highly-publicized "Log4Shell" security vulnerability. Log4Shell and others provide a constant reminder that IT security is a perpetual task. A properly protected technology stack requires certain best practices to be followed consistently.
 
So, what are these best practices? Most folks know the pitfalls of default passwords, guest file shares and excessively-granted authorities. But, we also need to be prepared for any up-and-coming exposures.  Today, I will focus specifically on the three most important habits to keep you prepared for any future security exposures in third-party software, whether it's proprietary or open source.

1. Know Your Software Stack

The most important element of maintaining a good security posture is simple, yet often difficult. One particular question always seems to come up when assessing the impacts of a security threat: "What software are we running?"
 
On one hand, the answer seems easy. After all, it should be easy to list your core business applications. It's not that simple, though. Your server is likely to have hundreds of different programs for various tasks. For instance, there could be a REST gateway, a web interface, a program for pulling supplier data, and so on. 
 
It's important to maintain knowledge of what's deployed on your server (and everywhere else in your infrastructure, for that matter!). Your software inventory should allow you to easily answer questions like:

• What is the complete list of software installed?
• What's running on port 8392?
• What job name does the software run under?
• What open-source packages are we using?
• If software is from a third party, who is the vendor? How do you contact them? How do they contact you if there is a security patch?
• If software is built internally, where is the source code? What types of change control are in place? 

When a security threat arises, not knowing answers to the above questions can be damaging. How are you supposed to mitigate a threat? Can you confidently assert the security of your systems? If you haven't yet done so, building and understanding your software inventory should be a top priority. Also, be sure to keep that knowledge up-to-date as your software stack grows. It may be a lot of effort, but I guarantee that it'll pay off in the long run.

2. Keep Informed

Certainly, you can't respond to a security threat if you don't know about it! Of course, with some vulnerabilities, like Log4Shell, it's difficult to NOT hear about it! Most of the time, though, this awareness requires extra due diligence on your part. Surely, you know about the National Vulnerability Database (NVD), but how can you leverage it effectively?
 
For any proprietary software, maintain a relationship with the supplier. Two-way communication channels are important. You should have a way to contact them with any questions, and they should be able to contact you with any patches or remediation steps in the event of a security incident. 
 
For software that your company owns, ensure that every piece of software has a team or individual identified as responsible for ongoing maintenance. That is, if some changes or investigation are needed, ownership of that duty is clear. Similarly, maintain a list of which programming languages and open-source packages are being used by the software (when possible).
 
Lastly, what about vulnerabilities in open-source software that you're running? Certainly, keeping an eye on the NVD is important. In addition, security issues might be documented in appropriate open-source communities like mailing lists, forums, issue trackers, etc. IBM also maintains the X-Force Exchange, a "threat intelligence sharing platform" that provides an interface to explore, research and collaborate. 
 
Even though many resources are available to help out, keeping informed about open-source updates can be a cumbersome task. Thankfully, IBM Technology Support Services (TSS) provides the Open Source Proactive Reporting Insights (OSPRI) offering to help remove some of the burden. For packages supported by OSPRI (currently over 250), you can be proactively alerted when there's an actionable issue. Figures 1 and 2 demonstrate the simplicity and usefulness of this offering.

Figure 1: Simple interface for enabling CVE reporting

Figure 2: Customizing how OSPRI information is delivered to you 
 
Yes, you can simply choose what information you want and when you want it! Check out this flyer for more information and resources. OSPRI is currently offered as part of IBM's world-class support for open-source software, which might already be a key piece of your open-source strategy. 

3. Stay Current

Knowing what software is running and learning when action is required are crucial aspects of security. But, it's also important to ensure that your software will be patched if any security vulnerabilities are found. That generally means running current versions of software, whether it comes from IBM, another vendor, or the open-source community. This will allow you to respond quickly to security incidents. Applying a small software update for a security fix is usually non-disruptive and carries little risk. On the other hand, a major migration or upgrade of your software could be risky, expensive and disruptive! 
 
Thankfully, this isn't a complex problem to solve. IBM and other software vendors will generally do the following:

• Establish some form of release cadence
• Publish lifecycle dates (including end of fix support) as they are known, providing plenty of time to plan for a software version's end of life
• Provide periodic updates, including security updates, for in-support versions of software. 

 
Naturally, the same is true for many open-source projects. I often use the Node.js release cycle in Figure 3 as an example. Use this information to plan accordingly. 

Figure 3: The Node.js release cycle 

A Comprehensive Security Approach

In short, if you follow these three best practices, your organization can master its response to security incidents. You'll be able to adapt quickly and confidently!

Figure 4: Process for managing security exposures
 
A comprehensive approach to security follows today's guidance in addition to the traditional set of knowledge. With a securable platform like IBM i, a bit of proper planning and some common sense, your IT stack can be secure and future-proof!

 

---