Why Veterans Make Great Security Team Members

Every year the United States honors its fallen service members during Memorial Day. As a Navy Veteran, I spent this past memorial day reflecting on my time in service, the memories I’ve taken away and most importantly remembering the people I served with who made the ultimate sacrifice.

I also thought about the incredible number of people that work for me and with me who are veterans. In general, the veterans I have led, worked next to or served under tended to be the best employees, peers or leaders over the course of my career. Here is why I think veterans make great security team members.

Candor

Anyone who has served in the military or had a military family member knows people who have served tell it like it is. This is a carry over from giving and receiving orders in times of stress that need to be clear and concise. It is also a firm belief that life is too short and at some point you need to stop talking and take action.

Veterans aren’t afraid speak up in times of uncertainty because when we were in the military confusion could lead to loss of life. It is better to ask the question and be really clear than to keep quiet and risk disaster.

This candor is particularly important in a security team. Is there a weakness the business doesn’t know about? Are you seeing something anomalous that other people have dismissed? Do you have a new idea that could improve a process or reduce risk to the business? Veterans aren’t afraid to speak up when they have something to say.

Perseverence

No matter what branch of service you come from, all veteran’s made it through some level of training that was more difficult than the civilian life they left behind. Sleep deprivation, physical hardship and generally being uncomfortable are table stakes in the military. This means veterans are hardened against failure and generally hate to lose. They will persevere through difficult tasks and can be relied upon when things become chaotic and difficult. They also seek out training to better themselves and add new skills to their repertoire because they may come in handy in the future.

This perseverance is particularly useful in all aspects of security. Attempting to change a culture to a security first mindset requires incredible perseverance. Similarly, implementing new controls, resolving an incident or passing an audit also requires perseverance. I’ve found the veterans on my team take these events in stride and enter them with the confidence they will accomplish their task.

Perspective

Veterans also possess a unique perspective. This perspective comes from the hardship they endured during the military and carries over to civilian life. No matter how bad the situation gets every veteran thinks back to a time that was worse in the military and says “hey, this isn’t that bad!” Civilian life can be stressful and I’ve certainly had my share of burnout, breakdowns and disillusionment, but every time I think back to my time in the Navy and am thankful I’m not deployed away from my family, I’m not getting shot at and I’m not being asked to do things that could put me in harms way.

This perspective is useful during security incidents, but can also be useful during every day routine engagements with the rest of the business. Security isn’t always going to go perfectly and sometimes this perspective can help you see the big picture, keep calm and work towards a solution.

Willing To Take Risks

It shouldn’t be surprising that veterans are willing to take risks. Everyone who has served took a huge risk by leaving their civilian safety net behind. We deployed to dangerous parts of the world in order to protect our country. Additionally, veterans will tell you they served because of the camaraderie of the people who sat to their left and right. We are willing to take huge personal risk to protect our fellow service members.

This risk taking attitude is useful in the security space because it lets us try new things. We aren’t afraid to fail because we know we will learn from the experience and can try again. We are also willing to put ourselves out there if we know it will result in a better security posture or reduce risk to the business.

Security Mindset

I’ll generalize here, but I think veterans inherently possess a security mindset. We are evaluating strengths and weaknesses of attackers. We are looking at the physical security of spaces. We are considering if a control is good enough to manage the risk or if we need to push harder to secure something. Serving in the military means serving in an organization whose sole purpose is to ensure the security of the nation it protects. This mindset exists at all levels and is readily transferable to the civilian sector.

This shouldn’t be surprising since a large number of veterans often pursue a post military career in law enforcement, the government sector or private security. However, I also find tons of veterans in the IT sector and particularly in the security space. We have a common mentality and it is usually very easy to spot someone else who has served.

Wrapping Up

If you find yourself lucky enough to lead or work with veterans, like I do, then I encourage you to take some time to explore their background and what they did in the military. I’ve often found swapping stories with another veteran is a quick way to build rapport. Their candor, perseverance, perspective and security mindset can be huge assets to your security team and your business.

