Security is a topic that is often poorly understood by developers because many of them focus on the technical side of security rather than the wide...
For further actions, you may consider blocking this person and/or reporting abuse
One thing, I'd mention too, although potentially obvious, but it never hurts to state the obvious, is to always apply the principle of Least Privilege.
Interesting, tell me more. I haven't heard about that before.
Give your users, services, etc. the least amount of privileges necessary to function and no more. For example, I recently watched a security video on how to hack AWS Lambda. Pretty much all the exploits depended on the admin being lazy and giving the IAM account all privileges (
*) rather than creating multiple accounts and customizing the capabilities of each one to the task at hand.👍 Thanks for providing the explanation Kasey, was in a meeting before, so didn't have time to respond.
For reference, I came across this in 2014 while working on Identity Access Management (IAM) for a bunch of SharePoint applications that were using WS-Federation, SAML etc. Although the code is generally related to C#, this was a great blog I used at the time, leastprivilege.com.
Dominick Baier, the author of this blog, is well versed in IAM, specifically on the .NET platform. If you're in that ecosystem, you should check out, github.com/identityserver
We use IdentityServer for one of our systems, actually.
Our client ended up going with commercial software. We set them up with Optimal IdM. Great product and support. We needed an on premise solution, so it fit their needs. The virtual feature allowed us to expose all the clients' user stores as one.
Ah that all makes a lot of sense. We've recently gone through a process of doing that at work.
@robdwaller , here's a real world example that occurred yesterday.
Why people run npm with
sudomakes no sense to me as you don't need to.In this particular case, by giving npm too much privilege, it wreaked havoc on Linux file systems, Show-stopping bug appears in npm Node.js package manager | ZDNet.
Had npm been run with a non-root user (least privilege), this would not have happened. The issue has since been fixed with a patch.
I have to admit I hate NPM. I've scrapped entire boxes and started over because I've messed up an NPM install. It always feels more like sorcery than actual Dev ops. Always advise developers to be careful with Node and NPM.
Also would be remiss without linking this:
Principle of Least Privilege
But that's just more dogma too. Don't get me wrong, the principle of Least Privilege is a fantastic security tool, but it comes a cost, and sometimes what you're protecting just isn't worth that cost. For example, I run my own server which handles my mail and runs my blog, and I also run an always connected IRC client through screen on it. Principle of Least Privilege would say that I should use a different user account that doesn't have the ability to admin my web and mail server for running my IRC client. But I don't, because the value of my mail and web server isn't that high, not high enough to outweigh the cost of managing multiple use accounts and SSH keys for logging in to the one server. That's a pragmatic decision I've made after understanding the threats.
Good article, I like how you boil down a complex issue into a simple set of questions. Thinking about security is the first challenge for many people. I also agree to your comments about Google and their movements with regards to HTTPS. It's a step in the direction of being more secure but like you said, being a HTTPS website doesn't make the application completely secure.
Really pleased you think so. I just think the Google Chrome position is odd given the influence they have over the web.
Hey Rob, a few good points in there.
With regard to Dogma, I feel it's often useful to follow the "Dogma" (ie, advice of the experts) in the area's you dont have a good understanding of, rather than dismissing it as Dogma. On a personal note, I wish more products treated access to Personally Identifiable Information with more security than credit card numbers. At least I can change my credit card, much harder to change my DOB.
"It is perfectly possible to build a site and serve it via HTTP that is more secure than a site served over HTTPS".
Could you elaborate on that statement? Otherwise I feel it does considerable more harm than any good it does to have in the article.
Golden -> Implement a proportionate solution
Hi Thomas,
Thanks for the comment and feedback, sorry I haven't responded to this sooner, I've been a little busy with work and other things...
To answer your questions, I absolutely agree that it's sensible to follow the advice of experts. I just believe there is a difference between this and following dogma which can be counterproductive.
In terms of of HTTP vs HTTPS: A Jekyll / Static site served over HTTP is likely more secure than a WordPress / Drupal site served over HTTPS. My point was simply that HTTPS does not guarantee security, merely increases it. You shouldn't implement HTTPS and assume you're safe.
I hope that answers your questions.
Hi Rob, No worries.
I think your statement about Site Security and HTTPS is conflating two very different aspects of security to the point of being harmful to a less-informed reader.
I'd argue that HTTPS in no way increases your site's security (for some definition of security). Any expectation that is does is misinformed. What is does do is well documented by others such as Troy Hunt, so I'll link to that rather than poorly attempting to make the same point. Overall HTTPS is about the security of your visitors, not how hackable your own platform is.
troyhunt.com/dont-take-security-ad...
troyhunt.com/the-6-step-happy-path...
It's certainly not dogma, but just good practice, and with the prevalence of services like CloudFlare and LetsEncrypt, the barrier to entry is pretty much zero now.
Cheers!
Great article Rob! I use the following mantra(s) when talking to technical teams about information security, I think they line up well with yours:
I also talk about security frameworks such as Gartner's Adaptive Security Architecture (Predict, Prevent, Detect, Respond), breaking each of these terms down with examples of technologies or processes used. This helps make infosec less abstract, especially if I can include some war stories!
I like the "Know you are wrong" mantra, it can be applied to all levels of development. As soon as you think something is working it's most likely broken in some way... :)
Very nice article.
I would like to add that in my opinion, the weakest link in every system are users. Of course, we should secure our systems itself but users awareness is the most valuable thing.
Cheers.
The biggest security hole in your business or organisation is always the people. I didn't touch on social engineering but most businesses are probably more vulnerable to it than a data hack.