SAS 70

Aug 21 2008   3:48PM GMT

How to Audit Databases: Part I

Posted by: Arian Eigen Heald
Security, Admins and Auditors, Compliance, Database security, Identity theft, IT audit, PCI DSS, SAS 70, SOX, Database, DataManagement, Data Breaches, Oracle, SAP, SQL Server

Databases are enormous, powerful repositories of data. They can hold payroll, HR personnel data (think social security numbers) stock prices, Accounts Receivable, Client Relationship Management, and customer information. Banks can’t live without them. Most medium and many small sized businesses use them, too.

They are the motherlode of the organization and the last line of defense in a hack. It’s critical that DBAs have the tools at their disposal to monitor and provide reporting. If your database isn’t secure, the hacker won’t care how well indexed it is.

And there are a lot of ways in. If I have administrative access to the server, I can copy all the database files, take them away and reload them on my own database server. If I have unencrypted backups of those files, I can do the same thing.

So the first step in auditing the database is to examine the server the database is running on. This gets confusing to non-DBAs and auditors because many of the terms used inside the database are similiar to server terms. It’s important to keep them separate, and to make sure that access to the database files on the server is monitored. Server administrators do not need to have access to those files, but they may have to, in order to manage/backup the server. So, set up logging.
Make sure everyone who has a need to access that server administratively has a unique ID. Remove access to root(*NIX) or Administrator (Windows). They can have administrative rights, just make sure you can identify them by ID and IP connection.

Finally, what about the backup tapes? If they are not encrypted, you can join the “breach list” of companies that have lost their data when tapes were misplaced, stolen, or “disappeared.”

NEXT: Inside the Database “Server”

Aug 19 2008   1:20PM GMT

I Can Make Your Database Lie to You

Posted by: Arian Eigen Heald
Security, Admins and Auditors, Compliance, Database security, Identity theft, IT audit, PCI DSS, SAS 70, SOX, Database, DataManagement, Data Breaches, Oracle, SAP, SQL Server

So many financial auditors, CEOs, CFOs and others rely on electronic data to understand the complexities of General Ledger, Accounts Payable, etc. In this era of SAP, ADP, electronic time clocks, etc., the one common denominator is the database underlying each application.

Applications aren’t something you just run on one PC anymore (I know I’m preaching to the choir, here). Financial applications, especially, are all networked, and the storage is usually a relational database like Oracle, MS SQL, Sybase, DB2 or MySQL. Relational databases are wonderful for business because you can correlate so many different facts.

So why are they so scary to me? Because they are rarely audited.

I need a network ID to log in, so the database is safe, right? No.

The application has security controls, so my database is safe, right? No.

DBAs (Database Administrators) know exactly what I am talking about here. All those items are just the outer edge of security. If I have a network jack and a database ID and password, I can bypass those controls easily.

Some applications have a database ID and no password, or an easy-to-guess password. And very frequently, that ID has access to everything, including reads, writes and deletes.

If I have that ID and a network jack, I can log into your database using ODBC, Microsoft’s Open DataBase Connection client software that is installed by default on Windows operating systems. I can use Excel, Access, or other database software to pull all your data out.

Or change your data.

And P.S., connecting with ODBC uses clear text usernames and passwords, which is how I once captured a DBA’s ID and password with a sniffer.

Fortunately for all of us, there are usually other financial controls that can capture errors or changes in the database. Usually.

NEXT: How to Audit Databases

Jul 29 2008   11:16AM GMT

What NOT to call SAS 70 Reports

Posted by: Arian Eigen Heald
Security, Admins and Auditors, Compliance, SAS 70, SOX, DataCenter, Start Laughing Now

I ran across the new website “securityidiot.com” in my travels, and was reminded that it is so important to be able to laugh at yourself (and others!). It’s so easy to turn a Bad Idea into Bad Technology, these days. Or worse, another new acronym.

