• Review your systems inventory to determine if you have any systems using Skylake processors;
  • For all Skylake systems, check the manufacturer’s support site to see if there is a recent Intel ME firmware update, probably with a November date.  
  • If so, follow their instructions regarding applying that update as soon as possible.  
  • If not, we recommend you either sign up for email notifications or check the support site frequently.

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?

In the past few days we have seen published articles discussing a newly discovered vulnerability in the Intel Management Engine (ME) firmware on Skylake processors (released in 2015). Online pubs reporting this include The Next Web, Gadgets and Techspot.

What can you do?

One of the articles indicates that Positive Technologies, the research firm that discovered the vulnerability, is set to reveal its findings at the annual Black Hat Europe Conference for the IT security industry, which begins on December 4. Black Hat offers an official summary to the briefing.

Contact us at 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  

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.” 

(Emphasis added.) 

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:


  • Are we running compromised firmware?
  • How do we know?


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


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


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


  • Do our systems have audit trails to detect and respond to firmware “Cybersecurity Events that have a reasonable likelihood of materially harming any material part of [our] normal operations”?
  • Can I have a report for the last 12 months?


  • Can I, in good faith, certify that we are addressing the risks in our environment if we are not monitoring the firmware?
  • Why aren’t we looking?

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 For more information contact Trapezoid here  or at