A Reuters blog today likened social networking to Jurassic Park. While this is probably the first time anybody has connected dinosaur-related themes to Web 3.0 technologies like social networking, in this case it was probably accurate.

The premise of the note was that social media sites are like Michael Crichton’s fictional dinosaur park—really, really cool technology, but not much in the way of security and safety precautions. This is a problem that cannot be ignored any longer. Like the elephant in the room—or in this case, the tyrannosaurus in the room—it’s too big to look the other way, and it’s not going away any time soon. Social media is here to stay, and with something on the order of a third of Internet users taking advantage of it, security managers have to get on with the business of creating a workable policy.

Why should businesses be concerned about social networking sites? It is after all, something that people play with on their own time (or at least, should play with on their own time), and doesn’t really have anything to do with the business. Or does it? The fact is, social networking is no longer just social. There are two factors at work here that warrant attention. First, on the other side of the office, mostly unbeknownst to the IT and security people, the marketing department is making very good use of social networking as a corporate marketing and communications tool. Companies use Twitter to keep customers and partners apprised of new releases, updates, special promotions and other information. They use LinkedIn to meeting other people interested in making deals, and they even use Facebook to make corporate pages meant to drive traffic to the main site. Most corporations now also have blogs, and even interactive forums where customers can participate in discussions with company staff and other customers. Yes, all those things were originally designed “just for fun,” and the creators of these social tools very likely had no idea that their creations would wind up in so many corporate toolboxes. Yet, here they are. Continue reading Social media security problems

A security advisory issued this week highlighted a serious code execution vulnerability in Mozilla Firefox 3.6. The vulnerability, according to the advisory, is caused by an “unspecified error,” and can be exploited to execute arbitrary code that could be malicious and harmful. The exploit was originally highlighted by Russian security firm Intevydis.

There has been very little reported on the vulnerability to date, with some even suggesting that it is a “hoax.” Don’t believe the hoax suggestion, no matter how big a fan of Firefox you may be—in the security business, things need to be taken seriously. Not doing so is inherently dangerous. That said, there is very little data on how widely circulated the exploit has become, although some sources report an increase in the number of Firefox 3.6 crashes on February 12 and 13.

On the Mozilla blog, Mozilla does not confirm the vulnerability at this point for lack of details on how to reproduce it, but does make a point of saying, “Mozilla takes all reports of security vulnerabilities seriously,” as well they, or any other software organization, should.

The advisory brings up an important issue, which is that even when using the latest version of software and the most recent patches, security is not always bulletproof. Applying patches as they are available, preferably on an automated basis, is always good practice, and it does go a long way towards reducing the incidence of preventable attacks. However, patch management alone isn’t going to keep your systems safe. In fact, in one forum where the vulnerability is being discussed, it is noted that the “Insecure” tab—which is a cool feature, by the way—only shows programs that have patchable exploits. The Firefox exploit has not yet been addressed with a patch from Mozilla, so it isn’t shown there as being insecure.

As such, it’s a classic zero-day exploit, which is a vulnerability that is able to do its dirty work between the time it is discovered and the time when it is patched. At this point, users of Firefox should proceed with caution, and as always with any browser, take standard precautions, avoid opening up unknown or suspicious URLs, use pop-up blockers, and monitor traffic accordingly.

I have faith that readers of this blog have enough good sense not to use social networking sites to send important emails. However, some of your users may lack that good sense, and so it behooves us all to send out a common sense reminder every now and then—only use your official corporate email for anything important or sensitive! Save the Facebook email messages for updates about parties, casual observations, and idle gossip.

Wall Street Journal reporter Zach Seward got to have a glimpse of some of that idle gossip last week after Facebook made a major blunder, and some people received emails from complete strangers that were meant for somebody else. Seward gives us a glimpse of what goes on in Facebook with a few unnamed excerpts. The editor became privy to love triangles, petty jealousies, teenage parties and other truly fascinating but private missives.

The glitch was caught shortly after it started and was resolved, but not before several emails were incorrectly routed. Although there is no data being released as to how many users were affected, Facebook noted that “During our regular code push early Wednesday evening, a bug caused some misrouting to a small number of users for a short period of time.”

