Archive

Archive for the ‘Uncategorized’ Category

Planning for your Digital Afterlife

April 15, 2013 Leave a comment

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

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

Advertisements
Categories: Uncategorized

Division Among the Ranks

September 11, 2012 4 comments

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

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.

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

Would You Open This File?

August 26, 2011 Leave a comment

The screen shot below is purportedly an image of the actual email used to launch the zero day attack against RSA, thereby compromising their SecurID algorithm, allowing the bad guys to get into US defense contractors.

screenshot of RSA email

The full story of how the file was eventually found within RSA’s email and malware repository can be viewed here.

Would you open the attachment? Those of us in the security and controls world would probably have picked up on the poor grammar, the unexpected nature and title of the attachment and figured out that this was some kind of attempted compromise and just deleted the email.  Others would likely have assumed that the email was intended for someone else and opened it out of curiosity, thereby giving the bad guys a way in.

I’m putting it out here because it drives home the point that when combating these kinds of attacks, the only real hope you have is the vigilance and knowledge of your own employees in being able to recognize the bogus emails and attachments.  That can only be effective if you spend the time and the money required to train your employees and train them often.

It takes a certain level of cynicism and suspicion to recognize these kinds of attacks.  Many people just don’t have enough of those two qualities and as a result, will open every email and every attachment sent to them.  The bad guys keep doing it because it works.

The author of the full article raises an interesting question: “Why does Excel support embedded Flash?”  Are there really that many Excel users that thought embedded Flash was a “must have” feature?  Was there anyone from the security team in the meeting where they decided it was a good idea?  What could possibly go wrong?  It’s just Flash?

Hopefully the malware providers are already working on an option to identify Excel spreadsheets with embedded Flash and issue a stern warning or prevent infection.   In the meantime, we have to rely on good old fashioned training to try and combat the compromise of our company systems.

 

 

Categories: Uncategorized

Got Bots?

While I was at lunch today I happened to see a short video on CNN about a company (Unveillance) that provides Security as a Service relative to the identification of compromised computers (bots) in private and corporate networks. For all the time and money spent by organizations to install and update anti-malware on their networks, the real bad guys are using and sharing new techniques to compromise devices without triggering  anti-malware software.

A bot is geek-speak for a software version of a mechanical robot.  A botnet is a collection of compromised computers used for malicious purposes. 1  In most cases the compromised machines are used to collect information such as account numbers, user ids, passwords, etc.  This information is then automatically sent back to the Command & Control (C&C) server which is controlled by a botnet administrator.  They are sometimes used to distribute spam or to execute Distributed Denial of Service (DDoS) attacks against websites.  Because the attacks come from compromised machines it is difficult to trace these attacks to the person actually initiating and controlling the attack.

The CNN piece goes on to discuss the current threat level which Unveillance estimates at 6% of the total IP addresses globally. That translates to an astounding 240 million computers that may be compromised and controlled to some degree by the bad guys.  Since the techniques used to compromise machines are not detected by conventional anti-malware, the owners and operators of compromised machines typically don’t even know the machine has been compromised.  In most cases, the computer acts normally, but is recording keystrokes and copying data undetected in the background.

This news, while disturbing, is consistent with some of the conversations I had last Friday at the Atlanta Technology Summit.  Several security experts that I spoke with at the conference told horror stories of entire corporate networks being “pwned” (owned) by foreign governments or organized crime rings in the far east and eastern Europe.  Multiple attempts to “clean” these corporate networks have been initiated, but ultimately within a short time, the evidence of compromise resurfaces.

After listening to my colleagues at the Atlanta Technology Summit and seeing the CNN piece, I realized that most of the IT risk assessments I have done in recent years did not address this issue.  So what am I going to change as far as my methodology for performing risk assessments?  First, I will ask management what policies and training are in place to help reduce the risk of compromise.  Many of the machines get compromised as a result of a social engineering techniques that rely on a valid user clicking a link to an infected website or execution of a payload program imbedded in an email.  So how do you combat that kind of an attack?  The key is effective and frequent education and training.   You should also constantly look for ways to improve the effectiveness of your spam filtering and website traffic monitoring.

In some cases, awareness of the risk and vulnerability is the first step toward designing and implementing appropriate controls.  Unfortunately I don’t have the cure on this one, but it appears that Unveillance at least has a method for identifying the disease.

1 – Wikipedia – http://en.wikipedia.org/wiki/Botnets – July 2011

SSAE 16 is the new SAS 70? Not So Fast!

July 24, 2011 4 comments