Centralized vs. De-Centralized Security Team?

Whether you are building a security team from scratch, expanding your team or re-allocating resources, you may be wondering what is more effective – a centralized or decentralized security team? Both have their pros and cons and I’ll discuss them and my experience with each in this blog post.

Centralized Security Team

This is probably the most common structure for a security team. In most organizations it makes sense to group all people doing the same thing into a single org. Sales people, IT, Finance, HR, etc. all get grouped into a single org with an executive leader at the top. For the security team it has some distinct advantages.

First, the CISO has direct control over the resources in their org. The reality is, whoever is responsible for the performance reviews and paycheck for the resource, is the one who actually controls that resource. This may sound obvious, but I have seen a lot of weird matrixed, resource sharing organization structures that quite frankly don’t work. There can only be one leader and centralizing the security resources under a single security org provides direct control of how those resources will be used.

Second, it provides a single point of contact or “front door concept” for the rest of the business. If there is an incident, security question, customer inquiry, etc. everyone knows who to reach out to and who the leader is for the security group. This can allow the CISO to more easily track metrics, measure risk and dynamically adjust priorities based on the needs of the business.

However, the downside of a centralized security organization is it often gives the impression that the rest of the business is absolved of their responsibility for security. I have heard the following from various parts of the rest of the business:

Why isn’t security doing that?

What is security doing if I have to do it?

What are you doing with all those resources?

A centralized security team can exacerbate the confusion about who is ultimately responsible and accountable for security within the organization. Or, the security team is held accountable for the security failings of the rest of the business even though they aren’t responsible for doing the things that will make the business more secure. These shortcomings can be overcome with a strong security first culture and when the CISO has strong relationships with the other business leaders in the org.

De-Centralized Security Team

A de-centralized security team can improve on some of the short comings of a centralized security team, but it also has disadvantages.

First, a de-centralized security team allows the business to place resources close to and often within the team that is actually responsible for doing the thing. Think about fixing software vulnerabilities. If the development team building the software product has security expertise on their team, that resource can help prioritize and even fix some of the issues as part of an embedded team member. They can raise the security performance of the whole team. This can be an efficient way to deploy resources on a limited budget.

A de-centralized security team can also spread the cost of security around the org in an equitable way. If each function is required to embed a few security resources then those resources (and headcount) are allocated to that business function.

The downside of a de-centralized team is loss of control. The CISO may still be held accountable for the security of the business, but they may not control the headcount budget for these embedded resources. If the CISO is able to hold onto the headcount budget, that is great, but it doesn’t prevent another issue – having the resources go native.

In my experience, de-centralized teams can often go native. This means the resource fails to prioritize the security asks of the team, fail to hold the team accountable or simply start doing non-security work when asked to do so by the rest of the team. If the CISO doesn’t control the headcount then this is effectively a lost (or non) security resource. Even if they do control the headcount, they may have to constantly battle and remind the embedded resources to prioritize security work. This is a particularly glaring problem when there is a weak security culture within the rest of the business.

What Should I Choose?

There really is no right answer here, but if I had to choose one over the other I would choose to centralize the security team and then spend a large amount of time with the rest of the org to articulate their responsibility for security. In an ideal world, that has a large enough headcount budget, I would choose both. Keep a core centralized team like incident response and GRC, but de-centralize application security engineers and architects within the teams that do development work. The structure of a centralized team and even a de-centralized team will be highly dependent on the needs of the business and who is ultimately responsible security.

However, the reality is your organization probably grew organically with the rest of the company and at some point you may be wondering if your organization structure is best to support the rest of the business. Shifting from centralized to de-centralized (or vice versa) is not impossible, but will require careful thought on how to deploy and control the resources so they can be effective. My suggestion is to start small, experiment and see what works for your org.

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.