3 ms·

My go-to example of a whole mesh of "accountability sinks" is... cybersecurity. In the real world, this field is really not about the tech and math and crypto -

My go-to example of a whole mesh of "accountability sinks" is... cybersecurity. In the real world, this field is really not about the tech and math and crypto - almost all of it is about distributing and dispersing liability through contractual means. That's why you install endpoint security tools. That's why you're forced to fulfill all kinds of requirements, some of them nonsensical or counterproductive, but necessary to check boxes on a compliance checklist. That's why you have external auditors come to check whether you really check those boxes. It's all that so, when something happens - because something will eventually happen - you can point back to all these measures, and say: "we've implemented all best practices, contracted out the hard parts to world-renowned experts, and had third party audits to verify that - there was nothing more we could do, therefore it's not our fault". With that in mind, look at the world from the perspective of some corporations, B2B companies selling to those corporations, other suppliers, etc.; notice how e.g. smaller companies are forced to adhere to certain standards of practice to even be considered by the larger ones, etc. It all creates a mesh, through which liability for anything is dispersed, so that ultimately no one is to blame, everyone provably did their best, and the only thing that happens is that some corporate insurance policies get liquidated, and affected customers get a complimentary free credit check or some other nonsense. I'm not even saying this is bad, per se - there are plenty of situations where discharging all liability through insurance is the best thing to do; see e.g. how maritime shipping handles accidents at sea. It's just that understanding this explains a lot of paradoxes of cybersecurity as a field. It all makes much more sense when you realize it's primarily about liability management, not about hat-wearing hackers fighting other hackers with differently colored hats.

