4 ms·

I wouldn't be as alarmed at the NSA's data collection revealed by Snowden if I felt they took their job of defending and protecting US systems with as much zeal

I wouldn't be as alarmed at the NSA's data collection revealed by Snowden if I felt they took their job of defending and protecting US systems with as much zeal. Of course, as the government's own reports show mass surveillance doesn't prevent terrorism, and we are also seeing how poorly citizen data is being protected. This feels very familiar. Instead of seeing a malicious organization, I'm just realizing its incompetent. Forget about Pokemon Go asking for too many permissions, your data is already lost.

nickpsecurity 10y ago
"I wouldn't be as alarmed at the NSA's data collection revealed by Snowden if I felt they took their job of defending and protecting US systems with as much zeal." I thought that at one point but DOD tried and nobody wanted the stuff. COTS, low-cost, and high-speed above all else even for critical stuff. Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. So, I blame the demand side instead of NSA. If market gave a shit, NSA would be working their butts off trying to get anything done in a memory-safe, type-safe, CPU-on-up system. But no... Least we're going to see another effort with the Dover to integrate RISC-V with SAFE architecture's PUMP. Both RISC-V and SAFE were U.S. government funded IIRC. Years of papers on both with no uptake in industry or FOSS for even SAFE's basic techniques until Dover. Far as NSA, at least they still fund Rockwell-Collins' SHADE and Galois Inc's awesome work. CRYPTOL language & toolkit got open-sourced by Galois. Nobody uses it. Seeing a pattern?
- ams6110 10y ago
  Private sector will always take the lowest cost option. The market will not give a shit until they start losing real money (edit: or going to jail).
  - nickpsecurity 10y ago
    Not true. Private sector blows money on bullshit all the time. That's that lucrative, enterprise market you hear about. They'll sometimes spend extra for quality or availability. Stratus Computers and HP NonStop come to mind. Orreck vacuums haha. They just usually won't do it for security. So, you have to sell high-security as part of some other product with benefits they want that justifies the expense. Security appliances were my obvious choice. Sentinel HYRDA, Secure64 DNS, Sirrix TrustedDesktop, & Samsung KNOX are all examples where they try to sell something useful to businesses with extra assurance embedded in there. I also thought a database or ERP package might pull it off. Subsidize the TCB development at least since enterprises expect the exhorbitant licensing. Shit, make it run PostgresSQL underneath with your "database" just being the front-end on a high-security appliance. ;) Funny enough, I used to design and build stuff like that via Seaview & LDV architectures. https://www.acsa-admin.org/secshelf/book001/19.pdf https://www.acsa-admin.org/secshelf/book001/19.pdf
