ShackF00

This is NOT intended to be a mean and/or overly cynical post. By no means do I imply that auditors are bad in general, in fact I have been one and still do audit and compliance work today. But there’s some unspoken truths that I’ve encountered over the years, from both sides of the fence. Things that people think and won’t say, and some common circumstances that are just a fact of life in the world of auditing and regulatory compliance. Here goes.

1. I am actually just following a checklist. And that’s that.
2. I do not understand the technology I am auditing. This is really common, and it shouldn’t come as a surprise. Too many technologies, not enough technically skilled people in audit.
3. The well-dressed, experienced greyhairs came in and sold this deal, but I graduated from college 8 months ago and went through ( E&Y || IBM || Deloitte ) auditing bootcamp. And numbers 1 and 2 on this list are present, too.
4. Most firms are really incentivized to help you pass. Why? Because in many cases, you can fire them and get a new  firm that is “easier” on you. This is not a universal truth. But it’s a big business, and no firm wants to get a reputation as “very difficult”. Leading us to…
5. Show me a viable set of compensating controls, and I’m liable to pass you. Or at least get you a neverending series of extensions. This could be exactly the right thing. Or not (if #1 and #2 are in play). They have to be reasonable though. (See #10)
6. Auditing standards suck. Although ISACA and other organizations are trying really hard to help with this, try finding a commonly-accepted auditing standard for Cisco ASA Firewalls, or Ubuntu servers. Lots of random sites, some more well-known than others, but still no universal standard.
7. Compliance regulations suck. They are almost all poorly written, vague drivel with 50 pages to somehow ambiguously describe one central point. PCI is much better, but still lots of grey area. This, combined with #6, leads us to…
8. You can’t have it “your” way. I’ll work with you, in a polite and professional manner. All part of the schtick. But at the end of the day, I’m following my auditing methodology, with my particular interpretation of things, and whatever skills and knowledge I bring to the table. So yes, it’s all about me.
9. I know more than you. The antithesis of numbers 1, 2, and 3 on this list. Sometimes auditors really do know a LOT about an area or areas, and they can really guide you. Two problems usually occur here. First, egos get in the way. Major gender in IT? Male. Do men stop and ask for directions often? No. Second, money and time. Auditors can be educators, sure. But most of the time, they’re there to gather information, provide a report with recommendations, and then check back in. They’re usually billable, and many organizations aren’t paying them for a huge number of training hours.
10. Covering my ass is my major goal. No auditing firm will forget the lessons of Arthur Anderson. Although some firms may still be less-than-ethical, most are 100% aboveboard and will pester the everlasting crap out of you to get enough detail to justify audit results and recommendations. This is ultimately a great thing for everyone, as audits are probably more thorough. But no one likes to admit this.

And here’s a bonus:

• I know you probably don’t like me. And that’s a shame. Better communication and collaboration with auditors would go a long way toward improving audits, controls, and likely security as a whole.

Information Security

And what about ethics?

This is not quite a book review, not enough time for all that, but I did just finish reading an excellent book, really the first of its kind that I’ve encountered. The book “Adventures of an IT Leader” by Harvard Business Press is written as a story, not some horribly dry academic treatise on the subject of managing IT. The plot, in a nutshell, is about a business leader in a turnaround company (new CEO) who is asked to take over IT and shape it up. He knows nothing about IT management, is not technical, and is under a lot of pressure from day one. The book then goes through a series of events and circumstances in this guy’s first year on the job.

I loved it. In fact, for any technical person in IT or infosec who wants to get a good grasp of business decisions and the process you’ll go through in making them, this is a fantastic read. A little contrived, and if you’ve been around a while, you’ll recognize some things and already know others, but a fun book nonetheless.

Why am I talking about it, though, and what’s the relation to the title of this post? Well, about midway through the new CIO’s tenure, the company has a security issue. This is a major topic in the book, although they stereotyped us “security types” a bit (purple hair? Skull T-shirt? C’mon, that’s only for Defcon for most of us). I won’t give away too much plot, overall, but here are the relevant facts:

• Company has sensitive financial data on people (they process loans)
• A fair-sized risk exists due to coupling of an acquisition’s network, security and IT have known about this for a while. Nothing was done (budget priorities.
• Company’s site experiences a DoS attack, coupled with some odd behavior that makes them THINK customer data may have been accessed. They can’t find definitive evidence (logs, etc) however.
• Legal wants them to be proactive and notify customers to be alert for strange account activity.

This brings us to the executive meeting where everyone has to decide what to do. To make this short:

• New CIO recommends a pretty drastic plan to wipe systems and start clean to make sure no more compromises exist. 2-3 days of downtime, planned for a weekend, still a big impact. We all know this isn’t that practical in real life, either, but it’s not wholly unrealistic.
• CEO says “Hell NO” to notifying customers AND shutting down systems. In other words, no GNUs is good GNUs.
• Head Legal Counsel and new VP of Loan Operations (new CIO’s replacement) challenge the CEO, saying they should notify customers to be proactive and wipe the systems.
• CEO promptly fires them both. Meeting adjourned.

Wow. This was a very interesting case study, and one that did not seem TOO unrealistic to me, frankly. There are some later follow-ups in the book, where the CEO explains that business can be a gamble sometimes. Risks have to be taken, regardless of a “higher moral ground” kind of stance. Also, keep in mind that there was no DEFINITIVE proof of data leakage, just suspicions. Other hacking activity (like the DoS) was present, but a data breach was not certain.

What do you think? Aside from legal requirements to notify, if a company feels that it can protect its reputation and save jobs, stock price, etc…is there an occasion when the “silent fix” is the right approach? In other words, clean up the backyard but don’t say a word about it? What if they did the risk analysis and determined there was a 80-90% chance they could pull it off? Mind you, I’m not necessarily espousing this approach, only debating.

Information Security

So it’s time to add a new installment of “BS Filtering for CISOs”. AS I stated in the first post of this series, BS filtering is a critical skill for CISOs everywhere, just as vital to the success of an information security team/program as content filtering and packet filtering for the technical members of the staff (not to suggest, of course, that the CISO isn’t or hasn’t been technical, far from it).The concept of “BS Filtering” does not always mean that people are deliberately trying to con you, though; you may just need to read between the lines, dig a little deeper into statements, etc.

This is particularly the case for dealing with vendors and 3rd parties, where you can get easily misled, contractual language aside. Here are a few tips specific to security professionals that I’ve gleaned over the years.

• Understand the business motivations first. By this, I mean understand what each party wants to get out of the negotiation. In the case of a vendor, it may simply be another sale or a new customer relationship. In the case of a business partner, they may be looking for a new sales or marketing channel, a means to increase revenue directly with you, or they could even be looking for a strong reference partner/customer. Knowing what the underlying motivation is can help you to have a more intelligent business discussion about risks and rewards for both parties involved.
• Do your homework. This sounds like common sense, and to some extent it is, but there’s a few concrete examples for security pros that can be useful to keep in mind:1. Talk to customers, preferably those in the same or similar business as you. You need to get an idea for how security has been handled by this vendor or 3rd-party during the course of their relationship. Put together a list of things that would concern you, and ask to speak with a customer they’ve had for at least a year or more. If they are reluctant to do this, you should be extremely skeptical of doing business with them.

  2. Ask them how they handle sensitive data covered by compliance regulations, if this applies to the scenario. Particularly with the advent of cloud computing and other hosted/provisioned applications and services that are remote from your data center(s), this becomes absolutely critical.

  3. Related to #2, ask them how they will demonstrate adherence to your internal and organization-specific security policies governing sensitive data. How will they keep it separate from other customer data? What guarantees will they give you? How will they respond to a data breach? There should be some contractual language crafted around the answers to these questions, once you’ve had the discussions.

• Ask to see a SAS70 (at the least) or other indication of security in the area where your data/systems/applications will be housed. If possible, arrange a site visit for you to personally inspect the premises and do your own due diligence. I’ve fought for this and won before, and so can you.
• Ask for audit results if possible. Especially those related to your particular data types, such as payment card data.
• Inquire about configuration and hardening standards, and which the organization uses. Do they follow CIS guidelines for Windows builds? Do they use the DISA ESX controls for hardening VMware platforms? Ask to see proof of the build (or image maintenance/deployment) and how often it is audited.
• For vendors hawking gear/software, ask about the volume of support cases maintained and CLOSED on a daily/weekly/monthly basis. Inquire about average turnaround time for support cases, and of course ask to speak to customers before you buy. This really comes down to availability at the end of the day, if the product doesn’t function properly it may be largely useless.

These are just a few of the “anti-BS considerations” you will need when evaluating business partners, vendors, and 3rd party providers. This doesn’t take into consideration the majority of typical operational considerations like uptime, SLAs, etc. For security pros, the most pressing issues are related to handling of data, adherence to internal and external compliance and policy requirements, and availability for security-specific products and services.

Information Security