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.

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.

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

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.

With the announcement that KPMG really is going to start performing HIPAA Privacy Audits in the New Year, we’ve had numerous conversations with healthcare providers around getting their privacy and security programs up to scratch. 

It’s a well-known secret in the healthcare industry that HIPAA compliance does not receive the attention (or the funding) that it should.  There are of course exceptions and I should note that most security and privacy professionals in the healthcare industry take their jobs very seriously and honestly do consider the protection of patient data to be their number one priority.  But, it’s often difficult to do your job if you don’t have the funding or resources needed to do it properly.

The federal government hasn’t helped – creating a mandatory requirement, but not putting in place any mechanism for testing compliance with that requirement rapidly creates a sense of non-urgency.  What’s the point of REALLY making sure that we’re HIPAA compliant if no one’s going to check?  It costs a lot of money, it’s annoying to doctors, it’s not even the slightest bit sexy, and it’s going to impact options to the organization.

And, if none of your competitors are limiting themselves and spending extra money on ensuring HIPAA compliance, a healthcare executive is going to see true HIPAA compliance as a competitive disadvantage.  Now it looks like everything is going to have to change.  Don’t believe me?  Think the audits are going to be ‘no big deal?’  Let’s draw a parallel with another compliance requirement – PCI DSS.

For those of you not familiar with PCI, you should be – you probably have to comply with this as well.  In any case, it’s the data security standard inflicted on merchants and service providers (companies that facilitate credit card payments) by the large credit card brands (VISA, MasterCard, etc.)  Anyone that takes (or processes) a credit card for payment needs to be PCI compliant.

Although the card brands catch a lot of flak for ‘inflicting’ PCI on the world, the truth of the matter is, something needed to be done.  Credit card data was not being protected and it was costing the card brands a LOT of money in fraudulent charges and impacting consumer credit ratings.  If they hadn’t created their own standard the government most likely would have.

When PCI was first rolled out to the community there were a lot of merchants that thought it was no big deal, but they didn’t plan on three things:

1. The card brands were perfectly willing to let non-compliant merchants make ‘examples’ of themselves (link, link)
2. The legal community quickly learned what ‘PCI-compliant’ meant and how not being PCI-compliant could be used in things like multi-million dollar class-action lawsuits
3. The PCI standard gave consumers a benchmark against which to judge the merchant’s brand.

These points have been effective because the card brands maintain a unified front when it comes to PCI (they all agree to the codified requirements as the baseline required by merchants to transact credit cards securely) and because they have a mandatory audit mechanism in place that gives them the power to take action if the merchant or service provider isn’t complying with PCI.

I think that we have the same dynamic going on now with HIPAA.

1. KPMG is going to be looking to justify their million dollar contract with the government – they will find issues with compliance during their audits.
2. The legal community is already very aware of privacy breaches in healthcare and what that means for things like multi-million (and multi-BILLION) dollar class-action lawsuits (link, link, link)
3. Everyone now has a benchmark against which to judge how much a healthcare provider cares about their patients’ data

I think that it’s time to figure out a plan on how to really address HIPAA – both in the short-run (i.e. achieving an initial compliant state) and long-run (maintaining compliance moving forward.)  If you aren’t familiar with the recent announcement involving the upcoming audits here’s a link on the HHS site which includes a sample of the letter that will be sent out to organizations.  Also note – the first round of audits is going to focus on Covered Entities, but future rounds will also include Business Associates.

For some additional information on how to put together a workable approach to really achieving HIPAA compliance please see material on the NetSPI blog and NetSPI services pages.  Also – NetSPI will be putting together whitepapers, additional blog posts, and (possibly) a webinar on this topic over the next couple of months.  Please check back here for more information, make a comment, or send me an email (link below) if you would like to discuss.

The problem is that individuals have found that they can recover the silver found within the film. While it isn’t a lot of silver (roughly 2% of the film’s weight) a few hundred pounds could make it a lucrative venture. That’s why it’s not surprising that thieves have begun stealing them. Let’s be honest here, when was the last time you checked the credentials of the crew coming to take away what you would consider to be garbage?

The issue here isn’t that these films will be used for identity theft purposes, it’s that you are now forced to go through breach notification procedures at your cost… for what is technically considered refuse! Three organizations in Pennsylvania already had to go through this as they’d fallen victim to thieves stealing the films from unsecured areas, and in one instance posing as a radiological film destruction company.

What can you do? Start securing X-rays and make sure they aren’t accessible to unauthorized parties, regardless whether the file is useful or scheduled for destruction. Many organizations store the X-rays near the equipment in semi-open rooms. If the rooms aren’t used 24×7 then you should either secure the room when not in use using your normal physical security system (key, badges, dragons, etc.) and monitoring equipment. If you don’t want to go to such extreme measures (I hear dragons eat a lot) then you may consider digitizing your x-rays and then securely dispose of the physical copies. Otherwise you may want to start recovering the silver yourself to help pay for the breach notification efforts you might find yourself facing.

Further reading:

http://www.ehow.com/how_4501375_extract-silver.html

http://www.ehow.com/facts_7786835_xray-silver-recovery.html

http://philadelphia.cbslocal.com/2011/10/17/thieves-seeking-quick-steal-x-ray-film-from-area-hospitals/

http://www.jeffersonhospital.org/Patients/scrap-x-ray-film-theft.aspx

Initially I thought of trying to showcase some of them in a silly reference; but I thought it might be too OPAQUE.

O – Overreacting is not going to get you through the event

P – Preparedness is key

A – Accept that it will happen to you

Q – Quit keeping old data

U – Understand the laws that impact your organization

E – Empathize with your customers/patients/employees – how are they going to react to your response?

In all seriousness; Q and A (no pun intended here) are both important and I wanted to point those two out.  

If you don’t need the data, as an organization you need to ask yourself, “what are we gaining by keeping this data?”  The liability is attached to every piece of information you retain regardless if you use it or not.  Having (and following) data retention policies will limit such a liability. 

Accepting that it is going to happen, now that’s a hard pill to swallow.;but similar to Emergency Preparedness techniques that many organizations routinely practice.  As they say, practice makes perfect even if you never have to use those techniques.  Organizations that routinely train for various circumstances are the ones best prepared to handle them.  If you accept that a data breach is going to happen, you’ll find yourself equipping and (more importantly) training for how to respond.  Whether you attach this to existing emergency practices or not is not as important as actually having a response.  Many organizations have suffered both from a Public Relations perspective and financially (fines) by their seemingly lack of response. 

In the end, training staff how to deal with data breaches because you accept that it will happen will yield positive results from a negative situation.  It’s amazing how people remember what to do during emergency situations; I still remember to get under my desk during an earthquake.

• Why is NetSPI not listed on their website? (Answer: We don’t need to be; we meet other requirements that make us qualified certifiers)
• Is NetSPI allowed to certify our application before you are listed on DEA’s website? (Answer: Yes)

According to 21 CFR 1311.300(a), there are two alternative processes for achieving the necessary qualifications:

1. “A third-party audit conducted by a person qualified to conduct a SysTrust, WebTrust or SAS 70 audit or a Certified Information System Auditor as stated in 21 CFR 1311.300(b), which comports with the requirements of paragraphs (c) and (d) of 21 CFR 1300.300” or
2. “A certification by a certifying organization whose certification process has been approved by DEA”

Therefore, the certification process emphasized within the clarification is simply one of the alternatives, and is in no way required or mandatory.  While the principal consultant involved with the EPCS Certification is a Certified Information System Auditor (CISA) in good standing, there should not be any issues with qualifications.  Experience with SysTrust, WebTrust, or the slightly outdated SAS-70 (in my opinion) are more a derivative of training provided by ISACA as part of CISA.

The bigger question would be whether having appropriate qualifications is the only measure by which you should select your certifying agent. This is where things like experience with certifying applications in other standards, experience in healthcare, and understanding of software development lifecycle can be significant differentiating factors.  Certainly, like with any other regulatory standard, there will be (perhaps already are) many low-cost, rubber-stamp firms that might get you the certification letter you are seeking.  They may let you replace application controls with policies and documentation, conduct the whole assessment by phone, and turn the whole certification process around in 24 hours.  However, obtaining the certification is only the first step in the long journey of maintaining DEA EPCS compliance.  If your client decides that your application does not meet requirements or is in violation of EPCS, you will have to investigate all such claims and if confirmed, announce to all of your customers that they can no longer use your application to prescribe or accept electronic prescriptions of controlled substances. (21 CFR 1311.302) 

While it may seem appealing to take a run at getting through the certification fast, trust me, taking this shortcut is not a good idea, and any perceived savings of time and money will likely come back to haunt you in the future.  Going for the low-cost auditor in this case may actually be the most expensive option.

Finding Sensitive Data
There are a lot of great tools available for finding data quickly on a SQL Server. Some are commercial and some are open source. Most of them can be useful when gathering evidence during PCI penetration tests or when simply trying to determine if sensitive data exists in your database. In this section I’m going to cover how to find and sample data from SQL Servers using my TSQL script, and the Metasploit module based on the script.

TSQL Script – FindDataByKeyword.sql
This script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the script and take a sample of the data. For more information please refer to the comments in the script.

Important Note: This script does not require SYSADMIN privileges, and will only return results for databases that the user has access to.

1. Download the “finddatabykeyword.sql” TSQL script from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/finddatabykeyword.sql.
2. Sign into an existing SQL Server using Management Studio.
3. Open the “finddatabykeyword.sql” TSQL script. Next, set the “@SAMPLE_COUNT” variable to the number of rows that you would like to sample. If “@SAMPLE_COUNT” is set to 1, then the query will also return the total number of rows for each of the affected columns that contain data.
4. Then, modify the @KEYWORDS variable to set words to search for. Each keyword should be separated by the “|” character.
5. Execute the “finddatabykeyword.sql” TSQL script to sample data from columns that match defined keywords.

Metasploit Module – mssql_findandsampledata.rb

This is my first Metasploit auxiliary module. I recently wrote it with a little help from humble-desser and DarkOperator. The module is essentially a Measploit wrapper for my original TSQL script. Currently, this script will search through all of the non-default databases on the SQL Server for columns that match the keywords defined in the keywords option. If column names are found that match the defined keywords and data is present in the associated tables, the script will select a sample of the records from each of the affected tables. The sample size is determined by the samplesize option.

Before I provide an overview of how the module works, I would also like to thank Digininja. His original Interesting Data Finder module (http://www.digininja.org/blog/finding_interesting_db_data.php) was my starting point for this script. Although, I didn’t use much of his IDF module, I did borrow his method for auto sizing columns. So Thanks! I think it’s a good time to mention that I haven’t submitted this to the Metasploit code base yet, because I would like to finish a few additional options. So enjoy the sneak peak! Hopefully some one finds it useful. Below is an overview of how to use the Metasploit module:

1. Download and install the Metasploit Framework. It can be downloaded from:
   http://metasploit.com
2. Download the “mssql_findandsampledata.rb” module from:
   https://github.com/nullbind/Metasploit-Modules/blob/master/mssql_findandsampledata.rb
3. Copy the “mssql_findandsampledata.rb” file into Metasploit. Below are the locations it should be copied to for Metaploit Framework and Pro:

       Metasploit Framework –Windows (Free Version):
       C:\framework\msf3\modules\auxiliary\admin\mssql\
   
       Metasploit Pro – Windows (Commercial Version)
       C:\metasploit\apps\pro\msf3\modules\auxiliary\admin\mssql\

4. Open a Metasploit console. Important Note: The pro version of Metasploit is not required.
   
5. Select the “mssql_findandsampledata.rb” auxiliary by typing: “use auxiliary/admin/mssql/mssql_FindandSampleData”
   
6. Set the required configuration parameters as illustrated below. Please note that enabling file output is not required. Also, IP ranges and cider notation can be set via RHOSTS.
   
7. Type “show options” to confirm you’ve entered your information correctly.
   
8. Type “exploit” to enumerate data from the remote SQL Server and write it to a file. If it fails confirm that the IP address, port, username, and password are correct.
   
9. Open file in excel for easy viewing and sorting.
   

Hopefully someone will find these scripts useful. If anyone has feedback or questions please feel free to email me. I always welcome the opportunity to improve scripts, approach, share knowledge etc. Also, next time I will be releasing a TSQL script and Metasploit module for attacking shared services accounts. In the mean time good hunting.

For those that suffer through this during your Policy Update sessions, there a few ways to break out of this cycle:

1. Establish a Grace Period when policies are updated. This is usually established within a policy about policies (feel like the definition of recursion?). Some organizations will issue policies with a Published Date and next to it an Effective Date. This reminds readers about the Grace Period while reinforcing the expectation that compliance is required in the near future.

a. Pros: Staff can work towards compliance by the established deadline without the label of ‘Non-Compliant.’ Project plans, budgets, and resources can be lined up to tackle the changes.

b. Cons: Effective dates may be too soon for some large changes, but having different effective dates for some projects but not everything leads to confusion. If the timeframes don’t run in parallel with budget cycles then there may not be enough available funds for changes that require fiscal resources. The other concern is that during the Grace Period, there may be the perception of having two active policies which may lead to some confusion.

2. Establish, or merge with an existing, Exception Process for non-compliant areas when the policies are published. If there are areas of non-compliance when the policies are updated then an exception must be immediately requested for a temporary acceptance. Part of this exception process will be to establish a plan of attack for reaching compliance.

a. Pros: The exceptions help to prioritize the identified non-compliant areas which may make it easier to see the total cost of compliance; this method is easier for organizations that have strong Project Management departments.

b. Cons: It may be overwhelming for the team reviewing all the exception requests. Especially for those that can’t assess all associative risks (such as business versus IT risks). There will also be overhead to track all the exceptions and the deadlines. Continual exception requests will have to be managed appropriately.

3. Establish a Hybrid Approach. This method takes a little from each above with tweaks to meet the needs of your organization. For example, establishing a short Grace Period for new / updated policies and anything that will need longer must be identified immediately and go through the Exception Process.

a. Pros: A sooner effective date will meet with regulatory requirements quicker. There may be a smaller Exception handling team yet the organization still receives the benefit of using Project Management to handle the outliers.

b. Cons: It is easy for this method to slide more into the Exception Process without the constant enforcement of the effective dates. A shorter Grace Period may result in an unexpected amount of Exception requests depending upon the policy.

Regardless of the method, the most successful implementations negate the Cons listed above with two major factors: (1) Management’s full support (which includes enforcement) and (2) communication.  Lack of those two elements often will leave you with a feeling that the wheels are spinning, but you aren’t moving.  Of course funding, or the lack thereof, is like a car with no gas – it’s only great if you want to go where you already are. 

The corporate culture may also dictate which approach is more likely to succeed.  Proactive organizations usually try for the Grace Period method while reactive organizations are better suited for the Exception Method.  This isn’t a slight against one or another, but in those instances the culture has established tools and workflows designed for one or the other. 

For example; reactive cultures are usually found in healthcare, especially hospitals, since that’s the name of the game: reacting to the events around them.  Financial institutions tend to be more proactive due to many of the existing regulations (SOX, GLBA, etc.).   It’s not to say that you won’t find Proactive healthcare institutions (which some are trying to be) or reactive financial organizations. 

Hopefully adoption of one of the above methods helps during your next Policy Update cycle so you can make changes happen; as behaviors, controls, and other requirements usually won’t change just because they can. 

“Catch-22 says they have a right to do anything we can’t stop them from doing.