Archive for the ‘IT controls’ Category

Survey Says! Marketers Make Phishing Easy

February 14, 2014 1 comment

I received an email today from my bank (see below) asking me to take a survey about their service.

Actual email from Wells Fargo

Actual email from Wells Fargo

The email initially appeared to be a phishing attack.  After all, banks are always telling customers not to open attachments or click embedded links, right?

wells alert

After a little bit of investigating I learned that it was a legitimate request to complete a survey.  Now I certainly understand that companies occasionally want to use surveys to better understand their customers.  But it strikes me as incredibly misguided and naive to send a direct email to your customers from a third party with embedded links and passwords to answer a survey, after telling those same customers never to open attachments or click on links in emails that appear to come from them.

Aside from the obvious invasion of privacy, these emails are incredibly easy for the bad guys to duplicate, masking the embedded links and sending customers to bogus websites where they can be infected with malware, keyloggers, and other bad things.  It is as if Wells Fargo is saying “Here you go phishers.  Here is a perfect template for gathering personal information on our customers!”

It is difficult enough to keep the public aware of the many dangers of phishing attacks without violating the company’s own guidelines for interacting with customers.  Shame on you Wells Fargo.  If you really want to perform a survey, it should be done from within the customer’s online banking interface using a secure, encrypted connection. 

I forwarded the email to this morning at 8am but so far I’ve only gotten an automated acknowledgement.  No response related to my inquiry.


How to know if your Data Center is Serious About Controls

April 15, 2013 Leave a comment

Every day I get an alert from Google for any new press releases about SSAE 16 reports.  The vast majority of the alerts come from co-location and “cloud” data center providers.  I believe I have already beaten the “SSAE 16 is not intended for general IT controls” horse to death in other blogs so I won’t go into that.  What I will continue to bring up is the colo, data center,  and cloud industry’s apparent unwillingness to recognize the importance of the SOC 2 report, especially now that the AICPA and Cloud Security Alliance have endorsed SOC 2, along with the Cloud Controls Matrix, as “likely to meet the assurance and reporting needs of the majority of users of cloud services”.

I’m sure that many readers will jump all over the semantics of cloud vs. data center vs. colo.  But conceptually all three house IT infrastructure at a facility that is not controlled by the customer.  As a result, IT general controls (non-ICFR) are extremely important.  The reason SOC 2 exists is to address all those IT general controls.  A customer of a colo, data center, or cloud provider that maintains responsibility for the initiation, processing, and reporting of transactions through IT infrastructure housed at a remote facility should be asking their provider for a SOC 2.  The Trust Services Principles and Criteria are the pre-established general controls criteria that have been missing from SAS 70 and SSAE 16 reports.  Without some type of framework, SSAE 16 reports are subject to all manner of missing and irrelevant controls.  The inconsistency in both structure and content is one of the primary reasons that information security professionals laugh at the mention of SSAE 16 and SAS 70.

Does your data center, colo, cloud provider offer a SOC 2 report?  If so, you can be a lot more confident that they are serious about providing you with meaningful information regarding their IT general controls.  They have taken the time to understand the new AICPA standards for SOC reporting and have made the decision to provide the appropriate report to their customers.  If your provider is still providing  only the SSAE 16 report, you really need to read the report and ask yourself “What’s missing?” because chances are, there are important controls being glossed over or ignored.

An easy way to test your provider’s SSAE 16 report is to compare the controls being tested and described to any number of controls frameworks, including the Trust Services Principles and Criteria or the Cloud Controls Matrix or COBIT or whatever you think is the best and most appropriate for the services being provided.  Chances are you will find that the report is missing important details.


When the Cloud makes Rain

November 5, 2012 Leave a comment

