If you're a Facebook user, you probably recently saw in your feed a post by someone like me telling you to watch out using Facebook because Firesheep was coming to get you, steal your profile, and wreak havoc across your online computing life. This post is to dispel some inaccuracy and explain that none of our web-based apps were ever in danger of being "Firesheep-ed".

What is Firesheep?

A nice little tool that makes what has been easy for real hackers to do for years, easy for anyone with basic computer savvy and a local Starbucks to do. It is basically a "point and click" way to steal someone's session with a website if the connection to that website is not consistently secured with HTTPS throughout the site. Everyone in our business uses a computer enough to know not to login to websites if you are not on an https:// address. If you were on an open wifi network and did so, anyone in the vicinity might be able to grab your password out of the air. So we are pretty careful about that and Firesheep DOES NOT allow an intruder to steal your password (or anything else) when you are an HTTPS page.

The problem arises when a web site redirects you back to a regular http page AFTER you login. Many websites do this, Facebook being the one that garnered the majority of attention. When that is the case, the Firesheep user can steal your session cookie out of the air. This is a technical way of saying they are able to get logged in as you. They can then do anything you could do in your account. However, once you click log out in the site, that session cookie is destroyed which means neither you OR the Firesheep user can use it any more. You have effectively just logged out yourself as well as the Firesheep user.

Overall, no doubt... a bad deal.

How to avoid a problem.

There are basically two ways to avoid being "Firesheep-ed", one that sucks and one that doesn't suck.

Way that sucks - Don't ever use open wifi points. Use only encrypted wifi networks that require some kind of WPA encryption. Fixes the problem but means you will no longer be surfing the net while drinking soy chai latte.

Way that doesn't suck - Wifi it up... but only use websites that use HTTPS encryption on ALL pages once you are logged in. Implementing this protection is the responsibility of the website owner but there really isn't much excuse for not doing it. For instance, each of our products including workpapers.com and sas70registry.com use HTTPS during your entire session with the site every single time. So, while your Facebook profile might end up with elicit posts made by the shady guy at the corner table in the coffee shop, your audit data is happy and secure.

The bottom line is watch out for the Firesheep.... but the online world is still not quite the crazy dangerous place that many of the reports on Firesheep made it seem.

Article and Comments »

I was going back through some notes from a conference I went to a over a year ago when I came across my notes about the five dysfunctions of a team. I have never read the book itself by Patrick Lencioni but judging by the reviews on Amazon, I am sure it is outstanding. Anyway, as I reflected on these, I think they are dead on when it comes to the dysfunctions of audit teams. I will elaborate.

1. Absence of Trust

Audit teams very often lack trust. It is a function of the employee rating systems established in the industry, particularly by the "Big Four". The absence of trust between team members leads to an unwillingness to be open and to be vulnerable to criticism. When employees are rated by being compared to each other, internal competition arises and internal competition leads to an unspoken desire for others to fail. When there is known desire for failure, the existence of trust between peers is impossible.

2. Fear of Conflict

This is a big one. Most fear conflict and typically dislike that person on the team who is aggressive and often the source of conflict. Politeness, guarded comments, and language that avoids all appearance of disagreement prevents unfiltered debate. This is a tragedy, particularly as it relates to audits. Open, unfiltered debate is incredibly important to the audit process. Frankly, in most audits, some conflict and tension likely should exist, both amongst the audit team as well between the audit team and the auditee.

3. Lack of Commitment

Everybody knows who the "over-achievers" are in the office. They are hard to work with. The reason is because they expect others they work to carry the same level of passion and commitment that they do. For a lot of us though, there just unfortunately is a lack of passion for the audit business. However, if you're going to bother, be committed. If you can't, no problem. But couldn't the time you spend in your career be better spent elsewhere?

4. Lack of Accountability

This one goes along with fear of conflict. Audits are projects and projects have both responsibility assignments and deadlines. When somebody tries to slide on their commitments, call them out. I know there have been A LOT of audits that would have been completed much more effectively if someone had stepped up and put me in my place regarding my responsibilities. Audit teams need mechanism for maintaining accountability, but ones that increase trust, no paralyze it.

5. Inattention to Results

Finally, my pet peeve. Results matter, quality matters, and DETAILS MATTER. When a team I supervise delivers a result but does so with poor attention to detail (unorganized workpapers, poorly formatted spreadsheets and documents, illogical work programs, etc.) it drives me crazy. This leads to an absence of my trust in the teams ability to conduct thorough, effective audits.

Explicitly avoiding the dysfunctions when developing a team feels to me like a great recipe to manage the "human" side of audit projects. So much so in fact that I have just talked myself into adding the full book to my Audible queue.

Article and Comments »

James Bourke recently wrote what I found to be an extremely thoughtful list of Ten Questions You Should Ask a Cloud Service Provider over on the CPA2BIZ newsletter site. We still detest this term "cloud" in the case of "Cloud Service Provider", but given that we certainly qualify under this definition as it was intended here, I thought that providing concrete answers to these 10 questions may help take some of the mystery out of our "cloud" infrastructure.