- rdtsc 10y ago
  > Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. That is the truth. But there is a chicken and egg a bit there as well. Common Criteria certification (say EAL4) is not cheap and takes years to achieve. RedHat even opted to do it in Germany by exploiting some international mutual agreement thing. RHEL 7 was out 3 or so years ago and it is still "in evaluation". Who has time for that? https://www.redhat.com/en/technologies/industries/government/standards https://www.redhat.com/en/technologies/industries/government... So I think the requirements and boilerplate needed is too much and too many hoops to jump through. A lot are not technical I feel but rather bureaucratic. I call it paper security -- security that exists only as rubber stamps or checkmarks in some checklist, which might not actually improve anything in reality. A lot of it is downright dangerous -- such as mandating installing an antivirus on a Linux server, which installs a kernel driver, which has a buffer overflow and so on, cue full on kernel level remote exploits ... as a result of a "security requirement".
  - pjc50 10y ago
    Indeed. The "certification" approach really doesn't work for infosec, because it's too much of a moving target.
  - nickpsecurity 10y ago
    "Common Criteria certification (say EAL4) is not cheap and takes years to achieve." Oh yeah. The original criteria got watered down to point that it's mostly expensive paperwork and takes years to achieve. The only ones that are even meaningful are EAL5-7. That's when the assurance activities that benefit security kick in plus you get pentesting of source. Contrary to pjc, I think certification is meaningful if it's a continuous or regular thing against meaningful criteria. The EAL's are meaningful given each requirement has proven to improve security in the past. Protection profiles often have sensible requirements mixed with BS. So, process needs to be subsetted and in a way that focuses on active evaluation rather than just paperwork with sensible requirements and only higher EAL's. I wrote on revamping the evaluation process here: https://www.schneier.com/blog/archives/2014/04/friday_squid_bl_419.html#c5457853 https://www.schneier.com/blog/archives/2014/04/friday_squid_... Far as specifics, the original systems secured to A1-class are still mostly secure today. I could shoot holes in them with what we've learned. Yet, the techniques they used left them in really good shape after all this time and still easier to apply modern stuff to than modern software. Imagine that. It's as if the certification criteria on design & assurance side were fundamental principles that geniuses figured out through many military & academic experiments that still work better than what most developers guess at or throw together. ;) Examples: http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec9-10-security-kernel.pdf http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec9-1... Note: Started with SCOMP and GEMSOS. SCOMP had minimal TCB, IOMMU, totally compartmentalized OS, trusted path, and (as XTS-300) ran UNIX apps in user-mode. http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf Note: I keep citing this, mainly layered design and assurance sections, because it's still more secure at software level than most virtualization. Just look at level of precision, testing, configuration management, safer coding, and so on. They also, per criteria, did a covert channel analysis that would've helped all these clouds with their so-called "side channels." ;) https://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html https://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html Note: A B3-class OS (w/ KeySAFE) from capability-security field. NanoKernel, protected IPC, and regular checkpointing for integrity/availability after a crash. http://www.cyberdefenseagency.com/publications/LOCK-An_Historical_Perspective.pdf http://www.cyberdefenseagency.com/publications/LOCK-An_Histo... Notes: LOCK was interesting as it was a hardware/software system with Type 1 cryptoprocessor & UNIX layer. They invented Type Enforcement for this product then implemented it with capability mechanisms. After it was canceled, "features over assurance," NSA had Utah reimplement that tech in a microkernel. They later added it to Linux as SELinux. LOCK was original model, though, with the UNIX section confirming prior experiments that UNIX calls are inherently insecure to point you can have compatibility or security. It's why separation kernels that came later all just virtualized it as a whole with security-critical apps running right on separation kernel. So, there's four systems that illustrate some design requirements and especially assurance activities. The assurance activities worked. Real flaws were found. A few did great in pentesting and/or the field. Definitely worth copying even if one avoids a CC evaluation: private certification against the criteria with plenty of source code focus instead. Preferably an ongoing process that starts at beginning of the project with third parties auditing feeding right back into development, esp catching flaws.
- forgotpwtomain 10y ago
  > I thought that at one point but DOD tried and nobody wanted the stuff. COTS, low-cost, and high-speed above all else even for critical stuff. Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. > So, I blame the demand side instead of NSA. If market gave a shit, NSA would be working their butts off trying to get anything done in a memory-safe, type-safe, CPU-on-up system. But no... Least we're going to see another effort with the Dover to integrate RISC-V with SAFE architecture's PUMP. Both RISC-V and SAFE were U.S. government funded IIRC. Years of papers on both with no uptake in industry or FOSS for even SAFE's basic techniques until Dover. And instead we get Intel ME. I seriously don't know what to think.. Certainly the later is a sub-system that 99% of users don't care for or want but will still happen to have (and all vulnerabilities associated). If opposite is possible why couldn't they shove a safer system down users-throats after all?
  - nickpsecurity 10y ago
    Intel tried to do the right thing three times: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/intel-itanium-secure-white-paper.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum... Backward compatibility with insecure apps, language, and OS features above all else is what market said. That plus raw speed. The above projects collectively cost Intel over a billion dollars that they didn't make back. i432 died for sure. i960 is in legacy mode with security features turned off or removed. Itanium is in downward spiral. Realistically, they should just modify x86 to support C safety like Cambridge's CHERI or other group's Hardbound are doing. Then, they get compatibility + safety. They're probably just too afraid to make another attempt after loosing a billion to a market that said "F* security or software maintenance." Giving them the insecure crap they demand is actually the ethical choice in capitalism given they'll put you out of business otherwise. Only two that ever made it with a Right Thing approach were Burroughs B5000 and System/38 (aka AS/400). Both turned off hardware security due to user demand (performance over security) but kept OS architecture. Both still sell.
