Security Monitoring

Choosing Components Within Monitoring Targets

Once you’ve selected the IT systems that need monitoring, you must analyze the component makeup of these targeted systems to select event feeds (which we’ll cover in depth in the next chapter). To determine the component makeup, you should break down each system into its core elements, including the databases, web servers, application servers, and various hosts upon which these solutions run. Depending on the components in your solution, you might collect syslog messages from Unix/Linux servers (and from Windows servers, if they’re configured with add-on packages), monitor the AUD$ table on Oracle databases, analyze the access_log from Apache web servers, and so on.

Your system will also depend on complementary services such as authentication servers (LDAP, Active Directory, NIS+, etc.), caching servers, network attached storage (NAS), and so forth. Analyzing your policies will help you determine which complementary services you should monitor to complete your targeted monitoring plan. You should even consider network devices that serve access to your system; tools such as NetFlow and syslog can help trace device configuration changes, among many other things.

Example: ERP System

To illustrate the process of selecting components for monitoring, consider an installation of SAP R/3, which by definition is a three-tier architecture composed of presentation servers, application servers, and a database server. In a typical installation, the presentation and application servers would be load-balanced across two or more Linux servers. The database server is often a single Oracle database instance, load-balanced transparently using Oracle’s native functionality to straddle instances across physical servers.

Assuming a total of five servers (two presentation servers, two application servers, and one database server), the following logs (also illustrated in Figure 4-7) provide rich event sources for security monitoring:

• Host syslog from all five servers

• NIDS logs from data center gateways

• Audit files from each application server

• Oracle audit logs from the Oracle 10g database, including specialized audit logging for master record tables

• Accounting audit trails (stored in database tables)^[39]

• NetFlow logs into/from the data center

Figure 4-7. Where to collect logs for SAP R/3 monitoring

Gathering Component Details for Event Feeds

In Chapter 5, we’ll detail how to begin selecting event sources from our various components into security monitoring systems. Now that we’ve selected our components to monitor, we have one final step to complete before we can begin to collect these events for analysis. Recall that in Chapter 3 we detailed the importance of documented network topology to provide context for security events. We’ll put some of that knowledge into practice here, documenting the specific host and network information of the components in our targeted system.

Server IP addresses and hostnames

We must enumerate the IP addresses and names of each server in our solution. This will allow us to determine the valid traffic patterns between servers and prioritize alerts containing the hostnames and IP addresses of target systems.

“Generic” user IDs

If we were to list the processes running on the servers, we would find the application components running with a generic user ID. This generic account should be “registered” to the application, and should run with very limited privileges. To monitor components effectively, we need to enumerate these user IDs. Once we build this list, we will be able to attribute behavior to registered user IDs, making it easy to see that the behavior is benign. For example, it’s common to observe a large number of simultaneous connections in the database originating from the app server. We can safely ignore this event once it’s clear that it’s the “WebSphere” user connecting to Oracle via WebSphere’s built-in connection pooling.

Generic accounts are used for running services, such as the “nobody” or “http” user that runs the Apache web server, or the “oracle” user which executes the database processes on the server. Generic accounts are also used to connect to other resources, such as the “connect as” user ID specified when connecting to the database.

Administrator user IDs

Legitimate system administration accounts must also be enumerated for similar reasons. This allows you to attribute administrative activity that may show up as security events. For example, if correlated security events show a user ID connecting to the database server and restarting the database listener, we can match the user ID with the “registered” database administrator for that database, documenting that it’s in the scope of his responsibilities.

Database details

To effectively monitor the database, we must detail the database setup, enumerating the following information:

• Schemas used

• Accounts used (often the user ID for application access is different from and more limited than the schema owner account), along with account details such as the roles granted to the accounts

• Sensitive objects (tables, views, procedures)

• How activity is logged (normally logged to AUD$)

• Access controls in place (privileges granted to enumerated accounts against database objects)

Access controls

Lastly, we must enumerate the access controls active in the environment. Access control systems such as firewalls and host IPS logs that can be useful for targeted monitoring. For example, if a firewall is logging DENY messages for users trying to directly access the database from outside the data center, analysis of those logs can prove useful in monitoring and defending the database. Similarly, security software, such as Tripwire and PortSentry, log messages that we can analyze to beef up our targeted monitoring capability.

---

^[39] Dr. Peter J. Best. “Audit Trail Analysis for Fraud Control with SAP R/3.” CACS 2005 ISACA Oceania Conference.