There have been other security blunders in the past, including a glitch in March 2008 that made it possible to publicly view photos that had been marked as private.

A report on the Wall Street Journal details the experience of a Journal editor who received several of the errant messages. According to the report, the editor received over 100 messages, ranging from ordinary to explicit.

Facebook recently redesigned its inbox interface to make it resemble Gmail.

Gmail has always had an encryption option, but until this week, it has been turned off by default. Now IT people, who tend to be a bit paranoid (but in a good way), would have gone through the trouble to switch on the SSL encryption option, but most ordinary users would simply not be aware that it exists. And for that matter, all those paranoid IT people probably wouldn’t have even used Gmail to begin with.

Google announced last week that it would start encrypting all Gmail traffic. In a blog post, Google noted that they initially rolled out the option to always use https back in 2008. This allows email to be encrypted on the path between the user’s web browser and Google servers. However, when Google first enabled the option, it was off by default. Now, SSL will be used by default, with users gaining the option of selecting “Don’t always use https” from the Settings menu. Some may choose to not enable the extra security option for performance reasons, but in reality, the performance hit will be minor, especially for broadband users—and well worth the extra couple of milliseconds. The login page will still remain encrypted. Using encrypted email can stop several types of attacks, such as man-in-the-middle attacks where an attacker may be snooping email in a public WiFi spot. Using encryption also prevents attacks such as DNS poisoning attacks where a domain name record is hijacked and redirected.

Google decided to make the upgrade just hours after they revealed information about having been victimized by specialized attacks, including certain attacks on Chinese human rights activists’ accounts. Users are cautioned however, not to get lulled into a false sense of security, thinking that turning on Gmail’s encryption option is going to prevent all potential attacks—because it certainly won’t. The same anti-virus, anti-spam and anti-malware software installations should continue in full force, regardless of any added encryption.

With Google making the switch, the next big question is whether the other main free email services like Hotmail or Yahoo! Mail will follow suit; my guess is that they will.

The increasing popularity of in-the-cloud email delivery and email security solutions, and the wealth of innovations available, raises the discussion of whether email administrators should consider cloud-based solutions. While the free, Web-based email remains out of the question for corporate use, some other cloud solutions that offer more robustness and security may be appropriate for some users.

Security is always imposed in cloud-based systems to one degree or another, but a major limitation is that many cloud providers still implement their own proprietary security approaches. While such an approach may well impose good security, this has still limited the uptake of cloud-based models. A more appropriate approach to cloud-based security would be the adoption of a common security model, made available through the cloud platform-as-a-service.

As outlined in “Cloud computing made easy,” co-authored by yours truly, a cloud platform (as opposed to cloud “software as a service” applications) imposes common software elements, which are used by developers to write cloud applications without having to re-invent the wheel for every aspect of each application. The use of a cloud platform is particularly useful for imposing rigorous security, in that it presents a standard security model for managing things like authentication and authorization, role-based access, secure storage, multi-tenancy, and privacy policies. Developers of common SaaS applications may not always be experts in security, but by using the common security model of a cloud platform, the developer is able to draw against the expertise of other developers who are. Continue reading Security and the cloud

A social application site called RockYou suffered an attack that resulted in 32 million usernames and passwords being exposed. And to make a serious problem even worse, the company, which TechCrunch says “has a history of stupidity”, didn’t inform its users until ten days after the fact.

Techcrunch reported on the issue, and RockYou’s statement to the IT blog noted that “On December 4, RockYou’s IT team was alerted that the user database on RockYou.com had been compromised, potentially revealing some personal identification data for approximately 30M registered users on RockYou.com. RockYou immediately brought down the site and kept it down until a security patch was in place. RockYou confirms that no application accounts on Facebook were impacted by this hack and that most of the accounts affected were for earlier applications (including slideshow, glitter text, fun notes) that are no longer formally supported by the company. RockYou has secured the site and is in the process of informing all registered users that the hack took place.”

According to reports, the site had an SQL injection flaw. This type of flaw is quite common, and targets the application’s database layer.