deleted 10y ago
[deleted]

nickpsecurity 10y ago

"I wouldn't be as alarmed at the NSA's data collection revealed by Snowden if I felt they took their job of defending and protecting US systems with as much zeal." I thought that at one point but DOD tried and nobody wanted the stuff. COTS, low-cost, and high-speed above all else even for critical stuff. Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. So, I blame the demand side instead of NSA. If market gave a shit, NSA would be working their butts off trying to get anything done in a memory-safe, type-safe, CPU-on-up system. But no... Least we're going to see another effort with the Dover to integrate RISC-V with SAFE architecture's PUMP. Both RISC-V and SAFE were U.S. government funded IIRC. Years of papers on both with no uptake in industry or FOSS for even SAFE's basic techniques until Dover. Far as NSA, at least they still fund Rockwell-Collins' SHADE and Galois Inc's awesome work. CRYPTOL language & toolkit got open-sourced by Galois. Nobody uses it. Seeing a pattern?

ams6110 10y ago
Private sector will always take the lowest cost option. The market will not give a shit until they start losing real money (edit: or going to jail).
- nickpsecurity 10y ago
  Not true. Private sector blows money on bullshit all the time. That's that lucrative, enterprise market you hear about. They'll sometimes spend extra for quality or availability. Stratus Computers and HP NonStop come to mind. Orreck vacuums haha. They just usually won't do it for security. So, you have to sell high-security as part of some other product with benefits they want that justifies the expense. Security appliances were my obvious choice. Sentinel HYRDA, Secure64 DNS, Sirrix TrustedDesktop, & Samsung KNOX are all examples where they try to sell something useful to businesses with extra assurance embedded in there. I also thought a database or ERP package might pull it off. Subsidize the TCB development at least since enterprises expect the exhorbitant licensing. Shit, make it run PostgresSQL underneath with your "database" just being the front-end on a high-security appliance. ;) Funny enough, I used to design and build stuff like that via Seaview & LDV architectures. https://www.acsa-admin.org/secshelf/book001/19.pdf https://www.acsa-admin.org/secshelf/book001/19.pdf
rdtsc 10y ago
> Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. That is the truth. But there is a chicken and egg a bit there as well. Common Criteria certification (say EAL4) is not cheap and takes years to achieve. RedHat even opted to do it in Germany by exploiting some international mutual agreement thing. RHEL 7 was out 3 or so years ago and it is still "in evaluation". Who has time for that? https://www.redhat.com/en/technologies/industries/government/standards https://www.redhat.com/en/technologies/industries/government... So I think the requirements and boilerplate needed is too much and too many hoops to jump through. A lot are not technical I feel but rather bureaucratic. I call it paper security -- security that exists only as rubber stamps or checkmarks in some checklist, which might not actually improve anything in reality. A lot of it is downright dangerous -- such as mandating installing an antivirus on a Linux server, which installs a kernel driver, which has a buffer overflow and so on, cue full on kernel level remote exploits ... as a result of a "security requirement".
- pjc50 10y ago
  Indeed. The "certification" approach really doesn't work for infosec, because it's too much of a moving target.
