Live data from Hacker News

Infosec's Jerk Problem (2013)

adversari.es

121–130 of 142 posts

Re: Infosec's Jerk Problem (2013)

#121
post #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 pa…

You don't need to create a term, you just need to want to hire good people and actually pay for them. With that said, as a security interested dev, I actually work in devops as it's simply the best paying job so maybe a term does need to be created, but if you actually deeply understood security, you'd probably be hiring a devsecops.

Re: Infosec's Jerk Problem (2013)

#122
post #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 pa…

> 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")

So much this.

One place I worked had a head of security that switched us to having passwords that auto-expired every 30 days, had annoying requirements (mix of upper, lower, numbers, and special characters) and not allowing reuse of a password for 1 year. The increase in people having problems was handled by having "security questions" and self-service password resets.

My insistence that "security questions" were just unexpiring, easy-to-guess passwords was met with "But this is the standard!". Pointing out that rapid turnover of hard-to-remember passwords led people to write them down generated a similar reaction.

Re: Infosec's Jerk Problem (2013)

#123

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…

Had a good friend and colleague who made an interesting point about how/why a security role can get depressing. What happens if your security program is really really really effective? Answer: Nothing

Same problem in IT. It's an inverse recognition problem.

Re: Infosec's Jerk Problem (2013)

#124

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…

Had a good friend and colleague who made an interesting point about how/why a security role can get depressing. What happens if your security program is really really really effective? Answer: Nothing

I could imagine that there would be a Peter principle situation where a successful infosec professional is given progressively more difficult responsibilities as long as nothing bad happens. Is this not the case?

Re: Infosec's Jerk Problem (2013)

#125
post #86
post #55

Earlier quoted context omitted.

All I know is that far too many "security guy" discussions sound like dick waving contests pronounced in the tone of The Simpsons' "Comic Book Guy".

It's sadly nothing at all like debates between people pushing different unit testing methodologies.

Also nothing at all like debates about static vs dynamic typing in programming languages!

Re: Infosec's Jerk Problem (2013)

#126
post #70

After nearly 20 years in various kinds of infosec companies, there are companies where jerks are not common, and companies where the jerks are very common. You cannot fix the jerks in the first kind of company. Learn from them, quietly, and look for your exit. Some people think that there is a correlation between being really good and being a jerk. Only in the sense that the only way a jerk can survive is if they are…

I've worked with such a mimic. He did a security audit, then scrapped the whole system because there was a completely unfiltered network interface, and no matter what other security was in place that would never ever be good enough on a GNU/Linux system. "All interfaces must have strict filtration, only allowing traffic on previously approved ports as per system and application specifications." The interface in quest…

>The interface in question was called "lo".

Ok that cracked me up. Happy Friday.

Re: Infosec's Jerk Problem (2013)

#127

Earlier quoted context omitted.

Had a good friend and colleague who made an interesting point about how/why a security role can get depressing. What happens if your security program is really really really effective? Answer: Nothing

I could imagine that there would be a Peter principle situation where a successful infosec professional is given progressively more difficult responsibilities as long as nothing bad happens. Is this not the case?

The opposite could come into play at some companies where people start questioning the expense of your salary since you're never having to deal with successful attacks. It's hard to talk up what didn't happen. Then you have people always putting out fires who look like they're "getting shit done."

It often seems like a myth when you hear about that phenomenon, but then I experienced this myself in a different role myself and became a believer.

It could still be the peter principle, and that you need to better communicate your unseen accomplishments. Maybe there should be a modified peter principle, where people rise according to their ability in the job and corporate politics.

Re: Infosec's Jerk Problem (2013)

#128
My few brushes with Infosec folks makes me think there's a general socialization problem with the field, not really just a "jerk" problem.

For example (and I know it's still a fairly young field), but simple activities like cataloging and sharing knowledge learned so far seems to be something that just doesn't get done. So the wheel gets reinvented over and over and over again. I'm actually kind of amazed at how many half-assed log parsing/visualization/analysis tools there are. Doesn't anybody in infosec centralize knowledge other than adversaries?

The feel I get from infosec conferences is more of a dick waiving contest and tribal activity than an honest information sharing activity.

Re: Infosec's Jerk Problem (2013)

#129
post #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 pa…

Your statement described my hell.

I put a lot of effort into running environments securely, and eventually, someone always decides to get a second opinion.

The only recommendation I have ever seen come from a security audit in an enterprise, is bikeshedding password lifetimes. Every time I point out "SQL Injection in the logon form" level vulnerabilities, I get directed to the "security experts", which is why I've seen password policies go from 180 days, to 90, to 30, while the mentioned issues get ignored.

People flash a PWC business card and it's seen as credential. Then they drag me to the comms room and spend all day auditing the serial numbers on individual patch leads going to desktops.

Re: Infosec's Jerk Problem (2013)

#130
This is an excellent article.

> Hanlon’s Razor says “Never attribute to malice that which can be adequately explained by incompetence,” but I would add, “Never attribute to incompetence that which can be explained by differing incentive structures.”

That's profound & pretty thought-provoking.

Ternus's Razor, anyone?

Post reply on HN