Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

US Energy and Commerce Committee: 6 Strategies for Modern Cybersecurity Risks

DZone's Guide to

US Energy and Commerce Committee: 6 Strategies for Modern Cybersecurity Risks

Learn more about cybersecurity from these key strategies for combating risks.

· Security Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

On the 12th of December, following the comprehensive timeline report detailing what happened during the Equifax Breach, the Subcommittee on oversight and investigations released an additional report identifying the core strategies organizations can take to address modern cybersecurity risks.

Following the increase both in security disclosures and events the Energy and Commerce subcommittee set about identifying what the common characteristics of these security events are and what, if any, priorities organizations can set from a strategic perspective to control and address these risks going forward.

  1. "The widespread adoption of coordinated disclosure programs.
  2. The implementation of software bills of materials across connected technologies.
  3. The support and stability of the open-source software ecosystem.
  4. The health of the Common Vulnerabilities and Exposures (CVE) program.
  5. The implementation of supported lifetimes strategies for technologies.
  6. The strengthening of the public-private partnership model."

OSS Is now Critical Infrastructure

It is a comprehensive report that sees input from several industry and technology sources, including the Linux foundation. Remarkably, the report discusses the inherent problem of known cybersecurity risks and the impossibility of managing known unknowns — and sets forth steps to control them.

The report bluntly states that open-source software components have not only become critical infrastructure for modern information systems but also that a vast majority of organizations leverage it, whether or not they know it, and that most software today is assembled, not constructed.

"For the same reasons that physical manufacturing moved away from bespoke craftsmanship to assembly-line-based manufacturing, software development has moved from an artisanal, soup-to-nuts process to one more akin to bricklaying"

As custodians of the largest open source ecosystem in the Java world, we at Sonatype have witnessed this transformation first hand. There were 87 billion download requests from this repository in 2017. A similar repository for JavaScript components is seeing 7 billion downloads a week, as reported in October 2018.

As the tools in the hands of developers across all programming ecosystems make it easier to leverage external code, the software engineering process itself has transformed itself to a process resembling manufacturing.

With the benefits of the above also arrives complexity, which the report by the subcommittee also recognises. As the amount of third party dependencies increases, it's becoming hard for organizations to fully understand or appreciate exactly what has gone into constructing their software. This is particularly problematic when they're trying to control risk during an event, as millions learned with OpenSSL in 2014, Equifax, AADHAAR, and Canada's Revenue Service learned in 2017 with Struts vulnerabilities, and CoPay learned a couple of weeks ago with event-stream JavaScript vulnerabilities. Buying software that is an opaque black box or assembling software without a full awareness of every constituent part can be a huge risk.

"The problem highlighted by Heartbleed and WannaCry was not that organizations did not know which software was vulnerable — that information was made publicly available from the outset — it was that they did not know which pieces of technology they depended on included it."

Towards this, their recommendation of building Software Bills of Materials (SBOM) is exactly what we here at Sonatype have been recommending to our customers for years. For organizations to be able to minimize their known unknowns, they must increase visibility of all aspects of software they produce and buy.

In our opinion, having and maintaining this SBOM allows organizations to develop and maintain automation that monitors for any new risk of these components and allows for effective lifecycle management of all parts. It takes away the risk of being caught unaware during a security incident in one affected component and allows for business-as-usual identification and remediation of any new risk.

OSS Needs Users' Support — and it's Implicit Trust Network Is Changing

Amazingly, the report also recognises OSS itself has become a part of critical infrastructure in the Internet and requires users to also contribute to its maintenance.

As we have seen over the last two years, OSS dependencies themselves are becoming the new front line for hackers and attackers to influence. As mentioned above, we saw this two weeks ago with the event-stream hack and targeted attack to a Bitcoin wallet that used it as a building block.

Although a sophisticated operation, the underlying tragedy of this event was that the event-stream component despite being hugely popular (having over 2m weekly downloads) was not supporting it's creator. In fact, for the two years he'd spent maintaining it, he never once made a cent off it. When the maintainer was approach by a seemingly beneficial party who offered to help, they changed control willingly.

This exchange has been normal in the open-source community for the last two decades, underpinning the implicit helpfulness of the community. Event-stream wasn't the only such event we saw, with a very similar incident occurring with conventional-changelog earlier in the year and many more before it.

The report advocates recognizing this inherent duality, urges organizations to contribute back to open source, and help take on responsibility of maintaining and supporting it. The economic argument for this is pretty convincing:

"After all, if 78 percent of companies run on OSS, then any improvements in the quality of OSS bricks will create immediate, widespread, and effective increases in the overall quality of the cybersecurity capabilities of the organizations using them."

The recommendation of seeing OSS contributions as a key security strategy concludes with the following statement:

"OSS support, together with coordinated disclosure (of security vulnerabilities) and SBOM, recognize and address some of the most critical facets of organizations' modern cybersecurity challenges."

The New Normal — Trust, Verify, and Manage With DevSecOps

We are happy to see the Energy and Commerce Subcommittees take such an active stance in improving the cybersecurity hygiene of all companies around the world — and acts as great recommendations to organizations across the world, including those covered under GDPR and other internationally significant regulation.

We are extremely pleased to see the report also call out for strengthening the NVD programm and have been advocating better quality security data for years. In our opinion, a key part of why information that is available is omitted by the consumers of open source is in part because it is hard for developers leveraging OSS to fully understand and consume security data in a meaningful way. This is why we have dedicated our lives to enriching and providing data about components in a meaningful, actionable way that helps our customers not only know about risk, but also to action it immediately without the need for a security middle man. DevSecOps automation is the concrete step every organization can take today to start implementing these practices in a scalable and meaningful manner.

Read the full report here:https://energycommerce.house.gov/news/suboversight-report-details-recommendations-for-addressing-cybersecurity-vulnerabilities/

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.

Topics:
equifax data breach ,data breach ,cybersecurity ,security ,hack ,data ,US Energy and Commerce Committee ,OSS ,CVEs ,Trust

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}