3 ms·

> Most of these settings can be set and managed from AWS Organisations for free, and backed up with alarming and alerts for Guard Duty trivially. Makes me wond

by jusssi 5y ago

> Most of these settings can be set and managed from AWS Organisations for free, and backed up with alarming and alerts for Guard Duty trivially. Makes me wonder, why are they even settings? Why aren't they just always on?

jiggawatts 5y ago
I've found that every one of these security incidents always has someone come in and say: "Why didn't they just ..." Where the problem is that the "..." is the subset of non-default security configurations that would have stopped this specific insider(!) attack. They never mentioned that: - You can't predict which attack you'll be hit with, so you have to implement every non-default / optional security setting or feature in order to be "protected". This is a metric ass-ton of work, typically on the order of multiple man years of up front effort, and then with ongoing multiple FTEs required (e.g.: for separation of roles). - While you're not actually under insider attack, this provides zero business benefit that can be measured in dollars. - The people implementing the protection against insider attack are the same people that the protection would typically be designed to stop. No one person can be trusted to do this. Not even any one team. Just organising the Byzantine security required for this is a project manager's nightmare. - Insider attacks by senior technical staff are stupidly difficult to protect against. I've never seen any org that could survive an intelligent, motivated attacker that already has significant admin rights. Even the FAANGS would take a significant "hit" in this scenario. Ubiquiti is nowhere near their scale or capabilities in this space. - All that stuff described like "QR codes in a safe" are hilarious to me. Every time I've tried to implement even 1/10th of that, everyone who ought to be responsible for the secure handling of this kind of key material ran away screaming from any personal responsibility. Literally nobody ever wanted to deal with anything even vaguely similar. - Many of complex delegation systems and IAM technologies suffer from permission-role inversion. Often the CEO/CIO/CTO has virtually no access to the technology stack, but the junior intern from the subcontractor has the keys to the castle and could delete the whole org for shits and giggles. But, you see, he's not "allowed to". But he has the physical permissions. That he's not supposed to use. Because he was told to. You see? - Now you're going to say that the senior staff should have the admin rights, and delegate the appropriate rights to the junior staff. Oh, you sweet summer child. That requires responsibility! (see above). It also requires that they learn, manage, and monitor something as technically complex as AWS IAM. But you see, senior people are busy people. They're busy with meetings. With memos. And more importantly, they're busy playing politics and jostling for the next promotion. The fiddly security rule stuff they just delegate to the juniors. That's the ticket to the next pay grade!

by jusssi 5y ago

jiggawatts 5y ago

I've found that every one of these security incidents always has someone come in and say: "Why didn't they just ..." Where the problem is that the "..." is the subset of non-default security configurations that would have stopped this specific insider(!) attack. They never mentioned that: - You can't predict which attack you'll be hit with, so you have to implement every non-default / optional security setting or feature in order to be "protected". This is a metric ass-ton of work, typically on the order of multiple man years of up front effort, and then with ongoing multiple FTEs required (e.g.: for separation of roles). - While you're not actually under insider attack, this provides zero business benefit that can be measured in dollars. - The people implementing the protection against insider attack are the same people that the protection would typically be designed to stop. No one person can be trusted to do this. Not even any one team. Just organising the Byzantine security required for this is a project manager's nightmare. - Insider attacks by senior technical staff are stupidly difficult to protect against. I've never seen any org that could survive an intelligent, motivated attacker that already has significant admin rights. Even the FAANGS would take a significant "hit" in this scenario. Ubiquiti is nowhere near their scale or capabilities in this space. - All that stuff described like "QR codes in a safe" are hilarious to me. Every time I've tried to implement even 1/10th of that, everyone who ought to be responsible for the secure handling of this kind of key material ran away screaming from any personal responsibility. Literally nobody ever wanted to deal with anything even vaguely similar. - Many of complex delegation systems and IAM technologies suffer from permission-role inversion. Often the CEO/CIO/CTO has virtually no access to the technology stack, but the junior intern from the subcontractor has the keys to the castle and could delete the whole org for shits and giggles. But, you see, he's not "allowed to". But he has the physical permissions. That he's not supposed to use. Because he was told to. You see? - Now you're going to say that the senior staff should have the admin rights, and delegate the appropriate rights to the junior staff. Oh, you sweet summer child. That requires responsibility! (see above). It also requires that they learn, manage, and monitor something as technically complex as AWS IAM. But you see, senior people are busy people. They're busy with meetings. With memos. And more importantly, they're busy playing politics and jostling for the next promotion. The fiddly security rule stuff they just delegate to the juniors. That's the ticket to the next pay grade!