They are soc 2 compliant - so it must be OK ;)
I mean, they can prove on paper that they are secure. Who cares about reality any more.
I mean, they can prove on paper that they are secure. Who cares about reality any more.
I've grown a bit cynical as time goes on about this sort of stuff; not the need for the kinds of controls and checks behind SOC2, but cynical towards the lip service I continue to hear about it from the executives and leaders I find in many shops.
The "InfoSec/CyberSecurity/DevSecOps" director is often a glorified send button. "The SIEM said do this, send to Devops, the auditor said do this, send to Dvops, the vulnerability monitor noticed this, send to Devops, we were asked to provide evidence of this, send to Devops"...etc.
3 of the last 5 jobs I've been in since 2016 have had dedicated personnel with the words "Information Security" in their job titles, and all 3 of them were really good at sending me shit to do, talking about what they read in some infosec blog, and a CVE they read about.
But here's the thing, I think I have a really good reason for this cynicism and I don't know what how to resolve it:
I don't know how confident I would be if these individuals were actually expected to build and contribute to the security effort beyond "send to Devops", but maybe they're not supposed to? Are "DevSecOps" people expected to actually...be involved in engineering too? Or do they just sit at the periphery throwing vulnerability assessments and threat modeling work? I've honestly only ever had the latter.
Tried having this conversation with a friend who just finished an MSc in Cybersecurity and he seemed a bit offended by my inquiry, so I dropped it...but I am still insanely curious to know because I really doubt this experience is unique.
I don't know of many developers, that in their day job, who pro- actively consider security. It's always "it's behind a firewall", or "it's for internal purposes", etc. Security practices need to be built in.
The best way I can think of to remedy this is to make university lecturers care as much about full stack security as say using goto or raw pointers or serverless or <insert flavour of the month>. I don't think a class on security would do it either.
A good way to fast track security practices in the universities would be to have actual hackathons that attempt to breach cs and it department computers... with extra points if you can make a clown of the head of the it dept or professor of security.
It'll take a few years, I admit, but things would eventually change. I can't see any other way, other than the general populace getting so sick of this stuff that legislation would be written to heavily penalise companies that are breached.
2c
I suggested this once actually at an org that made frequent use of Hackathons (as in we had one every quarter), basically an internal CTF challenge.
Executive paranoia took over and held strangled the life out of any good sense, nuance or reason, so of course in the end, we never did it.
They only know to press some buttons and then send some reports.
Adages about being able to ISO 9001 certify a cement life jacket ^H^H^H SOC-2 certify an Open S3 bucket remain true, but there is a certain amount of deliberate intent required on both sides to complete the process. In other cases it can be used as an excuse to give security _some_, much needed reason for funding and effort.
Consider the people who cannot handle a SOC-2 audit. They exist, they walk among us and get funding.
Having been the only security guy in a large, and complex, engineering enterprise, it feels darned near impossible. Security is often just regarded as an added expense, until something happens.
It really does take buy-in from everyone, understanding security, being invested in security, and consistently accounting for security, for a program to be super effective. Otherwise security is left playing whack-a-mole, asking teams to fix all the things they constantly are finding out of compliance.
I should note, understanding the issues helps, as you can also tell them what findings are irrelevant in their specific context. For web app security for instance, many issues are browser-related, and may not matter for inter-system API calls.