- nickpsecurity 10y ago
  "Common Criteria certification (say EAL4) is not cheap and takes years to achieve." Oh yeah. The original criteria got watered down to point that it's mostly expensive paperwork and takes years to achieve. The only ones that are even meaningful are EAL5-7. That's when the assurance activities that benefit security kick in plus you get pentesting of source. Contrary to pjc, I think certification is meaningful if it's a continuous or regular thing against meaningful criteria. The EAL's are meaningful given each requirement has proven to improve security in the past. Protection profiles often have sensible requirements mixed with BS. So, process needs to be subsetted and in a way that focuses on active evaluation rather than just paperwork with sensible requirements and only higher EAL's. I wrote on revamping the evaluation process here: https://www.schneier.com/blog/archives/2014/04/friday_squid_bl_419.html#c5457853 https://www.schneier.com/blog/archives/2014/04/friday_squid_... Far as specifics, the original systems secured to A1-class are still mostly secure today. I could shoot holes in them with what we've learned. Yet, the techniques they used left them in really good shape after all this time and still easier to apply modern stuff to than modern software. Imagine that. It's as if the certification criteria on design & assurance side were fundamental principles that geniuses figured out through many military & academic experiments that still work better than what most developers guess at or throw together. ;) Examples: http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec9-10-security-kernel.pdf http://www.cse.psu.edu/~trj1/cse544-s10/slides/cse544-lec9-1... Note: Started with SCOMP and GEMSOS. SCOMP had minimal TCB, IOMMU, totally compartmentalized OS, trusted path, and (as XTS-300) ran UNIX apps in user-mode. http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf http://www.cse.psu.edu/~trj1/cse543-f06/papers/vax_vmm.pdf Note: I keep citing this, mainly layered design and assurance sections, because it's still more secure at software level than most virtualization. Just look at level of precision, testing, configuration management, safer coding, and so on. They also, per criteria, did a covert channel analysis that would've helped all these clouds with their so-called "side channels." ;) https://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html https://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html Note: A B3-class OS (w/ KeySAFE) from capability-security field. NanoKernel, protected IPC, and regular checkpointing for integrity/availability after a crash. http://www.cyberdefenseagency.com/publications/LOCK-An_Historical_Perspective.pdf http://www.cyberdefenseagency.com/publications/LOCK-An_Histo... Notes: LOCK was interesting as it was a hardware/software system with Type 1 cryptoprocessor & UNIX layer. They invented Type Enforcement for this product then implemented it with capability mechanisms. After it was canceled, "features over assurance," NSA had Utah reimplement that tech in a microkernel. They later added it to Linux as SELinux. LOCK was original model, though, with the UNIX section confirming prior experiments that UNIX calls are inherently insecure to point you can have compatibility or security. It's why separation kernels that came later all just virtualized it as a whole with security-critical apps running right on separation kernel. So, there's four systems that illustrate some design requirements and especially assurance activities. The assurance activities worked. Real flaws were found. A few did great in pentesting and/or the field. Definitely worth copying even if one avoids a CC evaluation: private certification against the criteria with plenty of source code focus instead. Preferably an ongoing process that starts at beginning of the project with third parties auditing feeding right back into development, esp catching flaws.
forgotpwtomain 10y ago
> I thought that at one point but DOD tried and nobody wanted the stuff. COTS, low-cost, and high-speed above all else even for critical stuff. Government kept trying with Common Criteria but almost all vendors and customers went for least secure stuff. NSA tried again with programs like SPOCK that evaluated Sentinel's HYDRA firewall. Defense contractors and DARPA/NSF-funded groups keep making stuff. Basically nobody buys it. > So, I blame the demand side instead of NSA. If market gave a shit, NSA would be working their butts off trying to get anything done in a memory-safe, type-safe, CPU-on-up system. But no... Least we're going to see another effort with the Dover to integrate RISC-V with SAFE architecture's PUMP. Both RISC-V and SAFE were U.S. government funded IIRC. Years of papers on both with no uptake in industry or FOSS for even SAFE's basic techniques until Dover. And instead we get Intel ME. I seriously don't know what to think.. Certainly the later is a sub-system that 99% of users don't care for or want but will still happen to have (and all vulnerabilities associated). If opposite is possible why couldn't they shove a safer system down users-throats after all?
- nickpsecurity 10y ago
  Intel tried to do the right thing three times: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://www-ssl.intel.com/content/dam/www/public/us/en/documents/white-papers/intel-itanium-secure-white-paper.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum... Backward compatibility with insecure apps, language, and OS features above all else is what market said. That plus raw speed. The above projects collectively cost Intel over a billion dollars that they didn't make back. i432 died for sure. i960 is in legacy mode with security features turned off or removed. Itanium is in downward spiral. Realistically, they should just modify x86 to support C safety like Cambridge's CHERI or other group's Hardbound are doing. Then, they get compatibility + safety. They're probably just too afraid to make another attempt after loosing a billion to a market that said "F* security or software maintenance." Giving them the insecure crap they demand is actually the ethical choice in capitalism given they'll put you out of business otherwise. Only two that ever made it with a Right Thing approach were Burroughs B5000 and System/38 (aka AS/400). Both turned off hardware security due to user demand (performance over security) but kept OS architecture. Both still sell.

deleted 10y ago

[deleted]