DevSecOps Stating The Obvious - Part2
Previous part https://medium.com/@ahmad.aabed/devsecops-stating-the-obvious-14b53a36b53f
I am still stating the obvious when it comes to DevSecOps 😄
Review your tools
Nowadays, it became super easy to add a new tool to your stack
Log in with Github and there you go, you have a tool for code quality coverage. Allow access to AWS and there you go you have a tool for billing analysis.
While those tools are really helpful, you should always ask yourself
- Who are the creators of a certain tool, what is their reputation
- What the minimal access the tools can get
- What if the creators are malicious
- What if the creators have a malicious internal actor
- What if the tool itself gets hacked
- What is the minimal access the tool can get to do its job
I believe you should answer all of these questions before carrying on, because what if the code coverage tool you are using gets hacked and your code is taken, do you have something to worry about rather than your IP? Secrets and Keys for example?
What if your CI server is hacked, you Docker registry …etc?
Scanners FTW
No, I am not going to talk about the vulnerability scanners while they are useful what I want to talk about here is your own scanners looking for misconfigurations, we have the rules in place, the policy is written, but human error is inevitable, and I suggest having scanners running to detect any mistakes, for example, if no EC2 security group is allowed to go public you should have a scanner periodically checking if this rule is enforced or not
here is a dirty code to check that
apply the same concept for everything, scan for public docker images, IAM rules, and of course the root of all devils “public S3 buckets.”
Threat Detection
Recently Cado security released a report regarding the first crypto-mining worm to steal AWS credentials, we have seen this type of attack before when Tesla’s Kubernetes dashboard was hacked, and AWS got stolen, but it was a single attack, not a worm, read more here https://www.cadosecurity.com/2020/08/17/teamtnt-the-first-crypto-mining-worm-to-steal-aws-credentials/
Event threat detection products can help with such attacks by detecting mining traffic you can use products like
- https://aws.amazon.com/guardduty/
- https://cloud.google.com/security-command-center/docs/how-to-use-event-threat-detection
Watch for CVE lists and latest security updates
It’s really important that the team stays up to date regarding the latest CVEs
Of course, your code scanners we mentioned in part one can automatically detect some vulnerabilities but how about vulnerabilities in the tools themselves, for example, a vulnerability in Kubernetes or in Jenkins
Keep your eyes open for security updates, password dumps, new worms out there ..etc
Just like the Cado report above
Final thoughts
Security is an ongoing process, you should always review, enhance and repeat
Humans are important, and I am not talking about the typical weakest link thing, I am talking about not pissing the whole development team for a new policy, security is really important, but the whole point of DevSecOps is to integrate security in the process not to prevent people from working and slow down productivity.
If the development team is not happy with the security policies, then you have a problem with the policies themselves or the security, people can be pissed because they don’t understand why a certain policy in place, train them and try to be as transparent as possible.
NEVER do security only on paper, some organizations might just want a written down policies to pass an audit or something, never write something that you don’t do
“Write what you do, and do what you write”