chrisweekly 2y ago
+1 Insightful Thank you for sharing this really illuminating take. I spend an unreasonable amount of time dealing with software security, and you've put things in a light where it makes a bit more sense.
diognesofsinope 2y ago
> "we've implemented all best practices, contracted out the hard parts to world-renowned experts, and had third party audits to verify that - there was nothing more we could do, therefore it's not our fault" The amount of (useless) processes/systems at banks I've seen in my career that boil down to this is incredible, e.g. hundreds of millions spent on call center tech for authentication that might do nothing, but the vendor is "industry-leading" and "best in-class". > It's just that understanding this explains a lot of paradoxes of cybersecurity as a field. It all makes much more sense when you realize it's primarily about liability management, not about hat-wearing hackers fighting other hackers with differently colored hats. Bingo. The same situation for most risk departments at banks or healthcare fraud and insurance companies. I thought risk at a bank was going to be savvy quants, but it's literally lawyers/compliance/box-checking marketing themselves as more sophisticated than they are. Like the KYC review for products never actually follow up and check if the KYC process in the new products works. There's no analytics, tracking, etc. until audit/regulators come in an ask, "our best-in-class vendor handles this". All the systems are implemented incorrectly, but it doesn't matter because the system is built by a vendor and implemented by consultants, and they hold the liability (they don't, but it will take ~5 years in court to get to that point). Beginning to understand what "bureaucracy" mechanically is.
- finnh 2y ago
  What's funny is that checklists in hospitals have been shown, empirically, to be massive life-saving devices. cyber perhaps not so much...
  - __float 2y ago
    Checklists work well in high stress situations where you cannot forget a step (medicine, aviation). A checklist in a security incident? Probably helpful. A security checklist to satisfy auditors and ancient regulations? This is an entirely different kind.
    - pixl97 2y ago
      Yea, the problem most often in computer security checklists is misapplication of the checklist. I do cyber security related stuff for the finance and they have some of the dumbest checklists ever. A more recent one I got was "We only allow the HTTP verbs 'GET' and 'POST', your application can only use that and the verbs PUT, PATCH, and DELETE cannot be used. After not replying 'are you fucking stupid' I said "You do realize that you are using a RestAPI application and that these verbs can go to the same interface to modify the call in different way? Not only would we have to rewrite our application which would probably take months to years, you would have to rewrite tons of applications on your side to make this actually work." You get these dipshit auditors from other firms that pick up some 'best practice' from 2003 and put it in a list then get a god complex about it needing to be implemented when they have absolutely zero clue why the original thing was called out in the first place. For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application.
      - TeMPOraL 2y ago
        > For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application. Thanks. One thing that's more interesting than the revealed stupidity of such rules is the actual (and often sensible) reason they were first created long ago. "Temporary" hacks outliving both the problem they solved and the system they were built for seems to be a regular occurrence in bureaucracy as much as it is in software and hardware.
neilv 2y ago
The most unfortunate thing about much of corporate 'cybersecurity' is that it combines expensive and encumbering theatre around compliance and deniability... with ridiculously insecure practices. Imagine, for example, if more companies would hire for software developers and production infrastructure experts who build secure systems. But most don't much care about security: they want their compliances, they may or may not detect and report the inevitable breaches, and the CISO is paid to be the fall-person, because the CEO totally doesn't care. Now we're getting cottage industries and consortia theatre around things like why something that should be a static HTML Web page is pulling in 200 packages from NPM, and now you need bold third-party solutions to combat all the bad actors and defective code that invites.
- stavros 2y ago
  > Imagine, for example, if more companies would hire for software developers and production infrastructure experts who build secure systems. I do imagine that, and they get hacked (because you have to get lucky every time, but the hackers only need to get lucky once), and then the press says "were you doing all the things the whole industry says to do?" and they say "no, but we were actually secure!" and the press goes "well no you weren't, you got hacked, and you weren't even doing the bare minimum!" and then the company is never heard of again.
Rhapso 2y ago
Honestly is is just like Insurance. You understand the value of things you are protecting (and simple compliance has a value to you in penalties and liabilities avoided) and make sure it costs more than that to break into your system. At a corporate level, it is contractually almost identical to insurance, with the product being sold liability for that security, not the security itself.
- TeMPOraL 2y ago
  Right. I sometimes call it meta-level insurance, because it's structurally what it is. Funnily, actual insurance is a critical part of it - it's the ultimate liability sink, discharging whatever liability that didn't get diluted and diffused among all relevant parties. And, I guess it's fine - it's the general way of dealing with impact that can be fully converted into dollars (i.e. that doesn't cause loss of life or health).
  - photonthug 2y ago
    It’s really not fine. Expensive and useless security theater isn’t just inefficient and corrupt, it’s way more actively harmful than that because there’s a huge opportunity cost associated with all the wasted time and money AND the incentivized deliberate refusal to make obviously good/easy/cheap improvements. Even in matters pertaining purely to dollars.. Spreading out liability can’t erase injury completely. it just pushes it onto the tax payer because someone is paying the judge to sit in the chair and listen to the insurance people and the lawyers.
lucianbr 2y ago
I wonder what the difference is between cybersecurity and civil aviation safety. At a glance they both have a lot of processes and requirements. Somehow on one side they are as you said, a way to deal with liability without necessarily increasing security, while on the other safety is actually significantly increased.
- TeMPOraL 2y ago
  I think a big part of it is that failures in aviation safety cost lives, often dozens or hundreds per incident, in quite immediate, public and visceral fashion. There also isn't much gradation - an issues either causes massive loss of life, or could cause it if not caught early, or... it's not relevant to safety. On top of that, any incident is hugely impactful on the entire industry - most people are fully aware how likely they'd be to survive a drop from airliner altitude, so it doesn't take many accidents to scare people away of flying in general. Contrast that to cybersecurity, where vast majority of failures have zero impact on life or health of people, directly or otherwise. Even data breaches - millions of passwords leak every other week, yet the impact of this on anyone affected is... nil. Yes, theoretically cyberattacks could collapse countries and cause millions to die if they affected critical infrastructure, but so far this never happened, and it's not what your regular cybersecurity specialist deals with. In reality, approximately all impact of all cyberattacks is purely monetary - as long as isn't loss of life or limb, it can be papered over with enough dollars, which makes everyone focus primarily on ensuring they're not the ones paying for it. I think it's also interesting to compare both to road safety - it sits kind of in between on the "safety vs. theater" spectrum, and has the blend of both approaches, and both outcomes.
  - Wobbles42 2y ago
    > I think a big part of it is that failures in aviation safety cost lives This is an interesting point, and it certainly affects the incentives involved and the amount of resources allocated to mitigating the problems. I do think cyber security incidents with real consequences are likely to become more common going forward (infrastructure etc). We haven't experienced large state actors being malicious in a war time footing (yet). Will we able to better mitigate attacks given better incentives? I think that is an open question. We will certainly throw more resources at the problem, and we will weight outcomes more heavily when designing processes, but whether we know how to prevent cybersecurity incidents even if we really want to... that I wonder about.
