What a security champion is

October is security awareness month. So before you go spend the remaining 11 months of the year blissfully less aware of what security types like me do, let’s talk about what a security champion is, and the role a security champion plays in the IT organization.

What is a security champion?

Turns out I was a security champion for 5 years without having any idea. You probably won’t get any change in job title, you won’t get any kind of special ID or anything else. And in my case, I didn’t know I was a security champion, and neither did the security department where I was working at the time.

I found out I was a security champion two jobs later, when a security analyst asked me about my previous experience, and she said, “Oh, you were a security champion. And now you’ve moved into security.”

So then she introduced me to the security champions at that company, and we got along really well, because we had immediate common ground.

The line between IT and security

There isn’t always a good delineating line between where IT ends and security begins. Some organizations see firewalls as a security device. Some organizations see them as a network device. Whether you put them in the networking team or the security team, they are going to have to interact with people on both sides of the fence.

That means the security team is going to need friendly people on the networking team to work with. Many security initiatives involve firewalls, and they frequently move further into the networking field as well, especially when you start talking about VLANs.

As my blog post about CISSP work experience suggests, there are tons of roles that involve security decisions, and sometimes outright interaction with security departments.

What does a security champion do?

From a security practitioner standpoint, a security champion is a liaison between the security department and the rest of the IT department. It means they trust you to have a greater understanding of security objectives than the average IT professional, and when there is work that requires cooperation between the IT and security departments, the security champion will probably do much of the work on the IT side.

Security champions can expect to be invited to a few meetings that they otherwise wouldn’t be part of, including sometimes working with the security departments to evaluate vendors. Now that I work in the vendor space, there have been times I’ve given products demos to security champions, not just people in the security department.

The security champions may or may not play a part in the final decisions, but if the security champions dislike a particular solution, that’s not generally good news for the vendor.

In my area of specialty, vulnerability management, the security champion is pivotal. Vulnerability management doesn’t act on its findings. It’s not allowed to. They scan stuff and produce metrics and reports, but they have zero control over the outcome they are driving toward. The people who do the patching are security champions, whether they know it or not.

How to become a security champion

There is no single way to become a security champion. One of the questions an incoming CISO will ask, if they are smart, is whether the company has a security champions program. And if the company doesn’t, if the CISO is smart, they will initiate one, and the security team will ask for volunteers or potentially suggest some good candidates.

If your organization doesn’t have a security champions program, or if you aren’t one but would like to become one, have a conversation with a friendly security analyst. They may not know how the program works either, but they can find out.

And I say that it is smart to have a security champions program because frequently the IT and security departments are at odds. When people can’t get their jobs done because of some security initiative, the IT department gets caught in the middle. And let’s just say security teams are not generally known for being very understanding or forgiving. So the IT department and security department are natural enemies in some cases because of this.

A security champions program doesn’t automatically smooth out these conflicts, but it helps.

An example of the security analyst-security champion conversation

One time, when I was working as a security analyst, a security champion asked me what my stance was on network segmentation. He told me network segmentation makes his job much more complicated. He felt comfortable telling me this, because he knew that I had been a system administrator.

I told him he was right, it does make his life more complicated. And that we needed to figure out a balance. Then I went to the whiteboard and drew him a diagram of the cyber kill chain. I explained what the stages were, and I explained that everything my department ever asks the rest of the organization to do is designed to disrupt something on that diagram. I drew an X on the part of the chain where I normally live, vulnerability management, which tries to combat exploitation. And then I drew Xs on the elements that network segmentation interferes with. It interferes with the last step, action on objectives, but I’ll argue it can make life more difficult for the attacker at at least three other stages as well.

It probably wasn’t the answer that he wanted to hear at that moment, but My explanation showed him that it wasn’t just something that one person thought was a good idea. He could see some thought went into it.

From security champion to security professional

IT is stressful, and doesn’t seem to offer a ton of job security. The security field is extremely difficult to get into, and has a ton of gatekeeping, but there aren’t enough security professionals to go around. And there are even fewer qualified security professionals than we need.

Working in the vendor space, I’ve met hundreds of security professionals, if not thousands. I need a computer to keep track of all of the security professionals I’ve met. But let’s just say I don’t need a computer to keep track of the number of security professionals I would hire.

I argue time in the trenches in IT is just as important as classroom time. It’s an unpopular take, but I’ve noticed a big difference in effectiveness between those with field experience in general IT and those with book knowledge in security. Ideally you have both, but it’s easier to get book knowledge than field experience.

From system administrator to vulnerability management

If you are a system administrator and you spend any of your time deploying patches, I would encourage you to consider trying to move into vulnerability management. Get as good at patching as you can, and get some numbers to prove it. My mistake was not knowing what numbers to get, so I didn’t even know if I was good.

Here are the numbers that you need to ask for so you can build your case. Find out what your MTTR is. That is your mean time to remediate. It’s how many days it takes for you to fix something. Also ask what your average vulnerability age is. This tells you how old your backlog is. These are two metrics that your vulnerability management team probably can give you without too much trouble. Get those numbers every month. You want to be able to show a downward trend on both of them. They will have periodic ups and downs, and that’s due to factors that you can’t control, but if you are controlling what you can control, you can keep those two numbers trending in the right direction.

Using KPIs to collaborate to solve a problem as a security champion

Better yet, ask your security team if they are able to provide you with a chart showing what percentage of your vulnerabilities are past due and what percentage are not due yet. This chart tends to be an eye opener for everyone involved, because it is not at all uncommon for 80% of the vulnerabilities in an environment to be past their due date. The goal should be for 15% to be past due and 85% not yet due.

These metrics are related. If 85% of your vulnerabilities are past due, and your security policy says you have 7 days to fix high severity vulnerabilities, and your MTTR is 30 days, that’s the problem. The policy doesn’t reflect the timing of your maintenance windows.

If you, as a security champion, can collaborate on solving this problem, and get good at reading Qualys or Nessus scans and use the information from those scans to improve your MTTR and vulnerability age, and therefore, your compliance with due dates, you have an opportunity. Do that for a year or two, and then start applying for any security analyst role that has words like vulnerability management, Qualys, Nessus, and/or Tenable in the job description. In the interview, talk about how you got good at patching, cite the numbers that prove it, and convince them that you can help other system administrators to improve their game the same way you did.

If it’s an easy sell, congratulations. You found a good fit. If it’s not an easy sell, thank them for their time and move on. You don’t want the job anyway.

The path outside of vulnerability management

If you are not a system administrator, but you are a security champion, there is absolutely nothing wrong with going to lunch one day with the security analyst that you work with and asking them about their job. Security professionals are supposed to help other people move into security, and if you have a good rapport with one, they will generally be happy to answer any questions you have.