Latest Strategic Partner

We are pleased to have CFOs2GO as our latest member of our Global Goverrnance Community Strategic Partners.

"Given our work in independent board evaluations, we avoid any conflicts of interest when we refer strategic partners to help boards with any specific corrections needed" notes CEO Donna Hamlin.

"We are delighted to be able to have CFOs2GO as a capable partner who can address any such needs."

CFOs2GO provides financial expertise on an interim and consulting basis and placement services for direct hire positions to clients nationwide and internationally from offices in the San Francisco Bay Area and Silicon Valley. Our team is hand-picked from practicing CFOs with an average of 25 years of experience across a broad range of industries and practice areas, including expertise in International business, balance sheet management, corporate finance, Enterprise risk management, financial systems & reporting, SEC reporting, financial modeling and analysis, project management, succession planning, crisis, management, strategic services, equity crowd fundraising, and turnarounds, corporate restructuring, for startups, rapid growth & pre-IPO companies, small businesses, Non-profits, cleantech, healthcare & life science, food & beverage, financial services, real estate & construction and, most recently, agribusinesses. CFOs2GO is designed to produce significant client value through an interweaving of both consulting and recruiting capabilities, each supporting and enhancing the other. www.cfos2go.com

Director Duties:
Cybersecurity Guard Watch

By José E. González, Boardwise Community Featured Author

Within the last six months, responsibility for Cybersecurity Risk Management has expanded for board members. In March, 2017, a new regulation went into effect in New York State that requires organizations supervised by the Department of Financial Services to have a risk-based cybersecurity plan in effect by August, 2017. [1] Board of Directors are now required to certify, on an annual basis, that the organization is in compliance with the requirements of the law. [2] Certifying senior officer(s) and directors could be held personally liable for perceived compliance shortcomings. [3]

The Federal Government, too, is looking to raise cybersecurity accountability to the Board of Directors level in commercial organizations. A Bill [4] recently introduced in the US Senate would direct the Securities and Exchange Commission to issue rules that require all publicly -traded companies to disclose in their annual reports or proxy statements whether any member board of directors has expertise or experience in cybersecurity. If no Board member has expertise or experience in cybersecurity, the reporting company would need to describe what other cybersecurity steps were taken by the persons responsible for identifying and evaluating nominees for any member of the Board, such as a nominating committee.

This trend makes it important for Directors to familiarize themselves with the process their organization uses to identify cyber risks as well as the controls to mitigate them. There are a number of widely used frameworks, such as ISO 27001, the Federal Risk Management Framework, and the NIST Cybersecurity Framework (CSF). While they each vary in process, their common goal is to provide an organization with a method to identify organizational risk, designate controls to address those risks and document them so that they can be audited.

At this point, you are probably thinking, “Well, we are OK because our organization already has a risk-based cybersecurity program and has implemented controls to address those issues.” While this may be true, odds are your organization has done nothing about protecting the integrity of firmware on your systems.

What is firmware and why should you care?

Firmware is computer code. Instead of being stored in a hard drive, however, it is stored on a rewriteable chip. It is very powerful code that orchestrates how the different hardware and software components on a system interact with each other. What is worrisome about a firmware compromise is that firmware sits below operating systems and driver layers. Because it is the “traffic cop” telling the components what to do, firmware can fool anything on the system – including your existing security tools – into thinking everything is working fine. The problem is very few organizations pay attention to protecting the firmware. Yours may be one of them.

Last year, ISACA surveyed its IT security members to see what enterprises are doing about firmware security. The survey’s findings [5] are alarming. Here are a just a few:

• More than a 3^rd of enterprises surveyed either are not doing anything about firmware, or just don’t know if they are or not;
• More than a 3^rd of enterprises received no feedback about firmware controls during audits;
• Of enterprises that prioritized security as part of their hardware lifecycle management, 52% said they had at least one incident of malware-infected firmware

Due to its ability to control hardware, cybersecurity exploits against firmware can have serious real-world impact. Examples include the Ukrainian power grid attack [6] in December 2015 and the recent reports that Apple “severed ties” [7] with one of its server vendors after discovering compromised firmware in servers it was testing in its Siri development lab.

How does firmware get “compromised”?

Firmware can become "compromised" in one of two ways: 1) a bad actor can replace legitimate vendor firmware with malware that purports to legitimate; or 2) a new vulnerability is discovered in the legitimate vendor firmware that came with the system. If you are running compromised firmware on your systems, attackers can steal from you, listen in on your conversations, or simply bring down your systems. This risk will persist unless you physically flash the chip that stores the firmware. It is easy to see these firmware risks can lead to a reportable breach, potential service disruption, reputational damage and financial liability.

In developing your cyber security program, you likely quantified the risk to your organization if your data is stolen or your infrastructure is shut down. Yet, has your organization looked at those risks in the context of firmware controls? Since only 13% of respondents to the ISACA Survey said they have fully implemented firmware controls, you may not have addressed risks of compromised firmware in your cybersecurity plan.

What firmware controls are considered best practice?

Some quick background information is in order. Among the responsibilities of the National Institute of Standards and Technology (NIST) is developing security guidelines and controls for commercial and federal entities. The NIST “gold standard” for cybersecurity controls is NIST Special Publication 800-53 and 53A, currently entitled “ Security and Privacy Controls for Federal Information Systems and Organizations.” Of course, given that title, most organizations look at NIST SP 800-53 as “nice-to-have” set of controls from which they can pick and choose, but not as applicable outside the Federal space. Rather, organizations tend to look at sector-specific regulations that may call for controls targeted at certain industries.