motohagiography 2y ago
Security is closer to product management and marketing than engineering. It's a narrative and the mirror image of product and marketing, where instead of creating something people want based on desire, it's managing the things people explicitly don't want. When organizations don't have product management, they have anti-product management, which is security. We could say, "There is no Anti-Product Division." Specifically on accountability, I bootstrapped a security product that replaced 6-week+ risk assessment consultant spreadsheets with 20mins of product manager/eng conversation. It shifted the accountability "left" as it were. When I pitched it to some banks, one of the lead security guys took me aside and said something to the effect of, "You don't get it. we don't want to find risk ourselves, we pay the people to tell us what the risks and solutions are because they are someone else. It doesn't matter what they say we should do, the real risk is transferred to their E&O insurance as soon as they tell us anything. By showing us the risks, your product doesn't help us manage risk, it obligates us to do build features to mitigate and get rid of it." I was enlightened. Manage means to get value from. The decade I had spent doing security and privacy risk assessments and advocating for accountability for risk was as a dancing monkey.
- TeMPOraL 2y ago
  I worked in GRC space for a while, which is where I finally realized the things I wrote above. Our product intended to give CISOs greater visibility into threats and their impacts, making it easy to engage in probabilistic forecasting to prioritize mitigations. Working on designing and building it made me see the field from the perspective of our customers, and from their POV, cyber-threats are all denominated in dollars, mitigating threats boils down to not having to pay corresponding dollars, and that it's often more effective to ensure someone else pays than to address the underlying technological or social vulnerability.
  - motohagiography 2y ago
    we have close experiences for sure. mine was positioned as pre-GRC, more of a design stage tool. like an aha.io/roadmap.com for security. an early champion kept asking how it got them compliance and what compliance frameworks did it implement. I kept insisting this isn't for compliance, it's product level design for security- and that I wasn't interested in making a compliance tool because compliance is stupid. ironically it was essentially an anti-corporate security product. of course security people said, "wat, wut?" and it it was because I had made something for what I thought people should do, but not what they wanted. it's funny looking back at it, as I was so burned out and hating the security work I was doing that I just said f'it, and automated it. the biggest conceit (among many) was believing customers would want the results of the risk assessment consulting services I offered if they could do it themselves for 1/100th of the price. the other lesson was, if someone doesn't or won't take accountability for risks, it's almost never because they are dumb.
