Infosec's Jerk Problem (2013) • Hacker News Board

Re: Infosec's Jerk Problem (2013)

#131

Post by deadtofu » Sat, Apr 30, 2016, 12:58 AM UTC

bgilroy26 wrote: post #124

icaruswings wrote: post #110

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?

Or promoted into management where they implode due to being introverts who can't politic well.

Re: Infosec's Jerk Problem (2013)

#132

Post by [deleted] » Sat, Apr 30, 2016, 12:59 AM UTC

ergothus wrote: post #122

mjolk wrote: post #44

Earlier quoted context omitted.

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

[deleted]

Re: Infosec's Jerk Problem (2013)

#133

Post by bpchaps » Sat, Apr 30, 2016, 2:04 AM UTC

Yeah, they definitely are.

I reported a major issue of comcast to an indirect associate of mine I know who's huge into security. I wanted some contacts with folk who know how to disclose it properly, since I wasn't getting much help from comcast. He pretty much shrugged me off because I don't have a traditional "infosec personality". A day later, I got a hold of some pretty high ups in comcast who actually fixed it. Their engineers were completely blown away by the issue and it sounds like it might do pretty well for me in the end. He wasn't the only one who shrugged me off, but if I'd gotten help from any of them, it might've gone well for them, too. The exclusionary attitude is pretty ridiculous.

I think a lot of the problem is that their threat models tend to cause them to become pretty reclusive, so that they don't really want to trust "newbs". Problem is that it now feels like a paranoid echo chamber.

I commented here a while back about working with Northwestern's security to try and protect my own HIPAA data. NW's response to my disclosure was "We're already doing scans. Report back when you find something serious." It's fucking sad that security's treated this way on many fronts. If you're not on the "in", then you're considered a script kiddie, if you're on the "enterprise in", then you're useless and completely caught in red tape, and if you're in the "in crowd", then you're part of an echo chamber.

Just yesterday, I was explaining my reasoning for wanting to make a LAN party insecure as possible to promote openness rather than exclusion, since any measure to add extreme security would prevent further appearances. The not-so-fine print wold be, "Hey guys, your stuff is insecure. This is intentional. Please treat it as such." His recommendation that for each different game (of maybe 30), you disconnect and re-request from dhcp for the vlan which is hosting the game you want to play. Two games wouldn't be allowed. Silliness.

Re: Infosec's Jerk Problem (2013)

#134

Post by blue_dinner » Sat, Apr 30, 2016, 2:29 AM UTC

dkopi wrote: post #32

vox_mollis wrote: post #29

Earlier quoted context omitted.

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…

The real solution in my opinion is educating people on security. not just developers, but also end users, sales people, and product managers. When users start choosing the robust and secure product over the quick and insecure product, sales will pick that up, product will follow, and programmers will treat security just like any other feature.

The problem is two-fold. The average users doesn't care about security and probably never will.

Many developers like to hack software together. To make it secure requires discipline and more time and knowledge when developing it. Most businesses don't really care about this. They just want it finished fast.

The only way it will change is if the government starts fining companies for software that has a crazy amount of bugs or requiring developers to be certified.

I honestly don't think many developers even have the ability to write software without the obvious bugs we see popping up today. For sure we would see less companies outsourcing to countries like India.

Re: Infosec's Jerk Problem (2013)

#135

Post by _b8r0 » Sat, Apr 30, 2016, 10:52 AM UTC

jerf wrote: post #50

forgottenpass wrote: post #19

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…

Isn't DefCon supposed to be a play on words named after the defense readiness condition alert state used by the US armed forces?

Re: Infosec's Jerk Problem (2013)

#136

Post by mettamage » Sat, Apr 30, 2016, 12:51 PM UTC

s_q_b wrote: post #24

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 tha…

Well if that's the case, then times are changing ;) I study at the VU University of Amsterdam and took a couple of courses from the security master track. I had to use libnet to create my own custom TCP/IP packets, libpcap to listen to incoming packets (tcpdump for debugging).

Obviously, I did a SQL injection, cross site request forgery, cross site scripting and debugged malware with IDA Pro and later (when it was safe) with GDB. Did I talk about the concolic execution framework Triton that I used in combination with PIN to gather formulas for an SMT solver so we could crack the code of a binary? We did more things, I remember taint analysis being one of them with a PIN tool. Well, you get the point.

I don't know if we're a special snow flake. I like to think we aren't, but the way the courses have been taught to me is that writing code, breaking things and debugging (lots of it) are the norm in security. Smart conceptual thinking helps sometimes as well. So I have this (untested) view of the world that other security master degrees also let you code in C, Python and whatever else you need to analyze or break into a system. It would frankly be catastrophic if this isn't the case.

For me it was also a really interesting introduction to C! :) My main languages are Java, Python and Objective-C (where everything is a pointer, so I got away with not understanding it).

My only criticism is that some situations seemed a bit contrived, but on the other hand it improves practice because you know what to focus on. Another was that some parts were purely theoretical and had no practical assignment (e.g. return oriented programming).

Cool website to learn a couple of things more: https://www.win.tue.nl/~aeb/linux/hh/hh.html

Re: Infosec's Jerk Problem (2013)

#137

Post by hiddennetwork » Sat, Apr 30, 2016, 2:18 PM UTC

I was in IT security for many years and got out largely because of the sheer attitudes of many of the people I encountered. Some of them were genuinely very nice, very smart people, but these gentlemen were few and far between. Sadly.

