Podcast – Ed Daniel, ITIL, Audit & Cloud

I am joined on today’s show by Ed Daniel. Bit of a coup. Ed is one of Europes leading OSS evangelists but like me shares a background in process management ITIL, security and enterprise enablement. Ed works for Normation and was in London attending DevOps and I didn’t have to push very hard to get him to sit down in front of my microphones.

This podcast is really for the companies who are thinking about deploying Cloud, who are thinking security hardening, process management, ITIL, PCI-DSS, ISO standardisation, deploying against Cloud Security Alliance or SELinux guidelines. If you’re a service provider too this podcast also helps you. It’s your opportunity to hear myself and Ed try and give you a steer on designing your cloud and to get to deployment safely whilst growing the frameworks around Cloud management.

We talk ManageIQ/Cloudforms, how audit and logging is essential, OpenStack and Ceilometer, Heat etc etc. How you should engage with a Cloud provider or upstream vendor.

This is one of those difficult conversations which you rarely hear and that is designed to get you to a point where Open Hybrid Cloud can become a reality. We don’t always agree but between the two of us we try to get you to a point where you are armed to safely and securely start designing and consuming Cloud compute capacity.

 Download the podcast in MP3 format here – or alternatively browse the RSS.

Podcast: Red Hat Acquire ManageIQ


I’ve been promising to record and release this quick podcast on my take on our acquisition of ManageIQ. I don’t speak for Red Hat on this nor do my views or opinions matter in any way. I look at things from a technology adoption and technology abstraction layer and how it impacts and enhances our abilities in Cloud.

If you’re not aware of ManageIQ I’m presuming you’ve had your head buried in the sand for the last three years.

Needless to say when I found out about ManageIQ becoming part of Red Hat (subject to all the usual shareholder stuf) I was beaming from ear to ear. ManageIQ are an amazing group of people who really understand the granularity of cloud, the flexibility you need to demonstrate when dealing with elastic architecture but the need to get under the hood and deliver. Quite simply they demonstrate maturity in depth and excellence of the highest order when it comes to engineering solutions across heterogeneous cloud platforms and technologies.


Combine that with a virtualisation layer(RHEV/KVM), a storage platform (Gluster – Red Hat Storage), a PaaS platform (OpenShift) and CloudForms and you are effectively delivering an entire orchestration piece that no other vendor, VMWare included, can currently compete with. Seventy two hours on to the minute I am STILL smiling.

Here’s my take on it – listen now on iTunes or Stitcher or click the link to the podcast to listen to it in your browser.

Come back in 2013 for more content – and remember I love hearing your feedback and your news. Better stories come out of collaboration. 43,000+ downloads of my podcasts since August (thats nearly 580 man days of listening if you stacked each episode end to end) is flattering but I can do better – with your help.

Happy Christmas from my family to yours. Have a peaceful festive period and thanks for listening to my work and reading my articles during 2012.

Download the podcast here in MP3 format only

Security 101 for Cloud – building it right

For those of you who’ve known me or my work for the last decade or more you’ll appreciate that one of my main call to arms is security and in particular enforcement of security enforcing technologies at the gateway and application level, my little hobby (developing publishing and supporting a firewall technology which with variants based on the code) reached millions of homes, offices and enterprises across the globe and allowed me to make a career out of security.

So it’s often a question I get asked at conferences and when speaking about security in Cloud and security enforcement and responsibility in the Cloud and virtualisation arena. Fortunately at Red Hat we take security incredibly seriously and have contributed technologies such as SELinux and sVirt into our architectures and supported versions of our releases, as well as employing the mainstays in the SELinux world on our payroll to ensure that we have continuity and those folk are rewarded for their efforts.

However, to put it bluntly most architects and network  guys turn SELinux off when building out platforms and virtualised instances which is quite short sighted. When I do pose the question why a lot of responses are aligned to the fact that SELinux can sometimes due to configuration issues and past experiences where stuff broke and was hard to diagnose so easier to just turn off.

Let’s be blunt, it’s there to help you, it’s a free secure template based technology so turning it off if you haven’t got a full toolkit of other security hardening in your build schema or your platform is at best shortsighted. Did I say it was free ? In this current credit crunch culture can you justify not looking at using it ?

If you’re concerned or you struggle then enable it in permissive mode in the first instance making sure you make relevant mods to /etc/sysconfig/selinux to make it persistent on reboot. Simple boolean logic is the best way (and easiest way) to start experimenting with the functionality you want to add. Then if you want to know more then search for the audit2allow function and remember if you’re concerned with restrictive AVC denials breaking stuff then a quick search through auditd in /var/log/audit/audit.log then aureport is your friend. There are loads of howto’s available or if you’re thinking about large scale SELinux use in anger Red Hat even have a course to upgrade your RHCE to give you a complete comfort blanket in your own capabilities. It’s part of the assurance and certification mode we bring to the whole Linux piece. Belt and braces if you will.

