Sister CISA CISSP:

IT audit

May 23 2009   10:25AM GMT

When a Control is NOT a Control or, “It’s Good Enough”



Posted by: Arian Eigen Heald
Admins and Auditors, IT audit, Compliance, Steps to an Easy Audit

I run into an awful lot of engineers who hate paperwork (I feel the same way.) They are busy fixing problems, building new application support and dealing with upper managers who have no idea what they’re asking for, clueless users and now I come along to top it off asking for a bunch of documentation.

Been there, done that.

I gently explain, after I have corrected their misapprehension that auditors know nothing about IT, that if it’s not written down, it doesn’t exist. I know some engineers who believe in job security that way, but the fact is it just makes it harder for the next person to step into that role. That role will always exist. So why make it easier for the next person? Sooner or later, that next person will be you.

Why write down how a server should be built? Why write down how the servers get patched? Why bother changing the administrator password on all the servers and a different one on all the workstations? Why check to make sure that the anti virus server is actually updating all those machines? Why test to confirm that the group policy for downloading patches is actually working, and how to do that?

It’s part of being a professional engineer. It’s part of all the certifications we have signed off on; that pesky ethical paragraph that asks us to be responsible, dedicated and at the top of our game whether the job asks for that, or more commonly, does not.

It’s also a really great way of showing just how much work you do.

“Good Enough” is short for “Good Enough to Get Hacked.”

Bottom line? When you are sitting in front of a judge testifying as to what steps were taken to secure your organization, you WILL be asked what policies, standards and procedures you were following. If you have none to give the judge, you will be roasted by the jury, and your company will lose its case.

We can blame the company for not “making” us do it, but that’s not the real deal, is it?

Jan 13 2009   3:34PM GMT

The Purpose of Audit



Posted by: Arian Eigen Heald
Database security, Data Breaches, IT audit, Admins and Auditors

Bruce Schneier’s last cryptogram contained a discussion about the purpose of audit. He was commenting on the fact that Barack Obama’s phone records, passport file and aunt’s immigration status was inappropriately accessed by employees of the State Department, Immigration and Verizon employees.

Because of good audit controls, the State Department electronic monitoring alerted supervisors when information was inappropriately accessed. Verizon fared less well, and Immigration has no idea who accessed the information.

“Audit helps ensure that people don’t abuse positions of trust.” Too bad Countrywide didn’t have such alarms in place to catch the guy siphoning off information to sell. Or the guy who walked out the building with hundreds of thousands of dollars of hardware over the course of 10 years.

With hard statistics this year that insiders, either by ignorance or malfeasance, have been a large source of data breaches, having good audit trails and controls in place makes more and more sense.

With so many large databases out there holding such private information, how can we continue to pretend that it only happens to other businesses? And complaints about the cost of security just aren’t cutting it anymore. The incredible COST of a data breach just keeps rising.

Pointing fingers and saying the other guy should be responsible for security doesn’t work either. Ultimately, responsibility rests with those who have the data to safeguard the data - no matter what form it takes: inside a database, on a backup tape, on a laptop, on a web server.

If we’re going to use personal information to make money for our business, we’d better be prepared to protect that information - from ourselves and other employees.


Dec 28 2008   3:14PM GMT

Securing the Security Devices



Posted by: Arian Eigen Heald
Compliance, Security Devices, IT audit, Hardware & InfoSec, Tools for Auditing and Security, TCM (Truly Clueless Management), Admins and Auditors, Tools & Tricks of the Trade, "How Do You Know?"

OK, so you’ve bought the glow-in-the-dark, meets all the compliance requirements and looks really shiny “security solution” from a vendor (one or many).

Or maybe your management has bought it and presented it to you as a fait accompli. (Hope I’m spelling that fancy French right!) And of course either you have to manage it (without training, “that’s too expensive, just watch the consultants put it in”), or it’s been “outsourced.”

Or as an auditor, you’ve been told to use it for all auditing functions, and not worry about doing any follow up or periodic testing because this product is such a “time-saver.”

So, how do you know (my favorite question) it’s working and doing a good job? Not what the fancy report it produces says, not what the consultant says, not what the manual says, not what the boss says. What you can actually see.

