3 ms·
I see this sentiment a lot ("security is a matter of best practices"), but I'm an outsider, and I've never seen a description of what this entails (at a high le
by obastani 12y ago
I see this sentiment a lot ("security is a matter of best practices"), but I'm an outsider, and I've never seen a description of what this entails (at a high level). What are the kinds of best practices that you think would help solve the problem? Thanks!
- e12e 12y agoThat is a very good question, and one that isn't easy to answer succinctly! Just by asking that question, you are on your way to better security. One key thing to understand is that security is a process -- it cannot be added on. Similar in that way to how "high quality" cannot be added (and high quality is often a prerequisite for security -- bugs (in sub-systems) are almost always bad for system security). Another key is to see security as a trade-off between real threats and risks, and convenience[1]. For example, I don't currently encrypt my email (with gpg, my smtp server speaks SSL/TLS to those that are willing) -- I use webmail from time to time -- which IMNHO cannot mix meaningfully with gpg and/or end-to-end encrypted email. I have a bootstrap issue with both gpg and OTR -- very few of those I communicate with use either. So I cannot use either. This is another aspect, which I've seen little discussed: secure communication is all about the network effect (I'm sure it's been discussed, but I have not seen it discussed much). Facebook is actually a positive point here: Facebook chat supports[2] xmpp, which supports OTR (but not in the browser, messages that are encrypted are unreadable to Facebook, and via the web client). By having chatsecure on my phone, and many friends on FB -- I actually have a few I can communicate securely with, via XMPP+OTR. That google killed/are killing XMPP access to their IM, is devastating with regards to the security of IM going through Hangouts. Another important point, is that security is all about looking at the system, and realizing that the system, like the original MVC -- when it was MVCU: Model-View-Controller-User[3] -- includes people. People, unlike hw/sw tends to forget passwords, type passwords into the wrong input window[4] etc. I remember reading one of the "Rainbow books"[R], I believe it was NSA Orange Book[5], or maybe[6] a long while back, and found it to have a lot of good points on making a secure system. Maybe someone else have some newer recommendations? Again, it's a complex question. You can't be confident you're communicating securely if you can't be confident you're using a secure system. Hence, Snowden, as seen in Citizienfour, tells the journalists to use an air-gapped (off-line) system for encryption and de-decryption. This is good advice, against most "normal" adversaries. But it is really hard to be paranoid "enough". It is easy to back-door a modern device via it's BIOS/boot-code/kernel, to install various key-loggers (in hardware or software) -- and most people don't realize how absurdly easy it is to break into most houses undetected (see: bumpkeys, lockpicks). I've come to the conclusion that one small aspect that needs work is helping people choose and use better passwords/pass-phrases -- as that is often the weakest part of a system. Sometimes that can be mitigated by using hardware tokens to store keys and delegate encryption to. I'm afraid there are no easy answers. [1] Should be a link here to a sign posted outside a secure facility, I think a prison or jail, stating simply: "Security is not a convenience" -- but I couldn't find it on-line. I believe someone used it in a talk on security a good while back... [2] https://www.facebook.com/sitetour/chat.php https://www.facebook.com/sitetour/chat.php [3] https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html https://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html [4] http://bash.org/?244321 http://bash.org/?244321 [R] http://en.wikipedia.org/wiki/Rainbow_Series http://en.wikipedia.org/wiki/Rainbow_Series [5] http://www.fas.org/irp/nsa/rainbow/std001.htm http://www.fas.org/irp/nsa/rainbow/std001.htm [6] http://www.fas.org/irp/nsa/rainbow/tg017.htm http://www.fas.org/irp/nsa/rainbow/tg017.htm