I started off as an abuse investigator for a very large East Coast ISP, moved into firewalls, then penetration testing once I knew what I was doing. All along this path, the vast majority of guys I worked with, for, and around (on contracts) were sheer jerks of the highest order. Everyone seemed to be angry, upset, on edge. I can understand this. IT security--especially abuse investigations--necessitates seeing the seedy side of the Internet. Ditto IT security in general. You're not working for or with people who are "creatives". You're working for and with people whose sole job is to minimize threats and vulnerabilities.

The most stressful time was being a firewall engineer. Having to deal--on the fly--with impatient customers wanting a six-spoke VPN "right now!" and them being jerks about it was annoying.

I hated the calls that involved my placing a "tap" on some poor sod whose boss wanted an 8-hour tcpdump on him to see where he went when online. They wanted a gzipped log file placed on the server where they could SSH in and retrieve it.

I hated the double standards where executives were given static IP addresses on their machines and special rules created to allow them carte blanche access to the Internet at large--no filtering. They also avoided the proxy. These special executives were &^%#$@ and everyone knew it.

When you spend your life seeing nothing but evil, you take on a different view of life and the world around you. I saw this happening and I got out in favor of being a sysadmin. I'm much happier, and the IT security roles I do have are much smaller in scope and I know how to handle them quickly and quietly.

Re: Infosec's Jerk Problem (2013)

#138

Post by secfirstmd » Sat, Apr 30, 2016, 4:34 PM UTC

pdoconnell wrote: post #120

secfirstmd wrote: post #79

Earlier quoted context omitted.

Yep, within reason - I don't buy into the "I have nothing to hide argument, so I have nothing to worry about." People like Trump or UKIP remind should remind us of the danger of that. Though we should remember, in a realpolitik world, the long-term interests of the NSA -> US Gov -> West etc is in supporting democracy activists for example. It's just a pity that the sensationalism of "counter-terrorism" interests in t…

Question for you, what company do you work for? I've really wanted to break into NGO security in particular for a lot of reasons. Spent a lot of years working in NGOs, and now do internal corporate security. Pay's better but it feels different. Could you possibly reach out to me? pdoconnell at gmail

Cool.

We run our own. It's here www.secfirst.org - email me rory@

Re: Infosec's Jerk Problem (2013)

#139

Post by JoachimSchipper » Sat, Apr 30, 2016, 8:30 PM UTC

nickpsecurity wrote: post #81

jerf wrote: post #71

Earlier quoted context omitted.

"To me at least." I suppose I wasn't clear. I have fun with it too for the most part or I wouldn't be doing it. But I observe that I'm a rare duck that way. And the unrelenting stream of bugs caused by the same fundamental root-cause issues over and over again can get old. How many times do I have to see an XSS brought on by using string concatenation on HTML? How many times do I have to see, well, any of several vul…

Ahh, you do web applications. Then you might like my summary of state of the art for that : https://www.schneier.com/blog/archives/2014/04/the_security_... It's due for an update in near future with resources that a few people here shared with me. Still has lots of interesting stuff, though. Might not help in your day job as you can't dictate the stuff to management or dev team. However, you could enjoy doing it in p…

That's an interesting perspective, but some additions:

- the client (i.e. browser), protocol, proxies, etc. are very hard to reason about. For instance, content sniffing and HTTP response splitting should not show up in a sane protocol, yet here we are. An encyclopedic knowledge of - at least - browsers bugs is required to write "secure" web sites.

- type-based safety doesn't do a lot to ensure that e.g. the same-origin policy actually protects your users (i.e. that there is not some unrelated application on the same domain-ish). The public suffix list (https://publicsuffix.org/) is essential to modern web security, and there seem to be no plans to change this.

- "The Tangled Web" is very good (or at least the first half is). It makes me happy I'm not working on the web. ;-)

Re: Infosec's Jerk Problem (2013)

#140

Post by nickpsecurity » Sun, May 01, 2016, 1:08 AM UTC

JoachimSchipper wrote: post #139

nickpsecurity wrote: post #81

Earlier quoted context omitted.

Ahh, you do web applications. Then you might like my summary of state of the art for that : https://www.schneier.com/blog/archives/2014/04/the_security_... It's due for an update in near future with resources that a few people here shared with me. Still has lots of interesting stuff, though. Might not help in your day job as you can't dictate the stuff to management or dev team. However, you could enjoy doing it in p…

That's an interesting perspective, but some additions: - the client (i.e. browser), protocol, proxies, etc. are very hard to reason about. For instance, content sniffing and HTTP response splitting should not show up in a sane protocol, yet here we are. An encyclopedic knowledge of - at least - browsers bugs is required to write "secure" web sites. - type-based safety doesn't do a lot to ensure that e.g. the same-ori…

"the client (i.e. browser), protocol, proxies, etc. are very hard to reason about. For instance, content sniffing and HTTP response splitting should not show up in a sane protocol, yet here we are. An encyclopedic knowledge of - at least - browsers bugs is required to write "secure" web sites."

It's true. I think you could encode a lot of that in a framework or language such as Opa or Ur/Web. What's left is a tiny checklist. Edit to say maybe not tiny but smaller.

"type-based safety doesn't do a lot to ensure that e.g. the same-origin policy actually protects your users"

There's secure, browser architectures that do that in various ways. I'm not sure about the language level. Might need to be combined. Worth thinking about. The publicsuffix website is new to me so thanks.

" It makes me happy I'm not working on the web. ;-)"

You're the second or third to recommend Tangled Web. On my reading list for if I get back into Web development. I'm sure I'll have the same reaction. You might find it funny that a prior commenter found it shocking that I hadn't read work on secure, web applications. Whereas, I originally found it shocking that people were trying to build them.

Perspective changes everything, eh? :)