You should especially check out the rant on InfoSEC SPEEK that had me ROTFL. (Are “old” acronyms still OK? Or just old?) Between the hackers, the vendors, and our own pretentiousness, don’t we really have to wonder how anything really gets secured?

For example, following up my previous posts about SAS 70 audit reports:

“SAS-70 Certified” (They obviously haven’t read their own report. Maybe that’s a good thing for the rest of us.) I went to Google, just for fun, and searched on the topic after seeing one such statement in an RFP (Request for Proposal). There are an astounding number of responses for businesses that are listing themselves that way. Has no one ever told these folks that there is no such certification???

“CompanyName participates in an annual audit performed by an independent accounting and auditing firm and receives confirmation of our continued compliance with SAS 70 standards.” What standards? What compliance? It’s their own controls that were tested. Where are they getting this stuff? It’s almost painful to read.

Or, in a total munge of regulations:

“AnotherCompany, a premier provider of back office, accounts receivables and financial services announced that it has received full SAS 70 certification. This fulfills Section 404 of Sarbanes-Oxley, the corporate governance accounting mandate.” Wrong added to more wrong. SOX is not a mandate, a SAS 70 audit does not fulfill Section 404, and it’s still not a certification.

Then there’s the businesses that market themselves as having “passed” or “earned” a SAS 70. Writing your own test and passing it - Wow. What an accomplishment! For our sakes, I hope it was an “A” grade and not a “C.”

BAD marketer. BAD.

It also calls into question the quality of the organization. I don’t know about you, but reading that sort of publicity announcement from a Data Center would make me really nervous about putting my data there. And if you search those terms together on Google, there seems to be an embarrassing number (more than zero) of “Data Centers” that are doing just that.

The same feeling would apply for outsourcing my financial processes with the accounts receivable/financial services people. Some medical benefits administrators have “passed” and “earned,” too.

And it’s REALLY embarrassing when a public accounting firm offers such a “certification.”

Ouch. It hurts when I laugh.

Jul 24 2008   8:37PM GMT

SAS 70 Report: Section 2 - What to Look For in This Section

Posted by: Arian Eigen Heald
Security, SAS 70, Admins and Auditors

In this section of the report, it is common to find it titled “Description of Controls Provided by (Company Name).” The company being audited provides a narrative description of itself, their critical applications (usually the ones providing a service to clients) and general controls. Often, the service auditor will assist in the write-up of this section, but legally, it is the responsibility of the company to determine that what is in this section is correct.

You will want to review carefully the subsections on their organizational structure, and how they manage new employees. Do they provide annual security training? Are background checks used? How do they add and remove users?

The subsections on critical applications should have processes in place to add and delete users, as well as a periodic review of users to make sure there is no “access creep.” (Where people move departments and keep both their new access and their old access.)

Review their Change Managment/SDLC (Software Development Lifecycle) subsection to see how diligent they are in testing code before it goes into production, and if their testing process is documented. They should have software that acts as a code repository and controls code changes. Programmers should not be moving code into production systems. If they only have off-the-shelf software, they still should be managing updates and patches.

For network management, they should be fairly specific about common practices, such as password controls, patching servers, routers and managing firewalls.

There should be a section on physical and environmental controls. This should include access controls, fire alarm systems and power redundancy. Sometimes this area in the narrative will include backup controls as well. Where are they storing their backup tapes with your information? Is transport of those tapes secured? How about disposal of hardware and paper documentation? This can be really important when the SAS 70 is covering a medical services bureau, for instance.

Make sure the narrative addresses your how the service bureau protects systems that hold your company’s assets. If they only assess the Windows domain, and your data is on a Linux server in the DMZ, how do you know how secure your data is?

In short, look for what isn’t there.

Jul 17 2008   6:56PM GMT

SAS 70 Reports - Section One

Posted by: Arian Eigen Heald
Security, Compliance, IT audit, SAS 70, SOX

Commonly, a SAS 70 Type 1 report contains three sections, and a Type 2 has five sections. That because a Type 2 tests the effectiveness of the controls that a Type 1 says are there.

