SSL 3.0: POODLE Vulnerability Update

Who it affects, how hackers could use it, and what you should do about it.

You’ve probably heard about the newest online security threat, POODLE. While not as menacing as Shellshock or Heartbleed, many are still concerned about its potential impact on their business or personal security. 

Here’s what we think: The chances of this vulnerability being used to compromise your sensitive information is relatively low. The successful exploitation of this attack requires such a large number of preconditions that the chance of this attack being used in the wild is low. This attack would probably only be a concern if you are likely to be targeted by a state-sponsored organization.

Here are the facts

  • POODLE affects browsers with JavaScript enabled that support SSL 3.0 
  • The vulnerability could be used to retrieve authentication cookies that are encrypted via a man-in-the-middle attack
While this is a legitimate attack, the likelihood of being compromised via POODLE is very small.Tweet: While a legitimate attack, the likelihood of being compromised via POODLE is very small. http://bit.ly/1DBgKk1Tweet

Can I be compromised through POODLE?

Here’s an explanation of how an attack would have to take place in order for an attacker to exploit POODLE and assume the user’s identity on the target site.
  1. The victim must be logged into a site using HTTPS (and the session cookie must not be expired)
  2. The victim must browse to another website over HTTP before the session cookie expires
  3. The attacker must write a custom JavaScript code to exploit POODLE. To date, no prepackaged tool has been published to exploit POODLE
  4. The attacker must inject ~5,000 requests in order to decrypt the session cookie 
Basically, this attack is extremely difficult because both the merchant and the user have to be vulnerable. 

Our recommendations?

  • If you are still using Internet Explorer 6, you are using an obsolete operating system that is no longer supported. You need to upgrade to a newer operating system. If upgrading is not an option, you need to update to a newer browser that does not support SSL 3.0. 
  • If you are running a webserver and currently support SSL 3.0, you need to evaluate your business requirements to determine if SSL 3.0 is currently being used. If it is not, simply disable SSL 3.0. Otherwise, develop a plan to disable it as soon as possible. 
SecurityMetrics has plans to update our website after notifying customers of the change. We have made this choice because POODLE is not a critical risk vulnerability. We do not believe it puts our customers at direct risk.

SecurityMetrics is ready to help our customers navigate through POODLE with the highest reliability and least business impact. If you have any questions, please contact SecurityMetrics support, 801.705.5700.


My OCR Audit, and How I Survived

An interview with Doreen Espinoza of UHIN.

Doreen Espinoza
Doreen Espinoza, Business Development and Privacy Officer of UHIN answered some tough questions about her audit with The Department of Health and Human Services’ (HHS) Office for Civil Rights (OCR). UHIN (Utah Health Information Network) is a full-service clearinghouse and Health Information Exchange (HIE) that specializes in administrative and clinical exchanges. The organization was randomly chosen for a pilot audit in 2012, and was one of only two clearinghouse entities that passed their audit with “no findings”. 

Our hopes are that this interview gives you better insight on what to expect from any OCR audits in the future. This is her experience, from start to finish.

How did your audit with the OCR begin?

ESPINOZA: We received the letter from Leon Rodriguez (former OCR director) in May of 2012. The letter asked us to put together our documents in two weeks. At the time, we were already going through an EHNAC (Electronic Healthcare Network Accreditation Commission) audit. 

I told the OCR, “Sorry, but two weeks isn’t going to happen. I can’t do two audits at once, not of this magnitude.” Luckily, they worked with me and we negotiated a new date. After we finished our EHNAC audit, (a month after I received the letter from the OCR) I was then able to focus on the OCR audit. 

The amount of time the OCR gives you to prepare for the audit is interesting. Whether you have a really solid program, (which we do) or if you’re new to the program, it takes a lot of time. I ultimately spent 180 hours on the audit, even working nights and weekends. 160 hours were spent merely gathering documentation. It took about a month to get all our documents ready to turn in.

Explain your feelings before the audit.

ESPINOZA: Because we were one of the first to be audited, I wasn’t afraid our documentation would be lacking. As I explained, this wasn’t our first audit. However, if I had been a provider with little to no understanding, I would have been scared.

