4 ms·

> You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side I am not a security engineer. But as a generalist s

> You’ll get much more bang for buck for the product’s security by working on the enterprise and infra side I am not a security engineer. But as a generalist software engineer I do not believe this. Every time I go looking in app code with an eye on security, I immediately find all kinds of vulnerabilities. And yet, where I work, the security guys don't read or write a single line of app code. They do like you say, and focus almost entirely on the infra/business process side of things. I find it really hard to respect these people when they are more worried about locking down what jira tickets I can view than they are actually securing our product.

tomnipotent 3y ago
> entirely on the infra/business process side of things Considering most of the major incidents over the last few years fall into these categories, it makes sense.
- dogman144 3y ago
  Exactly
lelanthran 3y ago
My experience of IT Security in enterprises is that it's simply a checkbox to check off so that someone, somewhere, can say "I followed best practices; this breach cannot be blamed on me!" Preventing breaches is an objective, but it's purely secondary to CYA. This is why the Security Strategy Policy exists and often looks so out of touch with reality: 1. An external consulting firm advised on that policy document. 2. Someone signed off on that policy document (CEO/CTO/COO/etc). 3. Everyone below that person ticked-off every single clause in that document. 4. Breach occurs. 5. Employees can't be blamed, they did everything that was asked of them 6. CEO/CTO/sign-off person cannot be blamed: they sought, paid-for, received and heeded professional advice. 7. The external firm cannot be blamed, as their advice is "in line with modern security guidelines." In this sense, no one should be shifting focus from whatever the policy document says because then they can be blamed.
- dgb23 3y ago
  Security is of adversarial nature. Us vs them. But the reason I find your comment interesting is that it turns that towards the inside. Trivially the ones to blame are the attackers. But the responsibility for protecting against them is treated like a hot potato. It seems to be more important to say “It’s not our fault” than to prevent attacks. Why is that? I think a big reason is the interface of the technical side. People want to hear that it’s safe, but engineers can only really say “It’s safe against these particular things.” But it’s uncomfortable to hear that.
  - afiori 3y ago
    If the approach to a accident/catastrophe/breach is to find guilt and assign blame then there are strong and clear incentives to avoid blame. In a lot of contexts this cannot be significantly changed by company culture as many legal systems adopt this approach. The oft mentioned other approach is to assume that human and operational error cannot be eliminated[0] and design systems to withstands many compounding mistakes. Afaik we do this only in aviation and infrastructure [0] these two approaches are similar and live on a continuum between "we punished the guilty party, the problem is no more" and "let's make sure that this not any similar problem never happens again". Both extremes are often wrong, but in many cases it is a good idea to move towards the latter.
- dogman144 3y ago
  This rarely is the dynamic for startups. They’re not. Ringing in KPMG to advise on security lol. The closest that’ll happen is sales RFPs everyone had to pass to sell to enterprise, which yes can be full of holes and checkboxes.
dogman144 3y ago
Locking down Jira tickets isn’t enterprise sec, so that’s not what I’m referring to. This risks that happen that lead into bad exploits for startups and the controls available: - SaaS vendor is breached and doesn’t tell you for a week: okta allows you to cleanly kill perks for that SaaS, and impacted users - dev downloads a database access package on vscode, puts in prod creds, the package is calling home bc it’s surprise malware: EDR catches it - dev has prod passwords on their MacBook note sheets, or accessing prod from a home computer: process enforcement, password manager, secrets vault - customer service employee is phished, pivots into customer data: IR plans and email security tools - product m API is “move fast and break things” and full of vulns: except for the worst of them, get a WAF/cloud flare to cover and be careful about public endpoints beyond that. The above secures a product with limited bandwidth and a small security team, if you’re thinking defense in depth (which you should be). It’s important for sec engs to code, no doubt. Two things to note that I think you’re missing, putting aside issues if your sec team is doing Jira ticket focuses vs the above. - code vulns are paired with exploit paths. If a WAF is there, and the code doesn’t pivot into prod DBs and so on, these can wait to remediate. - Have you tried remediating code vulns or getting application logs for security, at a product-focused startup? Devs are the worst enemy here. Anything touching the code is “slowing the product” usually. Security is a political job and this is an easy way to burn all your social capital if you chase each of vuln. In short, you’re thinking about vulns, but not threat models. Startup sec program is all about smart thread modeling.

