By Grace Zeng and David Coffey

In Part I we described our experiment with 15 unprotected servers in the cloud under two configurations and showed the elapsed times of port scan, vulnerability probe and exploit. In this post, we would like to share the observations and insights we gained from this experiment and discuss several ways to protect your machines, whether they are running in the cloud or on-premise.

Observations

1. Every machine on the Internet is scanned within minutes after connecting. It does not matter whether a machine connecting to the Internet opens ports or not — any machine will be scanned within several minutes. This is not surprising because attackers don’t know it a priori – they need a scan to figure out.
2. More open ports means more vulnerability probes. The amount of elapsed time between the initial connection and the arrival of vulnerability probes depends on the specific services that are running. The more listening services a machine has, the sooner it will be probed, and the more risks it will be exposed to.
3. More vulnerabilities means more exploits. It is rare that attackers send exploits blindly without first knowing that their targets are vulnerable. On the other hand, if unprotected machines have holes, chances are good that attackers will find them and attempt to exploit them. How long it takes depends on the vulnerabilities a machine has.
4. Login attempts are more common than exploits. We observed that attempts to log in were much more frequent than vulnerability probes or exploits. On each machine, we captured dictionary attacks at ports 445 (SMB) and 3389 (RDP), attempting thousands of username/password combinations. Most attempts targeted accounts with administrator privileges. Weak or default passwords can be easily broken.
5. Unknown exploits are rare. Even though our machines were otherwise unprotected, we saw few unknown exploits. This suggests that security products such as firewalls, IDS/IPS and AVs are likely to be effective in protecting computers from the most common attacks.

Recommendations for customers

Our experiment showed that the Internet is perilous. Attackers are constantly searching for targets. Although the Windows operating systems have become more secure, machines are still vulnerable to attacks. We do not recommend that customers follow our example — that is, putting unprotected servers into the cloud or directly onto the Internet.

To protect machines from attacks, customers should employ a multi-layered defense strategy. Appropriate defensive tactics fall into two categories: network-based and host-based. Network-based mechanisms include firewalls, IDS/IPS and anti-virus tools. (Note that in-cloud customers are not able to customize and deploy all network-based mechanisms, but do as much as you can. For instance, on Amazon EC2, you can easily configure inbound traffic rules on the management console for each machine.) Host-based methods include anti-virus software, host firewalls and host-based IDS/IPS (HIDS/HIPS) as well as security log management agents. Network-based defenses can secure your entire network perimeter and prevent threats from reaching computers inside the network, while host-based defenses safeguard individual machines from attacks. Customers can also limit the risk by taking action to reduce attack surfaces.

Network-based tactics

Firewalls

Firewalls are a vulnerable but important part of network-based defenses. Customers should:

• Configure firewalls to deny all unwanted incoming traffic. As a result, attackers scanning the public-facing IP address will see most ports closed or filtered, and subsequent vulnerability probes and exploits will not be launched.
• If some firewall ports must be open, restrict source and destination ranges. If your business requires you to accept incoming connections such as port 3389 (RDP), you should configure your firewall to restrict logins to users and IPs that are allowed to make such connections; connections from other sources will be denied.
• If source restriction is not possible, consider rate limiting attack-prone traffic. For example, a common attack tactic is to attempt to brute-force logins on the target system. As a defensive tactic, you can implement rules that drop traffic from source IPs whenever the number of failed login attempts exceeds a threshold within a given time window. This allows externally facing machines to get a few failed logins but not an entire brute-force or dictionary attack. Similar rate-limiting rules can be set up to filter out targeted port scans and host sweeps as well.

Intrusion detection/prevention systems (IDS/IPS) and anti-virus (AV) tools

Although firewalls are generally effective in allowing legitimate traffic while blocking unwanted traffic, they work at a coarse level of granularity. They also have limited abilities to examine the content of the traffic. Customers should:

• Install a network-based IDS/IPS. These provide more granular protection. IDS/IPS can inspect traffic to detect vulnerability probes and exploits by matching known attack patterns. These products also use heuristics to quickly pinpoint malicious communications and take necessary actions thereafter.
• Incorporate network-based AV tools. IDS/IPS is communications centric, whereas AV tools provide visibility into files, programs and data transferred in the traffic in ways that IDS/IPS cannot. AV tools are especially capable of capturing packed and polymorphic malware in transmission.

Host-based tactics

In addition to network-based defenses, customers can add defenses on the host. Customers should:

