I'm still chasing down rogue wireless LAN access points (AP), but this week I've got bigger issues to deal with as my company integrates recent acquisitions into the IT infrastructure.
Before leaving the WLAN security saga, however, I should share one caveat I discovered: If you're using Net-Stumbler or a similar program to try to detect illegal wireless APs in your organisation, understand that the MAC address you detect with these products is the radio address, not the LAN MAC address. Without the latter, it's difficult to trace rogue APs back to their source.
Merger Insecurities
My company grew from a few hundred employees to several thousand in a very short time -- mainly through a series of mergers and acquisitions. We then had to quickly integrate these companies' IT infrastructures into ours.
Issues such as differences in the configurations and software have been a cause of great frustration during the integration process. It's scary when, due to a business decision, one is forced to configure a trusted relationship with an unknown entity.
Every time we absorb another company's infrastructure, methodologies and culture, we have to make a decision: Is it better to change its systems and ways of doing things to match ours, or to administer and manage its infrastructure per the company's established procedures?
That decision, in turn, affects the way the security infrastructure operates. For example, we have our intrusion-detection systems (IDS) tuned to monitor our existing network traffic based on a painstaking process of monitoring traffic and attributing suspicious activity to a valid incident or to normal network/application behaviour. Tuning an IDS is a complicated and time-consuming process in itself. And just when we think we've got our IDS tuned to a state of quiescence, we go and set up a new circuit between our company and another acquisition.
After we establish a relationship between our network and that of the new company, we send an IDS sensor out to each new location. Then we end up starting almost from the beginning, figuring out what traffic is legitimate, marking it to prevent false positives, tracking down a new group of engineers and administrators to find out what's what, and tuning the IDS sensors appropriately.
With all this going on, I'm uncomfortable trusting our IDS to detect every successful hack. We have continuing challenges with false positives, false negatives, event correlation, incident response, IDS tuning and proper placement of IDS sensors in the new infrastructure. And with new application-level attacks on the rise, I'm not sure we would detect an attack that penetrates into our critical infrastructure.
Backup Measures
Until I feel more confident, we will augment our IDS deployment with Portland, Ore.-based Tripwire's integrity-checking software. Tripwire is our option of last resort. If the IDS sensors fail to detect a compromise, Tripwire will pick up on it.
We're still thinking of deploying host-based intrusion-detection sensors on each of our critical servers, but in testing, the product we used required the Solaris Basic Security Module, which in turn shot our processor utilisation to critical levels. I'm sure that it's been refined, and now there are other host-based IDS alternatives that we can consider when we have more time for an evaluation. But for now, we'll have to make do.
To add insult to injury, we've even had problems with the Tripwire software after installing it on several of our production systems. We have the software set to conduct a full integrity check from 2:00 a.m. to 3:00 a.m. each morning. I also have Tripwire configured to conduct a special check every 30 minutes on about 10 critical files where a change usually indicates a security breach. In doing so, I'm gambling that if someone compromises one of our systems, one of those 10 files (such as /etc/passwd and etc/default login/) will change.
Here's the problem: There are three variables associated with Unix file attributes that are important for both forensic activities and integrity-checking programs such as Tripwire: Atime, Mtime and Ctime, which tell when a file was last read, when its status last changed and when it was last modified, respectively. Tripwire uses these attributes to detect file tampering. By default, Tripwire conducts a series of file status checks and verifies the returned values against the initial snapshot taken during the database initialisation phase.
The problem we ran into recently has to do with enterprise backups. By default, our backup software changes the Atime attribute as it backs up each file on the server. This is an issue because it's important that the file-access time is accurate at the time of backup. To remedy this, our backup software resets Atime on each backed-up file to what it was prior to the backup. But this changes the Ctime attribute, triggering a Tripwire alarm.
Our only remedy was to edit all of our policy files to remove the checking of the Ctime attribute on the files scheduled for backup. It's a bit of a kludge, but we made the changes, and our integrity checks are now running clean and quietly. It's a lot easier to tune Tripwire than it is an IDS. Then again, I'm not exactly comparing apples to apples.
But while these mergers and acquisitions have created security hassles, I expect it could have been worse: They could have been using WLANs.