Will the Idea of a Trust Services Self Assessment Questionnaire Fly?

In the Payment Card Industry (PCI), there is something called a Self Assessment Questionnaire (SAQ).  The SAQ is a very useful tool for small businesses who need to provide their customers and credit card transaction processors a basic level of comfort that they are compliant with the requirements set forth in the PCI Data Security Standards (PCI-DSS).  The SAQ includes a form that is signed by management called an Attestation of Compliance (AOC).

Granted, those who understand risk assurance know that an AOC from management is really, no assurance at all, but for some, it is enough to satisfy their need to transfer risk back to management.  Should a breach occur and credit card information be stolen, the recipients of an AOC can say, "Well, you told us you were compliant with PCI-DSS."

This is where I got to thinking...wouldn't it be great if the Trust Services Principles & Criteria (TSPC) had a similar mechanism!  

Here's a situation where a TSPC SAQ and AOC would be perfect.  I received an inquiry recently from a small business owner who had received a contract award for $50,000, and was looking for a quote on a SOC 2 report to satisfy the client's request.  When I told him what the report was likely to cost, he concluded that it was not economically feasible to go forward with even a Type 1 SOC 2 report.

What this company needs is an entry level assurance mechanism sanctioned by the AICPA and CICA that they can use to satisfy their customer's requirement for management assurance.  If the customer needs to see backup evidence, the small business can provide it.

There is one problem though.  The TSPC are a list of principles and criteria (or control objectives as I know them from my Sarbanes Oxley days), and it's not as easy as checking "In Place", or "Not in Place", like the PCI SAQ is.  Management has to spell out the specific controls (or control activities as I know them), that they have implemented in response to the TSPC.

The problem can be solved by listing the Illustrative Controls from the TSPC with a check box next to it as well as a check box that says "Other."  If management chooses, "Other", they can write in a custom control, or reference a control number from CoBIT 5, NIST 800-53, ISO 27001, or the CSA's Cloud Control Matrix (CCM).  If other standards are referenced in response to a TSPC criteria, the other standard can be attached so the detail can be viewed by the customer.

The responsibility for determination about the suitability of the control design can be placed squarely on management and the user organization in the fine print so that it is understood that the AICPA and CICA do not have any liability whatsoever.

I realize that there are many complications and issues that will undoubtedly be raised, but lets see if this idea will fly!  If not, we can say we tried, but if it does, we might change the risk assurance industry together.


What I Don't Know Blows My Mind

(UPDATE:  Since writing this post, I came across a great blog post titled: "Learn to hack."  This may help some out there who want to begin to deepen their security knowledge so they can perform high quality SOC 2 engagements.)


Recently, I have come under fire for writing about SOC reports because I am not a CPA.  It is not really relevant to you, but I think that these people would attack me even if I were a CPA.  They would say that I'm not a partner of a CPA firm, I don't have enough experience in a Big 4 public accounting firm, my firm isn't audited by the PCAOB, etc., etc.  The bottom line is that it is easier to challenge my qualifications for speaking than it is to debate the subject and issues I am speaking about.

Well I'm going to come out and just say it.  Just thinking about what I don't know completely blows my mind.  As I write about a topic, I make sure that I know enough about what I am saying so that I can at least defend my position based on the facts that I have, but my mind remains completely open to alternate points of view and facts that I have not considered.

This is where I had an idea...there are a lot of CPAs who think they understand security, and a lot of security professionals who think they understand auditing and assurance.  What if I post a few videos on deep, yet fundamental topics in each area?  The goal would be to demonstrate that CPAs need true security professionals and vice versa.

Thanks to my friend @Hacksec's introduction to @SebastianThrun, I discovered a phenominal resource called Udacity that offers free education from instructors at real institutions of higher learning, and promptly enrolled in CS387: Applied Cryptography.  The videos I have embedded below are from the course.  Please watch them when you have a few minutes.  The ease with which the instructor explains these very fundamental yet complex principles, compared with my difficulty comprehending his words enough to pass his simple quiz blew my mind.

My point is that when it comes to security and risk assurance, we need each other.  The "we can do it all" mindset of some service auditors is not only ignorant, it is arrogant, and should not be indulged by service organizations.  CPA firms need to understand that they are entering the security market for the first time.  SAS 70 was not designed to provide assurance about security, nor was it accepted by people who knew better as assurance regarding security.  Systrust and Webtrust were ignored by the market for the most part.

