It was recently announced that Electronic Health Records (EHR) are in use in all military hospitals. Granted the article is mostly marketing screed for one company, but it still represents a big step. Outside of the Department of Defense (DoD), this probably doesn’t seem like a very big deal. Inside the DoD, it’s HUGE. This is the culmination of years of work and millions, possibly billions, of dollars spent. It’s an important step in improving the health care for Wounded Warriors.

It also sets the stage for wider adoption of EHR in the private sector. But there are reasons to be concerned about this, of course. There are few, if any, pieces of information more intrinsically private and personal than one’s medical records. And while making these records available in an electronic format offers great advantage in medical care, it opens up great risk of compromise.

(more…)

This week’s questionable security breach reporting comes courtesy of the Daily Mail, regarding the compromise of accounts on Citigroup’s web site: http://www.dailymail.co.uk/news/article-2003393/How-Citigroup-hackers-broke-door-using-banks-website.html

The “attack” (if you can really call it that), required a logged in user to simply modify the URL of an authenticated session to change a plaintext URL parameter containing their account number to another account number. That was all that was required – no coding, phishing, social engineering or other technique that requires any thought was needed. Anyone with a rudimentary understanding of how URL parameters work could have figured this out. I’m amazed nobody figured it out sooner.

What bothers me about the article, though, is that the “expert” and law enforcement representatives who are quoted make it sound like this was a sophisticated intrusion.

One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser.
He said: ‘It would have been hard to prepare for this type of vulnerability.’
…
Law enforcement officials said the expertise behind the attack was a ‘sign of what is likely to be a wave of more and more sophisticated breaches’ by high-tech thieves.

(Emphasis added)

Nothing about changing a plaintext URL parameter requires expertise, and it would have been trivial to prepare for that kind of vulnerability. It’s nigh unbelievable that a financial institution would have such a bad security implementation, although if this is the state of expertise in this field, I suppose I shouldn’t be as surprised as I am.

Recently I had the chance to test out a clever little device called the hiddn Crypto Adapter. Made by Norway-based High Density Devices, the adapter looks somewhat like a miniature desk calculator with a USB port instead of a display, but its simple appearance belies some powerful functionality: transparent, real-time encryption of USB drives with two-factor authentication.

The adapter essentially acts as a proxy between your computer and a USB drive, meaning it needs no software, has no operating system requirement, and works with everything from a flash memory stick to an external hard drive. All communication with the USB device is encrypted on the fly using 256-bit AES via a certified FIPS 140-2 Level 3 crypto module, but the key isn’t stored on the drive: at the front of the hiddn adapter is a smart card slot.

When you insert a smart card, you have to enter the corresponding PIN code to use it. (After three unsuccessful attempts, the card becomes locked until a longer PUK code is given.) The device does not appear as an active USB device in the OS until a card is verified, and becomes “unplugged” when the card is removed. The encryption key (or half of it in split-key mode) stays on the smart card, making an encrypted drive unusable without it.

Setting up and operating the hiddn system is very straightforward. You connect it to your computer with a USB cable, plug a drive into the top USB port, insert your smart card, and then enter your PIN. From there, the experience is no different than using a USB drive normally – there’s not even a difference in speed.

When I first connected an unencrypted drive on a Windows machine, it appeared as an unformatted drive. After formatting, it behaved just as it would when plugged in directly. (A few times I had to reconnect the adapter to get Windows to recognize a new drive if I didn’t “eject” the drive first or tried a bad PIN, but those were minor issues.) Trying to use the drive without the hiddn adapter after it had been encrypted brought up another prompt to format – Windows could tell there was a volume, but it was completely unreadable.

After using the hiddn Crypto Adapter for a short time, I started wondering why no one else had thought of it before – or at least why I’d never heard of it before. It’s a great tool for anyone wanting a no-hassle method to encrypt removable storage. The only potential drawback is pricing; two adapters and two sets of pre-configured smart cards can run almost $900. High Density Devices offers a few different packages of units and cards, ranging from one of each to ten, as well as an enterprise key management system for creating new cards. But while some users may find hiddn too expensive for personal use, its flexibility, ease-of-use, and high security make for a combination that’s hard to beat.

A vulnerability demonstration this week involving a technology that’s generating buzz reminded me of an important concept: Security is as much about implementation as the underlying technologies you use. You can put together several “secure” components and still build an insecure system.

The example that reminded me of this relates to Bitcoin, a somewhat controversial form of digital currency that’s recently been discussed by several high-profile media outlets. I’m not going to talk about any specific merits or problems associated with Bitcoin, but note that it relies on mathematically solid encryption schemes to allow transactions while preventing theft.

