Compliance and Security in the Single Instance SaaS cloud vs. Multi-Instance SaaS...

Sorry for the big title... But I wanted to talk about compliance and security in the cloud, drawing particular attention to the differences between large multi-instance SaaS clouds such as Sales Force and smaller single instance offerings. Confused a bit?... Let me explain. There are several different models of SaaS (Software as a Service).

On one side of the spectrum, we have very large multi-tenant offerings like Sales Force where all tenants and all processing is done within one procedural domain and backed by one large ubiquitous database. Data for multiple tenants gets treated side-by-side within the same executable and all tenant data is stored within the same database. In an of itself, this model becomes very efficient from a provisioning stand point when large numbers of tenants are involved, but from a compliance and security stand point, it's a bit of a nightmare. Usually, after a certain threshold is achieved, large SaaS providers will usually deploy their own data centers since it's cheaper to do so than to depend on a third party for processing capabilities. Attacks such as SQL injection or a DoS attack could allow one tenant to gain access to another tenants data or deny timely access to other tenants. Then there is issues such as data remenance (i.e. what happens to the tenants data when the vacate?), data backups, Patriot act data confiscation, etc... In a setting where data for multiple tenants reside side by side, compliance management and risk analysis becomes increasingly complex. The threat exposure is also much greater in such an environment.