The problem was especially serious because RockYou usernames and passwords are the same as customer email names and passwords, and access to the database could open the door to a flood of spam, not to mention identity theft resulting from breaking into customers’ email accounts.

One hacker did gain access to the full list of unencrypted passwords, which had been stored in plain text, and posted some of it publicly. In true vigilante fashion, the hacker posted part of the file, with the note, “Don’t lie to your customers, or I will publish everything.”

RockYou made two critical mistakes, one in policy and one in technology. The policy mistake was to keep silent on the issue until ten days after the fact. Now, they are dealing with the public relations nightmare of their decision to not act right away in informing their customers. The second mistake was one of technology, and that is storing usernames and passwords in plain text. Storing this in plain text was a disaster waiting to happen, and the company should have known that. It’s not that hard to protect username lists, and simply encrypting the file would have prevented much of the negative fallout the company is now seeing in the press.

The issue of “ethical malware” has raised its ugly head this week in the blogosphere, sparking heated discussions and soapbox speeches everywhere. As reported this week in LinuxInsider, a lengthy Slashdot discussion was sparked when a participant wrote, “I was fed up with the general consensus that Linux is oh-so-secure and has no malware. After a week of work, I finished a package of malware for Unix/Linux. Its whole purpose is to help white-hat hackers point out that a Linux system can be turned into a botnet client by simply downloading BOINC and attaching it to a user account to help scientific projects.”

The writer, Johannes, is of course correct. Unix/Linux can indeed be vulnerable to malware. We must remember that absolutely no operating system is completely bulletproof. We may like its features, it may have good security, and the OS may be perceived as being “cool”, but it’s not magic. Like any other OS, it’s just lines of code. Armchair computer users that aren’t in the industry may have the incorrect notion of absolute security, but nobody in the business can seriously make that claim with a straight face.

The larger question that is raging on the Slashdot discussion thread is whether Johannes was within his rights to release malware on Linux for the purpose of illustrating his point.

Most people would agree that malware is a scourge on society, and in most cases is illegal. But, Johannes’ malware wasn’t malicious, so was he within the scope of ethical computing to release it? On one hand, the logic is indisputable that by releasing the malware, he was able to highlight a flaw in the OS. And especially when an OS is written the way Linux is written, it’s very likely that any flaw that is brought to public knowledge will be repaired soon enough.

On the other hand, there is naturally a window of vulnerability between when the flaw is made public, and the flaw is fixed, giving the real evil-doers a short but realistic opportunity to exploit it. Would we think it okay for example, if somebody broke into a bank vault one evening, but didn’t take the money, just to show the bank that it could be done? I don’t think there would be any debate about it, the perpetrator would go straight to prison. “White-hat” hacking of this nature may have good intentions, but the writer is taking a risk here that an aggressive prosecutor may decide to pursue the matter in court.

The European Network and Information Security Agency (ENISA) has issued one of the most comprehensive reports on the security risks and benefits of cloud computing. The report takes an impartial look at the cloud phenomena, and it starts out with the obvious—that is, cloud computing’s benefits of ease of access, scalability, instant provisioning and monetary savings are undisputable, but the biggest issue holding people back is the security concern.

In many cases, the concern over security is one of perception. We tend to think that things are more secure if we can put our hands on it. But the ENISA paper gets into more specific detail about precisely what the top security risks are:

1. Loss of governance. The biggest and most common concern, ceding control to a cloud provider may create a vulnerability if security isn’t specifically addressed in the service level agreement.
2. Lock-in. A lack of standardization and portability means that it may be difficult to switch cloud providers, or bring service back in-house.
3. Isolation failure. Because it is based on multi-tenancy, the cloud may be vulnerable to guest-hopping attacks or attacks on the cloud’s isolation mechanisms.
4. Compliance risks. The cloud provider may not be able to provide evidence of compliance with regulations to which the customer must comply.
5. Management interface compromise. There may be an increased risk of exposure through the customer management interface.
6. Data protection. The customer may not be able to verify the provider’s data handling processes.
7. Insecure or incomplete data deletion. What happens when you request that your resources be deleted? A true “wipe” of data may not take place, and reuse of resources may pose some risk of deleted information being detected later by another party.
8. Malicious insider. Insider attacks are always a risk, whether on-premise or in a cloud provider.

