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
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.
It’s good to keep patients entertained while in the waiting room. According to 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
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.
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.
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.
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
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.
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!
How should organizations prepare for an audit now?
ESPINOZA:
Gather your documentation now. Organize it.
Conduct an annual risk analysis. Not only is it HIPAA required, it makes sense.
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.
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. :)
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
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.
The victim must be logged into a site using HTTPS (and the session cookie must not be expired)
The victim must browse to another website over HTTP before the session cookie expires
The attacker must write a custom JavaScript code to exploit POODLE. To date, no prepackaged tool has been published to exploit POODLE
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.
The IT security failure spanning every healthcare organization.
By: Brand Barney
October is National Cyber Security Awareness Month so I thought I’d close out the month with a security tip for our IT friends in healthcare. First, let me give you a big high five on EHR security. Your EHR security is gaining serious traction. Most of you have started to implement unique usernames and passwords on the EHR level. Now let me break the bad news. You still have work to do. And I’m not just talking to small practices here. I’m talking to medium entities. Big hospitals. Even organizations with a large IT staff. Here’s why. HIPAA mandates each healthcare organization employ unique login IDs and passwords. IT professionals, doctors, and compliance managers think that requirement is covered because their EHR has a unique username and password for every employee. But at the network level, they don't. What that means:
You’re not HIPAA compliant
You’re leaving patient data unsecured
Your network’s vulnerabilities pose great risk to your EHR security
Let’s pretend you have a very secure password for your EHR, but your networked computers aren’t protected by a secure and unique password. Let’s also pretend that your organization left remote desktop protocol wide open, or some IT guy left the Telnet protocol wide open. Both scenarios are extremely common in any healthcare network size. A hacker cracks your crappy network password and gets in. He installs keylogger malware that records everything you type on your keyboard. He starts watching your traffic. In a matter of hours (or minutes) he now has the password to your ‘super duper secure’ EHR system. Whoops.
Mark my words. If you are breached in the next few years, it will likely be because of one of these three reasons:Tweet
Bad business associate practices
Insecure remote access
You didn’t use secure and unique IDs, passwords at the network level
You’ve got to make sure the network security on your systems is buttoned down. And it all starts with unique login IDs and passwords.
It’s not just about good passwords; it’s about unique ones too
Let me give you an example that applies to practically every healthcare environment. My example dentist office has 4 stations for patient cleaning, running a Dentrix EHR system. The computer login to station 1 is hyg01. The password is drbrown1. SEE ALSO: HIPAA Compliant Passwords Any security professional (or hacker) could crack that username/password combo in a matter of moments. The dentist office probably thinks that password is totally secure because it has more than 8 characters and a number. Wrong. But the most grievous part of this scenario is that the username and password are static. They’re not specific to the hygienist or doctor. Anyone can log on to that computer. The dentist’s EHR (Dentrix) may have unique user IDs and passwords, but each station doesn’t. Riddle me this. If your organization has a breach, how do you prove who got in if every single person at your organization has the same login as everyone else? How would you prove, as an employer, who stole or lost patient data? Consider this healthcare scenario. A 21-year-old former employee lost his job. He’s bitter about it. And guess what? He knows your usernames and passwords because no one has their own. He vindictively thinks, “I’m going to take some patient data. Besides, you can’t track it back to me anyway.” In 2014, Intermedia found at least 89% of employees retain access to at least one login and password from their former employer. 45% retained access to confidential or highly-confidential data.
Here’s another example.
Sometimes, computer stations aren’t even locked. I was recently consulting at a dental office and asked the office manager if I could walk around. As I walked passed one of their computers, I flicked the mouse. The computer popped right up at Dentrix with an open patient record. Not only had the dental hygienist not closed out of the patient record, but the system hadn’t been configured to require machines to pop up at the login screen when opened. If an attacker had walked in and grabbed a machine, their entire system would have been available to him.
The problem? Laziness? Lack of direction?
Now, I used to work at Dentrix. I know Dentrix systems have the capability to require users to authenticate every time they login to Dentrix, if configured appropriately. I also happen to know that most (if not every) computer system in the world has the ability to set up uniquely identifiable usernames and passwords for multiple users across a network. So why is no one implementing screen savers? Why is no one implementing unique IDs and passwords? IT guys know better. They’re often lazy, or don’t have the stomach to inform the C-level their current password situation isn’t good enough. Or worse, the C-level is restricting the IT staff from implementing these measures because they don’t think it’s necessary. Setting up unique user IDs and passwords does require a bit of work (hours depend on organization size) from IT. It takes enabling the Active Directory Domain Services (AD) role. A system has to be set up with a domain controller(s) that pushes the policies for unique user IDs and passwords to the forest of computers at an organization. Need active directory guidance for Windows Server 2008, Windows Server R2, and Windows 2012? How to implement strong password policies on computers running Windows 2000, Windows XP, and Windows Server 2003.
Conclusion
I don’t mean to be too harsh here, but healthcare’s security is embarrassing. Please, for the sake of your organization and your patient’s data, make the simple change to require unique usernames and passwords on the network level for each one of your staff members. Don’t let the myth that ‘our EHR security covers patient data’ convince you otherwise. Remember, your security matters!
(Thanks to SingleHop for inspiring the Get Involved NCSAM campaign for cybersecurity, and this post!) 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.
Prevent stolen tablets, smartphones, and laptops with these basic tips.
By: David Ellis
Practically every business has access to at least one laptop, tablet, and smartphone. For many organizations such as a local restaurant or clinic, these devices help provide quicker access to information, transactions, and services than ever before. A problem with physical data security begins when users forget to adequately protect these devices. We inadvertently abandon our technology devices in unlocked offices, forget them on subways, leave them in our cars, and let our kids play with them. According to Healthcare IT News, 9 of 10 of the largest Health Information Portability and Accountability Act (HIPAA) data breaches were caused by physical security issues.
If you store, transmit, or process sensitive data on a device, you will be held liable if any of that sensitive data is lost. Tweet
If there is a compliance guideline behind that data, serious repercussions, including financial penalties could arise. Standards like the Payment Card Industry Data Security Standard (PCI DSS) or HIPAA include such data protection requirements and consequences for mishandling sensitive information. Consider implementing these basic physical security guidelines to your business strategy to protect trade secrets, customer data, and your business.
Control physical access to your workplace
The best way to control the physical threat is through a physical security policy, which includes all the rules and processes involved in preserving the business. If you keep confidential information, products, or equipment in the workplace, keep these items secured in a locked area. If possible, limit outsider office/business access to one monitored entrance, and (if applicable) require non-employees to wear visitor badges at all times. Don’t store sensitive information (like payment card data) in the open. Many hotels keep binders full of credit card numbers behind the front desk, or piled on the fax machine, for easy reservations access. Unfortunately, that also means the collection of files is easy access to anyone within arms reach of the front desk or fax.
Keep inventory of all removable devices
Not allowing devices to go home with their users is an important step to keeping data out of the hands of criminals. Some healthcare offices require their employees to check out a tablet each morning and return it to a locked safe at day’s end. Each user has an assigned tablet slot, and it is obvious if the space is left empty. Another solution you might consider is attaching external GPS tracking technology on all laptops, tablets, external hard drives, flash drives, and mobile devices. SEE ALSO: Balancing Mobile Convenience and PHI Security
Document physical security processes
It’s crucial to document the who, what, when, where, and why of device use to determine the responsible party if data is lost. Items that should be documented include a list of authorized users, locations the device is assigned or is not allowed, and what applications are allowed to be accessed on the device. Oddly enough, it’s also recommended to document what sensitive data your business is trying to protect. Obviously, that must also be protected, and strict controls must be placed to allow access only to authorized users. Download a free physical security policy template.
Train your employees
While you care about customer card information, patient data, or your own proprietary data, your employees may not. That’s why regular security trainings are so important. Social engineering is a serious threat to smaller businesses. A social engineer uses social interaction to gain access to private areas, steal information, or perform malicious behavior…and your employees fall for their tricks more often than you think. If a man walked into your storefront and told you he was there to work on your network and needed you to lead him to the server room, would your employees think twice to further identify him and verify his presence? SEE ALSO: Social Engineering - It's OK To Be Paranoid Train your employees to question everything! It’s better to be safe than sorry. Establish a communication and response policy in case of suspicious behavior. Train employees to stop and question anyone who does not work for the company, especially if the person tries to enter back office or network areas.
David Ellis (GCIH, QSA, PFI, CISSP) is Director of Forensic Investigations at SecurityMetrics with over 25 years of law enforcement and investigative experience. Check out his other blog posts.
The newest Payment Card Industry Data Security Standard (PCI DSS) officially goes into effect on January 1, 2015. With the introduction of PCI DSS version 3.0, many merchants want to know how it will affect their business. Here are answers to a few commonly asked questions.
1. Why is there a new standard?
As always, new security guidance addresses the latest vulnerabilities affecting today’s merchants and also includes additional clarification. Three main reasons contributed to this updated security standard:
Increased clarification: The new standard helps merchants more accurately comply with the PCI DSS by clarifying some of the previously unspecific requirements.
Additional guidance: New guidance sections provide layman’s explanations of why standards are important and how noncompliance may put your business at increased risk.
Evolving requirements: As technology, threats, and security risks change, the PCI DSS must adapt to the changing environment. PCI DSS 3.0 has evolved to not only address emerging threats, but also new technology like EMV, P2PE, and mobile payments.
The transition from PCI 2.0 to PCI 3.0 will affect everyone governed by PCI. If you store, process, or transmit payment card information, this change affects you.
3. When is the PCI DSS 3.0 deadline?
January 1, 2014 was PCI 3.0’s effective date. However, PCI DSS 2.0 compliant merchants have until January 1, 2015 to transition to the new standard. Some changes will continue to be best practices until June 1, 2015 (see question 8). This means merchants do not need to revalidate until their compliance expires. For example, if your annual validation occurs in November 2014, you technically don’t need to validate compliance to 3.0 until November 2015. However, you are required to be compliant with the new standard starting January 1, 2015.
4. What does PCI DSS 3.0 mean for my business?
If you follow PCI 3.0 requirements, you will eliminate the majority of your business risk to compromise. PCI DSS 3.0 focuses on detecting, rather than reacting to, security vulnerabilities. But the standard only works if merchants comply. The best thing merchants can do now is review their compliance status. If you have a passing grade, great! Now it’s time to review PCI 3.0 requirements to make sure you will be in compliance once January 1, 2015 hits. If you have a failing grade, PCI 3.0 is a great time to reevaluate your security and begin securing your business.
5. What will happen on January 1, 2015?
If you haven’t complied with PCI 3.0 by January 1, 2015, you will technically be in violation of PCI DSS. If you are compromised, you may face heavy fines due to your noncompliance.
6. What is the biggest change for ecommerce merchants?
If you are an ecommerce merchant, the biggest change for you will be the new SAQ A-EP. Originally, ecommerce merchants were validated using SAQ A but many of those merchants must now move to a SAQ A-EP, which includes more requirements. Learn which ecommerce methods qualify for SAQ A-EP.
7. What new documentation does PCI DSS 3.0 require?
Documentation is a key theme of PCI 3.0. For example:
1.1.3 requires a cardholder data flow diagram that shows how cardholder data enters your network.
2.4 involves the creation of an inventory list of all your in-scope device types and their function (e.g., POS systems, computers).
9.9.1 requires an up-to-date list of all devices, including physical location, serial numbers and make/model.
11.1.1 involves maintaining a complete list of authorized wireless access points and the justification for each.
12.8.5 requires a list of all third party service providers in use, a list of all PCI requirements the service providers meet, and a list of PCI requirements the merchant is required to meet
8. What are the new ‘best practice’ requirements?
The PCI Council knows some requirements will take more time for merchants to apply. There are six requirements considered ‘best practice’ until they are officially required on June 2015. They are:
6.5.6: Insecure handling of PAN and SAD in memory
6.5.11: Broken authentication and session management
8.5.1: Unique authentication credentials for service providers with access to customer environments
9.9: Protecting of point-of-sale devices from tampering
11.3: Developing and implementing a methodology for penetration testing
12.9: Additional requirement for service providers on data security
9. How can I ensure compliance with PCI DSS 3.0?
The only way to ensure lasting compliance with the PCI DSS 3.0 is to make data security part of your company culture. According to Bob Russo, GM of the PCI Security Standards Council, PCI 3.0 is “about making PCI compliance part of your business, not a once-a-year, study-for-the-test kind of thing.” The new standard helps you implement security controls without disrupting your day-to-day processes—allowing you to focus on your business while maintaining appropriate data protection.
10. What is SecurityMetrics doing to help me with PCI DSS 3.0?
To simplify the transition, SecurityMetrics will update its SAQs, customer interface, and PCI scoping wizard on January 1, 2015. As part of the PCI 3.0 SAQ, select standards will be written in easy-to-understand language for the ease of the user. Because PCI 3.0 introduces more SAQs, SecurityMetrics will offer combination SAQs when more than one SAQ applies. SecurityMetrics is excited for the new 3.0 changes, but understands this can be a frustrating time for merchants. That’s why live 24/7 support is always available for all SecurityMetrics customers.
Giles Witherspoon-Boyd (PCIP) is Enterprise Account Manager at SecurityMetrics and assists businesses in defining their PCI DSS scope. Follow him on Twitter and check out his other blog posts.
What businesses can learn from armadillos, seahorses, and zebras.
By Giles Witherspoon-Boyd
Hackers are a lot like predators in the wild. After finding an unsuspecting animal, nature’s hunters test their victim for weaknesses before taking it down. Just like nature’s hunters, hackers aren’t looking for a challenge. They’re looking for an easy target.
Unfortunately, it seems as if hackers are always one step ahead. So how do you avoid becoming dinner? Take a clue from nature. It’s all about defense mechanisms.Tweet
1. The Lookout
Dwarf mongoose post sentries that stand on their hind legs to watch for birds (their main predator). When a bird is sighted, they send a warning call to others and run to safety. Just like the sentries that stand outside dwarf mongoose burrows, businesses have file integrity monitoring software, or log monitoring. Log monitoring systems collect and store logs. Logs are user actions inside an operating system (e.g., renaming a file, opening an application). Some systems have a real-time reporting system (like the dwarf mongoose call) that alerts you via email or text of suspicious activity. Reviewing logs on a regular basis helps identify malicious attacks on your system. According to the PCI DSS, businesses are supposed to have 12 months of logs stored, with 3 months readily available. Systems that have log monitoring capabilities include operating systems, Internet browsers, point of sale systems, firewalls, and intrusion detection systems (IDS). Some systems do not automatically enable logging (e.g., Windows XP out of the box has logging turned off).
2. The Upgrader
In the animal kingdom, bigger is often better. A larger, stronger set of antlers helps white-tailed bucks successfully battle other males during mating season. Every year, they shed their antlers to grow bigger ones for next season.
Just like deer upgrade their antlers, you should be regularly updating your software to make sure it has the most up to date patches for security vulnerabilities. Devices and software that should be regularly updated include: operating systems, anti-virus software, POS terminals, firewalls, intrusion detection systems (IDS), mobile devices, Internet browsers, app software, and more.
3. The Hider
Everyone knows that chameleons change colors to match their environment and allow attackers to pass them over. But so do seahorses, cuttlefish, octopus, and dozens of other animals. Changing colors is a great defense mechanism for animals without strength or stamina. Just like these animals hide their vulnerable bodies, it’s important for you to hide what’s most important to your business: customer credit card data. Did you know 63% of businesses store unencrypted card data? If a credit card isn’t encrypted, it’s completely exposed on your network, with no camouflage protecting it from predators snooping around. Encryption is the best way to hide data, but by finding and deleting unnecessary data, you have nothing to hide. After all, hackers can’t steal what isn’t there.
4. The Tank
Some animals undergo structural changes to protect their bodies from predators. Take the thick skin of the armadillo. It’s made of an armor-like substance and can roll into an indestructible ball if the armadillo is threatened.
The structural change businesses should use to protect their business is a firewall, both software and hardware. Like a security guard, properly configured firewalls control what goes in, and what comes out of your business. SEE ALSO: How Does a Firewall Protect a Business?
5. The Trickster
Zebras use their striped pattern as an optical illusion to confuse predators. Because each zebra has a unique striped pattern, it’s difficult for predators to single one out.
Businesses should apply the zebra strategy to passwords. Each network, device, and user should have a unique username and password. In addition, make sure each of those unique passwords are difficult to guess. The easiest way to create a tricky password is by creating a passphrase. Anyone love Corey Hart’s 1980’s hit, “I wear my sunglasses at night”? If you do, good. If not, too bad. It’s turning into my example passphrase. To create a complex passphrase, take the first letter of each word, and substitute special characters/numbers where you can. I wear my sunglasses at night --> Iwmsg@n1980!
6. The Teacher
In a recent study on lion cubs, researchers learned lions aren’t born with a natural fear of humans. They learn it from their mothers and the rest of the pride. For a species like lions to continue to prosper, their defense mechanism is to quickly teach their young to avoid other species that could harm them…aka humans.
Training is such a crucial security strategy. I can’t count how many compromises could have been prevented if staff were simply educated on the dangers of hackers. Business owners, IT staff, and managers must train staff members on physical security, phishing, passwords, policies, etc. so they can take the necessary steps to protect the business.
7. The Intimidator
Have you ever seen a lizard do a pushup? Those lizards are showing their strength to intimidate predators. Do you know the reason gazelles jump so high? It’s to demonstrate their ability to outrun pursuers. You know those lizards that flare extra skin around their neck when they are threatened? By doing so, they appear larger and more threatening to those that may try to eat them.
With nothing but their body language, animals signal to predators, “Attacking me is not worth your time. So don’t even try.” While it’s difficult to show to a hacker just how strong your business security posture is, the best way all-around way to maintain solid security is by complying with the PCI DSS. That means going through each section of the Self-Assessment Questionnaire (SAQ) and ensuring your organization’s compliance with all the requirements. SEE ALSO: Which PCI SAQ is Right for My Business? If you liked this post, please share!
Giles Witherspoon-Boyd (PCIP) is Enterprise Account Manager at SecurityMetrics and assists businesses in defining their PCI DSS scope. Follow him on Twitter and check out his other blog posts.
Increase security and take the pain out of HIPAA compliance.
This article is an excerpt from our ebook, 5 Healthcare Security Lessons From the Field. To download your free copy of the complete ebook, click here. With over 10 years of security assessment and audit experience, we have seen wide ranges of network environment complexity, IT staff experience, and executive team support. One consistency in the overwhelming majority of our assessments are deficiencies in data security, even in well-established organizations employing experienced IT staff.
Here is just one of the many lessons we’ve learned from the most commonly overlooked security errors we see in healthcare organizations. Learning about, identifying, and resolving these security mishaps in your organization will not only increase your security, but also help you take the pain out of the HIPAA compliance process.
Understand your data flow
In order to protect your patient data you must understand the flow of protected health information (PHI) throughout your network. Your PHI flow includes where PHI enters, moves, and is stored in your system.
From the field
A lack of communication between departments can lead to not understanding your data flow, which often creates security and compliance issues. During an onsite interview with customer service representatives, we discovered they were recording PHI in notebooks or Excel spreadsheets for future reference. These new copies of PHI were not protected or encrypted in any way. In fact, one representative showed us her desk drawer with dozens of notebooks filled with PHI. Not only is unencrypted PHI a HIPAA violation and security issue, but the fact that the organization was unaware of this practice is a big problem.
Take the pain out of HIPAA compliance
Example of a simple flow diagram
Fully understanding where PHI resides takes a lot of interdepartmental communication. Consult with all departments and individuals that collect, enter, store, transmit, or interact with PHI and create a PHI flow diagram based on your findings. (see picture) This exercise will assist in conducting a thorough risk analysis and identify where to focus security measures at your organization to adequately protect PHI. Want more tips? Download your free copy of the complete ebook here.
How do you encourage your employees to make security a priority?
By: Gary Glover
Employees can make or break your security. Like my colleague David Ellis says about phishing, “It doesn’t matter if you have the most secure security system in the world. It takes only one untrained employee to give away the data you’ve worked so hard to protect.” The importance of employee security training is why the PCI Council released a 25-page document on security awareness programs at the end of October 2014 called Best Practices for Implementing a Security Awareness Program. The document provides further knowledge that merchants may reference while following PCI DSS Requirement 12.6.
The guidance document explains, “One of the biggest risks to an organization’s information security is … the action or inaction by employees and other personnel that can lead to security incidents—for example, through disclosure of information that could be used in a social engineering attack [and] not reporting observed unusual activity.” The document hits the nail on the head. Multiple sources site human error as the main culprit for data breaches. In fact, according to Deloitte, over 70% of companies rate lack of employee security awareness as a vulnerability.
Whether it's a laptop stolen out of an unlocked car, password sharing, insider leaking of sensitive information, or simple ignorance, employees can cause a lot of organizational hurt.Tweet
Where do businesses go wrong?
Many merchants simply do not provide ongoing security training for their employees. It takes an educated person to be able to discern ‘secure’ versus ‘not secure’, and training is the first step in that education. Need security training for your employees? Learn more here. Another reason behind employee data breaches is the simple fact that humans forget. Employees need constant reminders of the importance of security. The content and methods of communication between regular trainings is a big part of what this new PCI guidance document addresses. Ultimately, the document gives some great pointers on instilling a culture of security among your employees. Here are my takeaways for successfully creating security awareness at your organization.
Gather a security awareness team
This team is responsible for the security awareness of your employees. Your team should include personnel with varying responsibilities from different departments. Team members should be the examples. They should recommend secure practices in your organization, and make sure information is disseminated so every employee has the chance to make security a part of their work behavior.
Develop security awareness content
Security awareness can be delivered in a variety of methods. I recommend annual formal training and other forms of communication as reminders, such as e-mails, employee newsletters, posters in break rooms, and memos. Types of training vary greatly based on what your employees do every day. For example, if you employ cashiers, specialized training for them may include how to inspect POS devices for tampering at the beginning of their shift. If you employ developers, their training will be much more in depth and include secure coding practices. Here are a few important things your training should include:
This checklist should be a list of all the things that must happen to keep your security awareness program running at your organization. I adapted a checklist from the PCI Council document, which you can download and use at your security awareness team meetings here. Don’t let your employees ruin all your hard security work. Organizations with a security awareness program in place are 50% less likely to have staff-related security breaches. Train them! Teach them to care about the security at your organization, and you will avoid a lot of potential heartache.
Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 9 years of PCI audit experience. Check out his other blog posts.
Windows Schannel vulnerability affects every Windows user in the world
Microsoft just reported and released a patch to a vulnerability (CVE-2014-6321) on November 11, 2014 that affects every single Microsoft Windows user in the entire world. CVE-2014-6321, commonly known as the Windows Schannel vulnerability, has the potential to be as catastrophic as Heartbleed for Microsoft users. After all, there are over 1 billion Windows PCs in the world today.
What is and isn’t affected?
Every supported Microsoft operating system and software on this list should be patched immediately. This includes both servers and workstations. Because the vulnerability affects a user’s operating system, it has the potential to allow attackers to compromise most applications on your computer. Apple OS, Linux, UNIX, and BSD systems aren’t affected by this vulnerability, and neither are applications that use other SSL libraries, such as Chrome, Firefox, and Safari.
What should I do?
5 words: Patch your Windows OS immediately. This includes all supported versions of Windows OS, such as: Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1.
How does the vulnerability work?
As of right now, we don’t know how the vulnerability works. The vulnerability was identified in an internal audit performed by Microsoft who did not release the nature of the exploit to the public.
What we do know is, Schannel is Microsoft’s closed-source version of SSL and Microsoft has informed the public that there was a remote code execution vulnerability. This means an attacker could execute commands to gain control of any computer or server running an unpatched version of Windows OS.
How does this affect me as a SecurityMetrics customer?
Because there is no exploit for Windows Schannel, remote vulnerability scanners can’t detect it…yet. But it’s only a matter of time. When an exploit for Windows Schannel is released, SecurityMetrics will work to include a check for the vulnerability in its vulnerability scanning engine. We recommend you update any Windows OS immediately. If you have any questions, please contact SecurityMetrics support, 801.705.5700.
Developers do not follow secure coding guidelines, but it’s not entirely their fault.
By: Brand Barney
According to OWASP, one in five companies experienced a data breach due to a web application security incident. Those are pretty bad odds. Unfortunately, coding flaws translate into bad security more often than you might think. Now, I hate to bash on coders/developers. Some of my best friends are developers. But, I have to be honest about organizational problems in order to help businesses fix security vulnerabilities. And that means exposing the truth about development culture. Here are five reasons coders might ruin your audit…and your security.
1. Coders regularly have heavy deadlines that may lead to scrappy quality
From a business standpoint, it makes sense to push product as fast as possible in order to beat competition to market. Well, from a security (and coding) standpoint, that is an absolutely ridiculous idea. Coders don’t have the luxury to take their time with secure code. They have bosses, product managers, directors, and VPs harping them to push code as fast as they can. The faster code is pushed, the less time is spent making it secure, and the more mistakes are likely to be made.
2. Coders don’t always use proper documentation
Each developer in your team probably comes from a different background and has a variety of skills and coding languages up his sleeve: PHP, Java, C, C++, Perl, Ruby, etc. Newbies, veterans, and job jumpers are all familiar with different code. The problem is, they are collaborating on similar projects. Consider this very common scenario. A developer is assigned to add a function to an existing product. He writes the function in an hour. Then, he finds a problem with the code written by one of his predecessors, and his function won’t work until he fixes the problem. So he goes hunting for broken code that he has no idea how to fix. No documentation exists that tells him who wrote the code, when it was written, or why it was created. Because his team never had a formal policy on code writing, he just wasted six hours to push that function (One hour writing the function, and five hours to fix the problem). The majority of the time, developers write comments in the code, which I highly recommend. However, if comments are literally the only code change documentation, all it takes is one accidental line deletion and that “documentation” is gone forever. Check out these hilarious comment examples taken from real code.
// Dear maintainer: //// Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy: //// total_hours_wasted_here = 42 //
/** You may think you know what the following code does.* But you dont. Trust me.* Fiddle with it, and youll spend many a sleepless* night cursing the moment you thought youd be clever* enough to "optimize" the code below.* Now close this file and go play with something else.*/
//This code sucks, you know it and I know it.//Move on and call me an idiot later.
// If this comment is removed the program will blow up
// I am not sure if we need this, but too scared to delete.
//I am not sure why this works but it fixes the problem.
/* after hours of consulting the tome of google i have discovered that by the will of unknown forces without the below line, IE7 believes that 6px = 12px */ font-size: 0px;
3. Coders aren’t magicians
It’s probably safe to say that no developer knows every library and language framework out there. If you ask a web developer to create a scrolling, randomizing function that works on mobile devices in C++, what does he do? He’ll likely Google it. Developers are living, breathing Google machines. The problem is, half the solutions they find on the Internet (and then implement in product and web code) are 10 years old, or have since proven to be insecure!
4. Coders code on personal, unencrypted machines
Many companies hire temporary developers during a product launch or for a new website. Usually those developers code on their personal machines. All it takes is one stolen, unencrypted laptop for a hacker to have your entire web code to himself.
5. Coders experience burnout
Coders truly are artists. They wish to create beautiful secure code that’s well-organized and designed. But good code rarely makes it into work projects. Good code is what your coders do in their free time. It’s what they look at when they’re feeling depressed at work. Why? Like I mentioned above, most companies don’t give them license to use good code. The stress of yesterday’s (and tomorrow’s) deadlines slowly beat them down. They start staying long hours to get work done. Then they come to work the next day with a new pile of requests. Burnout is the eventual fate of many great developers. The more burned-out a developer is, the less likely he will care about his code being secure.
How do you break the cycle?
Yes, I just made some serious accusations. Many organizations deny these problems happen on their team. “We have too large of a budget for this to happen!” or “My third party does all my coding. No way they have a problem with this!” Well, that’s where you’re wrong. I guarantee that at least one of the above problems happens in 99% of organizations, regardless of size, budget, or team. Before you begin to fix it, you must get the C-level to understand it’s happening. It’s not enough just to hire more developers or fire everyone and start over. Remember, this is a cultural problem that transcends your own organization.
If management and development members don’t understand the costs and damage insecure/sloppy coding can have on the business, it’s time to educate them on the benefits of secure coding practices.Tweet
Start secure coding practices
Following coding standards makes it simple to focus on security, rather than spending time fixing problems in code. If coding standard guidelines are spread across your organization, coders will easily finish each other’s work while constantly maintaining secure code. If your coders don’t come from a security background, ask them to review the OWASP Top 10, and NIST guidelines. Here are my recommendations to include in your secure coding practices methodology.
Test outside of production
Making changes in a production environment is one of the most insecure actions a developer could ever perform. Unfortunately, it’s extremely common. Product managers need a quick product change so they push development to release it as fast as possible. In this case, fresh, untested code is allowed into the wild … along with any accidental vulnerability. Ensure your methodology requires that developers test code outside of production to avoid these situations.
Code review
I hear this all the time, “Our guys are testing their own code, no worries!” I applaud those who test their own code, but that’s not enough. Code should always be reviewed to catch mistakes through external and internal vulnerability assessment testing. For bigger code releases such as product releases or a new website, it’s imperative to receive a penetration test to ensure your organization is secure and safe from malicious entities.
Patch management
I attended a talk at DefCon 2014, where a white hat SQL researcher discussed how he exploited Oracle’s SQL database for years. He then reported the flaws to Oracle…who would leave the problems for years before fixing them. This unfortunate company is a great example of bad patching practices. Security best practice is to always patch code flaws immediately. If you are participating in compliance mandates, you may have deadlines to consider as well. SEE ALSO: Cross-Site Scripting, Explained
Code documentation
Not only will proper documentation ensure your success as a team, but it also helps drive the team to understanding the prioritized needs of the entire project. As I suggested above, don’t let code comments become your only form of documentation. I recommend that you follow and disseminate a properly outlined software development lifecycle. This will help your organization and developers create and maintain your applications in a secure manner. This lifecycle should include development methodology, training, vulnerability testing, change control forms, etc. For instance, anytime code is changed, developers should use change control forms to document how the change will impact customers, how it might change functionality, how it impacts security, if there are any back out procedures, etc.
Summary
The vast majority of developers do not following secure coding practices. It could result from poorly managed development teams, or just poor product planning in general. Until your plan contains documented, formalized, and secure coding practices, problems will continue to happen. Businesses will continue to lose data. You will fail your security audit. Start changing your coding culture today! Have coding security questions? Ask away! 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.
How can you secure your organization without knowing how patient data travels?
By: Tod Ferran
Every privacy/security/compliance official should understand the specific details of how patient data flows in their organization. For example, the point of entry, where it flows within an organization, where it is stored, what format it's stored in, exit points for the data, and where it travels. That’s a lot of information to keep straight, especially for large providers and hospitals with dozens of departments. How does an official keep track of that? Data flow diagrams.
Example of a patient data flow diagram
Data flow diagrams are the graphical representations of PHI flow throughout your systems. They are a crucial part of every healthcare’s HIPAA security efforts, especially while creating a complete and thorough risk analysis. SEE ALSO: HIPAA Security Tip: Understand Your Data Flow Unfortunately, lack of data flow diagrams is the #1 problem I see when auditing healthcare entities. Organizations simply don’t have them. How are you supposed to implement appropriate safeguards if you don’t know which areas to safeguard? Maintaining a current PHI flow diagram is absolutely foundational to your security program and HIPAA compliance.
Besides being a great overview of your systems, here are a few specific reasons you should be creating data flow diagrams:
IT doesn’t always set up networks with security in mind. Tracking where PHI travels, enters, and exits will help you track any strange processes and adjust for efficiency.
By recording every instance of PHI, you can determine which systems, computers, and users require extra (or less) security technology.
Data flow diagrams help IT when it comes time for upgrades, as the diagram shows every computer/role, database, and network that should be included in an upgrade.
If your organization undergoes a breach, you will be able to track the possible weaknesses that could have led to the compromise.
Your HIPAA audit will go significantly faster if a PHI data flow diagram is already created. I speak from experience here. Your auditor will absolutely love you for it.
What does HIPAA say about data flow diagrams?
Data flow diagrams can greatly enhance network security and can make your HIPAA compliance process easier. While HIPAA doesn’t specifically state providers must provide a data flow diagram to be HIPAA compliant, the OCR Audit Protocol does state that auditors must, “determine if the covered entity has identified all systems that contain, process, or transmit ePHI.” What better way to do that then to request a healthcare provider to deliver a PHI flow diagram?
The healthcare security audits I conduct would go much faster if the entity simply had detailed PHI flow diagrams of their system.Tweet
The following is a step-by-step process to help you correctly create flows in your healthcare security environment.
Step 1: Scope definition
The first step is learning where your data resides. This is also the first part of a HIPAA Risk Analysis. (Need help with your risk analysis?) Scope is an inventory of all the places your organization accesses, creates, stores, transmits, or maintains PHI. The following may or may not be in scope (containing PHI), depending on your environment: •EHR •Database •Server •Security appliances •Patient admissions •Email system •Data warehouse •File shares •Ticketing systems •Telephone recordings •Tablets/smart phones/mobile devices Take a few minutes and try to identify everything in scope.
Step 2: Interview workforce members
Oftentimes, it’s simply not possible to create a data flow diagram on your own. The only way to ensure accuracy is to interview every single workforce member who has access to PHI. Your employees might know about random processes or data exits that no one else knows about. Interview process owners, web developers, sales force, physicians, third parties, etc. SEE ALSO: 5 Things You Should Know About Minimum Necessary PHI This step is the hardest of the bunch. Trying to track down every PHI location, its flow, and what process put it there is exhausting and extremely time consuming. That’s why keeping detailed documentation of your findings is crucial to your flows…and your sanity.
Step 3: Create flow diagrams
In congruence with your findings from steps 1 and 2, flow diagrams further help you illustrate the location and flows of PHI. It often makes sense to have a separate diagram for each different in-flow and for each different out-flow. Once a diagram is completed, you never have to create it again! All you have to do is update it if processes change, or you change vendors.
Data flow diagrams will make your life easier. I promise.
It’s somewhat embarrassing when healthcare organizations don’t have something so important to their data security as flow diagrams. If your organization is actively working toward its HIPAA compliance, your data flow diagram will play a crucial part in that development. Let me know if you need help with your flow diagrams by commenting below, or schedule a consulting session with me by emailing audits@securitymetrics.com or calling 801.705.5656.
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.
Vulnerability scans are automated tests that locate vulnerabilities, or holes, in business environments that could allow a hacker access into a network to steal customer credit card data.
Not only are quarterly vulnerability scans one of the easiest and best things you can do to remain secure, they are also a Payment Card Industry Data Security Standard (PCI DSS) requirement for most merchants.
The period between Thanksgiving and Christmas sees more frequent credit card purchases than any other time of year. In fact, according to CMO.com, total holiday season sales for retail are expected to reach $863 billion this year. The bummer is, this increase in transactions may also mean a potential increase in liability if a business has been breached. Businesses can and should protect themselves from hackers trying to take advantage of the uptick in holiday transactions by running vulnerability scans as often as possible and fixing the problems those scans find immediately. Discover more about SecurityMetrics vulnerability scanning.
Remediating vulnerabilities can help you avoid common hacking tactics, like SQL injection and remote access exploitation. And if you need help, SecurityMetrics technical support agents are standing by 24 hours a day, 7 days a week to assist with scans and vulnerability remediation.
Exchanging patient data securely takes planning and effort.
By: Tod Ferran
I don’t envy the healthcare industry. On one hand, Meaningful Use wants providers to increase the flow of records and on the other, HIPAA wants them to decrease compromise. That’s a lot to have on your plate. The quick, easy, and digital exchange of patient data has rocketed the healthcare industry light-years into the future. Health Information Exchanges (HIEs), for example, allow healthcare providers within a geographic area to contribute and access electronic patient data, usually to and from a centrally managed data repository.
I’m sure you can see how this would increase quality through all stages of the healthcare process. Now, all providers are linked together and can see, share, and provide additional data to a patient’s clinical context, potentially improving the timeliness and accuracy of care decisions and avoiding duplicate procedures. BUT, exchanging patient data in a secure fashion is more difficult than it seems. Perhaps that is why The Ponemon Institute reported that 72% of providers aren’t confident in the security and privacy of patient data shared via HIEs.
HIE member security
Let’s discuss HIE members. HIEs can connect tens of thousands of healthcare providers. But if HIE members do not have secure controls in place and one is breached, the HIE connection between all providers could potentially become a path to your patient data. Data exchange also has legal liabilities as well. If an HIE member is breached, they can be brought to court by fellow HIE members in a civil lawsuit. SEE ALSO: The #1 Way to Help Your HIPAA Audits Go Faster Some HIEs work hard to reinforce their systems against hackers, apply security best practices, and encourage each member’s individual data protections. Here’s a great example of one of them. The Utah Health Information Network (UHIN) wanted to go further than just passing their OCR pilot audit with flying colors. To do that, they needed to get their members on board. They created a customized, already-paid-for member program that includes security consulting, a self-assessed risk analysis, external network vulnerability scans, and a breach protection checklist. They also do a wonderful job of evaluating the clinical data being viewed, and who is viewing the data, to catch abnormal behavior (such as an attacker attempting to gain access) and block the activity. This is a great example of an HIE protecting and bringing their members to the next level of security. Now….what’s your HIE doing?
Our advice for HIE members
At the speed the healthcare industry is going, data exchange will continue to outpace security.Tweet
But for those who truly wish to avoid a devastating data breach, ensure your HIE partner has the expertise, resources, and implemented safeguards to secure your patient data, no matter who it is exchanged with. If you’re not sure what your HIE should be doing, have a look at ONC’s health IT security resources. They discuss security from the standpoint of an EHR user, but some of the same best practices should be followed by HIEs – such as encrypting all data maintained by the HIE, safeguarding its computer network with a firewall, and protecting its employee workstations with passwords and anti-virus software. Find out what your HIE is doing for security. Challenge them on it. If you’re not satisfied, it’s time to go shopping.
Did this post help you? If so, please share!
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.
PCI security assessors visit service providers to poke through every nook and cranny of company policy, documentation, and network security for PCI compliance. Ninety-nine percent of the time, we find problems, even in well-established organizations employing experienced IT staff. Most organizations get the obvious requirements, like encrypting card data. However, some important aspects of PCI are often missed. I’ve used my experiences over the last six years to compile a list of top security mistakes service providers make. Hopefully, it will aid you in your quest for data security and PCI compliance.
1) Not understanding your scope…and what data you’re storing
A group of blind men come upon an elephant in the middle of the road. Each touch one part of the elephant to figure out what it is. One touches the elephant’s trunk and thinks it’s a snake. One touches the elephant’s leg and thinks it's a tree. One touches the elephant’s ear and thinks it's a fan.
Departments sometimes act like the blind men when it comes to defining their PCI scope. Chief technology officers decide which Self-Assessment Questionnaire (SAQ) applies without consulting other departments. IT departments make network decisions without understanding segmentation. Upper management makes plans for a new POS terminal without advising IT of their new responsibilities. In many instances, a view at the whole picture is neglected. SEE ALSO: PCI 3.0: What You Need To Know Just the other month, I spoke with an IT administrator who assured me the encrypted table in their department was the only place the company stored card data. Period. A few days later while talking to a help desk manager, I found an application that allowed customer service agents to type unencrypted credit card data in a comments field. See why interdepartmental communication is crucial to understand your PCI scope? To finish the story, it’s only after the blind men collaborate that they figure out what they’re touching is an elephant. In order to correctly scope your environment, all departments in the organization must collaborate.
If all departments aren’t involved in understanding and defining your card data environment, you’re left with a partial picture and insecure environment.Tweet
2) Thinking that policy is just paperwork
When people think encryption, they think security. When people think policies and procedures, they think boring paperwork. A few years ago, I helped a large company through their painful first year assessment. The next year, they transferred the card environment responsibility from one technical group to another. The problem was, they hadn’t communicated policies to the new group, who thought the environment was more complicated than necessary. So, they removed all network segments controlling card data security. Because someone forgot to clearly communicate policy to this new IT group, they had to go back and re-architect everything, making their second security assessment as painful as their first. Having clearly written policies and communicating those continuously to employees is a critical part of having a secure environment. If corporate management pushes the culture of security through company policies, it gives the “why” that guides employee decisions. If there is no “why”, people may fail to correctly implement controls, or may implement them sporadically and leave gaps in security.
3) Failing to sufficiently secure inbound and outbound access to the card environment
Breaches resulting in loss of cardholder data are rarely caused by one looming problem. Multiple issues like overly broad permissions, insecure remote access, and lack of file integrity monitoring all have a part in leading to card compromise. This is how it is with most breaches. A business’s last line of defense is its access controls (also known as firewall rules.) Most threats can be blocked by simply and selectively restricting access to places in the card environment. Unfortunately, secure access controls are rarely set up correctly. In fact, I see insecure inbound and outbound firewall rules in 90% of first time assessments. It’s common for people to make their outbound access rules overly permissive, or protect the wrong systems from malicious inbound traffic. When considering access controls, don’t forget the outbound rules. If correctly configured, these rules can help prevent attackers from getting card data out of the environment.
4) Not keeping systems up-to-date
Hackers and their sneaky tools find ways into organizations through vulnerabilities. The best way to avoid these vulnerabilities is by installing software updates that contain essential security enhancements. I conducted an assessment of a merchant whose main POS system server hadn’t been patched for 12 years -- 12 years! Needless to say, the system had a vast number of vulnerabilities. He hadn’t applied patches because he was convinced patching the system would break things in the process. Eventually, he had to replace the entire system because getting to current patch levels would be too difficult.
5) Assuming log monitoring is only for forensic investigators
Companies are great at monitoring logs for performance, but when it comes to log monitoring for security they really need to step up their game. Most people incorrectly view logs as important only after an event has occurred. What they may not realize is if they carefully monitor logs they can stop a breach before it even happens, or at the very least limit data loss. SEE ALSO: Why Encryption is (Sometimes) Not Enough A colleague of mine examined a business’s logs as part of their first time assessment. While reviewing intrusion detection system logs, he realized the company was in the process of being breached! It was truly lucky that my colleague sampled those logs. Because of the company’s lack of log monitoring, they probably wouldn’t have caught it until customers began complaining of stolen cards. In this situation, they had the notification tools in place, but weren’t bothering to watch them.
You can do it!
Without proper preparation, most organizations would fail their first PCI assessment. PCI compliance is difficult. There are many security aspects that service providers might never have considered. If service providers fix the five top problems I’ve listed, they’ll be way ahead of most, and much more resistant to compromise.
Mark Miner has been a Principle Security Analyst at SecurityMetrics for over 6 years. He is responsible for overseeing the activities of the company’s assessment teams and has completed over 80 PCI DSS and PA-DSS security assessments.
How do you block access to your systems (and sensitive data) from hackers in the outside world? The easiest way is through a firewall. Firewalls block bad guys from intruding into your private systems, while still allowing you to access the Internet and communicate with the outside world.
Learn more about firewall basics here: How Does a Firewall Protect a Business? So how does this apply to healthcare? Every organization that deals with sensitive information (such as credit cards, patient health data, or government records) should have both a hardware and software firewall to protect them from attackers. Watch the video below to learn best practices for healthcare firewall security in just 60 seconds.
So how exactly does a firewall help me?
A software firewall regulates data traffic through two things: port numbers, and applications. Depending on your firewall settings, your firewall could stop programs from accessing the Internet, and/or block incoming or outgoing access via ports. SEE ALSO: Understanding the HIPAA Application of Firewalls For example, Port 80 is your Internet connection. Leaving outgoing Port 80 open is ok, because that is what allows you to browse the Internet. Leaving incoming Port 80 open is a different story. If it’s left open, anybody could access your network through Port 80. One downside to a software-only firewall is that you have to train and maintain the software to recognize threats. As you add or update programs, your firewall will block them, until you tell it not to. Additionally it only protects the device it is installed on. That’s what it does by design. For a firewall to be effective, you must have enough knowledge to know which programs and applications to allow, and which ones not to allow. SEE ALSO: How to Configure a Firewall in 5 Steps But, software firewalls are only half your defense. All networks (whether small or large) need a physical hardware firewall. A physical hardware firewall is placed between your office network and the Internet and guest wireless (if you have one). We often call this a ‘perimeter firewall’ because it is protecting our network and systems at the perimeter of the outside world. It not only adds a layer of protection to our workstations, it also protects network devices such as printers, medical equipment, and telephone systems which often don’t have a software firewall available on them.
Why both a hardware and software firewall?
The difference between hardware and software firewall is this: A hardware firewall protects you from the outside world, and a software firewall protects a specific device from other internal systems.
Basically, the software firewall helps protect you from yourself.Tweet
For example, if someone tries to access your systems from the outside, your physical firewall will block them. But if you accidentally click on a virus-laden email that’s already managed to get into your system, your software firewall on the other computers in your office network may stop it from infecting them.
Don’t be a hero
Even if you have both a hardware and software firewall, they may be useless unless you have the right people monitoring and managing them. We’ve all heard about the Target breach of over 40 million credit cards. Did you know Target IT staff received firewall alerts 5 days and then again 3 days BEFORE any data was stolen? These alerts were ignored, which allowed the bad guys to continue the attack. It does no good if you don’t have the technical expertise to work with firewall rules, understand them, and react to the alerts generated. Contract with an IT professional to help you set up and maintain this crucial portion of your healthcare security. 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.
Is outsourcing a viable option for reducing PCI scope?
By: Gary Glover
Creating an easily navigated, customer friendly ecommerce solution is challenging. Building an ecommerce website that conforms to Payment Card Industry Data Security Standard (PCI DSS) requirements is even more difficult. That’s why many ecommerce merchants choose to outsource some or all of their website content.
The million dollar question is, should your business outsource the payment portions of your ecommerce website and leave site security to those with expertise?Tweet
Depending on how you outsource, you may be able to decrease your PCI scope and business risk. PCI scope is how PCI DSS applies to your business. Specifically, any system, application, or process that has access to credit card information is in-scope. With the introduction of PCI DSS version 3.0, a new SAQ was announced (A-EP) that changed which PCI requirements need to be validated for some types of ecommerce merchants. So how do you figure out which method of ecommerce outsourcing reduces the most scope? Of course, outsourcing payment pages does not eliminate PCI DSS responsibility. After all, third parties are not weakness-free. That’s why I can’t overemphasize the importance of choosing a PCI DSS compliant service provider who takes security seriously. Consider choosing a Visa-approved PCI compliant ecommerce website host with validated dedication to payments security. If a provider is attempting to pitch you on a cheaper, simpler ecommerce solution that downplays security or claims to be secure, don’t fall prey.
What are your outsourcing options?
Outsource entire website: If you outsource the entire ecommerce website to a third party, no ecommerce payment data should flow through your company systems. If you choose to outsource your entire website, (this means no web servers at your company!) your SAQ is A. Do note there is a price tag involved with an entire site’s creation, and you will have less flexibility in regards to design changes.
Outsource payment page only: Outsourcing just pages that involve the collection and/or viewing of credit card information is very popular among small to medium merchants. There are about five different ways an ecommerce payment page could be outsourced. The method used will determine your PCI Self-Assessment Questionnaire (SAQ). The key is to understand where the payment data fields actually reside, and to whom that information is transferred throughout the payment process.
The following is a technical breakdown of the five most common ways outsourced payment pages are created.
Redirection Link
In this very common process, customers are passed from the merchant website to a separate, third party site to process the card transaction by clicking on a link or button that fully redirects to a third party site. Traditionally, small merchants use redirection links to minimize scope and reduce liability.
The risk of compromise is reduced to an attacker accessing your web site and changing the link destination to one of his choosing. Since this is a fairly overt attack that requires a more complex backend built by the attacker, the impact related to a redirection breach is very low. This is part of the reason the PCI Security Standards Council (SSC) classifies redirection processing as SAQ A.
IFRAME
An IFRAME (inline frame) element on a merchant web page can be used to view a third party hosted payment page through a seamless window in the source page.
This solution is very similar to a redirection link since there is no HTML code hosted on the merchant website that is taking any payment data. The biggest advantage of IFRAMEs is they allow the merchant site to maintain branding while outsourcing all card data collection and processing to a third party.
Like redirection, payment pages viewed through IFRAMEs are infrequently involved in card compromises. As such, the PCI SSC classifies merchants utilizing IFRAME as SAQ A.
Direct Client Post
The direct client post (i.e. client side redirect) payment fields originate from the merchant website, but are processed by the user’s browser. This allows the merchant more control over the look and feel of the payment process, and results in no credit card data coming back to the merchant website. Credit card data is posted directly from the user’s browser to the third party payment service provider (PSP). However, the merchant is still in charge of protecting the location of the payment form code.
Because there is a higher risk of an attacker modifying one of these direct client post pages, PCI DSS 3.0 classifies this processing method as a higher risk and requires merchant to validate using SAQ A-EP.
JavaScript
The JavaScript method is a bit unique in that the customer computer executes code, which comes from the PSP, to create the payment form or operate on payment data in some other way (such as encryption).
Similar to direct post, JavaScript is a moderate-risk ecommerce processing method, and merchants processing in this manner are required to validate to SAQ A-EP.
Traditional Ecommerce
There’s always the option to find or write your own shopping cart, but taking the full burden of PCI DSS on your shoulders is quite demanding. With traditional ecommerce architecture, the merchant controls nearly the entire payment process, which may even include storing credit card data. It may seem attractive up front because of lower costs and increased control over the payment process, but after considering the effort to develop and maintain full PCI compliance for all ecommerce systems, it’s likely not worth it. Hackers are always looking for the biggest bang for their buck. In ecommerce processing, traditional ecommerce can be the Holy Grail. Because this approach can lead to a larger breach footprint, it is considered a moderate-risk processing method and requires a full SAQ D validation. SEE ALSO: 7 Hearty Tips to Avoid Costly Data Breaches
Next steps
Hopefully now, the reasoning behind certain SAQ ecommerce qualifications is a little clearer. Hopefully you’ve also realized that the outsourcing method you use dictates both your risk and the security you must implement in order to stay secure. PCI DSS 3.0 makes it very clear that merchants hold the responsibility to protect ecommerce transactions that originate from their website. Whichever way is best for your business, third party outsourcing means you have a few tasks to achieve PCI DSS compliance.
Do research to make sure your third party is following PCI DSS, and have a contract to back that up
Complete your required SAQ based on your ecommerce methodology and submit a report to your merchant processor
Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 9 years of PCI audit experience. Check out his other blog posts.
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
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.
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.
Tweet
