This week, Websense published its State of Internet Security report for the first half of the year.  Here are some things to take away from it:

Legit Sites with Malicious Code – Most of the sites that contain malicious code are legitimate and have been compromised.  This number went up 50 percent over the past six months.  The growing popularity of sites with user-contributed content is opening holes in areas of the Web that people consider trustworthy.  Sixty percent of the top 100 sites have been involved in some kind of malicious activity this year.

“Blended Threats” Increase – Continually increasing amounts of e-mails contain a link to a spam site or a site with malicious code.  “Storm” attacks are making it more difficult to create anti-virus solutions because of their use of a mixture of attack vectors.

More Shopping Spam – Shopping has overtaken pornography as the category of spam you are most likely to see.  This could be caused by spammers using information gathered from social networking sites to tailor their messages to the victim’s interests.

Websense summarizes by predicting that reputation-based site filtering will become less effective as hackers continue to focus on attacking legitimate sites through their Web 2.0 security holes.  They also advise companies to take a more data-centric approach to security in order to protect against blended attacks which can circumvent defenses that only focus on one technology.

Today we are proud to present an update to the Security Musings site.  We’ve moved to WordPress, and made the look and feel very similar to the main Gemini Security Solutions site.  We have also started using FeedBurner to manage our feeds, allowing you to subscribe to Security Musings by email.  Please let us know if you notice any problems with the new site by leaving a comment below.  Enjoy!

Cisco unveiled a blueprint to address Payment Card Industry data security for the healthcare industry.

The blueprint is intended to provide healthcare organizations with a model for safeguarding patient financial transaction data and other personally identifiable information that is captured and processed within a healthcare facility or retail pharmacies. Called PCI for Healthcare Solution, it offers design and implementation guidelines to protect credit card, patient demographic and employee information.

Stats collected by Cisco are showing that external data security related attacks on the healthcare industry have increased 85% between January 2007 and January 2008. One in four healthcare executives do not know where their sensitive data is located, the vendor says. Also, many organizations do not have a security framework in place to provide optimal protection.

I like this idea because it shows a strong cross reference between two completely different types of industry (retail / healthcare). It shows that standards and practices that have already proven to help secure and improve industry trust, can be carried over into other forms of industry. The healthcare industry is already heavily flooded with many standards of it’s own that one would think there wasn’t anymore room to grow. But something like this, if implemented correctly could be a helpful hand in an over saturated area.

Many people will claim that the “openness” of open source software helps make it secure. With an entire community given access to all of the code, it makes sense that programming errors or security issues would be recognized often. And thanks to tools like Findbugs, many issues are found and fixed before, during, and after a product is released. Products that rely on security through obscurity or snake oil solutions generally fail to hold up in an open source environment… but I think this can be a double edged sword.

With the common perception of open source software as being “more secure” than their closed source counterparts, there also exists the possibility for people (and companies) to place too much faith in them.

According to this study (pdf) done by Fortify (which examined a number of OSS applications for potential security vulnerabilities):

...serious security threats stemming from numerous application vulnerabilities are a direct result of poor or nonexistent security processes. This follow-up survey found that security best practices are a low priority to the open source projects surveyed/community. Yet open source packages often claim enterprise-class capabilities but are not adopting — or even considering — industry best security practices.

Although some bias exists in the report (they only examined Java applications which they used to make some fairly broad generalizations), the data holds a lot of significance. As more and more companies embrace OSS as a component in their software solutions, they must be careful not to also embrace the perception of inherent security. Secure software depends on a lot more than the openness of its source code.

I recently came across a paper by Atul Prakash Analyzing Websites for User-Visible Security Design Flaws which discusses some findings in a recent survey of 214 financial institutions conducted in 2006. The origin of the study came about when Prakash notices many of the below listed flaws in his own financial institutions websites.

The top design flaws that Prakash and his team were looking for were:

• Placing secure login boxes on insecure pages: A full 47 percent of banks were guilty of this. A hacker could reroute data entered in the boxes or create a spoof copy of the page to harvest information. In a wireless situation, it’s possible to conduct this man-in-the-middle attack without changing the bank URL for the user, so even a vigilant customer could fall victim. To solve this problem, banks should use the standard “secure socket layer” (SSL) protocol on pages that ask for sensitive information, Prakash says. (SSL-protected pages begin with https rather than http.) Most banks use SSL technology for some of their pages, but only a minority secure all their pages this way.