I did have one concern: Would the OCR auditors understand what they were auditing? The auditing firm, McKesson, is basically an accounting firm and new to HIPAA audits. Since I hold an accounting degree, I understand how they think and what they’re trained to do. The problem is, privacy and security is not the same as a financial audit. 

These were my thoughts before the audit: Do they have any healthcare knowledge? Do they know how to interpret HIPAA rules? Do they have sufficient knowledge to understand our documentation?

When I asked the auditors who had audited a clearinghouse, only one hand of four went up. I think they understood, generally. But I did have to push back on one of the audit points. 

Requirement 164.520 requires a notice of privacy practices, but because UHIN is a clearinghouse, it doesn’t make sense for us to have one. We are technically a covered entity, but we don’t have patients. After a fair amount of explaining, I was able to convince them we were compliant without one.

How intrusive was the onsite audit?

ESPINOZA: Most of the interaction was with me, though our security officer was a part of some conversations as well. 

Besides the thorough examination of our documentation, the auditors went through our office looking at basic facility security, checking to see if doors were locked and where workstations were located. 

I walked them through the building and explained our workflows. I also gave them an explanation of our data center. 

The first 70 documents I submitted to them, they reviewed as a part of their pre-audit evaluation. When the auditors came onsite, they asked for an additional 55 documents. The onsite visit is truly to ask you additional questions and get additional documentation. 

They were there for three days, and those three days were really intense. It felt like an interrogation. They asked a question, I answered it, then they moved to the next question. 

The main focus of the audit was all about privacy and documentation, which was a little disappointing to me. I thought the audit would also focus on them testing security, like passwords and such. I am very proud of our data center and offered to take them, but they didn’t take me up on the offer.
They did a really good job of asking a million documentation questions. They just didn’t take it any further than that.Tweet: Tweet
That’s why I think companies like SecurityMetrics are great. After our OCR audit, we used SecurityMetrics to look at our security and it was a great security review. Honestly, I wish I had SecurityMetrics at that time. If nothing else, just to prove our security to the OCR. I can write policy all day and night. But to show compliance? Security is the tangible way to support privacy. 

SEE ALSO: What to expect with an HHS audit

What was the impact of your organization on this audit?

ESPINOZA: Since privacy is my job, I was probably the most impacted by the audit. Another thing that made this audit so intense was, in 2012, HIPAA 5010 was rolled out. So I didn’t have a whole lot of help preparing for the audit. Everyone else was busy implementing HIPAA 5010. 

What are the differences between an EHNAC and OCR audit?

ESPINOZA: EHNAC is a non-profit organization that accredits large organizations like clearinghouses and clinical health exchanges. We've held our EHNAC accreditation since 2004. To be accredited, we have to undergo an audit. 

The difference between an OCR and EHNAC audit is, OCR auditors wanted you to prove you were compliant with the rule, but didn’t provide examples of acceptable evidentiary documentation. I don’t know that the OCR auditors really knew what to look for, but remember, we were in the pilot audits. EHNAC specifically states which parts of HIPAA you must be compliant with, and gives examples on how to show that compliance. 

What information and documentation did the OCR request? 

ESPINOZA: All in all, 127 documents. Here are some specific examples:
  • Work desk procedures (e.g., thou shalt have a password, thou shalt change that password every 90 days, etc.)
  • Risk analysis
  • Contracts. We don’t do business associate agreements (BAA), but we do enforceable consent agreements (ECA) which incorporate BAA language
  • Training logs
  • Incident management
  • Complaint processes and procedures
  • Password policies
  • Electronic commerce agreement
  • EHNAC Self-Assessment
  • Trading partner security requirements 
  • Lists of vendors 
  • Lists of employees and their access to the system
  • Diagram of what our office looks like and where the exits are
  • Disaster recovery book
  • Employee handbook
  • Breach processes
  • Policies and procedures for security and privacy
  • …… lots more.
In a nutshell, we gave them our policies and procedures, lists, diagrams, workflows, and organizational charts. 

How did you feel after the audit? 

ESPINOZA: I was ecstatic. It was a sigh of relief to know it was over. Remember, I had already gone through the stress of our EHNAC audit. I was so proud and excited to see that we had completed our audit with no findings. 

What do you wish you had known about your audit?

ESPINOZA: If you get a letter and expect to have a good outcome, and don’t have everything prepared now, you’re not going to have time to do proper preparation. Your audit will fail. 