I’ve been following a discussion on the Security Focus “pen-test” mailing list about how security software has just as many issues as regular software. I don’t like thinking that the software protecting me and writing to a SQL database is using an unencrypted ODBC connection that can be captured by ARP poisoning.

So, although I am rarely asked to audit or test a firewall, IDS or host IDS, having run and learned on all of them, I have some suggestions for you to try out.

NEXT: How to Audit Your IDS/Firewall/ECM for free.


Dec 24 2008   7:14PM GMT

Getting What You Pay For…..2008



Posted by: Arian Eigen Heald
Security, HIPAA, Compliance, Database security, IT audit, Admins and Auditors, Tearing My Hair Out, SAS 70

In my travels as an auditor this year, I’ve visited 15 states and seen approximately 20 different networks, both LAN and WAN. I’ve audited hospitals, lotteries, racetracks, banks, small businesses, large online retailers, metal fabricators, telco service bureaus and health care service bureaus.

I continue to see networks that are not patched. “It might break our custom code,” is the most common excuse, followed by, “Gee, we just didn’t get around to it.”

Software coding continues to be a security disaster in the making. Developers continue to open up databases by giving too many rights to users and application IDs. I still find individual developer IDs inside production databases.

Management continues to be unwilling to invest the money in a secure architecture. In the last three years, I can count on the fingers of one hand the organizations I’ve seen that follow secure best practices. And not use all the fingers.

I still hear people try to tell me that they don’t need a firewall because they have really good routers. And then they don’t update the IOS on the routers and/or leave the default SNMP strings in place.

If you are paying for these services, and you are getting the above, there is a problem waiting to happen on your network. If you don’t know what’s going on in your databases, time to find out before another Countrywide happens in your back yard.

Have a safe holiday. And remember: who is responsible for good security? You are. I am. Let’s keep trying to do it right.


Nov 25 2008   2:57PM GMT

Data Breaches and Business Liability Part I



Posted by: Arian Eigen Heald
Security, HIPAA, Compliance, Identity theft, Data Breaches, PCI DSS, IT audit

The most significant financial impact of identity theft has yet to be examined. I believe that the risks to business and other institutions now include legal, reputation, financial and compliance risks that cannot be transferred.

Victims of identity theft are looking to recoup their financial losses and punish those people or institutions that enable identity theft to happen. The average arrest rate (according to law enforcement) is under 5% of all reported cases. Thieves do not have the resources to repay their victims by the time (or if ever) they are caught. Business does. If business organizations are providing the opportunity for identity theft to occur, they will be sued. We should make it our job to see that we are not among the defendants.

According to the Identity Theft Resource Center, (An outfit that I happen to respect a lot because they are very specific about their statistics and criteria of what a “breach” actually is), As of November 11, 2008 there have been 574 breaches, with a total of 33,593,557 records exposed.

You can download the report at their site. It’s painfully interesting.
Here’s how it breaks down, keeping in mind that we’re not done with 2008 yet:

Category: Banking/Credit/Financial
Number of breaches: 66
Number of records: 17,231,057
Overall % of breaches: 11.5 (2007? 7%)
Overall % of records: 51.3% The fewest breaches, but the most loss of data. Thieves are not stupid.

Category: Business
Number of breaches: 202 The most number of breaches. We need to get much stronger here
Number of records: 5,705,628
Overall % of breaches: 35.2% (2007? 29.3%)
Overall % of records: 17%

Category: Educational
Number of breaches: 120
Number of records: 761,303
Overall % of breaches: 20% (2007? 24.7)
Overall % of records: 2.3%

Category: Government/Military
Number of breaches: 100
Number of records: 2,656,407
Overall % of breaches: 17% (2007? 24.5%)
Overall % of records: 7.9%

Category: Medical/Healthcare
Number of breaches: 86
Number of records: 7,239,162
Overall % of breaches: 15% (2007? 14.5%)
Overall % of records: 21.5%

Why do these statistics matter? Because, one way or another, every business and every person is affected.


Nov 17 2008   9:42PM GMT

Educating Users (Yes, I Know….)



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

I can hear the collective eye-rolling from here. But guess what! New federal regulations are requiring security education from organizations as part of compliance:

