Security...What Security?

Yesterday I attended the Cloud Connect Conference in Santa Clara.  I enjoyed the keynote speakers and the breakout sessions covering various aspects of the Cloud frontier and the implications of working with new and older companies and with dealing with data that is stored off-site in the Cloud.

What does all of this mean for us?  Early adopters are of course, already there, storing data, sharing documents and collaborating in the cloud.  However there are some companies that are still entrenched in having a large IT department on site and in using data and software that is tethered to their intranet  and desktop computers.  The main take-away on Cloud Computing is that we are already in the Cloud and that the companies that are still entrenched in their own systems will need to migrate to the Cloud in order to be able to work anywhere and anytime.

This brings me to the issue of security.

I attended a fascinating session on "The Future of Cloud Security:  Panel Discussion About Security the Cloud Ecosystem - Sponsored by McAfee".
Members of the panel were:

Moderator - Charles Var, Director, McAfee

Speaker - Ronald Knode, Director, Global Security Services, CSC

Speaker - Shahed Latif, Partner, KPMG LLP

Speaker - Niall Browne, CISO & VP Information Security, LiveOps

Speaker - Scott Chasin, CTO, McAfee Software-as-a-Service

It seems that everyone is trying to make the Cloud more secure so that data, usernames, passwords, documents are safe and so that users will have trust in the system. There are standards for the Enterprise right now (SaaS compliant, etc), but there aren't the same standards yet for the Cloud.  The panelists said that we will see more standards set and companies boasting of having such and such compliance standard.

This brings me to 'Security...What Security?'

The problem that I see is that we will never be 100% secure in the Cloud, because we can't even be 100% secure when not in the Cloud.  There are so many inter-dependencies of companies that are collaborating with each other that if one part of the chain is not 'secure' then other members of the chain can potentially be compromised.

The latest hacking episode that surfaced that involved China hacking into Google, Yahoo and other companies turned out to be related to a program that is widely used for software development called, Perforce.  Who knew?  Everyone assumed that Perforce was secure, but it turned out to be the weak link in the chain.  Even if each company possibly had a certification for security, any new build or release from the company after the certification happened, could again compromise everyone.  Just look at all of the security patches that Microsoft has released and you will soon see that there are holes everywhere that we try to patch and fix, but during the time of identifying the problem and patching it, there is potential for a security breach.

So, what do we conclude from this?  We are not going to hold back the Cloud.  It is here, and it is the future.  We need to rely on security firms to find and identify security holes and then quickly release patches and then we move on.

Computer security is just like any other type of security.  We are mostly secure but never 100%.  Best advice...don't make yourself crazy about it.  That's just the way it is.

Method to My Madness

So you might wonder, "What does an exploratory tester do?  Does it really count as testing since it is not automation testing?"

Since leaving Google and starting my own company, I have run into companies that only want to hire automation test engineers or companies that think that exploratory testing can be easily handed off to off-shore teams without having someone from their company monitoring and guiding the testing.  The idea is that exploratory testing is so simple that it can be handled off to teams that don't have in-depth knowledge of the product.  They can just run some test cases while the automation testing covers the 'real' test cases.  Not so!

From my perspective, exploratory testing is an art...plain and simple as that. An outstanding exploratory tester takes great pride in breaking software, in finding the holes in the code, in stressing the system in a way that the software developer did not anticipate.  That is the fun in it, when you really love this type of testing.

Think of it this way.  Would you rather have your users find the bugs or give up using your site because of the bugs, or would you rather have someone with experience find the issues first so that your users will think that your site is awesome and easy to use?

Think like a user, but break the code like an expert!   That's what a great exploratory tester can do.

Let's take a simple example.  You have input fields on your site for people to sign up and get a login name and password. If the code is written properly, the fields will have limitations (number of characters allowed, types of characters accepted and those that are not allowed).

What happens if you haven't set the limits properly?  You leave yourself open to buffer overflows or cross-site scripting attacks, for example.  Also, if there are no limits to the fields, and you accept 200 characters for the username, what happens when you show the next screen that says "Welcome" and then proceeds to print out a name that is 200 characters long?  What happens to all of the nice formatting on the page that you were expecting?  Not looking so good now, is it?

A great exploratory tester thinks 'What if _____? and then proceeds to test it out.
A great exploratory tester truly enjoys this process of not following the expected road.
Anyone can do what is expected.  The interesting results come when you don't follow the expected path and then do what seems 'random'...but actually is well thought out and based on testing skills.

Many companies are using their software developers to test new builds.  Big mistake.
You wouldn't want your physician to do your dentistry, would you?  They are both doctors, but it takes a specialist to do the job right.  Don't let your software developers do all of your testing. Sure they will find some of the issues, but as your company grows, so does the expectation that your site will work all of the time..  People can be fickle.  If your site is down too much, loses data, releases features that are unacceptable to your users, you will have people looking for other options.

So what do I mean "Method to My Madness"?  I mean that exploratory testing may seem like 'madness' and 'randomness' but it is really well researched and thought out, educated 'madness'!