steveBK123 2y ago
Rhyming with this observation - the only time I've ever heard someone getting fired over a phishing incident anywhere I've worked.. was a guy on the cybersecurity team who clicked through and got phished.
werrett 2y ago
This is the ultimate nihilistic take on security. Yes, 'cyber' security has devolved to box checking and cargo culting in many orgs. But what's your counter on trying to fix the problems that every tech stack or new SaaS product comes without of the box? For most people when their Netflix (or HN) password gets leaked that means every email they've sent since 2004 is also exposed. It might also mean their 401k is siphoned off. So welcome the annoying and checkbox-y MFA requirements. If you're an engineer cutting code for a YC startup -- Who owns the dependancy you just pulled in? Are you or your team going to track changes (and security bugs) for it in 6 months? What about in 2 or 3 years? Yes, 'cyber' security brings a lot of annoying checkboxes. But almost all of them are due to externalities that you'd happily blow past otherwise. So -- how do we get rid annoying checkboxes and ensure people do the right thing as a matter of course?
- TeMPOraL 2y ago
  > For most people when their Netflix (or HN) password gets leaked that means every email they've sent since 2004 is also exposed. It might also mean their 401k is siphoned off. So welcome the annoying and checkbox-y MFA requirements. Not true. For most people, when their Netflix or HN password gets leaked, that means fuck all. Most people don't even realize their password was leaked 20 times over the last 5 years. Yes, here and there someone might get deprived of their savings (or marriage) this way, but at scale, approximately nothing ever happens to anyone because of password or SSN leaks. In scope of cybersec threats, people are much more likely to become victims of ransomware and tech support call scams. I'm not saying that cybersec is entirely meaningless and that you shouldn't care about security of your products. I'm saying that, as a field, it's focused on liability management, because that's what most customers care about, pay for, and it's where the most damage actually manifests. As such, to create secure information systems, you often need to work against the zeitgeist and recommendations of the field. EDIT: > This is the ultimate nihilistic take on security. I don't believe it is. In fact, I've been putting efforts to become less cynical over last few months, as I realized it's not a helpful outlook. It's more like, techies in cybersecurity seem to have overinflated sense of uniqueness and importance of their work. The reality is, it's almost all about liability management - and is such precisely because most cybersec problems are nothingburgers that can be passed around like a hot potato and ultimately discharged through insurance. It's not the worst state of things - it would be much worse if typical cyber attack would actually hurt or kill people.
bostik 2y ago
That is also why so much of the security[tm] software is so bad. Usability and fitness for purpose are not box-tickers. The industry term in play is "risk transfer". Most security software does not do what it advertises, because it doesn't have to. Its primary function is for the those who bought the product, to be able to blame the vendor. "We paid vendor X a lot of money and transferred the risk to them, this cannot be our fault." Well, guess what? You may not be legally the one holding the bag, but as a business on the other end of the transaction you are still at fault. Those are your customers. You messed up. As for vendor X? If the incident was big enough, they got free press coverage. The incentives in the industry truly are corrupt. Disclosure: in the infosec sphere since the early 90's. And as it happens, I did a talk about this state of affairs earlier this week.
Meleagris 2y ago
We should really define a new term for such work. Perhaps "Risk Compliance Security" or "Security Compliance Engineering" Where "Security Compliance Engineering" is the practice of designing, implementing, and maintaining security controls that satisfy regulatory frameworks, contractual obligations, and insurance requirements. Its primary objective is not to prevent cyberattacks, but to ensure that organizations can demonstrate due diligence, minimize liability, and maintain audit readiness in the event of a security incident. Key goals: - Pass external audits and internal reviews - Align with standards like ISO 27001, SOC 2, or NIST - Mitigate organizational risk through documentation and attestation - Enable business continuity via legal defensibility and insurability In contrast… Cybersecurity is focused on actively detecting, preventing, and responding to cyber threats. It’s concerned with protecting systems and data, not accountability sinks.

chrisweekly 2y ago

+1 Insightful Thank you for sharing this really illuminating take. I spend an unreasonable amount of time dealing with software security, and you've put things in a light where it makes a bit more sense.

diognesofsinope 2y ago