However, regardless of how strong your encryption, an insecure application using that encryption can introduce easily exploitable vulnerabilities. And Adam Baldwin of evilpacket has shown how this can happen with Bitcoin by creating a video demo of XSS/CSRF problems in a Bitcoin exchange site. These application-level issues could enable an attacker to steal Bitcoins without cracking the basic cryptography employed.

Using proven security technologies is important, but it’s only one part of securing your organization. I still remember my surprise when I first discovered that an “unbreakable” cipher did exist: the one-time pad. But using one-time pads is often impractical, and they are still susceptible to compromise from human factors. Building secure business operations requires understanding the risks at each level of a system and having a defense-in-depth response.

At Gemini, we can help you assess those risks, architect strategies to handle them, then apply those solutions in your organization to produce measurable security improvements. Don’t simply trust in “encryption” or WAFs to protect your data – let us help you understand the big picture of your company’s security today.

I recall back in the 80s, when “computer virus” was a new term, “antivirus software” hadn’t been invented yet, nobody had coined the term “malware”, and Apple was still running incomprehensible TV ads.

It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner.

To be honest, I find the iPad more disturbing. An increased awareness of mobile OSes in the black hat community can only mean more malware for those platforms. Various experts have been predicting widespread malware in mobile devices like phones and tablets for some time now. With the release of Weyland-Yutani BOT, we’re that much closer. The exact development cycle for such kits is hard to pin down, but a spike in mobile device malware is likely in the very near future. If you haven’t already, now would probably be a good time to look at anti-malware for all of your computing devices – Weyland-Yutani BOT is just the beginning.

As you’ve doubtless heard, Sony’s PlayStation Network has been down for several days now. The exact cause of this outage, being apparently affected by hackers of some stripe, is doubtless worth investigating. However, since those details haven’t been fully divulged yet, it’s best to wait on that front.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

While the software industry continues to make strides in the area of security and data protection, the hardware industry shouldn’t be underestimated. With the announcement of storage devices like Toshiba’s MK-61GSYG hard disk drives, it may only be a matter of time before we see even more creative security features for hardware (due, in part, to industry-wide adoption of standards). Toshiba’s harddrive comes with some interesting security tricks, including the ability to configure the disk to erase itself when connected to an unauthorized host, and the ability for the drive to self-encrypt without relying on the host computer’s operating system for cryptographic operations.

Most of the features are drawn from the standards found in the Opal Security Subsystem Class (SSC) (pdf). The SSC is, in turn, based on the TCG Storage Architecture Core Specification. TCG is the same company behind the TPM platform standard, which was designed to let a system create and operate a trusted subenvironment from within an untrusted environment. The TPM platform still receives a fair amount of criticism for privacy issues and the potential for abuse.

A similar approach is used for some OPAL-compliant storage devices: dedicated on-board hardware that can handle a range of specialized operations (maintenance, authentication, cryptography) independently. The result is hardware like the MK-61GSYG, which probably meets many storage security requirements right out of the box. Although much can be said of the controversy that can surrounds newer standards, they can certainly provide a welcome stepping stone for innovation.

A few years ago, I wrote a post about “the power of s” explaining how important it is to use https instead of http, and how that made things more secure. Strictly speaking, what I wrote then was true. It’s very important to implement SSL, and SSL can indeed make communications secure. But it’s more complicated than that. SSL is an excellent tool which allows secure communication if it is implemented correctly. A bad implementation, however, is no more secure than sending data via clear text. And it’s awfully easy to have a bad implementation.

Ciphers are a good place to start. A cipher is the method used to encrypt a message. It’s the basis for most of what we tend to think of as security. But not all ciphers are created equal. Some are simply not secure. DES, for example, while having no particular vulnerabilities, does not allow a long enough key to be secure with modern computing. Not coincidentally, this problem with DES demonstrates that even a secure cipher like AES can be rendered ineffective if an inadequate key length is chosen. Figuring out what key length – and comparing key lengths – takes in-depth understanding of the cipher in question: 3DES with a 128-bit key is comparable (though not equal) to RSA with a 2048-bit key!

After ciphers, there are hashes, message digests, and signatures. These authenticate a message and assure that, encrypted or not, a message came from the source which it claims to have come from and that the message was not altered in transit. These are all crucial for preventing “man in the middle” attacks by which a third party can take over communication. As with the ciphers themselves, the algorithms used here are very important, and many have been proven to be insecure.

On top of that, there is the matter of certificates. Certificates play an important role in proving the identity of each end of the communication, and determining who to trust. However, recent events have proven that the certificates themselves can be insecure, either due to poor design or compromise of the certificate authority.

