{"id":426,"date":"2015-01-28T15:36:35","date_gmt":"2015-01-28T15:36:35","guid":{"rendered":"http:\/\/adriangrigoras.com\/blog\/?p=426"},"modified":"2015-01-28T15:36:35","modified_gmt":"2015-01-28T15:36:35","slug":"13-security-principles","status":"publish","type":"post","link":"https:\/\/adriangrigoras.com\/blog\/13-security-principles\/","title":{"rendered":"13 security principles"},"content":{"rendered":"

1) Secure the weakest link<\/b> — Spaf (that is, highly respected security expert Gene Spafford<\/a> of Purdue University) teaches this principle with a funny story.\u00a0\u00a0 Imagine you are charged with transporting some gold securely from one homeless guy who lives in a park bench (we\u2019ll call him Linux) to another homeless person who lives across town on a steam grate (we\u2019ll call her Android).\u00a0 You hire an armored truck to transport the gold.\u00a0 The name of the transport company is “Applied Crypto, Inc.”\u00a0 Now imagine you\u2019re an attacker who is supposed to steal the gold.\u00a0 Would you attack the Applied Crypto truck, Linux the homeless guy, or Android the homeless woman?\u00a0 Pretty easy experiment, huh?\u00a0 (Hint: the answer is, “Anything but the crypto.”)<\/p>\n

As my co-author John Viega and I wrote back in our 2001 book, Building Secure Software<\/a><\/i>, “Security practitioners often point out that security is a chain; and just as a chain is only as strong as the weakest link, a software security system is only as secure as its weakest component.”\u00a0 Attackers go after the weakest point in a system, and the weakest point is rarely a security feature or function.\u00a0 When it comes to secure design, make sure to consider the weakest link in your system and ensure that it is secure enough.<\/p>\n

2) Defend in depth<\/b> \u2013 Author and consultant Kenneth van Wyk likes to call this one the “belt and suspenders” approach.\u00a0 Redundancy and layering is usually a good thing in security.\u00a0 Don\u2019t count on your firewall to block all malicious traffic; use an intrusion detection system as well.\u00a0\u00a0 If you are designing an application, prevent single points of failure with security redundancies and layers of defense.\u00a0 From Building Secure Software<\/i>, “The idea behind defense in depth is to manage risk with diverse defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense will hopefully prevent a full breach.” It’s a concept preached universally by information security experts, and for good reason: it works.<\/p>\n

3) Fail securely<\/b> — Make sure that any system you design does not fail “open.”\u00a0 My favorite story about this principle comes from the ill-fated Microsoft Bob product of yesteryear.\u00a0 (Bob was the precursor of Clippy the paperclip.)\u00a0 According to legend, if you failed to get your username and password right after three attempts, Bob would helpfully notice and ask whether you wanted to pick a new password to use.\u00a0 Thanks Bob (said the hacker)!\u00a0 Obviously a better default in this situation is to deny access.<\/p>\n

From Building Secure Software<\/i>, “Any sufficiently complex system will have failure modes. Failure is unavoidable and should be planned for. What is avoidable are security problems related to failure. The problem is that when many systems fail in any way, they exhibit insecure behavior.”<\/p>\n

4) Grant least privilege<\/b> — When you do have to grant permission for a user or a process to do something, grant as little permission as possible.\u00a0 Think about your Outlook contacts.\u00a0 If you need someone to have access to your contacts to see some data, grant them reader permission, but do not grant them edit permission.\u00a0 Or if you want a geekier example, try this: most users of a system should not need root permission for their everyday work, so don\u2019t give it to them.\u00a0 Bottom line, avoid unintentional, unwanted, or improper uses of privilege by doling it out in a miserly fashion.<\/p>\n

5) Separate privileges<\/b> — I once saw a system that divided its authentication front end into an impressive number of roles with different degrees of access to the system.\u00a0 The problem was that when a user of any<\/i>role had to perform a back-end database action, the software granted each user de-facto administrator privilege \u00a0temporarily.\u00a0 Not good.\u00a0 Even the lowliest intern could blitzkrieg the database.<\/p>\n

Know that if an attacker is able to finagle one privilege but not a second, she may not be able to launch a successful attack.\u00a0 Keep privilege sets apart.<\/p>\n

6) Economize mechanism<\/b> — Complexity is the enemy of security engineering and the friend of the attacker. It\u2019s just too easy to screw things up in a complicated system, both from a design perspective and from an implementation perspective.\u00a0 The irony: Want to see something complicated?\u00a0 Check out just about any piece of modern enterprise software!<\/p>\n

Do what you can to keep things simple.\u00a0 From Building Secure Software<\/i>, “The KISS mantra is pervasive: ‘Keep It Simple, Stupid!’ This motto applies just as well to security as it does everywhere else. Complexity increases the risk of problems. Avoid complexity and avoid problems.”<\/p>\n