> "we've implemented all best practices, contracted out the hard parts to world-renowned experts, and had third party audits to verify that - there was nothing more we could do, therefore it's not our fault" The amount of (useless) processes/systems at banks I've seen in my career that boil down to this is incredible, e.g. hundreds of millions spent on call center tech for authentication that might do nothing, but the vendor is "industry-leading" and "best in-class". > It's just that understanding this explains a lot of paradoxes of cybersecurity as a field. It all makes much more sense when you realize it's primarily about liability management, not about hat-wearing hackers fighting other hackers with differently colored hats. Bingo. The same situation for most risk departments at banks or healthcare fraud and insurance companies. I thought risk at a bank was going to be savvy quants, but it's literally lawyers/compliance/box-checking marketing themselves as more sophisticated than they are. Like the KYC review for products never actually follow up and check if the KYC process in the new products works. There's no analytics, tracking, etc. until audit/regulators come in an ask, "our best-in-class vendor handles this". All the systems are implemented incorrectly, but it doesn't matter because the system is built by a vendor and implemented by consultants, and they hold the liability (they don't, but it will take ~5 years in court to get to that point). Beginning to understand what "bureaucracy" mechanically is.

finnh 2y ago
What's funny is that checklists in hospitals have been shown, empirically, to be massive life-saving devices. cyber perhaps not so much...
- __float 2y ago
  Checklists work well in high stress situations where you cannot forget a step (medicine, aviation). A checklist in a security incident? Probably helpful. A security checklist to satisfy auditors and ancient regulations? This is an entirely different kind.
  - pixl97 2y ago
    Yea, the problem most often in computer security checklists is misapplication of the checklist. I do cyber security related stuff for the finance and they have some of the dumbest checklists ever. A more recent one I got was "We only allow the HTTP verbs 'GET' and 'POST', your application can only use that and the verbs PUT, PATCH, and DELETE cannot be used. After not replying 'are you fucking stupid' I said "You do realize that you are using a RestAPI application and that these verbs can go to the same interface to modify the call in different way? Not only would we have to rewrite our application which would probably take months to years, you would have to rewrite tons of applications on your side to make this actually work." You get these dipshit auditors from other firms that pick up some 'best practice' from 2003 and put it in a list then get a god complex about it needing to be implemented when they have absolutely zero clue why the original thing was called out in the first place. For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application.
    - TeMPOraL 2y ago
      > For those who wonder, typically these verbs are disabled to prevent the accidental enablement of WebDAV on some platforms, especially Windows/IIS that had some issues with security around it. It makes zero sense for such a rule in a modern API application. Thanks. One thing that's more interesting than the revealed stupidity of such rules is the actual (and often sensible) reason they were first created long ago. "Temporary" hacks outliving both the problem they solved and the system they were built for seems to be a regular occurrence in bureaucracy as much as it is in software and hardware.

neilv 2y ago

The most unfortunate thing about much of corporate 'cybersecurity' is that it combines expensive and encumbering theatre around compliance and deniability... with ridiculously insecure practices. Imagine, for example, if more companies would hire for software developers and production infrastructure experts who build secure systems. But most don't much care about security: they want their compliances, they may or may not detect and report the inevitable breaches, and the CISO is paid to be the fall-person, because the CEO totally doesn't care. Now we're getting cottage industries and consortia theatre around things like why something that should be a static HTML Web page is pulling in 200 packages from NPM, and now you need bold third-party solutions to combat all the bad actors and defective code that invites.

stavros 2y ago
> Imagine, for example, if more companies would hire for software developers and production infrastructure experts who build secure systems. I do imagine that, and they get hacked (because you have to get lucky every time, but the hackers only need to get lucky once), and then the press says "were you doing all the things the whole industry says to do?" and they say "no, but we were actually secure!" and the press goes "well no you weren't, you got hacked, and you weren't even doing the bare minimum!" and then the company is never heard of again.

Rhapso 2y ago

Honestly is is just like Insurance. You understand the value of things you are protecting (and simple compliance has a value to you in penalties and liabilities avoided) and make sure it costs more than that to break into your system. At a corporate level, it is contractually almost identical to insurance, with the product being sold liability for that security, not the security itself.

TeMPOraL 2y ago
Right. I sometimes call it meta-level insurance, because it's structurally what it is. Funnily, actual insurance is a critical part of it - it's the ultimate liability sink, discharging whatever liability that didn't get diluted and diffused among all relevant parties. And, I guess it's fine - it's the general way of dealing with impact that can be fully converted into dollars (i.e. that doesn't cause loss of life or health).
- photonthug 2y ago
  It’s really not fine. Expensive and useless security theater isn’t just inefficient and corrupt, it’s way more actively harmful than that because there’s a huge opportunity cost associated with all the wasted time and money AND the incentivized deliberate refusal to make obviously good/easy/cheap improvements. Even in matters pertaining purely to dollars.. Spreading out liability can’t erase injury completely. it just pushes it onto the tax payer because someone is paying the judge to sit in the chair and listen to the insurance people and the lawyers.

lucianbr 2y ago