These are the basic concerns entailed in implementing SSL. Would that it were really so simple. Unfortunately, the real world throws in greater complications. The truth is that implementing SSL properly relies on the options made available by the hardware and software vendors. They may not have implemented every possible cipher; it may not be possible to load custom certificates. The certificates in use may not be able to negotiate shared keys… the list goes on. And that assumes using something like a unified solution. Inevitably, almost any IT environment becomes a heterogeneous environment. There is always a particular piece of the puzzle – firewall, a management tool, a server – that simply must be from some other vendor. And these parts don’t always work well together; often the only option by which products from two different vendors can communicate at all turns out to be decidedly less than secure. On top of that, even if secure options are available, and all the various parts can use the same ciphers and other components, there’s the administrative overhead: sure, it’s possible for each SAN switch to have a certificate, but do you have the resources to administer certificates on more than 500 of them?

The more I’ve learned about SSL, the more I realize how difficult it is to truly engineer a secure solution. Doing so can require fundamental and sweeping changes to an IT infrastructure and may take months or more to enact. Of course, anyone who cares about security should implement some form of security – but it’s important to remember that not only is it not as simple as changing an option in a control panel, it’s often as difficult as engineering the infrastructure in the first place.

Last week there was talk of an information breach affecting customers of several large corporations, whereby names and email addresses may have been leaked through a marketing company (Epsilon).

Even without knowing all of the minute details, there are some important things to take away from this:

• Large pools of consolidated personally identifiable information are huge targets for would-be attackers
• Those you trust with your trusted data might not be as careful with it as you’d like them to be (applies to both customers and companies)

But, although there is much to be said of the risk we all take when we share private data, perhaps the bigger issue is the fact that companies hound you for your personal information in the first place. I can *maybe* understand a bank or financial institution needing to know a reference phone number or an email address to send you account information. But Walgreens, Kroger, Eddie Bauer; do they *really* need my personal contact info?

I once had an airport kiosk salesperson to verbally question whether or not I gave him my real phone number on the questionnaire that I filled out to get a “free” prize. I fraudulently reassured him that the last 4 digits were “3210″, and I half-expected him to whip out his phone and double-check.

But not every company is out to spam you to death. And I’m sure there are many people who don’t mind being marketed to (especially by their favorite brands). But for those of us who are asked to give up our email addy at the checkout counter, what can we do to shield ourselves from the inevitable mishandling of information we might not even want to share?

Far be it from me to suggest that *other* people willingly give out inaccurate information, but I regularly switch my phone number digits around and give out the wrong domain for my email (apologizes to my hotmail address twin). Even without resorting to harmless chicanery, there are things we can do to protect some of our important data. For example, disposable email addresses are great for keeping spam out of your real inbox, and have the added benefit of being valued lower by attackers than, say, a business or government account. After all, who targets mailinator accounts? Or, if you have the technical chops, an option may be to sign up with a call-forwarding service (like Google Voice) in order to cloak your actual phone number.

In other words, consider giving out your personal information on a need-to-know basis. Even then, we may have fewer options when it comes to protecting data a company creates in-house about its own customers, or the details associated with payment card purchases. But then again, that’s why we have standards like HIPAA and PCI-DSS…

Over the last few months, many people have talked about using HTTPS with sites such as Facebook and Twitter. The technology came up often after the release of Firesheep, which allowed Wi-Fi users to hijack other users who used these sites without HTTPS.

Part of the technology behind HTTPS are certificates – small electronic files that help your browser ensure it’s connecting to a trusted site and protect the connection from eavesdropping or tampering. For instance, when you visit https://www.google.com, the Google server has a certificate that lets your browser know it’s connecting to Google and not an impostor.

But how does your browser know if the certificate is not also from an impostor? Each browser maintains a list of certificate authorities, or CAs – special servers whose main purpose is issuing certificates for all those HTTPS websites. These CAs may also vouch for other authorities, creating a hierarchy of trust. If you access a site whose certificate is not from one of these authorities or has been marked by one of them as revoked, you’ll get an error or warning about a certificate problem. Ideally, all of the authorities are all trustworthy and only issue certificates for reputable websites.

Unfortunately, the current reality is less than ideal, and attacks can happen. Yesterday, a blog post from the Tor Project detailed research showing that two major browsers had quietly added code which blocked a few specific certificates. These certificates were issued by an authority in a hierarchy controlled by Comodo, who released a statement today providing a bit more information on what happened.

According to Comodo, attackers were able to access the account of a user who helped manage one of the servers for issuing certificates. They then created their own certificates for verifying websites from Google, Yahoo, Skype, and others. These fraudulent certificates could be used to make a user’s browser think it was connecting to legitimate sites when actually communicating with a malicious site.

Comodo stated that many of the attacks appear to be from Iran, and has said they believe the attack to be state-driven, but many details are still unknown at this point, and the situation calls into question several aspects of Comodo’s security policies. In the meantime, you should make sure you’re using the latest version of a modern browser, such as Chrome or Firefox, and avoid connecting to untrusted networks. The fraudulent certificates that have already been identified will be blocked by an updated browser, and we’ll have to wait and see if more fallout results from the attack.