In the past I was primarily a software engineer who blogged about software engineering and technology and was exploring and researching security. Now I am moving towards being a security professional that uses software to automate security, networking and compliance. For this reason my old blog has much more information and this one is currently a bit sparse. That, and the fact that a lot of my recent writings now reside on an internal blog for my company to help our developers at my job. Hopefully I will find time to write more here in 2016.
About two years ago, I made a few changes to align with the work I want to focus on in the future, which is based on work I found most interesting in the past. This entails AWS, security, automating complex processes and analyzing data - especially network traffic and financial data. I was accepted into the Master of Security Engineering from SANS Institute program the same month I started the Seattle AWS Architects and Engineers Meet Up. Through the SANS program I wrote a case study on the Target Breach, a security awareness kit for cloud developers, and have have obtained multiple SANS certifications. Additionally I have obtained AWS certification and as you can see the meet up has grown quite large.
Many of the projects on my resume are related to automation of processes. I need to add to this list the process for IP allocations and deploying security groups, subnets and NACLs for applications in over 60 VPCs for multiple lines of businesses. As for data analysis and security, around 2005, I wrote a WAF (web application firewall) after discovering via network traffic anomalies that my web server was hacked. The early pages of this blog include some traffic analysis from someone who was quite clueless about network traffic when I started doing this. By the time I was through I was able to very granularly control who got access to the forms and pages on my web sites based on network traffic, visitor fingerprinting and http request profiles.
Now I am studying packet headers in an advanced intrusion detection class and pen testing, and thinking about how all the things we are doing in information security can be automated. The number of ways systems can and are being compromised is mind-boggling. It is clear that it is not feasible for human review of complex designs that span applications, databases and data warehousing, networking, email systems, storage, back up systems, proxies, domain controllers and much more to prevent all vulnerabilities. Changes are constant and required for a business to innovate and remain competitive. The only way to keep up with the constant change and provide adequate security review, compliance and auditing is through security automation.
AWS is, in a way, the automation of processes revolving around configuration management. It is pure genius. I used to think when I was driving down to my rack at Internap to reboot a server, or attempting to change a hard drive in a custom built server (and frying it because I put the wires in backwards) what a pain it was and if someone could just automate all these horribly manual things their company would explode exponentially. It wasn't a business I particularly wanted to run - I hired someone to run my back ups because these things bore me to the point I don't trust myself to do it. But I wanted someone to do it. And Amazon has. All these manual, time wasting, error prone things we do in data centers and software deployments can be automated, so we software people who live in the logical realm and are not fans of boxes and wires can focus on other things.
When I requested to join the AWS team at Capital One, I had been evangelizing AWS at work (even sent our CIO a link to the Gartner report and a presentation I made after attending the AWS architecture training) but I had no idea at that point the speed at which AWS would be adopted at Capital One or that plans were underway to have our CIO speak at re:Invent in 2015. I simply believed that AWS had matured to the point it was highly feasible for use even at a financial institution, not to mention the benefits it provides to companies trying to remove barriers to innovation. The security processes used by AWS were better than things I had seen being done internally at any company where I had ever worked. The list of certifications offered by AWS Compliance is impressive. I also felt that the speed at which you can automate was unbeatable. The rate at which Amazon produces new features that make development easier cannot be matched by most companies trying to create an internal cloud.
In my opinion, the biggest value AWS provides for security, are tools to manage your inventory, the state of your environment, event triggers and auditing. The things you lose by not running everything yourself are offset by contracts that state what Amazon is responsible for and the ability to have separation of duties and 3rd party auditing of actions taken on the AWS platform by people in your organization. Of course you still need to implement things correctly on AWS to maintain security - but there are a lot of security tools which, for most companies, make things a lot easier and more secure than what they are currently doing in house at this time.
For this reason I'm a huge fan of AWS and hoping to pick up more projects related to security and automation both at work and through my side business on this platform. Hopefully I will be able to find some time to add some additional thoughts here in the near future about how AWS can help companies improve their security posture, if implemented using AWS and security best practices.
If you happen to be reading this prior to January 18, 2016, please register for our upcoming Seattle AWS Architects & Engineers meet up with Evident.io - which will also cover some of these security and automation topics.