In retrospect, I wish I had known there were companies in addition to EHNAC that could have prepared us for the audit. My advice to anyone out there preparing for an audit is: investigate other organizations that could help you pass your audit. Nobody should have to go through an audit alone. Reach out to organizations like SecurityMetrics and EHNAC now to help you with your data security! 

SEE ALSO: You may not be done with your HIPAA requirements 

How should organizations prepare for an audit now?

ESPINOZA:
  1. Gather your documentation now. Organize it.  
  2. Conduct an annual risk analysis. Not only is it HIPAA required, it makes sense. 
  3. Do periodic mini-audits internally. One day, go through your facility. Are your doors and filing cabinets locked? It doesn’t seem like a big deal, but I promise you’ll find a lot. 
  4. Make sure your company is committed. Make it a priority in your organization. Had UHIN not been committed to privacy and security all along, we would have never passed our audit. It’s all about the commitment of the organization. It really does take the entire group to make this stuff work. 

So, how do you survive an OCR audit?

ESPINOZA: Diet Coke, a calm demeanor, and help from others. :)



Securing Keys and Certificates: A PCI Auditor’s Perspective

Gary Glover and Brandon Benson on keys, Heartbleed, and security.

Businesses must ensure their key servers, certificate authorities, open SSL libraries, and server updates are secure. Christine Drake of Venafi interviews Gary Glover, Director of Security Assessments at SecurityMetrics, and Brandon Benson, Security Analyst at SecurityMetrics.


PCI Requirement 2.4

Listen to the full interview

Christine Drake: Let’s talk about the Payment Card Industry Data Security Standard version 3, and how it applies to visibility in keys and certificates. I’m with Venafi, and we deliver next generation trust protection, securing keys and certificates.

Gary Glover: I’ve been a Qualified Security Assessor (QSA) in this industry for about 10 years, before PCI DSS was even a standard. Over that period of time I’ve conducted many PCI DSS and PA DSS assessments, and a lot of consulting. Now I manage a group of QSAs and Penetration Test engineers at SecurityMetrics.

Brandon Benson: I’ve been a QSA at SecurityMetrics for approximately 4 years now. I work with point-to-point encryption format algorithm standards and have had quite a bit of experience with managing and dealing with keys. I help companies interpret the standards in their environment and see what controls are in place and what they need to fix on a regular basis.

Christine: I want to focus in on Requirement 2.4, which requires an inventory of all system components in scope of the PCI DSS. That includes keys and certificates. Gary and Brandon, do you think businesses know where their keys and certificates are that are in scope of PCI DSS?

Brandon: It is definitely more difficult for newer merchants or companies just starting to undergo the assessment process for the first time. Those are areas they haven’t really focused on in the past.

Gary: Most QSAs will go through a discovery process as they prepare someone for their first audit. During that process, we help businesses identify where those keys are.

Early on, when PCI assessors start asking questions about keys, IT staff members say, “I don’t know where those are.” or “The person who did that key process left the company. Let me figure that out and get back to you.” Scenarios like that happen a lot.

Christine: Sounds like it’s a manual back-and-forth process. As they hear more about what they need to discover, they go out and find it. Scope isn’t a one time process, but a back and forth until you’ve covered everything?

Gary: Yes. When we get people prepared for a full PCI DSS audit, we are constantly educating on data flows and how the digital keys are being used inside their network to protect an SSL stream. Part of the process we go through is identifying which employee knows where the keys are. We have to get them on the phone, talk them through it, and identify the flows. So yes, the discovery process is a bit of a manual thing. After a customer has gone through this process a few times, they’ll know which keys need to be changed, and which ones we’re going to ask them about.

The most difficult part of a PCI audit is determining the scope, ensuring it’s correct, and helping the customer understand how it might be modified to minimize scope.

It’s important for people to realize that the keys QSAs talk about are the ones used to secure static credit card data. Ensure you have good key management key procedures around those. Sometimes customers gloss over SSL key expiration dates, and they don’t care if they are self-signed.

Christine: Do you include SSL keys as part of the scope in PCI audits?

Brandon: Yes. PCI DSS Requirement 4 specifically talks about encryption of data over open public networks via transmission. That’s where we should focus more on the certificate type of keys and keys used to encrypt data on the fly.

