Live data from Hacker News

Infosec's Jerk Problem (2013)

adversari.es

61–70 of 142 posts

Re: Infosec's Jerk Problem (2013)

#61
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…

I can think of several people who fit firmly into both. Moxie, for instance. I fail to see how these two categories are mutually exclusive.

Re: Infosec's Jerk Problem (2013)

#62
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.

Not really though, some do and they should be patched, but only a small subset of vulnerabilities end up with a complete backend compromise.

Things are fucked, but not that fucked.

Re: Infosec's Jerk Problem (2013)

#63
post #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. Defens…

Nonsense. Defense is plenty fun. Anyone can find a 0-day. The principles and some methods are the same crap as Schell et al did in MULTICS security evaluation they published decades ago. Same kind of stuff Burroughs was preventing in 1961. More interesting was when the old guard tried to build something that couldn't be compromised under any circumstances. Others tried to find and master key areas of the problem. The results were very interesting although not always fun to apply given they could be tedious. Even then, trying to automate that in tooling provided a whole new level of fun to distract one from the tedium. :)

https://www.schneier.com/blog/archives/2013/12/friday_squid_...

Posted above in response to Schneier's call for INFOSEC after Snowden leaks. The title is both a parody on cryptography papers and a trick I used to make sure I can Google a link with a few, unique words. Still works haha. Anyway, that link covers both high-assurance and medium-assurance INFOSEC methods out of CompSci and Defense sectors. Skim through the titles and abstracts then come back to tell me if you still think defense is the boring part.

I mean, really, because I think people think that because "INFOSEC" as you see in mainstream is (a) bullshit or (b) boring. The real deal is constantly innovating, works more than it fails, and quite interesting. To me at least.

Re: Infosec's Jerk Problem (2013)

#64
If you think Infosec guys are jerks, I've met a group of even bigger jerks in some organizations: developers!

This isn't always the case, but in some software companies the developers capture the entire organization and run roughshod over everyone. I've seen developers tell support folks that because they are in support, they are utterly worthless and their opinions and views don't count and never will, right after they ask for their opinion. I've seen them obstruct QA people. Not arsehole, stick it to you QA folk, but quiet, unassuming QA guys doing manual test scripts and find a failure and send the case back to development.

Yup, having one-eyed folk around can really cause a toxic environment. Of course, I have to be careful, 6 years ago I was often that toxic one-eyed person, and I learned this the hard way.

Don't do that. Don't be me. Be nice and be willing to concede that the other person has good intentions. You'll be less angry, more likeable and probably more productive.

Re: Infosec's Jerk Problem (2013)

#65
post #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. Defens…

Let's be honest, Summer Security Camp is far more about socializing with "our tribe" than it is about learning.

That said, understanding how the red team does things is extremely useful for formulating one's own defense.

Re: Infosec's Jerk Problem (2013)

#66
"The Truth" is, it's probably not that big a deal. No matter how stringent you are, there are probably still vulnerabilities. And just like everything else, if there's a problem, you work through it. And likely remain unscathed.

Re: Infosec's Jerk Problem (2013)

#67
post #48

The lack of self-awareness here is breathtaking.

Do go on.

If that poster responded to every comment that showed a lack of self-awareness with the comment "The lack of self awareness here is breathtaking" he'd create a bunch of threads that go on forever.

Re: Infosec's Jerk Problem (2013)

#68
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…

Shouldn't there be a #3: people who are into security because it's important for their entity's constituents?

Re: Infosec's Jerk Problem (2013)

#69
> Never attribute to incompetence that which can be explained by differing incentive structures.

Oh, man, this is such a deeply, vitally true thing. It's something I've observed for a long time but never quite put it into words.

So often, when I see some person acting in a way that seems totally stupid to me, it turns out they were just operating with goals and constraints that weren't obvious and were different from mine.

Re: Infosec's Jerk Problem (2013)

#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 question was called "lo".

I don't work there any more.

Post reply on HN