Askhat - stock.adobe.com
Kiteworks CISO: Why We Shut Down Systems Before Finding Vulnerability
A federal warning prompted the vendor to take systems offline before confirming a breach -- a decision that exposes difficult questions about downtime and risk.
A warning from federal authorities about a potentially imminent cyberattack prompted the secure file-sharing vendor Kiteworks to recommend that customers shut down production systems for nine hours in late September.
The company also took the systems it hosts offline, acting on threat intelligence before a breach had been confirmed.
During that window, Kiteworks discovered and patched a critical vulnerability involving Advanced Forms, its secure data collection and web form feature. The company subsequently reported no evidence of compromise and restored its hosted services.
In the aftermath of the incident, Kiteworks CISO Frank Balonis told TechTarget that authorities monitoring known threat actors provided a warning whose source and timing warranted immediate action -- even though the company did not yet know how an attack might unfold.
"At that point, we did not know precisely how the threat actors planned to exploit Kiteworks," Balonis said. "Given the sensitivity of the data our customers manage with [us], we concluded that, out of an abundance of caution, a shutdown was preferable to the alternative."
The move highlights a rare, seemingly counterintuitive business decision in the SaaS industry: accepting guaranteed operational disruption to eliminate exposure to unconfirmed breaches.
While this proactive response successfully led to a critical patch, security experts say contractual SLA penalties, competitive pressure and fear of customer backlash make it unlikely that other vendors will follow suit.
Federal intelligence drove the shutdown decision
Balonis said the warning came from federal authorities monitoring known threat actors across dark web forums and similar communities. He declined to identify the authorities involved.
The finding that fewer than 1% of customers had the affected capability emerged during the investigation, rather than informing the initial decision to opt for a temporary shutdown.
"The 1% figure was unknown at the time and therefore irrelevant to the decision," Balonis explained.
Asked whether the disruption was disproportionate, he maintained that credible intelligence required action before investigators understood the threat's extent.
Kiteworks did not provide publishable figures on how many customers followed the recommendation, declined it or incurred disruption, nor on the company's financial costs or service-level agreement penalties.
"With information this credible, a potential exploit is not a moment to hope for the best or to ask forgiveness later," Balonis said.
Weighing precautionary downtime against risk of a breach
The timing of the decision matters more than whether subsequent findings made the shutdown appear broader than necessary, according to Philip Harris, research director for governance, risk and compliance solutions at IDC.
"The decision has to be made before the information that would make it precise is available," Harris said.
He considered the company-specific federal warning sufficient grounds for precautionary action. A vague warning to an entire industry would not meet the same threshold.
"This is a business risk optimization problem, not a technical one," Harris said.
He recommended leaders estimate both outage losses and potential breach consequences before a crisis, using exercises to test recovery assumptions and establish tolerable downtime. Otherwise, the immediate, visible cost of an outage can overshadow a less certain but more damaging outcome.
Kiteworks' history gives that calculation additional weight. Formerly known as Accellion, the company experienced attacks against its legacy File Transfer Appliance beginning in 2020, documented in a joint federal advisory. Harris viewed that institutional experience as relevant.
"Nine hours of downtime is a known, bounded, recoverable cost," Harris said. "A successful mass exploitation against a secure file-transfer platform holding sensitive customer data is not."
Shutdown authority, contracts need advance planning
Harris argued boards should delegate shutdown authority to a standing crisis team before an incident. Security, technology and business leaders bring different judgments about threat credibility, dependencies, revenue and customer exposure.
He also identified contractual penalties, customer churn and short-term revenue pressure as barriers to other vendors taking similar action. Contracts should explicitly address precautionary security interruptions and accompanying evidence and communication requirements, he said.
Robert Coles, senior cybersecurity engineer at application security firm Black Duck, likewise argued against treating shutdown authority as an exclusively technical responsibility.
"The decision should be made jointly by security, operations, legal, and executive leadership, as the implications extend well beyond cybersecurity," Coles said.
From Coles' perspective, the business case depends on whether available mitigations adequately reduce exposure. A temporary outage can be the lower-risk choice, but the existence of a threat does not settle the question.
"A full shutdown should not be the default response," he said, adding isolation, feature disablement, access restrictions and emergency patching should be considered before disrupting service.
Targeted isolation depends on threat knowledge
Mayuresh Dani, security research manager at Qualys Threat Research Unit, distinguished between confidence in an intelligence source and knowledge of the appropriate response.
"Credibility answers 'should I act?', whereas specificity will help you answer, 'How should I act?'" Dani said.
A broad shutdown is easier to justify when intelligence identifies an actor with a history of mass exploitation, a near-term attack window, and exposure that cannot be scoped, he noted.
Targeted isolation requires knowing which component is exposed, having a way to disable or restrict it, and ensuring that doing so will not damage data integrity.
Dani also distinguished hosted services from customer-operated infrastructure.
"For self-hosted systems, the vendor can only recommend a precautionary shutdown, whereas a CISO should have the authority to order downtime on hosted infrastructure," he said.
Before restoration, customers should receive actionable information, including indicators of compromise, the fixed build and instructions for verifying its installation, Dani said. Finding a vulnerability provides a concrete remediation outcome, but it does not establish what an attacker would otherwise have accomplished.
Customers must weigh their own operational risks
Steven Swift, managing director at Suzu Labs, emphasized that customers must make their own operational risk assessments.
"There's a huge difference between a vendor advising that the only effective mitigation is to shut things down, and a business deciding that they should take that action," Swift said.
Vendors may appropriately recommend a shutdown when no adequate compensating control exists. Customers nevertheless need to weigh that recommendation against the consequences of interrupting their operations.
Swift said he favors preparing mitigations, testing detections and reviewing response plans so teams can act quickly when relevant indicators emerge. Where technically effective, disabling a specific feature is easier to explain to users than a complete outage.
"Being a security leader means being comfortable accepting that risk is unavoidable," Swift said. "There is no perfect solution -- there is risk in both taking action and in not taking action."