tomnipotent 3y ago

> entirely on the infra/business process side of things Considering most of the major incidents over the last few years fall into these categories, it makes sense.

dogman144 3y ago
Exactly

lelanthran 3y ago

My experience of IT Security in enterprises is that it's simply a checkbox to check off so that someone, somewhere, can say "I followed best practices; this breach cannot be blamed on me!" Preventing breaches is an objective, but it's purely secondary to CYA. This is why the Security Strategy Policy exists and often looks so out of touch with reality: 1. An external consulting firm advised on that policy document. 2. Someone signed off on that policy document (CEO/CTO/COO/etc). 3. Everyone below that person ticked-off every single clause in that document. 4. Breach occurs. 5. Employees can't be blamed, they did everything that was asked of them 6. CEO/CTO/sign-off person cannot be blamed: they sought, paid-for, received and heeded professional advice. 7. The external firm cannot be blamed, as their advice is "in line with modern security guidelines." In this sense, no one should be shifting focus from whatever the policy document says because then they can be blamed.

dgb23 3y ago
Security is of adversarial nature. Us vs them. But the reason I find your comment interesting is that it turns that towards the inside. Trivially the ones to blame are the attackers. But the responsibility for protecting against them is treated like a hot potato. It seems to be more important to say “It’s not our fault” than to prevent attacks. Why is that? I think a big reason is the interface of the technical side. People want to hear that it’s safe, but engineers can only really say “It’s safe against these particular things.” But it’s uncomfortable to hear that.
- afiori 3y ago
  If the approach to a accident/catastrophe/breach is to find guilt and assign blame then there are strong and clear incentives to avoid blame. In a lot of contexts this cannot be significantly changed by company culture as many legal systems adopt this approach. The oft mentioned other approach is to assume that human and operational error cannot be eliminated[0] and design systems to withstands many compounding mistakes. Afaik we do this only in aviation and infrastructure [0] these two approaches are similar and live on a continuum between "we punished the guilty party, the problem is no more" and "let's make sure that this not any similar problem never happens again". Both extremes are often wrong, but in many cases it is a good idea to move towards the latter.
dogman144 3y ago
This rarely is the dynamic for startups. They’re not. Ringing in KPMG to advise on security lol. The closest that’ll happen is sales RFPs everyone had to pass to sell to enterprise, which yes can be full of holes and checkboxes.

dogman144 3y ago

Locking down Jira tickets isn’t enterprise sec, so that’s not what I’m referring to. This risks that happen that lead into bad exploits for startups and the controls available: - SaaS vendor is breached and doesn’t tell you for a week: okta allows you to cleanly kill perks for that SaaS, and impacted users - dev downloads a database access package on vscode, puts in prod creds, the package is calling home bc it’s surprise malware: EDR catches it - dev has prod passwords on their MacBook note sheets, or accessing prod from a home computer: process enforcement, password manager, secrets vault - customer service employee is phished, pivots into customer data: IR plans and email security tools - product m API is “move fast and break things” and full of vulns: except for the worst of them, get a WAF/cloud flare to cover and be careful about public endpoints beyond that. The above secures a product with limited bandwidth and a small security team, if you’re thinking defense in depth (which you should be). It’s important for sec engs to code, no doubt. Two things to note that I think you’re missing, putting aside issues if your sec team is doing Jira ticket focuses vs the above. - code vulns are paired with exploit paths. If a WAF is there, and the code doesn’t pivot into prod DBs and so on, these can wait to remediate. - Have you tried remediating code vulns or getting application logs for security, at a product-focused startup? Devs are the worst enemy here. Anything touching the code is “slowing the product” usually. Security is a political job and this is an easy way to burn all your social capital if you chase each of vuln. In short, you’re thinking about vulns, but not threat models. Startup sec program is all about smart thread modeling.