2.6k views9 Comments

Founder/Chairman/CTO in Telecommunication, 201 - 500 employees
I hope the lasting conversation is around the supply chain itself. We keep forgetting that the internet is not inherently secure because it's open source. It's written by people in the same way that bespoke code is, so it's just as likely to be vulnerable. And that’s underpinning most of what we've built at this point — what are we doing about that? That is where the narrative has shifted. Talking to CISOs is like talking to policymakers. We’re seeing stuff come out of DC around how to legislate open source being secure, which is absurd, but it’s the right conversation to have. The focus has moved away from that specific vulnerability to why that happened, and how we can get better at preventing that from happening again.

We need to realize that the internet is just a stack of turtles that are supported by one and a half people in North Dakota, because that's the truth of it. We rely on a lot of different software packages and systems that look a lot like Log4j. So it's not just about this particular piece of code and what it can do. It's about all the other stuff around it. How are we thinking about that from a risk management standpoint? It's an interesting time to be having that conversation because the pandemic has revealed to the average person how supply chains work and what they look like when they’re broken. This is not that different. It's conceptually a bit more abstract for non-technologists to get their head around, but it's quite similar.
1 Reply
SVP in Finance (non-banking), 1,001 - 5,000 employees

It's an interesting question, because I don't know if you can prevent something like this from happening again.

Secure Facilities Information Technology Manager in Manufacturing, Self-employed
This should open our eyes to the many vulnerabilities that are built in to the fragmented world of applications. 
Director ERP Management in Travel and Hospitality, 1,001 - 5,000 employees
Its a good question given the situation with recent vulnerability found in Apache. The fact is open source software is still used by tons of Admins and organizations. The legacy business applications are running on Apache and not all legacy apps are ready to update to other platforms or updated version of Apache software. Log4j being a logging service for Apache has significant impact on development teams. As a long term impact, I am afraid some of the systems will be left un-patched due to lack of technical resources or limitations of legacy applications.
Director in Manufacturing, 1,001 - 5,000 employees
I ran a large application retirement program for years.  We were retiring applications as complicated as full ERPs to as small as simple Marketing Websites.  The business people never really appreciated the risk of old applications.  Not the risk of being unsupported and no way to change them.  Not the risk of security vulnerabilities that can no longer be patched on the current version of the system or application.  

I'm hopeful that as there are more publicized issues with old software, or software that doesn't get patched or upgraded, the hard to measure risk is at least discussed at budgeting meetings more.  It takes budget and priority to try and avoid eventual problems.  Not every old system is a huge risk, but if you don't have rigor and process around evaluating and continually retiring, the problem grows until it's a crisis.    I wonder how many times the budget to avert the Log4j issues were cut, denied, lowered in priority.... until it was a DROP EVERYTHING AND GET ON THIS PROBLEM.    IT has always had some "fire fighter" mentality.   I myself had part of my career in Operations, and it was very satisfying to solve a crisis and save the day.  The difference now is it doesn't end.  Your fire fighting team could be working 7x24 and not contain the fire.  You really need a robust program and process to continually work the forest of your applications and systems to consolidate and update to reduce your security risks.   Fires will still start, but hopefully a lot less, and only an amount you can manage.
1 1 Reply
Director in Manufacturing, 1,001 - 5,000 employees

#technicaldebt #rootcause

Director of IT in Software, 201 - 500 employees
We had the SolarWinds and CodeCov breaches before, and with the Log4J vulnerability, the outcome should be a wake-up call to how vital supply chain security and vendor management are.   The worst part is that this vulnerability is likely not the last one.

Another important take from this is understanding the open-source risk in general. I have heard from far too many people that open-source is natively less risky because the code is visible and openly reviewed.  There was the Heartbleed in OpenSSL vulnerability in 2014 and Equinix breach from 2017 with the Apache Struts framework, so the narrative should change.  
VP of IT in Real Estate, 5,001 - 10,000 employees
Enhanced security awareness across teams 
Director of IT in Healthcare and Biotech, 501 - 1,000 employees
I hope this further emphasizes the importance of reviewing, testing, analyzing, and being wary of any and all software implemented within an organization, especially open source and keeping the application portfolio to a bare minimum. I also hope that this vulnerability exposes to non-technical key decision makers the importance of investing in sound security measures and the expenditures associated.

Content you might like



About the same as always23%



2.5k views1 Comment

CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.
Read More Comments
43.6k views132 Upvotes319 Comments

Strongly agree11%




Strongly disagree1%

Other (please specify)0%