Security concerns with a SAAS system

SAAS – Software as a Service can be defined as "Software deployed as a hosted service and accessed over the Internet rather than a product deployed at the customer’s premises for each customer."

Today, SAAS applications are expected to take advantage of the benefits of centralization through a single-instance, multi-tenant architecture, and to provide a feature-rich experience competitive with comparable on-premise applications.

Software as a Service (SAAS) is transforming the way traditional ISVs do business as providers of applications to the market. This new deployment and licensing model will fundamentally change the business model of the ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance.

But all sounds good for the ISVs run this Business model. The main point here is to get a customer convinced to go for a subscription based software rather than on-premise software.

Customers surely see lots of business advantages by using a SAAS based product over an on-premise product. The reasoning no longer is a business decision. It is more a technical decision. The key technical factor that influences the customer to take a decision whether to go on-demand subscription-based or to buy an on-premise software is – Security.

Since the data is multi-tenanted in a SAAS environment, the fundamental question that comes to the customers mind is – How secure is my data (since it is not in front of me)? What is the guarantee that other customers of the same service do not have access to my data?

The customer should ideally be asking the SAAS providers the following questions to be convinced. It is not necessary that all the question is expected to have a positive answer for the customer to take a decision. It also depends upon what type of business application is being offered as SAAS. But “knowing” the answers is a “must” before taking a decision of going the on-demand route or on-premise route.

Here’s a list of questions I think should be asked by any customer to a SAAS vendor before subscribing to their service. The same set of questions can also be used as a check list by a SAAS vendor.

Data Access Related Questions

• Is the Database Multi-tenanted?
• How many people in the entire chain have the Database SA password?
• Is the data for one customer securely away from another customer?
• Do the Data-Centre engineers have access to the database through SA?
• Can anyone in the entire chain in a position to access / copy / change / destroy critical data of any customer?
• In a system where 3rd Party integration is involved, is the Data communication secured and restricted to only the required exchange of information?
• What information is stored in the Audit log?
• What arrangements are made for Database backup?
• What types of data are encrypted and what is the encryption mechanism used to ensure it is safe?

Infrastructure Related Questions

• What SLA do you the SAAS provider have with their Data Centre?
• What is the hardware redundancy arrangements made by the vendor?
• Does the data centre have WAN backup? i.e. The data centre is replicated in 2 different continents as a backup?
• If yes, Ask all the Data Access Related Questions again with reference to this second Data centre
• How many people from the SAAS vendor organisation have the network administrator password within the data centre?
• How many people have the Shut-Down permission on the Server?
• How often are the servers need to be restarted?
• Does the SAAS vendor align with the Data Centre's SLA within their own SLA?

Internet based Security Threats

• Is the Site hosting the SAAS system SSL enabled?
• Is the Database server on the internet or behind a DMZ?
• If, Yes it is exposed to the internet, then Why?
• How is the system protected from SQL injection?
• (If in case the hacker gets access to Database) Are the critical data encrypted?
• Does the Application User security tightly aligned to the data security?
• Last but not the least, Does the SAAS vendor / provider get their system audited by Security Auditing authorities?

Typically all these (or most of them) are covered in the SLA provided by the SAAS vendor but this is something to my mind is a must for any customer to be aware of before signing as a customer for a SAAS offering.

Agile, SAAS, NFRs & Architecture

For quite sometime I have been trying to get a grip of the agile methodology to develop applications. Somehow I am not 100% convinced (although I am 90% convinced) that Agile is the way forward.
I am still in a state of mind that Agile does not solve 100% of all the software development problems. This article is my effort to highlight few of my view points on this subject.

Agile : I would not go any deep in to this topic as it is a known and a well established topic.
If would like to know more about Agile, there are tons of articles on this subject. All you would need to do is google or (in Microsoft terms) bing it :-)

The Agile Mantra says...

• Individuals and Interactions - over process and tolls
• Working software - over comprehensive documentation
• Customer collaboration - over contract negotiation
• Responding to change over following a plan

In short Agile means - "Iterative Design & development".

So far so good.

But the key point to note here is - its "Design & Development". The process starts at "Design".

For large scale systems such as high availability, high concurrency, highly scalable systems, the key way forward starts at "Architecture". May be there are cases where a good Design does not require a strong architecture pre-thought but not always the case.

Architecture is NOT Design. Architecture is a process of looking at the entire system from a high level and providing a blueprint of how large scale systems are built.

Architecting a complex product such as a SAAS offering goes beyond just designing. SAAS systems invariably has stringent Non Functional requirements such as Availability (99.99% uptime), Scalability (x Thousand Concurrent users), High Performance response times (X transactions per second), Configurability (Meta data driven configuration), Extensibility (NOT CODE extensibility but product extensibility).

All the above elements have to be well thought of for a successful implementation of a high performance solution such as a SAAS offering.

As the name suggests, these are "NON-FUNCTIONAL REQUIREMENTS". They cannot be "automatically" captured as "User stories". Even if we capture these things as a part of User stories, which sprint do these stories belong to? How do we cater to this in a particular sprint? Should this be pushed to the last sprint? How do you split these requirements within each sprint? Most applications (even enterprise scale) may not worry much about these non-functional requirements. An enterprise application can wait for a half hour down time but a SAAS system, these things are fundamental. A SAAS system is a different game all-together.

There is no doubt that Design and development is key to any software development. But equally important is Architecture. This makes me wonder if there is something called as a 100% pure Agile project? If there is a 100% pure agile project, can this be used to build a SAAS solution with stringent NFRs?

To my mind the answer is NO. The first 10-20% of the time goes in conceptualising and "architecting" the system and then the system can be developed in Sprints (which is rest of the 80%). Architectural Patterns such as Zachman, RM-ODP, Rational Unified Process etc. (or fr that matter any Architectural patterns) wouldn't have existed if it had no use and the same can be done using a Agile methodology by directly jumping into design and development.

I am not sure how this article will be received, but this is just an attempt I thought I should make share my mind to fellow architects in the software world. I do love Agile. Agile is the way to go. There is no doubt about that.

The attempt here is to highlight the fact that - "There is nothing called as 100% agile software development"

Especially if you are thinking of developing a SAAS solution with extremely stringent NFRs, ensure you cover these NFRs within your Architecture and then start development using any Agile methodology.

For an Agile evangelist, a product development life cycle is - Sprint + Spint + Sprint + Sprint.

To my mind it is - Conceptualising & Detailed Architecture + Sprint + Sprint + Sprint + Sprint.

As I have been emphasizing, I am not sure if this arcticle would be well received by Agile Evangelist, but I thought this could be a good food for thought.

I have been involved in building SAAS applications with Stringent NFRs and hence I am able to relate this to agile development.

Await for my next blog on NFRs and its importance in designing a software solution.