Firmware, CVEs and Vulnerability Management for AV

Why an AV engineer should care

AV systems live in an awkward place: they are networked computers expected to behave like permanently installed appliances.

IT may want every security update installed immediately. Operations may want nothing touched because the system currently works. Both positions make sense—and both become dangerous when treated as absolutes.

The goal is not “always update” or “never update.” It is:

Understand the exposure, prioritize the risk, preserve a rollback path, and verify the AV system afterward.

Learning objectives

By the end of this lesson, you should be able to:

• Distinguish a CVE identifier from a CVSS score and confirmed exploitation.
• Prioritize AV vulnerabilities using exposure and operational impact.
• Prepare an AV system for a safe firmware update.
• Validate networked AV functions after an update.
• Define useful vulnerability-management requirements for BMT projects.

---

1. Firmware is software wearing work boots

A switch, DSP, encoder or control processor contains software even when the manufacturer calls it firmware.

That may include:

• Operating system
• Web server
• SSH server
• Network protocol stacks
• Device-management services
• Media-processing code
• Control application
• Bootloader
• Third-party software libraries

A vulnerability in one bundled library can affect many products. The AV manufacturer may not have written the vulnerable component, but it still must provide an updated product image containing the fix.

Update terminology

Manufacturers use these terms inconsistently, but generally:

• Patch: Narrow fix for a specific problem.
• Maintenance release: Collection of bug and security fixes.
• Feature release: Adds capabilities and may change behavior.
• Firmware upgrade: Replaces much of the device’s operating software.
• Bootloader update: Changes the low-level software that starts the device.
• Hotfix: Targeted fix released outside the normal schedule.

Do not assume “firmware 10” is simply “firmware 9, but safer.” A major release may introduce different configuration behavior, file formats or companion-software requirements.

---

2. CVE, CVSS and KEV are three different things

CVE: the identification number

A CVE, or Common Vulnerabilities and Exposures identifier, gives a publicly disclosed vulnerability a unique name.

Example:

CVE-YYYY-NNNNN (illustrative format, not a cited vulnerability)

The number does not tell you whether the vulnerability is severe or whether it affects your exact product configuration. It gives manufacturers, researchers and customers a common reference.

Think of CVE as the case number.

CVSS: estimated technical severity

The Common Vulnerability Scoring System produces a severity score, normally from 0.0 to 10.0.

It considers technical characteristics such as:

• Whether the attack can be performed remotely
• Whether authentication is required
• Attack complexity
• User interaction
• Effect on confidentiality, integrity and availability

A score of 9.8 gets attention, but it does not automatically mean “patch every affected device tonight.”

NIST explicitly states that CVSS measures severity, not organizational risk. (nvd.nist.gov) Risk also depends on:

• Is the service enabled?
• Is the device reachable from the internet?
• Can normal users reach its management interface?
• Is there a working exploit?
• What could an attacker control?
• What happens if the update breaks the AV system?
• Are compensating controls already reducing exposure?

KEV: confirmed exploitation

CISA’s Known Exploited Vulnerabilities Catalog contains vulnerabilities for which there is evidence of real-world exploitation.

That is a major priority signal. A theoretically severe vulnerability and a vulnerability attackers are actively using are not the same operational situation. CISA recommends using the KEV catalog as an input to vulnerability prioritization. (cisa.gov) A useful mental model is:

• CVE: Which vulnerability?
• CVSS: How technically severe could it be?
• KEV: Are attackers actually exploiting it?
• Your architecture: Can they reach it, and what could they damage?

---

3. Prioritizing an AV vulnerability

Use four questions.

1. Is the affected feature present and enabled?

A bulletin might concern:

• Web management
• SSH
• Bluetooth
• USB file import
• Vendor cloud connection
• A discovery protocol
• A specific software library

If the affected service is disabled, the device may still technically contain the vulnerable code, but immediate exposure is lower.

2. Who can reach the device?

Exposure increases roughly in this order:

1. Directly reachable from the internet
2. Reachable through a vendor cloud or remote-access system
3. Reachable from the general corporate network
4. Reachable only from a restricted AV management VLAN
5. Physically isolated with no active network connection

Segmentation does not erase a vulnerability. It can provide time to test and schedule remediation safely.

3. What can exploitation accomplish?

Possible outcomes include:

• Read configuration information
• Steal credentials
• Change settings
• Execute arbitrary code
• Interrupt audio or video
• Move laterally into other networks
• Permanently damage configuration
• Use the AV device as a launching point

A denial-of-service vulnerability on a lobby signage player and remote code execution on the core switch are not equal business risks, even if their numerical scores appear similar.

4. What is the update risk?

Consider:

• Is the release recommended by the manufacturer?
• Is it a stable maintenance release or a new feature train?
• Does it require intermediate upgrade steps?
• Does it change configuration syntax?
• Does it require a new version of the programming software?
• Can the previous image and configuration be restored?
• Is console access available if networking fails?
• Has the update been tested on equivalent hardware?

This produces a practical priority:

---

4. The AV-safe update workflow

NIST defines patch management as identifying, prioritizing, acquiring, installing and verifying updates. It treats patching as preventive maintenance—not a random late-night adventure. (csrc.nist.gov) For AV, use the following workflow.

Step 1: Inventory

Record:

• Manufacturer and model
• Serial number
• Current firmware and bootloader
• Companion-software version
• Configuration or project-file version
• IP address and hostname
• Support and warranty status
• Installed options or licenses
• Known dependencies

SNMP may automatically collect some firmware and inventory information, depending on what the product exposes.

Step 2: Read the release notes

Look for:

