Infosec's Jerk Problem (2013)

Organizations typically fail at security because they try to manage it as far away from the product as possible. That leads security and dev/ops teams to manage their goals in isolations: one cares about preventing incident, the other cares about shipping products.

If Agile & DevOps have taught us anything, it's that everyone in the organization should be focused on serving the customer, be it through features, reliable operations, or data security. The only good way to do infosec is to embed security with devs and ops and make everyone shares the goal of making the product better.

There are no doubt a lot of smart security people with great judgment in the industry. Unfortunately, my experience is that such people are FAR from the majority. (This is true for other non-security segments as well, of course.)

This feels especially strange on the phone, when someone (who later turns out to be legitimate) opens up the conversation by insisting that I prove who I am, _when they're the one that called me!_

"To them, we’re Chicken Little crossed with the IRS crossed with their least favorite elementary-school teacher: always yelling about the sky falling, demanding unquestioning obedience to a laundry list of arcane, seemingly arbitrary rules (password complexity requirements, anyone?) that seem of little consequence, and condescendingly remonstrating anyone who steps out of line."

That is often true.

It might help if security knew what the hell we did. The last three "Java is broken forever!!!" issues, when the problem was with applets, nearly killed me. Or possibly if they knew their job. The last employer's security policy was defined by the latest vendor tool they bought, never mind that it couldn't possibly find any issues in the applications we were writing.

Of course there was the code review I did where I pointed out that it had a giant, monstrous hole in it. The other dev nodded and said, "yeah, that's a good point". But the app had to be in production now, so nothing happened. To escalate, I would have had to go to security, which would be like complaining about a hangnail to an axe murderer. So, nope.

Well, that's a great way to have an honest dialogue.

> You fume for several minutes, cursing all developers everywhere, but no response is forthcoming. Angrily, you stand up and march over to his cube, ready to give him a piece of your mind.

At this point, all you've done in response to finding a serious security issue is to send an email with a very poorly worded and vague title. Why are you getting upset that nobody has reacted to it within a few minutes? I'm also curious as to why Bob would think this email to be unimportant, does InfoSec just use one email subject for everything?

If something's important, people generally turn to synchronous communications, where we can verify that our audience has processed whatever it is we need to tell them. Async communication works just fine on smaller time slices, like chat/IM, but email overall tends to have relatively high latency, especially if you need to communicate a serious security issue.

> Many in the Infosec community are fond of casting the security world as “us versus them,”...

Wait. Is this a joke? Isn't "us versus them" the canonical wrong way to frame just about anything? At the very least, it's obviously the wrong way to approach InfoSec, in addition to virtually any other collaborative effort. This should be obvious if only because you need to work with other people. Conflict does not cooperation make.

> ...he gets lots of “urgent” security emails that turn out to be Windows patches, admonitions to change his password, policy reminders and so on.

That right there is entirely on InfoSec. They're not only boy-who-cried-wolfing, they're doing so with vague subject titles. But that's okay, InfoSec is going to get very upset anyway, because they've failed to properly communicate the severity of the situation, and people are acting accordingly.

> ...and Bob’s demand that you explain the vulnerability is met with your impatient demand to “just do it.”

Ouch. Why does InfoSec not want to share the wonders of 0days? Seriously, one of the most fun things to do is dissect, or read others' dissections of, an 0day. This is great knowledge to share, and I would applaud any developer who takes an interest in security by wishing to understand what security issues are, especially 0days.

Additionally, rejecting someone's request for additional information about a task you've given them is almost universally a bad thing to do. If it's not feasible to grant them the information they desire, it's on you to properly communicate that, don't just rebuff their request. Transparency is great for teamwork.

> Bob... can’t deal with this now, he’s too busy, it’s not his problem (there are other devs, right?) and you should take it up with his manager.

I actually thing this is valid. If a developer does honestly feel to busy, going to their manager (who should be in the loop for security issues anyway) seems like a reasonable escalation. If it's actually an urgent issue, it should be valid to disrupt the manager's day with it just as much as it is to disrupt the developers day.

