Wireshark security risk and how to manage it

A couple of social media influencers got into an argument over banning Wireshark in corporate environments because Wireshark is a security risk. While I don’t like getting involved in this type of drama, the argument does raise an important point in information security and vulnerability management. It’s very important as a security professional not to overplay the hand you’re dealt.

The Wireshark drama

The drama started when a Twitter personality who made her name talking about her day job as a network engineer said that if she worked in an environment where Wireshark was banned and you had to get special permission to install it every time you needed it, and then you had to immediately uninstall it when you were finished, that she would simply quit.

This caused a flurry of activity, to the surprise of no one. I think these types of posts are what help people build or maintain followers.

One of the people piling on was another influencer, a CISO. A CISO, if you are not familiar with that term, is a Chief Information Security Officer, typically the head of security in an organization. The CISO bragged that he banned Wireshark where he works.

Now, there was a nuance in what this CISO said that I think a lot of people missed. He banned it for non-IT personnel, which I would tend to agree with. I think most of us who work in security or IT would agree that non-IT personnel don’t need Wireshark. I would disagree pretty strongly with an outright ban.

But there were people weighing in who suggested there were companies who did have more widespread bans on Wireshark, including within IT departments.

So let’s go through the arguments.

The concept of least functionality

The CISO justified his actions using the concept of least functionality. The theory behind this is that a computer should have only the amount of software installed and enabled for it to do its job, and anything beyond that is an unacceptable security risk.

This is a principle frequently used in the military, and I note the CISO mentions having a Marine Corps background in his profile.

I spent nearly 7 years working for defense contractors on Air Force contracts. Part of my job was making sure the POSIX subsystem was disabled on Windows servers, which was something I always found ironic because Microsoft implemented the POSIX subsystem to make it easier to get government contracts.

But my job wasn’t to comment on the rules, it was find ways to comply as quickly and easily as possible.

So we did, and I was rather successful at it. We had fewer than one security incident per year. Part of that was due to least functionality. A bigger part of it was that I was extremely good at patch management.

The slippery slope

But the concept of least functionality is a slippery slope. I own a very secure computer. It’s secure because it doesn’t boot. I could make it more secure by encasing it in lead and burying it in my back yard. It sounds ridiculous, but that is taking the concept of least functionality to its logical extreme.

And when I was working on that Air Force contract, we had a fight over least functionality. The security analysts wanted us to remove Microsoft Excel from all of our servers. I was in favor of that, because it meant fewer copies of Excel I had to patch every month.

My boss disagreed, and he argued we should install Excel on every server, because there were times when he needed to use Excel to edit some data and restore a malfunctioning server with that edited data.

You’ve probably seen this playbook before. When presented with an unreasonable edict, take an equally unreasonable position on the other side, positioning yourself to compromise somewhere in between. And theoretically, the harder line you take, the more reasonable the compromise ends up being, from your point of view.

The compromise

In our case, leaving Excel installed on a very small number of servers ended up being the compromise. Nobody was thrilled with that outcome. But when you talk to people who negotiate for a living, the usual outcome of a good negotiation is no one being completely happy with the outcome. No one got their preferred outcome, but overall we ended up in a better place.

My experience with Wireshark security risks

In between my time working for the government and working for security vendors, I was a successful vulnerability management professional in corporate environments. One of the reasons I was successful was because I was good at looking at a vulnerability backlog and identifying the root cause behind the 10 biggest contributors to that mountain of tech debt.

One of those contributors was Wireshark. Like any piece of software, it receives regular security updates because of vulnerability disclosures.

The Wireshark compromise

And when I brought up Wireshark, the IT directors were the first ones to speak up. They told me in no uncertain terms that their people needed Wireshark in order to do their jobs.

I said I believed them. My only ask was that if they install Wireshark someplace for troubleshooting purposes, that they uninstall it after they no longer need it. And if they need Wireshark someplace for the long term, that’s completely understandable. Just keep it up to date when they find it.

Depending on what tools you have, keeping Wireshark up to date can be easy or it can be difficult. In their case, it wasn’t easy. But because I was patient with them, they found ways to manage Wireshark and keep it up to date.

The benefits from compromising

Because the IT staff saw me as reasonable and trusted me, they weren’t afraid to tell me things. And one of the things I learned from talking to them was there were things that bothered us as a security department that bothered them as well. Sometimes for different reasons. But that didn’t matter. We were able to take what they knew along with what I knew, and build a strong argument for fixing those problems.

Conceding a small amount of risk by not making a big deal about Wireshark allowed me to fix much greater problems. It would be wrong for me to elaborate too much. But known vulnerabilities are a much bigger problem than unknown vulnerabilities that will be disclosed in the future. Giving up a little bit of ground on Wireshark gave me the political capital I needed to fix notorious vulnerabilities that are a much bigger deal than Wireshark. I won’t disclose the details, but you can use your imagination. You won’t be too far off.

Had I taken the hard line of never compromising on security, they could have and would have pocket vetoed me. Then I would have gotten none of what I wanted. Like I tell my kids, getting some of what you want, or most of what you want, is a lot better than getting none of what you want.

How to know when you are over playing your hand

It can be difficult to know when you approach security with too heavy of a hand or too soft. I can think of a time in my career when in I didn’t get the job because one potential employer saw me as too heavyhanded and the next saw me as too soft. That happened in back-to-back interviews within a week of each other. I found the in-between place and learned from the experience, so it’s all good.

The way you thread that needle is to use the 85% rule. The 85% rule states that if 85% of the population will comply, then it’s a good rule. But the further away you are from an 85% compliance rate, the less enforceable that rule or policy will be.

Examples of the 85% rule

Prohibition and the national 55 mph speed limit are two examples of notorious US laws that failed to get 85% compliance from the general population. That’s why both ultimately failed.

Fireworks laws are a good contemporary example. On New Year’s Eve and Independence Day, those laws are unenforcable in the United States. But if someone randomly starts shooting off fireworks one night, especially if it’s not within 30 days of either of those holidays, the police will respond if someone calls them. Especially if it’s really late at night or it’s during a drought.

So while I cite the 85% rule, I don’t think you need to measure it precisely. You have a pretty good idea when you’re over or under that threshold.

Who’s right about these Wireshark security risks?

So it is possible that both the network engineer who says she’d quit if they took Wireshark away from her, and someone who banned it outright are both right.

The network engineer is taking a very mainstream stance. IT engineers are paid to solve problems quickly. So when you make policies that stand in the way of them solving problems quickly, three things happen. Your outages last longer. Your company loses profits. And the best people get frustrated and leave. Not to mention when security policies stand in the way of people getting their jobs done, the people who don’t quit will find ways around it.

But one who takes the other extreme and bans Wireshark outright might also be right. If 85% of the company is willing to comply with that policy, then I can’t say they’re doing their job wrong. It means they’re a good fit for that company, and the other people working there are a good fit. This would be rare, but not completely inconceivable.

But in my experience, just going in and banning a tool and making life more difficult for operations types isn’t something that’s universally going to end well. I’ve seen it end poorly, but I’m not comfortable elaborating on that much.

It’s certainly possible to convince yourself that a heavy-handed approach is always the right answer, or that a laissez-faire approach is always the right answer. The answer is usually somewhere in between, and to some degree it’s environmental. In either case and in all cases in between, the 85% rule is useful for keeping yourself out of trouble. Because eventually, a policy of never, ever compromising will catch up with you.

Legal stuff

This blog post is solely my opinion and was neither solicited nor endorsed by my current employer or any former employer. If any of them have strong opinions on this matter, they may have weighed in on their own blogs, or on social media.