• Use AV software to prevent, detect and remove malware on host machines. These products are able to identify malware that propagates not only through network communications but also through channels such as USB drives.
• Enable/Install a host firewall to allow or deny traffic that is transmitted from, or received by, particular programs or applications.
• Install a host-based IDS/IPS (HIDS/HIPS) product on critical servers to provide full visibility into what is happening on the host — all system events happening in the memory, file system and registry. HIDS/HIPS also uses behavior-based rules to defend against unknown threats.
• Consider utilizing log management agents to collect and monitor important system logs. Especially when HIDS/HIPS is absent, log management agents provide audit trails for further analysis and can send alerts in real time as incidents occur.

Attack surface reduction tactics

Besides the deployment of necessary defense mechanisms, customers can take additional, largely non-technical, steps to reduce the attack surfaces of Windows machines.

• Always use strong passwords — either a combination of letters, numbers and symbols or an easily remembered but hard to guess long phrase.
• Disable and/or uninstall unused services.
• Restrict anonymous SMB logons.
• If possible, change default ports such as RDP (3389) to less known ports.
• Always keep Windows and installed software up-to-date — ideally, automatically.

To sum up, no matter whether a machine is in the cloud or on-premise, one single defensive tactic is insufficient to protect it from attacks. Customers should combine host-based and network-based defensive mechanisms as well as attack surface reduction tactics to create a multi-layered defense to protect your machines.

Andrew Jaquith and Richard S. Westmoreland contributed to this post.

By Grace Zeng and David Coffey

The Internet is a playground for opportunistic attackers. Right now, there are thousands of malware threats circulating around the Internet. Most computers today are protected by firewalls, IDS/IPS and anti-virus (AV) tools. But what happens when they do not have any protection? Previous experiments on “Time-to-Live-on-the-Network” and “Survival Time” of Windows machines were conducted quite a few years ago with test machines running old Windows operating systems. The “Four-Minute Windows Survival Time” claim in 2008 was especially criticized for using a Windows XP RTM or SP1 version in the test.

Since the time of these initial time-to-live studies, the Internet threat environment has become deadlier. Meanwhile, the Windows operating systems have become more secure. Because the state-of-the-art changes so quickly, we wanted to know how well an unprotected machine with a current operating system does in today’s threat environment. Left to its own devices, how soon will it be probed and attacked? We are particularly interested in testing unprotected machines hosted in the cloud because enterprises are increasingly turning to the cloud for various business purposes.

We ran our experiment with 15 machines in Amazon’s Elastic Computer Cloud (EC2) environment with two configuration profiles: “wide-open” and “out-of-the-box”. In the wide-open scenario, a machine opens all ports and emulates all possible services. This way the machine can attract as many malicious attempts as possible. In the out-of-the-box scenario, a machine runs only with default open ports and services. This scenario gives us a baseline of how many malicious attempts an unprotected machine might encounter.

Windows is by far the most popular operating system on the Internet. Its Server versions are generally exposed to more risks than Home/Professional versions. Our tests were carried out on the latest Windows Server 2008 R1 SP2 and R2 SP1. We disabled all firewall and anti-virus programs and configured the security policies so that Amazon would allow all incoming connections (TCP, UDP, ICMP) to those machines. We used Wireshark to capture packet-level traffic in real time.

To create the wide-open scenario, we installed a low-interactive honeypot named HoneyBot and disabled/changed several services to avoid interference. After the configuration was complete, we took a snapshot of the instance and created an AMI (Amazon Machine Image) for later use. We launched ten instances on EC2 using the same AMI and made sure that they were hosted in different geographical zones and were allocated different IP addresses.

For the out-of-the-box scenario, we made a clean install of Windows Server 2008 and didn’t install any programs other than Wireshark. By default, only ports 135 (RPC), 139 (NetBIOS), 445 (SMB) and 3389 (RDP) were open. We ran five such instances on EC2.

Scan, probe and exploit elapsed times

Malware infections follow a predictable pattern. Using a port scan, an attacker tests whether a port on a target machine is open. If so, a vulnerability probe gathers more information about a listening service, such as the version of the service – to identify vulnerabilities; and an exploit delivers malicious payloads to compromise the machine.

