Whether you have payroll information, healthcare records, product designs, or financial histories, you name it, and your company network's got it: data that must be secured. To protect your electronic assets, your company has (or at least should have) written security policies. Depending on your company's industry, some of these policies might have been written to ensure compliance with government regulations, such as the Health Insurance Portability & Accountability Act (HIPAA), the Sarbanes-Oxley Act, the Gramm-Leach-Bliley Act (GLBA) or the United Kingdom's Data Protection Act.

In any case, as a network administrator, you probably participated in translating these security policies into the system-wide rules that enact these policies. At this point then, you sit comfortably with policies in hand and rules in action-right?

Well, "comfortably" might be overstating things just a tad. Sitting comfortably requires a level of confidence in your policies and your company's adherence to these policies that few administrators have reached. To reach this level of confidence, you need to know, at the very least, what's going on in all corners of your network at all times. This point begs the question: do you know what's going on in your network?

When employees tread in network places they have no right to tread, how soon do you know about it? Do you know with certainty that every event-every change in access rights, every failed or successful login, every server abend-in every system is consistently logged? Are you confident that these events are securely transferred to storage? When something goes wrong-for example, an unauthorized user gains Admin rights-can you immediately respond to correct this out-of-policy event? In such a case, can you easily analyze logged data to determine where your company-wide policies failed? Can you easily produce reports to prove that your company adheres to government regulations?

When you can answer "yes" to these and other similar questions, then you can relax. That is, when you know that your policies are effective, that they're being adhered to, and that you can prove it, then you've earned the right to feel warm and fuzzy about your network's state of security affairs.

	Figure 1 Click for large view

Unfortunately, you probably felt a pang of doubt while muttering a quiet "yes" to some of these questions and possibly answered "maybe," "sort of" or even "no" to other questions. To answer these and other similar questions with an unequivocal "yes," you know what you need: You need an auditing solution. That is, you need a solution that enables you to easily collect, analyze and respond to recorded data of all of the events on every network system. Such a solution would enable you to determine how well your company adheres to its security policies and to prove, if necessary, that your company complies with government regulations.

Audit Features - You need it, you got it
Novell knows that you need such a solution because you and other customers have said so and because Novell too needs such a solution. To address your needs as well as its own, Novell introduces Novell Audit, a comprehensive and secure logging and auditing solution.

Available in beta since March and officially released in July, Novell Audit is the result of Novell's years of experience developing some of the most secure enterprise software solutions in the industry. Like its recent predecessor, that is, Novell Advanced Auditing Service (NAAS), Novell Audit enables you to log eDirectory and NetWare file system events to a central location and to provide realtime e-mail notifications of various events. (For a complete feature comparison list, see Comparing Features.)

However, Novell Audit is built on an entirely new code set. Hence not surprisingly, Novell Audit provides capabilities above and beyond the capabilities provided by former Novell auditing solutions. More specifically, Novell Audit offers you the ability to perform the following functions:

• Securely log events to a central location from eventually all Novell applications and potentially any third-party application. (See Applications-Prepare to Log.)
• Ensure the integrity of logged data. (See Audit Security-Snuggle Up.) Choose the data store to which you would like to record your logged data. (See Logging-Central Information.)
• Choose the data store to which you would like to record your logged data. (See Logging-Central Information.)
• Mine your logged data by generating prewritten or custom reports. (See Reporting-The Scoop on Tools.)
• Select the method by which you would prefer to be notified of various events and by which you choose to notify others. (See Notification-the Real-Time Story.)
• Provide various real-time views of specific event occurrences for yourself and others. (See Monitoring-Broadcast News.)

In other words, Novell Audit tracks, records and reports on all network events and, equally important, does so securely. Hence, with Novell Audit, you really can sit comfortably, knowing that your policies are effective and that your system-wide rules are in action.

Audit Architecture - Just the Gist
Novell Audit is a client-server solution with three primary components:

1. Instrumented Logging Applications
2. Platform Agent
3. Secure Logging Server