Now this article really isn’t a security masterclass or SELinux howto, I’m actually more interested in getting to grips with culture change and trying to pass on my thoughts of how we need to get traction in influencing how protecting your assets, your data and your reputation in Cloud can take shape.

Over the last three years I’ve been using what I would describe as an almost military approach to building out legacy platforms be they physical or virtual. In days of old people might remember Jay Beale and his Bastille Linux hardening script, which was a great starting point when building simple Linux stacks. I remember vividly when he posted it to newsgroups and Slashdot picked up on it. It represented for the first time really in the Linux Open Source community someone who took a simple exercise but made it mainstream towards security as a standard rather than a retrofit. It enabled many of us to not only run it but get under the hood to find out “how” it worked. What is it they say “a little bit of knowledge is a dangerous thing ?”.

So as we move into provisioning our Cloud environments across one or multiple hypervisor types, or moving applications into hybrid or public Cloud having that “accreditation” process or controls breakdown is invaluable. Mine runs over about 5 tabs of a spreadsheet and would make most auditor feel out of a job. However maybe my way of having a moving spreadsheet of controls that I’ve built up over time for all the certifications / governances that I’ve had to deploy to (including in NATO battlefield accredited above classified environments) probably is going a bit far for standard run of the mill server environments.

So its fortunate that my friends and fellow members of the Cloud Security Alliance started many moons ago to put together an authoritative set of controls to allow you to get to work now building out your platforms or engaging with a Cloud provider regardless of the tenacity or the aggressive nature of your certification or audit model. The controls are designed to get you out the blocks building Cloud platformst that need to meet the regulations around ISO 27001/27002, ISACA COBIT, PCI, NIST, Jericho Forum and NERC CIP. Let’s not mention SAS 70. I still, do not, and believe me I’ve tried, understand why an accounting standard has ANY place in Cloud service provision. CCM will help you there and you can also take a look at the CSA STAR programme while you’re there.

I’ve mentioned the Cloud Security Alliance before here numerous times (lets call them the CSA from now on). The CSA are one of the most critical building blocks of the Cloud community and Jim Reavis and the steering members of the CSA have made the education and communication of security best practices to the community their ethos and commitment since they were founded. Red Hat support the CSA and if you’ve heard me talk you’ll hear me mention them proudly on a regular basis. I am continually mentioning them.

Shortly I am recording an often re-arranged podcast with Jim Reavis of the CSA and we’ll get that out to to you as fast as I can mix it in the coming days and weeks.

Whether you’re playing with Cloud in your dev/test sandpit or migrating to a hybrid  cloud understanding what part reputation protection of your app dev environment and your underlying transportation of data is critical. Reputations are lost in minutes as are share prices when a company is seen as damaged by data loss. Simple breaches of major household name organisations are often met with lax fines and investigation by sovereign territory governments and information commissioners, however the risk factors involved are enormous. At the back end of the application architecture – in the trenches – are the technical guys who have to turn the dreams and aspirations of sales people and marketing types into the portals and customer facing Cloud hosted environments that will generate the revenue. If we arm you to do your job better and to do it in a way that allows generic controlled growth of your platforms and your Cloud aspirations then thats a good thing right ?

Do visit the CCM matrixes today and learn how they help you go to work in ways that will make your auditor despair. It’s kinda cool actually because auditing Cloud and typically follow the sun type datacentre clouds has always been a dark art. By following this article and my advice you can actually have a retort to this argument. Cut a huge percentage out your auditors workload (and their resulting invoice) by owning the moral upper ground and in the process maybe think about turning SELinux back on. Blended use of SELinux, sVirt, supported certifed Red Hat subscriptions and technology such as CloudForms gives you everything you need from an IaaS perspective today to go to work. If PaaS security is your thing then listen out soon to another podcast I’m going to record with Tim Kramer of the OpenShift team (in fact if you haven’t already read it go visit Tim’s great security post here).

Also I’m promised a security podcast with Mark Cox at some point in the coming month so if security is your thing you’re going to be kept busy listening to me warble down your earbuds about everything related to CloudSec. If you think that more people could benefit from a primer in Cloud security deployment and the need to think out the box then share this article – I appreciate every Twitter mention I get if it helps educate another Linux user as to how to do things better.

Then get to the CSA website and join. It costs nothing and you’ll learn a lot if you are an active participant. Tell them I sent you.

Fluffy Clouds = Fluffy Auditors ?