To directly quote Jim, these questions are:

Some of the top questions that I would recommend asking before making your final decision (in no specific order, as order of importance will vary depending on the type of data and application deployed)

Here are his questions and our answers in the context of each of the products we develop and maintain (currently including workpapers.com, auditconfirmations.com, and sas70registry.com but would also be applicable to any other products we develop in the future as we are a big believer in this technology stack):

Where will my data be stored?

Our applications are built on the Amazon Web Services computing platform. We selected Amazon for a large variety reasons that I will discuss throughout these questions but not the least of which was because they have both a very thorough SAS 70 report done by Ernst & Young and an excellent track record of providing the best security, availability, and scalability among hosting companies available. Specifically, all of the data stored in our applications is physically stored in MySQL databases. Each application's production database runs on a dedicated EC2 database server instance. Each EC2 instance is replicated across Amazon's computing facilities in a given "availability zone". We are currently using the Eastern United States availability zones meaning production data is geographically located in Amazon run data centers in Virginia and New Jersey (possibly others as Amazon adds facilities in the East).

The only exception to this is the actual documents and files uploaded and attached to procedures in Workpapers.com. These documents are stored in a dedicated production storage bucket on Amazon's S3 service. Storing these documents to S3 rather than our server instances gives the files "durability" of 99.999999% which basically means that three geographically separated Amazon data centers would all have to suffer catastrophic disaster for us to be at risk of losing even one file. Additionally, it makes our storage pool virtually limitless. We never have to upgrade hardware storage which helps us keep pricing reasonable. What this means geographically is that these files are replicated to several physical Amazon data center locations that span the United States. We are also adding additional S3 storage in Ireland that will serve our clients in Europe, the Middle East, and Africa giving them better performance than we can provide from our storage pool in the US.

What type of security and controls are in place to protect confidential and sensitive client data?

We use a careful combination of both preventive and detective physical and logical access controls to protect sensitive client data. Physical access to computing facilities is managed by our hosting provider, Amazon Web Services, whose detailed SAS 70 report we have reviewed thoroughly to verify those controls are adequate. It is particularly important to remember that not only are the facilities physically secured, but that the servers we use are virtualized so even an individual who is inside the data center would not be able to specifically identify our servers and execute an attack. The Amazon SAS 70 also covers logical access controls to host operating systems (e.g. the operating systems on the physical servers that, in turn, host our virtual machines). From there, Workpapers.com controls security of the virtual machines ourselves directly as our systems administrators are the only ones with access to the operating systems and databases on those virtual servers. Our own SAS 70 report (which we expect to be issued in October of 2010) will cover the testing of those controls. As you can see, there is an extremely thorough "defense in depth" strategy in place here that would be essentially impossible for our customers to replicate in their own, onsite environment. Even still, we implement detective and audit controls to further test systems security. For instance, McAfee Secure scans our systems and certifies their security on a daily basis, 365 days/year.

What type of redundancy does the vendor have in place?

Our most important redundancy controls is the real-time data replication that we get from using a virtualized systems infrastructure (Amazon EC2) and storage pool (Amazon S3). Unlike most vendors in the accounting and audit space who operate on older, internal infrastructure, every piece of data we have is instantly replicated across multiple, geographically separated, data centers. That makes data stored with us ultra-durable compared to other vendors or using in-house systems.

Even despite this real-time redundancy, we do our own backups of both our production application databases and the mass of files and documents stored in workpapers.com. We take twice-daily backups of each database, then store the backup to S3 so that it is as safe, redundant, etc. as all of our other files. With files and documents, we copy them to a second S3 storage bucket in case the ultra-unlikely event occurs where Amazon does lose three data centers at one time. We have never needed to restore a file from this second line of backups or the effective "backups of the backups" that are created but they are there, should we ever need to.

Finally, we also maintain a relationship with an entirely separate hosting provider should everything from Amazon across the globe fail, even though that seems nearly impossible. We have thoroughly tested the procedure to restore our applications to this second provider (Rackspace) and are able to move our infrastructure, applications, and customer data over there within just a couple of hours.

What is the vendor’s data retention policy?

Our data retention policy with regards to customer data is to let the customer control it. For instance, in workpapers.com we keep client engagements that have been archived there permanently. However, if the customer deletes an engagement because it is older than their data retention policy requires, we warn the customer then delete it immediately. All of the backup data we take (as noted above) is retained for a maximum of one year. We do not keep backup data longer than one year expressly for the purpose of not having customer data they thought was gone available in the event of litigation.

Who will have ownership of that data?

100% of customer data, without exception, is owned by that customer. We do not and will not ever allow anyone to mine customer data for any reason. This is a contractual obligation on our end as we provide these terms in our terms of service and privacy policy for each product.