• Security fixes
• Known problems
• Required upgrade path
• Hardware-revision limitations
• Configuration conversion
• Downgrade restrictions
• Companion-software requirements
• Factory-reset warnings
• Cluster, stack or redundant-system procedure

“New firmware available” is not sufficient engineering information.

Step 3: Capture the known-good state

Before touching the device:

• Export its configuration.
• Save the programming source file.
• Record current firmware.
• Back up certificates where supported.
• Capture licenses and activation information.
• Save switch running and startup configurations.
• Photograph or export important status pages.
• Confirm access to the old firmware image.
• Confirm the recovery or console procedure.

A backup is not a rollback plan unless you know how to restore it.

Step 4: Test or stage

Where possible:

• Test on spare or equivalent hardware.
• Load a copied configuration.
• Confirm device discovery and control.
• Verify interoperability with surrounding equipment.
• Let it run long enough to reveal obvious stability issues.

Smaller projects may not have spare hardware. In that case, increase preparation, schedule on-site support and avoid updating immediately before an important event.

Step 5: Establish the maintenance window

Define:

• Systems affected
• Expected outage
• Responsible technician
• Client approval
• Recovery threshold
• Rollback decision time
• On-site or remote coverage
• Post-update test list

Do not update the sports bar’s video core two hours before Sunday kickoff because the release notes used the word “recommended.”

Step 6: Install in the documented order

The correct order varies.

A manufacturer might require:

• Management server before endpoints
• Controller before peripherals
• Stack members in a specific sequence
• Intermediate firmware before the current release
• Application software upgraded before opening the project

Follow the product-specific procedure. There is no universal “always update the core first” rule.

Step 7: Validate the entire AV workflow

A green power LED is not acceptance testing.

Confirm:

• Device boots and retains its configuration
• Management login and certificates work
• Control interfaces operate
• Audio passes correctly
• Video routes and HDCP function
• USB extension works where used
• Dante or AES67 subscriptions recover
• PTP clock status is stable
• Multicast receivers join and leave correctly
• IGMP querier and snooping remain correct
• VLANs and trunks are unchanged
• PoE endpoints power correctly
• SNMP polling and syslog resume
• Remote access still works
• Redundancy or failover operates where applicable

Then record the new version and archive the post-update configuration.

---

5. Commercial-AV examples

Example 1: Ruckus ICX switch carrying AVoIP

A new FastIron release includes security fixes. The switch is also carrying multicast video and PoE endpoints.

Before updating, BMT should capture:

• Running and startup configuration
• Boot preference and both firmware-image slots
• VLANs and tagged/untagged port assignments
• IGMP snooping and querier configuration
• Spanning-tree state
• PoE status
• SFP DOM readings
• Port error and discard counters
• LLDP neighbors

Afterward, test multicast routing and receiver changes—not merely internet connectivity. Also confirm that the switch booted the intended image. Loading firmware into secondary flash is not useful if the boot command quietly returns to the old version.

Example 2: Q-SYS, Crestron or Biamp platform update

A processor update may require a matching designer or programming-software version.

Before upgrading:

• Preserve the editable source project.
• Confirm that the new software can open and deploy it.
• Identify plugins, scripts or modules that may be incompatible.
• Verify that a converted project can be downgraded—or save an untouched copy.
• Confirm touchpanels, peripherals and control modules support the target release.

A processor that boots successfully but no longer communicates with a third-party display is not a successful update.

---

BMT standards takeaway

Add a Software and Support Register to project closeout records:

• Product and model
• Installed firmware
• Configuration-tool version
• Latest tested BMT version
• Vendor support status
• Security-advisory URL
• Configuration-backup location
• Upgrade and recovery procedure
• Last review date
• Responsible party
• Known dependencies

Specifications should also require manufacturers to disclose:

• Security-support period
• Vulnerability-reporting contact
• Firmware-update process
• Whether configurations survive updates
• Whether downgrade is supported
• End-of-support notification policy

Practical exercise

Choose one active AV product and find its current firmware and release notes.

Without installing anything, write down:

1. Current installed version
2. Available target version
3. Security issues fixed
4. Required intermediate versions
5. Configuration backup method
6. Rollback method
7. Companion-software requirement
8. Five post-update tests

Then decide: urgent, prompt, routine or defer with compensating controls.

The point is to make a defensible decision—not reflexively click Update All and hope the building respects your confidence.

Compact glossary

• CVE: Unique identifier for a publicly disclosed vulnerability.
• CVSS: Technical-severity scoring system; not a complete risk score.
• KEV: CISA catalog of vulnerabilities with known exploitation.
• Firmware: Software embedded in a device.
• Exploit: Technique or code that takes advantage of a vulnerability.
• Compensating control: Protection that reduces risk without removing the underlying vulnerability.
• EOL: End of Life.
• EOS: End of Support or End of Sale, depending on the manufacturer.
• Rollback: Restoring the previous software and configuration.
• Maintenance window: Approved period for potentially disruptive work.

Review questions

1. Why should BMT not prioritize vulnerabilities using CVSS alone?
2. What is the difference between a configuration backup and a rollback plan?
3. What does presence in CISA’s KEV catalog tell you?

Answers

1. CVSS estimates technical severity but does not include BMT’s exposure, architecture, operational impact or compensating controls.
2. A backup is stored data; a rollback plan includes the previous image, restoration procedure, access method, decision point and validation steps.
3. There is evidence that attackers have exploited the vulnerability in real-world conditions, making remediation a higher priority.

Where we are headed

We have now completed the first networking and security foundation. Lesson 18 will be the requested practical USB primer: USB 2.0 versus USB 3.x, cameras, conferencing, USB-C, Power Delivery, DisplayPort Alt Mode, extension limits and why USB over AVoIP can become a bandwidth and topology problem.