That is about to change.

NIST is expected to publish DRAFT Revision 5 of NIST SP 800-53. Among the announced changes, they are removing the word “federal” from the publication and changing “information systems” to just “systems.” The new document will be called “Security and Privacy Controls for Systems and Organizations.” NIST’s stated goal is for organizations to use their cybersecurity framework of choice to develop a risk-based cyber security program that incorporates the applicable controls in NIST SP 800-53. This change does away with any argument that sector specific controls are the baseline for an organization in a particular industry. Instead, NIST SP 800-53 should now be viewed as baseline for best practices, with additional controls aimed at specific risks associated with that industry.

How NIST SP 800-53 helps mitigate firmware risk

NIST SP 800-53 can very quickly help your organization identify best practices when it comes to firmware integrity management. As you begin thinking about firmware in the context of your organization’s risk-based cybersecurity program, keep these concepts from NIST in the back of your mind:

• Firmware is a computer program or data stored in hardware;
• Malware includes firmware that performs unauthorized actions that will adversely impact on your organization; and
• Firmware is a fundamental building block of any system.

Thus, controls to mitigate risks of compromised firmware are woven into the fabric of NIST’s approach.

he first step is to include the risk of compromised firmware as part of your risk assessment process. Generally, the following broad concepts apply across all risk assessment frameworks:

Plan
Identify and document asset vulnerabilities
Establish and maintain a Baseline configuration
Establish and implement a vulnerability management plan

Continuously Monitor
Use integrity checking mechanism to verify firmware integrity

Detect and remediate
Detect and analyze events and determine their impact
Detect Malicious Code
Test detection processes

Adding firmware to your risk assessment process allows your organization to understand the potential vulnerabilities in your assets. From there, you define your baseline configurations. Once defined, you can continuously monitor your firmware to detect malicious code and add firmware related steps into your Incident Response Plan.

With your risks identified, you can use NIST SP 800-53 to develop specific baseline firmware controls, particularly when it comes to patching and monitoring for unauthorized changes. The main NIST SP 800-53 control “families” applicable to firmware are:

• “Security Assessment” (CA)
• “Configuration Management” (CM)
• “System and Service Acquisition” (SA)
• “System and Information Integrity” (SI)

While there are references to firmware throughout the controls, these are key controls that apply to firmware:

• CA-7: Continuous Monitoring
• CM-6: Configuration Settings
• CM-8(3): Automated Unauthorized Component Detection
• SA-10(1): Software / Firmware Integrity Verification
• SC-34(3): Hardware-Based Protection
• SI-2: Flaw Remediation
• SI-2(6): Removal of Previous Versions of Software/ Firmware
• SI-3: Malicious Code Detection
• SI-7: Software, Firmware, and Information Integrity
• SI-7 (1): Integrity Checks
• SI-7 (2): Automated Notifications of Integrity Violations
• SI-7 (3): Centrally-managed Integrity Tools
• SI-7 (4): Tamper-Evident Packaging
• SI-7 (5): Automated Response to Integrity Violations
• SI-7 (6): Cryptographic Protection
• SI-7 (7): Integration of Detection and Response
• SI-7 (8): Auditing Capability for Significant Events
• SI-7 (9): Verify Boot Process
• SI-7 (10): Protection of Boot Firmware
• SI-7 (11): Confined Environments with Limited Privileges
• SI-7 (12): Integrity Verification
• SI-7 (13): Code Execution in Protected Environments
• SI-7 (14): Binary or Machine Executable Code
• SI-7 (15): Code Authentication

As a Board Member, you are not expected to know the details of these controls. You should at least know they exist and are available to help organizations mitigate the risks of compromised firmware. Taken together, these controls support a program that continuously monitors configurations and verifies integrity to detect unauthorized changes in firmware or report firmware with known vulnerabilities.

By ensuring your organization is implementing the NIST SP 800-53 firmware controls as part your risk-based Cybersecurity Program, you can effectively answer to these questions from Shareholders, Regulators and Customers:

Vulnerability Assessment

• Are we running compromised firmware?
• How do we know?
• Continuous Monitoring & Cybersecurity

Event Detection

• Can we detect compromised firmware?
• What tools are we using?

Incident Response

• Can we respond to the presence of compromised firmware on our systems?
• What steps do we take?

Third Party Risk Assessment

• What are our 3^rd party suppliers/partners doing about their risk of compromised firmware?
• When was the last time we checked?

Audit Trail

• Do our systems have audit trails to detect and respond to firmware Cybersecurity Events?
• Can I have a report for the last 12 months?

Board/Senior Management Compliance

• In good faith, can I say to ur stakeholders that we are addressing the risks in our environment if we are not monitoring the firmware?
• Why aren’t we looking?

All in, it comes down to a very simple question:
How can you trust your software if you can’t trust your hardware?

José E. González is co-founder and CEO of Trapezoid, Inc. , which offers solutions focused on monitoring, detecting and responding to firmware that is compromised either through unauthorized changes or newly discovered vulnerabilities. His LinkedIn profile can be viewed at https://www.linkedin.com/in/jegonzalez/ . For more information contact Trapezoid at info@trapezoid.com .