In what type of format will my data be stored?

We find data lock-in and format trapping the most annoying and egregious practice among both traditional and "cloud" software vendors today. Your data comes out of our applications as easily as it went in. The most important of our products in this regard is of course workpapers.com. Everything you enter in the system itself like audit procedures, work plans, findings, testing results, etc. is available for download in both Excel and PDF formats. Additionally, you can of course download all the files and documents you have uploaded into the system back out at anytime. If you want to move to a new software platform, we understand... we change vendors sometimes also. You can certainly take every document with you. AuditConfirmations is the same way. Download all of your completed confirmations in a PDF format and move on to another vendor or back to using paper for confirmation procedures. No problem.

What happens in the event of data loss or corruption?

We have not ever lost any customer data, easy as that. In fact, we have never utilized our second line backups outlined above. Every potential data integrity concern we have ever seen is corrected in real-time by our use of virtualization and replication.

What happens in the event of loss of data? Who is responsible?

Workpapers.com maintains specialized insurance coverage that specifically covers the risks associated with being a hosted application provider that covers data breach and loss for all of our customers. However, we cannot afford to lose our own data in our applications so we realize our customers can't either. Thus, we consider insurance only a resolution tool in the worst possible scenario. We are happy to provide evidence of our insurance coverage to customers requiring that.

What if you end up in a fee dispute or disagreement with the vendor?

We have never had a fee dispute because we don't trap (or even ask) customers to engage in long term contracts. We hate trying to buy a cell phone contract for example so why would we put our customers through something similar? Our products are operated under a very simple "pay for what use, stop whenever you want" model with open, public pricing available. We guarantee 99.9% uptime on all our products and if we miss that for any reason other than a planned upgrade which we have notified customers about ahead of time, we'll be happy to refund that month's service. Easy as that.

How financially stable is the vendor and who or what is behind their primary funding source?

We are a privately owned software company and have been in business since January of 2008. We are funded through the operations of our business and we have been profitable since the inception of the business. As our business and our customers grow, our applications and computing infrastructure grow with it. This is the same way most audit firms themselves grow and finance their operations. We frankly feel we are CONSIDERABLY more stable under this operational model than many software companies that are bought and sold between large vendors who may or may not kill off the products you use and care about or venture-backed companies that may have their funding cut-off anytime for whatever reason and don't the profits to sustain operations. We finance our products, we grow our business slowly over time, and we use our products ourselves. We have as much skin in the game as any of our customers.

I (Dan Zitting) personally serve as the CEO of Workpapers.com. I am also a partner in the public accounting firm Linford & Company LLP which provides two services: SAS 70 audits and royalty/licensing audits. Workpapers.com's products were born because they were what we needed in our work and were not available in the market nor was an equivalent available in a price range reasonable for our small practice. It is our background in public accounting that makes our products great. They are built directly from the practitioner's perspective rather than a software developer's. It is also why we are so careful with customer data, my own firm is one of those customers. I am the only person with involvement in both of these businesses and using my position as the CEO of Workpapers.com to identify customers whose clients Linford & Company could pursue would be a gross violation of ethics rules. If it is a concern, just give me a call directly and we can make arrangements to relieve it.

Article and Comments »

In order to remain responsive to the needs of different types of organizations, we are now offering an option for private server installations of the Workpapers.com software. Private server installs will give an organization a dedicated server(s), dedicated database for system data, dedicated file storage buckets, and dedicated firewall where we can implement customized configuration.

We still do not (and will not) on-site customer installations as we feel doing so would put the quality of our service at risk, which we will not do. However, offering private, dedicated hosting gives larger organizations to have to customize their installation to meet specific company policies.

If you are interested in a dedicated server installation, please contact us for a pricing quote. Pricing for private server installations includes a one time setup fee of $1000-5000 (depending on specific needs) and a monthly or annual service fee (starting at $2000/month with discounts for annual payment), just like our standard plans.

Article and Comments »

This feature has been a long time coming. For certain audits, like Sarbanes-Oxley testing for instance, only being able to download the key documents (risk control matrix, walkthroughs, test plans, and testing round results) for each specific objective/saudit area was not an issue as this is how the documentation is typically presented for such audits. However, many other types audits really require having these documents available for the entire project. I found myself personally taking all of the objective-specific documents and using Adobe Acrobat to stitch them together into a document covering the entire project (as I know many of our customers have been as well).

NO LONGER. There is now tab within the “Project-Level Files” section of each audit where you can download the documents mentioned above for the entire project. This is also the case for the audit workplan and audit workplan results documents for “workplan” type audits. The screenshot below shows the new sub-tab with these new “project-wide” reports.

Just as a side note, if you have a giant audit project it can take a few seconds to generate these reports as it takes a bit of time to compile that much data into a single document. A few seconds patience is much appreciated on our end and we hope not having to download these documents one by one from now on will be appreciated on your end.

Article and Comments »