In basic terms and as Figure 1 shows, these components work together like this: the Platform Agent collects event data from the Logging Applications running on the same server or workstation. (See Figure 1.) In nonrepudiative mode, the Platform Agent (or Logging Application) then digitally signs each event before transmitting it over a mutually authenticated and encrypted connection to the Secure Logging Server. The Platform Agent and Secure Logging Server establish this secure communication channel using Transport Layer Security (TLS).

The Secure Logging Server writes the data to a persistent data store, such as MySQL, Oracle or a flat file. Simultaneously, the Secure Logging Server evaluates the data to determine if any alerts are required or if any monitored values have changed.

Audit Security - Snuggle up
Novell Audit components work together to protect the integrity of your logged data through a process Novell refers to as the signing and chaining of events.

Signing is the process whereby the Platform Agent (or, in some cases, the Logging Application) affixes a digital signature to each event it receives before forwarding the event data to the Secure Logging Server. This signature enables the Secure Logging Server to verify the integrity of the event data it receives and thus ensure that the event data has not been tampered with. Chaining is the process whereby the Platform Agent (or, in some cases, Logging Application) includes with each new event from a given Logging Application) a hash of the previous event (from the same Logging Application). The hash (along with the data from the next event) is also signed. This hash enables the Secure Logging Server to verify that all events are in the data store and that none has been removed.

Through signing and chaining, Novell Audit protects your data against various types of security breaches, such as rogue administrators attempting to cover their tracks.

Novell Audit helps you achieve nonrepudiation by signing and chaining events. In the context of auditing, non-repudiation means that you log and record event data in such a way that you can prove that events have not been tampered with and that your record is complete. "Nonrepudiation is more than just a word to impress your friends with at parties," says Jeff Allen, Novell product manager. "Our customers are looking for the ability to log in such a way that the data they collect will stand up in a court of law. That's what nonrepudiation gets you."

The vice president and chief technology officer of Novacoast, Inc., Adam Gray, supports Allen's claim that nonrepudiation is what Novell customers hope to achieve with a logging and auditing solution.

The California-based Novacoast provides professional IT services for clients from a wide range of industries. In dealing with these clients, Novacoast deals with "the worst of the worst security cases," says Gray. "In the past, when a security incident has occurred, all we've been able to do is say, 'Well, it looks like this source, but you don't have a proper log, so there's nothing you can do.' All people could do was recover."

Novell Audit has changed everything. Novacoast has been running the Novell Audit beta since April. According to Gray, Novell Audit meets one of the main criteria Novacoast applied in its search for an ideal logging and auditing solution: the ability to properly record and store data. (For more information on Novacoast and its experience with the Novell Audit beta, see Novacoast Confirms: Novell Audit is Solid, Stable and Ready to Go.)

By "properly," Novacoast means a solution that securely records and stores data to yield legally admissible logs, a criterion Novell Audit meets. Of course, Novell Audit is only as secure as your security perimeter: you also must take steps to adequately secure the physical devices you are auditing.

Applications - Prepare to Log
Gray is also happy to confirm what Novell claims: You can use potentially any application with Novell Audit. To do so, you use the C and Java application programming interfaces (APIs) described in the Novell Audit Software Developer Kit (SDK) to instrument the application to log to Novell Audit. The Novell Audit SDK has been available and supported at http://developer.novell.com/ndk/naudit.htm since April.

Using these APIs, Novacoast has in fact already integrated several third-party applications in its test environment, a job that Gray says takes only "a couple of days." (For more information, see Novacoast Confirms at the top of this page.)

Thus far, Novell has instrumented the following systems to log events to Novell Audit:

• eDirectory 8.5x, 8.6x, and 8.7x
• Novell Directory Services (NDS) 6.x, 7.x, and 8.x
• NetWare 5.1, 6.0 and 6.5, including the traditional file system and Novell Storage Services (NSS)
• Novell iChain 2.2 with Support Pack 1
• Novell NetMail 3.5 (due to be released this fall)