As you know, the AICPA officially retired Statement on Auditing Standard number 70 (SAS 70) as of June 15, 2011. The AICPA has released three new standards for service organization audits. They are known as Service Organization Control (SOC) reports, more specifically SOC 1, SOC 2, and SOC 3. SOC 1 has published guidance, SSAE 16 associated with it. SSAE 16 is the “official replacement” for SAS 70.

Due to the timing  and publicity around SSAE 16, many organizations (and CPA firms for that matter) do not fully understand the differences between the three new SOC reports and when each report is most appropriate.  Instead, they assume that if a SAS 70 report had been issued in the past, then an SSAE 16 report should be issued after June 15, 2011.  Depending on the type of services being provided and the intended use of the report, an SSAE 16 report may not be the most appropriate choice.

Part of the reason the AICPA created the new standards was to attempt to rectify the misuse and abuse of SAS 70 reports.  In years past, many colocation facilities and data centers have been asked by their customers to provide them with a SAS 70 report.  In many cases, these data centers have nothing whatsoever to do with the processing of their customers transactions or the operation of the software they utilize.  They merely provide a physically, environmentally and logically secure environment for the computing equipment owned and operated by their customer.  They have little if anything to do with logical access controls, processing controls, change controls, or reporting of processing results.  They are not unlike the landlord of many office buildings that supply facilities, heating and cooling, and limited building security to businesses every day.

SAS 70 reports were intended to assist financial statement auditors in understanding the controls present at third party service organizations that were relevant to user entities financial statements.  Would it make sense for auditors to request a SAS 70 report from the landlord of the building where their client’s business resides?  No. And it doesn’t make sense for auditors and customers of a colocation facility to ask the colo to provide an SSAE 16 report.  Why?  My primary argument is that the services provided by the colo have very little impact on the customer’s controls over financial reporting.  But before you all go flaming me and bringing up Sarbanes-Oxley and IT General Controls, read my next argument.  My secondary argument is because there is now a better alternative to SSAE 16 and its predecessor SAS 70 for reporting on the ITGCs at a colocation facility.  It is the AICPA SOC2 and SOC3 report.

There are many readers that will disagree with my statement that the services provided by a colo have little impact on controls over financial reporting because Sarbanes-Oxley requires auditors to understand the IT General Controls (including environmental and physical) that support applications and systems that are relevant to financial statements.  I agree that it is important to understand these foundational controls.  However, the controls that matter most in systems that have relevance to financial reporting are not under the control of the data centers and colo providers.  Logical access controls, segregation of duties, program change, operations controls are normally the responsibility and domain of the customer, not the colo.  These controls are far more relevant to the ongoing control over financial reporting.  A locked facility with adequate environmental controls is important but does not have the same impact over financial reporting that good logical access, program change, and operations controls will have.

Wouldn’t it make more sense to have a standard set of ITGC  controls criteria so that every processing environment (i.e. data center, colocation facility, IT “closet”) could be graded on a standard scale?  Wouldn’t that make everyone’s life a little easier and provide better information for the auditors AND the customers?  Yes, it would. And the good news is that the AICPA has given us a working tool that is far superior to the wildly fluctuating quality and coverage of SSAE 16/SAS 70 reports.

SOC 2 and SOC 3 reports are based on the AICPA and CICA Trust Services Criteria.  The Trust Services Criteria are divided into 5 Principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy.  Each of the five Principles contains a list of criteria that support that Principle.  For most data center and colocation service providers, an audit based on the Security and Availability Priniciples would provide ample evidence of the state of ITGCs applicable to whatever systems the customer is operating. Granted, once a service provider moves into the realm of Platform as a Service or Software as a Service, then you will likely have to add Processing Integrity criteria to the mix.  Confidentiality and Privacy could also be part of the scope of an audit based on the types of data being maintained and the industry or compliance requirements of the customer.

I will be the first to admit that the criteria currently published by the AICPA and CICA are not a silver bullet.  My initial impression is that the Principles and criteria are in some cases difficult to interpret and poorly organized.    But they are still a superior alternative to allowing every DC and colo to write their own criteria which is what happens with SAS 70 and SSAE 16 audits.

So before you request an SSAE 16 report from your client or service provider, take the time to understand SOC 2 and SOC 3.  I believe that for most data center and colocation providers, these new report offerings are a better alternative to SSAE 16 reports because there is a pre-defined set of controls criteria that we auditors will be using as a baseline for evaluation.  The best place to begin your education about SOC 2 and SOC 3 is the AICPA website: http://www.aicpa.org/SOC