The Trust Problem with "The Cloud"

Cloud in Flask

While having an espresso yesterday with a colleague, we discussed the trust problem with the Cloud and whether or not people will grow to trust it much as they did with the PC or electronic documents. It was a simple conversation about how people can come to trust technology that is new. As we were speaking I felt uncomfortable and perhaps uneasy with the conversation. The conversation continued and then we changed subjects and discussed privacy and general security of document stores and content stores in general. I later had a cup of Ketepa Pride tea and sat in my library. While I was relaxing it came to me, the whole problem of trusting “The Cloud” is that there is no such thing as “the cloud” and thus you cannot compare it to trusting an electronic file versus a paper file.

Let’s take a look at the Electronic File versus Paper trust considerations. So in the simplest form you have a file on your local drive or a file folder with a paper inside. Both are easily accessible and both have points of failure (I will keep it simple).

Electronic:

• Hard-Drive could fail 
• Someone without permission can gain access to the file 
• You may delete the file unintentionally 

Paper:

• Could misplace or lose the file unintentionally 
• Someone without permission may get access to the file 
• May spill water on the file or some other type of medium failure 

Countermeasures are easy for both types of situations and once you are comfortable with the base technology you can assign your team to provide protections for the electronic files that surpass the capabilities of the paper easily. In fact you know and trust your team and have direct accountability and monitoring. If necessary you still keep the paper but add electronic copies of it as well for easy access. This access could be on your private network or local computer. You are responsible for all standards, practices, policies and security of your information.

With this simple example it should be getting very clear what the problem is with “the Cloud” and why I was uneasy with the conversation. However, let’s take a look at the cloud. First we have to define it; Cloud computing is a marketing term/metaphor to represent a service to a community that provides one or more of the following:

• Storage 
• Communications 
• Collaboration 
• Computing Power 
• Applications 
• Databases 
• Network(s) 
• Server(s) 
• Monitoring 
• Identity management 
• Financial Controls 

Again, I am keeping it simple and keeping that in mind we can imagine one or more server rooms being managed on or off premises for one or many groups of customers, and where access can be from any connectable device. For the purpose of this post I will assume that we are talking about a cloud provider versus your company creating a private cloud. In this model your employees connect through the Internet to the cloud and complete your companies business.

Let’s take a look at points of failure and again I am keeping it simple and I will put next to each point of failure a remedy:

• Local desktop system fails – your staff repairs the system 
• Your network fails – your staff corrects the issue 
• Your internet connection fails locally – your staff corrects the issue 
• Your internet Service provider goes down – you place a trouble call in and they attempt to fix the problem within the service agreement. (If you have a backup internet service provider great and perhaps you need to keep everything local and on “the cloud”) 
• Hard Drive fails on “the cloud” – the cloud provider has a backup and recovery plan that they manage and assure that it is followed ethically and in accordance to terms of service 
• Network Connection for Cloud service provider fails – they place service call to internet service provider and attempt to get everything back online 
• Local internet connectivity hardware fails for cloud service provider – provider works to correct issue in accordance to terms of service 
• Someone without permission gains access to your companies cloud – service provider is responsible for keeping content secure within terms of service 

Let me say that I am absolutely aware that this is simplistic but this does demonstrate the problem with trust and the cloud. What you need to understand is the cloud can provide your company with a competitive edge and a new set of capabilities, but it also means that you must know your provider and the software as well as hardware that they use to deliver the service. You need to know their capabilities to the extent that you would understand your own IT staff.

In summary, it is clear, that it is not as easy as trusting new technologies. It’s the trusting of third parties with both your business success and most confidential data. This leap of faith that you must take in fully outsourcing your business and data is far more complex and risky than converting from a paper to electronic document system. From your own internet connectivity to backup, restore and governance you have to evaluate every piece of what will be “your cloud” and remember trust but verify!

Translating Accessibility Governance to Compliance for Websites and Cloud Applications

Roofing Nail

People tend to look at governance as a set of policies and processes that are in line with their company value systems, or  as a set of applicable laws or regulatory requirements  to which they are subject. These can be used to manage risk and provide an acceptable level of compliance. The simple acronym that many people use to describe this is GRC (Governance, Risk and Compliance). Unfortunately many organizations “tack on” these compliance measures as an addition to their core development efforts (Web Properties or Cloud Applications.) This often occurs because even though there is a policy in place and there are qualified Subject Matter Experts (SMEs) available, the steps are not part of the development process but are an addition to the same.