PCI Requirement 5

Listen to the full interview

Christine: Let’s talk now about Requirement 5 including a new provision that requires companies to evaluate uncommon systems to see if they are susceptible to malware.

We recently saw that to remediate the Heartbleed vulnerability, all keys and certificates had to be replaced. Very recently we saw a compromise in a health systems services company that compromised 4.5 million records because the keys and certificates were not updated. Gartner predicts that 50% of all network threats will use SSL by 2017. So I’d like to get your take on how Requirement 5 applies to keys and certificates.

Brandon: The primary target for malicious software is keys. If I have access to keys, I have access to your encrypted data. That’s why it’s so important to protect the keys.

But what we’re seeing is that malware attacks vulnerabilities in applications that use those keys. The malware for Heartbleed for example, didn’t attack the keys, it attacked the open SSL vulnerability so it could obtain the keys.

I think that’s what Requirement 5 in PCI 3.0 talks about. We need to make sure our key servers, certificate authorities, open SSL libraries, and update servers are secure, because that area has been neglected in the past.

The keys themselves are the target, but it’s not key strength that’s being attacked. It’s how the keys are managed.

Gary: I’d also like to add that when QSAs go through a system, they are supposed to look at all systems in scope and determine how those systems affect network security.

Technically, you can define something as inside a network zone, but it may be a server outside the network zone that’s critical to the security of the card network. It may be a shared key server. Even though it’s not technically inside the boundary of the cardholder data network, we’d want to make sure good controls were placed on that server. That might include anti-virus and anti-malware protection.

Christine: It really doesn’t matter if an organization sees keys or certificates as a common or uncommon system attacked by malicious software. Really, they’re supposed to be looking at their entire environment. Requirement 5 emphasizes that.

Brandon, you brought up the point that keys and certificates are a target, and compromising those assets helps in the delivery of malware. It sounds like protection would go beyond anti-virus.

Brandon: As you start looking at the security of an environment, the strength of the key is the key! No pun intended. We recommend all our customers to monitor their key locations. We don’t want keys to be swapped out or changed in any way.

If any keys are compromised, released, or disclosed, your environment becomes vulnerable to attack. Key misuse has a direct impact to the security of a cardholder environment.

I also wanted to mention that we’re seeing malware stream data from environments using SSL. So it's not like the bad guys don’t know the importance of encrypting data, because now they’re using it to encrypt data in these environments.

Christine: Sounds like it’s important to do anomaly detection and make sure these assets are being used as they are intended to be used. Do you think Heartbleed will put more focus on key and certificate security in audits going forward?

Brandon: The short answer to that question is yes. The long answer is, it’s not just keys we have to focus on. It’s also the systems and components supporting those keys. A key could be 100% secure. You can store a key in a hardware security module or a key management server that’s 100% isolated from the system. But the moment I need to use a key, for example in an open SSL library for receiving web traffic, I need to put protections around the key in all locations.

Heartbleed reemphasized the need for companies and assessors to understand where all keys are located and ensuring proper controls are in place to protect them.

Christine: Sounds like Heartbleed has a big ripple effect, but really what matters is remediation.

Brandon: Because Heartbleed attacked Open SSL to steal the secret keys, that’s what companies had to patch. Once they patched their open SSL libraries, then they had to issue new private keys for everyone. We saw some companies patch, but not replace their keys. Some companies replaced keys but didn’t patch. When you look at security, it’s really a multi-layer approach.

Christine: Whether it’s Heartbleed or another attack, you have to make sure remediation happens. I would assume you look at the latest attacks when you’re doing audits?

Brandon: Any QSA should consider that as part of their process. As we learn about new vulnerabilities, we communicate them to our customers. It’s not uncommon for me to email my customers and say, “I know you’re using Open SSL, have you seen this?” I know you’re using Oracle or My SQL, have you seen these vulnerabilities released today?”

Gary: The real point of Requirement 5 is, things change. Even if you think a system is out of scope for anti-virus or malware protection, you’ve got to be aware of what’s going on in industry and what’s going on with vulnerabilities. Earlier in the year, your system could be out of scope for anti-malware, but based on how things are happening, it is now.

