Preventing the Next Equifax – All CVEs Have Root Causes in CWEs

Tracie Berardi, Program Manager, CISQ

 

The Equifax data breach in 2017 was the result of attackers exploiting an unpatched vulnerability in Equifax software. The vulnerability – Apache Struts: CVE-2017-9805: Possible Remote Code Execution as titled in the NIST National Vulnerability Database – was a flaw discovered in Apache Struts web application software. Equifax was employing the open source code from Apache. The patch became available in March. The breach of Equifax occurred two months later in May. Outrage, lawsuits, and Federal investigations ensued…

 

A couple of key takeaways from the breach –

 

  1. Developers commonly use third-party components, both open source and commercial-off-the-shelf, in their code and products. It is critical for the development team to maintain an inventory of its third party components to manage the component’s source, versions, and patches. SAFECode has published an excellent guide on the subject. Read: Managing Security Risks Inherent in the Use of Third-party Components. In the case of Equifax, action came too late.
  2. Basic security prevention can help to protect against CVEs and future zero-day vulnerabilities. A subset of CVEs are issued with a mapping to relevant CWEs. The CWEs represent the vulnerability’s root causes and source vectors for exploitation. The Equifax CVE, for example, was mapped to CWE-20 (improper input validation) and OWASP A4 (broken access control) in the OWASP Top 10 2017.

 

The security weaknesses underlying the Equifax breach are highlighted in two major industry resources – the Top 25 CWEs maintained by MITRE Corp and OWASP Top 10 maintained by the Open Web Application Security Project (OWASP). As part of a secure development process, developers should continuously review their code for CWE-identified weaknesses. Many security tools automate detection of CWEs for this purpose. The CISQ Security measure is based on the Top 25 CWEs that can be detected through static code analysis. By mitigating CWEs early and often, a team can prevent future exploits and creation of future vulnerabilities.

 

As concluded in a recent CISQ board call, “Zero-day vulnerabilities really represent CWEs that were already there that somebody else was more committed to finding in your software than you were.” – Joe Jarzombek, Global Manager of Synopsys Software Integrity Group

 

There are a number of resources and stakeholders involved in helping the industry get further ahead on the zero-day CWE problem. In future posts we’ll explore what current mechanisms work and what the industry can do better to proactively address this issue.

 

Mar 2, 2018 Update:

Equifax identified additional 2.4 million affected by breach. Equifax Inc. said an additional 2.4 million Americans were affected by its massive data breach last year, the WSJ’s AnnaMaria Andriotis reports. The total number of U.S. consumers whose personal information was compromised now stands at 147.9 million.

 

Texas Cybersecurity Legislation Passed In 2017 – A Summary

Herb Krasner, University of Texas at Austin (ret.), CISQ Advisory Board member

 

Here is a summary of the cybersecurity legislation that was passed this year that will have an impact on state agencies and institutions of higher education (all from the 85th regular session of the Tx legislature). The Tx Dept. of Information Resources (DIR) and state agency CISO’s will be the primary actors to make these new laws happen. The 2017 cybersecurity legislation (HB 8, except where noted otherwise) includes the following summarized provisions:

  • Establishment of legislative select committees for cybersecurity in the House and Senate.
  • Establishment of an information sharing and analysis center to provide a forum for state agencies to share information regarding cybersecurity threats, best practices, and remediation strategies.
  • Providing mandatory guidelines to state agencies for the continuing education requirements for cybersecurity training that must be completed by all IT employees of the agencies.
  • Creating a statewide plan (by DIR) to address cybersecurity risks and incidents in the state.
  • DIR will collect the following information from each state agency in order to produce a report due to the Legislature in November of every even numbered year. (SB 532)
    – Information on their security program
    – Inventory of agency’s servers, mainframe, cloud services, and other technologies
    – List of vendors that operate and manage agency’s IT infrastructure
  • The state cybersecurity coordinator shall establish and lead a cybersecurity council that includes public and private sector leaders and cybersecurity practitioners to collaborate on matters of cybersecurity.
  • Establishment of rules for security plans and assessments of Internet websites and mobile applications containing sensitive personal information.
  • Requiring the conduct of a study on digital data storage and records management practices.
  • Each agency shall prepare a biennial report assessing the extent to which all IT systems are vulnerable to unauthorized access or harm, or electronically stored information is vulnerable to alteration, damage, erasure, or inappropriate use.
  • At least once every two years, each state agency shall conduct an information security assessment, and report the results to DIR, the governor, the lieutenant governor, and the speaker of the House of Representatives.
  • Required proof that agency executives have been made aware of the risks revealed during the preparation of the agency ’s information security plan.
  • Requires state agencies to identify information security issues and develop a plan to prioritize the remediation and mitigation of those issues including legacy modernization and cybersecurity workforce development and retention.
  • In the event of a breach or suspected breach of system security or an unauthorized exposure of sensitive information, a state agency must report within 48 hours to their executives and the state CISO. Information arising from an organization’s efforts to prevent, detect, investigate, or mitigate security incidents is defined as confidential.  (SB 532)
  • Requires creating and defining an Election Cyber Attack Study (by Sec. of State).
  • Allowing DIR to request emergency funding if a cybersecurity event creates a need (SB 1910).

 

 

 

 

