There has been some media coverage over recent weeks about complaints filed against a cloud-based backup provider. The complaints allege that the company misrepresented their security features, primarily their lack of encryption.

Encryption should be a basic essential in providing a secure cloud-based service. This, therefore, seems like an appropriate time to share my thoughts on how businesses and consumers can recognize the proper implementation of encryption, giving them greater peace of mind as they finalize their choice of a cloud service provider.

As many people know from reading the news over the last month, Epsilon, a permission-based email marketing provider, suffered a major security breach. Their clients’ customer data was exposed as a result of an unauthorized entry into Epsilon’s email system. Their customers include big brand names such as Target, Red Roof Inn, Best Buy, Chase, Marriott and Brookstone.

It’s safe to assume the people that launched this attack on Epsilon are no script kiddies that accidentally hit the jackpot. The recent breaches at Epsilon as well as RSA have proven that there are individuals or groups out there that are willing to commit significant resources to hacking and anticipate a decent return on their investment. The Epsilon breach is essentially part of a criminal business model that simplifies the attackers’ task in crafting e-mails targeted to specific people. Sadly, we can only expect that these so-called spear-phishing attempts will soar.

The primary challenge around adding two-factor authentication to online applications is that it is difficult to bolt-on anything to an existing product. The problem is usually unrelated to the security technology but is down to inherent problems with the web applications. Most are not designed with security in mind.

Traditionally, if access control was important, some kind of login functionality would have been added to the application. This has been the way since the early days of client-server model. Unfortunately not a lot has changed since then. Even the most cutting edge web applications are designed as a castle with a reinforced perimeter and a heavily guarded entrance in the form of the login page. Once in, all users will have access to everything they are authorized to.

Last year, I wrote about the IntraLinks vision for using enhanced two-factor authentication (2FA) to protect data in a SaaS-based environment. What I covered in that blog was used as a basis for designing a customized 2FA (or strong authentication) framework for the IntraLinks platform. The most important feature of the framework is the adaptability it offers to users for their security policy requirements. The idea is that people who own the data are more likely to understand its sensitivity and level of protection required than the people who design systems. On the other hand, system designers have the necessary technical skills to implement robust protection mechanisms. Our framework allows for the optimal ‘separation of duties’ — we implement the best of breed 2FA mechanisms, and our users apply those where and when they think it makes sense.

In light of the upcoming “capture-the-flag type” type contest at DEF CON, this is as good a time as any to talk about social engineering. There is no technical solution to this issue. Humans cannot be patched (I am paraphrasing from a t-shirt that I saw at a conference). So, we need to help people recognize a scam when they see one.

In a CSO Online article they talk about the favorite ‘pick-up’ lines of social engineers. These and some stories shared by the publication’s readers are pretty instructive, so I will mention a few of them here for everybody’s benefit.