But it’s not all downside, either, and the report lists several security benefits as well. Most importantly, there’s the obvious differential that exists between what a small business knows it should do, and what it has actually gotten around to doing when it comes to on-premises security. Smaller businesses in particular which may lack in-house expertise and may be short on time or funds often don’t have the best security, and it is often out of date. In such a case, the cloud may present a big security advantage, since the cloud provider is more likely to have security expertise and the staff to implement it. In the case of the cloud provider, it’s a matter of scale. A top of the line security investment at the cloud center is paid for ultimately by distributing the cost between hundreds of customers, which makes it possible to get better protection for all parties.

US-CERT has issued a vulnerability note that should worry anybody who relies on SSL VPN products to establish secure web sessions. SSL VPN is a very common method of establishing a secure connection between two remote sites over an Internet connection, where the user connects only through a standard web browser, without the need for any client software. It’s gained popularity because of its simplicity, and because of its clientless nature, it allows for easy, anywhere connectivity. It is commonly used in Internet commerce, and sometimes in cloud-based or remote email.

According to CERT though, many of the commercially available SSL VPN products bypass the security that exists in the web browser, and this could create a security problem. The problem revolves around the “same origin” policy enforced by standard web browsers, which enforce a rule that prohibits active content from accessing data from an external site. However, some of the SSL VPN products do take content from multiple sites, then present it as coming from the SSL VPN by rewriting the URLs that come from the VPN. It would be possible for example, for an attacker to lure a user to a rogue web page, gain access to the VPN session token, and alter content. It would be possible for such an attacker to, for example, use that malicious web page to launch an attack that could capture keystrokes from remote users.

The vulnerability is mostly theoretical, and whether you are vulnerable really depends on how you’ve configured your SSL VPN. It’s important not to take the SSL VPN warning as an indication that you shouldn’t use SSL VPN–such an indication would be unnecessary, and would have a dramatic impact on e-commerce as we know it.

According to CERT, there is no immediate solution to the problem, but there are three workaround solutions: (1) Limit URL rewriting to trusted domains, (2) limit VPN server network connectivity to trusted domains, and (3) disable URL hiding features. In limiting URL rewriting to trusted domains, most firewalls will allow policy rules to be set  to accommodate this neeed, so the VPN can only access specific domains.

The Wall Street Journal carried an article last week on the US court’s shifting position on whether or not it’s okay for a company to read employee email. Most companies tend to take the position that whatever goes on within the corporate walls–or even within its virtual walls–is company property, and the actual keystrokes that take place on company property are fair game for snooping. However, that’s not always the case.

First of all, let’s take a look at why a company would be snooping on employee email. Are they worried about gossip? Or are they just nosy? In fact, the reasons revolve mostly around concerns of security leaks, and information leaks. Security leaks may occur if an employee is using their personal email account from a work computer. Information leaks can occur from anywhere–and this just involves a company employee emailing sensitive information that they ought not be sending to anyone. If you’re using your email account to send the Colonel’s secret recipe, or some such trade secret to the competition, then the company would like to know about it. Some employers take this very seriously, and use software to check all outgoing emails for sensitive information. Some 38 percent of companies analyze the contents of outgoing mail for these purposes.

The question is, are you allowed to do that? Courts, which in the past were more sympathetic to the employer, are now starting to weigh in favor of employees. The legalities of it get a little hairy, but the basics of it are that it is necessary to describe to every employee, in very specific terms, what the expectations are in regards to employee email privacy. The Journal article cites a particular case where an appeals court ruled that an employee had a “reasonable expectation” of privacy when they sent out an email using their personal account. To quote the article, courts are now finding that “unless they (the employers) have explicitly told the employee they will monitor email, they don’t have the legal rigth to do it–even if the email in question was a personal one sent using a work account, rather than a personal address.”

The bottom line is that if your company policy is to read, either by human or software means, employee emails, you need to make sure that every employee had been explicitly informed of that policy. Of course, telling someone you’re going to snoop on them kind of takes the wind out of your sails, but can still be a good preventive measure regardless.