It seems like it's the same response a developer would give to someone freaking out about a serious bug in their code. If it's a serious issue (developer, for whatever reasons, is unconvinced) then you should take it up with their manager. That's not to say the developer is correct in being unconvinced, but arguing that route is less timely and less likely to actually work.

> The jaundiced attitude among Infosec mentioned above...

When I first read the article, I thought the author was knowingly straw-manning, hence their opening warning about jerks. This seems to indicate otherwise, as the author is seriously referencing their story as something remotely realistic. Either the author's story was a terrible straw man, or I'm very ignorant of how unprofessional my professional compatriots are.

Regardless, the author lays out the solutions:

> Practice active kindness.

That's horoscope level advice. It is good to be nice, but it's not exactly feasible to do all the time to everyone or we'd have solved a great many problems in society a long time ago. Generally speaking, being nice requires some emotional effort, and not everybody has the same capacity for that as everyone else, and those that can afford to do it probably already do. Although I suppose I could believe that an adult capable of being nice all the time simply isn't doing so because nobody suggested to do so...

> Seek to understand and make this clear.

Always great advice, like being kind, but far more actionable and sadly, far more applicative. Yes, communication is critical when working with others, especially when attempting to delegate tasks to others. This should be obvious, but I've found many people to not take this seriously. If you need something done, it's on you to ensure whoever you delegate the task to understands it at least as well as you. You can't fault them for your inability to properly communicate.

One of the saddest things to see is when two or more parties get upset at their own failures at communicating. For example: Bob shouts across the office "Hey Alice, do X" but Alice is listening to music and doesn't hear. Some time passes, then Bob gets upset that Alice has not done X, and Alice gets upset at Bob for being upset that Alice has not done X. Now we've got two parties, both upset over an unfortunate circumstance, with no resolution in sight. Had Bob attempted to confirm his communication, this whole situation could have been avoided. Alice could also do her part by not being upset by Bob's failure at communicating, but emotions are fickle and it's hard to defend yourself stoically when your attackers are fuming with emotions.

Additionally, had Bob confirmed his communication, in the event Alice had still not performed X, Bob can escalate to whatever authority is appropriate with the evidence of Alice's understanding of his request, increasing the odds for meaningful resolution (at least from Bob's perspective).

> Be flexible. Recalibrate “urgent.”

The boy who cried wolf.

> Create stakeholders...

I'd be a little concerned with teams arbitrarily deciding their security goals. They should 100% be involved in the process, but leaving them entirely to their own devices would incentivize them to have terrible security, as that's generally the easiest thing to do.

>... and spread security knowledge.

This is good advice, and it's sad to think it is useful advice. If you're ever in a situation in your life where you need to communicate to another person a task to be performed, you should be more than willing to share information about said task in order to aid in the delegate's efforts. It's an obviously useful thing to do, and it's sad to imagine adults making it through life, surely having many tasks delegated to them by this point, and not understand how valuable additional information about the task can be.

I would be highly concerned if my coworkers did not already understand this. While we all can't have our dream jobs/offices/employers, compromising on communication abilities is pretty much always going to have both bad and unpredictable consequences (you can't easily predict how someone's going to react to (mis)information from poor communication).

> Fixing Infosec’s jerk problem benefits everyone: us, the people we deal with, and ultimately the security of the system — and since that’s our long-term goal, we should actively seek to fix the problem.

I think the easy solution here is to fire those jerks. Seriously. Talk to them about things, ask them why they're doing what they're doing, but this isn't a systemic issue. This is a personal issue. People being jerks can (and will) happen anywhere people are present, and the solution isn't to group everyone in a large category together and then proclaim it a categorical issue that they all must work to resolve. Find the bad apples, deal with them as you would in any other situation. Communicate to them that what they're doing is both technically (security issues are not being fixed in a timely manner) and personally (they're failing to communicate on multiple levels and upsetting people) ineffective. Ensure they understand that their actions are not desirable and are creating a hostile workplace (I never thought I'd say that non-sarcastically...). If they keep doing what they're doing, let them go. If they harbor animosity towards being repressed, let them go. There's a wealth of wonderful people in the world, seek them out instead. Be selective, it doesn't take a large security team to be effective, especially when developers are a part of the security effort (which they should be !!!!11).