The sensors are looking for intruders attempting access from the outside. Consider state-of-the-art ID products such as ISS: they focus on who's coming in, who's pinging ports, who's trying to get through the TCP/IP stack. The program functions by looking at changes in activity logs.
That is a good start, but it is not enough.
Current ID technology is missing what is happening inside systems. It is pointless to protect a system against hackers on the outside, but be oblivious to internal changes, executed by employees, that result in dire security vulnerabilities. If you are looking to provide a total security monitoring solution, you must consistently monitor changes to the settings of highly configurable devices such as servers, routers, workstations and the systems that connect them.
Firewalls are only as good as the last vulnerability they protected you from. Hackers can get through. And when they don't, people are always downloading things, using instant messages, accessing Hotmail accounts that can carry viruses and worms. Virus scans get out of date very quickly.
Companies are beginning to focus on extending intrusion detection to include proactive configuration monitoring. Software applications are available that can scan configurations at all layers of the infrastructure, compare the settings to previous configurations, and report what has changed. Security professionals can then review this information and address potential vulnerabilities.
What intrusion detection misses
Usually, configuration-level holes happen inadvertently; an administrator or IT person will make a change to solve a problem and not realize that they have opened up the system to potential breaches. Here are five examples that occur frequently in the IT world.
1. A contractor who has Oracle database identification gives him or
herself a higher level of access to a database or changes a
schema (or operating system, server, application). Though the
configuration change impacts security, those kinds of changes will
largely go unnoticed by intrusion detection software.
2. A system administrator is troubleshooting a problem: mail does
not work. He tries everything to get the server back up.
Eventually, he pulls out the CD-ROM and reinstalls Exchange
Server. Now mail is working, but what just happened? First, he
blew away the service pack that had closed some known security
holes. Second, there was a lot of fine-tuning done by security
experts in the company to harden the server. After the re-install,
the server went right back to being vanilla (and vulnerable).
3. A Lotus Notes administrator goes in and makes a configuration
change to an access control list without realizing that now anyone
coming into that system with an anonymous level of access can
read information out of the database. Administrators are not
always security-savvy, because of the steep learning curve and
the crisis-solving nature of their jobs.
4. Employees often flout company policy by installing their own
software, unwittingly creating methods of access for hackers or
'downgrading' service packs for compatibility with the software
5. Disgruntled or terminated workers might wish to sabotage the
infrastructure. Given their inside information about your network,
these former employees can present a serious hazard.
Not only does intrusion detection software not pick up these types of changes, but also security teams inside companies are rarely apprised of them, creating vulnerabilities that can last days or weeks. Whether changes are inadvertent or happen purposefully, security professionals are often unaware they have taken place.
Focusing from the inside out
Focusing on intrusion detection from the standpoint of configuration settings offers a powerful, cost-effective means of hardening internal security. All of the major devices in an enterprise have hundreds or thousands of settings. Manually documenting such a vast amount of data is next to impossible without armies of IT auditors working round the clock.
Automated solutions can discover all such settings and present data in plain language reports. Some can automatically schedule reports that flag any changes that have taken place since the last report. IT professionals can use these reports to quickly discover potential vulnerabilities.
Some of the security-related items these reports can provide include: patch and service pack levels, services (such as SNMP) currently running or enabled, BIOS versions, passwords, workstations with access to which servers, and much more.
How configuration intrusion detection functions
Intrusion detection at the configuration level allows you to harden security on the inside and offset weaknesses on the perimeter.
The challenge in this approach is developing and enforcing policies that enable you to monitor how machines behave, which is usually a more effective approach than worrying about how people behave at their computers.
Millions of dollars are lost each year due to hacking, and one assumes much more goes unreported to avoid giving customers the impression that systems are unsafe. So justifying configuration intrusion detection is not difficult, but implementing it is.
Implementation begins with a high-level assessment of your computing environment and starting to pinpoint necessary generalities for secure operation. This might include good authentication, complex passwords, no unnecessary services, the latest patches, operating system updates, etc., enforced and continually monitored across all machines in the enterprise.
After this high-level policy definition is complete, you can begin looking at systems individually for compliance. This can be time-consuming when done manually - one server might have 10,000 different configurations - but gathering data down to the individual setting is necessary to build a bulletproof policy and system.
A 'cycle of control'
A big question arises when developing a configuration intrusion detection plan: how do you consistently test all those systems? This is where automation becomes essential. Automation enables IT staff to create a 'cycle of control.'
A cycle of control begins with an initial gathering of data, in this case, configuration settings, then establishing a reporting schedule in which systems are audited and documented, changes are flagged, and vulnerabilities are addressed. Such a cycle enables you to get your hands around your enterprise and tighten security; each update adds to your knowledge base and improves your system security.
A cycle of control catches innocent acts that can compromise a system, such as an employee opening an instant message that might be a backdoor. Things like that not only compromise that machine, but the entire infrastructure to which it is connected. One minor change affects everything.
Such cycles never end, but automation makes their implementation and maintenance extremely easy to manage. Knowledge changes, new programs and patches appear, user behavior changes, companies evolve, and new regulations are introduced. Keeping the focus on changes to the configuration settings over time is the surest way to monitor traffic in your enterprise.
Configuration intrusion detection enables you to monitor down to the file integrity level, where you look at permissions on files, whether or not they have been accessed, if data has changed, or if the file has been replaced. This is vital because in any system breach, one of these things will occur. Reliable methods can be written for managing data that go beyond just collecting, to testing the data to see if an intrusion has occurred. Being able to enforce and manage policies, detect changes, monitor file status and provide instant reports is at the heart of this new security focus.
In summary, configuration intrusion detection is a new way of looking at security that focuses on an infrastructure's many configuration settings tracked over time. Reports on such activity provide data that enable IT staff to quickly address any planned or unplanned changes that might open potential vulnerabilities. Given the time required to audit such settings manually, automated systems provide the greatest efficiency for setting and comparing of baseline configurations.
Andy Evans (firstname.lastname@example.org) is Ecora's security expert.