... so honestly, at this point, we basically have another Uber thing every 2nd week. I do not get why there is no legal action taken against Uber or even steps to shut it down. So much of the stuff violate basic laws how to run a business, apart from the humongous flaws in Ubers ethics and damaging effects on society.
Uber Paid Hackers to Delete Stolen Data on 57M People
501–510 of 606 posts
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#502Amazon's access control and authorization system is the current most important broken thing in the industry. The Joe Sullivan details are the lurid stuff that propels news story copy, but the important takeaway is that almost nobody, including companies with serious investments in security, can safely get a large-scale dev team deploying onto AWS. This story keeps getting re-told, and has been for something like 5 ye…
Full disclosure: I'm the founder of CloudSploit[1] which aims to reduce these risks. You're definitely on to something here. While I wouldn't call AWS security "broken," it is next to impossible to implement it correctly in any medium to large size business. There are 30+ services that AWS provides, each with an infinite number of security controls, JSON-based policies, etc. Cross-service access is even worse. Almost…
That doesn't match with the rest of your comment. At all. What would you call broken, then?
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#503Earlier quoted context omitted.
Yep, but think of all of the private keys and tokens used in automation servers (think CI) for pulling down source. Those don't have 2FA - because they don't login - but they have full access to most source. In an organization of about 200 engineers across various products, 1000+ github repos, and 10 or so different CI systems. We enforce 2FA at github. I can still easily see how someone could easily gain access to s…
> In an organization of about 200 engineers across various products, 1000+ github repos Wait, what? That's 5+ repos per engineer. What on earth would warrant that level of granularity? I've only worked once in my career in a place that used more than 2-3 repositories total, and that was a "MegaTechGiant" with thousands of engineers.
I'm surprised you're being so heavily downvoted for your question. Engineering teams (and software companies) come in all shapes and sizes. It is absolutely reasonable for even an experienced engineer to have only worked at companies with a handful of repos.
Rather than downvoting, it would have been helpful to explain why your company has opted for such granularity (perhaps engineers or teams have a high level of autonomy, or your software is highly componentised and built from a great many, separately managed, parts).
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#504Earlier quoted context omitted.
I assume it was password reuse from one of their engineers or something similar. If you could compromise GitHub itself there would probably be higher value targets (source code for upcoming AAA games, Coinbase, government organizations, etc.)
> If you could compromise GitHub itself there would probably be higher value targets (source code for upcoming AAA games I'm intrigued. Why would that be a higher-value target?
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#505Earlier quoted context omitted.
> In an organization of about 200 engineers across various products, 1000+ github repos Wait, what? That's 5+ repos per engineer. What on earth would warrant that level of granularity? I've only worked once in my career in a place that used more than 2-3 repositories total, and that was a "MegaTechGiant" with thousands of engineers.
I know that mentioning downvotes usually invites more downvotes, but... I'm surprised you're being so heavily downvoted for your question. Engineering teams (and software companies) come in all shapes and sizes. It is absolutely reasonable for even an experienced engineer to have only worked at companies with a handful of repos. Rather than downvoting, it would have been helpful to explain why your company has opted…
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#506Earlier quoted context omitted.
"Don't check secrets into VCS, folks! " I suppose? But at this point they have your code base . You are so owned at that point.
Yeah, but hopefully they can't do much if they just have your code base. If the secrecy of your code is the only thing stopping hackers from exploiting you, you're missing some gaping holes in your infrastructure. With that said, nothing wrong with using secrecy as a additional barrier, but shouldn't be the only, and if it's not the only, you're not "so owned at that point".
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#507Earlier quoted context omitted.
What makes you think you (or most devs for that matter) know more about security than Github's security team?
It's not just about who knows more about security. It's a trade-off, and you need to account for other factors like cost, availability/uptime, data integrity, total attack surface area and others. Honestly, I'm surprised this is such a controversial point of view, but judging by the downvotes it appears it is. You learn something new every day, I guess.
I think you’ve misinterpreted people’s reactions. It’s not at all controversial to use other companies’ services for your most sensitive assets, it’s your opinion that appears controversial to them. If you’re in control of your own servers, what remains is to trust GitHub Enterprise not to literally phone home your source code or to enable remote code execution on your own server. There are myriad information security policies and compliance methodologies for compartmentalizing, quantifying sharing that risk.
For what it’s worth, having personally performed security assessments for over 50 different companies across the gamut of size/maturity, nearly all of them use a centralized VCS hosted or produced by GitHub or Bitbucket (and nowadays, occasionally GitLab too).
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#508Earlier quoted context omitted.
I never quite know how to think about them. On the one hand, they’d changed an entire industry in a way that people wanted but was getting serious resistance from the entrenched players. They had to break a lot of rules and go around a lot of people with a whole lot of connections to get where they are and in the process made a lot of enemies. I expect blowback. I expect negative news. They essentially pulled it off…
Plenty of companies have disrupted plenty of industries by now, but without this kind of behavior. I don't see how the way they dealt with the data breach was required to disrupt the local ground transportation industry, nor was the way they've treated employees (including drivers) and customers.
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#509Earlier quoted context omitted.
This is so gob-smackingly uncommon I started asking "do you require 2fa for your github accounts" as part of my interview questions when I was looking for jobs (i.e. I'd ask my interviewers). I don't know how to feel knowing that there is even one software-focused company out there that doesn't enforce 2fa on its github accounts. Like... how?! Why?!
Unless you're talking about a 3 person start-up, wouldn't the use of github itself be a red flag? If you're a software company, you live and die by your source code. Why on earth would you rely on some other company to hold it for you? This seems as ridiculous as doing your bookkeeping on Google Docs. I've never once worked in a company that permitted source code to leave the company network.
Re: Uber Paid Hackers to Delete Stolen Data on 57M People
#510Earlier quoted context omitted.
You're in charge of security at a large e-commerce company, and your view is that your company is bound to get hacked? I think that's a very sad commentary on how little your company values security.
I think your perspective is either immature or unrealistic. OP's a realistic. His perspective is nothing to do with how a company values security. No one in security assumes they won't get hacked, we assume we will and when we do get compromised. Our metrics aren't measured on if, our success metrics are: * How quickly we find out * How much damage we can mitigate * How quickly we mitigate the risks and controls for…