Those of you who have been reading my stuff for almost a decade or using the security stuff I’ve been writing and bringing to the market for more than that length of time will know that I have a passion for security as a business as usual accepted practice. That extends from perimeter security through to application level security and the chagrin of being intelligent about your management and change controls around every aspect of your deployment be it on-premise or in a third party hosted datacentre or hybrid/public Cloud.
One of the reasons for finally joining Red Hat is here is a company that has grown in every aspect of it’s operation that is relied upon by the largest brands and the institutions we all rely upon to handle our financial transactions, our well being and the processing of our needs as consumers. I can be picky who I work for, I do this for the love, not remotely for the money and whoever I work with has to be able to add to what I bring to the table around the whole security value add. Never more so is that intrinsic to what we do as an industry as in Cloud. There is literally nowhere to hide. Security through obscurity is not a practical approach and a zero day exploit or a badly coded application or a drop in escalation of a privilege level can be the difference between a Cloud environment succeeding or failing and a platform collapsing like a pack of cards.
A conversation I often have with friends in the Security space is one of understanding risks. Mark Cox who runs the Security Response team at Red Hat is someone I’ve known for over a decade and who I talk to very regularly. He runs a blog outside Red Hat which is crammed full of illustrations around the maturity of security controls in the Red Hat release and engineering space (see this report from December around the vulnerabilities and advisories and our responses as a vendor for RHEL). Mark’s team work very closely with the engineering teams in Westford and globally to ensure that our appetite for risk (given we’re the platform people rely on to go to work) is entirely focused around visible responses in lightning fast windows.
So why is the title of this article talking about Aasholes, what is an aashole ?
For starters I’d have loved to have coined the description, to be the one adding this to the Cloud vernacular but unfortunately I can’t take the praise for it. Fred Pinkett the popular blogger came up with it and it’s the perfect word to describe a potential or actual security hole in a PaaS, SaaS or IaaS environment. I point you with genuine admiration to his article from June 2011 as a primer on the very basic needs and structures as you build your own Aashole Protection System (let’s just refer to it going forward as an APS).
An APS can take many formats but one thing that I start to try and get across to people, and those of you who have sat and listened to me at conferences or across a table will hear me bang on about controls and mindset to deployment and beyond. I have long been a major fanbois for the Cloud Security Alliance and I work closely with their founder Jim Reavis (watch for an upcoming announcement soon from the CSA about working with Red Hat). Since 2009 I’ve been responsible for signing off and accrediting some of the largest Linux deployments in the most dangerous and critical parts of national and international infrastructure and in the defence sector (or defense for the majority of you reading this article appreciating you already think I spelt datacentre wrong earlier in this article). I would not have been able to do so without being able to take often badly written and badly managed higher level design documents and to cross reference them against the freely developed and distributed Cloud Security Alliance control matrixes or CCM’s. I cannot stress heavily enough or place enough emphasis on why these are uber critical towards getting on your personal radars if you don’t already know what I am talking about.
Here are some pointers why you should already be aware or using them !
1) These controls are free !!! If you haven’t got a copy – get a copy.
2) If you read them and you build and deploy with them in mind you are going to have a very boring life but you’ll be able to rely on your own deployed controls to avoid an Aashole incident.
3) They are a living, breathing document that changes over time – make sure you check for updates as the CSA community have more strength in depth than any blue chip consultancy security company / pen testing organisation / managed services organisation.
4) Working with them when designing your Cloud and working out which apps you can and can’t move to a Cloudy environment and how you fit into legislative governance requirements and audit needs (PCI-DSS/ISO 27001/2/SAS 70/HIPAA etc) will save your organisations tens of thousands of dollars.
5) Using the CSA CCM matrixes alongside proven segregation controls such as sVirt and SELinux templates in RHEL / RHEV deployments will give you the strongest industry controls that you can find. Belt and braces.
So you have the Cloud Security Alliance freely propogating and educating more than any other body in the world around standards adoption and building security as a cornerstone of your application and provisioning environment and you have a healthy fear of a pink slip / P45 / being able to work again because you’re an Aashat (I am claiming this one Fred – sorry) and more than anything you take a pride in what you do as an individual in your team or as a solo warrior in your Cloud efforts within your organisation.
Now if you didn’t read Tim Kramer’s article I posted last week on Security in the Cloud please go read it now. We’re all about playing safe and being sensible. Nobody wants to be the Aashat who didn’t go the extra mile.
Last but not least we hope to have an interview in Podcast form with Jim Reavis from the CSA that we’ve been trying to get in the can for three weeks but we keep missing diaries / travel schedules. If you’re in Germany and you want to go and hear him speak he’s at the CSA conference in Frankfurt next week, details here.
You can also listen to a podcast I recently recorded with Gordon Haff and Ellen Newlands when I was in Boston around the whole Cloud Security piece in MP3 and OGG formats by following those links.
The Red Hat Security Knowledgebase
Mark Cox has asked me to point out that we have a Security Knowledgebase that is now for the first time publically available from access.redhat.com containing a depth of information that aligned with the CSA controls give you as a practitioner / administrator security in depth and able to work with us to move to Cloud even more securely. Alongside the cookbooks that are available on request (please feel free to ask me for more info) we hope that you find these massively useful.
Just in case anyone reading this has a sight impairment and uses a text to speech / Festival type converter I hope you didn’t have a heart attack listening to the transcription of this article. Sometimes to get a very serious critical point across you have to bow to the influence of others and Fred Pinkett wrote the book on this.
Download the podcast in MP3 format here – or alternatively browse the RSS.
The Cloud Evangelist 
You must be logged in to post a comment.