61–70 of 83 posts
¯\_(ツ)_/¯
I guess now, finally, with the introduction of advertising they have a recognisable form of income. Meaning they might be less likely to profit off data.
Fixing cybersecurity with laws is the same as fixing drug trafficking with laws
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.
Earlier quoted context omitted.
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…
Were you involved in a Common Criteria certification at EAL5 or higher? Anything below EAL5 is just paperwork. As stated above, EAL4 is explicitly only intended to certify a system protects against casual and inadvertent attacks. Checkbox security is largely sufficient to meet that standard. In contrast, it takes actual effort to certify at EAL5 or higher which is why Microsoft and Apple have consistently failed ever…
Efforts are better placed at isolation and hardening of a standard distro.
Earlier quoted context omitted.
> "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 sa…
> 60-70% of severe CVEs are due to memory safety violations...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 Based on your tone and profile you probably aren't interested in better information here, but I'll offer anyway. The vast majority of cybersecurity attacks, and especially the…
You might be surprised :) I come across as emotional online because I'm genuinely invested in things, not because I'm looking to flame, which means I'm actually far more likely than the average person to change my mind if given good arguments, because I'm actually putting my views on the line. I reacted as harshly as I did to the GP mostly because they didn't actually substantiate anything, just made a broad unsubstantiated claim and followed it up with annoying dismissive rhetoric.
On the other hand, this is useful information, and I appreciate you providing something to make this discussion more interesting. Your input certainly does make the tradeoff picture more complex, and I'm certainly a fan of letting each team decide what moves are best for it, and agree that moving to memory safe languages is a long term thing (or a thing for greenfield projects), not an imminant emergency.
Nevertheless, I still think it's more important than to deserve a dismissive "one percent of one percent, we should keep starting new projects in C." For one thing, CVEs might be more important than you let on, since while yes, most breaches are the result of social engineering and such, not bad code per se, we as tech people can only really control what our tech does, do we should focus on breaches that result from technical faults — and wouldn't that usually be CVEs? And if we're looking at CVEs, it seems like we're just looking at things from different perspectives: I'm looking at how to decrease the volume of critical CVEs, and seeing a handy majority of them are caused by memory safety violations that can be fixed with essentially a tooling change, which seems like a big win to me, whereas you're looking at what CVEs end up being exploited, and saying that since it's about 50/50 logic bugs, memory safety doesn't matter. To me, it seems like the ratio of which ones actually get exploited is probably a bit arbitrary, because which ones get used and which don't probably is, so we should focus on just minimizing how many we produce at all, though. Moreover even at 50/50 or so, it seems worthwhile to deal with memory safety, especially since again dealing with it just requires using tools that stop you from creating those bugs, whereas trying to "solve" programmers creating logic bugs is like cold fusion unless you wanna program in Coq (and even then...). As for there being a bunch of other issues memory safe languages can't fix... sure, but why not deal with what we can deal with? It sort of seems like whataboutism.
Earlier quoted context omitted.
> 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.
Remember that for an engineers job to continue to exist there is a need to ensure that the product and systems are secure.
Earlier quoted context omitted.
Were you involved in a Common Criteria certification at EAL5 or higher? Anything below EAL5 is just paperwork. As stated above, EAL4 is explicitly only intended to certify a system protects against casual and inadvertent attacks. Checkbox security is largely sufficient to meet that standard. In contrast, it takes actual effort to certify at EAL5 or higher which is why Microsoft and Apple have consistently failed ever…
And yet afaik no Linux is certified higher than eal4+ and no-one buys them anyway. Efforts are better placed at isolation and hardening of a standard distro.
It is not even like they were asking for the impossible. High security systems designed and verified to protect against state actors were developed and deployed. Just everybody demanded they be allowed to use cheap garbage because they value their budgets over your security.
Incidentally, we also learned from this process that it is basically impossible to retrofit security onto a insecure design. Any system with a insecure design must be thrown out and redesigned from scratch. Numerous attempts over multiple decades and billions of dollars were spent trying to retrofit security onto existing designs and literally every single one of them failed to this day. Attempting to "harden" existing systems to achieve meaningful security is just a fools errand when there are plenty of examples showing you can develop a secure, general purpose base from scratch, and no examples of anybody ever successfully hardening a existing system.
> 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, m…
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 VER…
…
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.
You get what you pay for. Dinosaur companies still can’t stomach paying “nerds” more than their Assistant Regional Managers and it shows. Maybe they’ll be extinct soon.
Earlier quoted context omitted.
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…
Were you involved in a Common Criteria certification at EAL5 or higher? Anything below EAL5 is just paperwork. As stated above, EAL4 is explicitly only intended to certify a system protects against casual and inadvertent attacks. Checkbox security is largely sufficient to meet that standard. In contrast, it takes actual effort to certify at EAL5 or higher which is why Microsoft and Apple have consistently failed ever…
EAL5+ only really kicks in for cryptographic systems (think SmartCards and whatnot) or very critical RTOSes developed by Green Hill.
The RoI on formal verification just isn't there, and imo detracts from a lot more pressing and basic security concerns that can and need to he resolved.
Something like SKPP just doesn't make sense outside of certain niche usecases as you mentioned. Like, you can have a nice formally verified kernel, yet you still need to ingress and egress data. You might retort that you can encrypt, and then I can retort that I can MTIM, .....
The cycle goes on and on and doesn't resolve the core fact - nothing can be 100% secure. And Formal Verification, while a useful tool, cannot solve all security issues.
And being friends with several 8200 and similar program alums, trust me when I say formal verification wouldn't solve some of the attacks or vectors they would use.
David Micken's article in USENIX about realism in security a couple years ago is a good overview [0]
[0] - https://scholar.harvard.edu/files/mickens/files/thisworldofo...
Earlier quoted context omitted.
Were you involved in a Common Criteria certification at EAL5 or higher? Anything below EAL5 is just paperwork. As stated above, EAL4 is explicitly only intended to certify a system protects against casual and inadvertent attacks. Checkbox security is largely sufficient to meet that standard. In contrast, it takes actual effort to certify at EAL5 or higher which is why Microsoft and Apple have consistently failed ever…
And yet afaik no Linux is certified higher than eal4+ and no-one buys them anyway. Efforts are better placed at isolation and hardening of a standard distro.
Amen! I love the work Chainguard is doing to push that philosophy btw.
> no-one buys them anyway
Well, there is a very niche market for this at a very specific federal agency (not the one you think) but IBM Mainframes and Green Hills are more than enough to meet that market need.
What database tech is this referring to? I’m guessing bitcoin, but the phrasing wasn’t clear to me that it meant the payment method rather than an easily exploitable target database everyone was choosing.