• Putting contact information and security advice on insecure pages: At 55 percent, this was the flaw with the most offenders. An attacker could change an address or phone number and set up his own call center to gather private data from customers who need help. Banks tend to be less cautious with information that’s easy to find elsewhere, Prakash says. But customers trust that the information on the bank’s site is correct. This problem could be solved by securing these pages with the standard SSL protocol.

• Having a breach in the chain of trust: When the bank redirects customers to a site outside the bank’s domain for certain transactions without warning, it has failed to maintain a context for good security decisions, Prakash says. He found this problem in 30 percent of the banks surveyed. Often the look of the site changes, as well as URL and it’s hard for the user to know whether to trust this new site. The solution, Prakash says, is to warn users they’ll be moving off the bank’s site to a trusted new site. Or the bank could house all of its pages on the same server. This problem often arises when banks outsource some security functions.

• Allowing inadequate user IDs and passwords: Researchers looked for sites that use social security numbers or e-mail addresses as user ids. While this information is easy for customers to remember, it’s also easy to guess or find out. Researchers also looked for sites that didn’t state a policy on passwords or that allowed weak passwords. Twenty-eight percent of sites surveyed had one of these flaws.

• E-mailing security-sensitive information insecurely: The e-mail data path is generally not secure, Prakash says, yet 31 percent of bank Web sites had this flaw. These banks offered to e-mail passwords or statements. In the case of statements, users often weren’t told whether they would receive a link, the actual statement, or a notification that the statement was available. A notification isn’t a problem, but e-mailing a password, a link or a statement, isn’t a good idea, Prakash says.

One of the focuses is the fact that these flaws aren’t exactly bugs, but actual flaws in the designs. Many can be remedied, but these are the kinds of things that should have been considered in the design phase.

It only goes to show that planning is as important as implementation.

Many of you may have heard of the massive DNS patch release coordinated by Dan Kaminsky. What you may have also heard is that the details of the vulnerability and the patch would be released at Black Hat this year (two weeks from now).

This has been one of the few patch releases that had such widespread secrecy around it. Very few people knew about the patch until Windows (and OS X and Linux) asked them to update. Now that the patch is released, the code can be viewed, and compared to the old code and people can figure out what the problem is. It took a while, but several people have done just that.

There are some generally accepted “rules” to vulnerability disclosure that most security researchers follow, and agree not to disclose the vulnerability before a patch is released. However, the patch was released well before the vulnerability was disclosed (if not by the initial researcher). With the patch out there, smart people are going to be looking at it to see why things were patched. BIND, an open source DNS server was affected, and so the code is freely available. It was only a matter of time before someone (with more time than me) read the code to see what changed and what was wrong.

Reverse-engineering patches is more difficult, but not impossible, when you don’t have the source code, so it’s not reasonable to expect people to keep quiet.

In this particular case, there were a lot of politics going on about disclosure and giving a talk at Black Hat, but the fact remains the same, once the patch is released, the cat’s out of the bag, and it’ll be pretty hard to get back in.

Over seventy-five percent of banking web sites examined by researchers at the University of Michigan were found to have design flaws that make it easier for identity thieves to trick customers.

The researchers found that many banks silently redirect users to third-party sites, plop “secure login” boxes on insecure Web pages, and improperly use Social Security numbers or e-mail addresses — which an outsider can figure out — as default user names.

Practices like these can make it harder for the user to notice when they have been directed to a phishing site. Even more careful users might tire of checking to see if the login box posts to a secure site. Then, phishers have a better chance of catching someone off guard as opposed to sites that keep customers on their toes.

I suggest going with a bank whose online banking makes it easy to check for authenticity. You should be able to tell by looking at your address bar or status bar if the site is secure. You should be able to easily check the details of the server’s certificate. You should not have to dig for this information.

Also, be careful about trusting a site because of information it might present to you. Having your SSN show up in the User ID box or presenting an image to you that you previously selected are not terribly impressive feats. Use them as reminders to double-check the site’s authenticity.