Christine: Excellent point Gary. Businesses must continue look at their scope and security over time and not expect it’s finished after one review.


Want more? Watch this Infosecurity Magazine webinar:
What’s new in PCI DSS v3 for cryptographic keys and digital certificates?
The new PCI DSS v3 mandates stronger security for the technology that creates trust between servers, devices, and cloud—cryptographic keys and digital certificates. With cybercriminals hungry to steal keys and remediation of Heartbleed still incomplete, there’s sure to be more attention to this in audits. Yet the PCI DSS v3 requirements demand more visibility and security over keys and certificates than most organizations can deliver.
Could Your Waiting Room Wi-Fi Be Sabotaged?

Wireless network configuration best practices.  

Tod Ferran, Security Analyst
By: Tod Ferran
It’s good to keep patients entertained while in the waiting room. According to a 2013 Software Advice survey, 90% of U.S. patients are aggravated by doctors’ office delays. In that same survey, 60% said free Wi-Fi would somewhat minimize their frustration. 


The problem is, many offices don’t have their Wi-Fi set up correctly, turning that free patient asset into a liability. What if a patient (or someone posing as a patient) hacked that free Wi-Fi network? Depending on how your network is set up, he or she could tap into your patient data in less than 60 seconds.

SEE ALSO: Warbiking Studies Find Wi-Fi Has Serious Security Issues

Watch this video to learn best practices for healthcare Wi-Fi security. 


There are a few potential problems with free Wi-Fi in healthcare, but the main two I’ve seen are:
  • Network configuration 
  • Network encryption

Network configuration

Do your patients use the same wireless network as your workforce members? If the answer is yes, you have a potential security breach on your hands. Tweet: Do patients use the same Wi-Fi as your workforce? If yes, you've got a problem: http://bit.ly/1wuIhiu #HIPAATweet
Guest wireless networks should always be segmented from your non-guest wireless network by a firewall. 

For example, if your Wi-Fi network name was DrSwenson, I would set up another Wi-Fi network exclusively for patients named DrSwensonGuest. Nurses, office managers, and physicians should only use DrSwenson, and patients should only use DrSwensonGuest. 

In addition to the two different networks, it’s imperative to ensure both networks are actually separated by a firewall. If not, you could be putting your organization in serious liability. In fact, you have probably allowed impermissible disclosure of patient data and don’t even know it. 

SEE ALSO: Balancing Mobile Convenience and PHI Security

Network encryption

What type of Wi-Fi encryption does your guest wireless network use? What type of Wi-Fi encryption does your workforce wireless network use? 

As you set up your network, the little acronym next to the security encryption standard you choose will be a crucial part of your security. Is it WEP, WPA, or WPA2? Or do you have an open network with no encryption at all? 

Security best practice is to set up your Wi-Fi with WPA2. Since 2006, WPA2 has been the most secure wireless encryption standard. As you set up WPA2, for both your guest and non-guest wireless networks, make sure the password you use is secure (SEE ALSO: HIPAA Compliant Passwords). Don’t use the default password or username that comes with your wireless router! 

Have a HIPAA security question? Leave a comment and you may see your question answered on the next HIPAA Snippets video.



Tod Ferran (CISSP, QSA) is a Security Analyst for SecurityMetrics with 25 years of IT security experience. He provides security consulting, risk analysis assistance, risk management plan support, and performs HIPAA and PCI compliance audits. Check out his other blog posts.
Plug-and-Play POS: Can It Ever Be Secure?

Tackling the microwave nation mentality.

Brand Barney, Security Analyst
By: Brand Barney
As a microwave nation, we have a very plug-and-play mentality when it comes to electronics and devices. When my morning coffee takes longer than 60 seconds, I’m snapping my fingers, checking my watch, and rolling my eyes. In our minds, faster is better.

In a similar way, the microwave mindset is ruining Point-of-Sale (POS) security. From manufacturers to salesmen to implementation, the security process is broken.

Manufacturers

When a new POS system is created, manufacturers and developers go through a delicate balancing act. The object is to get a product out as fast as possible. The problem is, security infringes upon go-to-market time. The more security aspects they implement, the more competitors beat them to the punch. Unfortunately, this can be applied to just about every industry.