SEC regulations for financial institutions http://www.sec.gov/index.htm
NERC regulations for utility organizations http://www.nerc.com/files/RSAW-CIP-004-1-060608.doc

According to a study just finished by Cisco, “Data leakage often results from risky behavior by employees who are unaware that their actions are unsafe. Some of this problem can be attributed to a lack of corporate policy or inadequate communication of corporate policies to employees. In other cases, IT professionals simply expect some degree of professionalism, security awareness, and common sense precautions on the part of employees-and don’t get it.

• 43 percent of IT professionals said they are not educating employees well enough.
• 19 percent of IT professionals said they have not communicated the security policy to employees well enough.”

The SEC regulations affect publicly traded companies, so if you regularly undergo SOX audits, this will definitely be part of the package. PCI has also had a requirement for quite some time. So, in short, you cannot escape. And besides, I suspect there are some things YOU can do to improve the understanding of your users. They are a very important part of YOUR network.

Who does your information security training? Have you taken a look at it lately? Is it any good, or just “CYA” material? See any improvements after training on the part of your user base? If not, maybe it’s time to change it.

How “user-friendly” is your organization/department for employees that want to ask computer-related security questions?

Are chronic problem users tracked, and their managers notified? (I love this idea…)

There is a rising tide of studies confirming that internal data theft and loss is far more costly to business than external attacks. All it takes is one user clicking on one phishing email to compromise company information (even a corporate email list is important). A monthly email from you explaining a topic, and inviting questions might result in a LARGE saving of YOUR time dealing with infections and information compromise.

And hey, you’ll be compliant! Auditors love you!


Oct 20 2008   1:06AM GMT

Let’s Get Physical



Posted by: Arian Eigen Heald
Security, DataCenter, IT audit, Admins and Auditors, Tools & Tricks of the Trade

When I do an audit, or a penetration test, I start by walking around the building, both inside, outside, and sometimes even on the roof. In my travels, I’ll leave my business card where I can gain unauthorized access. How often am I successful? 95% of the time.

I mentally catalog the exterior doors, the signs on them, and I keep an eye on whether people use them a lot. Then I monitor where the smokers go; I’ve often been able to enter a building undetected that way.

From there, I move to the Data Center. How many doors? Do the doors close firmly and immediately behind whoever enters? I’ve gotten in that way, too.

How about door locks? At a business I was at recently, they were still using push-button locks with a four digit code. After the fourth visit to the server room, I had the code in my head. They couldn’t recall when the last time was they had changed the code, either.

Keys? How many keys are there? I’ve never seen a key that couldn’t be duplicated. How about having to deal with when they get lost? One memorable evening, I went around the IT staff’s desks, looking in desk drawers (in pen tests, all “politeness” is off). I found a very nice key ring labeled “Server Room.”

What about contractors or cleaning people? Does someone escort them while they’re in there, or are they left to their own devices? As boring as that is, leaving someone alone with the corporate crown jewels is equivalent to unlocking the barn door. Are the server cages secured? Are there segments to your Data Center, so that the really significant equipment is in a further secured area inside the Data Center?

I recently visited a really nice Data Center, and the Security guys were very proud of their camera system. It was an excellent system, covering all the doors. But what about once someone actually gets in? What are they doing? Where do they go? The company used a lot of subcontractors, and I pitched to the Security guys the idea that they needed cameras for all areas of the Data Center, not just the doors.

They needed to be able to see where someone went down the server rows to do their work. It’s great physical evidence that says it all in a court of law. If someone says they didn’t touch that server, and you have pictures showing them walking down that row and stopping at that rack, well, game over.

We often think about hacking or breaches as something that is completed with some esoteric piece of magical computer code. I think like the bad guys: what’s the easiest way in?


Oct 6 2008   8:19PM GMT

Auditing iSeries



Posted by: Arian Eigen Heald
AS/400, Security, Compliance, IT audit, Tools for Auditing and Security, Admins and Auditors, Tools & Tricks of the Trade

IBM’s system iSeries are some of the most solid server systems around. Formerly (and by some, still called) the AS400, those servers are at the top of the food chain for reliability and stability. DB2, the native database system for iSeries, is as solid as a rock, and powers many of the banking, healthcare and service industries I get to see.