7) Do not share mechanisms<\/b> — Should you plunk your inward-facing business application on the public cloud?\u00a0 Probably not, according to this principle.\u00a0 Why have your authentication system deal with random Internet traffic when you can limit it to employees who you (supposedly) trust?<\/p>\n

Here\u2019s a geekier example. If you have multiple users using the same components, have your system create different instances for each user.\u00a0\u00a0 By not sharing objects and access mechanisms between users, you will lessen the possibility of security failure.<\/p>\n

8) Be reluctant to trust<\/b> — Assume that the environment where your system operates is hostile.\u00a0 Don\u2019t let just anyone call your API, and certainly don\u2019t let just anyone gain access to your secrets!\u00a0 If you rely on a cloud component, put in some checks to make sure that it has not been spoofed or otherwise compromised.\u00a0 Anticipate attacks such as command-injection, cross-site scripting, and so on.<\/p>\n

This principle can get tricky fast.\u00a0 From Building Secure Software<\/i>, “One final point to remember is that trust is transitive. Once you dole out some trust, you often implicitly extend it to anyone the trusted entity may trust.”<\/p>\n

9) Assume your secrets are not safe<\/b> — Security is not obscurity, especially when it comes to secrets stored in your code.\u00a0 Assume that an attacker will find out about as much about your system as a power user, maybe more.\u00a0 The attacker\u2019s toolkit includes decompilers, disassemblers, and any number of analysis tools.\u00a0 Expect them to be aimed at your system.\u00a0 Ever look for a crypto key in binary code?\u00a0 An entropy sweep can make it stick out like a sore thumb.\u00a0 Binary is just a language.<\/p>\n

10) Mediate completely<\/b> — Every access and every object should be checked, every time.\u00a0 Make sure your access control system is thorough and designed to work in the multi-threaded world we all inhabit today.\u00a0 Whatever you do, make sure that if permissions change on the fly in your system, that access is systematically rechecked.\u00a0 Don\u2019t cache results that grant authority or wield authority.\u00a0 In a world where massively distributed systems are pervasive and machines with multiple processors are the norm, this principle is a doozy to think about.<\/p>\n

11) Make security usable<\/b> — If your security mechanisms are too odious, your users will go to great length to circumvent or avoid them.\u00a0 Make sure that your security system is as secure as it needs to be, but no more.\u00a0 If you affect usability too deeply, nobody will use your stuff, no matter how secure it is.\u00a0 Then it will be very secure, and very near useless.<\/p>\n

Spaf has always laughed at the line that mentions how the most secure system in the world is one with its hard drive demagnetized that is buried in a 30 foot hole filled with concrete poured around a Faraday grid.\u00a0 Such a system is, ahem, difficult to use.<\/p>\n

12) Promote privacy<\/b> — Yeah, I know, everybody talks about privacy, but most people don\u2019t actually do anything about it.\u00a0 You can help fix that.\u00a0 When you design a system, think about the privacy of its ultimate users.\u00a0 Are you collecting personally identifiable information (PII) just because somebody from the marketing team said to do so?\u00a0 Is it a good thing to do?\u00a0 Do you store PII in a place where it can be compromised?\u00a0 Shouldn\u2019t that be encrypted? Information security practitioners don’t always have to provide the answers to these privacy questions (that’s what CIOs get paid for), but it’s important for infosec to put forth these kinds of questions if no one else does.<\/p>\n

13) Use your resources<\/b> — As I was taught in troop leader development class when I was 14, “use your resources” is a principle with incredibly wide application.\u00a0 If you\u2019re not sure whether your system design is secure, ask for help.\u00a0 Architectural risk analysis is hard, but there are people who have been doing it well for decades.\u00a0 Don\u2019t try to go it alone if you can\u2019t.\u00a0 And don\u2019t feel bad about asking for help; this stuff is tricky.<\/p>\n

Source:\u00a0http:\/\/searchsecurity.techtarget.com\/<\/p>\n","protected":false},"excerpt":{"rendered":"

1) Secure the weakest link — Spaf (that is, highly respected security expert Gene Spafford of Purdue University) teaches this principle with a funny story.\u00a0\u00a0 Imagine you are charged with transporting some gold securely from one homeless guy who lives in a park bench (we\u2019ll call him Linux) to another homeless person who lives across\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"class_list":["post-426","post","type-post","status-publish","format-standard","hentry","category-architecture"],"_links":{"self":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/comments?post=426"}],"version-history":[{"count":1,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/426\/revisions"}],"predecessor-version":[{"id":427,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/426\/revisions\/427"}],"wp:attachment":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/media?parent=426"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/categories?post=426"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/tags?post=426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}