In  the wide-open scenario, after launching, on average it took about 23.4 minutes to see the first port scan, and 56.4 minutes to see the first vulnerability probe (the number for each server is shown in Figure 1).  Probes hit well-known ports such as 22 (SSH), 23 (Telnet), 25 (SMTP), 80 (HTTP), 445 (SMB), 1080 (SOCKS Proxy), 1433 (Microsoft SQL Server) and 3389 (RDP). With respect to exploit times, we observed that almost all first exploits were made within 24 hours, with the average time being 18.6 hours (Figure 2). We captured exploits on port 445 (SMB), 1434 (Microsoft SQL Monitor), 2967 (Symantec AV) and 12147 (Symantec Alert Management System 2). Almost all exploits during our month-long experiment were known threats. For example, the attack targeting port 12174 exploits a remote-code-execution vulnerability which was disclosed in 2009.

Figure 1. Scan and Probe Times for Wide-Open Servers (in minutes)

Figure 2. Exploit Times for Wide-Open Servers (in hours)

In the out-of-the-box scenario, it took an average of 13 minutes for the first port scan to arrive (Figure 3). Port scans hit ports such as 8080 (HTTP) and 1433 (MS SQL Server). The first vulnerability probe arrived within 3 hours on average (Figure 3); all probes were login attempts to Samba share (445) or via RDP (3389). We monitored the servers for a few weeks but didn’t see any exploits due to the limited number of open ports.

Figure 3. Scan and Probe Times for Out-of-the-Box Servers (in minutes)

Wrap up

Back to the question we asked in the beginning: On today’s Internet, how long does it take for an unprotected machine in the cloud to be probed and attacked? The short answer is: not very long.  What do we learn from the experiment? What can you do to beef up the defense of your machines? Go and check out Part II.

Andrew Jaquith and Richard S. Westmoreland contributed to this post.

Early last week, I was attending the three-day WiSec’ 2012 (ACM Conference on Security and Privacy in Wireless and Mobile Networks) conference in Tucson, Arizona.  This conference used to focus primarily on wireless security topics, but this year it attracted quite a few papers on mobile security.  There was a whole session with five presentations on mobile device and application security – all of which were related to the Android platform. I was a presenter in this session, talking about my work titled “Design of SMS Commanded-and-Controlled and P2P-Structured Mobile Botnets.”

I have been researching botnet issues since 2007 when the Storm botnet was in its heyday.  Botnets have been primarily targeting personal computers in recent years. Not until 2009, did I start to think about the possibility of mobile botnets after seeing the growing popularity of the iPhone and Android-based phones. I felt that they would fall victim to attackers sooner or later because of the following factors:

• Frequent downloading and sharing of third-party applications (esp. non-market applications) and user-generated contents
• More processing power and memory
• More personal and sensitive data stored
• Multiple communication interfaces (SMS/MMS, Bluetooth, EDGE/3G/4G, WiFi) coupled with mobility
• Lack of protection mechanisms

So I put myself in the attacker’s shoes to think ahead on how to construct a mobile botnet in an efficient and stealthy way. I designed a proof-of-concept mobile botnet that takes advantage of mobile services and stays resilient to disruption. Similar to PC-based botnets, a mobile botnet requires three key components: a vector to propagate the bot code; a channel to issue commands (a.k.a. command & control channel); and a topology to organize the botnet. Our bot code can be propagated through user-involved vectors such as hiding itself into popular game or system applications to entice users to download and install. My design primarily focuses on the command & control channel and the topology shown in the figure below. In this botnet, all C&C communications are transmitted via SMS messages and these messages are disguised as spam to be less noticeable. For example, the spam-like message shown in the figure actually encodes a command that asks the bot to send system information (SYS_info) to a server. To hide the identity of the botmaster, I adopted a P2P topology to allow the botmaster and bots to publish and search commands in a decentralized but structured fashion.

When I first started demonstrating the reality of mobile botnets in 2009, I received comments like “Mobile botnets are not realistic” and “Why would attackers bother to compromise smartphones? – there isn’t much a phone can do.” Over the past three years, we all have witnessed the evolution of mobile malware that has not only grown in number but also become sophisticated.