This list, however, represents only the tip of the Novell Audit potential. In fact, even as we speak, Novell engineers are in the process of instrumenting the next version of Novell BorderManager to log events to Novell Audit. In addition, you can watch for the following systems to do the same:

• Novell DirXML
• Novell SecureLogin

This list of available and forthcoming logging applications is not exhaustive and is growing rapidly. Eventually, Novell expects to instrument all of its applications to log events to Novell Audit. Moreover, you or third-party developers can instrument any third-party application to do the same (just as Novacoast already has).

Getting Started with Starter Pack
Future releases of Novell products will include the Novell Audit Starter Pack, beginning this summer with NetWare 6.5. As you can guess by the name, the Novell Audit Starter Pack entitles you to some but not all of the capabilities provided by the complete Novell Audit solution. Furthermore, the Novell Audit Starter Pack includes evaluation versions of all of the features in Novell Audit.

Among other capabilities, Novell Audit Starter Pack enables you to centrally log events from NetWare 6.5 and eDirectory 8.7. Don't assume that Novell Audit Starter Pack is lacking on the feature front. In fact, it offers all of and far more than the auditing features Novell previously provided in NetWare 6.0. (For more information, see Comparing Features.)

Novacoast provides IT professional services for clients from a wide range of industries, including education, financial, government, entertainment and manufacturing industries. To fulfill its mission of becoming a stakeholder in its clients' success, Novacoast makes a practice of researching and implementing only the best networking solutions. Not surprisingly, Novacoast lays claim to an impressive list of clients, which includes the University of California in Los Angeles (UCLA), Union Bank of California, City of Los Angeles, Academy of Motion Pictures and RedBull.

To best serve the network security needs of its clients, Novacoast was interested understandably in finding an auditing solution that would meet the seemingly stringent requirements: to log and record data securely so that logged data would be admissible in a court of law and to do so within the budget of a typical IT department. Unfortunately, what Novacoast discovered was that most auditing solutions produce logs that are legally inadmissible, and the few that manage to do so are prohibitively expensive.

By signing and chaining events at a reasonable cost, Novell Audit meets the Novacoast criteria. "If you rip something out of [an Novell Audit log]," says Adam Gray, Novacoast vice president and chief technology officer, "you're going to know about it." Novell Audit maintains the "validity of the log," says Gray, and "from a legal perspective," that's all that matters. "The court doesn't care if anyone can read [the log]," Gray explains, the court only "cares if [the log] has been changed."

Gray reports that the Novell Audit installation process went smoothly. "Everything worked out of the box," says Gray, adding that it took approximately only 15 minutes "to get this thing built." Novacoast runs Novell Audit on a mix of Linux, Solaris and NetWare platforms. "We didn't test it on Windows," Gray points out, "because most organizations that are serious about security are not dealing with Windows other than on the desktop."

Novacoast runs the Secure Logging Server on "borderline low-end hardware," onto which several servers report between 50,000 and 60,000 events daily. The server can handle it, says Gray. Novell Product Manager Jeff Allen is not at all surprised that the server can handle this load. Allen explains that with Novell Audit, Logging Applications can report a few thousand events per second without impacting the performance of these applications. Gray implies something similar when he says that Novacoast will use a "nice one-use server," which "will be more than sufficient," for the environments where they plan to implement Novell Audit.

Novacoast has already used and is impressed by the Novell Audit SDK. Using the SDK, Novacoast has integrated with relative ease several third-party applications, including an intrusion detection system, which gets about 2,000 attacks per hour. The drivers took only "a couple of days" to develop, says Gray. "We feel confident that we could integrate other thirdparty products at a rapid pace in any environment that we go to."

In their testing thus far, says Gray, Novell Audit has been "flawless." The product is "solid, stable and ready to go."

The specific events a Logging Application logs to Novell Audit depends on two variables:

• The events you or a developer enable an application to log
• The events you configure the application to log