How Outsourcing Can Mitigate Cyberrisks in DevOps

 

Dr. Erik Beulen, Principal, Amsterdam office (beulen.erik@bcg.com); Dr. Walter W. Bohmayr, Senior Partner, Vienna office (bohmayr.walter@bcg.com); Dr. Stefan A. Deutscher, Associate Director, Berlin office (deutscher.stefan@bcg.com); and Alex Asen, Senior Knowledge Analyst, Boston office (asen.alex@bcg.com)

 

DevOps agility requires organizational adjustments and additional tooling to ensure cybersecurity. At the same time, the challenges of the cybersecurity labor market drive the need to increase tooling’s impact and to consider outsourcing. In turn, these require carefully focusing on cybersecurity governance, including the assignment of accountability and responsibility.

 

In DevOps, the business is in the driver’s seat. DevOps characteristics (such as iterative prioritizing and deployment) plus the combined responsibility for development and operations present cybersecurity risks. They also create opportunities. DevOps tools, infrastructure, processes, and procedures can be used to fully automate patch deployments and continuously monitor, for example, open ports. Best practices are to automate information security platforms using at a minimum programmable APIs, but preferably automated to control access, containers and container orchestration combined with hypervisors or physical separation to avoid the impact of an attack on the OS kernel layer.

 

Market Developments

 

Our analysis of global startup activity in cybersecurity products reveals about 1,000 firms that represent more than $20 billion of investments. This explosion of competing cybersecurity products has driven enterprise reliance on best-of-breed solutions, which requires a lot of coordination and increases the risk of gaps in the cybersecurity landscape. Consolidation of cybersecurity product portfolios through mergers and acquisitions will still take some time—about three to five years. In the enterprise segment, we have to accept best-of-breed solutions and the associated increased complexity for the years to come.

 

Meanwhile, the service market is also evolving but still scattered. Managed security service providers (MSSPs) provide end-to-end protection, stabilize infrastructure, optimize IT operations, and provide rapid responses to security breaches. On one hand, MSSPs can be used to scale up required capabilities, reduce complexity, and innovate to achieve cyberresilience. On the other hand, the service market is not mature yet, so prior to contracting with an MSSP, companies should rigorously assess a solution’s robustness and vision. Companies should also determine  the number and seniority level of the cybersecurity experts at an MSSP.

 

Accountability

 

Accountability for cyberresilience can never be outsourced. Organizations need to build a cybersecurity competence center that oversees the design and maintenance of strategy and requirements, assesses cybersecurity compliance, and evangelizes cybersecurity. (See Exhibit 1.) This competence center manages the business demands. It also directs in-house cybersecurity and MSSPs’ strategy and policies, including standards, frameworks, certification, risk tolerance levels, and attack procedures. The number of MSSPs a company should engage depends on the size of the organization, cybersecurity requirements, and the capability to manage suppliers. Rarely do organizations engage with more than three MSSPs to avoid coordination challenges and ensure unambiguous responsibilities.

 

Exhibit 1: Cybersecurity Competence Center Responsibilities
Click to view larger image

 

 

Responsibility

 

Responsibilities for cyberresilience have to be embedded from the board level down to each DevOps team. This is not straightforward and requires a constant and intense dialogue embedded in governance structures and involving all stakeholders. At the application level, product owners and scrum masters have to ensure cybersecurity is respected and embraced by the DevOps teams (“cybersecurity by design”). This doesn’t mean developers must become security experts. Rather, product owners must assign dedicated security experts to each DevOps team. This will not be a full-time role, and security experts can be allocated to multiple DevOps teams. However, cybersecurity remains a team responsibility. Scrum masters have to explicitly address cybersecurity in each step of the DevOps lifecycle. This starts with creating cybersecurity awareness by training developers using gamification (such as Microsoft EOP game[1]). Furthermore, continuously monitoring and measuring cybersecurity performance (service levels) is important. The end goal is to champion cybersecurity by deploying and maintaining software in accordance with the set risk tolerance levels and applicable security standards.

 

Conclusion

 

Ensure cybersecurity in DevOps by taking these steps: empowering your product owners and scrum masters, building a competence center, partnering with no more than three MSSPs, using automation, and, of course, making cybersecurity a business agenda item. Also follow the World Economic Forum Working Group,[2] which kicked off cyberresilience through brainstorming!

 

[1] https://www.microsoft.com/en-us/SDL/adopt/eop.aspx

[2] https://www.weforum.org/whitepapers/advancing-cyber-resilience-principles-and-tools-for-boards