A few pieces of mobile malware in the wild have already demonstrated botnet-like behavior.  For example, in February this year, a malware application called RootSmart was discovered in third party Android markets in China and made headlines immediately. It was estimated to affect between 10,000 and 30,000 phones on any given day. Once started, RootSmart connects to a remote server to send information of the infected phone and fetches an exploit to root the phone. The infected phone is configured to send premium SMS messages and use other premium telephony services. Though the infected devices haven’t coordinately launched any large-scale attacks, potentially they can be instructed to do so because the attacker has full control of the rooted devices. Observing the advancement of mobile malware, people have realized that mobile botnets are becoming a real threat.  This emerging threat particularly concerns enterprises due to the exploding trend of employees using their mobile devices for company purposes –compromised smartphones that have access to privileged company resources can cause an enormous security problem. At the conference last week, the questions asked were: “Will mobile botnets be a more serious threat than PC-based botnets?” and “what countermeasures can we use?”

Indeed, my objective is not just to demonstrate that a mobile botnet can be stealthy, resilient and as sophisticated as a PC-based botnet, but to spur discussion on how to defend against this threat before it becomes serious. Although mobile botnets sound scary, unlike PC-based botnets that can infect your machines without your consent, mobile botnets cannot get to your phone without you taking some action. So, users, you are the first line of defense! Use caution when you download and install an application. (Android users, please pay attention to the permission list that is prompted to you and make good judgment. Does the application require strange permissions like sending/receiving SMS messages?) I believe an informed user can ward off a majority of mobile malware himself.

Unfortunately, many users have poor judgment. So automated detection solutions are still indispensable to securing mobile devices. Here are some options:

• Mobile application certification is useful but has limitations.  Apple has a tight control over applications placed in its App Store, though it cannot limit what jail-broken iPhones do. The certification required on the Android Market is not difficult to get around – that’s why we have seen numerous disguised malware plaguing the Market. What is worse, there are many third-party Android application markets with malware circulating around. I think an additional protection such as an install-time certification is necessary. For the Android platform, an install-time certification can automatically analyze the application as well as its permission list and tell if it requires more permissions than it needs. In a proactive manner, it can alert the user or even prevent the application from installing if something suspicious is found.
• Network-based detection should complement host-based detection.  Host-based detection solutions for mobile devices have been around for a while. Like their PC counterparts, such solutions may be disabled and uninstalled by malware. Since network-based detection is more resilient and has a good view of all devices’ traffic, it is better off working together with host-based detection to provide an additional layer of protection. But unlike in the PC world where a firewall and IDS/IPS can be placed at the entry point of a LAN, there are few vantage points in a mobile network. So a network-based detection solution has to scale well in order to protect a large number of mobile devices.

Interested readers: For more details, please refer to my WiSec paper here.

Here at the Perimeter STAR Team blog we try to keep level heads. Yes, information security is a dynamic field with lots of threat actors to worry about. Yes, it’s a fully buzzword-compliant field with lots of mumbo-jumbo. But no, despite what you might read, things are not all going to hell in a handbasket.

A big part of keeping our customers informed is knowing what to pay attention to, and what they should not worry as much about. We have, in the past, written some short “CTO’s reading list”/”5 articles you must read today” posts, describing news items of interest. Well, today I’m going to indulge my mischievous tendencies and do the opposite. So, here are three articles not to read, because they are silly, spread FUD or distract security managers from what they really need to be thinking about.

Don’t panic: Anonymous is not your biggest problem

The Wall Street Journal ran a story today, based on a Bit9 survey, that characterized Anonymous as security department’s biggest worry. As the article puts it, “some 61% of respondents to Bit9′s April report said they believed Anonymous or some other form of “hacktivist” attack, in which the perpetrators try to make an example of a company, would be the most likely assailant on their company computers.”

This is just silly. Anonymous is not your number one security problem. Anonymous is just one type of attacker companies need to worry about. As I described in my webinar, “The Hype and Reality of APTs,” (watch it for free!) there are at least three:

1. the nation-states of China and Russia, sometimes and misleadingly called “advanced persistent threats,” seeking to steal industrial secrets;
2. criminal gangs who want to steal and resell commoditized personal information about your customers, such as credit cards, personal health information, SSNs or other personally identifying information, and:
3. anarchist groups such as Anonymous that have political agendas to embarrass or discredit governments and businesses.

