Why use of Open Source must be accounted for in Business Continuity Planning of a business – Lexology

Today, use of Open Source Software is a norm to develop Commercial Software by the businesses. A critical aspect at stake for such businesses remains to ensure business continuity at all cost.

Could use of Open Source Software hamper the business continuity? We investigated a landmark security event in the history of Open Source Software to vet this question.

The Comfort or peril of using Open Source Software

Open Source Software provides unique building blocks for Software development in todays Age. The time, effort and investment, that would have been required to build similar Software from scratch using a dedicated team in-house, is unimaginable! Most companies today understand the trade-off very clearly and therefore allow theuseof Open Source Software in their Projects while greenfield development is kept focused where the core Intellectual Property of such companies lie.

Companies often frame detailed Policies to regulate the use of Open Source Software, which we will discuss in further details in later blog posts, from our experience of creating Open Source Policies for different types of Companies.

So, there is an evident Comfort in using Open Source, yet such use of Open Source is not without its own peril.

Remember Heartbleed!

Heartbleed was detected as a serious security vulnerability on1st April, 2014which led to many commentators gasp and note that this could be the worst kind of vulnerability seen right from the beginning of Internet.

Just to refresh the memory, it is suspected that while updating OpenSSL withHeartbeatextension, the vulnerability might have crept into the Source code due to a possible oversight of coding error of the developers as far back as 2012. Though often contested, it is also suspected that some busybodies might have exploited the vulnerability at least five months prior to its eventual detection and disclosure to the public.

Codenomicon, now acquired by Synopsys, maintains a page athttps://heartbleed.com/, which works as a constant remembrance of the vulnerability that had massive effect on IT Infrastructure maintainers across the Globe.

But then we ask, what happens when such a vulnerability gets detected and worse even, when a threat actor exploits such a vulnerability.

The typical response of the businesses range from

immediately stopping the access to such a Software completely and introducing a patch to rectify such a vulnerability before re-initiating the access, ...to negotiating with threat actor for recovery of lost data while tackling questions from Privacy regulators as well as the data owners in parallel.

Amid, all of this, theBusiness Continuitygets lost and further raising serious questions on the Companys readiness to ensure business continuity.

What could cause such a peril?

While facing Heartbleed, a pertinent question got asked- was it avoidable?

Through Steve Marquess, the then CEO of the OpenSSL Software Foundationsblogpost, we get to see a rare view of the inner workings of such a popular Open Source Project. Steve says, that most of the revenue collected by OpenSSL Software Foundation comes from two streams: Donations and Commercial Contract for support.

Though the project had been very popular even before Heartbleed happened, it is evident thatthe flow of money into the project had been scarce, when compared to what would be required to maintain a project of such scale. Also, it seems developers, who were mostly working part-time on the project, were driven by their passion to create, above everything else and even though highly capable, an oversight could not be ruled out.

Post Heartbleed, when the issue came to fore, financial support got extended from different quarters.

Even at the peril of hindsight bias, it could be argued that even though the incident was not entirely unavoidable or at least for the businesses that got affected, unpredictable, at least from the clear identifier that such an important project had such an informal approach towards maintenance.

What should bother most businesses is the propensity of such an error due to lack of support to most Open Source Projects, at least in their initial stages and without formal backers, is more of a rule rather than exception.

So, what do you do?

Review.The first step starts at determining the Open Source Software that matters to your business. While advising our Clients, this is the most common response that we receive- our Codes have grown organically, we arent able to distinguish Open Source Software from the codes written in-house.

Revise.Check and rectify whether there are Open Source Software with known identifiers that can cause you trouble. If need arises, plan to move towards mature and robust Open Source Software, if you intend to not move to developing inhouse, and better, contribute to the Community through Donations, Commercial support or Vulnerability rectifications. It is always a great practice to remain invested in the Community that supports your business.

Prepare to Respond.Finding a vulnerability is inevitable. The strength of business is a function of how the business responds to a crisis. So, define a response plan in case aHeartbleedstrikes your business, including who would respond to it, how would you arrest it, how would you communicate to your Clients, Partners, Regulators etc.

Remember, your comfort in using Open Source Software must not affect yourBusiness Continuity.

Go here to see the original:

Why use of Open Source must be accounted for in Business Continuity Planning of a business - Lexology