On the other side of the spectrum we have what I term 'Single Instance SaaS', where a SaaS provider will stand up a single instance of their offering on a per-tenant basis. Each tenant gets their own separate processing domain and their data gets stored within their own separate database. For early to market offerings, this model is very cost effective and offers a lot of benefits, from a compliance, security and management stand point. This model is very popular with small or medium sized providers who rely on public clouds as the foundation for their provisioning (since it's absolutely too damn expensive to host your own data centers). They only need to provision tenant resources during the on-boarding process and are able to decommission those resources when a tenant vacates. At first, this model is very cost effective (since the provider only provisions resources during tenant onboarding), but once a certain tenant population is reached, the model becomes less cost effective. Issues such as data rememance and data backups are more easily managed and secured under that model. Other issues such as those revolving around the Patriot act are also greatly mitigated since there is much less risk that one tenants data will be confiscated should the DOH or FBI server a warrant on another tenants data. This model also offers both providers and tenants with compliance and security options that would not otherwise be possible in a Sales Force model. This is a model that is very popular with legacy software vendors who are able to 'saassify' their legacy applications (there are even companies such as Parallel who specialize in 'saassifying' legacy applications) and offer them through service portals such as Savvis. I personally see a lot of growth in that model since the majority of software vendors will probably end up hosting their offering in providers such as Savvis.

Dealing With Persistent Threats - A cloudy business (Part III)

In my last blog, I discussed some of the broader aspect of advanced persistent threats and I promised to touch on the subject of these threats when it comes to cloud computing.

When it comes to cloud computing, there are a lot of security fears flying around. Some of these fears are well founded while others are… well… amusing. Some aspects of cloud computing actually offer better protection than a private onsite deployment. For example, physical security within a cloud provider is often much greater than what one might find within a traditional enterprise server room. And IT administrators also receive much greater scrutiny during the vetting process before they ever get hired. In some cases, law enforcement organizations will actually make thorough background checks of prospective employees for cloud providers that deal with government departments.

However, cloud computing also exposes data to vectors of attack that would normally not be encountered within private deployments. Issues such as data remenance (i.e. what happens to a tenant’s data when they vacate), data backup and multi-tenancy now have to be considered, both from a compliance management stand point and from a security stand point. When a tenant leaves a cloud provider, how can they be guaranteed all of their data is destroyed? When the cloud provider makes backups, where are the backups stored?  Are the backups for a tenant all destroyed when they vacate? Then of course, there is the whole patriot act thing where the DOH or the FBI can order cloud providers to hand over data without the tenant’s knowledge.

If you plan on deploying into a public cloud, you need to start looking at encryption products. Not only that, but you need to begin looking at encryption products that give YOU control of the cryptographic keys. Issues such as data remenance, destruction of backups, etc… should be as easy to deal with as simply ‘pulling the keys’. From a compliance stand point, it makes things a lot more manageable and from a security stand point, it drastically reduces a lot of risk vectors. Obviously, encryption does not eliminate all risks, nothing does, but reducing the surface of attack is the best thing anyone can do. Even stuff like data confiscation because of the patriot act is a thing that tenants get to keep control off.

These were some of the core values that drove the development of AFORE’s CloudLink VSA and CloudLink CypherX. We wanted to give tenants control over their data, regardless of where the data was stored/handles.

Dealing with Persistent Threats (Part Deux)

Most security systems currently deployed within organizations focus on access control, malware/virus detection and network edge protection (i.e. firewalls, DLP, etc…). Unfortunately, none of these security systems is very useful when it comes to dealing with Advanced Persistent Threats. Now I’m not saying that everyone should go off and get rid of these mechanisms since they still play a role in securing your IT infrastructure, they just don’t do much when it comes to APTs.

APTs are usually tailor-made attacks, so malware removal and anti-virus software are ill suited to detect them. Some pundits say that DLP will prevent APTs from exfiltrating data, but that’s a silly proposition. DLP is good at preventing accidental leakage of data, but is totally incapable of preventing data leakage through things like encrypted tunnels, or through more exotic mechanisms such as stenography. Most properly crafted APTs will lie low to avoid detection, waiting for the best time to exfiltrate data or even extract small bits of data over a long period of time.

I could drill down on how APTs get into a perimeter, how they propagate, move laterally from one system to the next, etc…, but these are all academic details. The fact is, APTs will get in and will be in a position to exfiltrate data if they can get to it.

And therein lies the key focus when it comes to combatting APTs. The data! Data encryption is the silver bullet of data security. The problem with current data encryption solutions is that if a user has access to encrypted data on a system, then any and all applications are able to access that data. As such, if Microsoft Excel is able to access that spreadsheet, then so can Internet Explorer and so can that piece of malware lurking in your infrastructure.

This is why AFORE Solutions engineered a solution called CypherX. CypherX is a policy driven security solution designed to allow some applications (let’s call them trusted) access to encrypted data while all other applications (let’s call those untrusted) can still open the encrypted files, but only see encrypted data. The more important thing is that CypherX ensures that all data emitted by a trusted application (i.e. via the file system, IPC, network sockets, etc…) is either encrypted on the way out or is only emitted towards another trusted application (i.e. sockets can only be established between trusted applications). As such, sensitive data is forced to stay within the ‘trusted environment’. This is a powerful paradigm. In essence, CypherX elevates applications to the level of securable objects, just like users or machines. As such, unknown applications (including malware, viruses and APTs) can come along and open all these sensitive data files, but because these applications are not seen as trusted, all they see is encrypted data. So let them exfiltrate your totally encrypted data! Hopefully, they’ll chase their tails trying to make sense of the gobbledygook before realizing they got nothing… And the coolest part is, CypherX is totally transparent to both applications and end-users.

In the next part in this series, I want to continue with a quick discussion on cloud-based attack vectors and risks to data when it comes to things like backups (and how APTs might be able to reach those)…

Dealing with Advanced Persistent Threats

So this is the first of several blogs where I want to write on the subject of advanced persistent threats, or APTs for short. Unlike viruses and malware that are spammed at hundreds of millions of users in the hopes that a few of them will get suckered in, APTs are totally different. Wikipedia defines it very well with:

“Advanced persistent threat (APT) usually refers to a group, such as a foreign government, with both the capability and the intent to persistently and effectively target a specific entity”

For the past few years, most targets of APTs have been government and large enterprise, but lately, I’ve come across interesting reports that smaller organizations are being targeted, and that’s an interesting shift in the security landscape. The most interesting case has been of attacks on law firms that specialize in patent law being targeted by foreign interests (starts with a ‘C’ and ends with a ‘hina’) so that intellectual property could be exfiltrated while patents are being authored (i.e. prior to filing). I presume the purpose of this would be to either allow an organization to file a patent before the competition (i.e. beating them to the punch) or to simply publish the intellectual property for all to see, thus establishing ‘prior art’. Either way, I suspect it would give someone a significant competitive advantage.

Unlike regular hacking attacks, APTs are sophisticated multi-vector attacks designed to attack a specific target. The people behind APTs are exceptionally well funded and willing to sustain an attack over a long period of time. In some cases, APTs are designed to achieve a singular hard to achieve goal (i.e. steal that top secret file, acquire this trade secret, etc…), but in many cases, APTs attempt to establish and retain a foothold within an IT infrastructure over an extended period of time, thus allowing the perpetrator of the APT to continuously spy on their target.

The biggest challenge with APT’s lies in the fact that many of them are custom developed. Traditional security systems such as anti-virus and malware removal software as well as perimeter security systems are often useless against such attacks. As one of my co-workers coined the other day, when it comes to APTs, most security solutions out there are not unlike ‘closing the gates after the cows have escaped’… As this is absolutely true. Organizations should accept that they will get breached (or have already been breached) by APTs.

In part 2 of this blog, I want to continue this blog by discussion what is actually effective against APTs. So stay tuned!!!