Anonymous (#3) is just one type of threat actor. Not every company needs to worry about them. The key common factors in the target include: the target is powerful (government), affects the lives of many (any “establishment” organization: press, Wall St); engages in controversial practices or lines of business (biotech, fur, oil). If you aren’t in an industry or part of an institution that attracts controversy, Anonymous is definitely not your biggest problem. Stating otherwise is just plain fearmongering.

 Are you afraid of the Top Attacking Countries? Don’t worry, you don’t have to move.

Sophos released its periodic “Top Attacking Countries” Dirty Dozen spam report yesterday, with the tantalizing blog headline “India becomes the king of the spammers, stealing America’s crown.” In the article, we learn machines in Indian IP address space relay more of the world’s spam than those in any other country. As much as 9.3% of the world’s spam comes from machines whose IP address are in India. And the US? Well, clearly, we American citizens ought to feel left out because we were relegated to second place — the silver medal! (I feel hurt, don’t you?)

I’ve long been critical of this silly, silly report because it doesn’t help customers in the slightest. It’s just headline-grabbing linkbait that won’t help customers become more secure. For example, what should you do if you reside in India or the US and want to avoid spam? Move?  It’s unclear. From Sophos’ standpoint, this report is great because it takes no effort to put together any conclusions or blame anyone. It generates a lot of headlines and offends nobody.

Here’s what would be much more fun: who are the top relaying companies? Which ISPs do the worst job policing their networks for spammers? Which registrars allow the most spammers to create spam-related domains? Now that’s a report I’d like to see. You’ll never see it from Sophos, though, because actually fingering responsible parties might annoy their customers or prospects.

No, one-fifth of Mac customers are not infected

Sophos is on a roll today. Right on the heels of their fluffy “Top Attacking Countries” report, we see a post on their blog blaring that one-fifth of Macs are infected. This is based on 100,000 Mac customers that downloaded Sophos for OS X and discovered that, in fact, they are infected with something.

I am not surprised that 100,000 Mac customers are worried enough about their security that they felt they needed to download Sophos’ free antivirus software for OS X. Good for them. Nor am I surprised that a significant proportion of those worried customers were found to be infected. If you are feeling bad enough to go to the doctor, odds are that you’ve got a cold. Makes sense.

But it’s a step too far to suggest that this sample of 100,000 customers can be generalized to the Mac population as a whole. Generalizing in this way displays what statisticians call “selection bias.” It’s statistically dishonest, and misleading. And the headline doesn’t help: “1 in 5 Macs has malware on it. Does yours?”

I don’t mean to whitewash the relatively new and novel phenomenon of drive-by Mac malware. Research from Dr Web and Kaspersky has shown that several hundred thousand Mac customers have likely been hit by the Flashback Java-based backdoor malware. The number infected may be as much as 1% of the installed base — a significant percentage. That’s enough to be worrying anybody, and more than enough to remind every Mac customer of the importance of following sensible security precautions (turn off Java in the browser, turn off the “open ‘safe’ files option in Safari, use ClickToFlash to disable Flash, consider running an outbound firewall such as Little Snitch, run as a non-admin user, etc).

But there’s a huge gulf between a possible 1% infection for Flashback and the conclusion that 20% must be infected.

Do yourself a favor: try to tune out the siren sounds of Sophos ambulances and their yappy ambulance-chasing dogs speeding past your house. You will sleep better.

On Monday, Apple released an urgent fix for a zero-day Mac Java flaw, reports Brian Krebs on KrebsOnSecurity. “The update, Java for OS X Lion 2012-001 and Java for Mac OS X 10.6 Update 7, sews up an extremely serious security vulnerability (CVE-2012-0507) that miscreants recently rolled into automated exploit kits designed to deploy malware to Windows users,” he reports.

Many Mac users believe that they don’t need to be concerned about malware attacks. However, reports have emerged that the Flashback Trojan is utilizing this same flaw to wreak havoc on more than half a million Macs worldwide — and counting. To make matters worse, the majority (56.6 percent) of infections are here in the United States.

According to Ars Technica’s Dan Goodin, Flashback is an increasingly sophisticated strain of malware that sniffs network traffic searching for user names and passwords. Previous versions of the Trojan prompted Mac users to enter their password before it would run, but the most recent strains don’t require a password. The strain is being spread via common Exploit Kits and its infection vector is utilizing a still unpatched zero day java exploit.

Although this issue should concern Apple customers, it’s important to note that nearly all Mac malware are Trojan horses. That is, the customer must take an active step to install harmful software, for example by installing little-known software found on shareware sites. If you spend time looking for “special codecs,” or for software that might be linked to other dodgy activities (for example, copyright protection cracking, BitTorrent, etc.) you might need to worry. Customers that always use Apple’s App Store, or obtain software from known-trustworthy vendors (Mozilla, Microsoft, Adobe, Twitter, etc.)  have essentially zero risk.

The Perimeter team is closely following this development and have put a correlation in place for all known command and control servers. Additionally, we strongly urge customers to investigate their Mac machines for evidence of the Trojan. We recommend visiting F-Secure, which has outlined a good set of instructions on how to identify an infected machine here. And of course, you should use Software Update to install the latest patch.

This is the second of a three-part Q&A series focusing on security concerns of credit unions.

Last week’s question focused on whether credit unions spend too much time on compliance tasks. Today’s question:

Can credit unions implement security measures and systems in ways that actually enhance productivity?

Our answer:

Security and productivity are usually diametrically opposed. Most organizations think about what needs to be done with respect to security first. The productivity impact is usually a secondary consideration. That’s not to say they can’t reinforce each other, but in most organizations, little thought is put into how they might. Or to put it in terms that I’ve heard come from the mouths of several business executives: ” we call IT security the ‘business prevention department.’”

That said, a little creative thinking can yield some good ideas about how to improve productivity while keeping employees secure. The key is to put yourself, as a security manager, in the shoes of your employees. You want to try to understand where the most important points of “friction” in their day-to-day tasks. Then, see if you can imagine ways to engineer work environments so that they make the right choice by default. For those of you who have read about “behavioral economics,” this is about “nudging” employees to do the right thing through incentives and changing default rules. Security becomes a side-effect of their normal tasks.

Let me give you a few examples of smart security strategies that also enhance productivity:

• Get rid of password expirations. Prevailing security dogma holds that security passwords should be complex and frequently changed. But requiring your employees to change their passwords every 90 days just annoys them, and they will do highly insecure things to cope as a result. They will scribble passwords on sticky notes, re-use the same password everywhere, or make the absolute smallest changes to their passwords that they can while still complying with policy. For example, an employee might pick a “complex” 8-character password “rosebud1!” and then increment the “1″ every 90 days. Even worse, because passwords must be changed so often, IT managers use the shortest passwords their regulators will let them squeak buy with: 8 characters. For these reasons, researchers from Microsoft, Cambridge University among other institutions have concluded that password aging is a massive waste of time. It’s far better to require comparatively longer passwords that never change, such as passphrases or mnemonic passwords. Although employees will face a slightly longer learning curve initially, once they commit them to memory, they becomes reflexes. The best part: long passphrases can’t be broken as easily, so you’ve increased security and productivity at the same time.
• Use LDAP, AD and single sign-on to reduce the passwords employees need to remember. As with password length and aging considerations, the employee’s ability to remember their passwords is a strong predictor of how likely (or unlikely) they will be to behave in ways that are less secure. The fewer passwords they have to remember, the less likely they are to make mistakes or game the system. Tying your applications into your LDAP or Active Directory servers is a good way to reduce the burden — think of it as the poor-man’s SSO. Full-blown single-sign-on (SSO) systems, of course, are even better. Consolidating password stores has benefits beyond just convenience, though. You also get better security because you can centrally enforce your password policies, and suspend access to applications and infrastructure much more quickly.
• Protect sensitive applications using terminal servers. Most credit credit unions probably know that Windows Server has a feature called Terminal Services, which presents a virtual Windows desktop for accessing applications on that host, or for accessing resources that host can access. Citrix does the same thing. You can use this feature strategically by forcing employees to use Terminal Services access to highly-sensitive applications and resources. I call this the “glove box strategy” because data and applications are all remote — thus keeping sensitive data off of the employee’s laptop. If you do this well, for example by providing plenty of processing power and bandwidth to the server, employees will want to use it. It will feel like a natural part their workflow — it becomes how they “go to work.” The best part is that you get much better security as a side-effect.

Tune in tomorrow for the third of three questions: Can you highlight some of the main ways that your solutions help credit unions maintain compliance and add to their overall security posture?

This is the first of a three-part Q&A series focusing on security concerns of credit unions.

We recently got an excellent question from one of our business partners, asking me:

Do you think that credit unions have focused too much energy and resources on maintaining compliance with ever-growing regulations, and not enough on information security?

Our answer:

For many credit unions, effort spent on compliance can indeed crowd out security considerations. It’s not surprising to see why this might be the case. Financial regulations and audit standards were often created with large financial institutions in mind. The FFIEC IT Examination Handbook for Information Security, for example, contains nearly 100 pages of guidelines on more than 50 different control areas. I’d argue that these are all worthy topics to assess, but if you are a credit union serving a small member base, you might have trouble satisfying all of the audit criteria if you’ve got an IT staff of just a few people. The CFO is sometimes also the CIO, CISO, CRO, and VP of Procurement!

At Perimeter, we call the amount of time, labor and expense needed to satisfy IT security-related regulations “the compliance tax.” It’s a tax because you have to pay it. It’s a tax because it is the price you have to pay for being a credit union that handles members’ financial assets. And it is a tax because like many other taxes, the effort related to paying it means that you can’t devote resources to other things. Security — or at least, security that actually works — is sometimes the casualty.

Tune in tomorrow for our second of three questions: Can credit unions implement security measures and systems in ways that actually enhance productivity?

Greetings! Long time, no post. I have four good articles for you to read today and over the weekend.

HITECH regulations start to bite

Today, Dark Reading’s Ericka Chickowski  wrote a story about a recent settlement with Blue Cross/Blue Shield of Tennessee over violations to the HIPAA Privacy Rule. Why the penalty? Blue Cross failed “to prevent a breach that saw the theft of 57 unencrypted hard drives containing recordings of customer service phone calls. The drives were left behind in a data closet after the company stopped using a leased facility.” The precedent, in other words: thou shalt encrypt thine hard drives under penalty of fine.

Good article, but Dark Reading waxes a bit hyperbolic by saying that that particular case ushers in a “new era” in health care regulatory enforcement. HHS’s OCR division has been reporting on breaches since 2009 at least, with over 100 breaches affecting more than 500 individual since 2009. But Ericka’s broader point is still valid. Anecdotally, we’ve seen a steady uptick in visibility of these kinds of enforcement actions. For example, see this recent post by Proskauer LLP’s Robyn Sterling about Minnesota Attorney General Lori Swanson suing a business associate for failing to encrypt the contents of a laptop that was lost.

As a managed security services and hosted email provider that does significant business with health care companies, Perimeter believes health care Covered Entities need to take a proactive approach to security. You can see my blog post describing our “Rx for health care” (sorry for the pun) here.

Disclaimer: Perimeter E-Security is a Proskauer LLP client.

More testimony to John Nash’s beautiful mind

The Turing’s Invisible Hand blog posted an excerpt and commentary about a recently declassified John Nash’s 1955 letter to the NSA describing a new method of cryptography. In the letter, Nash anticipates by nearly two decades something that we all now know to be true: the “strength” of a key should be judged based on how long it takes to factor it. He also suggests that by selecting algorithms of sufficient complexity, cryptosystem designers could fashion sufficiently long keys that were essentially unbreakable. Again, this is held as gospel today — how many times have you heard expressions like “it would take 16.7 million years to crack a xxxxx-bit key”? — but it was a sensational assertion (albeit privately voiced) at the time. It’s not clear that the NSA ever took Nash up on his offer to work on his proposed cryptosystem.

If you are a cryptography nerd, or play one on TV like me, you’ll get a real kick out of this letter, though.

EU Data Protection rules become less confusing

US multinational corporations that have European subsidiaries have long had to make difficult decisions about how to comply with the EU Data Protection Directive (DPD). Do you use model contracts or binding corporate rules? How much money will it cost you to comply with each member country’s Data Protection Authority (DPA)? Are you forced to set up European data centers? So it comes with some relief that The European Commission’s new draft regulation, which essentially replaces the DPD, would bring much clarity to these and other issues. Covington Burlington LLP’s Mark Young does a nice job in his post “European Commission Proposes Comprehensive Data Protection Reform” summarizing the key changes.

That said, if you want to read a very thorough, incredibly thoughtful yet readable analysis, go read Christopher Kuner’s article, “The European Commission’s Proposed Data Protection Regulation: A Copernican Revolution in European Data Protection Law.” Christopher is a Brussels-based partner at Hunton & Williams, and is my “go-to” guy for all things related to EU data protection.

 Visions from Ben

On a fun note, for Friday:

Over at Stephen Few’s Perceptual Edge blog, Stephen posted a link to a paper by Ben Schneiderman that made me very happy. For those of you who don’t know him, the University of Maryland’s Ben Schneideran is one of my favorite data visualization thinkers. His specialty is exploratory data analysis, and he invented the treemap. He and Jeffrey Heer from Stanford just published a delightful taxonomy of  analysis tools for data visualization called… (wait for it), “A taxonomy of tools that support the fluent and flexible use of visualizations.”

The article — which will take you about 15 minutes to read — defines a vocabulary and way of thinking about interactive data exploration. This is a crucial discipline for Big Data analysis (see my post on that topic here). You can’t say “Big Data” without “analysis.” Two items in the paper that got my attention is formally defining “trellis plots” (another name for small multiples) and “brushing and linking” (clicking, selecting or rolling over a data range in one plot causes them to to be highlighted in related plots). I also liked the closing part of the paper, which stresses that data analysis is really all about storytelling. While I can’t say too much about what we’re working on here at Perimeter (super secret!), I’ll just say I was able to relate to this point really, really well.

That’s it for now. As always, I look forward to your comments on these articles and other topics.

During this month’s patch Tuesday, Microsoft released six updates, with one critical patch. The critical patch fixed a serious flaw found in all versions of Window’s Remote Desktop Protocol (RDP). This flaw allows attackers to remotely execute code on machine running the service, or perform denial of service (DoS) attacks.

This exploit is extremely dangerous, for three reasons:

• RDP is widely used
• RDP is commonly passed through firewalls due to its utility
• No initial authentication is required to pull off these exploits

On Tuesday, Microsoft’s Security Research and Defense Blog stated that they expected to see exploit code in the wild within 30 days according to a quote from their recent blog post addressing the flaws: ”During our investigation, we determined that this vulnerability is directly exploitable for code execution. Developing a working exploit will not be trivial – we would be surprised to see one developed in the next few days. However, we expect to see working exploit code developed within the next 30 days.”

Unfortunately it seems Microsoft was being a little too optimistic. It has been only been 3 days and there is now code in the wild, which our Security Operations Team observed this morning. The Proof of Concept (PoC) exploit code is able to successfully exploit the flaws with a specially crafted .dat file and a copy of NetCat. Because the PoC code is now circulating, it’s no longer a question of if but when botnet and worm programmers will incorporate it into their existing kits. Due to the simplicity of exploiting the flaw, I personally expect to see RDP exploits become prevalent in banking botnets such as ZeuS and SpyEye. It’s a “no brainer” prediction to say that this exploit will be added to any worms or trojans written this year.

We felt it was extremely important to get the word out to so that you prioritize this patch for your Windows systems. To eliminate this risk, you should patch all of your RDP-enabled hosts immediately.

For those who cannot patche their RDP-enabled hosts immediately, Microsoft recommends using Network Level Authentication (NLA) as a temporary workaround. NLA will substantially reduce the risk on Windows Vista and later systems. NLA works by requiring authentication before a remote desktop session is established. Once NLA is enabled, the vulnerable code is still present and could be potentially exploited. However, the user would need to authenticate before being able to exploit the vulnerabilities. Details on enabling NLA can be found at Technet.

NLA has some side-effects. Enabling NLA will prevent Windows XP and Windows Server 2003 clients from connecting. If you need to connect to an NLA-enabled server with a Windows XP SP3 client, you will need to install support for Credential Security Support Provider (CredSSP). You can install CredSSP by visiting http://support.microsoft.com/kb/951608. Enabling NLA does not require a re-boot.

In addition, links to the various Microsoft Fix it packages can be found on Microsoft’s blog.

Perimeter E-Security urges you to protect yourself by applying this patch, and/or implementing these workarounds. You should also:

• harden your network by restricting RDP connections from known IP addresses
• change the default RDP port
• restrict users on RDP hosts to specific programs
• create organizational units for terminal servers, and set restrictive Group Policy settings (RDP enabled) desktops and terminal servers.

Harald Wilke and Andrew Jaquith contributed to this post.

In the succinctly-titled research paper “Ron was wrong, Whit was right,” researchers Lenstra, Hughes et al showed that flaws in the RSA key-generation algorithm could cause weak keys to be generated in a small percentage of cases, making RSA-based certificates insecure. As the paper put it,

We performed a sanity check of public keys collected on the web... We found that the vast majority of public keys work as intended. A more disconcerting finding is that two out of every one thousand RSA moduli that we collected offer no security. Our conclusion is that the validity of the assumption is questionable and that generating keys in the real world for “multiple-secrets” cryptosystems such as RSA is significantly riskier than for “single-secret” ones such as ElGamal or (EC)DSA which are based on Diffie-Hellman.

The report was widely reported in the press, including MSNBC, which ran the story under the sensationalistic headline “Hidden flaw jeopardizes millions of online transactions.” Here’s our take on the issue.