I wonder what the difference is between cybersecurity and civil aviation safety. At a glance they both have a lot of processes and requirements. Somehow on one side they are as you said, a way to deal with liability without necessarily increasing security, while on the other safety is actually significantly increased.

TeMPOraL 2y ago
I think a big part of it is that failures in aviation safety cost lives, often dozens or hundreds per incident, in quite immediate, public and visceral fashion. There also isn't much gradation - an issues either causes massive loss of life, or could cause it if not caught early, or... it's not relevant to safety. On top of that, any incident is hugely impactful on the entire industry - most people are fully aware how likely they'd be to survive a drop from airliner altitude, so it doesn't take many accidents to scare people away of flying in general. Contrast that to cybersecurity, where vast majority of failures have zero impact on life or health of people, directly or otherwise. Even data breaches - millions of passwords leak every other week, yet the impact of this on anyone affected is... nil. Yes, theoretically cyberattacks could collapse countries and cause millions to die if they affected critical infrastructure, but so far this never happened, and it's not what your regular cybersecurity specialist deals with. In reality, approximately all impact of all cyberattacks is purely monetary - as long as isn't loss of life or limb, it can be papered over with enough dollars, which makes everyone focus primarily on ensuring they're not the ones paying for it. I think it's also interesting to compare both to road safety - it sits kind of in between on the "safety vs. theater" spectrum, and has the blend of both approaches, and both outcomes.
- Wobbles42 2y ago
  > I think a big part of it is that failures in aviation safety cost lives This is an interesting point, and it certainly affects the incentives involved and the amount of resources allocated to mitigating the problems. I do think cyber security incidents with real consequences are likely to become more common going forward (infrastructure etc). We haven't experienced large state actors being malicious in a war time footing (yet). Will we able to better mitigate attacks given better incentives? I think that is an open question. We will certainly throw more resources at the problem, and we will weight outcomes more heavily when designing processes, but whether we know how to prevent cybersecurity incidents even if we really want to... that I wonder about.

motohagiography 2y ago

Security is closer to product management and marketing than engineering. It's a narrative and the mirror image of product and marketing, where instead of creating something people want based on desire, it's managing the things people explicitly don't want. When organizations don't have product management, they have anti-product management, which is security. We could say, "There is no Anti-Product Division." Specifically on accountability, I bootstrapped a security product that replaced 6-week+ risk assessment consultant spreadsheets with 20mins of product manager/eng conversation. It shifted the accountability "left" as it were. When I pitched it to some banks, one of the lead security guys took me aside and said something to the effect of, "You don't get it. we don't want to find risk ourselves, we pay the people to tell us what the risks and solutions are because they are someone else. It doesn't matter what they say we should do, the real risk is transferred to their E&O insurance as soon as they tell us anything. By showing us the risks, your product doesn't help us manage risk, it obligates us to do build features to mitigate and get rid of it." I was enlightened. Manage means to get value from. The decade I had spent doing security and privacy risk assessments and advocating for accountability for risk was as a dancing monkey.

TeMPOraL 2y ago
I worked in GRC space for a while, which is where I finally realized the things I wrote above. Our product intended to give CISOs greater visibility into threats and their impacts, making it easy to engage in probabilistic forecasting to prioritize mitigations. Working on designing and building it made me see the field from the perspective of our customers, and from their POV, cyber-threats are all denominated in dollars, mitigating threats boils down to not having to pay corresponding dollars, and that it's often more effective to ensure someone else pays than to address the underlying technological or social vulnerability.
- motohagiography 2y ago
  we have close experiences for sure. mine was positioned as pre-GRC, more of a design stage tool. like an aha.io/roadmap.com for security. an early champion kept asking how it got them compliance and what compliance frameworks did it implement. I kept insisting this isn't for compliance, it's product level design for security- and that I wasn't interested in making a compliance tool because compliance is stupid. ironically it was essentially an anti-corporate security product. of course security people said, "wat, wut?" and it it was because I had made something for what I thought people should do, but not what they wanted. it's funny looking back at it, as I was so burned out and hating the security work I was doing that I just said f'it, and automated it. the biggest conceit (among many) was believing customers would want the results of the risk assessment consulting services I offered if they could do it themselves for 1/100th of the price. the other lesson was, if someone doesn't or won't take accountability for risks, it's almost never because they are dumb.