If you’ve sat across a table from me when I am poked gently I’ll often bring up the topic of the need to behave in a way that doesn’t detract from the nature of your responsibilities in computing. What I mean by that is that designing any platform or architecture should have the effect on a developer / architect / sysadmin to generally earn their keep and to stand up to be counted. It’s the one time in a project where the program manager or project lead can honestly do nothing else other than hope and trust that the right people are in situ towards ensuring that the processes and controls, both paper and network/software based are equal in measure to his/her task of getting to deployment.

There is a need now, not later, to think about how Cloud impacts on your ability to satisfy the needs of audit processes. Luckily, companies tending to work with networks and deployments utilising Open Source components, especially supported Red Hat stack components have a general understanding of the need of how platforms need to be constructed and managed. You take your average Linux sysadmin / architect and you put him in a technological boxing ring with his Wintel adversary and my money isn’t on the guy wearing the colour co-ordinating shorts and vest and the Technet subscription being declared victor. I often find, and this isn’t a new phenomenon that your average Linux professional has a tacit understanding of not just his or her platform but also everything that impacts on it. I’ve seen sysadmins wince from across a table in project meetings when the network guy starts talking about upstream network problems because they’re already thinking logfile size and CPU utilisation before the guy has even finished talking. There is a palpable sense of pride and responsibility for most Open Source architectured platforms due to the rite of passage to get them there in the first place when faced with adversarial opposition and the “nobody ever got sacked for buying Microsoft” mantra. Not that theres anything remotely wrong with Microsoft Windows as an environment, it’s just a very closed mindset towards engineering that drives the development and evolution of the platform that makes little to no sense to many of us in Cloud or datacentre centric operations. Bit like being given a burrito – told to eat it and not being allowed to see what’s inside it. Personally I’m a bit fussy when it comes to stuff I consume hence I make a living out of Open Source.

So when I start talking about audit in Cloud, theres an automatic assumption that I’m going to bang on about SAS 70 and the fact many providers in the Public space use it as a get out of jail free card when it comes to their approach to audit response and service level based liability. I’m not going there, there are 101 articles you can grab and reports from WebCPA to Gartner and all points west that will give you balanced industry views from seasoned commentators.

My focus is on specific things that we can do as individuals in Open Cloud to make the impact of audit less of a drain on company resources and management cycles whilst also allowing it to proceed smoother and to learn from both sides of the fence as to what you can sometimes do better. I’ve talked already in previous blog articles here about the Cloud Security Alliance (CSA) Cloud Control Matrixes (CCM). If you didn’t look you should, it’s free and it will give you a grounding at the developer and platform provisioning level of controls you should be using and documenting – or if you’re already installed, retrofitting. I’m a big supporter of CloudAudit.org which last year published it’s API specification which in a nutshell means a public Cloud provider to be able to publish detailed information to a defined namespace to allow proper queries to assist with audit and GRC (Governance Risk and Control) requirements. The fact that they went away as a body and also built a range of rock sold compliance packs which target specific governance types, e.g HIPAA, PCI-DSS, ISO27002 etc and by reflection upping the ante with the marketplace by highlighting differences between vendors. So theres a gap here, a gap that can be filled by the roadwarrior journeyman with his RHEL / RHEV installation building out his cloud to be able to document, based on his or hers tacit understanding. An understanding or realisation of both the global build out of your cloudy endeavours to have time to build attestation reporting and flexible approaches to security and audit as part of 24/7 ops not waiting for your CFO or FC to send you an email to tell you that next week you’re under audit. If you are smart, an early OpenShift or JBoss exponent then you’ll not disagree with me when I say we give you the tools to ensure audit is a 24/7/365 normality not a tickbox in time to satisfy governance.

The great news for you, if at this point you’re getting concerned is that the Red Hat University is running courses on Cloud and also security and virtualisation security that will prepare you to be that man/woman of steel.

Do not get into the liablity argument with project managers. Liability being thrown out as a buzzword by some analysts is hardly something thats new to what we do as an industry. It probably matters more in a hybrid / public world where you’re having to accept an Amazon / Verizon / Rackspace or whoever is your partner to maintain and build out as well as support locally from an app dev environment – each having their own level of documented controls and risk appetites / Service Level Agreements.

Anytime you outsource any business process be it payroll, be it estates management etc you introduce an element of risk. The same risks you can argue is just as pertinent to hand cranked platforms you build internally to support BAU activities. Just at least in your datacentre you can go and pull ethernet / fibre out and hide in the restroom till everyone goes home before you venture out with an iso image nervously to resolve the problem. In the Cloud there is no virtual restroom 🙂

