Red Hat, I am very disappointed. We're all ISO27001 everywhere, separation of data, and separation of network resources. But you keep our data in your github repo?
You've got to look at ISO27001 from the perspective of the Sales Rep, not from an Engineer.
In theory, being ISO27001 means that you're environment follows best practices and has a somewhat sane security posture.
To the business people, a new customer demands that you have ISO27001 certification before they'll sign the $$$$ contract. The salesperson does not care HOW you get the certificate, just that you have it, they need this contract signed!
The department wasn't designed with security in mind, so implementing everything required by ISO will take many months. But sales needs $$$$ now! The CEO, CFO, and CTO are aligned: money now!
So, there's high pressure to pass the audit quickly. You implement what you can, you weasle your way around the things that will take too long. Those things are "out of scope" or "testing databases". You implement MFA while the auditor is auditing, but you know it breaks developers' workflows and there isn't a quick fix, so you turn MFA back off once the audit is complete....
TA-DA! We're ISO27001 certified! But we're no more secure than we were before.
> In theory, being ISO27001 means that you're environment follows best practices and has a somewhat sane security posture.
Nah, it just means you have defined, documented processes and document that you stick to them. They actual processes can be shit and maybe you also have something on the side the auditors don't get shown, but ultimately the certification is a total joke. Source: Worked at a place that got certified despite being a security joke.
Yes and no. Even if it is a joke there is one thing it qualifies: You at least spent time looking at the process. This already is a gain over complete wild west.
Engineers who are smart enough / talented enough, and who feel secure, can push back on security issues even if it will hold up a deal. This tells me that the most valuable engineers at Red Hat either do not push back enough on security concerns, or don't care enough (or aren't experienced enough) to know that the concerns exist in the first place, or they feel insecure in their position.
Ultimately, devs can't get sales reps fired, but sales reps can absolutely get devs fired.
Depending on how dysfunctional the org is, there's no super dev anywhere who can fix it. You just shut up, do bad things knowing theyre bad, or get fired.
It should be the opposite. For every big engineering issue happened because of the sales' dept pressures, the sales reps would have their asses out of any company.
Every time I've been involved in audits at a company, my boss will tell me "let me tell you how to talk to auditors," which ends up meaning lie by omission, imply that things are in good standing without making strictly false statements, and otherwise just make the auditors go away. It all seems silly, but maybe it should be thought of like the court system? An adversarial process whereby each side is vying for its own interests?
With auditors you talk like you would either talk on a deposition or on the witness stand: do not say more than what you were asked, do not make assumptions, do not try to be helpful in any way, do not offer more data than asked for.
Is it really OK? Not necessarily, but on the other hand you don't want to spend the rest of your life answering even more questions from other people the auditors might bring in to help them understand your helpful explanations.
I learned this the hard way, assuming auditors are logical and understand technology.
90% of the time, they are checking boxes. But if they are fishing, you have to be careful because they generally are bad at understanding anything, but good at manipulating the audit rules to frame things in such a way so they can “catch a big fish”.
That may sound bad or immoral by the company, but know that auditors have the own ambition and mo ey to think about, and will try to mark any possible thing as a serious problem regardless of whether it is.
Yes, it is highly adversarial and the best compromise I've seen is to have an internal audit team that is separate organizationally from IT, but has to withstand peer review if they claim anything is a real problem.
> Correction: After publishing, Red Hat confirmed that it was a breach of one of its GitLab instances, and not GitHub. Title and story updated.
> After publishing our story, Red Hat confirmed that the security incident was a breach of its GitLab instance used solely for Red Hat Consulting on consulting engagements, and not GitHub.
> While Red Hat did not respond to any further questions about the breach, the hackers told BleepingComputer that the intrusion occurred approximately two weeks ago.
GitLab, not GitHub. I think the distinction is that you can have a on-prem GitLab (as well as hosted online). The implication here being that RedHat probably had very relaxed account security.