Novell plans to enable its Logging Applications to log all events-not just warnings or errors but also positive events, such as successful logins and the successful writing of a file. Traditionally, event logging took a significant toll on performance, so auditing solutions logged only negative events. In contrast, Novell Audit has been optimized to allow applications to log both positive and negative events without a significant performance decrease. Novell encourages you and your developers to take advantage of positive logging.

Novell Audit extends the eDirectory schema and includes Novell iManager 2.0 plug-ins so you can configure and otherwise manage Novell Audit components, including Logging Applications, using iManager. (Novell iManager 2.0 is a Web-based application that you use to manage, maintain and monitor Novell eDirectory through wired and wireless devices.)

For example, using iManager, you mark in eDirectory the events you want a Logging Application to log to Novell Audit. More specifically, from the Novell Audit tab in the NCP Server object associated with your Logging Application, you select the Event menu. From this menu, which lists all the events that this application can log, you mark the events that you want logged. Thereafter, the Logging Application reports these marked events to the Platform Agent.

Platform Agent-Uninterrupted Logging
On every server and workstation running one or more Logging Applications, you install a Platform Agent. (See Figure 1.) A system on which you install a Platform Agent is called an Instrumented System in an Novell Audit context. At this point, you can install the Platform Agent on any server or workstation running one of the following operating systems:

• NetWare 4.2 and higher
• Microsoft Windows NT, Windows 2000 and Windows XP
• Sun Solaris 8 and 9
• Red Hat Linux 7.3, 8 and 9
• Red Hat EL Advanced Server
• SuSE ES 8.0
• Linux for IBM S/390 (zSeries)

The Platform Agent is a shared library that the Logging Applications running on the Instrumented System call when they want to report an event. The Platform Agent collects this logged data from Logging Applications and forwards the data to the Secure Logging Server.

With Novell Audit, you can be sure that all events that you have configured a Logging Application to log to Novell Audit will be logged-without question. Even when an Instrumented System is temporarily unable to communicate with the Secure Logging Server, the Platform Agent nevertheless collects and records the events that the Logging Applications on this Instrumented System have been configured to log.

If the Instrumented System loses its connection to the Secure Logging Server, the Platform Agent immediately sends events to its Logging Cache Module. The Logging Cache Module writes these events to a secure Disconnected Mode Cache file. The Logging Cache Module maintains a Disconnected Mode Cache file on disk for each Logging Application.

When the connection to the Secure Logging Server is restored, the Platform Agent Logging Cache Module transmits the Disconnected Mode Cache files for each Logging Application to the Secure Logging Server. Similarly, if a Platform Agent receives a high volume of events that would clog the wire, it will use the offline cache to buffer the events until the traffic lightens.

Secure Logging Server-Fundamental Facts
The Secure Logging Server manages the flow of information to and from the auditing system. (See Figure 1.) More specifically, the Secure Logging Server performs the following services:

• Processes events that Platform Agents collect and forward from Logging Apps
• Logs these events to storage
• Notifies you and others by various means when certain events occur, based on criteria you specify
• Sends values to monitoring applications

In this release of Novell Audit, you can install the Secure Logging Server on servers running any of the same operating systems the Platform Agent supports. (See Platform Agent-Uninterrupted Logging.) The Secure Logging Server is represented in eDirectory by the Logging Server object, which you can choose to create automatically during installation. Because the Logging Server object is unique to Novell Audit, this object does not replace the NCP Server object. Instead, each Logging Server object is associated with an NCP Server object. The Logging Server object stores the host name of the NCP Server object with which it is associated as well as all of the other Secure Logging Server properties and attributes.

Logging-Central Information
When Platform Agents forward logged data from Instrumented Systems to the Secure Logging Server, the logging server's Event Manager receives the data. (See Figure 1.) The Event Manager forwards logged data from Instrumented Systems (with valid Logging Application Certificates) directly and immediately to the Logging, Notification and Monitoring services.

The Logging Service records the data to any data store for which Novell Audit has a driver. Currently, Novell Audit includes drivers for the following types of data stores:

• MySQL database
• Oracle database
• Flat file
• Syslog

Additionally, Novell Audit supports several notification drivers. (For more information, see Notification-The Real-Time Story.) Further, the Novell Audit SDK includes C and Java APIs that enable you or third-party developers to extend this model by creating other custom drivers.

To configure a driver, you create eDirectory Channel objects in iManager. Channel objects represent an instantiation of a driver with specific configuration values. For example, MySQL Channel objects include the IP address or host name of the MySQL database server; a username and password to connect to this server; and the database, table names and fields for SQL table create and expiration commands.

For each driver you plan to use, you create one or more Channel objects. Why would you want to create more than one Channel object for any particular driver? Because doing so enables you to set up different configurations for different functions or events. For example, you can configure one MySQL Channel object to function as the default log channel through which all events are recorded. You can then configure another MySQL channel to act as the recipient of filtered events for a particular Logging Application. This can be useful if you have an administrator who is responsible for this application and needs access to the log but should not have access to events generated by other applications.

Once you have created one or more Channel objects, you can configure the Secure Logging Server to log events to the data store of your choice. (See Figure 1.)

Think about this system for a minute: The Logging Service records all events from potentially all of your systems (which are located here, there and everywhere) to a single location and using a common data structure. This means that when you need to check things out, you can-easily. You can generate reports from a central log, and these reports will enable you to analyze the goings on not in one system but in any and all of your network systems.

Reporting-The Scoop on Tools
Novell Audit provides three different tools that enable you to generate meaningful, useful reports that, in turn, enable you to analyze network events:

• LETrans
• Novell iManager plug-ins for Novell Audit
• Novell Audit Report

LETrans is a command-line log event translation tool that enables you to perform queries against and translate raw logs into human-readable logs. This does not mean all logs need translation in order to be read. You can configure the file and syslog drivers to automatically create human-readable logs. Generally, you use the raw log option when you want to use reporting tools to access the data.

Novell iManager plug-ins for Novell Audit include a report wizard that enables you to write, run and store SQL queries without having to know SQL. This plug-in also includes predefined SQL queries.

Comparing Features	Novell Audit	Novell Audit Starter Pack	NAAS
General Features
Centralized Logging	Y	Y	Y
Logging to flat file	Y	Y
Logging to MySQL database	Y	Y
Logging to Oracle database	Y
Real-Time Notifications	Y	Y	Y
Real-Time Monitoring Views	Y
Report Generation	Y
Logging Applications
NDS (6.x, 7.x, 8.x)	Y
eDirectory (8.5, 8.6, 8.7)	Y	8.7 instrumentation included with NetWare 6.5	Y
NetWare file system and console events (5.1, 6.0, 6.5)	Y	6.5 instrumentation included with NetWare 6.5	file system only
Logged Events
eDirectory General	Y	Y	Y
eDirectory Debug	Y	Y
eDirectory Partition	Y	Y
eDirectory Auditing	Y	Y	Y
eDirectory Meta-Events	Y	Y	Y
NetWare Traditional File Systems	Y	Y	Y
NetWare NSS File Systems	Y	Y	Y
NetWare Server	Y	Y
Real-Time Notifications/Alerts
Filter setup wizard	Y	Y
Alert using SMTP	Y	Y	Y
Alert using SNMP	Y	Evaluation included
Alert using Syslog	Y	Evaluation included
Alert using Java application	Y	Evaluation included
Write Alert to Log	Y	Evaluation included
Critical Value Reset	Y	Evaluation included
Log Management
Automated log file management	Y	Y
Log query wizard	Y	Y
Exportable SQL queries	Y	Y
Export reports to HTML	Y	Y
Export reports to MS Excel (CSV)	Y	Y
Export reports to *.txt	Y	Y
Report Generation
Preconfigured reports shipped with product	Y	Evaluation included
Integration with Crystal Reports	Y	Evaluation included
Security
Mutual Authentication (PA -> SLS)	Y	Y
Signing and Chaining of Events	Y	Evaluation included
SSL/TLS Encryption of Events in Transit	Y	Y
Delegated Administration	Y	Y
Other
Data transfer using IP	Y	Y	Y