My point? Many manufacturers don’t take the time to ensure their products are secure before they slap the “100% PCI Compliant” sticker on it.

Salesmen

POS manufacturers are great marketers. “This POS system is secure!” or “Guaranteed compliant!” are great ways to differentiate from the competition...but often aren’t necessarily true.

Merchant implementation

The faster a merchant can enjoy the benefits of a new POS system, the more money he makes. The less time he has to spend fiddling around with settings, the more he can spend making pizzas, or shining shoes, or developing software for his business.

Merchants are told by manufacturers, salesmen, and installers that the system is safe, so they plug it right in to their environment without a second thought. On occasion, POS systems aren’t properly configured right out of the box, which can lead to devastating malware being uploaded onto the POS device. Additionally, the POS device itself may be missing crucial patches.

So how does a business compensate for not-so-secure POS systems?Tweet: Securing Plug-and-Play POS http://bit.ly/1stXAcu How does a business compensate for not-so-secure POS systems? #SMBTweet
Here are three important questions to consider before installing a point-of-sale-system in your cardholder data environment.

1) Are all vendor-supplied security patches installed?

It doesn’t take long for a POS system to become ‘old.’ Here’s what I mean. Every second after a released update isn’t installed, the system falls further and further from security and non-compliance.

Chances are if you’re running an old POS system in your environment, it’s riddled with weaknesses. Maybe you missed a few security patches along the way. Or maybe it’s no longer supported by the manufacturer.

Even if you bought and installed a new POS system every week (a ridiculous notion, I know), your security wouldn’t be foolproof. Technology increases so rapidly, that by the time you got the brand new system home or to your business, a new update may be waiting to be installed.

SEE ALSO: Shellshock: Be Wary, But Don't Panic

That’s why updates are so important to maintaining point-of-sale security. I recommend going to the POS manufacturers website to discover the most recent patches and updates for your device…right after you read the rest of this post of course.

2) Has your environment been tested for vulnerabilities?

If you dip a marshmallow in a pot of melted chocolate, what color is it when you pull it out? Brown. It’s unlikely any amount of licking will get it back to pure white.

Just like my marshmallow example, a squeaky-clean POS system can become immediately infected if placed in an insecure environment.

That’s why your payment processing environment must be regularly tested for vulnerabilities, both internally and externally. Not only should you scan your environment every quarter, but you should scan before and after ANY changes are made including installing a new POS system.

Some business owners, POS installers, and even IT experts think, “We have a quarterly test coming up in 2 months, let’s worry about scanning then.” Or, “We just ran a vulnerability scan yesterday, I’m sure our system is fine.”

WRONG!

Hackers search for the smallest of holes to squeeze into a business environment. Weaknesses are discovered every minute. Resolving the issues you find in your vulnerability scan immediately prior to installing any new technology will save you a lot of heartache in the long run and may save you from a business crippling data breach.

3) Whose responsibility is POS security? The manufacturer, the installer, your IT guy, or the merchant?

Many merchants believe security is being dealt with by someone else and thereby means it’s not their problem. This is wrong. It is always the merchant’s responsibility to make sure a POS system is secure, fully patched, and devoid of known vulnerabilities. That means it’s also the merchant’s responsibility to pay for any breaches that result from an insecure POS system.

No matter how pushy he is, don’t let your IT guy or POS installer talk you out of testing your systems before going live. Even if he’s someone you trust. Remember, you’re ultimately the one liable if something goes wrong.

If your IT guy balks at all the security precautions (testing, updating, vulnerability scanning, remediating vulnerabilities, etc.) remind him that you require rigorous testing of all systems prior to production, no matter the device or system.

Remember the story of the tortoise and the hare? Slow and steady wins the race. Stop racing to a breach and start walking to security.

SEE ALSO: 7 Hearty Tips to Avoid Costly Data Breaches

SOS

If you need help with POS configuration, vulnerability scanning, installing security patches, (anything!) PLEASE ask for help. Contact your POS vendor, PCI vendor, or your QSA who will be happy to help you secure not only your POS environment, but the rest of your systems as well.

What other security questions do you have?


Brand Barney (CISSP) is an Associate Security Analyst at SecurityMetrics and has over 10 years of compliance, data security, and database management experience. Follow him on Twitter and check out his other blog posts.