A lot of engineers will tell you that the iSeries is the most secure OS around, due to the object-level security functions. Those object levels are great, but I can tell you that I find that iSeries are incredibly easy to get into, for two reasons:

First, default services are left enabled. FTP, DDM and ODBC ports on the server are open, and unless you have an exit program, no logging of access takes place. So if I have an application ID and password, I can gain access to see what I can get into. Try a port scan and see what the server tells you.

Last year I saw an iSeries at a merchant (details fudged to protect the guilty) that had NETBIOS enabled. Sitting on a Windows 95 computer in their training room, with a guest ID access, I could see every single file on that iSeries. And I had Full Control of those files. Ooops.

And let’s talk about telnet! Many legacy “green-screen” applications that connect to an iSeries are running via telnet, which means that usernames and passwords are passed to the iSeries in clear text.

Second, special authorities are not locked down. What initial program are users accessing (UPINPG)? If the response is NONE, then they can break through to the command line. How about user classes (UPUSCL)? Have you got people that are part of the programmers group (PGMR) or SECOFR, or SYSOPR? Regular users shouldn’t be in these classes either.
UPSPAU indicates what special authorities each user has. By default, a user should only have access to their printer queue jobs (*SPLCTL), not all objects (*ALLOBJ).

Last, but not least,are the users changing their passwords? I found two with UPPWCD last week… Are there users that are using their username as a password? UPPWON will tell you the facts.


Sep 24 2008   5:36PM GMT

FREE Tool - Changing Local Administratior Passwords On Your Domain



Posted by: Arian Eigen Heald
Security, Compliance, IT audit, Tools for Auditing and Security, Admins and Auditors, Tools & Tricks of the Trade

I just love VBS.

And I love the folks that share their tools, AND give us a nice interface AND allow us to push a report to a .csv file. So a BIG thank-you should go out to Jeffrey Hicks, who has his own site, anjd a helpful Blog.

He has a nifty free tool for changing the local Administrator password, PWDMan. This tool also reports on the password age. I’ve been looking for a tool like this to give to the admins I “visit” so that I don’t have to hear any more excuses about how hard it is to change that password periodically.

Jeffrey also has a whole page of VBS scripts and yes, Power Shell scripts, something I’m going to learn when I grow up.

I look for tools I can offer to help admins do their jobs, detect problems and provide easy ways to assess their own systems. I teach how to fish, and try to get buy-in so that the watchfulness happens all year long, not just during an audit.


Sep 23 2008   3:15PM GMT

Host vs. Network IDS



Posted by: Arian Eigen Heald
Security, Microsoft Windows, Security Devices, IT audit, Admins and Auditors, Tools & Tricks of the Trade

I’ve noticed a definite tendency for organizations to move to monitoring network traffic with their Intrusion Detection Systems. It’s a lot easier than trying to update a host IDS service/agent and keeps the increased CPU at the monitor, where it belongs. Also, host agents are limited by what the operating system is willing to log.

Windows, for instance, will give you hundreds of logging messages that actually have no useful information for an IT Admin or Auditor to review. The setup of their Event Log auditing mechanism is still klugy, outdated and difficult to interpret. (Micro$oft, are you listening?). I can’t say I get to wow about UNIX either, and FORGET anything like logging with Novell.

So, why bother? I still think that a host IDS has a place, because there are things it can watch for that you will only see on the server. For instance, if someone is doing brute-force against the administrator account. If someone has made Active Directory changes who should not be in there.

How would you tell if someone added themselves to the Server Operator group? (where I’d go to look around and maybe get my hands on a SAM database). If you’ve got an Event Log monitoring function, you could pick it up that way, but wouldn’t it be nice if the IDS would pick it up? If you just installed a host IDS on certain critical servers? There’s lots of options if you step out of the all-or-nothing approach.

Speaking of which, monitoring development and test servers really does have to be included. As much as we’d like to forget that they’re there, that’s the first place hackers look. As a penetration tester, I can attest to that, as well. Patch ‘em, monitor ‘em, they’re on YOUR network.