I’ve always been a bit skeptical about single sign-on solutions, especially when they are the only thing standing between a would-be attacker and their goal. To me, the idea of a single sign-on solution linking a user to multiple subsystems represents a dangerous risk. A compromise at one point would propagate to other systems instantaneously. However, that doesn’t stop people from relying on them.

For example :

Winchester and Eastleigh Healthcare NHS Trust has deployed a single sign-on solution from Evidian to simplify access to key hospital applications, enabling 2,500 staff to better focus on the delivery of essential frontline healthcare services.
...
With 1,700 clinicians at the Trust requiring access to up to 14 different healthcare applications on a day-to-day basis to carry out key services, the Enterprise SSO solution from leader in identity and access management Evidian enables clinicians to use all web-based services with a single user log-in and password.

A single sign-on solution for a hospital or clinic may certainly make things easier for staff— potentially decreasing mistakes and allowing things to flow more smoothly. However, the idea that one person’s password holds so much power is disturbing. I think perhaps it may be best to find some way to compromise. The inherent risk of a single sing-on solution can’t necessarily be overcome— accounts are linked, so access to one means access to all. However, I do believe the risk can be reduced through other methods. A multi-factor authentication system could help harden a single sign-on system like this. Especially when the private data of patients might be at stake.

Making things more convenient doesn’t always mean making them less secure.

In my last article [link] I outlined a few of the hardships we are facing with the constant uprising of technology and how it’s affecting our privacy and security. Hopefully I can shed some light on it, and reassure you that not all hope is lost.

Previously I talked a lot about how technology is making it easier for us to obtain information. This really only applies when the proper measures aren’t taken to protect that data. I mentioned how it’s only a matter of time before cryptographic keys can be broken. Well the real question isn’t how secure do you want your data to be, but how secure do you need it to be for what length of time? With RSA 1024 you’re still looking at a good 5-10 years before even the simplest of keys can be brute forced. Even longer before it’s a main stream breakthrough. Nothing is ever going to be 100% secure, this is a fact, but usually we only really ever need to secure things for a extended amount of time.

Those areas where human error come into play. We are starting to build an arsenal of tools and methodologies to help us automate and reduce the risk of mistakes. Whether it be a coding framework, more strict policies, with harsh penalties for those who don’t cohere to them. We really are trying, and I think we are making a good stand. The goal isn’t to lock down everything, but simply protect it long enough that those who are trying to get it give up.

When it comes to personal privacy, it really comes down to training the users/individuals. It’s a new world, you wouldn’t go leaving your wallet full of cash lying around anywhere would you, you keep it protected. The same goes for protecting your identity or credit information. Clean up after yourself if you use public computers. Secure your wireless. Don’t give out personal information. Be smart about it, and you’ll continue to stay on top.

We have a fighting chance, no one said it would be easy, but don’t go getting paranoid either. There are people looking out for you too.

If you haven’t heard of OpenID, I suggest you create a livejournal account, and start seeing where you can log into with your live journal credentials. You can also go read more about it at openid.net. The basic premise is a distributed authentication system that allows a user to select their authentication provider when they log into various web sites. The hitch is that you and the site you’re wanting to log into have to use a mutually agreeable authentication provider.

When OpenID was first announced, it touted that you could run your own OpenID server, and then you’d never have to give your password to the site you’re logging into, only the site (which you trust) that you’re authenticating to. That completely runs afoul of the whole “mutually agreeable” authentication provider. If the site you’re logging into doesn’t trust your OpenID provider, you’re never going to be able to use it to authenticate. Most of us have moved past this point, and expect that we’ll be using major OpenID providers rather than our own, but the protocol still allows it, and it can be used among friends.

One of the huge benefits of OpenID is that each OpenID provider can authenticate their users in whatever way they want – password, two-factor, etc. But the relying party still gets to choose what authentication level they’ll trust (and so far, the only models I’ve seen are password based).

So, why will OpenID succeed? Once people realize that they can log into sites that may look sketchy without having to give their passwords directly to that site, they may start visiting smaller sites that just don’t have the security that the larger sites do. This gives a huge boost to those smaller companies by bringing in more consumers.