Understanding your risks, setting a risk appetite, using proper automated tools and platform technologies such as OpenShift, JBoss or the soon to be released CloudForms and working out your application blueprints, environments then your business is going to enjoy a more relaxed and shorter audit by virtue of you owning your own destiny and understanding application and platform lifecycle in Cloud. If you outsource to a Cloud provider, especially one where a follow the sun plan takes centre stage to their operations it makes auditing harder and also your descriptive synopsis of the related costs and problem to your CEO and CFO that much more of a bind to deliver. Cloud could be argued to bring in the concept of a chain of liability where a Cloud provider may have other third party vendors in situ to suit your stack – do you have visibility of that – or do you have the right to even know that ?

Is working more openly sounding more attractive by the second ? Outsourcing by its very nature is tricky especially when negotiating liablity and access to audit required functions. I can see you pointing at the screen and saying “This was the same in managed hosting” and I’d agree to a point the only difference was you had more ability to sit down with your provider and work out terms of reference and access for audit. In Cloud with the majority of leading vendors you actually stand to release them from that responsibility unless you understand how to engage or the ecosystems that you will rely on.

Red Hat are your technology partner. The clue is in the word partner – not provider – partner. We have built Cloud Foundation Pathways to help you get through this minefield, backed up by training and support and also the ability to work with us towards making those steps to audit friendly Cloud deployment that doesn’t stop you going to work or shackle you from innovation.

Engage with us, Experience why we’re the number one at what we do in the number one fastest growing industry on the planet. Building the next house of Red Hat on solid foundations and being the compute and node building blocks that are the bedrock of Cloud. Open Cloud.

Security in Plain Sight

I was writing an article for a publication in Europe at the tail end of last week and one of the cornerstones of the piece centred around the holy grail of the qualm of the technology adopter moving to this scary new world of PaaS in the Cloud both on-premise or in a open hybrid model.

I think we’re fortunate – fortunate to be able to be in a position where we have a framework for the safe democratisation of data and applications with the structure of tools and technologies that the management of Red Hat allow us to develop and then bring to market. OpenShift is one of these technological sandpits internally that has seen the brightest and the best minds from every part of the Red Hat family throw in code, ideas and know how to get to a point where just wrapping and packaging a product becomes less of an end point, and more of a lifecycle stage. What I mean by that is that when we now, as we move from being seen by many customers and also potential customers as more than an OS play, we internally have adapted to change when breathing life into platform technologies. It’s a major change for a company when after a decade of providing rock solid support for the fastest growing operating system in the enterprise and the datacentre then it also grows (both naturally and by acquisition) to lend its weight to KVM and the important work of oVirt, but also the JBoss, MRG Grid and Gluster product lines without diluting support or capabilities. I do often think that a lot of analysts are starting to “get it” but many more are still misunderstanding where we’re at and it’s a good thing we get to show everyone in an open and transparent way what the roadmap looks like, but more importantly the structures that the GM100 and FTSE100 type organisations are going to be using as their foundations for the next five years.

I’ve talked about OpenShift at length, we’ll be talking next week to some of the OpenShift crew in a podcast you can download from here once it’s mixed (and I’ve got through death by Audacity and my new howto book – thank you Amazon.com). When we talk about OpenShift you need to think of it as a Roman legion of troops with OpenShift at the head flying the standard followed up by the proven rock solid proven technology components that make up Red Hat Enterprise Linux (RHEL). After ten years we’ve polished and we’ve honed a set of Open Source contributed code and Red Hat engineering excellence into the building bricks of what we’ll now take to Cloud. As we also continue the thought leadership and engineering contributions we’re making to OpenStack over the next quarter that too will benefit massively.

So for the cloud adopter with their entirely fair qualms about PaaS and Cloud you have an opportunity to use something you already know and understand and can compartmentalise – RHEL – and start thinking about how the transparent adoption of OpenShift can just fit into your schema or your plans moving forward.

You already get RHEL, you understand the SELinux seperation and “firewalling” within RHEL, so that then makes understanding how OpenShift has inherited that best of breed behaviour. SELinux providing OpenShift a proven “firewall” to segregate sessions and applications, resources and data, realtime using magic dust that your auditors and your control methodologies and risk registers already understand. This makes security as a process easier to understand AND easier to document. Please don’t underestimate the hidden costs around this. If you’re an ISO/PCI/HIPAA/SOX audited company this is going to be something you have no wriggle room and here’s a technology you can adopt at speed that will not alter your threat fabric or risk appetite.

I’ll leave you with a video shot last year by Gordon Haff talking to Matt Hicks at our Westford offices which I recommend you take time out to watch. If you need any more information or you want to know more please feel free to reach out to me in Europe or to any of our teams geographically.


How to avoid Aasholes

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.