Of the reporting tools included with the product, Novell Audit Report is the most powerful. Novell Audit Report is a Win32 application that, like Novell iManager, includes a wizard that enables you to define or write, store and run SQL queries and to use predefined SQL queries.

In addition (and this is where things get interesting), Novell Audit ships with several prewritten Crystal Reports for each Logging Application. (See Figure 2.) The even better news is that you can run these printer-ready reports without a Crystal Reports license. Furthermore, you can use Novell Audit Report to develop and run custom reports in Crystal Reports. To develop custom reports, you'll need a Crystal Reports license.

Arguably most important, Novell Audit Report enables you to easily verify the integrity of individual events as well as the log chain. With the click of a button, Novell Audit Report verifies all of the signatures in a particular log and all of the hashes that make up the chain of events contained in this log. Novell Audit Report then reports to users which (if any) events have been tampered with and where (if anywhere) the chain of events has been broken.

You can extend these reporting capabilities as easily as you can extend any other Novell Audit capability. The schema of the log data is well documented, enabling you or third-party developers to create additional prewritten reports using off-the-shelf reporting tools. The Novell Audit product team will continue to develop new reports and will share these reports via a community the team will soon create on developer.novell.com. The Novell Audit product team hopes that you and third-party developers will join them in these efforts.

Notification-The Real-time Story
As soon as data is received by the Secure Logging Server, the Event Manager forwards the data to other Secure Logging Server services, including the Notification Service.

The Notification Services provides two kinds of notification: filtered notification and heartbeat notification. Filtered notification tells you when a specific event has occurred, while heartbeat notification tells you when a specific event has not occurred.

In either case, the Notification Service looks for specific events from the stream of events it receives from Platform Agents. From this stream, it sends filtered or heartbeat notifications based on filters and other criteria that you specify in eDirectory (in Notification Filter and Heartbeat objects, respectively).

	Figure 2 Click for large view

Defining filters is made possible in part through the design of Novell Audit events, all of which have the same format. (For more information, see How Does It Look? The Makeup of an Novell Audit Event.) This format, which is similar to Syslog, dictates that each event include mandatory system attribute fields, such as the Event ID and Severity, and optional payload fields, including Text1, Text2, Value1 and Value2. Each Logging Application specifies the use of each field for every event in a Log Schema File (*.lsc). The standard format enables you to use a common set of tools to report on the data.

Once you define filter criteria in eDirectory, you indicate which Channel object or objects the Secure Logging Server should use to provide event notification. The Server Logging Server can use Channel objects you create for the binaries to data stores (that is, the binaries to MySQL, Oracle, Syslog and flat files) to route notifications. In addition, the Secure Logging Server can use Channel objects that you create for supported notification handlers, which include the following:

• Simple Mail Transfer Protocol (SMTP)
• Simple Network Management Protocol (SNMP)
• Java
• Critical Value Reset (CVR)

The types of notifications these handlers enable are self-explanatory, with the exception of the CVR handler. The CVR handler enables you to automate the reset of particular eDirectory attributes in the event these attributes are changed. For example, you might have a policy that dictates that no user can be equivalent to Admin. To enact this policy, you would create a Notification Filter object that would route notification to the CVR handler via a CVR Channel object each time a User object gained Admin rights.

In the CVR Channel object, you would define a rule that dictates the value to which the CVR handler should reset the affected eDirectory attribute. Then, if a User object gained Admin rights, the Notification Service would route a notice to the CVR Channel object, which in turn would reset the User object's rights according to the rule specified in this object.

You can configure the Secure Logging Server to route the same notification to several different Channel objects, resulting in different types of notifications. For example, for a particular event, you could configure the Secure Logging Server to send an e-mail notification to your mailbox, log the event to a MySQL database, and notify the CVR handler to trigger a reset policy.

