Hacker News Reader

Comment by jalapenos | Hacker News Reader

Have had some level of security farce, like described in this paper, in every org I've ever been in.

The root cause is failing to hold security staff to a dual mandate: keeping the bad guys out AND keeping the good guys in.

Because they don't get held to account for obstructing everyone else's work, they naturally do every ass-covering piece of security theatre they can - they don't suffer any consequences.

The moment they're under carrot-and-stick for not interfering with productivity, as well as preventing intrusions, you get more acceptable outcomes.

View on HN

Only tangentially related but my wife used to work at a private institute research lab which was affiliated with a large university, and therefore used computing resources.

The University IT security staff did a great job enabling 2FA across the entire network.. big job, well done. They didn’t do the slightest bit of requirements analysis of those people using the network such as affiliated research labs. One day my wife went to use the computer _in the PC3 lab_ and couldn’t without 2FA. Even logistically getting a computer in - that computer can then never leave the lab. PC3 labs don’t allow you to bring in a phone or anything really.. you’re double gowned, double gloved, goggles etc… hilarious.

Took them about a week to explain themselves sufficiently for IT security to fix it.

> PC3

Physical Containment Level 3 = Biosafety Level 3. I think.

https://en.wikipedia.org/wiki/Biosafety_level#Biosafety_leve...

Great case in point. In a well run org, that would've been elevated to a "security incident" just the same as a hack, with their jobs potentially on the line, rather than a week of pleading to them to have mercy.

a company may very well consider this a “security incident” or other high-priority issue, but at least in my experience, the method of reporting something like this can be vague. While the right answer should be a place to submit a ticket, even internal systems nowadays seem to not let the users set the priority on tickets and instead let L1s try to resolve everything, who may not have the experience to recognize something needs to be elevated. At that point, it seems the only good option is to run the issue up the chain and back down through the right department (which is probably more effective, at the end of the day).

Yeah she was on the L1 helpdesk ticket merry-go-round for a couple of days before I told her what she needed to say to them to have a security team member look at it

> with their jobs potentially on the line

That would be a bit much and not accomplish improvements.

There’s actually published evidence of exactly that!

Where Do Security Policies Come From found that the websites with the most aggressive policies were those with the least incentive to make the system easy-to-use. Big sites like Facebook and Paypal somehow manage to be safe without the strict password requirements of <random university intranet here>. Likely because they have financial incentive to make their systems easy-to-use.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

(Disclaimer: I know one of the authors)

> keeping the bad guys out AND keeping the good guys in.

YES

> Because they don't get held to account for obstructing everyone else's work, they naturally do every ass-covering piece of security theatre they can - they don't suffer any consequences.

Every time you push back on some ridiculous policy they'll respond with ironic smirk or shrug (are you seriously forcing password change monthly and keeping hashes of the last 10 passwords?!). Nowadays basically every corporate security policy forces employees to install some kind of crappy DUO/whatever (FUCK YOU CISCO) app on a private phone, work phone is a rare occurence nowadays ("everyone have their own smartphone anyway"). It's never a TOTP which somehow works perfectly fine on many other crucial services. One might think we're all competent tech folks, but they're vicious malicious cunts.

At the exec level, the Chief Information Officer (CIO) is primarily responsible for maintaining availability of the network systems and data, but the Chief Information Security Officer (CISO) is responsible for securing systems and data. Sometimes they are same-level positions and compete for authority + resources. Sometimes CISO is subordinate to CIO. CIO supports profit centers, whereas CISO is entire a cost center and is focused on preventing losses.

The problem is that the competing interests aren’t exactly comparable apples-to-apples. Should every system get OS patches ASAP? Yes if you want to minimize the security surface area. No if the upgrade creates some adverse affect on employee/system. Testing can reveal the latter, but it takes time, which is the enemy of unpatched systems.

Low level IT workers are given instructions and incentives to follow established security procedures (including overseeing patching). Their supervisors are the ones who must make the call when it comes to how much testing is sufficient before forcing those patches.

This is a failure of the business, not security per se. A proper impact analysis of changes should be conducted along with risk analysis to determine if the change is even warranted.

Security themselves aren't usually qualified to know how things will affect everyone and all processes, any more than anyone else is in the business for things outside their domain.

If you allow one bit of the business to run rampant and put their needs ahead of all others, you will get bad outcomes, whether that department is security, or development or IT infrastructure, or marketing, or whoever.

So I disagree with your carrot and stick approach. It's not about holding people who may have a good reason to want something accountable for all the other possible negative effects of it. It requires a business that is properly managing itself and balancing all the differing needs within it.

"The moment they're under carrot-and-stick for not interfering with productivity, as well as preventing intrusions, you get more acceptable outcomes."

Suggestions on how to do this?

Give the COO/CTO the last say, not the CISO.

Usually it's the opposite, due to the asymmetry of a terrible unknown and claimed unquestionable remedies vs "it'll certainly slow us down to some degree". The person making the latter argument needs to have far more knowledge in areas outside their domain, and far better debate skills, to prevail. The person arguing the former need only say "hackers" in a solemn tone, to win by default.

Specific security measures should be added at "absolutely needed, beyond reasonable doubt" threshold, not "probably helps", as adjudicated by the leaders of the productive core of the business.

That'd go a long way to stopping them doing nonsense password rolling witch-doctoring.

> Give the COO/CTO the last say, not the CISO.

The problem with this is that when the COO/CTO doesn't understand or respect the CISO or their job, you end up with easily-preventable security breaches.

There need to be places where security is paramount.

There need to be places where user access/experience is paramount.

There are no hard and fast rules as to where these are. Human judgement is required, however messy that ends up being.

We did that for years and got more breaches and vulnerabilities…

Reply on news.ycombinator.com