A case for Security on cloud

A case for Security on cloud – What vendors tell developers and what they actually do

There has been commensurate commentary over the issue of security over clouds by people. My observation so far has made me come to this consensus that on the Internet, there have been two fractions of crowds – one that favors CSPs(Cloud Service Providers) and place trust over them and the other, quite skeptical and $% one wary of the CSPs over privacy and security issues. This issue has permeated from individual to enterprises alike. In keeping with the main issue of 'trust', CSPs have been quick to point out (for their good more than anything else) the black-boxed nature of their offerings.
This discussion has become more important due to ever increasing share of cloud over the IT infrastructure in almost all organizations, which is not surprising considering the ever growing importance to economize and increase flexibility in all firms across every domain.
As apparent from the above chart, cloud computing has moved from network and storage level (SAN, NAS) to complete machine level virtualization (vmware, zen) to platform as a services, and is moving towards completely managed applications (of which Salesforce serves as an excellent example). This implies that interdependence over CSPs is increasing at almost an exponential pace. Apart from risks in reliability, interoperability and vendor lock-in, there has been jitters in the IT industry, and rightly so because of the black box approach towards solutions as I'll mention below that CSPs sell while explaining the benefits of abstracting security.
However, things aren't as rosy as they appear and life is not as simple as we imagine it to be (sigh!) and security for entire solution is different than that of an application. It is not an aspect or component that we can invert to container or add in addition to the application. In this case, the approach towards security differs as it has to be applied at all the levels of the application stack.
Infrastructure Security
This is important in context of public clouds as there tends to be misconceptions between the terms infrastructure security and infrastructure-as-a-service security. There is a slight difference between the two as there is a difference in the above mentioned terms. Both have a similar ramifications over the customer threat, risk and compliance management. Some of the leading CSPs like Amazon and Google have had incidents where their Data Confidentiality and Integrity have been breached. Proper access control over data is as important as having the information secure. Here again, the emphasis is not over the information security but also on the infrastructure security(There have been cases where discarded AMIs have been used maliciously) that is being offered.
In order to mitigate the increased risk factors, we need to rethink about whether we need a public, private or a hybrid cloud. Similarly for the data in transit, we need to implement rigorous encryption algorithms which again have a trade off between security and usage.
The security approach follows an onion pattern where host security forms the basis followed by virtualization software and virtual server security, which then propagates into network and finally application security.

Data Security(Information Storage and Management)
This is an important part of information storage and management because in a cloud setup, there tends to be a change about how the data moves about. Since the data gets remotely stored, security of the data takes a new dimension. Data security now requires the following aspects:
Data-in-transit
Data-at-rest
Processing of data, including multitenancy
Data lineage
Data provenance
Data remanence


Authenticity and Accessibility on cloud
The services pertaining to the trio of Authentication, Authorization and Auditing(AAA) comprise the Identity and Access Management. Unfortunately, it remains to be seen whether the cloud providers actually are committed towards providing them in a readily usable manner or not because it is inconvenient to provide it properly, but also due to frequent change of roles and rules of the stakeholders involved. However, there has been a lot of work going about here and largely due to federation of IAM entities and emergence of web service standards such as SAML and WS-Federation. What is needed here is something that is IAM-as-a-service. This will not only address weak ISM models, but also makeup for lack of federated structures.

Is Security as a Service (Gosh, another SAAS acronym ) sufficient ?
The Security-as-a-service model, like the original SAAS also is subscription based. This however is nothing new as many vendors have been providing email filtering and anti-virus scanning traditionally.
This service today needs greater scanning and importance that ever before largely due to the rise of crime over the cloud and before cloud platform assumes even greater dimensions than ever before. These are just some of the difficulties that I've mentioned. Similarly, vulnerability management and IAM has been around for a while, but has not truly been incorporated as a service up till now.
Hopefully in the near future, the shift of enterprises towards cloud computing and the maturity of the services oriented model would promote this service paradigm and the ever increasing security conscious customers would fuel the growth of security over cloud.

Commenting about Comments

//TODO : Finish this rant
#There has been a lot of discussions about the use of comments that appear in program code. This was something that I overlooked so far and only used when it appealed to me, which is itself a rare occasion for me.

#In the book, '97 things every programmer should know', there have been a lot of insight over the same issue. In it, Carl Evans recollects a lesson that he learned from his teacher(getting poor grades without commenting). The same thing, in fact happened to me too.

#Recently, a lecturer teaching Software Engineering (who is quite vociferous in his teachings)in our class proclaimed, “Comments are just waste of time and people(coders perhaps ?) should be kicked in their ass for writing comments. Comments indicate that the programmer was wasting time in writing them instead of writing LOCs”.
However, I learned a lesson similar to Carl in my class exams held in the previous week. In the exam, there was a question that required us to print a pascaline triangle using C#. I wrote its program, that I conjured up at the moment and hoping that it'll yield returns in terms of marks. But to my utter surprise, the program in question was awarded a big 0.
While explaining the paper, this teacher(who teaches .NET framework and C#) declared the opposite of the commenting practices listed above.
In my opinion, the amount of comment that you really need to insert is when the code requires some external prodding to be able to be understood.

So, I guess that it is probably useful to create and maintain comments in a codebase if it is self-describing. According to me, for long term basis a comment should only written specifically for technical documentation. The use of javadocs or msdn styled comments not only serve the purpose for the ordinary comments, but also aid future developers into maintaining and extending the software as they can provide insight in various ways( separate documentation and IDE support).

In The Elements of Programming Style (Computing McGraw-Hill), Kernighan and Plauger note that “a comment is of zero (or negative) value if it is wrong.”. These, alongwith my thoughts over the usability and proportionality of comments are echoed in this javaranch discussion thread. Hopefully, in the near future such a situation may not arise when it became an embarrassing situation for me, just because of lack of comments in my otherwise correctly functioning piece of code.