71–80 of 93 posts
Therefore products that increase security and products that decrease security do not look any different to those buying them.
I suspect that the current widespread ignorance of this fact is the result of a covert operation by one or more TLAs.
Computer security is a solved problem.[1] The problem arose during the VietNam conflict, and was solved in the 1970s. I suspect that the current widespread ignorance of this fact is the result of a covert operation by one or more TLAs. [1] https://en.wikipedia.org/wiki/Multilevel_security
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.
Computer security is a solved problem.[1] The problem arose during the VietNam conflict, and was solved in the 1970s. I suspect that the current widespread ignorance of this fact is the result of a covert operation by one or more TLAs. [1] https://en.wikipedia.org/wiki/Multilevel_security
That's definitely not "solved" for any but the highest level definition, simply due to the fact that it's an absolute nightmare to maintain this kind of approach in large organizations due to people coming, leaving, changing their security levels. 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 ma…
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.
I've been saying this since at least 2009 when the company I worked for was sending credit card info from card readers across the network in plain text and they dragged their feet to fix it even though they knew we were violating some serious SOX policies. 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…
"Nobody (i.e., business leaders)" 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…
Those are great points. And what you're saying is why I used the "nobody cares about backups" analogy. 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".
Earlier quoted context omitted.
> 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. What's the problem with self-signed certificates? Did they not know each other?
IME when people start using self signed certificates they trust anything that is presented, with no pinning. That means that so long as you MITM it with something with it's own self signed cert it will work just fine.
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.
Earlier quoted context omitted.
TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the c…
I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security. 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 aut…
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.
Earlier quoted context omitted.
Sure, now you just need a way to validate the public key and IP address genuinely belongs to the claimed identity. Could use a certificate?
The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we…
Earlier quoted context omitted.
I'd argue that at least some of the problem is that we are forced to record fundamentally insecure data. 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.
We are replacing such things, although USA is a decade or so behind the rest of the world due to various legitimate sociopolitical and historical reasons. 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 pro…