Tuesday, September 6, 2016

Keeping Things Static With My Public Presence To Reduce Security Friction

I've been pretty vocal about running the API Evangelist network of sites on Github Pages, ever since I first started doing it back in January of 2013. Back then I was just playing around with the concept, but in 2016 my entire public presence runs on Github Pages.

There are several reasons I do this, starting with the simplicity of static website solutions like Jekyll, something that quickly evolves when you marry with the social approach to managing code that is Github. I like managing my sites this way, but the primary reason I migrated to this setup was because of security. After a couple of online events where I stepped up to defend my girlfriend Audrey Watters (@audreywatters) I woke up to all of my sites being down, by some friendly hacker.

I admit I don't have the best security practices. I have the skills to do it, but everything I do is public, so security is really not a concern. I just don't want my shit taken down by someone, or have my readers experience an outage. I got backups of things up the wazoo, in three different locations, including a nuclear missile silo in Nebraska. I can restore and rebuild at any point, but I don't like people taking my sites down just because they disagree with me. 

So I moved everything to run on Github a couple years ago. I'll outsource my security to them. All of my API industry research projects have a JSON core, driving the data, content, and API definitions for the APIs I create and keep an eye on--often times there are code samples, libraries, and other open tooling as well. So I'd say that my "websites" meet the criteria of being a worthy project for hosting on Github Pages. All of my research, except what ends up in a PDF, is meant to be open, forkable, and remixable--so Github just works for me.

With this move to being static my world became a dynamic push, instead of a dynamic pull, which significantly reduces the attack surface area for hackers--well except for the part where Github is hosting my sites, and I'm outsourcing security to them. At least it isn't my responsibility, plus I get the network effect of being on Github. When this is coupled with CloudFlare for my DNS, and offloading my DNS security to their experts, I figure I'm coming out ahead when it comes to securing my public presence, and what is most important to me--my research.

I still have my administrative API monitoring system (which is dynamic), something I will be working to further localize on my workstation, and a local server--it doesn't need to be on the Internet all the time. Then, all that is left then is my API stack--a stack of simple web APIs that help me operate the API Evangelist network. I will have to secure my APIs, but it dramatically reduces the publicly available surface area I have to defend, something that helps ensure my static presence will always remain available--even if my APIs go away.

In the current online environment I am not one to pull back from using the cloud after all I have invested in it, but with the volatility that lies ahead, it makes sense to keep my surface area defined, including all domains, and 3rd party services, and reduce the size of it at every turn. When possible, it also makes sense to go static, something that I'm seeing reduce a lot of friction and concern for me when it comes to maintaining my very public online existence.



from http://ift.tt/2bRBHmP

No comments: