Sister CISA CISSP


June 10, 2008  12:56 AM

Identity Theft and Your Tax Returns



Posted by: Arian Eigen Heald
Identity theft, Security, TCM (Truly Clueless Management)

Thieves continue to get more and more creative with personal information. Computerworld reports that so far 155 medical students from the University of California at Irvine have experienced fraud from identity theft.

The criminals used their personal information to file fraudulent tax returns and then collect the tax refunds.

(Question: Medical students? I can’t think of a poorer group of people. My medical student niece has a great T-shirt with “Massive Debt” on the front.)

The original loss of information came from United Healthcare, the health provider for UCI students, where over 1,000 identities were stolen. UHC was unaware of the breach. The spokesperson seemed to think it was local to UCI – and nothing further bad was happening….Guess it was not happening to HER.

“Local and federal law-enforcement agencies have been called in to help with the investigation, and they have traced the source of the data breach to United Healthcare, the carrier for the school’s graduate student health-insurance program.”

The way this was discovered was by the students attempting to file tax returns. And what about those tax “rebates?” Gotten yours? Maybe not…..

June 3, 2008  3:01 PM

Eigen’s 2008 InfoSecurity “Rules of Thumb”



Posted by: Arian Eigen Heald
Compliance, Eigen's Rules of Thumb, IT audit, Security, Steps to an Easy Audit, Tools & Tricks of the Trade, Tools for Auditing and Security

Rule #1 – You can pay now, or you can pay later, but if you choose to pay later, you will pay MORE.

Rule #2 – You can outsource function, but you cannot outsource responsibility.

Rule #3 – A classic, shamelessly plagiarized: “Faster, Better, Cheaper. Pick TWO.”

Rule #4 – Make NICE with your auditors, no matter how dumb they are.

Rule # 5 – The volume of company executives screaming about the “cost” of information security is the direct inverse of how little money they’ve put into it in the past.

Rule # 6 – Don’t expect the best audit from the cheapest bidder. You get exactly what you pay for. Unless, of course, that’s exactly what you want. See Rule #1.

Rule # 7 – Compliance with regulations is a Gentleman’s C.

Rule # 8 – If you have “checkbox security,” you will have a box full of checks. Paid to other people.

Rule # 9 – The skills of your IT people directly relate to the training they receive. See Rule #1.

Rule #10 – No more acronyms! PCMCIA.


May 29, 2008  1:44 PM

Firewalls Part IV – Quis custodiet ipsos custodes?



Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, IT audit, Security, Security Devices, Steps to an Easy Audit, Tools & Tricks of the Trade

Who guards the guardians? Good IT governance mandates oversight of all IT functions. The firewall tends to be neglected, because it appears to be such a back-office function that only engineers or admins actually see and work on.

However, it is one of the most critical pieces of the IT infrastructure. As a result, the following steps ought to be put in place:

1.) Administrative access – Too many shops use one ID (“admin”) and password. Each person who accesses the firewall should have a unique ID and very strong password that should be changed more frequently than the standard policy. All administrative access to the firewall should be logged, and the logs stored separately for review.

Access should be reviewed at least annually to confirm no inappropriate users have been allowed access and signed off as reviewed by management.

2.) Changes - Too often firewall rules get changed “on the fly” or as the result of a phone call from a panicked person in the board room who can’t get to his demo site or custom application. Tough nookies. All changes to the firewall rulebase should go through change controls. Emergency change controls should go further up the management tree for approval, not just the network manager. This way it’s documented as to who asked for what, who did it, and who approved. It will make people think ahead and think twice before saying, “just open it up.”

Many firewalls can be enabled to send an email every time a rule is changed, added or deleted. This should be enabled immediately so that a management person (ideally, the ISO) is notified. This will also help eliminate admins giving themselves a convenient back door into the network.

A rulebase review should be conducted quarterly with management sign-off. It helps them be aware and start to understand what a firewall is really doing for the business.

3.) Monitoring the Logs – Firewall logs are a goldmine of information. Ideally you have a system for collecting the logs for analysis and storage with a third-party application. Someone should be looking at them every day. If the organization is smart, they have a product that can store, analyze and correlate logs from servers, routers, IDSes and firewalls. One stop shopping that everyone can review – including management. (Well, you can offer!) Make sure the designated person is logged or signs off on such reviews – then your audit will be a snap.


May 26, 2008  12:05 PM

It’s Not Your Mother’s Firewall Anymore – Part III



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

When all is said and done, a configuring a firewall comes down to creating a set of rules. Firewalls are bi-directional – they control traffic going out (outbound) to the Internet (or the DMZ) and they control traffic coming in (inbound) to the network or the DMZ. You are configuring for WHO, WHAT, WHERE and WHY.

WHO – in firewalls, everything is identified by IP address, whether it’s a single server or internal subnets. Firewalls have a category called “ANY,” which is a “red flag to the bull” for an IT Auditor. “ANY” is short for ANYBODY. Do you want anybody on the Internet to have access to something on your internal network? It’s sloppy work on the part of anyone who is configuring the firewall to use “ANY.” It means they didn’t take the time to specifically identify parties who need to access the network. The absolute only time the use of “ANY” is justified is when you have a web server you want customers to come to (think amazon.com, or ebay.com). And you can bet those folks don’t have their web servers inside with their corporate databases – those web servers are sitting alone in a DMZ.

“ANY” doesn’t work for outbound traffic either – you want to identify your internal subnets so that you can LOG who is going outbound and to WHERE. This is how Hannaford might have caught their hackers – the hackers were sending an outbound text file to somewhere in Europe from a store server – that could have set off an alarm. (Apologies to Hannaford; hindsight is, of course, 20-20 vision.)

WHAT – Applications on servers and other network devices respond by port number. There are 65,535 ports for UDP connections and 65,535 TCP connections. (I know this number by heart from the days when I did tech support for a firewall company.) Commonly, web servers use port 80/TCP. Theoretically, a server could be listening on all ports, but it will only listen on the ports that are running services on the server. If you are not running IIS or Apache, your server will not be listening on port 80 for connection requests.

So, here’s another place not to use ANY. Don’t allow hackers to bang away on every conceivable port. If you are only using FTP, disable web services, and allow traffic only to port 21/22. (Applications can use more than one port). Be specific about what services people can get to from the Internet.

Outbound, you may want to use the firewall to limit things like Peer-2-Peer networking, instant messaging, IRQ, video streaming, etc. There are also certain blocks of IP addresses you might want to bar access to, such as the entire netblock in Russia that hosts so many hacker applications.

WHERE – If you know WHAT, you also know WHERE. Be specific about what IP addresses can get to what on your DMZ and your internal network. If your email server in the DMZ is delivering to an internal email server, make it a rule from one IP address to the other. If clients want to connect or deliver data, request the specific IP addresses the client will be using. Will it be more work? Yes. But you will know exactly who came in, where they can go and what they are using.

Can hacker applications use standard ports? Absolutely. They often use port 80 since it is so commonly allowed in and out. Applications can be configured or coded to use non-standard ports. A good application firewall should catch some of this, and an IDS can catch the rest.

Finally WHY. I see too many configurations with rules labeled “test” or “demo,” with nothing in the comments section. Every rule should have a business owner AND a description. What are you testing? When does the test end? Who is testing what? If the cost of managing the firewall goes up because of a business application, this is your justification for getting extra funds from the business, AND a great opportunity to educate them.

Opening the firewall to let in “just the printer?” Is the printer connected to the rest of your network? Then you’ve just opened a hacker rest stop. Printers have hard drives and usually a default web server and FTP as well.

Next: Management Oversight of Firewalls


May 23, 2008  6:55 PM

It’s Not Your Mother’s Firewall Anymore – Part II



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

There are some amazing firewall appliances out there – application-level firewalls that monitor for web attacks, intrusion prevention features where the firewall can block an IP that is performing suspiciously, etc. These are complex machines and software that require training and daily monitoring. It’s definitely not a “set it and forget it” arrangement. Too many small businesses are treating it that way.

A firewall is only as good as where you put it and how you let traffic IN. I’ve seen organizations that put special applications behind their firewalls and left the rest of their network behind routers. Thank heaven there’s not enough bad people to find configurations like this. A firewall should be between your Internet router (usually managed by your Internet services provider) and the rest of your network. I’ve had business managers tell me a well-configured router is the same as a firewall. NO. No. No. Routers are meant to route traffic. It’s like calling a really good door with no lock a locked door.

Next, what traffic are you letting into your network? By default, NOTHING should come in. NADA. All ports should be closed. Knock on your door, rattle the knob, bang on it even, they should not get in. Some employees want to access their email, or their machines from their home network (that’s a WHOLE other article). OK, firewalls have this nifty feature called a segregated subnet (a DMZ). Put your spam-catcher and Web-accessible mail on a server in the DMZ. Put your FTP server where customers drop off files on your DMZ. Segregate the Domains if you are using Windows.

What about customers? Put the web server for them in the DMZ (NOT the database. NO. Just say NO. Tell the auditor to say NO).

Create what’s called an “extranet” for clients who need to access certain things on your network. Don’t allow them free access via a router to everything you have. You don’t know who has gotten into their network. Put a firewall between your network and the extranet.

Run a college or university, where it’s all about “open access?” Put your critical financial applications and records behind a firewall inside the school network. They can whoop it up out there, with some protection, but not where it really counts.

You may say, hey, everybody knows this stuff already, but I have seen organizations in the last year that have had exactly these issues. Scary, but true. Part III will be on firewall rules.


May 23, 2008  12:20 AM

It’s Not Your Mother’s Firewall Anymore – Part I



Posted by: Arian Eigen Heald
Compliance, Eigen's Rules of Thumb, IT audit, Networking, Security, Security Devices

In the northern part of Maine, (north of Portland, where I live) folks go about their business without locking their doors or even leaving their cars running while they go into the store. (When it’s -10 degrees, it’s good to have the car run a little more). This describes the fundamental trust the people there have in their community and their neighbors. If you drive by a sign on a driveway that advertises fruits or vegetables for sale, often there will be no person there to collect the money, just a basket with a “thank you” tag. During the winter, folks on the highway will pull over and run down the bank to help a car that has just slid off the road.

The bigger businesses do lock their doors, because they don’t know everyone who might come into their store, and don’t trust unknown people to care or pay for their merchandise.

Fifteen years ago, many businesses did not have a firewall between them and the Internet. You couldn’t pay for something online, or do business-to-business operations. The value of the information was lower, and there was a higher level of trust.

The other issue that came along was the limitation of IP4 addressing. NAT (Network Address Translation) allowed networks of any size to use non-internet routeable subnets as long as they were behind a firewall that had an outside (Internet-facing) legal IP address. (It’s why you don’t see addresses on the Internet for the 10.x.x.x, 172.16.x.x and 192.168.1.x).

Turns out that NAT and firewalls made perfect friends; behind a NAT enabled firewall, a huge network could exist and have all private IPs that the Internet cannot route to or see. The firewall acts as a gatekeeper and monitor, with an internal NIC (Network Interface card) that has an internal private address and an external NIC for Internet communications.

Today, I can ping a server in Russia on my desktop, and that server in Russia could ping me back, if I were not behind a firewall. My Northern neighbors, many of whom have a computer at home, can also ping that far away server. Our “neighbors” on the Internet are people we do not know, and many of them have the ability to “break in” without ever having to knock on our doors or even try the lock. There is zero trust on the Internet.

What does this have to do with IT Auditing, for heaven’s sake? Well, I see too many firewall configurations set up without any safeguards against the bad Internet neighbors. And I see too many auditors who say, “Oh, you have a firewall, that’s good.” They never ask to see the configuration and examine it carefully. (Security by checklist) Management seem to think that just having one is enough. They don’t send their folks to be trained on how to use it, or they outsource the management of their firewall and never inspect the rules or the logs.

Eigen’s Security Rules of Thumb #2: You can outsource function, but you cannot outsource responsibility.

I’ve seen outsourced firewalls that allowed every single IP address of the vendor access into the firewalled company’s network. It was easier for them to get to other network devices they managed, but there were no access controls as to who on their network could come in, or any logging, either. No one from the company looked at the configuration until I came along and said, “Why do they need that?”


May 15, 2008  5:54 PM

Steps to an Easy Audit (3) – Compensating Controls



Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, Database security, IT audit, PCI DSS, Security, SOX, Steps to an Easy Audit, Tools & Tricks of the Trade, Tools for Auditing and Security

These two magic words should be in every network manager and system engineer’s lexicon. It’s your get-out-of-jail (not necessarily free) card with an IT Auditor.

Every IT shop has an application, a device, a configuration that breaks good security rules and usually corporate policy, as well. Every one. Stuff gets bought and installed by another back office group that turns out to have a boatload of security holes. A legacy router in a critical location that can’t have its IOS upgraded. A bunch of wireless registers using WEP. A database that gives every user db_owner access. A firewall rule into the corporate network when everything should be going into a DMZ. (You don’t let anything into your network from the Internet, DO YOU??? Please say no.) Anyway, these issues will all come forward in an IT Audit. If they don’t, somebody should be looking into better IT Auditors.

So, if that has to happen, what controls can you put in place, that compensate for the risk of the vulnerability? Set up a firewall in front of that pesky application that Finance set up? Make that old router log connections AND remove telnet? Lock that firewall rule from IP address to IP address and require 2 factor authentication? All these things are good, but you need one more thing:

Documentation. Document the following:
1.) Your organization acknowledges the risk (identify the issue in the application, router, or firewall)
2.) Management acceptance of a break in policy (covers your assets)
3.) How those compensating controls specifically address the risk
4.) A plan and time line for removal of the vulnerability.

After this, you can hand it to the Auditor, and it will go in their report, but it can be considered reasonable.

Now, a large caveat here: Please resist the temptation to try and make a silk purse out of a sow’s ear. I’ve heard a boatload of excuses called “compensating controls” usually because someone higher up doesn’t want to spend the money. If they won’t listen to you, be honest with your IT Auditor. Management will often listen to an auditor because the report goes to the Board. Don’t take the heat for a bad management decision by backing it up with one of your own!

The second caveat is make sure you are actually doing the compensating control, whether it’s log monitoring, or firewalling, or whatever. Be prepared for the auditor wanting to review that control, just like all the others.

Some auditors might say I’m giving admins an easy out – but I don’t think so. It just means that auditors should look a little harder and know a little more about the systems they are auditing. If we all get smarter, we all get better.


May 13, 2008  4:38 PM

Steps to an Easy Audit (2) – Where’s the Beef, ah, I mean, Data?



Posted by: Arian Eigen Heald
Compliance, Database, Database security, IT audit, PCI DSS, Security, SQL Server, Steps to an Easy Audit

Remember that commercial (I’m dating myself, I know) where the little old lady lifts the top of the burger bun and says, “Where’s the beef?” All things considered, we have to ask the same sorts of questions about data.

Usually we’re looking at a nice fat application wrapped around data. It looks great, manipulates the data into all sorts of interesting reports, and adds a lot of value to the data. But ultimately, without the hamburger, the bun is useless.

Many IT Auditors and business managers tend to approach security by testing the application controls – synonymous with testing the hamburger by sampling the bun. The bun looks great, controls are all set, no one can see what they shouldn’t, right?

BIG Wrong. This is why the PCAOB is now requiring SOX auditors to examine the configuration of databases. I’m delighted to see that this is finally a requirement, because that’s where the beef is, and always will be. Inside the databases.

First question to ask: How does the application talk to the database?
Every connection to the database requires a username and password (even if the password is blank). EVERY CONNECTION. So, what is the application using? I’ve found IDs and passwords hard-coded inside applications (well, you won’t be changing the password on that one!), inside ASP code on the web server that serves up the application (hack the web server, get the database, too!) and sniffed it online using port 1433 and/or ODBC connections (IDs and passwords run in clear text). Another fun one is to examine a user’s workstation and find the ID in the ODBC configuration (pushed out via script) so that the user can use their Excel application or nice Access database code. (Of course, I’m talking Microsoft SQL server here, but these items are applicable across the variety of databases.)

Second question to ask: What rights does the application ID have?
It’s ironic that so many software companies cut expenses by enabling an application ID that has db-owner rights to the database. That way everything works, right? I’ve seen it dozens of times, and it’s always painful. Often there is no DBA at the company, or it was installed and the DBA is stuck with it. If it’s in production, removing that access will probably break the application, and no one wants that. So everyone crosses their fingers and toes that no one discovers this easy in. And, PS, hopefully there is a password to that ID.

Third question to ask: Is logging enabled to critical database tables?
Don’t believe anyone who says, “Logging can’t be turned on due to performance issues!” Sure, if you turn EVERYTHING on to be logged, the server will tank. But setting up triggers that send reports and logging access to half-a-dozen tables is not going to impact the server (unless, of course, the application is already a hog). It means more work for the DBA, but if she is skilled, it shouldn’t be a problem. A good DBA can do that in his sleep.

This way you can watch who is getting to the beef. Why does the application ID matter so much? Because if I have that ID and password, I don’t need that application to get into the database. The application is just a pretty face – I can connect via Excel, Access, or any other database-connecting application as long as I have a username and password. Just to see what I can get. And if that application ID has dbowner access, or even better, sysadmin access, I can get everything in the database.

The application may have good controls, but outside the application, or using MY application, those controls won’t exist. Beef, lots of it, sans bun. In short, hacker hamburger.

So, OK, how does this make a good audit, Eigen, you ask? Sounds like a pain in the neck, right? Two magic words for you: compensating controls.


May 8, 2008  3:21 PM

Steps to an Easy Audit: Standardizing Patch Management



Posted by: Arian Eigen Heald
Compliance, IT audit, Security, Steps to an Easy Audit, Tools for Auditing and Security

Many of my clients ask me what is the best way to deal with applications and operating systems that need to be patched frequently (like Microsoft’s monthly “Patch Tuesday”). Industry best practices have emerged in some simple steps that can work in almost any size organization:

1. Create a Patch Management Policy
Policies come from the top down and demonstrate that the executive level is invested in managing and securing the enterprise. Policies dictate the scope of standards (“Once a month, we will review patches and document risk, etc, etc”) and procedures (“the patches will be tested on server A, deployed on production servers C,D,E…”) to deploy the patches. This Policy should be part of your overall Vulnerability Management. It’s part of managing risk.

2. Identify What Needs to Be Patched
Don’t just think Microsoft, or even just think servers. Every device on your network, at some point or another will need to be updated. Some devices may require multiple types of updates, such as a server that holds a database; both need to be patched. You need to know your entire inventory, and categorize those devices in terms of risk, so that you can prioritize patching. Some devices, such as your workstations, will need to have software patched, such as Microsoft Office. It will be worth your while to have a complete software and hardware inventory. Think of the SQL slammer worm: it paralyzed networks not only because of SQL Server, but because of all the default installations of MSDE (Microsoft Desktop Database Edition) on workstations.

3. Classify and Rank
Different devices on your network may have different levels of risk, so that patching them takes higher priority than say, patching a printer (yes, these must be updated, too!). Take the time to assess the devices according to their risk levels so that you know what must be patched first.

Different patches have different levels of risk. Those that Microsoft, for example, identifies as “critical,” should always be assessed and tested for deployment first. All patches should be reviewed for criticality and ranked. That allows testing and deployment to proceed efficiently. Lower priority patches can be deployed on a more moderate timeline.

4. Test, Test, Test
It certainly is true that Microsoft, in particular, has vastly improved its process for creating solid software updates that don’t, generally, break things. However, good process requires that you not make changes on a production system without ensuring that the patch will not break some critical procedure. Use your development environment as a test bed, or even your less critical production servers to rollout the patches to. You’ll be glad you did.

5. Document, Document, Document
What got patched when? How will you remember the reason you didn’t patch a particular server in six months? Develop a documentation system, or better yet, use your Help Desk system to document who, what, when and why. You can track compliance very effectively with those reports and not an extra cent.

6. Trust, but Verify
On more than one audit, I have discovered that the great piece of software the client set up to patch everything stopped working, or didn’t patch certain other systems. Once a quarter, run a check using MBSA (Microsoft Baseline Security Analyzer, a FREE tool from Microsoft) for Microsoft products, at the very least. It will also give you a good baseline on the security of those servers, and a better night’s sleep!


May 5, 2008  8:52 PM

Five Myths About Compliance



Posted by: Arian Eigen Heald
Compliance, Data Breaches, Security, 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.


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: