The Insider Threat

At this year’s PCI Community Meeting there was a great presentation done by Verizon Business Services on their 2011 Data Breach Investigations Report.  However, one of the things that concerned me about their presentation is that they seemed to downplay the threat insiders pose to the breach of information.

So, I went back and reread their report because I did not get that same interpretation when I originally read the report.  On page 42 of the Verizon report, there is a discussion of “Errors.”  Errors are defined “as anything done (or left undone) incorrectly or inadvertently.”  According to this section, there were 219 instances out of the total 761 breaches where insiders contributed to the breach.  That computes to almost 30% of all breaches.  That is almost twice the 17% quoted as a highlight in the front of the report and used to justify the downplaying of the insider threat.  So the insider threat is still substantial and should not be ignored.

The biggest problem with the insider threat is that it does not matter how much technology you have in place to protect your information assets as it only takes one person in the right place to neutralize every last bit of your high-tech security solutions.  Just ask anyone at any of the recently breached organizations how all of their technology functioned when they suffered their breach.  I am sure they will tell you the technology worked just great – not so much for their people.

First, there are the mistakes everyone makes that are done in the name of efficiency or politeness.

• The sharing of a manager password to expedite a process in the name of good customer service.
• The holding open of a door to a secure facility because someone’s arms are full.
• The swiping of your access card and letting others tailgate through a secured door to be polite.

At the end of the day, we all are guilty at one time or another of doing these things as well as many other bad security acts.

That is the real problem we all face and why security standards focus so much on a layered approach also known as defense in depth.  The hope is that with multiple layers in place, even if one or two layers become non-functional due to the people issues, another layer will stop or at least detect the issue and the issue will be averted or minimized.  However, in most cases, if someone can get the right software onto the right user’s computer, it really does not matter what security is in place.

The first example of such a breach was of RSA back in March 2011.  As the story goes, through the use of electronic mail, attackers targeted RSA network and system administrators with messages containing an Excel spreadsheet as an attachment.  The spreadsheet contained backdoor software that was surreptitiously installed on the computer providing the attackers with remote access into RSA’s network.  With remote access, the attackers are free to scope out the RSA network at their leisure.  Over time, the attackers obtain the code for RSA’s SecurID servers and FOBs.  Once discovered, RSA is forced to replace SecurID FOBs for free to their customers.

Right on the heels of the RSA breach was the breach of Epsilon in April 2011.  Epsilon was a quiet firm that did the electronic mail marketing and loyalty programs for such businesses as Best Buy, Kroger, Marriott and LL Bean.  It creates the biggest opportunity for spear fishing ever seen.  Based on news reports, Epsilon was attacked in a similar fashion as RSA although the two breaches have never been linked to the same attackers by authorities.

In May 2011, the apparent fruits of the RSA breach were unleashed on Lockheed Martin and rumored to have also been unleashed on Northrup Grumman and L3 Communications.  Using fake FOBs, the attackers broke into Lockheed Martin and attempted to gain information from Lockheed Martin’s systems.  News reports indicated that the Lockheed Martin attack was eventually repelled and no information was obtained by the attackers.

Citigroup suffered a double whammy of bad news in June 2011.  The first hit was the admission that their online banking site had been compromised and more than 350,000 customer accounts had their information leaked to the attackers.  Then on June 26, a former Citigroup executive was arrested for embezzling $19 million while they worked in the treasury finance department.  The first event was front page news in the papers and on the Internet.  The second event barely made a notice.

The reason I bring these breaches up is that while these computer attacks are big news, they point to the fact that the bigger threat is actually the people you employ.  The reason why attackers targeted these companies’ employees is that insiders have direct access to information and, in most cases therefore, that attackers do not need to hack any computer systems to gain the information.  This is bore out in the fact that security survey after survey keeps confirming that the vast majority of compromises are the result of some amount of insider involvement.

All organizations are at significant risk to the insider threat because most have done little or nothing to prevent it.  Sarbanes Oxley and the like have done no one a favor in propagating this view of controls.  This is why I think a lot of organizations push back on complying with the PCI DSS, they abhor controls and want nothing to do with controls of any type.  You hear arguments regarding the “stifling of creativity” and “make do work” which are nothing more than whining from people that have no clue as to why controls are needed.  I have documented in a previous post the three phases of a well structured control environment, so I will leave readers to review that for reference.  Properly designed and implemented, internal controls make a big difference because if people know that someone is looking over their shoulder to ensure that their job is done properly, that in and of itself goes a long way to keeping everyone honest as well as minimizing operational errors.

However, just because you have controls does not mean that everything will go smoothly.  A lot of organizations have a great control environment on paper, but do very little to ensure that it is executed as written.  We see time and again organizations that talk a good game, but when you start looking at their operations, the control environment is a paper tiger because no one is enforcing those controls and the controls are being followed haphazardly, if at all.

Then there are the organizations that have never reviewed and streamlined their controls since the founding of the organization.  These sorts of companies have created a controls monster.  What has happened is that as the business encountered a new issue, a new control was placed on top of other controls to address the new threat.  Over the years, all of these controls now keep a huge bureaucracy busy doing nothing but making sure that controls are controlled.

While some of this problem can be laid at the feet of management, it is not entirely all their fault.  Custom and packaged application developers have only recently started implementing security and controls into their software that allow the level of granularity necessary to meet SOX, PCI and other security requirements.  In most cases, security has always existed in applications, just not at the level necessary to properly ensure the security of sensitive information in today’s environment.

