Category: #leadership

The Most Powerful Word A CSO Can Say Is No

A Tale Of Two Extremes

A few weeks ago I was sitting across the dinner table from a CIO and a CISO who were discussing how security works within their specific businesses. The CIO was complaining that the security team had unreasonable processes that slowed down his ability to deliver new technology projects within his org and as a result he ignored a lot of their requests. This resulted in an engaging discussion about the best way to balance security requirements against the needs of the business. I found it interesting that some of my fellow CISOs were adamant about having teams meet security requirements without exception, regardless of the impact to the business.

After this discussion I spent some time thinking about own my stance on this issue and how I have tried to balance security requirements against the needs of the business over the course of my career. I pride myself on finding ways to partner with and support the business, instead of just telling them no all the time. However, I have also found that sometimes the most powerful word in my vocabulary is NO. Saying no is particularly useful during the rollout of new processes or security controls where you are changing behavior more than you are implementing a new technology.

Tug Of War

Security requirements and business needs can often be in a perpetual tug of war. This isn’t necessarily a bad thing when you consider the purpose of a CISO organization is to help protect the business not only from attackers, but often from itself. However, it can be difficult when the tug of war is biased towards one side or the other. If the business simply steam rolls and ignores all security requirements then clearly the CISO isn’t valued and the business isn’t interested in managing risk. However, if the CISO says no to everything, then this can be a significant and costly drag on the business in terms of people, processes, technology and time. Lost productivity, lost revenue, inability to deliver a product to market quickly can be difficult to measure, but have real impact to the business. Worse, the business may just ignore you. It is important for CISOs to find an appropriate balance to allowing the business to function, while meeting the desired security objectives to protect it. I firmly believe when done correctly, CISOs can avoid being a drag on the business and can actually enable it.

Just Say No

Despite my general inclination to find ways to keep the business moving forward, I’ve also found saying no to certain things can be extremely useful. For some things, when teams want an exception I usually say no as my initial response. I have found often teams just need to hear an exception isn’t an option and this unblocks them to pursue another alternative to the problem. As a result the teams improve their security while also delivering their business objectives.

Sometimes the teams will ask for an exception a second time. In these cases, I usually reconsider, but often still tell them no. My expectation after telling them no a second time is to either get them to fix the issue or if the issue can’t be fixed to present a plan with different options along with their recommendation. When teams come back for the third time it ends up being an actual business risk discussion instead of an exception discussion. The outcome usually ends up being some sort of compromise on both sides, which is exactly what you want. Taking a balanced approach develops an appropriate level of partnership between security and the rest of the business where one side isn’t always sacrificing their objectives for the other side.

Seriously, Just Say No

Next time a team comes to you with an exception request try saying no and see if they respond differently. You may or may not be surprised when they find an alternate solution that doesn’t require an exception. For me, it has become a powerful tool to nudge teams towards achieving my security goals, while still delivering on their business objectives.

Leadership During An Incident

At some point in your CSO career you are going to have to deal with and lead through an incident. Here are some things I have found helpful.

Know Your Role

Unless you work at a very small company, I argue your role is not to be hands on keyboard during an incident. You shouldn’t be looking up hashes, checking logs, etc. Your role is to coordinate resources, focus efforts and cognitively offload your team from key decisions. You need to lead people during this chaotic event.

Declaring An Actual Incident

This may vary depending on company size and type, but in general the CSO should not be the one to declare a security incident. The CSO (and their representatives) can certainly advise and recommend, but declaring an incident carries legal, regulatory and business ramifications that should be made by a combination of the Chief Legal Counsel and some representation of C-Suite members (CEO, CTO, etc.). Once an incident is declared, your company will most likely need to disclose it on SEC forms and customers may need to be notified. All of this could impact your company’s reputation, stock price and customer goodwill.

Use A War Room

A war room is simply a place where everyone can gather for updates, questions, etc. It is a place that is dedicated to this function. If you are physically in the office, it is a dedicated conference room that has privacy from onlookers. If you have a virtual team it is a Zoom, Teams, WebEx, etc. that gets created and shared with people that need to know.

The CSO’s role in the war room is to keep the war room active and focused. Once the war room is created and the right people join, everyone should discuss what happened, what is impacted and what the course of action should be. Document this somewhere and pin it to the appropriate channels. If people join and start asking basic questions, send them away to read the existing documentation first. If people want to have a detailed technical discussion then send them to a breakout room. The point is to keep the main room clear for making decisions and directing resources.

Bridge The Gap

Your role during an incident is two fold – 1) Communicate to other leaders within the company about what happened so you can get the appropriate support to resolve the incident and 2) Direct the appropriate resources to focus on resolving the incident quickly, while following appropriate chain of evidence, legal requirements, customer notifications, etc.

Communicating To Executive Leadership and the Board
 

Keep it short and sweet so they can respond as needed. The purpose of this email is to inform them so they can give you the support you and your team need. Make sure to invoke legal privilege and keep the audience small (I discuss this in my post about Legal Privilege).

I use the following email template when communicating about an incident.

Subject: PRIVILEGED – Security Incident In [Product/Service X]

A security incident was detected at [Date / Time] in [product x] resulting in [data breach/ransomware/etc.] At this time the cause of the incident is suspected to be [x]. Customer impact is [low/medium/high/critical].

The security team and impacted product team are actively working to resolve the incident by [doing x]. This resolution is expected [at date / time x].

For any questions please reach out to me directly or join the war room [here].

Next update to this audience in [x time period].

Communicating To Responders
 

Your job here is to get the team any resources they need, offload them from decisions and then get out of their way. It is also important that you buffer them from any distractions and protect them from burnout by enforcing handoffs and reminding people to take breaks. It is easy for your team to get caught up in the excitement and sacrifice their personal well being. Learn to recognize the signs of fatigue and have resource contingency plans in place so you can shift resources as needed to keep the overall investigation and response on track.

Designate someone to help coordinate logistics like meeting times, capturing notes, etc. Capture action items, who owns the action item and when the next update or expected completion time will be.

Have A Backup Plan An Practice Using Them

Hope for the best and prepare for the worst. Can your incident response team still function if your messaging service is down? What if your paging program doesn’t work or you can’t stand up a virtual war room? Part of your incident response playbooks should include fallback plans for out of band communications in the event of a total disruption of productivity services at your company. Practice using these during table top exercises so everyone knows the protocols for when to fall back on them if needed.

Wrapping Up

Incidents are both exciting and stressful. It is up to the CSO to lead from the front and provide guidance to their team, executive leadership and the rest of the organization. CSO’s need to buffer their teams to allow them to focus on the task at hand, while protecting them from burnout. CSO’s also need to remember the conduct and response of the organization could be recalled in court some day so following appropriate evidence collection, notification guidelines and legal best practices are a must.