I recently presented at CBI’s 3rd Summit on Clinical Trial Investigator Portals in Philadelphia. The event drew an array of members from the pharmaceutical, biotech and CRO industries to discuss and share strategies for using portals to share clinical research information.

While there were sponsors and CROs at the conference who were just beginning to test the portal waters, a significant number had already made sizable investments into home grown portals. Now on their first, second or next generation portal, many have realized they were focused on their own needs and not necessarily on those of the end users. The conference gave attendees an ideal opportunity to explore the perspective of the clinical investigator—beyond gathering their feedback, but actually using their insights to incorporate into their clinical portal plans.

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.

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.

I recently read an interesting article on Computerworld.com by Michael Scalisi called "The Art of Creating Strong Passwords." It discussed how to create secure passwords but took an approach that didn't necessarily reflect best practices. I filed this away until I came across the same article at Threatpost and realized something needed to be said. The "artsy" approach to password security this piece suggests, combined with Microsoft's infamous password checker, misinforms the public on what constitutes a secure password and how they should be created. These suggestions can quickly go from uninformative to plain harmful. In other words: An "artsy" approach suggests using emotions rather than logic. This is hardly a good strategy for information security.