The lesson here is to ensure you have controls in place to ensure the security of your sensitive information.  If your applications that process, store or transmit sensitive information do not have the capability to properly protect your sensitive information, then you need to create manual controls to fill in any gaps.  Those manual controls need to have the ability to provide feedback so that if they begin to fail, someone is alerted to that fact and can step in and get the controls functioning again.

Advertisement

Meaningful Security Awareness Training

Is there really such a thing or am I dreaming?

For any of you that are involved in security awareness efforts, you know what I am talking about.  Security awareness training efforts just do not seem to catch fire or interest anyone, even yourself.  So what is one to do?  The reason I bring this topic up is that I attended an FS-ISAC Webinar where Lance Spitzner of SANS offered a very interesting idea in regards to security awareness training.

Before I get too deep into security awareness training, a bit of background.  Mr. Spitzner pointed out in his presentation that human beings are very bad at judging risk.  Worse yet, since most people have a poor understanding of the Internet and technology, that risk judgment gets even worse as most people, even IT professionals, just do not seem to get the risks presented by the Internet.  He presented numerous examples of just how bad people are at risk evaluation without information or a frame of reference.

If you think this is a fallacy, go and read peoples’ Facebook and LinkedIn pages.  The amount of proprietary and sensitive information that can be gleaned off of social media pages is terrifying.  But it is not just social media that creates problems.  Organizations do it to themselves all of the time with their own Web sites.  In the name of openness and marketing savvy, organizations post amazing amounts of proprietary and sensitive information on their own Web sites.  The ready availability of all of this proprietary and sensitive information lends itself to making a successful social engineering attack a foregone conclusion.

As I like to point out in my social engineering presentations, no one walks down the street indiscriminately handing out their business cards to everyone they encounter.  The looks I get from that statement are truly amazing.  Most of the people in the room do not get it and, unfortunately, probably never will get it until they are breached.  However those that do get it usually turn pale as it is usually the first time they realized the seriousness of the situation and the amount of risk to their organization all of that information presents.  When you are on the Web, organizations and people post their life stories for anyone and everyone to see.  Is it any wonder why the DEF CON “How Strong Is Your Schmooze” social engineering contest is so successful?

I have thought about this situation a lot lately as social engineering becomes more and more one of the tools used to initiate a breach.  I keep coming back to what can we do to minimize this disaster?  Security awareness training just does not seem to be working and then I run across Lance Spitzner’s presentation to FS-ISAC.  Mr. Spitzner states that people are just like any other device in the mix.  He points out that Microsoft patches Windows every month on ‘Patch Tuesday’, so why are we not “patching” people at least monthly.  What an idea.

Mr. Spitzer stated me to thinking about people as running the human operating system, or hOS as I prefer to now call it (my apologies to Apple).  And all of a sudden, viewing people as devices running hOS clarifies security awareness training.  Now, I know there are some that will chastise me for dehumanizing people.  But I justify my doing that in the fact that it needed to happen so that we can better understand and educate people so they are less at risk.

If you accept the premise that people should be treated no differently than any other device, then you know that security awareness training on hiring or an annual basis is just not often enough.  Microsoft issues patches to their software monthly if not more often in emergencies.  Since human beings are terrible at judging risk, then how can only annual security awareness training address the issues in hOS?  And that is just it, annual training cannot.  hOS needs to be regularly “patched” just like every other operating system.  That means at least a monthly patching cycle.  But doing monthly “patching” is not just all you have to do for hOS, you also need to make the “patching” relevant to hOS.

This is where subscribing to news and information security RSS feeds or listservs to track what the hot issues are for hOS.  Just like Microsoft focuses their patching of Windows on the most dangerous vulnerabilities, hOS vulnerabilities also need to be tracked the same as technological vulnerabilities.

By decoupling people from the equation and looking at the security awareness problem as patching another OS, it liberates you to think in new ways.  So, what are the steps in patching an OS?

1. Identify the vulnerability.
2. Determine the risk of the vulnerability.
3. Determine what can be done to mitigate or remediate the vulnerability.
4. Develop a program to mitigate or remediate the vulnerability.
5. Test the mitigation or remediation of the vulnerability.
6. Implement the mitigation or remediation of the vulnerability.

Now apply those principles to hOS on a monthly basis.  Taking the results of your research you can surely come up with a vulnerability or two that has occurred whether it is a suspicious email with a PDF or spreadsheet attachment or a drive-by attack.  Take those as examples, explain their risk, explain how to recognize these attacks, and then put your marketing department to work on developing a message that trains people.  There is a reason I recommend the marketing department and that is because you can share this information with your customers as well as your employees.

Send out these messages on a regular basis, preferably monthly but definitely more often than annually.  Follow up those messages with ‘lunch and learn’ or similar sessions to further discuss those messages and to ask attendees if they have any security questions or have encountered any threats at work or even at home.  These steps should show your customers and fellow employees that security does not require knowledge of technology so much as just using common sense and being skeptical.

Security awareness does not need to be conducted like a TV sitcom, but it can work if you take the approach that you are patching another device and you make that training relevant.

Merchant Beware – New Mobile Payment Solution Out In The Wild

Merchants need to be aware of a new mobile payment solution – Square from Square Inc.  A colleague pointed me to the Square site with the question, “Is this PCI compliant?”

Square appears to be a hardware/software solution for iPhones, iPads and Android devices.  It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards.  This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly.  It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.

In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard.  Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard.  Has Square submitted their solution for PTS certification?  It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified.  However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement.  Game over.

While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue.  In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed.  That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely.  As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not.  Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.

And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over.  Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext.  Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted.  And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device.  It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.

There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone.  The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner.  The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.

The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications.  These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified.  In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.

The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions.  The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.

If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.