JPMorganChase’s “200 Days Into the Frontier” and What It Means for Exposure Management

JPMorganChase's Global Technology Leadership Team says vulnerability discovery and attack automation are moving much faster than remediation. The bank laid that out on November 2 in "200 days into the frontier: What we know and what to do now," a post written for CEOs. One question it puts to CEOs is this: if a material vulnerability emerged tomorrow, what would stop the company from acting within hours?

The November 2 post follows JPMorganChase's April memo, a list of 10 actions for AI-ready cyber resilience, which we recommended every security team read. It says those April actions remain important foundations and builds on them with a framework for CEOs in three parts: change assumptions, shorten decision cycles and build resilience. 

The November 2 post also says AI magnifies risks that organizations have accumulated over time, such as outdated technology and remediation timelines built for a slower environment, and that complexity itself has become a security risk. Several of the new post's recommendations, including measuring execution speed and tracking unsupported technology, fall to CISOs and vulnerability management (VM) teams.

Three questions for every asset in your inventory

JPMorganChase says to start with a complete, current inventory of software and hardware, then prioritize what's in it by asking three questions:

1. How exposed is it? Can it be reached directly from the internet?
2. Can we protect it? Can it still receive timely security fixes?
3. What is the impact? Could a compromise or failure affect customers, disrupt critical operations or impede recovery?

These questions give a VM team a simple way to sort a large inventory. An asset that is reachable from the internet, can no longer get security fixes and supports a critical service belongs at the top of the list. The bank calls unsupported technology a time-sensitive business liability and says every exception should have an accountable owner, funding, compensating controls and a dated exit plan.

PHP shows all three questions at once

The bank's example of unsupported software is PHP, the programming language behind WordPress, Drupal, Joomla and Magento. The recent PHP2Shell flaws show how that plays out. On October 20, two critical PHP vulnerabilities leaked ahead of their coordinated release, and PHP shipped fixes the next day. Zafran's research team reported that exploitation attempts climbed from a handful to millions within minutes.

Run PHP2Shell through the three questions and the answers line up. About 1.5 million internet-facing hosts advertise a PHP version. More than half of them run PHP 8.1 or older, which have no fixed release, though PHP published source-only backports for versions 7.4 through 8.1. And many of those hosts run public websites and online stores, where a compromise reaches customers directly.

A patch existed within a day, but more than half of the exposed hosts were on versions with no official fix.

Start at the front door

JPMorganChase also advises reducing how directly the internet can reach firewalls, VPN gateways and other remote-access systems. These devices accept connections from outside the company, so a serious flaw in one can let an attacker straight into the network. The bank recommends placing an independent authentication layer in front of sensitive services, so a single flaw in the service itself is not enough for an attacker to get in.

A mitigation counts as action

For cases with no timely fix, JPMorganChase says leaders should define in advance when an exposed service gets isolated, reduced or taken offline, and give teams clear authority to do it. The April guidance adds a related option: where possible, use perimeter controls such as web application firewalls (WAFs) to block attacks while vulnerable software is being fixed. A control like that is a compensating control, an existing defense such as a firewall rule or WAF policy that blocks the path to a vulnerable system while the patch is pending.

CISA, the U.S. Cybersecurity and Infrastructure Security Agency, has built the same idea into policy. Its Binding Operational Directive 26-04, issued June 10, sets remediation deadlines for federal civilian agencies by risk. For the three-day tier, the directive accepts a mitigation action as meeting the deadline, as our breakdown of the directive explains. Few teams can test and deploy a patch across a fleet in 72 hours. A change to a firewall, WAF or endpoint control can land in minutes.

Decision speed and execution speed need separate measures

Once a team knows which assets matter most, the next question is how fast it can act on them. JPMorganChase separates decision speed, how fast leaders decide to act, from execution speed, how fast that decision becomes a fix in place. An organization can decide to act within hours and still need days or weeks to get a fix deployed. In between sit the steps that fill a VM team's week: working out which systems are affected, finding the accountable owners, testing a patch, securing a change window, coordinating with suppliers, deploying across the estate and confirming the fix worked.

That stretch between decision and action is the widest part of the exposure window, and every step in it adds hours or days.
‍

What CISOs should bring to their CEO

Four items build on JPMorganChase's guidance, and a CISO can put them in front of the CEO this month:

• Keep an inventory that lists software components. The bank's April guidance calls for a software bill of materials (SBOM, a list of every component inside an application) for each application, so teams can answer "where are we exposed?" in minutes.
• Know where outdated or end-of-support (EOS) technology exists, meaning the vendor has stopped issuing security patches. For each item, know whether an exception has been accepted, who owns it, which compensating controls are operating and when it will be upgraded or replaced. JPMorganChase also expects each exception to have funding.
• Write down the conditions under which an exposed service is isolated or taken offline, and who can make that call.
• Report time to confirmed exposure and time to live mitigation alongside time to patch. JPMorganChase says decision speed and execution speed each need their own measure.

‍

How Zafran helps close the execution gap

Zafran speeds up the steps that sit between a decision and a fix, starting with showing which exposures can be exploited in your environment. It builds a software inventory from the tools you already run, and Zafran Discover adds continuous, agentless scanning through your existing endpoint detection and response (EDR) agents. You can see every asset running a given component without waiting for a scanner to publish a detection. For each match, Zafran adds the context that decides what to fix first: whether the software is running, whether the asset is reachable from the internet, and whether your firewall, WAF, or EDR already blocks the path.

For exposures that remain open, Zafran maps them to the controls you already own and, for supported integrations, pushes mitigations through your existing EDR, WAF and firewall tooling with your approval while the patch is tested. During PHP2Shell, Zafran's research team wrote and lab-tested intrusion prevention system (IPS) rules where vendors had not published any. Those rules gave teams a way to block the exploit while they planned an upgrade. 

The remaining fixes go to the right owners as tickets in Jira and ServiceNow. Zafran's zero day agent checks new disclosures against your inventory, flags any asset where data is missing, and lists the actions to take first. 
‍

Measure the gap before the next disclosure

JPMorganChase's November 2 post asks CEOs what would stop the company from acting within hours if a material vulnerability emerged tomorrow. A CISO or VM leader can answer that with measured hours from the company's own last critical vulnerability.

Pick the last critical vulnerability your team handled. Write down the hours from public disclosure to three events: confirmed exposure, a live mitigation and a completed fix. Find the longest gap, because that is where your exposure window stays open. Take the three numbers to your CEO as your measure of execution speed.

Zafran exists to shorten the time between decision and action. When the next critical vulnerability lands, the teams that have already timed the gap will be able to say how fast they can act.