SwiftOnSecurityA commonly-misunderstood aspect of computer security is that you are battling computers.
No. That is not right at all. Computers are barely involved.
You are battling humans who eat apathy and coordination problems.
I tell the story often but in the beginnings of my career in IT I was fascinated by stories of 0days by state actors. And I worried about them.
As our entire client base was XP SP2 with zero governance and many machines shared huge groups of local admins. Some of them made Authenticated User a local admin.
And I sat there and I was worried about foreign military 0days. Perspective later is hell of a thing.
The reason IT Security is so hard is someone has to do it. That's the answer.
That is not a technical challenge it is an interpersonal one.
Do you know how many smart people there are trying their very best? You think it would be deluged in security.
But it's not. This is a personal problem and that's what ruins everyone that tries it.
The funniest thing I find about my history and Helpdesk is the credibility. Yes I can talk your language and I know your priorities and I know what worries you about technical change. I know the results of an outage because I have had to support it. I took the calls and I took them for a decade.
I know exactly what it means to fail. Which is something you should understand when you make a change for IT Security.
They don't need to hear perfection. They need to hear empathy. They need to know you thought this out and that you know exactly what will mean if it fails. Because you sat on that call. The thousands of them.
Failure is pain. And they need to hear that in your voice when you tell them the plan about changing everything.
Dan Murphy@SwiftOnSecurity The human communication aspect of what we do is undervalued sometimes.
I think you make an especially good point about the consequences of failure. Unfortunate timely example: Our local hospital trust had an IT upgrade for patient records rolled out very recently and apparently it wasn't sufficiently load tested and has been causing chaos for clinicians.
Having spent some years in software testing prior to infosec, I empathise with the QAs who likely weren't given sufficient time to test and/or had defects they raised "risk accepted" for fixing after release. But the decision makers aren't often the ones who feel the negative outcomes of their poor decision making.
I think you make an especially good point about the consequences of failure. Unfortunate timely example: Our local hospital trust had an IT upgrade for patient records rolled out very recently and apparently it wasn't sufficiently load tested and has been causing chaos for clinicians.
Having spent some years in software testing prior to infosec, I empathise with the QAs who likely weren't given sufficient time to test and/or had defects they raised "risk accepted" for fixing after release. But the decision makers aren't often the ones who feel the negative outcomes of their poor decision making.