Nobody Cares About Security
adatosystems.com
adatosystems.com
At another company in 2015, I discovered we were sending user credentials for a large hospitals in plain text across the network and need to fix this ASAP. When I brought this up to management, they shrugged and said "it's been this way for years and we have other priorities". After a large New York hospital was breached, I suddenly had management show up to my desk in panic asking how we can fix the issue immediately. I came up with a nice write-up for both our company and the hospital IT groups on how to secure our infrastructure with certs and whatnot and they still half-assed it with self-signed certificates.
In 2018 I worked for a fin-tech company in charge of some A-list celebrity 401K portfolios. We had a default admin password for our production database. ZERO encryption on the data; including SSN, birth-date, phone numbers, addresses, beneficiaries info, etc.
Last year one of the leading payroll providers in the country (USA) I used to work for started aggressively out-sourcing the software and allegedly had a really nasty security breach due to a back-door inserted by one of the out-sourced team members. It's alleged that leadership threatened employees if they disclosed the incident to anyone outside a key group of members.
Nobody give a damn about security until their identity is stolen and they have to spend hours/days/weeks/months putting their lives back together from the fallout.
This is exactly why the CrowdStrike disaster happened: https://news.ycombinator.com/item?id=41011065
https://www.theinformation.com/articles/companies-are-ditchi...
but the OP's arguments also apply to insurance, yet businesses buy insurance every day. The difference is the fines and liability for data breaches are so paltry it is the rational thing to do not to invest in security. This can only change through legislative action. I wouldn't hold my breath.
What's the problem with self-signed certificates? Did they not know each other?
Especially for internal server-to-server connections there shouldn't be any security weaknesses in a fully self-signed architecture where the same scripts that deploy the certificates will also deploy the configuration on other servers specifying that this is the only thing that should be trusted.
In the banking sector, you can still, to this day, try to get away with stealing money by forging a paper check and hoping the bank honors it. And they may let you walk away with the cash! What protects the system is that when the fraud is detected via auditing and resolution, actual law enforcement will come find you.
The early web never had such legal protections ("Wikipedia's database was hacked? What even is a wikipedia? They got their facts disrupted? What does that mean?"), so they were forced to grow infrastructural protections or be consumed by attackers. But there's a case to be made that the costs inherent with hardening infrastructure like that are unnecessary to bear when the law will actually show up to stop the criminals messing with your infrastructure. It's counter-intuitive for those of us raised on the "You can only rely on yourself; everyone else is a potential attacker" side of the fence, but it's a way to be.
I think these are the main problems and why it's hard to tackle. I think they can help prevent issues but I'd like to hear other suggestions:
1) You can't measure maintenance or security benefits the same way as you can measure costs of failures. You can measure the cost it takes to implement, but when you do you can't measure the counterfactual cost of if you hadn't. It's not actualized. But I'm confident maintenance is always cheaper than repairs. Don't fix things that aren't broken, but do fix things before they break. We need to learn the difference.
2) the world is complex and many costs are outsourced and distributed. I like to think of this like the inverse software success. Software is great because once made you can copy it trivialy and distribute it. But the down side is the mistakes propagate too! So something that may only cause a second delay is seen as miniscule but it's not when you consider a hundred million users using it every day. Enshitification is about these little things adding up and accumulating.
3) we avoid slack like the plague. I don't mean slacking off, but slack in the system. You don't make a ship and only have enough lifeboats for exactly the number of passengers. You need more because you can't assume everyone perfectly makes it to the right life boat, especially in an emergency. Covid should have been a real wakeup call but the global economy shouldn't shut down anytime a single ship gets stuck.
4) doing good and quality work has the stability of an inverse pendulum. Most evil and shit isn't caused by malice, it's that it's harder to do good and with longer and more complex tasks it's easier for something to go wrong along the way which then snowballs.
So a big belief I have is trust we need to slow down if we want to speed up. Move fast and best things is great when problem solving but you need to also also go back and clean up all the mess you've left behind. We've become so accustomed to technical debt we aren't even recognizing how much we have.
We can't be just focused on the next quarter. We're in a much more complex world. Even early humans had to plan for winter. I know what I'm asking for is difficult but nothing worth doing is usually easy. All of us have done hard things and continue to do hard things. But importantly, try not to distribute and amplify mistakes. Squash them when they're small. Don't ask for permission, just fix things.
If we could replace things like SSNs, passport numbers, credit card numbers, etc. with org-specific tokens/certificates, they'd be largely useless to anyone else.
Sadly, no one cares enough about security to fix the problem though, not even governments.
In most places worldwide identifiers equivalent to SSNs and passport numbers aren't really treated as financial secrets; they may not be totally public due to certain privacy aspects, but they generally don't result in financial identity theft, that's a fixable problem of certain regions (like USA and a few others). Similarly, moving to proper credit card authentication (chip&pin or wireless chip when card is present, 3dsecure when not, etc) has made many credit card numbers mostly useless for thieves unless accompanied by a more serious compromise.
But all these things above have been implemented only because (and where, and when) the actual companies became financially liable for the consequences - as long as the losses/fraud/etc hit only the users/consumers, there is no motivation to fix anything. Shift the liability to the company which accepts that fundamentally insecure data as good enough, and they'll figure out some way to implement a secure process.
The liability shift that I had in mind is mostly about immunity from liability for the impersonated person, like, if some criminal defrauds a company by claiming to be Bob, then shifting the liability for that risk (compared to currently common cases in USA) to that company which had lax processes and was defrauded would be various consumer protection mechanisms for things like credit score, preventing that company from trying to collect that money from Bob, preventing them from reporting that Bob owes them money (as he doesn't) and requiring that company to correct any adverse credit reports if they had already made them, etc, various means to ensure that the fraud stays between the fraudster and the defrauded company and doesn't affect the person whose identity was falsely used; and removing the implication that they are somehow responsible if that information (which they aren't legally required to keep secret) is used by someone else.
And monthly insurance bills that explicitly reflect discounts/charges paired to inspection histories & inspector statistics.
Suddenly efficient but strident inspectors will find themselves gods of seasonal demand.
Consider TLS, the "industry standard" for connecting two processes securely over the network. There is a huge amount of complexity just to accomplish something that should be secure by default. Certificates, algorithms, cipher suites, domain names (for some reason). Cue the people who have traded some of their valuable time to memorize this trivia showing up to defend TLS and how simple it is. They remark that anyone who hasn't memorized this trivia "isn't a security expert".
Contrast that to something like Wireguard. There are keys, one is private, and I swap the public ones. Simple as that. If the only way to connect two processes was to transfer a string `<public-key>@<ip address>` between them, think about how many problems would be avoided, and how many fewer security "experts" the industry would need.
You must be a TLS expert because saying we need to check if a public key "belongs to the claimed identity" is creating a problem where none exists. The public key is an identity, that's who I want to connect to. In the Wireguard example, it really is that easy.
With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to.
Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.
In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary.
DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `<public key>@<ip:port>` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
The problems with make name lookups yield certificates are all real-world, pragmatic, people-based issues:
* The deployed base of DNS software, which includes middleboxes of all shapes and sizes that pay attention to DNS, is hostile to things that look like DANE lookups, so DANE lookups (really, all DNSSEC lookups) have a high failure rate, so high that anything using DNSSEC needs to have an alternate path to building a secure channel without DNSSEC.
* The entities that ultimately decide what DNS lookups are going to return (note well: those entities are rarely ever the people who "own" the zones themselves) are themselves firms with roughly the same shape as certificate authorities, but with none of the accountability mechanisms; browser vendors had to force legacy CAs to adopt Certificate Transparency and no such leverage exists for the DNS.
* For bonus fun, add in that ultimately most of the (~all of the popular) TLDs are de jure government controlled --- and governments have a lot of practice exploiting their control over DNS for policy ends.
DNSSEC is a dead letter. Deployment in .COM actually WENT DOWN within the last 24 months, and it was trifling to begin with. The most common experience large tech companies have had with deploying it is "falling off the face of the Internet for several hours due to misconfiguration". Stick a fork in it. It was a reasonable idea that, like many reasonable ideas, has turned out to be completely impractical in the real world.
For the vast majority of use cases, this cannot be done, hence certificates (with CA)
At which point I just had to stop and re-evaluate the problem again. If I have such a small amount of data that I am find at processing it at single-digit IPS (micro-MIPSes? geez...) then surely I could just process it locally, and much faster (and cheaper to boot)? And if I have an amount of data large enough to warrant using cloud resources, and important enough to justify paying astronomical sums... surely I could just spend that kind of money to simply buy lots of hardware and, again, run it locally, and much faster (and cheaper to boot)?
That's why my switch from software development to application security only lasted four years. It drove me up the wall to find so many vulns and have them ignored because they weren't necessary to fix for the various compliance checklists to be completed. No one cared if systems were actually secured, they just cared that they got their compliance certified so if there ever were a breach, they'd have coverage for their liability. It's also an area where most people in it have little to no actual programming experience so when tools mark potential vulns, programmers can get away with claiming it's a false positive and everyone moves on, even if it's a plain as day case of clear text PII going out over the internet or some ancient injection vuln that no one wants to get their hands dirty fixing.
There are more formal/rigorously defined terms for this and variations. You can google IND-CCA to start digging in.
By default I mean that the least complicated, easiest to use, front-and-center API establishes this sort of connection with the 2nd party. And sending insecure data becomes akin to dealing with raw ethernet frames, possible, sometimes necessary, but not even allowed on most operating systems without elevated privileges. Concretely that might look like replacing `dial(host, port) -> Conn` functions with `dial(publicKey, host, port) -> SecureConn` functions.
Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.
If it was just Serve and Dial with the guarantees I mentioned, we would be in agreement that it was easy and a suitable default.
> "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined."
I thought I was fairly clear in saying: less complicated == better. That is the way in which it is better, that I am now defining explicitly for you. If that's controversial then that probably explains most your disagreement. The complexity has to be so low relative to other solutions that it is more likely to be used than not.
I must disagree. a vulnerability where a threat actor has no way of exploiting it in the real world is not a security issue. On the flip side, a software that magically lacks any vulnerability in its code can still have design issues like bad UX or easy to misconfigure (is it elastic's fault when people expose their elastic db to the internet for example).
In the software dev world, there is this view that security is absolute. in reality, it is very much relative to the data and real-world threat. Since software devs aren't expected to know details about current threats, they're expected to think in terms of absolute and hypothetical scenarios. Which is great for writing software,but when evaluating or discussing security (software or otherwise), it's not about how many vulnerabilities there are, it is about data vs threat actors and how that risk impacts you.
But if we built a culture and practice that low-security code is low-quality code, and made security issues a software defect like any other, it would get handled. Plenty of developers (and leads, and PMs) are fine with shipping low-security code, but would fight to the death if accused of shipping low-quality code.
[0] https://blog.invisiblethings.org/2008/09/02/three-approaches...
Sometimes I wonder what we lost by only working on things with measurable impact
It's just that it is not the norm, so expectations are low. Some companies consistently do better than others, so clearly it's not all down to luck.
> The McNamara fallacy (also known as the quantitative fallacy),[1] named for Robert McNamara, the US Secretary of Defense from 1961 to 1968, involves making a decision based solely on quantitative observations (or metrics) and ignoring all others.
Which had a profound effect on the Vietnam War
I agree, by the way, we shouldn't focus only on measurable metrics. Humans, and businesses should also value "norms and values". Although I have no idea how to evangelise this
"the prevailing attitude among business leaders is:
Damage to the company’s reputation SOUNDS bad, but (so the thinking goes) it’s really too amorphous to quantify. Plus, many companies in recent memory were the victims of massive cyber attacks, took a hit to their reputation or stock price, but saw it rebound a week later with no other ill effects. (again, that’s the belief. More on this later)
The fines currently in place appear to be lower than the expected cost to improve the company’s security posture."
But where is the counterargument against that? There is no "more on this" in the article, and if those two things are true, then it would be wrong for companies to start caring more, as it's cheaper/more effective to suffer the not-that-bad-really consequences than bear the substantial effort and expense of trying to prevent them.
Let's say I'm an executive and I think there's a 1% chance of a breach that costs me 100x and a 1% chance of a 100x payout on every project.
I have 2 projects that each make $X. Let's say $X is $1000. 1 project will go from $X to $X/100 based on breach, so it's now worth $10. 1 project will go from $X to $X*100. It's now worth $100,000.
I went from making $2000 to $99,990.
This goes back to the argument about fines. They aren't NEARLY severe enough. If I'm an executive at a big company, I may enforce greater security on the "cash cow" projects (e.g. ad revenue and GSuite at Google [but not the Pixel or GCloud], AWS and Retail at Amazon [but not Alexa, Kindle, etc]) but the rest? I need to get ANOTHER cash cow. If my service that's only netting me $1M/year goes to $0, and I needed a service that would make $1B, I literally do not care.
If adding in-depth security to the $1M/year project makes delivery 2x slower, I've now spent 2x on something that probably wasn't even worth it. This is a game of stats; businesses and features as cattle not pets. I'd rather have 2 projects and another dice roll than 1 project that's just "meh".
That's not how I operate, but if you're playing this game as an executive, that's the most logical outcome.
There's also a severe over-reliance on completing a checklist, rather than having an answer for a given class of issue. Asking the correct question is important for receiving a good answer. 'Restores are what people care about.'
Critical vendor failure and ability to operate independently in an isolated recovery mode might be new features added to recently updated checklists.
The best thing anybody can do for this is making apis that make `unrepresentable` unsafe things.
` A classic is password length. Instead of `login(user:str, pwd:str)`, do `login(user:NotEmptyStr, pwd:ValidPwd)`.
This is stuff that must be done in the lower layers, to take advantage of how lazy people is. Do it for the most popular libraries and frameworks and we are talking about real impact.
The newer generation of companies and startups are better, but it's still a work in progress.
Security cares about nobody.
Glad that was clarified, I was afraid I was "Nobody".
What the author is trying to articulate makes me wonder if he considered what security is.The core properties we mean when we say "security" are the CIA triad (confidentiality, integrity and availability). You can't tell me a "business leader" doesn't care about any of those. You have business related information that is vital for your business continuity and profitability. The confidentiality, integrity and availability are what we generally mean (not always though) when we say "security".
I'd argue that business leaders do care about security a lot. I think what the author means is "nobody cares about security for the sake of saying you're secure", but even then, business leaders do care about theatrical security, because it helps them sell their products and services. "we have a state of the art, military grade, encrypted cybers, unlike the competition". There are even popular and profitable security vendors whose main service is rating the security posture of companies, so that when you do B2B you avoid poorly rated businesses that won't protect the data you will share with them.
Security for individuals is a different topic than businesses, it's almost a different ballgame altogether.
Use APTs as an example, should some mom&pop small/medium size business care about them? Certainly not. They should care about ransomware though, because chances are, they can't afford the downtime and ransom payment. Should a defense contractor business care about APTs? yeah, like all of them and then some.
Context and nuance are important.
It's NOT that nobody cares about the results of security. It's that those results ("not losing our sales database")are often not presented clearly or coherently enough for the decision makers to recognize the value of the activity ("doing regular backups, paying for offsite storage, etc.")
To sum it up, what business people think about the term "secure" in terms of computer information is "The data we need for business has confidentiality, I can rely on its integrity and it will be available when we need it for business reasons". They may not necessarily be concerned abut quantifiable and/or short-term profits. appearances, morale, ability to recruit new hires, come up with new solutions/products better than the competition can, because the systems we use are reliable and secure with less hoops to jump through because of "security theatrics".
I suspect that the current widespread ignorance of this fact is the result of a covert operation by one or more TLAs.
Basically you have to have a whole team of people whose only job is to maintain the correct/accurate security levels for everyone else, grant and revoke them in a timely manner.
And a whole another team to maintain this for every single software service that the company runs and uses, internally or externally.
So the solution is either a huge performance or cost penalty, or both.
> I suspect that the current widespread ignorance of this fact is the result of a covert operation by one or more TLAs.
No. It's a simple fact that it's difficult and costly to maintain and most orgs don't have the talent to do so in-house or the money to hire external experts.
Image if some agency had decided that knowledge of fuses and circuit breakers should be restricted in the national interest. This would make electo-security a Trillion dollar industry.
Just as cyber security is now.
--
We let random people plug things into the electrical grid. We don't have to run an "electrical scan" for each item plugged in. We don't have central authentication of people and devices being plugged in. This is because the default is NOT to get all of the power in the US electrical grid in every outlet. It's a default deny policy. We all understand how it works.
When experts are required, they come in, make required changes, and leave. On site electricians aren't a common site except for weird things like McCormick place in Chicago, where they are required to plug ANYTHING in.
If a user wants to plug in an Electric Range, Electric Dryer, Welder, etc. they have to find an appropriate outlet. The capabilities of each outlet are defined in advance. There are widely respected standards.
On the other hand, we are forced to run virus scanners, and try to enumerate every piece of code before we use it to compute. If we run code, it can use all of the resources of the host it's running on, in almost all cases. The policy is default allow. We blame users, applications, and software vendors for mishaps. There are no standards. Everything is layers of band-aids on top of Operating Systems that are insecure by design.
This is madness.
If we could now find out how to do security in an economical, non-annoying way, that would be great
Therefore products that increase security and products that decrease security do not look any different to those buying them.
Companies do not give a sh*t...
When we have GDPR style laws in place in the U.S., companies will start to care..
4% of a companies annual worldwide turnover is a tremendous deterrent..
It's a lesson that I've learned, the hard way.
I've seen things, man...
Is buying antivirus "paying for good security"? Hiring the first security firm that showed up in a Google search?
If you advertise for a security person to join your company, how do you effectively interview candidates?
They paid Accenture and Gartner to tell them what to do.
Ditto for having them set up a security organization -- get Accenture to sit a temporary CISO, hire some people, and then fuck off. Hopefully the replacements work!
Mom and Pop shops might use Google, but in 2024 they're usually using whatever the local, oversubscribed MSP is selling.
"Passing our audit" has been presented with measurable consequences (cannot sell to customers) and finite, well-defined actions (this is what the audit list looks like).
What I'd like (the goal of the follow up article, coming soon) is to present the value of security in a way that makes the justification of the effort viable and palatable.
What people do not give a shit about is digital security. Because nothing about computers or the Internet "is real". And it's getting less real by the day. That's the fascinating psychological talking point.
Our culture in particular excels at implementing this bias.
Recovery from an encryption event is great and all, but it doesn’t solve the problem of your new regulatory fine and legal problems.
> This brings me back to my original point: Nobody (i.e., business leaders) cares about security. What they care about is avoiding lost revenue due to application downtime, extortion, and lawsuits.
Followed by arguing that fines and reputation loss, under the current status quo, aren't seen by business leaders as being extraordinarily disastrous.
This is starting to align with security needs now too (eg. ransomware, data breaches, etc).