The first section, the “Independent Service Auditors’ Report,” is basically a letter by the service auditor (the CPE firm performing the SAS 70 exam) to the management of the service company (the company being tested in a SAS 70 exam) providing an opinion, with some standard legal coverage, on the quality of the controls in place at the company.

The paragraph after that, if the report is a Type 2, will also express an opinion based on the tests performed as to the effectiveness of those controls. There will also be a disclaimer that the report only provides reasonable, not absolute, assurance that the controls were in place and operating effectively.

Why?

When performing a SAS 70, the auditors are dependent upon what the service organization gives them for information. When I perform logical controls testing, I must ask the service network administrator to give me the information I need for an assessment. We must rely on what the service organization provides us. We do not test the environment directly. Most organizations are loathe to let some auditor have admin rights and go wandering around their network. How, then, do we ascertain the correctness of the information?

The short answer is in the contract. SAS 70 auditors will indicate in a contract for services and in the report that they base their opinion on the information they are given. The onus is on the service company to provide true and accurate information to the auditors.

So this is not a “true” security audit, in the sense that we are not directly testing the environment. (And P.S., only a CPA can perform an “audit.” Everything else is an “exam” or a “test,” or an “assessment.”) But remember that this is a report for your company’s financial auditors, so that they can determine whether the outsourcing agreement with the service bureau is protecting your company’s assets.

But can’t the service company lie to the auditors? Sure. But they take the risk of having their socks sued off if they are committing fraud. That’s also why the financial auditors perform a financial “due diligence” on outsourced companies on an annual basis to make sure they are on sound financial footing. The SAS 70 report is just part of the due diligence to protect your company.

On to the next sections.

Jul 15 2008   6:34PM GMT

SAS 70 Reports - Reading What You’re Getting - From The First Page On

Posted by: Arian Eigen Heald
Security, Admins and Auditors, IT audit, SAS 70

So you have this report from the company you’ve outsourced a critical financial service to, and it looks like a lot of boilerplate with a chart of sorts at the end. What are all those sections for, and why should you care?

First, determine that the company performing the report is a certified public accounting firm. This is the only legal entity permitted to perform a SAS 70 type audit, regardless of whether it is a Type 1 or a Type 2. Other firms can perform SAS 70 “readiness assessments,” but not the SAS 70 exam itself.

The first page can tell you whether it is a Type 1 or Type 2 audit. The subtitle:

Report on Controls Placed in Operation
and Tests of Operating Effectiveness
Prepared in Accordance with
Statement on Auditing Standards No. 70

indicates a Type 2 by virtue of the statement “Tests of Operating Effectiveness.” If you’ve read a previous column, you know that a Type 2 looks at controls and tests those controls. That’s a Good Thing.

The next thing you should see on the first page is an indicator of when the controls were tested. The date range is commonly a year, but it can also cover a six or nine-month period.
This means the auditors have tested controls over that time period to see if they were actually in place and effective.

Consider how long ago that date range was. Some organizations will attempt to use a SAS 70 report that is two or three years old. Regretably, some auditors will take 4-6 months to issue a report - which can mean that what you’re looking at has limited value. The longer the period from the actual test of controls, the less value the report has, because it cannot report on the current state of controls.

Jul 11 2008   1:46AM GMT

“SAS 70″ - It Pays to Actually READ What You’re Getting

Posted by: Arian Eigen Heald
Security, Compliance, IT audit, SAS 70, SOX

When I do an audit and request that my client give me SAS 70 reports from his/her critical financial vendors, I am often amazed (or appalled) at what I get to read.

My team performs about 20-25 SAS 70 Type IIs every year, and maybe 2 SAS 70 Type I exams. Why the big difference? Type II exams actually test the controls the service organization says it has in place. In a Type I, all we test is that the company says it has controls, and that those controls appear adequate. BIG difference. It’s also a big difference in price for the service organization, so that companies try to get a Type I if they can.