You can easily incorporate additional notification handlers into this model. The Novell Audit SDK includes APIs that you or third-party developers can use to enable the Secure Logging Server to provide notification services through other means.

Monitoring-Broadcast news
In addition to the Notification Service, the Secure Logging Server provides a Monitoring Service that essentially maintains counts of values requested by monitoring applications.

Novell Audit ships with a Win32 monitoring application that provides realtime counts of event occurrences. These counts are based on the mandatory Event ID, IP Address or Log Level fields in the Novell Audit event format.

The Novell Audit SDK describes APIs that enable you or third-party developers to create additional monitoring applications that make use of the Novell Audit Monitoring Service.

	Figure 3 Click for large view

the way things could be If you introduced Novell Audit to the environment shown in a recent Novell television ad, the look of the ad would be quite different. In the ad to which I'm referring, you see two corporate users that have gained access to a resource to which they presumably have no rights. They've somehow acquired rights equivalent to their boss' rights, a CxO who sits nearby, periodically looking nervously at the two of them. "Check this out," says the guy at the keyboard. "The system thinks I'm him. . . . Cover me. I'm going in."

The ad ends with the Novell business definition of the technical term "browser": someone you never have to worry about when your systems are secure.

With Novell Audit, this CxO doesn't look nervous. He looks amused, if anything. He sits smugly because he knows precisely what these two are up to. He shakes his head in sympathy, knowing these two are in trouble, that he has the power to stop them, and that a legally admissible log is a few clicks away.

The bottom line is that with Novell Audit, you can answer "yes" to the questions in the introduction. Your data is secure-and you know it.

Talk back to editor@novell.com or rate this article online at www.novell.com/connectionmagazine.

NOTE: The "you" in this sidebar refers to the developer instrumenting an application to log to Novell Audit.

Novell Audit requires that all Logging Applications report events using the same format. (See Figure 3.) An Novell Audit event consists of two sections that contain data about the logged event:

1. The system attributes section, which is mandatory
2. The payload section, which is optional

• Component
  The component string is hierarchically formatted like a DOS pathname, with backslashes (\) separating component parts. The intent of the component string is to allow searching for common components of different Logging Applications. It can also be used to identify between multiple instances of the same application running on the same IP address. The first part of the component or the root identifies the application and is automatically inserted by the Secure Logging Server.
• Event ID
  The Event ID is made up of two parts: the Application ID and the Event ID. The Application ID is assigned through a central registry. Before instrumenting a new application, you need to register your application to obtain an Application ID from Novell Developer Support. Events IDs are numbers that you assign to each distinct event generated by a Logging Application.
• Grouping ID
  The Grouping ID is used to mark multiple log events belonging to a single transaction. The Logging Application is responsible for the use of Grouping IDs.
• Loglevel
  The LogLevel follows the standard Syslog log levels and indicates the relative severity of any reported event. For example, log levels indicate events that cause the reporting application to shutdown (EMERGENCY), events that require immediate attention (ALERT) and negative events that don't represent problems (WARNING).
• IP Address, Client Timestamp, Server Timestamp
  The IP address of the reporting host as well as the client and server timestamps are automatically assigned by the Platform Agent and Secure Logging Server, respectively, for security reasons.

The payload section is optional and consists of the following:

• String Value (1) and (2), Numeric Long Value (1) and (2)
  These values enable an application to report string values that are relevant to a given event. The ultimate value of any application instrumentation is determined by the care you take when determining your use of these fields.
• Mime Hint, Data Size and Data (Binary)
  In the Data field, you can store information (up to 3 KB) that you cannot store in the string or numeric value fields. If you use the Data field, you need to also use the Data Size field to indicate the size of information stored in the Data field and, if possible, you should provide a MIME hint about the type of data in the Data field.

For more information about preparing an application to log to Novell Audit, visit http://developer.novell.com/ndk/naudit.htm.

Tech Talk #2 - Using NetWare 6.5 To Develop A Sound Business Continuity Solution