steveBK123 2y ago

Rhyming with this observation - the only time I've ever heard someone getting fired over a phishing incident anywhere I've worked.. was a guy on the cybersecurity team who clicked through and got phished.

werrett 2y ago

This is the ultimate nihilistic take on security. Yes, 'cyber' security has devolved to box checking and cargo culting in many orgs. But what's your counter on trying to fix the problems that every tech stack or new SaaS product comes without of the box? For most people when their Netflix (or HN) password gets leaked that means every email they've sent since 2004 is also exposed. It might also mean their 401k is siphoned off. So welcome the annoying and checkbox-y MFA requirements. If you're an engineer cutting code for a YC startup -- Who owns the dependancy you just pulled in? Are you or your team going to track changes (and security bugs) for it in 6 months? What about in 2 or 3 years? Yes, 'cyber' security brings a lot of annoying checkboxes. But almost all of them are due to externalities that you'd happily blow past otherwise. So -- how do we get rid annoying checkboxes and ensure people do the right thing as a matter of course?

TeMPOraL 2y ago
> For most people when their Netflix (or HN) password gets leaked that means every email they've sent since 2004 is also exposed. It might also mean their 401k is siphoned off. So welcome the annoying and checkbox-y MFA requirements. Not true. For most people, when their Netflix or HN password gets leaked, that means fuck all. Most people don't even realize their password was leaked 20 times over the last 5 years. Yes, here and there someone might get deprived of their savings (or marriage) this way, but at scale, approximately nothing ever happens to anyone because of password or SSN leaks. In scope of cybersec threats, people are much more likely to become victims of ransomware and tech support call scams. I'm not saying that cybersec is entirely meaningless and that you shouldn't care about security of your products. I'm saying that, as a field, it's focused on liability management, because that's what most customers care about, pay for, and it's where the most damage actually manifests. As such, to create secure information systems, you often need to work against the zeitgeist and recommendations of the field. EDIT: > This is the ultimate nihilistic take on security. I don't believe it is. In fact, I've been putting efforts to become less cynical over last few months, as I realized it's not a helpful outlook. It's more like, techies in cybersecurity seem to have overinflated sense of uniqueness and importance of their work. The reality is, it's almost all about liability management - and is such precisely because most cybersec problems are nothingburgers that can be passed around like a hot potato and ultimately discharged through insurance. It's not the worst state of things - it would be much worse if typical cyber attack would actually hurt or kill people.

bostik 2y ago

That is also why so much of the security[tm] software is so bad. Usability and fitness for purpose are not box-tickers. The industry term in play is "risk transfer". Most security software does not do what it advertises, because it doesn't have to. Its primary function is for the those who bought the product, to be able to blame the vendor. "We paid vendor X a lot of money and transferred the risk to them, this cannot be our fault." Well, guess what? You may not be legally the one holding the bag, but as a business on the other end of the transaction you are still at fault. Those are your customers. You messed up. As for vendor X? If the incident was big enough, they got free press coverage. The incentives in the industry truly are corrupt. Disclosure: in the infosec sphere since the early 90's. And as it happens, I did a talk about this state of affairs earlier this week.

Meleagris 2y ago

We should really define a new term for such work. Perhaps "Risk Compliance Security" or "Security Compliance Engineering" Where "Security Compliance Engineering" is the practice of designing, implementing, and maintaining security controls that satisfy regulatory frameworks, contractual obligations, and insurance requirements. Its primary objective is not to prevent cyberattacks, but to ensure that organizations can demonstrate due diligence, minimize liability, and maintain audit readiness in the event of a security incident. Key goals: - Pass external audits and internal reviews - Align with standards like ISO 27001, SOC 2, or NIST - Mitigate organizational risk through documentation and attestation - Enable business continuity via legal defensibility and insurability In contrast… Cybersecurity is focused on actively detecting, preventing, and responding to cyber threats. It’s concerned with protecting systems and data, not accountability sinks.