Twitter names famed hacker 'Mudge' as head of security

Sometimes they were blindingly obvious things. One employee would drive two bolts, quickly change heads, then drive a third bolt. While the carcass advanced to the next station, the emloyee would change back to the original head and be ready for the next carcass. That employee's suggestion: Make all three bolts the same size so I don't have to change heads.

Of course, that is just a fun anecdote. All such efficiencies have been implemented long ago... for auto assembly. But the point is still valid. Your employees know a ton about your business. Even the ones who do the most mundane tasks. Listen to them. Or... pay a very expensive consultant to listen to them.

i think you hit the nail on the head here. the problem is that the upper management usually arent clueless, they are just better leaders than they are doers...

http://www.shirky.com/weblog/2013/11/healthcare-gov-and-the-...

Back in the mid-1990s, I did a lot of web work for traditional media. That often meant figuring out what the client was already doing on the web, and how it was going, so I’d find the techies in the company, and ask them what they were doing, and how it was going. Then I’d tell management what I’d learned. This always struck me as a waste of my time and their money; I was like an overpaid bike messenger, moving information from one part of the firm to another. I didn’t understand the job I was doing until one meeting at a magazine company.

The thing that made this meeting unusual was that one of their programmers had been invited to attend, so management could outline their web strategy to him. After the executives thanked me for explaining what I’d learned from log files given me by their own employees just days before, the programmer leaned forward and said “You know, we have all that information downstairs, but nobody’s ever asked us for it.”

I remember thinking “Oh, finally!” I figured the executives would be relieved this information was in-house, delighted that their own people were on it, maybe even mad at me for charging an exorbitant markup on local knowledge. Then I saw the look on their faces as they considered the programmer’s offer. The look wasn’t delight, or even relief, but contempt. The situation suddenly came clear: I was getting paid to save management from the distasteful act of listening to their own employees.

In the early days of print, you had to understand the tech to run the organization. (Ben Franklin, the man who made America a media hothouse, called himself Printer.) But in the 19th century, the printing press became domesticated. Printers were no longer senior figures—they became blue-collar workers. And the executive suite no longer interacted with them much, except during contract negotiations.

This might have been nothing more than a previously hard job becoming easier, Hallelujah. But most print companies took it further. Talking to the people who understood the technology became demeaning, something to be avoided. Information was to move from management to workers, not vice-versa (a pattern that later came to other kinds of media businesses as well.) By the time the web came around and understanding the technology mattered again, many media executives hadn’t just lost the habit of talking with their own technically adept employees, they’d actively suppressed it.

Tell me about it. On one of my previous jobs I would constantly speak out about what we were doing would cause people to lose hundreds of thousands of USD, and every time I was laughed out of the meeting for "overthinking" things (I guess that's what wanting to do things right is called these days). When one of our customers lost US$200k and nobody had any idea why or how or when I knew that company would be the death of me, and coincidentally I was on the same meeting I planned to use to quit my job.

If anything it taught me that working in finance is not for me :p

They have a long experience of asking the right questions to the right people , filtering out useless inputs, creating the right abstractions strategically from tactical inputs, there are very niche skills, it may be easy for us, but for the non technical manager it is black magic

As a very expensive consultant I'm surprised the reason is not more clear to you. Most managers like to pay consultancy firms so that they can cover their asses.

If they just followed the guidelines of what the McKinsey team said then surely they weren't in the wrong. Whilst if they followed the advice of a subordinate or god forbid made a decision it's on them.

That is to say, he did executive level work. I imagine he’ll do similarly great work at Twitter, setting them up for long term success, just as he did at Stripe

You need tools for your group.

IT wants to use tool MSFT.

Everybody has been using tool X for a while. They like it, but there is issue Y.

How does upper management resolve this?

but obviously that's not what happened

1. Telling them in person (they didn't understand)

2. Asking for the IT persons Phone number (they didn't give it to me)

3. Leaving my phone number and email (they never contacted me)

4. Notifying the austrian CERT (they never got an answer from the owner)

5. Notifying the press (standard.at posted an article about it, they didn't respond)

6. Writing them on Facebook (ob boy did they respond :D)

But since my first police raid I don't publish anything before letting my lawyer read it. He said if they do press charges they haven't got a chance since I have a paper trail of everything I did and didn't harm them or their site in any way

Security vulns move waaay faster than algos

Setting your security test labs takes way more effort than opening IDE, LeetCode, checking informatic olympics tasks or maybe some book/pdf/write up/wiki

When developing algos you're in your own world meanwhile security often has to mess with other things like software, standards and stuff

e.g you're interested in web sec/hacking, then except understanding of standards (what it allows and what not, etc.) then you have various implementations to care about like web browser - chromium, gecko, ie, safari and stuff. It's a lot of effort!

Let's say that you want to find vulns in PDF parsers/renderers by checking their code source code - I think it'd take a lot of effort to check and understand (let alone exploit) those implementations in two major browsers (I suppose they're different, but I've never checked that)

>I also don't think ctf's are a good model for security questions during interviews

I didn't meant that, sorry if I made it sound as if I expected people to solve CTF tasks during SE interviews

Just wanted to encourage people to do cool stuff :)

You need to know how to avoid common pitfalls (i.e., yeah, maybe nested for-loops with millions of elements per level of iteration, maybe some alarm bells should go off)

Advanced algorithm knowledge is not needed for developing typical business software.

Bad security is a disaster for any public-facing software projects. A product you didn't ship because you hired the wrong people can't be reverted, but neither can a data leak.

Or the company who goes bankrupt because you leaked highly sensitive data.

Etc. etc. ad nauseum.

Would be nice but no, not really. The standards you mentioned are mostly compliance requirements. To be honest, a good chunk of the industry considers them as kind of a joke from a security perspective.

> It's comprehensive and not that hard to learn

Have you even read these standards? I mean, they might be "not hard to learn" but they are far from comprehensive (or specific, depending on which one you are looking at)

> Twitter are not remotely close to operating like that given their recent hacks

Ask literally any security professional you trust, companies compliant with PCI DSS and ISO27k1 get security incidents and breaches all the time just like everyone else and possibly more (given that if they need compliance with these standards they are probably big enough to have very wide/heterogeneous infrastructure/applications portfolio/administration practices/etc). If they claim they don't, that's most likely because their telemetry sucks (so, it still happens they just don't know about it)

The thing to do is familiarize yourself with the OWASP Cheat Sheets directly related to the things you do day-to-day...and to check if the thing you're working on relates to one you're less familiar with.