With SOC 2 we have the opportunity to leverage each other's strengths as I enumerated in my blog posts titled "So many security standards..." and "Don't worry...", and actually make a difference in the world of security.  If CPAs and security professionals join forces, we may have a real opportunity to defeat, or at least discourage those who would try to cause mayhem in our IT infrastructures.

Enjoy the topic of cryptography (cryptology to be more accurate).  Perhaps I will continue the theme in another post, and concentrate on some things CPAs know that security professionals do not.




Here's the answer to the quiz.  By the way, if you get this one, you are much smarter than me, but you should enroll in the course, and watch some of the other things this instructor teaches!  CS387: Applied Cryptography


Introducing the Term "SSAE SOC2"

I have been watching the SOC (formerly SAS 70) reports market since early last year, even before June 15th - the official date that SAS 70 died, and have taken note of many things. Among the good things I have noticed in the market is use of the term "SSAE SOC2." Whoever came up with this term is a genius. I noticed this term first in a blog post by @Internap.


The term is genius because it helps people overcome the fixation that people have unfortunately developed with the term "SSAE 16" while remaining 100% accurate.  Others have tried to do the right thing by getting a SOC2 report (SSAE 16 is not designed to provide assurance about security), but needing to satisfy their customer's misguided demand for an SSAE 16 report, told everyone that they had an "SSAE 16 SOC2" report.  This is not accurate because SSAE 16 has to do with SOC1 instead of SOC2.

The reason the term "SSAE SOC2" is 100% accurate is that SOC2 is based on AT-101 which is in turn based on SSAE 10, SSAE 11, SSAE 12, and SSAE 14 (I just had to go double check).

Okay, so you may be asking, "WHO CARES?", and wishing you could say, "Quit boring me!"


Here's why I care...last year, and into this year, we all witnessed the market completely ignore the changes in the standards the AICPA made to service organization control reporting.  The AICPA was clear..."SOC reports replace SAS 70", and "SSAE 16 is not designed to provide assurance regarding security, availability, processing integrity, confidentiality, or privacy." 


Instead, the market heard "SSAE 16 replaces SAS 70", and what happened?  Well, but for a few elite service organizations, everyone rushed out and got their SSAE 16 report.  Why? Because that's what customers were asking for.  The RFP said "SSAE 16", so service organizations gave them an "SSAE 16."

What the term "SSAE SOC2" enables us to do is easily transition to the report that IS designed to provide assurance regarding Security, Availability, Processing Integrity, Confidentiality, and Privacy - a SOC2 report.  The term will ease the minds of people that have latched onto the term "SSAE 16", and as long as SOC2 engagements are performed by competent security professionals, service organizations will be more secure, and user organization's data will be better protected.

Automating the DoRS™ Analysis

There has been an overwhelming response to the Degrees of Risk Separation (DoRS) concept, and I got to thinking...why not automate the analysis so that a list of controls can be uploaded, and a DoRS number can be automatically assigned?  To do this, I will need a fairly large database of sample SAS 70 and/or SSAE 16 controls so that the pattern recognition software can do its job and accurately determine the number of DoRS that separate the control from the risk of financial misstatement.

This is where I would like to ask for your help.  Please use the form below to upload your list of controls.  I do not need the entire SAS 70 or SSAE 16 report, just the list of controls.  It would also be great if the company names were already sanitized to save me some time and keep things confidential.  If you include your email address in the comments section, I will send you a $5 Starbucks eGift card for your trouble.

Thanks for your help!  Together we are going to revolutionize the risk assurance industry.

Do You Trust Your Service Provider's Auditor?

I recently came across a really impressive RFP example that included SOC2 audit requirement language.  You can  view and download it here.


Besides calling for a SOC2 report in connection with security, the great thing about the originator of this RFP (whoever they are) is that they included this language:

The Contractor’s SOC 2 Audit Plan shall identify the independent entity that will perform the Contractor’s SOC 2 Audit, or a description of the means by which the Contractor will select its SOC 2 independent auditor. The OUR COMPANY Contract Manager will have 10 days to review and comment on the SOC 2 Audit Plan, and shall identify any concerns with the scope of the audit, the independence or capability of the SOC 2 auditor, or the described plan to obtain an independent SOC 2 auditor. 

In other words, the contract manager is empowered to veto the auditor that the service organization selects!  This is great news for ethical auditors and very bad news for unethical auditors.

