Tim Brown’s Next Chapter—and Why Cyber Crisis Readiness Cannot Depend on Luck
By Michael Hiskey
Former SolarWinds CISO Tim Brown reflects on the SUNBURST incident, the realities of managing a cyber crisis, and why preparation, coordination, and practiced response matter as much as prevention.
When Michael Hiskey reconnected with Tim Brown at the Yale University Club in New York City, the conversation covered more than Brown’s experience as the former CISO of SolarWinds during the SUNBURST cyberattack. It also explored his next chapter as Chief Strategy Officer at Cytactic and a lesson every security leader should take seriously: an organization’s ability to manage a cyber crisis should never depend on luck.
Brown’s experience has given him a valuable perspective on what happens when a major incident moves beyond the security team and becomes an enterprise-wide crisis. His willingness to speak candidly about that experience has helped other security leaders consider what they might face—and whether their organizations are prepared to respond.
Reflecting on the role that luck played in certain aspects of the response, Brown put it simply: “Pure luck, right, as opposed to practice.”
For CISOs, the distinction is critical. Security programs often focus on preventing attacks, detecting threats, and reducing exposure. But even mature organizations must consider what happens when those defenses are breached. How quickly can leadership make decisions? Who coordinates legal, communications, technical, and business response efforts? And have those responsibilities been practiced before the pressure of a real incident arrives?
The CISO Cannot Manage a Crisis Alone
One of the clearest lessons from Brown’s experience is that a major cyber incident quickly becomes bigger than the CISO’s ability to manage it independently.
Security leaders may expect to coordinate the response, but a serious incident requires simultaneous action across legal, executive leadership, communications, operations, and outside advisers. Each group brings different responsibilities, priorities, and decision-making requirements. Without a clear structure, coordination itself can become another challenge during an already difficult event.
Brown described how that played out during the SolarWinds incident:
“As the CISO you think you will be the one who coordinates the response. That just wasn’t possible. DLA Piper scheduled our meetings. DLA Piper acted as our quarterback.”
The experience underscores the importance of defining crisis leadership and decision-making authority in advance. A CISO may lead the technical response, but enterprise crisis management requires a broader team and a clear understanding of who is responsible for bringing the different workstreams together.
In Brown’s case, DLA Piper helped organize the response, with Ron Plesco serving as crisis coordinator. That external coordination played an important role in bringing the necessary people together and helping the organization navigate an exceptionally demanding situation.
The lesson is not that every organization needs to replicate the same structure. It is that every organization needs a structure that works for its circumstances—and that its leaders understand before an incident occurs.
The Gap Between Having a Plan and Being Ready
This is the challenge Cytactic is working to address through its focus on Cyber Incident Response Management: helping organizations prepare for, coordinate, and manage cyber crises.
During the conversation, Cytactic founder Nimrod Kozlovski highlighted a familiar problem. Organizations can find themselves assembling advisers, clarifying authority, and determining how to coordinate their response at the very moment they should be focused on managing the incident.
As Kozlovski observed, “It sounds to me that’s the scenario you were supposed to plan for.”
That point gets to the heart of crisis readiness. Having an incident response document does not necessarily mean an organization is prepared to execute it. Plans can outline procedures and responsibilities, but a real incident tests whether people know their roles, whether decisions can be made quickly, and whether the organization can bring the right expertise to bear under pressure.
Preparation means understanding the process, establishing responsibilities, building relationships with outside partners, and practicing how the organization will work together. It also means recognizing that the response may not unfold exactly as expected.
Brown’s experience reinforces the value of doing this work before a crisis. Familiarity with the process and the people involved can reduce confusion when time is limited and the consequences of a poor decision are significant.
Importantly, preparation should not be confused with a guarantee of a particular legal or regulatory outcome. Brown pushed back on the suggestion that simply getting ahead of the news cycle would have prevented the SEC case. The broader lesson is that organizations need to prepare to make sound decisions and manage the consequences of an incident—not assume that one communications strategy can control every outcome.
Transparency and Practice Matter
Another important theme from Brown’s experience was the role of transparency and leadership tone. During a major incident, an organization’s response is shaped not only by its technical actions but also by the decisions and priorities communicated by senior leadership.
Brown recalled the message from the SolarWinds CEO: “The tone from the CEO was to help customers anywhere you can.”
That emphasis highlights how executive leadership can influence the response, particularly when customers and other stakeholders are affected. Clear priorities help teams understand what matters, while coordinated communications help the organization respond more consistently.
But transparency and leadership direction are only part of the equation. Teams must also be able to execute.
Tabletop exercises are a valuable tool, but their effectiveness depends on how realistically they test an organization’s readiness. Walking through a hypothetical scenario is useful; discovering whether people can actually reach the right colleagues, access the necessary plans, obtain decisions, coordinate with external advisers, and communicate under pressure is even more revealing.
A useful exercise should expose operational gaps before those gaps become real-world problems. It should test the organization’s ability to make decisions and adapt as circumstances change—not simply confirm that a response plan exists.
What Security Leaders Should Take Away
Brown’s experience offers several practical lessons for CISOs and the executive teams responsible for enterprise resilience:
- Define responsibilities before an incident. Establish who leads the technical response, who coordinates the broader crisis, and who has authority to make key business and communications decisions.
- Build relationships in advance. Identify external legal, crisis-management, communications, and other advisers before they are urgently needed.
- Practice the actual work of responding. Use exercises to test communications, access to critical information, decision-making, escalation, and coordination across teams.
- Prepare for uncertainty. A response plan should provide structure without assuming that every incident will follow a predictable path.
- Measure readiness, not just prevention. Evaluate whether the organization can respond and recover effectively, in addition to assessing how well it works to prevent and detect attacks.
These steps do not eliminate risk, and they cannot guarantee that a crisis will be contained without consequences. They can, however, help organizations avoid losing valuable time to confusion and untested assumptions when the stakes are highest.
Comments
Preparing for the Incidents You Cannot Prevent
As cyber threats evolve and AI introduces new capabilities for both attackers and defenders, the need for effective incident response remains fundamental. Even organizations with substantial investments in security cannot assume that every attack will be stopped.
Brown captured the challenge directly: “We’re not going to be able to stop everything, and we need to be able to respond and recover with as limited damage as we can.”
That is a realistic approach to cyber resilience. Prevention remains essential, but organizations must also be ready to manage incidents, make difficult decisions, communicate clearly, and recover while conditions are changing.
For security leaders, the question is not simply whether an incident response plan exists. It is whether the organization can put that plan into practice when it matters most.
Brown’s experience at SolarWinds—and his work at Cytactic—reinforces a message that deserves attention across the C-suite: crisis readiness is built before the crisis begins.
The CxO Security Forum brings together senior cybersecurity, technology, risk, compliance, and other executive leaders for candid, peer-led conversations about the challenges organizations face today. These discussions provide an opportunity to share practical lessons, challenge assumptions, and learn how fellow leaders are preparing for the incidents no organization can afford to handle by luck alone.
6. Which Model Did You Approve?
Identity is only part of the challenge. The model itself matters, too.
A workflow tested against one model may behave differently after an upgrade, a model change, or a deprecation. Even if the business process remains unchanged, the application’s behavior may not.
That creates a governance question that traditional software change management does not always address in the same way: what happens when a component responsible for interpreting instructions and choosing actions changes?
If an agent has access to sensitive systems, a change in model behavior could affect how it uses that access.
Organizations should therefore consider model version, provenance, evaluation, and change management as part of the broader security design. Knowing which model was approved is a starting point, but it does not eliminate the need to test whether that model remains appropriate for the intended application.
Tim also challenged the group to learn more about open-weight models and deployment on infrastructure an organization controls. That led to a related discussion about cost and architecture.
His observation was concise:
“I think about watts per transaction.”
The point was to think about the practical economics of running AI workloads, not simply the headline cost of a model or service.
Local deployment may offer meaningful control over infrastructure and data flows, but it also introduces engineering, operational, and security responsibilities. The right choice depends on the workload, its requirements, the data involved, and the organization’s ability to manage the environment.
Tim’s ModelDNA project offers a place to explore model lineage and provenance. Understanding what model was obtained and where it came from is an important part of evaluation, but provenance does not replace testing for a particular use case.
For security leaders, the broader takeaway is that AI governance needs to account for both identity and the changing software components that exercise that identity.
7. Accounts, Access, and Accountability
As the conversation came to a close, three questions provided a useful way to organize the issues discussed throughout the afternoon.
Accounts: Do we know which identities exist and who owns them?
This includes human users, service accounts, application identities, machine identities, and AI agents. Each should have a defined purpose, an accountable owner, and a clear lifecycle.
Access: What can each identity do, and how much authority is actually necessary?
Organizations need to understand permissions in context, reduce excessive privilege, and consider whether access should be permanent or granted only when required. They also need to distinguish between an identity’s ability to access information and its authority to take a particular action.
Accountability: Can we explain who approved an action, what actually acted, and why the action was allowed?
This requires meaningful audit trails, documented policies, appropriate logging, and a clear distinction between human decisions and automated activity.
These questions are not unique to AI. They are the foundations of effective identity and access management.
What has changed is the urgency with which organizations need to answer them.
The closing discussion about applying just-in-time privilege to AI agents highlighted the implementation challenges still ahead. Controls designed around a human approval process, a physical interaction, or a hardware token do not automatically translate to software that can operate autonomously.
The answer will not be one product, one policy, or one new acronym. It will require organizations to connect identity management, data governance, security operations, legal oversight, and AI development practices.
Most importantly, it requires security leaders to make deliberate decisions about the authority they are granting.
8. What Should CISOs Do Next?
The conversation generated plenty of questions that deserve further discussion, but there is a straightforward way to start.
Choose one AI agent or automated workflow already operating in your environment. It does not have to be the most sophisticated or the most strategically important system. In fact, a relatively simple example may be the best place to begin.
Then trace its identity, permissions, and activity all the way through.
Ask who owns it, which credentials it uses, which systems it can reach, what data it can retrieve, what actions it can perform, and whether it can interact with external destinations.
Determine whether it operates under a dedicated identity or inherits a person’s permissions. Establish whether its actions are logged in a way that distinguishes the agent from the person who initiated the work. Identify what would happen if its credentials were compromised or its behavior changed unexpectedly.
Finally, ask whether the organization could explain its activity to an incident-response team, general counsel, a regulator, or an affected customer.
If the answer is unclear, you have found a useful starting point.
That exercise may reveal gaps in ownership, excessive privilege, undocumented integrations, weak audit trails, or contractual questions that have not been addressed. Those findings are valuable because they turn an abstract discussion about AI risk into a specific set of improvements.
It also gives the organization a practical foundation for evaluating additional agents before they are introduced into more sensitive environments.
The objective is not to prevent every use of AI or to treat every agent as inherently dangerous. It is to make sure that the authority granted to an agent is deliberate, limited, visible, and accountable.
The Value of the Peer Conversation
One of the reasons I value the CxO Security Forum format is that it gives practitioners room to examine these issues without turning every discussion into a product demonstration.
The questions raised during this session were practical, sometimes uncomfortable, and directly relevant to the decisions security leaders are making now. The discussion moved naturally from identity fundamentals to incident response, legal obligations, emerging solutions, privilege management, and model governance.
No one left with every implementation question resolved. That was never the objective.
The value was in connecting problems that are often handled separately and identifying the questions that deserve attention before an incident forces the issue.
My thanks to our hosts at DLA Piper, our partners at Ambient Security and AWS Startups, our discussion leaders, and everyone who contributed candidly. A special thank-you to John Bryson of Western Alliance Bank for his continued support of the community, and to Jeff Klein and the exemplary DLA Piper team for helping make the gathering possible.
As AI agents become more capable, organizations will need to think carefully about the relationship between identity, authority, and accountability.
An agent may have valid credentials. It may be operating exactly as its software was designed to operate. It may even be using permissions that have existed for years.
None of those facts, on their own, establishes that the action it takes is appropriate.
The question is no longer simply whether your AI agent has access. It is who gave it that authority, what limits govern its decisions, and whether you can explain what it did when it matters most.
We called about your agent. Could you explain what it did?
That is a conversation worth having before the incident begins.
Comments
I welcome your input on this article… please do that via the summary LinkedIn post on this same topic!