When developing a site or an application a developer works from a set of requirements, norms, and internal/external pressures and then sets off to deliver the product. After this is completed the organization may use the Quality Assurance (QA) team or external SMEs to detect issues with GRC and then set out to fix them. In the case of accessibility regulations, and to keep out of the weeds, let’s just assume the governance objective to be the Web Content Accessibility Guidelines (WCAG) 2.0. In this case, the company does not have to go far to find an expert in Accessibility (a11y).  For those of us that have worked in the GRC field, however, we know that we have now ventured down a rabbit hole from which there may be no escape. This is because we just broke the most basic rules of the development lifecycle. Let’s take a moment to look at the last statement closely.

Classic development, even with the “Agile” method, would have the developer as the responsible party for the first phase in the GRC process, Unit Testing. This developer-driven testing is simply completed at the most basic level and at a point where corrections are easy to fix at a low cost. If you can correct any issues at this stage you have just handled governance and eliminated risk. What you have developed is by default (if developed properly) in compliance.  Some organizations claim that because of Agile they do not have time to test for something like WCAG so instead they pass it off to the post-development system. This, prima facie, makes no sense because the increased development cost to address accessibility after the fact-will be a much greater drain on resources than to incorporate accessibility from the beginning.

A simple search engine query will demonstrate the problem clearly. While you can find many SMEs to help you detect errors (or to test existing systems), you will have a far greater problem finding training for your development staff. In addition the SMEs may not necessarily understand your platform or development language.  Thus even with SMEs you may still be at risk. This is a lesson that we learned long ago in the security world. Imagine developing a site or application without a security plan or checklist. It would be hard if not impossible for you to find a company that develops without a plan these days. In fact, if are hoping to have your company acquired, it is essential to be able to deliver your software security development and test plans.

If you included WCAG testing as part of QA process you would of course, via defect resolution, begin training your own development staff. This internal method, while not the best choice, will in time translate governance to compliance for your company. However, what will not be effective is the external approach because the cost will always be a determent. Now, we must define risk for our organization. Today we should recognize that by not having an A11y strategy in place we are putting our company and customers at risk.  The real question is where to begin. For those of you that have read any of my articles or technical books and guides you are no doubt used to me saying “start with education”. A11y is no different, start with education. While most companies have a team dedicated to security, it is time to have a team devoted to Accessibility.

The team should include at least one development resource, one training resource, one QA resource, and one SME. From there, adjust the numbers as you see fit and yes one person “could” fill the role in smaller organizations. This team should be responsible for building the policies that will turn governance into compliance and simply put you will be changing the QA and development processes to have a11y built-in. I should note that it is very important that your a11y SME have full knowledge of your development platform or you may find that the SME and developers do not speak the same language.  For example, consider a carpenter building a deck that uses roofing nails versus finish nails to attach the deck planks. While the deck SME knows that the roofing nails are wrong on the finish boards he has no way to communicate to the carpenter (Developer) what he must do to correct the situation. He knows that the nail does not look right and it will not function but he lacks the ability to communicate how to remedy the problem.  This will do nothing but add cost in the end and in some cases provide incomplete compliance.

Many small to medium size business (SMBs) outsource their web site or cloud application development to a third party - thus they do not have a team dedicated to developing the site or cloud properties to match GRC requirements. They must set the GRC requirements for the development firm. When doing this a company should consider the vendors capabilities. Look back to our analogy of security -you would never use an outside development company that could not provide you with a development checklist related to security and you should also ask for the same thing as related to a11y.
Translating accessibility governance to compliance is simple and cost effective if you take a standard approach and bake it into your product or solution. If you decide to tack it on after development you will be less successful and in most cases you will not achieve sustainable compliance.  There are a few things you should remember to be successful:

• Education of your development team to build accessible is a first step
• A11y testing must be part of QA
• SMEs MUST be able to speak the same language as the developers
• If outsourcing development you must review a11y capabilities and the providers checklist followed for a11y

Success is both easy and affordable if company leadership commits to a long term plan. Next week I will cover “Translating privacy Governance to Compliance for Websites and Cloud Applications” and as always if you have questions on this post please send your questions to ryonaitis@34alabs.com .

Resources:
W3C, Education & Outreach Working Group (EOWG) http://www.w3.org/WAI/EO/ 
Web Accessibility Initiative (WAI) http://www.w3.org/WAI/