This started me thinking.  On what grounds would a contract manager veto a selected auditor?  How about using the same basis that ethical auditors use to screen the clients that they accept?  One of my CPA firm partners introduced me to the concept of prospective client background investigations.  Please see the following (sanitized)verbiage from an actual form they require all prospective clients to fill out:

Due Diligence Background Investigation Disclosure Form

We may, with your consent, obtain a background investigation report related to a prospective or current business relationship you may have with us. This may include procurement of a consumer report or an investigative consumer report (defined as a report that includes information as to your character, general reputation, personal characteristics, or mode of living).

By signing below, you grant permission to us or any of our affiliated or subsequent companies to obtain such report or reports at any time. You also grant permission to all parties to release information regarding your previous or current military service, employment, education, or criminal matters, including information which may be deemed negative.

Detailed background reports are available for $29.95 on People Smart.  I would encourage anyone accepting third party risk assurance from their service providers to do a quick Google search to find out who the executives of the audit firm are, and make an objective decision about whether to accept their risk assurance or not.

What is the Value Proposition of Knowing My Son's Password?

There was a comment posted yesterday on a LinkedIn discussion group that I follow.  An individual asked the group how to respond to a service organization prospect that wanted to know what the "value proposition" of a SOC 2 report is.  This is a situation that I'm sure a lot of service auditors find themselves in when dealing with service organizations who do not understand what risk assurance is.

The situation also got me thinking...What is the value proposition of my son giving me his password?  If you ask him, he will tell you that there is no value in giving me his password.  If you ask me, there is plenty of value there.

The fact is, he thinks I should trust him implicitly even though he knows there are good reasons why I do not.  I would not be a good parent if I did not exercise judicious parental controls.  I have a vested interest in the outcome of my son's upbringing.  If he ends up in jail because of my poor parenting, who is the first person that he's going to call to bail him out?  My "right to audit" his laptop, cell phone, or whatever else protects my interest not his.

Answering a service organization's question about the value proposition of a SOC2 report is like trying to explain the value proposition of parental control to my son.  Risk assurance does not need a value proposition because it is valuable in itself.  It is valuable to customers of service organizations.  It is completely useless to service organizations themselves.  Service organizations that do not understand the implicit value of risk assurance think customers should trust them, just like my son thinks I should just trust him.

Why do Data Centers Have to Choose Between SSAE 16 and SOC 2?


There was a debate between two auditors about whether data centers need SSAE 16 or not captured in these two articles on Infosec Island: Why Datacenters Need SSAE 16 and Why Data Centers Don't Need SSAE 16. Well the jury is in, and the market decided definitively that data centers need SSAE 16.  Please refer to my post titled "When I See a Can in the Road All I Want to do is Smash It" where I list out the service organizations that obtained SSAE 16 examinations versus those who obtained SOC 2 examinations.  My question, however,  is this, "Why do Data Centers Have to Choose Between SSAE 16 and SOC 2?"  




If SSAE 16 is applied correctly, non-ICFR controls should not be included in the report.  This means that at the very least Physical Security and Environmental controls have to be removed from the SSAE 16 report.  For more information about how to determine if a control is non-ICFR, please refer to my post titled, "Use Degrees of Risk Separation (DoRS™) to Determine ICFR / non-ICFR"  


  • If Physical Security and Environmental controls are removed from SSAE 16 reports, customers are going to need to receive assurance about security and  availability from another source.    
  • That is where SOC 2 comes in.  SOC 2 is designed to provide assurance regarding both security and availability whereas, SSAE 16 is not designed to, nor can it provide assurance regarding security and availability.
  • While the market was trying to figure out which was the right report, the answer was right there in front of us.  Data centers need both an SSAE 16 report and a SOC 2 report.  


Remove non-ICFR controls from most data center SSAE 16 reports, and you will be left with a very thin report.  This will create the need for a SOC 2 in order for data centers to provide their customers the assurance that they will not cause a material misstatement (SSAE 16), and assurance regarding security and availability (SOC 2).

Some may be thinking..."What about cost?  Won't two reports cost more than one?"  The answer I give is that it will not cost more if the controls that were tested under SAS 70, and incorrectly under SSAE 16, map to the Trust Services Principles and Criteria.  The reports themselves do not take much effort to compile, and therefore should not cost much, if any more than one report.  Where the additional cost comes in is when there are additional controls that need to be tested because of gaps between the existing report and the TSPC.  

