We checked various manufacturer websites and found recent Intel ME driver and updates. For example, Lenovo has an Intel ME firmware update with a release date of 11/08/2017 and Asus has a new ME update tool with a release date of 11/09/207. This would be consistent with OEMs releasing updates for their systems in anticipation of the Black Hat briefing.
Although this attack requires physical access to the system, the actual attack would be totally invisible to the user any security tools monitoring the system.
Consequently, we urge you to:
José E. González | November 13, 2017
What is the Impact?
What can you do?
Contact us at firstname.lastname@example.org for assistance.
Although specifics will not be available until the Black Hat briefing, the articles indicate that attackers can introduce any code into the ME and execute it thanks to a design decision that connects the ME to a PC's USB subsystem to enable a debugging mechanism. This would mean the anyone with physical access to a system running a Skylake processor may have the ability to exploit a significant firmware vulnerability.
Developing a NY DFS Cybersecurity Program? Pay attention to firmware.
José E. González | March 1, 2017
What is firmware and why should I care?
Today, the “Cybersecurity Requirements for Financial Services Companies” adopted by the NY State Dept. of Financial Services (DFS) goes into effect (the “NY Cyber Rule”). A quick internet search will result in many excellent high-level analyses of the NY Cyber Rule, its general requirements and potential impact on impacted organizations. This post is designed to supplement those articles by highlighting why organizations need to include firmware security controls as part of a Cybersecurity program that complies with the NY Cyber Rule. In particular, Board members, Senior Officers and Chief Information Security Officers (CISO) must consider the potential impact of firmware exploits when signing off on a Cybersecurity Program that complies with the NY Cyber Rule. Failure to do so may have personal consequences.
Firmware is everywhere; from servers in the data center to the “smart” light bulbs that were just connected to your office network. Basically, firmware is just software that happens to be stored in non-volatile memory on a device, but it is still programmable software. This powerful code persists from device restart to restart, sitting below operating systems and driver layers where it can fool anything else on the system – including existing security tools – into thinking everything is working fine.
Programmable code you load on a hard drive and interact with directly is “software.” Code that is physically hardwired into the chips on the system and cannot be programmed is part of the “hardware.” Code that is stored in non-volatile memory on a chip but can be reprogrammed sits somewhere between software and hardware – that’s “firmware.”
Firmware’s essential function is to control how software (operating systems and applications) interacts with hardware (keyboard, screen, storage, network). Think of it like controls in a basement that manage the core systems of a house (electricity, HVAC, alarm, cable & internet).
Currently the cybersecurity industry is focused on protecting applications, networks and data; in our house analogy, they guard the front and back doors, and the windows on the first and second floor.
The problem is that very few people are paying attention to protecting the firmware. To continue our analogy, that means that while you are sitting in your living room feeling safe and secure, your basement door is wide open and anyone could walk right in and take control of your systems – and you would never know!
Due to its ability to control hardware, cybersecurity exploits against firmware can have very serious real-world impact. One disturbing example of the potential severity of firmware breaches is the cyber attack on the Ukrainian power grid in 2015 (and maybe 2016), where the perpetrators uploaded firmware malware to prevent breakers tripped as part of the attack from being reset remotely.This rogue code required workers to travel to the affected industrial controls systems and manually reset them, seriously delaying recovery from the attack.
At this point you may be wondering if I’m citing a 2015 state-sponsored attack in a blatant attempt to invoke FUD. I’m not; firmware related issues have serious financial consequences in day-to-day business operations.
In fact, last year ISACA surveyed its IT security members to see what enterprises are doing about firmware security. The survey’s findings are alarming. Here are a just a few:
More than a 3rd of enterprises surveyed either are not doing anything about firmware, or just don’t know if they are or not;
Over a third 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
The report has additional insights about what organizations are (and aren’t) doing about firmware security so I highly recommend you read the whole thing.
OK, it’s theoretically possible, but, really, what could possibly happen?
For example, in late February 2017 reports surfaced that in November 2016 Apple “severed ties” with one of its server vendors after discovering compromised firmware in servers it was testing in its Siri development lab.
Had Apple not implemented processes and procedures to detect the presence of compromised firmware, it could very easily have deployed it within its Siri infrastructure and made itself vulnerable to an attack against this popular service.
The reports are unclear as to the specific nature of the problem Apple found – some refer to malware, others to vulnerabilities. At Trapezoid we use the term “compromised firmware” because it covers both situations: a bad actor introduces malware into the firmware code or a manufacturer discovers a vulnerability in its firmware that requires patching.
Apparently, the formal name of the NY Cyber Rule – the Cybersecurity Requirements for Financial Services Companies – has led some organizations to believe it does not apply to them because they are not “financial services companies.” The rule applies to any entity that is supervised by the NY DFS, which are more than just financial services companies. For more detailed information regarding what entities the DFS supervises please see http://www.dfs.ny.gov/about/whowesupervise.htm.
The NY Cyber Rule applies to New York State-chartered or licensed banks, insurance companies, licensed lenders, check cashers, money transmitters, and their holding companies, and other firms that are licensed by, operating under approval orders of, or otherwise subject to regulation by the DFS (“Covered Entities”). It requires that Covered Entities develop and maintain a Cybersecurity program, policies and procedures, as well as a third-party service provider security policy. Most importantly for our analysis, the NY Cyber Rule further requires that the Covered Entity’s Board of Directors or Senior Officer personally annually certify that the Cybersecurity Program meets all the requirement of the NY Cyber Rule.
But there’s nothing in NY Cyber Rule that talks about firmware so I don't have to worry about it, right?
However, rather than prescribing specific controls that a Covered Entity must include as part of its Cybersecurity Program, the NY Cyber Rule establishes a risk-based approach for developing a Cybersecurity Program that best addresses the Covered Entity’s risk profile. This means that, just like a risk assessment under the HIPAA Security Rule, even when specific items such as firmware exploits are not mentioned in the rule, they must still be evaluated based on the potential risk to the organization.
Think of the NY Cyber Rule as a regulatory wrapper that essentially mandates that Covered Entities use industry recognized best practices and frameworks like the NIST Cybersecurity Framework or ISO 27000 series to develop their risk-based Cybersecurity Programs.
Your Premium Car Dealership Just Got New Cars!
Meanwhile, NIST is currently revising its Special Publication 800-53 to remove
“the term ‘federal’ from its guidance to facilitate inclusiveness for all types of organizations (e.g., state, local, and tribal governments, industry, academia) and promotes the view that security and privacy are national areas of concern, not just for the federal government.”
This makes the extensive set of NIST controls applicable to firmware – e.g. SI-7 “Software, Firmware, and Information Integrity” (1-15) – “best practice” for all organizations, including Covered Entities.
Interrelationship among the NY Cyber Rule and existing Frameworks
Note that the NY Cyber Rule extends this risk analysis to the potential risks posed by a Covered Entity’s third party service providers. This includes not just technology providers, but lawyers, accountants and other consultants that have access to Non-Public Information.
You said something about “personal consequences”?
“Completion of an annual certification of compliance is likely to be costly for Covered Entities and will require senior officer(s) of such Entities to obtain actual, perhaps extensive knowledge of compliance systems and controls. Prior DFS statements in connection with the issuance of the Revised Proposal suggest that a Covered Entity's certifying senior officer(s) and/or directors could be held personally liable for perceived compliance shortcomings.”
As we’ve seen, firmware exploits can have some very serious consequences. In performing the required risk assessment, a Covered Entity should analyze the potential adverse impacts of firmware exploits: e.g. data exfiltration, intellectual property theft, eavesdropping on video/telephony systems, destruction of core operational systems and persistent attack vectors.
The organizational risk from any of these potential events could include reportable breaches under the NY Cyber Rule, service disruption or complete outage, reputational damage and ultimately financial liability. Given that the NIST firmware controls are specifically designed to mitigate those risks, it would be wise to include applicable controls as part of the final Cybersecurity Program. Should a Covered Entity’s decide not to include controls for firmware exploits in its Cybersecurity Program, it should clearly document why lack of firmware monitoring is an acceptable risk, or what other controls sufficiently mitigate against the risk of firmware exploits.
Unless it has done the above analysis and properly documented its findings, if a Covered Entity suffers a material firmware-related Cybersecurity Event (defined at 23 N.Y.C.R.R. Part 500.01(d)) the Directors or Senior Officer certifying NY Cyber Rule compliance could be held personally liable:
CONTINUOUS MONITORING & CYBERSECURITY EVENT DETECTION
THIRD PARTY RISK ASSESSMENT
BOARD/SENIOR MANAGEMENT CERTIFICATION of COMPLIANCE
Got it! What should I ask about firmware as part of our annual certification process?
As a Director, Senior Officer or CISO, you can show you took due care and used industry best practices regarding firmware risks by developing your Cybersecurity Program that uses frameworks like the NIST CSF and controls like those in NIST SP 800-53 and 800-53A. Ultimately you want to be able to answer these questions as part of your annual certification process:
In the end, it really 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 here or at email@example.com.