undefined | Better HN

0 pointslelanthran2y ago0 comments

My experience of IT Security in enterprises is that it's simply a checkbox to check off so that someone, somewhere, can say "I followed best practices; this breach cannot be blamed on me!"

Preventing breaches is an objective, but it's purely secondary to CYA. This is why the Security Strategy Policy exists and often looks so out of touch with reality:

1. An external consulting firm advised on that policy document.

2. Someone signed off on that policy document (CEO/CTO/COO/etc).

3. Everyone below that person ticked-off every single clause in that document.

4. Breach occurs.

5. Employees can't be blamed, they did everything that was asked of them

6. CEO/CTO/sign-off person cannot be blamed: they sought, paid-for, received and heeded professional advice.

7. The external firm cannot be blamed, as their advice is "in line with modern security guidelines."

In this sense, no one should be shifting focus from whatever the policy document says because then they can be blamed.

0 comments

3 comments · 2 top-level

dgb232y ago· 1 in thread

Security is of adversarial nature. Us vs them.

But the reason I find your comment interesting is that it turns that towards the inside.

Trivially the ones to blame are the attackers. But the responsibility for protecting against them is treated like a hot potato. It seems to be more important to say “It’s not our fault” than to prevent attacks.

Why is that?

I think a big reason is the interface of the technical side. People want to hear that it’s safe, but engineers can only really say “It’s safe against these particular things.” But it’s uncomfortable to hear that.

afiori2y ago

If the approach to a accident/catastrophe/breach is to find guilt and assign blame then there are strong and clear incentives to avoid blame.

In a lot of contexts this cannot be significantly changed by company culture as many legal systems adopt this approach.

The oft mentioned other approach is to assume that human and operational error cannot be eliminated[0] and design systems to withstands many compounding mistakes.

Afaik we do this only in aviation and infrastructure

[0] these two approaches are similar and live on a continuum between "we punished the guilty party, the problem is no more" and "let's make sure that this not any similar problem never happens again". Both extremes are often wrong, but in many cases it is a good idea to move towards the latter.

dogman1442y ago

This rarely is the dynamic for startups. They’re not. Ringing in KPMG to advise on security lol.

The closest that’ll happen is sales RFPs everyone had to pass to sell to enterprise, which yes can be full of holes and checkboxes.

j / k navigate · click thread line to collapse