Security Metrics archives - Sister CISA CISSP

Sister CISA CISSP:

Security Metrics

Jul 7 2008   11:38PM GMT

SAS 70 Reports - Why Should You Want One?



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

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.

May 5 2008   8:52PM GMT

Five Myths About Compliance



Posted by: Arian Eigen Heald
Security, Compliance, Data Breaches, Security Metrics

Compliance: The state of conformity of a regulated party (including a corporation, institution, individual or other legal entity) with a legislative or regulatory requirement or a recognized standard.

1. If we’re compliant, that means we’re secure.

Would that this were so! Unfortunately, the letter of the law is usually far less than the spirit of the law. If Management isn’t invested in securing the entire network, they often settle for compliance with existing laws and regulations. Having a secure environment takes a lot of resources, time, and investment in infrastructure processes. Compliance is only the beginning.

2. We have {enter name of software here} so we’re compliant.

I’m sorry, but there is no such software. There’s plenty that give out some really pretty reports and provide some oversight, but that’s very different from securing an enterprise. Usually, multiple layers of software and good people are required.

3. Our vendors tell us they’re compliant, so our information is secure. If they get broken into, it won’t impact us.

Ultimately, it’s YOUR data, whether it resides on a third-party’s web site or inside your network. If they are broken into and your data is stolen, that is what the newspaper will report. Your customers will blame YOU for not monitoring the vendor more closely. You can outsource functions, but not responsibility.

4. Everybody in my organization is trustworthy.

The “fraud triangle” consists of the following elements: Incentive, opportunity and capability. Anyone can find incentive if the opportunity and capability exists. Insider attacks are far more effective than external hackers. Organizations of any size that don’t do internal monitoring are asking for trouble - they’ve provided opportunity, incentive is plentiful and often the hack takes very little capability. If people know they are being monitored, they will think twice.

5. Compliance only happens once a year.

If you have strong security controls, policies and procedures in place, your auditors won’t spend half as much time on site, the audit will not require hours and hours of extra work and you can be quite pleased with yourself at the end of the day. Isn’t it great when you give the auditors what they’re looking for and they go away? If all that stuff is working, you have a secure environment and an audit is a non-event.


Apr 24 2008   9:10PM GMT

How Mature Are You?



Posted by: Arian Eigen Heald
Security, Compliance, IT audit, Admins and Auditors, Security Metrics

I know it’s a leading question, but I think we’ve got to start asking ourselves where we are when it comes to information security and managing risks to our organizations.

Continuing my quest for how to measure good security, I ran across an excellent article on the Information Systems Audit and Control Association website. (Yes, I admit it, I visit there and read lots of stuff) The authors grabbed me with a reasonable title: How Can Security be Measured? and one of the ways to examine the organization’s security posture as a whole is to use a capability maturity model. (CMM). Here’s the good point:

Management needs some measure of how secure the organization is. Organizations need to ask themselves:

* How many resources does it take to be “safe”?
* How can the cost of new security measures be justified?
* Is the organization getting its money’s worth?
* When does the organization know it is “safe”?
* How does the organization compare its posture with others in the industry and with best practice standards?

As you can imagine, there are a number of CMMs out there that relate to information security. The article lists several, and goes on to propose its own. Looking at the different varieties, I scanned over the organizations I have audited over the years, and considered where those organizations were in terms of the size of the business, the number of employees in the IT Department, and the complexity of the IT infrastructure.

The COBIT CMM has a structure I like:

Five levels of progressive maturity:
1. Initial/ad hoc
2. Repeatable but intuitive
3. Defined process
4. Managed and measurable
5. Optimized

Depending on the size of the organization, we can consider it like so:

1. Initial/ad-hoc - Policies are informal, everybody in IT knows all the systems, all the employees
2. Repeatable but intuitive - Policies are informal, everybody in IT knows what to do
3. Defined process - Procedures have to start getting written down, because the department is too big for everyone to know everything on the systems
4. Managed and measurable - Policies are put in place so that change is managed and communicated due to the size and structure of IT and the business
5. Optimized - Policies and procedures are developed to optimize change and manage risk - including compliance with regulations

If you think about your organization today, where are you in this model?


Apr 14 2008   8:48PM GMT

Yes, We Have No Bananas



Posted by: Arian Eigen Heald
Security, Compliance, DataManagement, IT audit, Tearing My Hair Out, Security Metrics

I’ve been reading a fascinating book by Andrew Jaquith, Security Metrics - Replacing Fear, Uncertainty and Doubt. This book takes lots of buzzwords, like “ROSI,” “Risk Management,” “key indicators,” “accountability,” and “compliance,” and turns them on their heads.

It has always bothered me that IT security and IT audit pundits and promoters propose all sorts of theories masquerading as fact for assessing risk. Everyone has a different unit of measurement, including some very large standards organizations. This is simply an attempt to justify the cost of securing data. It has always bugged me because I have yet to see a good explanation for measuring events that have not happened. If there is a solid security architecture, Bad Things don’t happen. Mostly. How to get this across in measurable terms is deplorably difficult to the non-IT parts of the business (usually management).

We’ve been reduced to using “compliance requirements” to justify the cost for “security initiatives” across an enterprise, and that limits their applicability to what the regulations require, rather than basing our efforts on solid evidence for security improvements. Measurements and quantification just do not exist. (Gasp! Heresy, I know.)

How do we differentiate between an organization that has no security incidents because of their solid security practices, and an organization that has no incidents due to blind, dumb luck? Or my personal favorite, no incidents because they don’t have any way to even know if such incidents occur? Yes, we’re fine because we have no idea.

Jaquith does a great job of picking apart the BS Bingo, especially flashy terms used by vendors, who must continually sell you something to stay in existence. (When did true improvement turn into the next release?) If you run a Google search on “compliance,” there are 133 million results. Try the same query minus “.com,” and the results fall to a measly 12 million or so. No wonder most of our security spending has gone to product, not process. Companies have turned to compliance as a metric for good security.

Yes, we have no real idea what constitutes good information security practices.