Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Infosec's Jerk Problem (2013)

adversari.es

Post reply on HN
Print view View original

21–30 of 142 posts

Re: Infosec's Jerk Problem (2013)

#21

Post by oarsinsync »

frou_dh wrote: post #16
red_admiral wrote: post #5

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.

> Teaching blind compliance with any (unauthenticated) request based on "security" This feels especially strange on the phone, when someone (who later turns out to be legitimate) opens up the conversation by insisting that I prove who I am, _when they're the one that called me!_

Doubly so when they get irritated with you for responding with "and how do I know you are who you say you are?"

Re: Infosec's Jerk Problem (2013)

#22

Post by acveilleux »

HCIdivision17 wrote: post #8
red_admiral wrote: post #5

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…

> When everything starts at urgent and gets worse from there, people will just rescale the noise to be more understandable.

I really like that phrasing. I've been intuitively thinking along the same line but rescale is just the perfect word. Thanks!

Re: Infosec's Jerk Problem (2013)

#23

Post by sapphireblue »

There is a fundamental conflict of interest between security people and developers/owners/the general public. Infosec isn't interested in curing fundamental IT insecurity by, say, using safe languages (like Rust or something JVM-based or maybe JavaScript which is also a safe GCed language) for application development and using safe OSes that aren't built around 70s state-of-art (ugh.. really no production ready examples here). Instead infosec community - both "blackhat" attackers and "whitehat" protectors - profits from business as usual: a never-ending stream of zero days, CVEs, buffer overflows, side-channel attacks. It's not in their true interest to kill their cash cow.

Remember: If we, developers, used modern safe programming technologies, such as safe languages and OSes built around capability-based security, 99% of security exploits wouldn't even exist.

Re: Infosec's Jerk Problem (2013)

#24

Post by s_q_b »

What is extremely frustrating is the rise of "cyber security" Masters degrees.

The vast majority of these people have never written a single line of code.

They don't understand security, because they can't understand the underlying logic in the code. They just write documentation to meet certain outside standards, and have no idea what I'm talking about when I talk about our security posture. They genuinely think that an online satellite campus degree qualifies them to manage security devs from top ten schools.

This coast's tech centers are starting to drive me batty.

For a data scientist, my normal trade, especially. So much red tape that it's a two month project to get myself a small server for test.

Anyone in need of a remote data scientist, Princeton University A.B., two years at a funded startup, four years work experience with a major firm, with specialties in machine learning, (real) cybersecurity, and big data experience?

Re: Infosec's Jerk Problem (2013)

#25

Post by orf »

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 any fallout would be his problem.

He might hate you for giving him the task but it would be done.

Re: Infosec's Jerk Problem (2013)

#26

Post by danielweber »

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 very very good. Some other people try to pattern-match them. Mimicking the "jerk" part is easy. Mimicking the "very very good" part is not. (See also: making a name for yourself by being a jerk is a lot easier than making a name for yourself by being really good.)

There are good people who are not jerks. I've worked with a bunch of them.

Re: Infosec's Jerk Problem (2013)

#28

Post by tptacek »

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 the end of winning the war on the "bad guys". These are the people who tell you your Scala serverside application is insecure because of some recently-released Java applet bug; they're the people who fought against DNS query randomization for a decade because we need to finally release DNSSEC; they're the ones shipping grievously broken cryptography to try to "stop the NSA".

There are jerks in both categories, and competition is a dimension orthogonal to this one, but I find I can handle jerkiness and competition between when I know it's from someone who truly cares about understanding what they're talking about.

Re: Infosec's Jerk Problem (2013)

#29

Post by vox_mollis »

binarymax wrote: post #9

The (un)funny thing is, most developers would love to have the time to make sure their code is secure and well tested. Very often they lack a voice to product stakeholders, to get the time off feature development, and make sure their software is up to date with patches. > Practice active kindness. Go out of your way to do kind things for people, especially people who may not deserve it. If you wait for them to make t…

most developers would love to have the time to make sure their code is secure and well tested

This is certainly true. But competitive pressures will always force quick hacks over software robustness. The only real solution is a sort of developers' guild -- whose membership includes over 90% of all worldwide professional developers -- wherein an oath is sworn to always include security robustness as a required feature during the software estimation cycle. Or perhaps an analogue to the Hippocratic oath.

Which of course will never happen.

Re: Infosec's Jerk Problem (2013)

#30

Post by forgottenpass »

jvehent wrote: post #12

I've seen this happen way too often at various organizations. My take away is security is a function of the product, not some external process you bolt on top of it. Organizations typically fail at security because they try to manage it as far away from the product as possible. That leads security and dev/ops teams to manage their goals in isolations: one cares about preventing incident, the other cares about shippin…

I don't think the problem is specialization, just that the incentives mean that the specialization doesn't always get applied where it's needed.

Presume a company with the budget to have a SOC, they're doing all the "regular" security jazz and them some. But are they auditing the network services they themselves run, or just applying patches? Auditing the products the company itself is producing, or just kicking the tyres? But they MITM all the outbound https connections, I'm sure that more than makes up for it.

Post reply on HN