This morning I was preparing to make some final adjustments to a presentation I am to deliver on Wednesday at the Cloud Security Alliance Congress in Orlando. Prezi ( is a cool cloud app that allows a much more interesting presentation than the square slide, square slide, square slide sequence of Powerpoint. The issue this morning was that every attempt to get to the site ended in 502 Bad Gateway. I hate when that happens. 

I checked Twitter and sure enough, was having major issues. Hundreds of tweets from customers desperate to get their presentations running. Many panicked tweets like “My presentation is due and your site is down?!?!” Hmmmm. This cloud stuff is really cool when it works. But if you have connectivity issues or the host site is unavailable because of poor change management (my prediction for why Prezi is down today) what can you do? The cloud service providers have you over a barrel. They have your content. You cannot update or edit your own content when their site is down.

Having given many presentations where wifi or internet connections were unavailable, I knew that using Prezi was a risk. Prezi has a feature that will allow you to download your presentation for offline use. Apparently many of their customers had not thought ahead about the possibility of the service being offline.

When your entire business model revolves around 24/7 availability, it only takes one event like this morning to ruin your world-wide online reputation. I hope prezi comes through unscathed on this one. Perhaps they should consider a traditional software licensing model that does not rely on 99.99% uptime for their infrastructure.

Beyond SSAE 16 Certified

August 13, 2012 1 comment

All I can say is, “Wow”.  In my inbox this morning was a press release from Verian, a “world leader in universal purchasing and invoice processing systems” with a headline that states “Verian Recognized by AICPA for Delivering Highest Levels of Quality and Security”. Of course I had to see what that was all about.

Turns out, Verian completed an SSAE 16 attestation. Nothing in the accompanying press release says anything about special recognition from the AICPA. The press release goes on to talk about the value of the SOC 1 report and why all their customers can trust them because “The completion of the SOC 1 Type ll examination typifies Verian’s continued commitment to create and maintain the most stringent controls needed to ensure the highest quality and security of services provided to their customers.”

That “may” be true but it certainly does not indicate that the AICPA provided any special recognition of Verian’s quality and security. I can understand why the company wants to issue a press release to announce the completion of the SSAE 16 attestation. But to announce it as recognition from the AICPA is over the top. This goes way beyond saying you are “SSAE 16 Certified”.

Major AwardThe average reader would assume that this SSAE 16 must be a “major award” from the AICPA when in fact it is nothing more than an independent attestation that Verian does what they describe in their own description of their own controls over their system.

I recognize that marketing people get paid to create press releases and that headlines are what attracts people to read them. Hey, it worked on me.  But this headline is misleading and over the top.  So all you marketing people, please don’t try to mislead your customers and potential customers with flamboyant claims about special recognition. Doing so just further diminishes the value of a well written SSAE 16 report.

Passing the Buck

June 16, 2012 2 comments

I had an interesting discussion with a SaaS vendor the other day at a networking event. This particular vendor supplies a system to automate certain functions of a company’s accounts payable process. They extract data from the customer and place it in a web based portal for suppliers to utilize for checking on payment status, expediting payment, resolving payment disputes, etc. Clearly this service has a direct impact on financial reporting for their customers, so I asked “Who performs your Service Organization Control examination?” Of course I had to follow with a reference to SAS 70 so that she knew what I was talking about.

“Oh,” was her reply (fictional name).

Confused, I asked for clarification. “ performs your SOC examination?” I asked.
“No, they provide it for us. We host our services with them.”

Now the picture was getting clearer. “So I’m guessing then that you don’t have an SSAE 16 or SOC 2 review performed independently?”
“No, why should we? is responsible for all of the redundancy, backup and security of our services.”
“What about the controls around the actual sending and receiving of data from your customers? You know, like how do you ensure that if Acme sends you 115 invoice records, that you receive them all and they were accurately filed in the data base to the correct customer?”
“OH! We do that regularly with our customers. If we have a file transmission issue, we call them and tell them to resend the data.”
“What happens if your programmers make a mistake in the code resulting in errors for your customers that impact their financial statements?”
“We have a very robust change management process that would catch any errors like that. If one did happen to get through we would obviously correct the error and apply a patch to our code as quickly as possible.”

Here we have a large publicly traded company outsourcing a key part of the management of their Payables function to a SaaS vendor that does not have any third party attestation around the services they perform. The SaaS provider is relying completely on their hosting company to provide evidence of controls to satisfy the needs of their customers’ auditors and management. And as a result, the customer and their auditors have no third party attestation of the fundamental controls over the development, update, management, and operation of the application controlling this significant business process.

The troubling thing is, this is not the first instance of this scenario that I have encountered. I’ve had several SaaS providers tell me they don’t need to have a SOC report because their hosting company provides them with one.

I am curious to know if the auditor for the publicly held customer has any idea that the controls they should be most interested in understanding (interfaces, input, processing, output, reporting) for the purposes of their financial statement audit are not being addressed by the SOC report provided by on behalf of their auditee’s SaaS provider. My guess is the audit team did what most audit team’s do – they asked for the “SAS 70” for the SaaS provider, received a copy of the SOC report for, checked the box on the appropriate audit work paper, and moved on.

As a result, their audit of financial statement controls is missing an important component to a critical financial statement line-item. Does your SaaS provider provide you with independent attestation? If not, perhaps it’s time you ask for it.

What Good is PCI-DSS?

May 2, 2012 1 comment

With the most recent high-profile credit card data breach occurring late last month at Global Payments, one has to question the real benefit of PCI-DSS.  After all, didn’t a nationally-recognized Qualified Security Assessor (QSA) confirm their compliance with PCI-DSS?  If so, how is it that the company still had a breach?

There are very few details on exactly what happened at Global Payments.  One rumor has the breach occurring through a taxi company in New York.  Another rumor states the breach involved answering a series of knowledge-based security questions correctly.  The truth is, Global Payments may never know exactly what led to the breach.

Once the breach became public, VISA removed Global Payments from its list of “approved” card processors.  VISA indicated the company can be reinstated after an independent assessment of compliance with industry standards.  If we read between the lines,  VISA is essentially saying that since Global Payments had a breach, they must not have been in compliance with PCI-DSS standards at the time of the breach.  So where does that leave us regarding PCI compliance?  Basically the same place that any compliance review leaves you.  Just because an organization is compliant with a given standard does not mean that bad things won’t happen.

Credit card processors have some very valuable information that bad guys all over the world would love to get their hands on.  They are the Fort Knox of the modern world.  When bad guys are motivated, it seems no amount of security can keep them out. Does that mean PCI-DSS standards are worthless?  Not at all.  It just means it isn’t foolproof.  Especially not in today’s world of spear phishing, trojans and highly coordinated social engineering attacks.  When you have good locks on your data, the bad guys will simply begin targeting those within the organization that have the keys.

No matter how much technology you throw at security, people will always be the weakest link. The PCI-DSS standard (and many others) doesn’t do a very good job of evaluating how well we train our people to recognize social engineering and spear phishing.   As evidence, look at the facts behind the breaches at RSA, Epsilon, and HBGary.  Each of those breaches involved a failure of humans to recognize that they were being enticed to hand over the keys.  If we ever do get any details about this latest breach at Global Payments, I’m betting there was a component of human failure. It can be difficult to recognize the wolf in sheep’s clothing when they are asking for the keys.

PCI-DSS compliance is primarily about setting up and maintaining technology to protect credit card data.  With the exception of Requirement 12, the PCI-DSS criteria are predominantly about security technology such as firewalls, intrusion detection, encryption, IDs and passwords, and the like.  Requirement 12:  “Maintain a policy that addresses information security for all personnel.  A strong security policy sets the security tone for the whole entity and informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecting it.” That description does not address the need for a rigorous training program for the human factor.  Are all your employees equally capable of recognizing a spear phishing email?  Are they trained how to recognize a telephone-based social engineering exploit?  Are they absolutely clear on what information is secret, classified, and public?  Without regular ongoing training the human factor will continue to be the weakest link in our security and the bad guys will continue to exploit that weakness.

So what’s the answer?  First, we have to do a better job with education and training.  The SANS Institute has developed a two-day course devoted to “Securing the Human“.  The course is Management 433.  The intent is to develop and strengthen the human side of the security equation through an effective security awareness program; one that will change behaviors of employees and give them more tools to recognize the wolf in sheep’s clothing.

Second, we need to work to improve our standards to include the human factor.  That will take time and effort on everyone’s part, but especially those at the PCI Security Standards Council and other standards organizations.  What have you done recently within your organization to strengthen the “human factor”?

SSAE 16 “First to Fail”?

December 27, 2011 7 comments

I’m still waiting for a service organization to write a press release that is:

  1. accurate
  2. replete of the word “certification
  3. shows a moderate level of understanding about SOC attestations
  4. announces that the service organization conducted the right SOC attestation

This morning I was greeted with a press release from First To File ®, announcing that they have “passed” their SSAE 16 audit “for the third year in a row”.   Hmmm.  Considering the SSAE 16 standard wasn’t released until 2010 that’s a pretty neat trick!  But that isn’t really why I’m writing about this press release.  And I really am not trying to pick on First To File ®.  Their press release just happens to contain many of the issues I have been trying to address with this blog.  Apologies in advance.

It appears to me based on the description of  First to File’s® business (patent prosecution support and document management service) that the SOC 1 audit was probably not the right type of SOC review for them to undertake in the first place.  One of the primary reasons that the AICPA decided to do away with SAS 70 and create the SOC standards was because SAS 70 was being misused.

The AICPA white paper describing the new SOC standards says it best: “As organizations became increasingly concerned about risks beyond financial reporting, SAS 70 often was misused as a means to obtain assurance regarding compliance and operations.” 1  SOC 1 reports focus “solely on controls at a service organization that are likely to be relevant to an audit of a user entity’s financial statements.” 2

So if First to File® is in the business of document management, how do their services have any relevance to a user entity’s financial statements?  They are merely storing intellectual property (IP) in a web-based environment for their customers.  The only impact to the financial statements of their customers would be the fees paid by the customer for the services rendered.  You might even stretch things and conclude that the value of the IP is at risk since it is being stored and protected by a third party.  But that still does not justify the use of a SOC 1 (SSAE 16) report.

Certainly their customers would be interested in knowing what types of controls over the security and confidentiality of that intellectual property First to File® has in place.  This is precisely the scenario that the AICPA created the SOC 2 report for.  It is intended for situations where a report is needed about controls at a service organization intended to mitigate risks related to security, availability, processing integrity, confidentiality, or privacy.  Of these, it appears to me at first glance that customers of a company providing document management services would certainly be interested in controls around security, confidentiality, and privacy.  Perhaps even availability since it would be important to know that the web-based services would be available when needed.

So why would First to File® decide to ask their auditor for an SSAE 16 report?  Because the AICPA and many CPA firms have not sufficiently educated the marketplace regarding the intent and appropriateness of SOC 1 vs SOC 2 vs SOC 3.    Which is why I felt compelled to share this blog.

I can’t really blame the marketing and public relations folks that drafted the First to File® press release.  If CPAs and other controls experts can’t figure out the new standards, we shouldn’t expect marketing folks to get it.  If anyone is at fault, it would be the CPA firm that undertook the engagement.  They should have done a better job of explaining the options and steered the customer away from SOC 1 and toward SOC 2.  If after thoroughly understanding the options, the company still elected to have a SOC 1 (SSAE 16) report prepared, then all we can say is “the customer is always right“.

1  Service Organization Controls: Managing Risks by Obtaining a Service Auditor’s Report – AICPA, Nov 2010

 2 ibid