Sometimes a service company will start with a Type I, planning to go to a Type II. I’m inclined to recommend getting a SAS 70 readiness assessment, then completing a Type II - it saves money and makes clients happier. More on this later.

Also, Type I exams only look at what control procedures are in place at the time the service auditor comes to visit (called “Point in Time,” appropriately enough). They can throw out the controls the day after that. So this type of SAS 70 has limited value to clients (your company).

For Type II exams, we test over a period of time, say the six months, or nine months, or 1 year previous, to ensure that the controls were in place and effective. The downside is that it is previous time testing, so if the controls fall apart three months after the test, I can’t report that until (or if) I come back for the next test. But it does give considerably more assurance that controls are in place, if you can see that in the previous year what we have tested is in place.

SAS 70 exams must be signed off on by a certified public accountant, even if CISAs are doing the testing on site. Make sure the company that did the test for your outsourced service is exactly that. Otherwise, the report is not legal in a court of law.

I have seen proposals (just two weeks ago, from a very big service company, as a matter of fact) that announced they were “doing” a SAS 70 as part of their security; number one, they can’t “do” one, and number two, a SAS 70 isn’t a “security” exam.

It’s an exam to provide reasonable assurance to the client company’s internal financial auditors.

So, when reading the report, you’ll want to pay attention to the sections that describe what they’re doing to protect YOUR data. If your company is using a specific application over the web, what are they doing to provide safeguards for your data on that web server or database?

A little over a year ago I reviewed a report on exactly this issue; the report tested the office Windows Domain for good control practices but never addressed any controls over their application web server: a Linux box. (Scary, isn’t it?)

There’s generally several sections to the SAS 70 report, and it’s worth knowing what to look for in each section. We’ll touch on that next.

Jul 7 2008   11:38PM GMT

SAS 70 Reports - Why Should You Want One?

Posted by: Arian Eigen Heald
Security, Compliance, IT audit, SAS 70, SOX, DataCenter, Security Metrics

There seems to be a lot of mis-information about what a SAS 70 report is - just today I came across a post that referenced being “SAS 70 - compliant.” There is no such thing. There is no pass/fail aspect to a SAS 70 because the Control Objectives and Control Procedures are designed by the client. It’s hard to flunk a test you designed for yourself (although I’ve seen lots of companies that do it).

A Statement on Auditing Standards #70 is used exclusively by service organizations that provide a critical financial service to their client businesses.

For instance, if your company outsources health care management to another company, your company will want a SAS 70 report from the health care management company. Why? (For starters, it’s good to know your health care mgt company takes good care of your money and personal health information.) Because your internal financial auditors are going to demand you get one from them. Health care management costs a lot of money and can have a big impact on your company should they not have good practices in place.

SOX regulations require that companies that outsource services that provide a critical financial function have a SAS 70 from that company. Banks are required by the FDIC to have SAS 70s from any service that provides a critical financial function.

So, your internal financial auditor is asking because he/she must meet regulatory requirements. Any time your company outsources a service that is deemed a critical financial service to the company, they should be asking for a SAS 70. And not just any old SAS 70.

Jun 12 2008   7:18PM GMT

SAS 70 Reports - Are They Worthwhile?

Posted by: Arian Eigen Heald
SAS 70, Admins and Auditors, Compliance, IT audit

I noticed a recent post on the boards questioning the value of SAS 70 Reports. Given that I do about 15 a year, I thought I’d venture an answer to that question.

First, it’s important to understand what a SAS 70 is NOT:

It’s not a checklist;

It’s not a certification;

It’s not a security assessment;

In fact, it doesn’t do a thing for your network security, except, perhaps, inadvertently. It does not directly attest to the quality of your network security, either; that’s not its’ function.

And only a certified public accounting firm can do one, because a certified public accountant must sign off on the report.

So what CAN such a report do for your organization, and why? Are your customers constantly asking for one? Are you losing business because you don’t have one?

That’s next.