A DoRS analysis can help data centers separate out non-ICFR controls, and a TSPC mapping exercise can help data centers determine whether they will need to implement missing controls.  Doing these two things can help data centers determine whether to expect to have to pay additional audit fees moving forward.  If anyone needs any help, please let me know.

Greatness

I recently witnessed someone I highly respect (@Hacksec) refer to someone as "Greatness."  The thing is, I had walked into the room and had casual conversation with this person without the slightest idea of who he was.  

Without the context that would have enabled me to recognize greatness, I was reduced to seeing this person as another person attending the same event that I was attending with whom I should make polite conversation.

That experience reminded me that sometimes greatness just is, whether we recognize it or not.

Albert Einstein
Please allow me to introduce the visionary of SOC2. 

Chris Halterman.  

 








http://bcove.me/8i5fhqf9 

"Every time a seismic shift takes place in our economy, there are people who feel the vibrations long before the rest of us do, vibrations so strong they demand action-action that can seem rash, even stupid." - Excerpt from the Time magazine article accompanying Jeffrey Preston Bezos' Person of the Year Award in 1999

I believe that Chris Halterman is such a person.

The Risk Assurance Manifesto


Listen to me discuss this post on my talk radio show below:


Listen to internet radio with Risk Assurance Talk Radio on Blog Talk Radio

rev·o·lu·tion [rev-uh-loo-shuhn] noun -A sudden, complete or marked change in something.

Every good revolution needs a manifesto, or at least a position statement that everyone can rally around, so I decided to put forth an initial draft.

For the purpose of this manifesto, "acknowledge" is used for our acceptance of factual statements, and "believe" is used for expressions of our convictions.

1.  We acknowledge that Statements on Standards for Attestation Engagements no. 16 (SSAE 16) is not designed to, and cannot provide assurance regarding security, availability, processing integrity, confidentiality, or privacy.  (More info)

2.  We acknowledge that Service Organization Controls (SOC) reports replaced SAS 70, and that SOC reports include SOC 1, SOC 2, and SOC 3 reports. (More info)

3.  We believe that an Internal Control over Financial Reporting (ICFR) is defined by a reasonable degree of risk separation between itself and the risk of material financial misstatement.  (More info)

4.  We acknowledge that service auditors fail to follow the SSAE 16 attestation standard if they conclude that non-ICFR controls are "reasonable in the circumstances" when they are included in SSAE 16 by management.  (More info)

5.  We acknowledge that SOC 2 is designed to and can provide assurance regarding security, availability, processing integrity, confidentiality, or privacy.  (More info)

6.  We believe that SOC 2 is the vehicle that will unify the risk assurance industry by allowing management to include PCI, HIPAA, NIST, CCM, ISO 27000, and other regulatory and industry standards as "other subject matter."  (More info)

7.  We believe that SOC 2 engagements should only be accepted by service auditors who use professionals with deep technical expertise of the subject matter being tested.  (More info)

8.  We acknowledge that there is an inherent conflict of interest created when service auditors provide risk assurance for the benefit of management rather than stake-holders.  (More info)

9.  We acknowledge the responsibility of stake-holders to verify that they are receiving adequate risk assurance from management, but that service auditors are not absolved of their responsibility to represent the stake-holder's interest above management's interest.  (More info)

10.  We acknowledge the supremacy of real-time assurance over period-of-time assurance over point-in-time assurance over management assurance.  (More info)

11.  We acknowledge that "bridge letters" are not to be offered by external auditors, and when they are offered by management, they are to be seen as management assurance. (More info)

Please feel free to challenge or agree with any of the above.  If you think it is too risky, please consider these words from Starbucks Chairman and CEO Howard Schultz:

Don't Worry. I've Got This.

Okay, it's time to address a sensitive subject.  In my post, "So Many Security Standards, Audits, and Certifications..." I laid out the reasons why I think CPAs need security professionals, and vice versa.  It is a tough subject because no one likes to hear that they are not capable of doing something, and I am no exception.  

Back in 2004, I was hired to "in-source" a previously outsourced IT function in hopes of saving the company money.  The project included everything from purchasing and setting up new equipment to bringing on additional staff.  The company ran SAP at the time, and part of my job was going to be managing SAP after the project was completed. When I was hired, I told the hiring manager that I had no experience managing SAP implementations, but that I had plenty of experience with ERP systems, so I should be able to handle it with some training and whatever documentation that was available.  

