The legal and regulatory considerations of the Heartbleed bug

Standard

As everyone knows, there has been a bunch of chatter on the Heartbleed bug. The vast majority has been focused on identification and remediation. While both are important, the folks over at information lawgroup (http://www.infolawgroup.com) posted some things to consider from a legal perspective. Here’s the link (FAQs Concerning the Legal Implications of the Heartbleed Vulnerability – http://bit.ly/1hF0Dcr). It is a little repetitive, but still informative.

They talk a bit about breach laws and HIPPA, with the main take away been that being exposed to the bug doesn’t trigger any legal action per-say. Like anything, failure to react and remediate could lead to some form of negligence and ultimately legal exposure.

The bank regulators also chimed in. The FFIEC publish some guidance on the Heartbleed matter recently (http://www.ffiec.gov/press/PDF/OpenSSLAlert041014.pdf). The guidance reminds institutions to not only patch their own systems, but to check with outsourced providers to make sure that they have taken appropriate action as well. Banks should ask for and document this verification from providers so that it can be shown to regulators during the next exam cycle.

Some Quick Notes on Heartbleed

Standard

I’ve been receiving a bunch of questions on this, so let me try and summarize things a bit…

What you need to know:

Any website running OpenSSL (Versions 1.0.1 – 1.0.1f) are at risk. This is the software that creates a secure encrypted session with a given webserver (for example – online shopping or banking). OpenSSL is said to be running on 66% of all Internet servers.

The simple gist of the vulnerability allows an attacker to send a message to a webserver and receive back a portion of memory that is being used to run the server. The bit of memory could contain usernames, passwords, encryption keys, etc. If run multiple times, a great deal of sensitive information could be gathered and used for evil purposes.

The term heartbleed was coined because the message being sent is a heartbeat or keep alive packet, for a secure connection, that allows for a secure connection to stay open and ultimately bleed out any vital information.

Action needed:

• Upgrade any old versions of OpenSSL installations in your environment – (https://www.openssl.org/) For example: Servers, Firewalls, VPN concentrators – pretty much anything that uses a secure web connection with OpenSSL.

• If not contacted directly to do so, consider changing your password on sites that have been effected by the vulnerability. There are links below to help figure that out.

• Ignore attempts from phishers or other scam artist to reset passwords or patch systems

Useful links:

The site dedicated to the entire issue: http://heartbleed.com/

For a technical explanation, watch this video: http://vimeo.com/91425662

The actual MITRE listing is here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Here is a list of sites that could be effected: http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/?utm_cid=mash-com-fb-main-link

Here are a few tools to determine if a site has the heartbleed bug:
https://lastpass.com/heartbleed/
http://heartbleed.criticalwatch.com/
https://www.ssllabs.com/ssltest/

I hope this helps!

Another XP consideration – the remote user

Standard

With Windows XP finally reaching its sunset, many organizations have been thinking their security woes are gone. I’m not sure that is entirely true.

I’ve been speaking with several banks lately and while their internal networks are largely free of XP system, many of their external/remote users are still running the operating system at home. Like BYOD (Bring Your Own Device), some of these devices are largely unmanaged, personally owned, and could still pose a threat to an otherwise secure environment when connected via VPN. In one recent case, a bank was allowing executives and support personnel to VPN in from their respective home computers. Some of these computers are home systems that are shared amongst family members. While the employee working from home is made aware of the threat environment (at least annually in a bank), I’m sure their kids are not. Who knows what they have been clicking on?

In any case, it might be worth the time to review how users access internal systems while remote to make sure that there are no system exposures. I know much of the focus on remote access has been on cell phones and iPads but some consideration should be given to Personal Computers. It would be a shame to get compromised by one of these systems after spending so much time and money on securing the internal network.

An intro to IoT (Internet of Things) with a banking spin

Standard

Working with bankers, I have seen over the past few years how Internet-based technology has become one of the more dominate trends. For instance, you can’t walk anywhere today without seeing someone on their cell phone looking at social media or messaging someone on Facebook. To this end, banks have focused on managing how people use Internet resources. This obsession has led banks to rethink the business models and risks associated with Internet usage, forcing considerable policy changes and investments in technologies to keep pace with the rate of change. The availability of mobile devices alone has justified these expenditures, and banks have grappled with implementing some form of Bring Your Own Device (BYOD) for some time now. As if these changes have not been hard enough, banks will need to alter course again, shifting to a more device-centric approach to leveraging and managing Internet resources. This leads to the notion of an Internet of Things (IoT). Continue reading

Hello World!

Standard

This is the first of hopefully many posts on the new blog. I’ve been forwarding along everyone else’s content I figured I would add a lille of my own.