Last external IT audit I had to explain to the auditors what a password manager was. They'd never heard of it.
Last external IT audit I had to explain to the auditors what a password manager was. They'd never heard of it.
The auditors themselves are often tasked with reviewing a massively disparate group of systems, so there's no way they could be come subject matter experts in each one.
So the result is a checklist approach, especially as most compliance tasks are pass/fail.
https://www.crowdstrike.com/cybersecurity-101/cloud-security...
Cloud native tools such as Cilium that leverage eBPF to provide packet level visibility but I doubt 1% of enterprises use them!
https://cloud.google.com/blog/products/containers-kubernetes...
He didn't care about Aws having 2fa configured about our vlan ipsec Tunnel, etc
I even took the liberty to fix the md5 Passwort shit with bcrypt just before the audit...
Are you serious?
What would be your suggestion then?
The solution is defense in depth. Have different accounts with separate access to various services. That way if an account is compromised they don’t have access to everything.
Most of your accounts should provide least access to what they need. Higher level accounts allowing greater control of your system should be rarely available for access and need to be part of regular access control audits.
But non the less with 5 people what audit system would be even available in which only one person has access.
All smart concepts cost either a lot of money or just don't work if you don't have enough people.
Should the only techlead have access to the audit system? Probably. Should the only techlead have access to VMs? Probably yes.
I made sure my systems are encrypted, 2fa wherever possible, no external systems besides the services.
I know this sounds mean but software developers are really embarrassingly bad at security, because security is inconvenient by design and developers strive for convenience.
This is a common statement from security people, and in my view, one of the reasons that security frequently fails.
To make an analogy, it's like a failing startup blaming the market for not adapting to their product. They're trying to solve this in a way the market doesn't want. Likewise, Security teams keep trying to ham-fistedly force everyone to do things in a way that's easy for them, and hard for everyone else.
Ops realized this a while ago, which is why we have so many tools for easily managing infrastructure abstractions. Where are the security abstraction tools? You want accounts to have the least privileges possible, so where are my tools to manage that? From what I've seen, those tools are few and far between.
I maintain that the way security is currently done is actively harmful. It incentivizes not talking to security, because if you do they're going to drop in, make a ton of demands (none of which they will actually help you accomplish), and your PM is going to be pissed the project is now late. Most of the meetings I've been in where security should have been there have involved someone saying "don't do that, because security will get involved".
Frankly, it happens because there is no alternative to using in house security. I can petition my higher ups to let me use AWS or GCP if I'm not happy with how the infrastructure is being managed; who do I petition to use if Security is holding us back?
For what it's worth, compliance departments often have the same issue. They know there's no one else you can use, so they have little incentive to make themselves easy to deal with.
Like some 4 eye system.
They both liked the idea very much that I might need to call them for access to systems I build :D