Sister CISA CISSP:

Security Devices

Sep 23 2008   3:15PM GMT

Host vs. Network IDS



Posted by: Arian Eigen Heald
Security, Admins and Auditors, IT audit, Security Devices, Microsoft Windows, 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.

Aug 25 2008   6:33PM GMT

European Hotel Chain Has Their Customer Data For the Past Year Accessed



Posted by: Arian Eigen Heald
Security, Database security, Identity theft, Security Devices, Database, Data Breaches

Visited Europe in the last year and used a Best Western Hotel? Your credit card, expiration date, the company that employs you, your name, address and future bookings may be in the possession of a Russian Mafia website. An enterprising Scottish newspaper, the Sunday Herald, noticed on Thursday night that an Indian hacker offered to sell access to Best Western and notified Best Western about the breach. Although Best Western closed the hole on Friday, the horse is out of the barn.

Eight million people stayed at 1,312 locations from 2007. Is this “Identity Theft?” It’s a darned nice start. Only the Social Security number is missing. Certainly the names, addresses, business information, details of employment, credit card numbers and expiration dates could be used for synthetic identity theft.

According to the Herald:

“The Sunday Herald understands that a hacker from India - new to the world of cyber-crime - succeeded in bypassing the system’s security software and placing a Trojan virus on one of the Best Western Hotel machines used for reservations. The next time a member of staff logged in, her username and password were collected and stored.”

One of the first things I learned doing penetration testing was that you don’t have to have some fancy piece of coding to break in. It can be the simplest thing - finding a set of keys in someone’s desk - that gets you into the server room. In fact, it usually IS the simplest thing. Their web site may have great security, but that was easily bypassed by a user login.

Best Western evidently had not noticed all the activity that account was generating - sucking all the data out of their databases. Which takes us back to auditing databases, doesn’t it?

Best Western’s response? Tim Wade, head of marketing for Best Western GB, said it was “unlikely” that whoever was responsible got hold of the details of “every booking at every hotel” in Europe because of the way their system worked. Has anyone mentioned to Best Western that letting a marketing guy handle communications for a data breach is not always the best choice? “Unlikely” is not a word that I find comforting. What are the facts? Why don’t they know exactly how much was taken? Because they probably don’t have any security logging in the right place. It’s why they didn’t notice the breach in the first place.

Let’s hope they didn’t get all the way into the American side of the company. Or maybe they have. How would we know?


Aug 5 2008   4:46PM GMT

ATMs - Automated Theft Machines



Posted by: Arian Eigen Heald
Security, Hardware & InfoSec, Identity theft, Security Devices, Eigen's Rules of Thum

It’s absolutely fascinating (in a nerve-wracking sort of way) to read about how many different ways there are to use ATMs to capture (and steal) accounts and PIN numbers. From there, it takes very little time to create a fraudulent card and spend what you can before the bank catches up. It’s a triumph of hardware over software. Thieves simply work around the software controls to capture the information they want.

For example, the concept of “skimming.” Typically, thieves attach a device to the outside of the ATM that records the magnetic stripe information as you insert it. They also need a camera of some sort to capture the PIN as you type it in. For a classic example, with pictures you can see that the card skimmer fits in front of the regular card slot. For PINs, the clever placement of a pinhole wireless camera makes it all way too easy.

Thieves tend to get endlessly creative: One fellow bought his own ATM equipment and kept moving it around from place to place in order to capture information. He was good enough at it to collect at least $4 million, and is still at large.

More losses come from retail ATMs (those found in supermarkets, convenience stores, gas stations, or other non-banking environments) where there are less stringent controls and only casual observers. In May of this year, the ATM at one gas station was rigged, with at least 80 victims. When he was finally apprended, he had stolen more than $185,000. Ouch.

There are about 360,000 ATMs in the United States, according to Bankrate.com Only half of them are at a bank.

The ATM designers are moving to internal card readers and other techniques to eliminate external skimming devices, but when you can buy your own ATM and move it around, controls on sales of such machines must be tightened.

Rule of Thumb: If I don’t go to the bank for gas, I won’t go to the gas station for money.


May 29 2008   1:44PM GMT

Firewalls Part IV - Quis custodiet ipsos custodes?



Posted by: Arian Eigen Heald
Security, Security Devices, Admins and Auditors, Compliance, IT audit, 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:05PM GMT

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



Posted by: Arian Eigen Heald
Security, Admins and Auditors, Compliance, IT audit, 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   12:20AM GMT

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



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

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?”