Felipe Medina   |   January 12, 2018


It’s been about a week now since Meltdown and Spectre. Here’s what you need to know:


There are no confirmed threats out in the wild being exploited right now. However, for Windows 8 or 10 most fixes to applications, AV and the OS kernels, require either a manual update or hacking your registry. Thus, Windows 7 does not have the update automatically come in yet. MacOS is resolute, upgrade to Sierra to patch Spectre; but if you want Meltdown protections at the kernel you must update your OS to High Sierra 10.13.2. See the article here.

After a fair amount of research and grinding, Microsoft has released a tool you can run in Powershell. However, thanks to Microsoft , user Andy Bentley has compiled an executable you can use to check the update. You can download the verification tool here and use version 20 or 30 for Windows 7, 8 and 10. 


Below is a screenshot of an unverified system once this script or executable has been run. 

Windows 7:

For Windows 7 you can download the appropriate version of the update for your system from Microsoft’s update catalog here. 

Once applied and your system restarts, check your system again with the script above. When completed, you should see the following on your system that is now patched:

Windows 8 & 10

For Windows 10 there is an automatic update which requires you to change the registry that will allow automatic updates to show as an out of band patch.

The keys to add and remove automatic updates on Windows 8 or 10 are below:

To enable the fix *

  • reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
  • reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for changes to take effect.

To disable the fix *

  • reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
  • reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for changes to take effect. (There is no need to change MinVmVersionForCpuBasedMitigations.)

Cylance Script:

There’s also a script you can download from Cylance to simplify the registry edits needed. (Please note that this requires you have a Cylance account for support).

Once the registry is updated and the Windows 8 or 10 computer has been rebooted, simply check for available updates . Once completed, verify using the above script to ensure the updates applied have taken effect. You can also manually download Windows 8, 10 and server updates from Microsoft’s Update Catalog.

Finally, beware that if your AV vendor is not compatible, the registry update could bluescreen your windows pc/server.  Before doing anything, 1) back up, and 2) test it in your own lab. 

Stay Safe! We hope this information helps our community. 


...beware that if your AV vendor is not compatible, the registry update could bluescreen your windows pc/server.  






Felipe Medina   |   January 5, 2018

So, by now you have heard that a flaw present in most modern Computer Processing Units (CPU) produced in the last decade will require operating system (OS) kernels and system firmware to be overhauled. This flaw is easily exploitable to obtain information from databases, applications and processes running on the system due to the way the CPUs pre-process instructions and access system memory. 

The immediate fix is to update the different OS kernels and applicable firmware. However, some security experts are suggesting that the only real fix is to replace all CPU’s as the only mitigation. In any case, this presents a serious operational challenge to all organizations, including cloud service providers. For example, Azure, AWS and Google have notified customers of major ongoing security updates in the upcoming weeks related to this issue. 

And not all devices can be updated. All Apple devices are vulnerable at this time but the kernel fixes will only apply to the latest IOS, macOS and tvOS operating systems. Devices that cannot run the latest OS versions will remain vulnerable.

It is also important to note that there are some needed changes in antivirus tools to properly inspect virtual memory and access. In addition, organizations must now continuously monitor their environments to ensure they are running the latest OS kernel and firmware combinations.

First of all, reports indicate that no known exploits have been found at this time. But that just means that none have been detected or seen by security companies or organizations.  In fact, the disclosures include proof-of-concept code that is probably being tested by bad actors as you read this.

Second, OS kernel changes will be a software level change meaning that the underlying hardware will likely remain vulnerable unless firmware patches are released by the hardware manufacturers and OEM. In fact, security analysts fear that many cheap IoT devices will never be updated.

This will remain a critical issue for months to come because of the sheer amount of hardware that needs to be properly inventoried, updated, monitored and potentially replaced to really enact a proper remediation. Visibility will be key in knowing not only what clean-up has been done, but also what remediation is still needed. 

1) Trapezoid’s Firmware Integrity Verification Engine (FIVE) is designed to continuously monitor the firmware regardless of manufacturer or OEM.

2) Trapezoid FIVE can maintain an inventory of hardware platforms and firmware revisions over time to detect whether your systems are threatened by this critical vulnerability and others like it.

3) Trapezoid can leverage multiple integrity measurement technologies from different OEM’s to identify changes that could be indicators of compromise and remotely attest to the integrity of your systems.

If you would like to discuss

contact us at info@trapezoid.com.


Below are some links with detailed information regarding these vulnerabilities.

So now what?

How can Trapezoid help?

What can you do?

José E. González   |   November 13, 2017



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.

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.

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.

What is the Impact?

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:

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

Contact us at info@trapezoid.com for assistance.


Developing a NY DFS Cybersecurity Program?  Pay attention to firmware.

José E. González   |   March 1, 2017

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.

What is firmware and why should I care?

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!

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.

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. 

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.

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?

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.  

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.

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:

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

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:  


  • 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?

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 info@trapezoid.com.