[HN Gopher] Cybersecurity Is Broken
___________________________________________________________________
Cybersecurity Is Broken
Author : obscurette
Score : 73 points
Date : 2024-04-06 17:43 UTC (5 hours ago)
(HTM) web link (crankysec.com)
(TXT) w3m dump (crankysec.com)
| otabdeveloper4 wrote:
| "Memory unsafe languages" is maybe one percent of one percent of
| the problem.
|
| As always, nobody actually gives a damn about "security" and uses
| it as a pretext to push something unrelated. (In this case,
| Current Year's stupid fad programming language.)
| candiddevmike wrote:
| From what I've seen, we're going to rewrite everything in
| memory safe languages, miss all of the corner case logic and
| tests, and end up less secure than we were at the beginning.
| bradley13 wrote:
| Memory safe languages are nearly irrelevant. Last time I
| looked, freaking _injection_ attacks still held the top place
| among vulnerabilities.
|
| Even companies that take testing seriously rarely test for
| security problems. This needs to change.
| joemazerino wrote:
| Injection attacks holding a top place means the adoption of
| memory-safe languages is working.
| bradley13 wrote:
| No. Injection attacks have held the top place for literally
| decades. They are kindergarten level: validate your inputs.
| Lazy or incompetent developers still fail to do so.
| RajT88 wrote:
| Injection attacks AFAIK have held the top place since
| forever.
|
| It is why people keep buying WAF's.
| nanocode wrote:
| On the other hand, WAFs are another kind of security
| theater. They won't stop any determined attacker. Usually
| you just need to change your payload to make it work.
| Unless you tweak the rules a lot, to the point where you
| could encode then in your application as well (for example
| "user_id" field in the POST data must consist only of
| decimal numbers)
| logicprog wrote:
| > "Memory unsafe languages" is maybe one percent of one percent
| of the problem.
|
| Multiple distinct large scale software projects have found that
| 60-70% of severe CVEs are due to memory safety violations[1].
| The White House has called for projects to use memory safe
| languages [2]. The Android Project has seen an incredibly
| substantial drop in security vulnerabilities concurrent with
| their rapid shift to using memory safe languages in New code,
| with the correlation being so tight and the number of
| vulnerabilities having been so constant before that they are
| forced to conclude that memory safe languages have helped[3].
| So your claim that memory unsafe languages are maybe 1% of 1%
| of the problem is not only completely unsubstantiated, but
| almost certainly false given all of the available information.
|
| And your jab presumably at Rust for being a "fad" similarly
| holds no water. It is the only language that has actually
| offered a practical means of eliminating memory safety
| violations at compile time, statically, without needing a
| runtime or garbage collector or to give up zero cost
| abstractions, meaning that is the only relatively memory safe
| language with a solid shot at working in the fields where C and
| C++ were ordinarily used. That really doesn't seem like a fad
| to me. Or stupid.
|
| As I've said many a time, this sort of denial often seems like
| the cantankerous lashing out of someone who doesn't want to
| learn something new and can't be bothered to look past the
| occasionally superficially annoying antics of a community to
| see the actual technical merits of the software, and perhaps
| even can't stand to be confronted with the fact that their hard
| won knowledge in a needlessly difficult language might
| eventually be less in demand than it was before, and whose
| fragile elitist self-mythology about being better than everyone
| else because they can "write C code without making mistakes" is
| in danger of collapsing under the weight of evidence that it is
| a delusion.
|
| [1]: https://alexgaynor.net/2020/may/27/science-on-memory-
| unsafet... [2]: https://www.whitehouse.gov/oncd/briefing-
| room/2024/02/26/pre... [3]:
| https://security.googleblog.com/2022/12/memory-safe-language...
| Kharacternyk wrote:
| I'm fascinated by C. I agree that using almost anything else
| automatically eliminates entire classes of bugs and
| vulnerabilities, but it's so much _fun_ to be close to the
| machine and avoid those bugs and vulnerabilities myself.
| Judging by the fact that even some greenfield projects are
| still written in C, I'm not alone.
| logicprog wrote:
| I am as much of a rust shill as you'll ever meet, but I agree
| that there is something beautiful and alluring and simple and
| engaging about C that few other languages match. It's
| basically an advanced macro assembler for an abstract
| machine, so there's all of the allure of using 6502 or 68000
| assembly language but with none of the portability problems,
| and a vast ecosystem of libraries and amazing books to back
| it up.
| Kharacternyk wrote:
| I've enjoyed writing a few projects in x86-64 assembly as
| well, for what it's worth. Even though I'm sure that any C
| compiler would generate better assembly than my handwritten
| one. Flat assembler is great, by the way.
| saulpw wrote:
| Any C compiler can generate better assembly for a
| function. But there's often some whole program
| optimizations that you can make, which the C compiler
| isn't allowed to do (because of the ABI/linker).
|
| For example, a Forth interpreter can thread its way
| through "words" (its subroutines) with the top-of-stack
| element in a dedicated register. This simplifies many of
| the core words; for example, "DUP" becomes a single x86
| push instruction, instead of having to load the value
| from the stack first. And the "NEXT" snippet which drives
| the threaded execution can be inlined in every core word.
| And so on.
|
| You can write a Forth interpreter loop in C (I have), and
| it can be clever. But a C compiler can't optimize it to
| the hilt. Of course it may not be necessary, and the
| actual solution is to design your interpreted language
| such that it benefits from decades of C compiler
| optimizations, but nevertheless, there are many things
| that can be radically streamlined if you sympathize with
| the hardware platform.
| bitwize wrote:
| No. Put C out to pasture -- or just take it behind the barn and
| shoot it. Entire classes of severe bugs Just Go Away when you
| switch to a memory-safe language. Not all bugs, obviously, but
| the vast majority of the low-hanging fruit.
| nanocode wrote:
| Well if I could shake my magic wand and instantly convert all
| my (and other) C code to some kind of MemorySafeC code, I
| would. Unfortunately, there is no such magic wand, and all we
| can do is to rewrite tens of millions of lines of C code to
| another language with different tradeoffs and different
| compatibility. It is, in other words, usually not possible.
| Kharacternyk wrote:
| The ideal data protection law would prevent most of the data from
| being collected in the first place. Cybersecurity, on the other
| hand, is about protecting what you have collected anyway. So,
| maybe cybersecurity is broken, but fixing privacy is a great
| first step.
| bradley13 wrote:
| _" When literally nothing happens when some stupid service gets
| popped and loses your data they had no business collecting in the
| first place, this kind of thing will happen over and over and
| over again."_
|
| Money quote, and he's right. In Europe, the GDPR helps stop
| random data collection, but there is still no penalty for getting
| hacked and losing customer data. There should be, and in
| egregious cases upper management should be personally liable for
| civil suits by affected people.
| nanocode wrote:
| Well that's clearly false. GDPR fines for data breach (when
| there is enough negliglence) (or even inproper handling of data
| breach) can be pretty severe. At least in theory, in practice
| the enforcement depends on the country and the fines are
| usually nowhere near the legal limit. But there is a penalty.
| OrvalWintermute wrote:
| cybersecurity can mean many things.
|
| a noun, a verb, a quality, attribute, or function.
|
| In general, I don't see the noun, verb, or function as broken
| (despite being new(immature) fields relatively) but I definitely
| see the quality, or attribute as broken because it is subject to
| the whims of profit and doesn't have many of the guard rails of
| more mature industries.
|
| The Body of Knowledge is not firmly established therefore there
| are huge asymmetries between developers, offensive and defensive
| practicioners, and resourcing/tooling plays a gigantic part of
| this.
| TehCorwiz wrote:
| This is a great summary of the economic problems perpetuating lax
| cybersecurity and the real political reasons we continue to
| suffer. The answer is clear, and there is precedent in other
| similar fields: we need data protection laws with teeth.
| api wrote:
| This, if done right, would also reduce surveillance capitalism
| by turning huge troves of personal data into liabilities rather
| than assets.
| monkburger wrote:
| I wonder if any kind of pro-security legalisation were
| proposed, how many lobbying firms from big tech (Google,
| Amazon, etc) would fight it tooth and nail.
|
| Kind of reminds me of PHK's criticisms of HTTP2, tho
| (https://queue.acm.org/detail.cfm?id=2716278 ), where he
| makes this point;
|
| "The reason HTTP/2.0 does not improve privacy is that the big
| corporate backers have built their business model on top of
| the lack of privacy"
| alephnerd wrote:
| > any kind of pro-security legalisation were proposed
|
| Most of these kinds of policies are done in coordination
| with companies. Google and Facebook/Meta are actually
| massive laggards on the lobbying side.
|
| It's companies like Cisco, Microsoft, PANW, ZScaler,
| Crowdstrike, etc that partake in this. Some of the stuff
| they propose is good, others is crap.
|
| That said, no one's an idiot. Most of these kinds of
| legislations and proposals are a direct result of
| coordination and cooperation between defense buyers and
| vendors.
| Terr_ wrote:
| > You see, cybersecurity is broken because of the lack of
| consequences. It's really that simple.
|
| To put a slightly more explicit phrasing around the blog's
| message: Consequences fall on _the wrong people_. The ones
| _screwing up chasing profit_ are not the ones feeling the pain.
|
| The damage falls on the innocent people the companies were trying
| to use as resources.
|
| This can be broadly classed as an economic externality, much like
| how a company can make money dumping poison into the lake but the
| people who suffer are the ones who drink from it.
| alephnerd wrote:
| Consequences are happening.
|
| People just don't see them because this happens well above the
| IC pay grade and takes some time to percolate down and no one
| wants to publicly announce you shitcanned 5-10 people in middle
| management and security leadership because you enter thorny
| employee litigation territory.
|
| That said, I agree with the author about mismatched
| expectations, though I can safely say that $500k year is VERY
| HIGH for a CISO. I know CISOs for publicly listed F500s who
| earn around 200-300k at most after 15-20 YoE.
|
| The bigger issue is CISOs, VP Security, and Security ICs are
| not enabled institutionally.
|
| If I'm honest, most security engineers suck. 90% are crappy IT
| Admins or Compliance Monkeys who did CISSP and maybe worked for
| PWC or an MDR for 1-2 years and don't know the difference
| between NFTables and NTFS. Most CISOs and VP Sec are former
| security engineers in turn.
|
| Security Engineering NEEDS Security Minded Engineers. Now that
| development teams own Platform Management and Deployment, they
| should also be enabled to own Security, and a Security Team of
| 10x Engineers with a Security background should help with
| implementation and guidance internally. At least this is the
| model I've seen in tech forward public companies (some of whom
| HNers wouldn't even realize are tech first).
|
| I also agree with Scarlett that data protection laws are
| critical and need to be enforced. That said, it's not enough
| (wouldn't protect against a vulnerability disclosure or
| misconfigured ACLs), and several Security ICs I trust recognize
| that as well. That said, the tone of the author and a couple
| well intentioned security minded engineers can impact this
| larger effort. You trap more flies with honey as they say.
|
| A security minded engineer cannot present this kind of an
| article to their non-technical leadership, as it opens multiple
| questions about liability, ownership, and potential
| incompetence.
|
| > Absolutely no amount of gentle pleas disguised as executive
| orders from the White House urging people to use memory-safe
| languages will solve the problem. CISA, despite all the
| phenomenal work they do, can't charge people who mishandle data
| with negligence; critical infrastructure involved or not
|
| Amen to that! There's a reason why pushing for cybersecurity
| insurance might be a good push - hurting the bottom line is a
| good forcing function for change.
|
| ----------
|
| Also, Engineers need to stop being shitty to QA and Platform
| Engineers.
|
| Treat QA, IT, and DevOps as a first class citizen.
|
| I don't give a rat's ass that you like using Mosh or xyz
| project on GitHub (not trying to pick on Mosh).
|
| I don't care that you feel restricted by having to use MacOS
| laptops and SSHing into a CoLo protected behind ZPA when you'd
| rather use ArchLinux on your work laptop.
|
| Every bug, misconfiguration, or non-standard platform
| deployment needs to be treated as a potential security
| liability.
|
| Sure it might slow down the deployment of your "yet another
| wrapper around an LLM SaaS" but there absolutely needs to
| validation.
| nanocode wrote:
| >If I'm honest, most security engineers suck. 90% are crappy
| IT Admins or Compliance Monkeys who did CISSP and maybe
| worked for PWC or an MDR for 1-2 years and don't know the
| difference between NFTables and NTFS
|
| As a security engineer, I agree. I hang up and work with
| really skilled people, so sometimes I'm shocked when I work
| with a client's it security engineer and they barely know how
| to use a terminal. Sometimes don't even have a way (or skill)
| to use SSH. Not to mention that I code/script every day, and
| most "standard" big company security engineers just use ready
| made tools.
|
| Sorry for the rant.
|
| >I don't give a rat's ass that you like using Mosh or xyz
| project on GitHub (not trying to pick on Mosh). >I don't care
| that you feel restricted by having to use MacOS laptops and
| SSHing into a CoLo protected behind ZPA when you'd rather use
| ArchLinux on your work laptop.
|
| I somehow agree with your examples, but not sure if I agree
| with the overall idea behind your messages (as written).
| People have different workflows, and forcing everyone to the
| same mediocre one will just hurt productivity. Of course
| there need to be standards, but if people feel restricted by
| having jump through hoops on unfamiliar operating systems and
| spend a lot of time and frustration fighting them... Then
| they're probably right. You should listen and give way more
| than rat's ass to engineers problems.
| alephnerd wrote:
| > if people feel restricted by having jump through hoops on
| unfamiliar operating systems and spend a lot of time and
| frustration fighting them... Then they're probably right
|
| I completely agree with you!
|
| I think all us people in the cybersecurity space are cranky
| ;)
|
| But it also brings up a good point. I feel bad quality User
| Experience is a critical cause for bugs and
| misconfigurations. And UX isn't just "look pretty" - it's
| about optimized and simplified workflows.
|
| > most "standard" big company security engineers just use
| ready made tools
|
| I've worked for vendors and have funded vendors, so I might
| be biased, but ready-made tools can be helpful.
|
| The issue is if you are using tools without understanding
| the underlying architecture or design of your platform.
|
| If you're just a script-monkey and only concentrating on
| the what, security automation is going to take your job
| away (and is already in the pipeline in the IR world as we
| speak)
|
| > Sorry for the rant
|
| No worries. You yourself replied to my rant XD
| ahtihn wrote:
| > I don't care that you feel restricted
|
| Yeah well, this is why we don't like security engineers. You
| absolutely should care that the policies you push for are
| making workers feel restricted.
|
| For your job to even exist, engineers must be able to produce
| just remember that.
| alephnerd wrote:
| There is a happy middle ground between keeping users (in
| this case Engineering) happy and an environment secure.
|
| Ideally, Security Ownership should be taken up by the
| Application/Dev team with an open understanding that heads
| roll if you messed up ("ownership"), and a security team
| and platform team exists to help consult and implement
| security and deployment.
|
| I guess they call philosophy "DevSecOps" or "Shift-Left" in
| the Gartner world.
|
| That said, a lot of "security" practices are pure BS and
| security theatre.
| BiteCode_dev wrote:
| Nassim Taleb was right again.
| bitwize wrote:
| It's time to introduce PE licensing for the title of "software
| engineer". Like civil engineers, software engineers should be
| personally, civilly and criminally liable for the systems they
| sign off on. Reserve other titles, likE "software developer", for
| those who work under the engineer and do not assume liability.
|
| Other measures, like data protection laws, will still be
| necessary. But introducing certification and liability like an
| actual profession would be a good start.
|
| This will greatly diminish startup culture. Fine. I'd rather have
| a few responsible companies out there playing by the rules than a
| thousand wildcats for whom rules are an inconvenience.
| curioussavage wrote:
| I've had the same thoughts and I'm glad I'm not alone. We like
| the money and prestige from wearing these titles but not the
| responsibility that others who call themselves engineers
| shoulder.
|
| I can protest to my boss about security issues and data privacy
| or even try refusing to proceed with a project or release but
| that's a minor inconvenience to him. Easy enough to fire me and
| get somebody else who doesn't care.
|
| We complain that we are powerless but investors and executives
| aren't going to give us any power willingly. That will have to
| come from legislators and if we want it we'll have to take some
| responsibility too.
| motohagiography wrote:
| it's a profession for negotiating machine based contracts instead
| of legal ones now. like legal services and compliance it creates
| its own demand and demands infinite management. its essentially a
| branch of law.
| ergonaught wrote:
| Author appears broken, as well.
| Veserv wrote:
| Partially correct. Cybersecurity is broken because there are no
| consequences, but cybersecurity is not broken because there is no
| money in it. Large corporations spend literal mountains of money
| on cybersecurity, but cybersecurity is broken, so that money is
| basically wasted. Literally go ask any CISO or cybersecurity
| director at any Fortune 500 company: "How much would it cost to
| hire hackers to compromise our the systems of our company with
| billions of dollars of revenue and take down operations?" Keep
| asking that until they give you a literal monetary number. I have
| never heard a number over 1 M$ by anybody who knows anything.
| None of the big 4 banks, who literally spend hundreds of millions
| to billions of dollars, gave a number over 100 k$. If they give
| you a number over 1 M$, ask if you can make a open prize at
| Defcon so they can prove it, they will be shaking in their little
| boots.
|
| Cybersecurity technology is, as a rule, useless. And it is also
| worthless since there have been no meaningful consequences to
| date. Large companies pay huge piles of moneys so the CEO and
| Board of Directors can say they spent a lot of money so they,
| personally, have plausible deniability when their systems get
| breached. Then the lack of actual business consequences kicks in
| and everybody is happy after the PR blip passes over. Optics are,
| in fact, more important than security for large companies which
| is why heavy spenders look so broken. It does not need to
| actually work, it just needs to look good to outsiders so they do
| not get a phantom PR hit (it is a phantom from their perspective
| since there are no actual business consequences, there may be
| other consequences but that is outside of their evaluation
| criteria).
|
| The only actually meaningful and cost-effective "preventative"
| measure is doing the bare minimum of standard IT practices (i.e.
| keep things up to date, keep backups, etc.) to prevent amateurs
| from crippling your systems. Against professionals, no commercial
| IT solution works, so you are better off just purchasing
| cybersecurity insurance. You should only waste money on the
| standard cybersecurity garbage if you need to slough off
| liability. In every other way it is just plain useless; it
| provides no meaningful increase in security and costs a ton to
| boot. This is why small companies look so broken, nothing works
| and they do not need the optics, so there is little point in
| spending money on things that do not work.
|
| With the recent wave of mature, professional cybercriminals we
| are finally starting to see a little bit of a shift. The 18 year
| old hackers who thought 100 $ was a lot of money are now in their
| 30s running professional extortion companies. They are starting
| to ask for serious money and the consequences are starting to
| materialize. Unfortunately, we have an entire industry of snake
| oil and the rest of the economy is not ready for the
| consequences. It is already hitting the cybersecurity insurance
| companies who are rapidly going underwater because policies are
| backwards looking. The cyberattack industry is growing like 300%
| per year, so the premiums from 5 years ago, which assumed a
| expected value 243x lower, make no sense today, and the premiums
| today make no sense next year. Incidentally, this is why you
| should purchase as much long-term cybersecurity insurance as you
| can, it is massively underpriced given current trends (e.g.
| Maersk got a real steal with their 1 G$ payout which is probably
| more than the total premiums paid to all cybersecurity insurance
| companies put together over their entire existence at that time).
|
| The problem is not money. It is working solutions. Money helps
| make working solutions as long as it goes to people making
| working solutions. But, so far, optics have been preferred over
| security due to the lack of consequences.
|
| If we want working solutions, then we need systems verified to
| protect against the now commonplace attacks by professional
| attackers at the 10 M$+ range. As a first-order estimate, that is
| a team of 20 full-time for a year. That is the _minimum_ bar. For
| large nationals or multinationals, you probably need to be in the
| 100 M$ to 1G$ range, 60 full-time for 3 years or 600 full-time
| for 3 years. Only then are we reasonably safe against
| sophisticated financially-motivated attackers.
| demondemidi wrote:
| There is no black and white "this will fix it" in cybersecurity.
| It is a continual arms race. Arguing "X will stop cybercrime" is
| so naive it hurts.
| siliconc0w wrote:
| It'd be interesting if you basically made it illegal to both
| process and store user-data. If you want to process a user's
| information you need to go through that user's storage API and
| then you need to persist your data back through that API. Since
| everything is co-located in the cloud I don't think latency would
| be a huge deal. Users would get a choice of storage vendors -
| total visibility into who and what is doing the reading/writing
| and can delete/revoke access at any time.
| tayo42 wrote:
| I think this is the wrong way to think about personal data.
| You're better off just living your life like everything is hacked
| and out there and take precautions to deal with that.
|
| Otherwise you place your destiny in the hands of others. And your
| also expecting a 100% success rate against data being stolen.
| We're only human, eventually someone will screw up no matter how
| much punishment there is.
| iron-s wrote:
| Fixing cybersecurity with laws is the same as fixing drug
| trafficking with laws
| alephnerd wrote:
| Bullshit. Liability and regulation can absolutely help with
| ensuring better practices. The fact that the SEC now requires
| disclosure of active breaches has forced companies overnight to
| begin taking cybersecurity seriously, and there are plenty of
| other liability related changes happening as we speak.
| QuantumG wrote:
| Here ya go https://www.csoonline.com/article/567531/the-biggest-
| data-br...
|
| It takes time.
| cjk2 wrote:
| Nope . It's broken because all policy is normalised into box
| ticking and insurance.
| wepple wrote:
| > You do what the payment card industry has been doing for
| decades
|
| What? Mandate a bunch of paper-thin worthless rules that tie up
| security & engineering teams and don't actually add measurable
| security improvements?
|
| I'd be very interested in seeing the data that shows PCI-DSS has
| had any impact. I spent a previous life breaking into PCI
| compliant companies, and it didn't offer the tiniest speed bump.
|
| This is a horrible recommendation.
| nyrikki wrote:
| While it feels dirty, I blame companies more than PCI.
|
| Just like the failures of traditional Enterprise Architecture,
| the Prescriptivist, universal top down method eats lots of
| resources without delivering much value to the company.
|
| While governance and policy are important, most are written to
| CYA more than to solve the initial problems.
|
| As an example, as a consultant I once found a serious
| vulnerability with a serialization library on a very large
| companies stack.
|
| Because it wasn't web facing, it couldn't be prioritized as
| policy didn't allow increasing its weight.
|
| They were compromised a few quarters later... but it was their
| policy that they wrote that caused that.
|
| Almost universally, restrictions and barriers have almost
| nothing to do with PCI requirements, but due to how the company
| implemented it.
|
| A lot of that is due to the consulting and certification
| industrial complex and the focus on productized offerings. Just
| as chatGPT is intentionally verbose because it appears more
| authoritative, companies adopt governance that is way more
| detailed than appropriate.
|
| Obviously any compliance will have some detailed and firm
| requirements, but the core concepts are replaced with blindly
| implemented checklists when values and principles are what
| should drive most decisions in specific systems.
|
| The requirements to be PCI compliant often follow that concept
| far more closely than what companies actually adopt.
|
| PCI DSS isn't that far off from generic best practices,
| optimization for superficial Self-assessment questionnaires and
| audits that we know don't catch much over those best practices
| is the problem.
| xg15 wrote:
| > _You see, cybersecurity is broken because of the lack of
| consequences. It 's really that simple. When literally nothing
| happens when some stupid service gets popped and loses your data
| they had no business collecting in the first place, this kind of
| thing will happen over and over and over again. Why the fuck do
| you need my home address just so I can copy and paste some GIFs?
| Because you want to sell this data to data brokers, and you know
| there will be absolutely no negative consequences if you
| mishandle this data, fucking over the people who keep your
| business afloat. So, companies big and small fuck things up and
| we need to clean up the mess and face the consequences. Sounds
| about right._
|
| 10 years from now: AI somehow knows every single tiny detail
| about your life and can accurately predict any decision before
| you even made it. How could it have come to this? Clearly, it's
| just the fundamental superiority of AI compared to the human
| intellect. It's just the inevitable march towards the
| singularity. There is nothing we could have done to prevent
| this...
| Animats wrote:
| Back in my aerospace days I worked on an obscure secure operating
| system, which, unfortunately, was built for the PDP-11 just as
| the PDP-11 neared end of life. This was when NSA was getting
| interested in computer security. NSA tried applying the same
| criteria to computer security they applied to safes and filing
| cabinets for classified documents. A red team tried to break in.
| If they succeeded, the vendor got a list of the problems found,
| and one more chance for an evaluation. On the second time around,
| if a break in succeeded, the product was rejected.
|
| Vendors screamed. Loudly. Loudly enough that the evaluation
| process was moved out of NSA and weakened. It was outsourced to
| approved commercial labs, and the vendor could keep trying over
| and over until they passed the test, or wore down the red team.
| Standards were weakened. There were vendor demand that the
| highest security levels (including verification down to the
| hardware level) not even be listed, because they made vendors
| look bad.
|
| A few systems did pass the NSA tests, but they were obscure and
| mostly from minor vendors. Honeywell and Prime managed to get
| systems approved. (It was, for a long time, a joke that the
| Pentagon's MULTICS system had the budgets of all three services,
| isolated well enough that they couldn't see each other's budget,
| but the office of the Secretary of Defense could see all of
| them.)
|
| What really killed this was that in 1980, DoD was the dominant
| buyer of computers, and by 1990, the industry was way beyond
| that.
| alephnerd wrote:
| ^^^ this guy is an absolute legend (and his work was the bane
| of my existence as an Engineer, which made me switch to the
| business side /s).
|
| This the guy who created the Nagles Algorithm for TCP
| optimization.
|
| https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm
| Veserv wrote:
| And still, despite the weakening, hardly anybody passed even
| the watered down requirements. Large vendors like Microsoft
| complained that the bidding process was unfair because they
| were not even allowed to compete just because they could not
| meet the minimum security requirements. So, the requirements
| were reduced until the requirements could meet the the
| abilities of the vendors.
|
| For operating systems in the early 2000s, this constituted a
| Common Criteria EAL4 certification according to the Controlled
| Access Protection Profile (CAPP) [1] which is only appropriate
| for: "an assumed non-hostile and well-managed user community
| requiring protection against threats of inadvertent or casual
| attempts to breach the system security". EAL4 certifications
| have since been viewed as too onerous for vendors so they
| progressively dropped it to 2 stacked EAL2, since clearly 2 *
| EAL2 = EAL4 (I am only half-joking). To where we are now where
| the requirement is only the lowest level of certification,
| EAL1, which does not even demand a security analysis. The
| vendor is only required to Google: Name + Vulnerability (I am
| not joking this time [2][3]) and show that any vulnerabilities
| that showed up were patched.
|
| And people wonder why everything is easily hacked. Should be
| pretty obvious once you see the standards we hold them to.
|
| [1]
| https://www.commoncriteriaportal.org/files/ppfiles/pp_os_ca_...
| Page 9
|
| [2] https://www.niap-ccevs.org/MMO/Product/st_vid11349-vr.pdf
| Page 20 to see the searches used to validate iOS
|
| [3]
| https://download.microsoft.com/download/6/9/1/69101f35-1373-...
| Page 14 to see the searches used to validate Windows
| alephnerd wrote:
| Tbh, Common Critera is basically security theatre. I've went
| thru the process and it's very checkbox driven and not truly
| design driven.
|
| There is a mutual issue of both Procurement being an onerous
| shitshow and vendors being lazy about validating and ensuring
| security.
|
| I have some thoughts about this but that would basically be a
| book (or an angry presentation at RSAC, Black Hat, DefCon,
| and Gartner Federal)
|
| Some of the federal PoCs I've been a part of recentlyish
| (past decade) have returned to the red-teaming methodology
| that OP mentioned, but it's very Agency dependent.
| s4mw1se wrote:
| it doesn't help all governments sponsor and partake in the 0-day
| trade which undermines efforts of their citizens private sector
| blue teams. In addition to paying ethical hackers sometimes 1-2%
| of what they pay 0-day brokers for the same vulnerability.
|
| It's definitely broken, and as long as the same entities
| demanding "improved cybersecurity" from its citizens also
| continue to undermine their efforts nothing will change.
|
| It's to wrapped up in the military industrial complex, no one's
| trying to fix and stop wars when there's money to be made.
| amluto wrote:
| > Why the fuck do you need my home address just so I can copy and
| paste some GIFs? Because you want to sell this data to data
| brokers, and you know there will be absolutely no negative
| consequences if you mishandle this data
|
| One might argue that selling or giving away (or even internally
| abusing) customer data is every bit as bad having it stolen. As
| far as I'm concerned, selling my address _is_ a data breach and
| should be treated as such.
|
| (Obviously, as the article notes, data breaches aren't really
| taken seriously.)
___________________________________________________________________
(page generated 2024-04-06 23:01 UTC)