- 구글 클라우드, 구글 워크스페이스용 제미나이 사이드 패널에 한국어 지원 추가
- The best MagSafe accessories of 2024: Expert tested and reviewed
- Threads will show you more from accounts you follow now - like Bluesky already does
- OpenAI updates GPT-4o, reclaiming its crown for best AI model
- Nile unwraps NaaS security features for enterprise customers
Firmware Monitoring is Just a Snapshot Away
Any time the television news presents a story about cybersecurity, there is always a video of a large data center with thousands of blinking lights. Even most cybersecurity blogs will include an image of many lights on the front panels of servers, routers, and other hardware. However, most people don’t notice that the lights are usually green or some shade of blue. Rarely are those lights yellow or red, signaling a problem.
Firmware problems
Just as a red traffic light is the signal to stop, few things raise the blood pressure of a sysadmin faster than a hardware, or worse, a firmware problem. A hardware problem is usually easy to remedy by just removing the failed part and replacing it. Firmware problems, however, are not only more difficult to remedy, but they are often overlooked while researching another likely cause for the failure. When discovered firmware changes/updates always cause downtime. Many times, a malicious firmware change is just a timebomb waiting for a reboot. Thus, it is so important to have a baseline of your firmware and know when it has been modified.
Firmware problems are not limited to end-of-life or simple malfunction events. Sometimes, firmware can be an attack vector, as seen in at least one high-profile attack, as well as another incident with potential long-term consequences. A recent report released by the Foundation for Defense of Democracies (FDD) points out the dearth of attention paid to firmware by most government mandates.
It is interesting to note that firmware is not overlooked in NIST documentation. For example, NIST SP800-53 specifically states:
SI-7 SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY
Control
- Employ integrity verification tools to detect unauthorized changes to the following software, firmware, and information: [Assignment: organization-defined software, firmware, and information]; and
- Take the following actions when unauthorized changes to the software, firmware, and information are detected: [Assignment: organization-defined actions].
While government organizations must adhere to the NIST guidance, the FDD article points out that even the mention of the word “firmware” is notably underused in many regulations. Is this because firmware is impossible to monitor? Perhaps, as with the AcidRain attack, it is just easier to throw away the hardware. A full replacement is not as easy as it sounds since the firmware configuration of one device is not necessarily the same on another, even if that firmware is from the same manufacturer.
Firmware Monitoring with Tripwire Enterprise
What makes firmware so different from software or hardware? The main difference is that firmware is not a file in the same sense as software or hardware configurations. This means that it cannot be monitored in real time. However, firmware monitoring is possible. Tripwire Enterprise (TE) can capture the contents of firmware using Command Output Capture Rules (COCR).
In the modern world of real-time analysis and remediation, it is difficult to consider the problem of static firmware monitoring. However – as any sysadmin elder can attest – prior to the age of real-time monitoring, benchmarking was the only way to monitor for changes. The difference between real-time and benchmarking is that it is impossible to know when a change took place; it is only possible to see that something happened between one snapshot in time and the next. Is this good enough to protect against the perils of wiper software such as AcidRain?
As an example, imagine that an attacker gains the ability to exploit a vulnerability and places some malicious code in volatile RAM, which could trigger a “write to firmware” at some point and then a reboot. TE enables you to set up a firmware check at reboot and a periodic check throughout the day. A change would be evident in one of the periodic check snapshots:
Rather than wondering if a specific hardware component has failed, leading to a step-by-step isolation and testing exercise, Command Output Capture Rules pinpoint that the failure of a device is the result of a firmware modification. This can save time as well as act as a beacon that an active attack is underway. Notice that TE COCR can be set to monitor both Windows and Linux-based devices.
Firmware is just as much a target as any software or hardware. Unfortunately, it is often overlooked, even when something goes wrong. When the lights on a device change from green to red, it is more typical to troubleshoot from the assumption of a software or hardware failure rather than a firmware alteration. With Tripwire Enterprise, firmware monitoring is not out of reach.
Contact us to see how we can help reduce your troubleshooting steps and make your organization safer.