It's not a cop-out. How many people put off or refuse to do day-to-day responsibilities at home, preventative care for themself, maintenance on vehicle, checking on PC backups, and so on? Varies per person but happens a lot. People will also opt out of even an easy to use tool because of a single extra step. Web research shows a web site taking just a few seconds too long to load will cause a huge chunk of business. Such things show that people's very nature is to take on risk rather than put forth effort. This can't be ignored in a security, usability discussion or design attempt. People will only protect themself if it takes *almost zero effort* and will otherwise let themselves be devoured by digital wolves.
Note: Zynga doesn't count because it's just a game that they *want* to play as an *escape from work* and other things. Security in day-to-day apps is something they *have* to do they usually see as *an obstacle* to fun. Totally different. Although, Zynga's psychological tricks might be copied.
The bigger effects, though, are legacy and networking. The legacy effect says the new thing must build on or integrate well with what's already invested in. Lead to all the COBOL, SAP, and Windows out there. Builiding security on something inherently so insecure without vendor participation puts a limit on both security and usability. We see something similar with Facebook's hold on people after they've put so many photos, comments, shares, etc into it that they don't know how to move. Both companies and individuals simply will not let go of a broken-by-design product to get even the most usable, secure-by-design products. This issue is unresolved and it's why I think the better stuff can only take hold for *new* deployments + niche that will give up bad stuff.
The networking effect is illustrated best by Facebook. They start as just a social media site. All kinds of people start using it. Now, people start using it because others are using it. Their API let's all kinds of third parties and services develop that people start using. A whole network and platform of people, apps, and so on. Problem 1: how do you get them adopt something similar if nobody they know is using it? Problem 2: how do you get the 3rd parties to build similar effort into your platform if nobody is using it? Problem 3 (for non-snooping): How can you do anything like this without the billions in ads that paid for Facebook and esp while solving 1 & 2?
So, in summary, human nature has always worked against even the best efforts. There are very usable apps out there right now for private communication, storage, etc. Threema, Silent Circle, SpiderOak, ZixMail/Hushmail, and so on. Apps do almost all the hard things for you inexpensively. Threema is only $1 more than WhatsApp. Pop quiz: how many people buy these over the insecure alternatives? Now you know how much the users care.;)
Total agreement. The good news is that has been going on and with support of security field's best minds. I made a pastebin link with rest of reply below cuz Slashdot comments are a bitch to work with.
"Then make it not necessary to type in a password. Even I don't understand why I should type a password for every mail I send."
They did: you type a password once to unlock the private key and then you just send emails from there on. The password method is used because (a) people rarely buy dedicated, secure hardware, (b) it's easy to implement, (c) people are used to it, (d) the method works on all platforms, and (e) protecting it is easier in a more secure architecture (eg trusted path to isolated component). Security engineers repeatedly come up with password replacements that get almost no adoption. Top labs are *still* researching how to replace passwords while maintaining security.
"No, it's not. It might be technically the best tool, but if it's unusable, then in sum total, it's not. There are many factors that go into these equations, and we techies are sometimes blind to some of them."
That's true except all kinds of people have learned to use GPG. I Google'd how to use GPG, got a nice page listing common actions + commands, and simply typed that into my terminal. The people with GUI's, Thunderbird, etc had it even easier: dialogs for configuration or keyrings + press-button sending of secure mail. That's pretty damned easy to learn and use. It could certainly get better. Yet, I've taught the basics to all kinds of people. The real reason people rarely use it is pure laziness and/or mainstream uses other, insecure things.
Although I largely stand by my post, I agree with your comments too. The users won't buy anything I build that's close to being truly secure. They won't make necessary sacrifices, even spending $1 more (eg Threema vs WhatApp). What you said is true, though: developers and security engineers often ignore the users' perspective when designing the product. The few that pay attention achieve a lot more success in terms of market adoption. The good news is there's more stories and advice on so-called UX (user experience) popping up in places like CodeProject news where developers might see it. I think we need to go further by designing and promoting best practices for usability for common types of apps. Then, people not wanting to think about users can just checklist and refactor their prototypes.
What you think?
Oh no, he's smart: almost every high assurance security offering ever marketed has been ignored by consumers. They *don't give a fuck*. Being the demand side of the equation, they're the reason [1] the suppliers are producing insecure garbage all the time. It's what they buy. Steven Lipner, who managed VAX High Assurance VMM, wrote about the what it taught management here [2]. Summary: users wanted the features more than security and would decide against any product developing features too slow (read: all high security systems). Many users also wanted lower costs (security adds costs) and integration with whatever garbage went mainstream. Intel tried three times [3] to do their part with i432 being a marvel of engineering and Itanium being used in a highly secure, affordable OS [4]. Intel's security-oriented efforts tanked to the tune of billions lost as market favored backward compatibility and price/performance instead.
So, users and market don't give a fuck. Only a niche segment does. Unless subsidized by grants or government contracts, high assurance systems are typically not built at all. All the secure stuff being built is grant-funded academia, defense-funded commercial, and/or high priced, patented I.P. for niche use (eg smartcard, embedded). Those of us left doing custom solutions pre-Snowden had very little business with most doing it on the side of better paying work. Post-Snowden, there's more demand, the demand is once again making insecure tradeoffs, false security abounds, and talent to do high assurance is still mostly nonexistent after market killed it off post-OrangeBook. On top of the millions using ad-driven services and tech that sells them out. Truly don't give a fuck and it ain't changing.
All good points if you're stopping run of the mill hackers or snoops. Some people are worried about Five Eyes, China, Russia, and other High Strength Attackers. Author misses that the only proven approach to surviving them are high assurance security engineering and/or obfuscation + diversity + battle-hardened software. There's no H.A. FOSS for this so gotta do the latter. GPG is specifically mentioned in leaked slides as a pain in the ass for NSA: true going back to Zimmerman's PGP. GPG also runs on many hardware architectures and buying old hardware (esp RISC) is a good way to dodge any subversion programs that are going on. So, the best route to high security email is GPG + FOSS OS + diverse, old hardware behind a guard for interface level protection and preventing them hitting the lowest (weak) layers of the old system. Easy to use, cheap, and pretty? No, but high security setups rarely* were.
This, with contractor developed implementations, is one of the ways the NSA's own black programs protect their information from their opponents. Same is true for Five Eye's. So, it has both stopped them and they rely on similar approaches. That's best endorsement an encryption product can get. That so few people use it has more correlations to NSA SIGINT effectiveness than GPG's.;) So, per INFOSEC history's lessons, we let people develop (and PROVE!) better solutions that don't have GPG's problems. Meanwhile, we use GPG, improve its interface, and make solid workarounds to any issues with it that don't violate security arguments. Only new scheme I've seen with strong security properties is Tinfoil Chat. Everything else usually has a weak TCB allowing bypass or an unproven design/implementation they might covertly beat. I'll stick with what works until situation changes.
*Note: Capability, tagged, and language-based methods can be nearly identical to insecure product in functionality with better, easily-done security. They're the exception, though.
Nick P,
Security Engineer/Researcher (high assurance focus)
PL/I is what many mainframe applications were written in. MULTIC's was written in a similar language because it prevented errors you see in others. IBM's mainframe OS IIRC was written in a runtime-less version called PL/S. They considered it a secret weapon for a combination of productivity, performance, safety, and safety/speed tradeoffs. There are two papers you can find with Google on it. Interesting part is how you can put identifiers in each function to control how compiler will transform it to machine code. That both allows and documents tradeoffs you make on a per module/function basis. Mainframes set the gold standard in reliability with often 30+ year uptimes so I think it's unwise to laugh at their design and implementation choices. Unlike my UNIX/Windows boxes, those PL/S and PL/I apps virtually never fail. Language design probably contributes a little bit. -Nick P
Certain industry members are already doing it so you're wrong in the micro sense. In the macro sense, I totally agree and I've stayed out of the market specifically because of their power over U.S. citizens. I already know the parallel construction strategy they'd use against me. Good news is some people overseas have a chance of building something and I can at least teach people how to do it right in my various essays. More people learn from it every year although single digits lol.
A familiar name.:) You talking about a message that the best opportunity is to ally with NSA to subvert things because otherwise won't get hired? I agree. Further, I still promote my mantra of judging what a person produces rather than the person themself. Anyone can be had in security of all types. Trust but verify: more than one person working on stuff with controls and review activities to ensure stuff is being done right. No guarantees but much better than guilt by association. Besides, most malicious insiders I've seen looked great on the surface.
-Nick P
I agree on the public competition. The good news is that we learned much of what we need back in Orange Book days when everyone was sharing stuff publicly. Dozens of papers on high assurance security. Academia and commercial sector has only added to this. The thing that trips people up is it's scattered everywhere. That's why I've been making integrated frameworks like I referenced in the link. Contrary to your belief, the NSA *does* tell us how to build something secure although they skirt on the requirements a bit. Just apply Common Criteria EAL6-7 to a system like SAFE or CHERI at every layer and integration point. Add EMSEC and physical security. Done. It will take time and cost you plenty, but it's doable. They'll even certify it because they can then export restrict it and kill your ROI.;) I'd have it evaluated privately by top security engineers against their criteria and NSA's. Then, they post a signed message on their web site with the evaluation, optionally password protected. (Or email it.) Such methods were how I did things in private sector in the past.
Read the link I posted in my original post showing what a high assurance secure design takes. Now, look at all the designs you referenced and typical commercial development practices. You should see a *HUGE* gap between the two. For starters, the design must be as such that every state the system might be in is known, every error state is shown to fail safe, only the strongest configurations are used, an inspection happens for every known weakness, safe subsets are used for the coding, those are extensively tested, covert channel analysis, minimal TCB, and so on. Such methods would've prevented Heartbleed and AES timing attacks among others. Yet, companies time and time again do whatever maximizes profit. And then the software gets smashed.
Security against High Strength Attackers often takes at least 30% of the project budget. It also takes many compromises on features and hurts time to market. On the other hand, there's some companies doing at least medium assurance with good results. Example: Matasano's review of Secure64 DNS on SourceT OS says they couldn't begin to figure out how to do a code injection on such a design. Sentinel's HYDRA firewall got similar remarks from NSA evaluators a while back. Two high assurance designs still available are Boeing SNS and GHS INTEGRITY-178B. All are in use by defense contractors to protect high value assets. Such solutions aren't cheap or pretty, though. So most companies buy cheap, full-featured alternatives that are developed with commercial best practices (read: hackerbait). That's why *those* products keep getting hacked.
What does all that nonsense have to do with a VPN? Do you even know what they do? A VPN protects the secrecy, integrity and authenticity of communications between two points. This has been done to high assurance. Repeatedly. NSA still relies* on some of these to protect their communications from foreign nation-states. You can leverage strong end-to-end VPN tech to protect all kinds of other apps from eavesdropping if the parties on each side trust each other. The tech can also be leveraged in anonymity schemes that encrypt links or circuits. It's a building block along side other building blocks. I've gotten a ton of mileage out of mine in the past with zero evidence of compromise despite clever efforts.
Learn how it works, learn how it can go wrong, learn what it looks like done right, and start doing it right avoiding anything that's known to be wrong. It's not rocket science: just a very simple concept quite alien to most COTS and FOSS products. An exception is Micro-SINA VPN and Turaya VPN. They at least kept the TCB tiny and modular.
*They also largely stopped buying high assurance products minus a few for select critical sites and mostly killed off that market. A combination of that, poor organizational security practices, and the post-9/11 push to knock out obstacles to info sharing have led to most of their security breaches. It doesn't say anything about the quality of the good stuff.
One of the earliest secure (at the time) systems was a VPN: the BLACKER VPN. NSA couldn't hack it. There were numerous products with this capability under the banner "crypto seal" that were evaluated in 90's, including GEMSOS. The NSA's Type 1 HAIPE is a modified IPsec that passed their rigorous Type 1 development and evaluation process. Navy researchers also finished an EAL7 IPsec VPN that got canned just before certification because there was "no market for it" per management. Further, there's been many link encryptors and mail guards (which support crypto) that made it to the top level.
The result is that you *can* build secure VPN's. Private companies, NSA, and academics have all done it. You must clearly understand where the risks are, mitigate them in the design, and do the software lifecycle with a EAL6-7 type process. A rare few companies are using high assurance methods, but almost zero FOSS projects are. They use insecure languages, libraries, OS's, firmware, and hardware. Guaranteed to be hacked. Want to know what it takes to build something secure? I included some of the requirements in the conversation below:
I noticed people fighting over FOSS vs proprietary philosophies a long time ago. They acted like these two are all there is. I posted this essay arguing there's a large variety of models with some combining proprietary and open source:
https://www.schneier.com/blog/...
One of the first mainframes, Burroughs B5000, was sold quite profitably with the customers getting the source code and able to extend it however they wanted. They could also submit changes back to Burroughs to include for everyone. The continued and significant funding ensured the system kept getting improved. The openness has many of the benefits of FOSS. They later closed the source like QNX did, but I could see a contract where the customers get the current and future source indefinitely so long as they pay.
So, it's nice to see a new venture that challenges the false dichotomy of proprietary, FOSS, or nothing else. There's lots of mixes. I look forward to seeing how this scheme works out.
China and Russia are certainly involved in cyber espionage, especially for state secrets or intellectual property. I was simply pointing out that the US is the main country talking about how we have to be worried about cyberwar and is also the main country using a vast arsenal of cyberweapons against most developed nations, including allies & neutrals.
This is both a nice irony and a potential explanation for why we know neither specifics of cyber weapons nor how to stop good ones.
Thanks for that!:) The funny thing is that I put trailing slashes in there because that's how the Slashdot advice said to do it: "(markuptag here) will auto-link a URL." It had a trailing slash in the URL. Those darned documentation writers...
"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website)
The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers.
The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED.
Nick P,
Security Engineer,
schneier.com contributer
1. http://www.eros-os.org/~shap/NT-EAL4.html/
2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/
(Note: I originally posted this comment in the wrong spot. Reposting it here. Rarely use this comment system so my bad.)
"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website)
The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers.
The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED.
Nick P,
Security Engineer,
schneier.com contributer
1. http://www.eros-os.org/~shap/NT-EAL4.html/
2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/
Use Foxit and keep javascript off by default. (Or don't even install the JavaScript plugin.) It's lightweight, fast and has fewer quality issues than adobe. Additionally, considering PDF is inherently an unsafe format, I'd say adding a sandbox like Sandboxie can help you.
More technical people here might try porting a good PDF reader's key parsing and JS functionality to NaCl sandboxing system. Put each component in separate partitions with inner sandbox protection at a minimum. That lets us use the fast and legacy native code, but have plenty isolation almost for free.
Nick P
Security Engineer
usually on schneier.com
Re: "run it on a RAM sled with between 128 GB and 512 GB of memory"
Google gave me absolutely nothing on RAM sleds. I've used RAM disks for years and even know of hard disk's that are flash-backed RAM for performance. 128GB-512GB of RAM? If I needed that in a server, SGI (rip) and others have it. I doubt that's what they mean, though, as it's expensive custom stuff.
So, what is a RAM sled? And where are they bought or how are they set up? Thanks ahead of time for any answers.
Slashdot Mirror
It's not a cop-out. How many people put off or refuse to do day-to-day responsibilities at home, preventative care for themself, maintenance on vehicle, checking on PC backups, and so on? Varies per person but happens a lot. People will also opt out of even an easy to use tool because of a single extra step. Web research shows a web site taking just a few seconds too long to load will cause a huge chunk of business. Such things show that people's very nature is to take on risk rather than put forth effort. This can't be ignored in a security, usability discussion or design attempt. People will only protect themself if it takes *almost zero effort* and will otherwise let themselves be devoured by digital wolves.
Note: Zynga doesn't count because it's just a game that they *want* to play as an *escape from work* and other things. Security in day-to-day apps is something they *have* to do they usually see as *an obstacle* to fun. Totally different. Although, Zynga's psychological tricks might be copied.
The bigger effects, though, are legacy and networking. The legacy effect says the new thing must build on or integrate well with what's already invested in. Lead to all the COBOL, SAP, and Windows out there. Builiding security on something inherently so insecure without vendor participation puts a limit on both security and usability. We see something similar with Facebook's hold on people after they've put so many photos, comments, shares, etc into it that they don't know how to move. Both companies and individuals simply will not let go of a broken-by-design product to get even the most usable, secure-by-design products. This issue is unresolved and it's why I think the better stuff can only take hold for *new* deployments + niche that will give up bad stuff.
The networking effect is illustrated best by Facebook. They start as just a social media site. All kinds of people start using it. Now, people start using it because others are using it. Their API let's all kinds of third parties and services develop that people start using. A whole network and platform of people, apps, and so on. Problem 1: how do you get them adopt something similar if nobody they know is using it? Problem 2: how do you get the 3rd parties to build similar effort into your platform if nobody is using it? Problem 3 (for non-snooping): How can you do anything like this without the billions in ads that paid for Facebook and esp while solving 1 & 2?
So, in summary, human nature has always worked against even the best efforts. There are very usable apps out there right now for private communication, storage, etc. Threema, Silent Circle, SpiderOak, ZixMail/Hushmail, and so on. Apps do almost all the hard things for you inexpensively. Threema is only $1 more than WhatsApp. Pop quiz: how many people buy these over the insecure alternatives? Now you know how much the users care. ;)
Nick P
Total agreement. The good news is that has been going on and with support of security field's best minds. I made a pastebin link with rest of reply below cuz Slashdot comments are a bitch to work with.
[1] http://pastebin.com/5cH6jd4R
"Then make it not necessary to type in a password. Even I don't understand why I should type a password for every mail I send."
They did: you type a password once to unlock the private key and then you just send emails from there on. The password method is used because (a) people rarely buy dedicated, secure hardware, (b) it's easy to implement, (c) people are used to it, (d) the method works on all platforms, and (e) protecting it is easier in a more secure architecture (eg trusted path to isolated component). Security engineers repeatedly come up with password replacements that get almost no adoption. Top labs are *still* researching how to replace passwords while maintaining security.
"No, it's not. It might be technically the best tool, but if it's unusable, then in sum total, it's not. There are many factors that go into these equations, and we techies are sometimes blind to some of them."
That's true except all kinds of people have learned to use GPG. I Google'd how to use GPG, got a nice page listing common actions + commands, and simply typed that into my terminal. The people with GUI's, Thunderbird, etc had it even easier: dialogs for configuration or keyrings + press-button sending of secure mail. That's pretty damned easy to learn and use. It could certainly get better. Yet, I've taught the basics to all kinds of people. The real reason people rarely use it is pure laziness and/or mainstream uses other, insecure things.
Although I largely stand by my post, I agree with your comments too. The users won't buy anything I build that's close to being truly secure. They won't make necessary sacrifices, even spending $1 more (eg Threema vs WhatApp). What you said is true, though: developers and security engineers often ignore the users' perspective when designing the product. The few that pay attention achieve a lot more success in terms of market adoption. The good news is there's more stories and advice on so-called UX (user experience) popping up in places like CodeProject news where developers might see it. I think we need to go further by designing and promoting best practices for usability for common types of apps. Then, people not wanting to think about users can just checklist and refactor their prototypes. What you think?
Oh no, he's smart: almost every high assurance security offering ever marketed has been ignored by consumers. They *don't give a fuck*. Being the demand side of the equation, they're the reason [1] the suppliers are producing insecure garbage all the time. It's what they buy. Steven Lipner, who managed VAX High Assurance VMM, wrote about the what it taught management here [2]. Summary: users wanted the features more than security and would decide against any product developing features too slow (read: all high security systems). Many users also wanted lower costs (security adds costs) and integration with whatever garbage went mainstream. Intel tried three times [3] to do their part with i432 being a marvel of engineering and Itanium being used in a highly secure, affordable OS [4]. Intel's security-oriented efforts tanked to the tune of billions lost as market favored backward compatibility and price/performance instead.
So, users and market don't give a fuck. Only a niche segment does. Unless subsidized by grants or government contracts, high assurance systems are typically not built at all. All the secure stuff being built is grant-funded academia, defense-funded commercial, and/or high priced, patented I.P. for niche use (eg smartcard, embedded). Those of us left doing custom solutions pre-Snowden had very little business with most doing it on the side of better paying work. Post-Snowden, there's more demand, the demand is once again making insecure tradeoffs, false security abounds, and talent to do high assurance is still mostly nonexistent after market killed it off post-OrangeBook. On top of the millions using ad-driven services and tech that sells them out. Truly don't give a fuck and it ain't changing.
[1] https://www.schneier.com/blog/...
[2] http://blogs.microsoft.com/cyb...
[3] https://www.schneier.com/blog/...
[4] http://www.secure64.com/secure...
Nick P, Security Engineer/Researcher (High assurance focus)
All good points if you're stopping run of the mill hackers or snoops. Some people are worried about Five Eyes, China, Russia, and other High Strength Attackers. Author misses that the only proven approach to surviving them are high assurance security engineering and/or obfuscation + diversity + battle-hardened software. There's no H.A. FOSS for this so gotta do the latter. GPG is specifically mentioned in leaked slides as a pain in the ass for NSA: true going back to Zimmerman's PGP. GPG also runs on many hardware architectures and buying old hardware (esp RISC) is a good way to dodge any subversion programs that are going on. So, the best route to high security email is GPG + FOSS OS + diverse, old hardware behind a guard for interface level protection and preventing them hitting the lowest (weak) layers of the old system. Easy to use, cheap, and pretty? No, but high security setups rarely* were.
This, with contractor developed implementations, is one of the ways the NSA's own black programs protect their information from their opponents. Same is true for Five Eye's. So, it has both stopped them and they rely on similar approaches. That's best endorsement an encryption product can get. That so few people use it has more correlations to NSA SIGINT effectiveness than GPG's. ;) So, per INFOSEC history's lessons, we let people develop (and PROVE!) better solutions that don't have GPG's problems. Meanwhile, we use GPG, improve its interface, and make solid workarounds to any issues with it that don't violate security arguments. Only new scheme I've seen with strong security properties is Tinfoil Chat. Everything else usually has a weak TCB allowing bypass or an unproven design/implementation they might covertly beat. I'll stick with what works until situation changes.
*Note: Capability, tagged, and language-based methods can be nearly identical to insecure product in functionality with better, easily-done security. They're the exception, though.
Nick P, Security Engineer/Researcher (high assurance focus)
PL/I is what many mainframe applications were written in. MULTIC's was written in a similar language because it prevented errors you see in others. IBM's mainframe OS IIRC was written in a runtime-less version called PL/S. They considered it a secret weapon for a combination of productivity, performance, safety, and safety/speed tradeoffs. There are two papers you can find with Google on it. Interesting part is how you can put identifiers in each function to control how compiler will transform it to machine code. That both allows and documents tradeoffs you make on a per module/function basis. Mainframes set the gold standard in reliability with often 30+ year uptimes so I think it's unwise to laugh at their design and implementation choices. Unlike my UNIX/Windows boxes, those PL/S and PL/I apps virtually never fail. Language design probably contributes a little bit. -Nick P
http://www.throwww.com/a/7bn
Also has implications for society. Many of his predictions have been solid for years after writing the essay.
- Nick P
Certain industry members are already doing it so you're wrong in the micro sense. In the macro sense, I totally agree and I've stayed out of the market specifically because of their power over U.S. citizens. I already know the parallel construction strategy they'd use against me. Good news is some people overseas have a chance of building something and I can at least teach people how to do it right in my various essays. More people learn from it every year although single digits lol.
A familiar name. :) You talking about a message that the best opportunity is to ally with NSA to subvert things because otherwise won't get hired? I agree. Further, I still promote my mantra of judging what a person produces rather than the person themself. Anyone can be had in security of all types. Trust but verify: more than one person working on stuff with controls and review activities to ensure stuff is being done right. No guarantees but much better than guilt by association. Besides, most malicious insiders I've seen looked great on the surface.
-Nick P
I agree on the public competition. The good news is that we learned much of what we need back in Orange Book days when everyone was sharing stuff publicly. Dozens of papers on high assurance security. Academia and commercial sector has only added to this. The thing that trips people up is it's scattered everywhere. That's why I've been making integrated frameworks like I referenced in the link. Contrary to your belief, the NSA *does* tell us how to build something secure although they skirt on the requirements a bit. Just apply Common Criteria EAL6-7 to a system like SAFE or CHERI at every layer and integration point. Add EMSEC and physical security. Done. It will take time and cost you plenty, but it's doable. They'll even certify it because they can then export restrict it and kill your ROI. ;) I'd have it evaluated privately by top security engineers against their criteria and NSA's. Then, they post a signed message on their web site with the evaluation, optionally password protected. (Or email it.) Such methods were how I did things in private sector in the past.
Read the link I posted in my original post showing what a high assurance secure design takes. Now, look at all the designs you referenced and typical commercial development practices. You should see a *HUGE* gap between the two. For starters, the design must be as such that every state the system might be in is known, every error state is shown to fail safe, only the strongest configurations are used, an inspection happens for every known weakness, safe subsets are used for the coding, those are extensively tested, covert channel analysis, minimal TCB, and so on. Such methods would've prevented Heartbleed and AES timing attacks among others. Yet, companies time and time again do whatever maximizes profit. And then the software gets smashed.
Security against High Strength Attackers often takes at least 30% of the project budget. It also takes many compromises on features and hurts time to market. On the other hand, there's some companies doing at least medium assurance with good results. Example: Matasano's review of Secure64 DNS on SourceT OS says they couldn't begin to figure out how to do a code injection on such a design. Sentinel's HYDRA firewall got similar remarks from NSA evaluators a while back. Two high assurance designs still available are Boeing SNS and GHS INTEGRITY-178B. All are in use by defense contractors to protect high value assets. Such solutions aren't cheap or pretty, though. So most companies buy cheap, full-featured alternatives that are developed with commercial best practices (read: hackerbait). That's why *those* products keep getting hacked.
What does all that nonsense have to do with a VPN? Do you even know what they do? A VPN protects the secrecy, integrity and authenticity of communications between two points. This has been done to high assurance. Repeatedly. NSA still relies* on some of these to protect their communications from foreign nation-states. You can leverage strong end-to-end VPN tech to protect all kinds of other apps from eavesdropping if the parties on each side trust each other. The tech can also be leveraged in anonymity schemes that encrypt links or circuits. It's a building block along side other building blocks. I've gotten a ton of mileage out of mine in the past with zero evidence of compromise despite clever efforts.
Learn how it works, learn how it can go wrong, learn what it looks like done right, and start doing it right avoiding anything that's known to be wrong. It's not rocket science: just a very simple concept quite alien to most COTS and FOSS products. An exception is Micro-SINA VPN and Turaya VPN. They at least kept the TCB tiny and modular.
*They also largely stopped buying high assurance products minus a few for select critical sites and mostly killed off that market. A combination of that, poor organizational security practices, and the post-9/11 push to knock out obstacles to info sharing have led to most of their security breaches. It doesn't say anything about the quality of the good stuff.
http://www.schneier.com/blog/a...
Examples of better approaches and some exemplar secure products:
https://www.schneier.com/blog/...
I noticed people fighting over FOSS vs proprietary philosophies a long time ago. They acted like these two are all there is. I posted this essay arguing there's a large variety of models with some combining proprietary and open source: https://www.schneier.com/blog/... One of the first mainframes, Burroughs B5000, was sold quite profitably with the customers getting the source code and able to extend it however they wanted. They could also submit changes back to Burroughs to include for everyone. The continued and significant funding ensured the system kept getting improved. The openness has many of the benefits of FOSS. They later closed the source like QNX did, but I could see a contract where the customers get the current and future source indefinitely so long as they pay. So, it's nice to see a new venture that challenges the false dichotomy of proprietary, FOSS, or nothing else. There's lots of mixes. I look forward to seeing how this scheme works out.
I've done an analysis based on what's in their paper and posted it to Schneier's blog. Link below.
https://www.schneier.com/blog/...
Spoiler: it's not trustworthy but it's good work in progress.
Nick P
Security Engineer
(High assurance security focus)
I posted my rebuttal to and analysis of this on Bruce Schneier's blog. Link below. https://www.schneier.com/blog/...
China and Russia are certainly involved in cyber espionage, especially for state secrets or intellectual property. I was simply pointing out that the US is the main country talking about how we have to be worried about cyberwar and is also the main country using a vast arsenal of cyberweapons against most developed nations, including allies & neutrals.
This is both a nice irony and a potential explanation for why we know neither specifics of cyber weapons nor how to stop good ones.
Thanks for that! :) The funny thing is that I put trailing slashes in there because that's how the Slashdot advice said to do it: "(markuptag here) will auto-link a URL." It had a trailing slash in the URL. Those darned documentation writers...
"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website) The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers. The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED. Nick P, Security Engineer, schneier.com contributer 1. http://www.eros-os.org/~shap/NT-EAL4.html/ 2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/ (Note: I originally posted this comment in the wrong spot. Reposting it here. Rarely use this comment system so my bad.)
"The FedRAMP security assessment process defines a set of controls for low and moderate impact level systems based on NIST SP 800-53 controls." (FedRAMP Website) The key words here are "for LOW AND MODERATE impact level systems." Low and medium robustness are what the government usually accepts. All kinds of stuff that was routinely compromised fits that profile too. The Shapiro [1] paper on the Window's EAL4 evaluation illustrated why it actually meant "certified insecure" and sadly still applies to this one. At least the NIST standard has plenty of useful controls to keep out the riff raff attackers. The EAL7 or Orange Book A1 certification are very rigorous security standards. So few products reached that level that I could fit many of their names in a single tweet (97 characters actually). Cygnacom has a nice breakdown [2] of the assurance levels and extra work that must be done to verify the entire lifecycle to reach something resembling secure. Such solutions look... nothing like Azure. And Azure was neither built on such standards nor evaluated to one. It's not secure. QED. Nick P, Security Engineer, schneier.com contributer 1. http://www.eros-os.org/~shap/NT-EAL4.html/ 2. http://www.cygnacom.com/labs/cc_assurance_index/CCinHTML/PART3/PART36.HTM/
Use Foxit and keep javascript off by default. (Or don't even install the JavaScript plugin.) It's lightweight, fast and has fewer quality issues than adobe. Additionally, considering PDF is inherently an unsafe format, I'd say adding a sandbox like Sandboxie can help you. More technical people here might try porting a good PDF reader's key parsing and JS functionality to NaCl sandboxing system. Put each component in separate partitions with inner sandbox protection at a minimum. That lets us use the fast and legacy native code, but have plenty isolation almost for free. Nick P Security Engineer usually on schneier.com
Re: "run it on a RAM sled with between 128 GB and 512 GB of memory" Google gave me absolutely nothing on RAM sleds. I've used RAM disks for years and even know of hard disk's that are flash-backed RAM for performance. 128GB-512GB of RAM? If I needed that in a server, SGI (rip) and others have it. I doubt that's what they mean, though, as it's expensive custom stuff. So, what is a RAM sled? And where are they bought or how are they set up? Thanks ahead of time for any answers.