Well needless to say, I overestimated my ability to OJT SAP, and quickly learned after my $7,000, one week BASIS training class that you can't pick up SAP overnight.

My point is this...sometimes we fail to see that we don't know what we don't know.  I consider myself an IT generalist even with over 15 years experience in the IT industry.  The fact is that the minute we step away from hands on "doing", our knowledge becomes obsolete.  

There is nothing that changes faster than technology, and if you are not ahead of it, you are ancient history.  Within the category of technology, security is at the forefront of rapid change, and there is nothing more critical to ensure that we understand as auditors.

CPAs, here's the stark reality:  Security professionals laugh at you behind your backs when you ask for and accept "kick to the tires" level evidence when doing so-called security audits.

Security professionals, don't get too comfortable:  CPAs laugh at your so-called "certifications", and wonder why people accept your point-in-time assurance as evidence that your environment is secure.


There, I said it.  It needed to be said, and you can get mad at me for saying it if you would like, but it is true.

Here's where the opportunity is though!!  We both need each other, and the beauty of SOC2 is that it allows us to work together.  Instead of worrying about who is going to capture more market share in the assurance space, we can collaborate and focus on defeating the hackers for a change.

If we are not careful though, SOC2 will become a kick to the tires just like SAS70 was.  I have already been met with resistance from CPAs who think they can do it all just like I did back in 2004.  Will they have the good sense to realize that they are wrong like I did?  On the opposite side, will security professionals see that CPAs bring their understanding of audit methodology and documentation to the security assurance space where it is lacking today?

Thank You Google!

Dear Google,

I am writing to say thank you for my search result position and for providing me with a free tool to blog with in the first place.  I'm a big fan of Google.

Thank you very much.

Jon Long, CISA, QSA
The Risk Assurance Guy (Google Me!)

By the way, these are the keywords that people have used to find me organically.  Please let me know if there is any way that I can help you (besides Adwords which I am hoping to be able to ramp up my spending on soon).  I love Google.

Keywords are linked to my posts on the topic:
icfr, informatii cfr iasi, audit soc report, financial statement attestation sample,  international standards, ngenx ssae, soc 1 restricted  use, Internal Control Over Financial Reporting, how to conduct an audit of ICFR?, INTERNATIONAL STANDARD ON ASSURANCE ENGAGEMENTS -ISAE, SOC 1 bridge letter, soc 1 control objectives checklist, criteria language in a SOC 2 report, "soc 2" audit, 27001 tspc control comparison, bridge letter ssae 16 definition, Bridge Letter SSAE16, bridge letters versus soc1 report, bridge letters, soc internatl controls, bridging letter for auditors, can you still do an attestation under the at101 but not soc2, certified logos, Confidential Integrity Available, define privacy, energy saving auditing, environmental impact of energy efficiency, financial controls, financial statement and internal control, how is SOC1 different from SOC 2, How to establish internal control, icfr example, icfr examples, ICFR framework of SBP, icfr handbook, icfr report, icfr reports, icofr, internal control financial reporting OCG, internal control over financial reporting definition, Internal control reporting, Internal Controls Over Financial Reporting, is soc2 international, ISMS lead auditor certificate, iso 27001 lead auditor log evidence,iso 27001 logo download, iso soc2 nist matrix, iso27001 controls definiation, jon long cisa qsa, large entities, control risk assessment contributes to audit efficiency, Non-ICFR, non-icfr controls, secure data recovery ssae16, service assurance organization, so many security standards problems, so many security standards, audits, and certifications., SOC 1 checklist, soc 1 report bridge letter, soc 1 report checklist, SOC 1 reporting can you add non-ICFR assertinos, soc report non-icfr,  soc2 bridge letter, ssa16 soc1, ssae 16 bridge letter sample, ssae 16 icofr, SSAE16/SOC1 Report formerly SAS70, standard right to audit, "soc 2" "type 2",Annex A of ISO/IEC 27001, bridge letter ssae 16, cause material misstatement, compliancepoint, conflict of interest, iso 27001 and soc 2, iso 27001 audit - period or point in time?, iso 27001 la certification, iso 27001 lead auditor certificate, iso 27001 session time out code practice for data center, ISO Cloud standard certificate, iso27001, iso27006, where can I find a Sas70 or SSA16 Certified hosting service, guy+iso