Live data from Hacker News

Infosec's Jerk Problem (2013)

adversari.es

41–50 of 142 posts

Re: Infosec's Jerk Problem (2013)

#41
post #28

I carve up this problem differently. To me, the field can be divided into two basic categories of people: 1. People who are into security to prosecute some immortal struggle between good and evil. 2. People who are into security because of the engineering challenge. It's the people in group (1) that I tend to have a problem with. Often, for the "good guys" security professionals, engineering facts are just a means to…

One of the worst is the cyber-security political purist. The person who has drunk the kool-aid so badly and/or likes to use their knowledge to beat others round the head with it. The person who likes to talk about things like "risk/threat modelling" but actually doesn't:

a) Have a real understanding of the needs of the people they say they are trying to help

b) Have the courage to make tough calls related to ideal vs good security.

Working in the NGO security space we get these people all the time. Send them out in front of a bunch of African/Middle Eastern/Asian/Russian activists who have been risking their lives for years for democracy etc etc and all they do it spend three days showing off, berating people and then leaving. Telling everyone that TAILS/PGP/Linux/TrueCrypt etc etc is for everyone and that anything else "is gonna get people killed," so by extension shouldn't be done. There are people who have made entire careers around taking that attitude, which most of the time actually leads to demoralisation and a long-term decrease in security.

It's easy to recommend the hard "cover your ass" stuff because you don't like the NSA, it's harder to say "Hmm, ok we gotta assume some risk that the NSA doesn't care what we're looking at and use a solid Google two-factor here and see how we get on...now how do we stop the security guard from selling you out?"

Re: Infosec's Jerk Problem (2013)

#42
This is a big reason I stayed away from infosec, although it fascinates me in many aspects.

IMO, security orgs, especially within companies have this awful reputation because they borrowed the credentialing model of project managers and walk around like doctors with an alphabet soup of certifications. Talking to these folks is like crossing a circa-1998 MCSE with a lawyer.

The CPE requirements from CISSP and other certs encourage publishing and delivering talks, which is good -- if the authors/talkers are competent. The side effect within enterprises and some vendors is you develop a cadre of bullshit artists who are great at throwing spears, not so great at doing anything of value.

Re: Infosec's Jerk Problem (2013)

#43
As others have said, this is a good article.

I'd like to comment on a line that literally changed my life, from my favorite https://en.wikipedia.org/wiki/Vorlon, Kosh:

"Understanding is a three-edged sword: our side, their side, and the truth."

I think about that every single day. Speaking for myself, a lot of the other suggestions in the article naturally flow out of embracing this perspective.

I could literally go on and on about this, but I'll leave it be.

Re: Infosec's Jerk Problem (2013)

#44

One of the root causes seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security. It's not as fun to be a developer that is really into security but only have that be part of your job. Even if it's all you do, if your days are just "analyze, document, harden, repeat," that's a lot less fun than getting paid to pop boxes. I know, because that's w…

>A root cause seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security.

To expand on this, I've also noticed that "security" in enterprise-size companies tends to be a dumping ground for helpdesk+ staff -- people that can read a CVE or parrot "best practice", but not really grok the subject or think critically about it (e.g. jumping from one password to another every 3 months isn't "more secure"). It's been my experience that people in security teams can't implement the fixes to the things they complain about because if you're a security-minded dev, your career path will be in dev.

>It's not as fun to be a developer that is really into security but only have that be part of your job.

I think it would be ideal to have security as a parallel track to regular dev staff -- with their placement in the ecosystem being between dev and QA. Much like how "devops" was used as a hiring filter to have sysadmins that can at least read code, I think we should have a "devsec" group that bridges security-QA and dev.

Re: Infosec's Jerk Problem (2013)

#45
Technical Infosec guys can fix vulnerable dependencies themselves and use the tests Bob writes (right?) to make sure they don't break anything. Only need to bug Bob when there is a breaking change and you prioritize it with Bobs PM.

Also passwords are dumb - Bob should use certs and or ssh keys and 2fa to access anything.

The point is that any security that hinges on hassling Bob is likely bad security.

Re: Infosec's Jerk Problem (2013)

#46

I read the first lines and thought immediately of all those e-mails marked IMPORTANT coming from "my bank" that request I immediately enter my username and password somewhere for "security". Teaching blind compliance with any (unauthenticated) request based on "security" is the one way we could make the situation even worse.

It's a pretty big deal. When everything starts at urgent and gets worse from there, people will just rescale the noise to be more understandable. It's just like the joke about sitting down and assigning points to a task and finding out everything is 100 or all bugs are critical or all tasks are top priority. The meta joke here is that is some ways every security issue is critical, but if everyone is immune to the fea…

> all tasks are top priority

I often joke with my boss that if all tasks are high priority, all tasks are therefore of average priority.

Re: Infosec's Jerk Problem (2013)

#49
post #25

Good article, I can't help but think this is the real problem though: > and Bob’s demand that you explain the vulnerability is met with your impatient demand to “just do it". Maybe rather than say "Just do it" you could say "Any user can delete our entire database and steal all of our data". I think Bob would understand why this is a bit more important than his current tickets, and by not doing it when told about it…

> you could say "Any user can delete our entire database and steal all of our data".

See the problem is that all/most vulnerabilities wind up with this sort of description, which can lead to Bob building up an immunity to it.

Re: Infosec's Jerk Problem (2013)

#50

One of the root causes seems to be that everyone with the aptitude for security crowds toward jobs that don't actually involve implementing good security. It's not as fun to be a developer that is really into security but only have that be part of your job. Even if it's all you do, if your days are just "analyze, document, harden, repeat," that's a lot less fun than getting paid to pop boxes. I know, because that's w…

I'm also on the defensive side. I went to the last "DefCon", which you'd think expands to "Defense Conference". There was a grand total of one presentation that had defensive elements in it and I still don't recall it being dedicated to the topic.

I don't intend to go back. Great conference, don't get me wrong, I got personal enjoyment out of much of it, but it's impossible for me to professionally justify it.

Defense isn't fun enough, for anybody; neither the one defending, nor the developer who was just told the code the spent a week developing is a gaping security hole, nor the managers being asked to spend money to prevent black swans, nor the open source developers having fun developing frameworks and libraries, and on it goes. It just isn't fun.

Post reply on HN