You may have seen some of the recent articles regarding a research paper that documented a discovered flaw in some commonly used encryption schemes, including those used for online transactions. I think it’s important to point out that the sky isn’t falling. That said this may be a good time to check your encryption processes and determine if this really applies to you. Within the paper the researchers determined using 1024-bit RSA provides “99.8% security at best.” This isn’t systemic for all processes; the researchers did not find the same problem after looking at 5 million OpenPGP keys (which is the source of the paper’s title). Without getting too far into the technical aspects of the paper, the researchers found that numbers used in the creation of the keys weren’t so random after all. This culminated in critical parts of the algorithm being similar to another key. Thus the keys were the same. What does this mean for you and your organization? Time to check your encryption settings and certificates. If you outsource this as part of your e-commerce solution, have the vendor validate their settings. If you use RSA keys you might consider changing them, of course this isn’t something that most organizations can/will do with minimal impact. One of the big questions I foresee is if this will affect your PCI Compliance? At this time no. While many recognize that risk posed by the redundant keys found by the researchers is significantly less than it might otherwise be, you most likely will be safe. However this is something to keep tabs on. If further research continues to find issues with how the prime numbers are generated within the methods, it may be time to start the switch. Overall, it’s important to remember that if you use the RSA keys, the sky isn’t falling all around you, just 0.2% of it is.
Social media has both helped and hurt organizations and healthcare is certainly no exclusion. Many entities are getting on, or have been on for some time, the social media band wagon. In fact this is not the first time we’ve mentioned it here on our own blog. Some organizations have seen a great boon when it comes to using the many varied venues of social media, with probably the exception of anyone still left on MySpace. However, social media can also hurt organizations, and while the cases tend to be somewhat cut-and-dry, “you posted a patient’s personal information on Facebook, so you are fired” it’s the organizational response which I find most interesting. Searches on the internet can find many organization’s social media policies posted online (I don’t understand this; but that’s for another day). Perusing these policies you get the gamut from ‘gentle guidance’ to Orwellian 1984-esque policies. So why such a spectrum? Organizational culture aside, they are mostly indicative to where breaches have occurred. While I understand that healthcare breaches are (starting to be) a big thing, I believe the over-handed policies go too far and will never make the changes they strive for. Some of these policies read like they are taking away an employee’s right to express themselves via any social media outlet without the oversight and approval of management, even if it’s their own personal account written during non-business hours. This is also usually followed up with web filtering to remove the ability to gain access to Facebook, Twitter, or other popular social media sites (sorry again MySpace). Ironically enough, I’ve seen this happen and then the company emails all employees saying to “like” the company’s Facebook page and/or follow their Twitter feed. This tactic will never work for a few main reasons. Human are social and companies can’t filter all channels to social media, even during business hours (i.e., smartphones). Remember when Egypt attempted to block Twitter during the protests? Short of the having the ‘Thought Police’ and ‘Ministry of Love’, people will always share their thoughts, some more than others. With the many technological advances it’s become easier and easier, now people can take a photo and upload it to their medium of choice in seconds. This can lead to some fairly significant issues for organizations, especially healthcare. So how does an entity prevent these breaches? By setting expectations with reasonable limitations. What I mean by this is educate everyone what is acceptable and what is not. Telling employees that they can’t say anything bad about their job isn’t going to work. Telling them that they can’t use copyrighted materials (logos) or act as a company agent on a personal blog is acceptable. Informing them of libel and how far is too far is key for when employees become disgruntled (hopefully this never happens to you). Understanding that filtering social media sites is not going to be a control that prevents material from getting online and that it will be a time management control at best (assuming smartphones aren’t prevalent). The successful policy both defines the acceptable boundaries of personal social media as it relates to the organization and educating employees on what to self-scrutinize before posting; pictures from work with a patient walking in the background, posts that may read like an organization-sanctioned post, etc. This ensures that the “what” comes across but also the “why.” This balanced approach is at least easier for organizations that don’t yet have their own Thought Police.
While getting compliant and passing your yearly Report on Compliance audit or filling out a Self Assessment Questionnaire is important to your organization and your customers (and a requirement for merchants and service providers), the PCI Data Security Standard (DSS) is intended to be the foundation of an ongoing program, ensuring you follow best practices throughout the year. I continue to work with clients who overlook the maintenance aspect of the DSS, and few things are worse than scrambling to update everything at once while you are in the middle of an audit. In this past year, I have come across several instances of companies who overlooked a key time-based DSS requirement and were forced to use compensating controls or simply could not meet compliance because of the oversight. The DSS does little to protect your cardholder data and systems if you think of it as something that you only have to do once a year. Maintaining your program should be like maintaining your house: don’t wait to fix that leaky pipe, repair the broken window, fix the lock on the door, and take out all of the trash right before your mother-in-law shows up – you don’t want to deal with it all at once, and neglect can lead to increased effort, expense, security gaps, and non-compliance. Similarly, following a scheduled maintenance routine can help you purge unnecessary accounts and data, provide visibility into your processes, train personnel, and ensure that different business units are aware of and performing their expected duties. The cheat sheet in the following whitepaper was developed to help you prioritize, schedule, and assign responsibility for the tasks that must be performed on a periodic basis to meet DSS 2.0 requirements. Throw this in a spreadsheet, update your group calendar, or transfer this to your GRC tool, and then off to the beach for a Mai-Tai! Care and Feeding of your PCI DSS Compliance Program
In my experience, one of the security management processes that causes the most confusion among security stakeholders is the periodic risk assessment. Most major information security frameworks such as ISO/IEC 27002:2005, the PCI Data Security Standard, and HIPAA, include annual or periodic risk assessments and yet a surprising number of organizations struggle with putting together a risk assessment process. Fundamentally, the concept of a risk assessment is straightforward: identify the risks to your organization (within some defined scope) and determine how to treat those risks. The devil, of course, is in the details. There are a number of formal risk assessment methodologies that can be followed, such as NIST SP 800-30, OCTAVE, and the risk management framework defined in ISO/IEC 27005 and it makes sense for mature organizations to implement one of these methodologies. Additionally, risk assessments at larger companies will often feed into an Audit Plan. If you’re responsible for conducting a risk assessment for a smaller or less mature company, though, the thought of performing and documenting a risk assessment may leave you scratching your head. The first step in any risk assessment is to identify the scope of the assessment, be they departments, business process, systems and applications, or devices. For example, a risk assessment at a financial services company may focus on a particular business unit and the regulated data and systems used by that group. Next, the threats to these workflows, systems, or assets should be identified; threats can include both intentional and unintentional acts and may be electronic or physical. Hackers, power outages, and hurricanes are all possible threats to consider. In some cases, controls for addressing the vulnerabilities associated with these threats may already exist so they should be taken into account. Quantifying the impact to the organization should one of these threats be realized is the next step in the risk assessment process. In many cases, impact is measured in financial terms because dollars are pretty tangible to most people but financial impact is not always the only concern. Finally, this potential impact should be combined with the likelihood that such an event will occur in order to quantify the overall risk. Some organizations will be satisfied with quantifying risk as high, medium, or low, but a more granular approach can certainly be taken. When it comes to treating risks, the options are fairly well understood. An organization can apply appropriate controls to reduce the risk, avoid the risk by altering business processes or technology such that the risk no longer applies, share the risk with a third party through contracts (including insurance), or knowingly and objectively determine to accept the risk. At the conclusion of all of the risk assessment and treatment activities, some sort of documentation needs to be created. This doesn’t need to be a lengthy formal report but, whatever the form, it should summarize the scope of the assessment, the identified threats and risks, and the risk treatment decisions. Results from the Audit Plans can also assist in this documentation process. Most organizations already assess and treat risks operationally and wrapping a formal process around the analysis and decision-making involved should not be overwhelming. Of course, different organizations may need more rigor in their risk assessment process based on internal or external requirements and this is not meant to be a one-size-fits-all guide to risk assessment. Rather, the approach outlined above should provide some guidance, and hopefully inspire some confidence to security stakeholders who are just starting down the road of formal risk management.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.