5 ms·

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.

by jgaa 4y ago

dvtrn 4y ago
Boxes: Checked. 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.
- htrp 4y ago
  The Security guy has no responsibility without authority.... his role exists because some regulation/best practice says it needs to exist and therefore it is created. Security is almost always relegated to an afterthought and as a result you end up receiving an e-mail.
- gdfgjhs 4y ago
  Same experience. It is so hard to have a conversation about any of the security requirements with our security team because they have no idea what they are asking. They only know to press some buttons and then send some reports.
  - dvtrn 4y ago
    I'm in the wrong daggone field, man.
- stock_toaster 4y ago
  Yeah, this hits hard. Same experience here.
- cmroanirgo 4y ago
  I've been thinking that the problem can only begin to be addressed when security becomes a first class citizen in the complete tech stack. 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
  - deleted 4y ago
    [deleted]
  - dvtrn 4y ago
    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. 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.
- AviationAtom 4y ago
  Security at enterprise scale is pretty damned hard. 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.
  - tlavoie 4y ago
    When the organization itself takes security seriously, it can be so much better. I'm at a telecom, where we have multiple security teams. Ours is all about security testing, and we're regularly meeting with dev teams to discuss findings, exploring them together if necessary. I'm not always sure about the project managers, but the developers definitely seem to appreciate the insights and guidance. 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.
- er4hn 4y ago
  SOC-2 is best thought of as a basic soundness check on the cybersecurity stance of an organization. The very pessimistic way to think of it is it is a check on sufficient documentation being in place to keep things running if everyone in DevOps/Security is outsourced overnight. 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.

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.

by jgaa 4y ago

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.

dvtrn 4y ago

Boxes: Checked. 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.

htrp 4y ago
The Security guy has no responsibility without authority.... his role exists because some regulation/best practice says it needs to exist and therefore it is created. Security is almost always relegated to an afterthought and as a result you end up receiving an e-mail.
gdfgjhs 4y ago
Same experience. It is so hard to have a conversation about any of the security requirements with our security team because they have no idea what they are asking. They only know to press some buttons and then send some reports.
- dvtrn 4y ago
  I'm in the wrong daggone field, man.
stock_toaster 4y ago
Yeah, this hits hard. Same experience here.
cmroanirgo 4y ago
I've been thinking that the problem can only begin to be addressed when security becomes a first class citizen in the complete tech stack. 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
- deleted 4y ago
  [deleted]
- dvtrn 4y ago
  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. 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.
AviationAtom 4y ago
Security at enterprise scale is pretty damned hard. 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.
- tlavoie 4y ago
  When the organization itself takes security seriously, it can be so much better. I'm at a telecom, where we have multiple security teams. Ours is all about security testing, and we're regularly meeting with dev teams to discuss findings, exploring them together if necessary. I'm not always sure about the project managers, but the developers definitely seem to appreciate the insights and guidance. 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.
er4hn 4y ago
SOC-2 is best thought of as a basic soundness check on the cybersecurity stance of an organization. The very pessimistic way to think of it is it is a check on sufficient documentation being in place to keep things running if everyone in DevOps/Security is outsourced overnight. 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.