Planning for your Digital Afterlife

I read about an interesting new service from the folks at Google today.  They have started allowing their customers to control what happens to their online data after a pre-defined period of inactivity.  Although you don’t have to die for it to be activated, it started me thinking about all of the places in cyber-space where my data and information might live on.  For example, this blog is controlled by me through an id and password.  If I passed away tomorrow, what would become of the entries I have made over the last several years?  How long would they continue to exist?

For all the important accounts in my life, my wife is aware of the login credentials so that online banking, retirement accounts, email, etc. would not be a problem.  But what about all those other services that I use?  Facebook, LinkedIn, Twitter, Ebay, PayPal, the car insurance online account, UPS, rental cars, hotels, frequent flyer, etc.  I have no idea how long those accounts would remain active with no interaction from me or my heirs.  I can only imagine how difficult it would be for a surviving spouse or child to have control transferred to a new id and password.

There are certainly more accounts online than I have listed here.  Is there a mechanism out there somewhere that closes all these accounts in the event that I pass away unexpectedly?   What is the real risk of these accounts continuing to remain active after I pass?  There is certainly a risk that they could be taken over by an unauthorized party.  Would my heirs be responsible for any unauthorized transactions from accounts that I created?  Is there any case law involving digital assets in probate court? These are questions that I had never considered before.

A quick search online reveals several companies that help you plan for this.  I found Legacy Locker and SecureSafe.  I am sure there are lots of others.

I would be curious to know what the policy is for various types of accounts and what the “expiration date” is for automatic deactivation or deletion of an account.

Perhaps more companies will begin to follow Google’s lead and provide for the inheritance or elimination of online “property”.  It certainly has me thinking about what to turn off and what to leave on.   Now I just have to figure out who should inherit my blog…..

How to know if your Data Center is Serious About Controls

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”.  http://www.journalofaccountancy.com/News/20137424.htm

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

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 (prezi.com) 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, prezi.com 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.

Division Among the Ranks

There is no shortage of strong opinions regarding the state of third party attestation today. On one side we have the proponents of the new SOC 2 standard. On the other, we have those that want to stick with the tried and not-so-true legacy of SAS 70, aka SSAE 16/SOC 1. The real conflict appears to be around how to determine what ICFR is.

ICFR is the acronym for Internal Control over Financial Reporting. Why is this understanding so important? Because it helps determine the most appropriate report for a given service organization and what should be included in the report. At the root of the disagreement is whether or not it is appropriate to include certain general technology controls (e.g. physical security, redundant network and power feeds, etc.) in a SOC 1 (SSAE 16) report.

There is no question about the purpose and applicability of SSAE 16. The preface to the guidance from the AICPA is crystal clear: “Statement on Standards for Attestation Engagements (SSAE) No. 16, Reporting on Controls at a Service Organization (AICPA, Professional Standards, AT sec. 801), establishes the requirements and guidance for reporting on controls at a service organization relevant to user entities’ internal control over financial reporting. The controls addressed in SSAE No. 16 are those that a service organization implements to prevent, or detect and correct, errors or omissions in the information it provides to user entities.”

Based on that guidance, it would appear that if a control does not prevent, detect and correct errors or omissions in the information that a service organization provides to its customers, then it does not belong in a SSAE 16 report. A more fundamental question can be derived from the guidance. That is; what information does the service organization provide and is it relevant to ICFR?

So perhaps the question is not so much whether a particular control itself is or is not related to ICFR. Rather, the question is, does the control prevent, detect and correct errors or omissions in the information provided? If we examine the information provided by a service organization it should help us determine whether the controls are relevant to ICFR.

I have recently seen some blog postings where certain firms are being “called out” for including what the author believes are clearly non-ICFR controls in SSAE 16 reports.  The intent of the postings are to point out that the firm producing the report is somehow violating the SSAE 16 standard by including non-ICFR controls in the report. But it seems to me that the author is himself violating the standard by making portions of a restricted report ( one intended only for management and the service organization’s customers) publicly available.

Healthy disagreement about how to interpret standards, laws, and rules helps improve those same standards, laws, and rules. That is why we have multiple layers of courts in our country. Discussions among professionals in an appropriate forum in order to provide additional clarity over the interpretation of a very complex, very technical standard like AT 801 (the real standard behind the SOC 1 report) will advance the profession.

Copying entire sections of restricted reports in an attempt to support an argument about what controls should or should not have been included will not advance the profession. It will only add more confusion to an already confused customer base and allow some other reporting mechanism to replace SOC reports as the market leading third-party attestation. That would be bad for our profession and bad for our customer base.

Let’s focus on giving our customers a reporting solution that works for them and stop bickering among ourselves as to who is right and who is wrong.

Beyond SSAE 16 Certified

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”.

The 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

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, LargeHosting.com” was her reply (fictional name).

Confused, I asked for clarification. “LargeHosting.com 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? LargHosting.com 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 LargeHosting.com 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 LargeHosting.com, 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?

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”?