Don't Bother Me With Details, Part 2

The phrase "don't bother me with details" refers to a particularly annoying dynamic between the cybersecurity people and others. The short version is that saying "don't give me the details" is often not the clever avoidance of wasted time that one might think. The long version is in this post.

This post is part of series about how culture can hamper the delivery of cybersecurity, but it is also about which talents you need to succeed in this field.

At Pythia Cyber we add behavior science to classic cybersecurity engineering to take effectiveness to the next level. We lean heavily on our proprietary assessments which allow us to add awareness of talent to the question of who you should hire, which employees should be in which roles and how that talent should be developed.

Today's example of how cybersecurity people can feel caught between a rock and hard place is why we try to balance a talent for enforcing rules against a talent for finding reasonable compromises. A rigid cybersecurity team is often an ineffective cybersecurity team. A lax cybersecurity team is often an ineffective team. A reasonable cybersecurity team is often an effective team.

But for us to be reasonable you have to be receptive.

Today's example is the question "Why can't I run {whatever} from {whichever} machine?" Usually this not a sincere question, it is a complaint better stated as "I want to run {whatever} from {whichever} machine and I don't see why you won't let me."

Some concrete examples: "Why can't I see the project status page on my iPad?" "Why can't I use the personnel directory on my phone?" "Why can't I run the A/R system on my laptop?" "Why can't I access my files from the computer in the conference room?" "Why can't I print on that cool new printer in Finance?"

When I run into this complaint I sigh and then I choose a response from the following spectrum: "Because you can't" at the low end and a long disquisition on networking on the high end. Neither pole satisfies: if I give the short answer then I'm an imperious jerk. If I give the long answer then I'm a bore. Unless.

Unless you let me bother you with details. Relevant details. Details which help round out the value judgement you are trying to understand so we can discuss whether or not that value judgement should be revised. Let me bother with the details needed to explain such a value judgement. In this case I am on all sides of the conversation, so that makes things a bit easier.

Individual Contributor Me (ICM) was having trouble accessing a network resource and so Systems Administrator Me (SAM) had to help, but in a way that would not upset Cybersecurity Me (CSM). The kind of problem described below is becoming very common as IT integration between customers and vendors, as well as between vendors and suppliers, gets ever tighter.

One of ICM's clients requires the use of a remote access solution that insists on secure HTTP (HTTPS) when accessing web servers on the client's network. Fine, that is reasonable.

ICM's desktop's browser requires that the certificates which protect any site accessed via HTTPS be from a trusted source. That makes sense.

The client generates their certificates internally, to save time and money. That is logical. But ICM's desktop's browser doesn't trust the client as an issuing authority for certificates. Nor should it, by default.

SAM found a solution: to add the client to the list of trusted certificate issuing authorities, at least on ICM's desktop. CSM didn't love this idea, because CSM likes to keep all the desktops as secure as possible. CSM had accept this idea because it would be bonkers to lose a client over a very slight rise  in ICM's risk of visiting a malware site.

So SAM is going to do this--carefully--and then make a note of this on SAM's "things I hate but are true" list. CSM don't want SAM to just do it and forget about it because that would likely return to bite us.

This configuration exception means that ICM can only debug web apps for this client on that particular desktop; ICM can't use any other machine on our network without SAM making the same configuration alteration and CSM would never sign off on that.

Note that absolutism won't work here: the client's choices are reasonable, the browser developer's choices are reasonable and our firm has to adapt. But we don't have to go to either extreme: we don't have to refuse to do the work and we don't have to open this hole on any other machines. Or use a browser that doesn't care about certificates.

Sometimes being in cybersecurity feels like being between a rock and hard place. Having managers ask  questions such as "why can you only do that work at your desk?" and zone out during the answer doesn't make our jobs any easier.

Hiring absolutists generally leads to cybersecurity tyranny. Hiring overly accommodating cybersecurity personnel makes them into cybersecurity janitors. Hiring talented people who can work with you as partners is just right.