Implementing Database Security and Auditing phần 9 potx

Audit trails are required and defined as “the data collected and tially used in a security audit,” and audit controls are defined as poten-“mechanisms employed to examine and record syst

334 11.1 The alphabet soup of regulations: What does each one mean to you?

that to their knowledge the filed reports do not contain any untrue ment or omission and that they represent the true financial condition ofthe company They are personally responsible for the report and can even

state-go to jail if a few years down the line the company needs to restate cial reports (as has been done often in the past few years) as a result ofimproper information presented in financial reports—especially if theycannot prove that they took enough steps to try to ensure that the infor-mation was correct

finan-SOX is a detailed document, and you don’t really need to read the whole

of it The most important section (and the one most IT people focus on) isSection 404, which requires management to report on the effectiveness ofthe company’s internal control over financial reporting This sectionrequires management’s development and monitoring of procedures andcontrols for making assertions about the adequacy of internal controls overfinancial reporting Furthermore, it is management’s responsibility and can-not be delegated or abdicated, so they also need to understand what is beingaudited, monitored, and how control is enforced (i.e., they cannot just betold that everything is okay) It goes even further: management has to doc-ument and evaluate the design and operation of, and report on the effec-tiveness of, its internal controls Management has to document theframework used, assess its effectiveness, publish any flaws and weaknesses,and do all of this within the annual report published to investors This boilsdown to the need for visibility, transparency, and segregation of duties

In September 2002, the Governor of California signed Senate Bill 1386into effect Among other things, SB 1386 mandates that:

operative July 1, 2003, a state agency, or a person or businessthat conducts business in California, that owns or licenses computer-ized data that includes personal information, as defined, to disclose inspecified ways, any breach of the security of the data, as defined, toany resident of California whose unencrypted personal informationwas, or is reasonably believed to have been, acquired by an unautho-rized person For purposes of this section, ‘‘breach of the security

of the system’’ means unauthorized aquisition of computerized datathat compromises the security, confidentiality, or integrity of personalinformation maintained by the agency

11.2 Understand business needs and map to technical requirements 335

Chapter 11

In effect this means that any business that maintains personal tion of a resident of California must have the appropriate provisions andcapabilities to know when this information may have been accessed by anunauthorized person This bill adds to a long line of bills that focus on pri-vacy, but stresses not just the need for privacy but also the need for effectivecontrols that will allow one to know when access control has been compro-mised and data has been accessed in an unauthorized manner

technical requirements

Regulations and other privacy requirements do not typically define cisely what types of technologies need to be implemented (although thereare exceptions E.g., HIPAA includes wording such as “Implement amechanism to encrypt electronic protected health information wheneverdeemed appropriate”) Some regulations actually go out of their way to not

pre-mention any technical implementation detail, and this makes them open

to interpretation and more difficult for you in that you need to decidewhat you need to implement and how For example, interpretations ofSOX regarding what type of technical provisions should be implementedcan range wildly Other regulations like HIPAA tend to be a little morespecific and define the types of technologies that should be implemented.But even in HIPAA you can find wording such as the following definingrisk management requirements—“Implement security measures andimplementations that reduce risks and vulnerabilities to a reasonable andappropriate level”—motherhood and apple pie! In most of these cases youwill often be asked to suggest a set of concrete implementation options tobring your organization into compliance with these regulations This map-ping is critical because, on the one hand, you need to implement a set ofprovisions that will comply with regulations (and will withstand a possibleexternal audit), and on the other hand, you need to come up with a setthat is implementable, does not cost an arm and a leg, and does not dis-rupt the smooth operation of the organization

It is surprising how difficult it can be to translate regulations and ness requirements into technical action items HIPAA is one of the mostspecific regulations, and even in this case mapping is difficult HIPAArequires that technical measures for securing private patient information areintegrated into the organization’s information systems and that auditing ofthis access is supported It goes on to define various categories that must beaddressed, including authentication, authorization, accountability, integ-

busi-336 11.2 Understand business needs and map to technical requirements

rity, secure transfer through cryptography, key management, and securestorage All of these requirements map intuitively to elements within thedatabase and topics that you have seen in previous chapters

Because of the complexities of these regulations, because they often dealwith a wide array of topics that address broader issues than just the techni-cal ones, and because the language used within these regulations leaves alot to interpretation, it is often easier and more efficient to do a “reversemapping.” In a reverse mapping exercise you start out with a list of secu-rity and auditing provisions that you have implemented, are implement-ing, or plan to implement, and that hopefully include the various topicsdiscussed in Chapters 1 through 10 You then check off items in the regu-lations that these security best practices cover Couple that with auditingimplementations based on Chapters 12 and 13, and you get a reverse map-ping that normally addresses most of the requirements in terms of thedatabase infrastructure

The nice thing with a reverse mapping approach is the ease with which

it satisfies a lot of these regulations Some HIPAA examples include thefollowing:

You implement user-based and role-based privileges in your databaseand you might also have some context-related mechanisms, that helpyou identify the end user (in addition to the database user) such asthose seen in Chapter 6 Such definitions map well to the securityrule in section 142.308, which defines access controls as methods ofcontrolling and restricting access to prevent unauthorized access toinformation The rule states that CEs must provide one of threeaccess controls: user-based, role-based, or context-based

The minimum requirement for privacy is that role-based accessrequires policies and procedures that identify the person or class ofperson within the CE that needs access to the protected health infor-mation This maps well to your authentication scheme and identifica-tion mechanisms discussed in Chapters 4 and 6

Audit trails are required and defined as “the data collected and tially used in a security audit,” and audit controls are defined as

poten-“mechanisms employed to examine and record system activity.”

11.2 Understand business needs and map to technical requirements 337

Chapter 11

Pretty much any type of monitoring and auditing described in many

of the previous chapters will satisfy this definition

If you have any type of database intrusion-detection capabilities(including detection of Trojans, rogue connections, etc.) or SQL fire-wall capability, then you can check off section 164.308—administra-tive safeguards/security management process—requiring you to

“implement policies and procedures to prevent, detect, contain andcorrect security violations.”

Another good example for the effectiveness of reverse mapping is GLBA,which mandates the privacy and security of nonpublic personal informa-tion (NPI) Including the following:

Authentication, access control, and monitoring

Reverse mapping is an excellent starting point, but it often needs to becomplemented by additional mappings These include a timetable map-ping, a data mapping, and a process mapping

A timetable mapping is necessary because if you start from scratch youhave quite a lot of work and many issues to deal with This is a large project,and like any project it has phases and interim goals The regulations, too,often have various phases and deadlines, and you should make sure that the

338 11.2 Understand business needs and map to technical requirements

implementation phases and timetables map to the regulation timetables

Another time-related matter that will affect your project is the retentionperiod required by the regulation This will determine the type of storageand the tools you will need to put in place to implement archiving and res-toration of audit information For example, HIPAA mandates a retentionperiod of six years

Data mapping is perhaps the most important exercise and one that isabsolutely mandatory for your success You need to identify the data in thedatabase that maps to the information that the regulations discuss Forexample, if you are working on a HIPAA initiative, you need to identifywhat constitutes protected health information, what data elements are usedfor row-level security (e.g., if you have to implement authorization based onthe association between a primary care provider and a patient), and so on Ifyou are working on a SOX implementation, you need to identify whattables maintain financial data and what data and procedures need to bemonitored and controlled to ensure the correctness and integrity of finan-cial reporting If you are doing a GLBA project, the NPI can include name,Social Security number, net worth, and income, and you need to identifythe appropriate tables and columns within which this data resides

Finally, you may need to do a regulation-specific process mapping

Beyond the basics of security and privacy, some of the regulations definevarious processes that embed exceptions or that require more attention As

an example, after defining uses and disclosures for which an authorization isrequired in section 164.508, HIPAA goes on to define a set of uses and dis-closures for which an authorization is not required (section 163.512) Thesection states that CEs may use or disclose protected health informationwithout the patient’s consent or even validation in the following cases:

As required by law

As required for public health activities

If related to victims of abuse, neglect, or domestic violence

For health oversight

If related to judicial and administrative proceedings

For law enforcement purposes

If related to deceased persons, to coroners, medical examiners, andfuneral directors

If related to organ and tissue donations

11.2 Understand business needs and map to technical requirements 339

Chapter 11

For research purposes

To avert a serious threat to health and safety

If related to military personnel, inmates in corrections facilities, orother specialized government functions

If related to worker’s compensation

In these cases you must ensure that the security and audit provisions youmake support these processes as exceptions

Excel and other spreadsheets have become the focus of many SOX mentations, because spreadsheets are extensively used in financial reportingand form the user interface layer in many financial applications In somecases, Excel actually bypasses the real financial application that usually hasmore security, audit, and control mechanisms than Excel and forms a

imple-“rogue” financial application

Many companies are investing in better controls related to the use,development, and maintenance of spreadsheets The focus is both in terms

of the formulas and correctness of the models implemented within thespreadsheets as well as the data that is accessed and updated using spread-sheets This focus on what seemingly is just another application accessingthe data is justified, because there have been many real cases in whichmore damage was done using a spreadsheet than you could imagine Awell-known case (without naming names) involves a major financial insti-tution that, as a result of a flawed change control process, allowed theintroduction of an error that resulted in a $1 billion financial statementerror Another true example is of a trader who committed fraud by chang-ing spreadsheet macros and updating data in a database that was not beingaudited for changes

All in all, because spreadsheets are so ubiquitous, open in terms of tionality, and do not have robust auditing and control mechanisms, mostSection 404 implementations will include a specific task that directlyfocuses on the use of spreadsheets and the data that is being accessed andchanged from spreadsheets This maps very well to various techniques youhave learned that allow you to monitor, audit, alert on, and block access tooperations that are initiated from a spreadsheet For example, monitoringsource programs (as shown in Figure 11.1) will give you a clear indication

func-of which applications are accessing the database Baselining access

(dis-340 11.3 The role of auditing

cussed in Chapter 5) will allow you to identify any divergence from normal

access as a result of operations initiated using Excel and can help with anadditional control and audit point in the spreadsheet macros’ change con-trol process Finally, if you would prefer all updates to be made through thefinancial application, you can create an alert or even a deny rule in a SQLfirewall that will allow Excel to read from the database but not allow it tomake any DML commands (or DDL commands for that matter)

Audit as a function (both internal and external) needs to play a central role

in ensuring compliance This is very clear in all regulations and is perhapsthe most significant item that is well-defined in all of the regulations men-tioned in Section 11.1 For this to be possible, data must be available andtransparent so that an audit can be performed

Two types of data are required to ensure compliance of the databaseenvironment The first category includes audit trails and other logs—called

auditing information here You need audit trails for access to sensitive

infor-mation, for metadata (as part of a change control process), for updates tofinancial data, and so on The simplest example that we all know (Figure

11.3 The role of auditing 341

Chapter 11

11.2) is an audit trail detailing all logins and logouts into the databaseserver, but audit trails are everywhere, and they are explicitly mentioned bymany regulations HIPAA, for example, includes section 164.528—Accounting of disclosures of protected health information—which statesthat an individual has the right to receive an accounting of all disclosuresmade by the CE in the six years prior to the request (excepting some spe-cific types of disclosures such as to the individual) These disclosures map todatabase access The CE must present the account within 60 days of therequest and must supply one of these per year free of charge If taken to anextreme interpretation, this requires knowing who connected to the data-base maintaining the protected health information and selected recordsabout the individual—and keeping this record for six years in a place thatcould be relatively easy to retrieve from

The second audit category involves security audits These are sometimes

called assessments, penetration tests, or vulnerability scans, and focus onthe current state of a database environment rather than auditing data Theseaudits are typically performed periodically (e.g., once a year) as part of alarger audit, compliance, or governance schedule and are aimed to ensurethat the database environment continuously complies with set regulationsand policies

You should use assessment tools for these types of audits, because theyalready include and package a set of best practices, known vulnerabilities,and items that map well to compliance requirements Some of these toolsare free whereas others need to be purchased For example, in the secondhalf of 2004, Microsoft released the SQL Server Best Practices AnalyzerTool, which is free and can be downloaded from

D3CA-44EE-893E-9E07339C1F22&displaylang=en

www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-(or just run a search on the Microsoft site for SQL Server Best tices Analyzer) Using this tool you can analyze SQL Server instances forcompliance with widely accepted best practices The initial focus of thetool is on performance and efficiency, but items related to security will beadded over time

Prac-When using the analyzer, you start off by defining your database serversand by creating groups of servers This allows you to run an audit per server

or run it for the entire group You then define the best practice rules to run

as shown in Figure 11.3—groups of items that the audit run will check pereach of the databases in the group You then run the audit, which will checkeach rule with each database server in the defined group to produce a com-

342 11.3 The role of auditing

pliance report with a value for each rule, as shown in Figure 11.4 Anotherexample of a penetration test (this time for Oracle) is shown in Figure 11.5.Penetration testing and vulnerability assessments check the configura-tion of your database, the patches installed, and try to find mistakes andproblems that may exist in your database However, they do this in an iso-lated manner and only look at the database as a server Another breed ofassessment tools merges the notion of audit with the notion of auditing tosupport continuous assessments that evaluate potential flaws in the databaseenvironment—not in how it is configured but how it is used Rather thanscanning the database and its configuration, it scans all access to the data-base from all applications and assesses whether there are weaknesses andproblems in the way the database is being used

A simple example will clarify the difference A static vulnerability ment will try to sign onto the database using an empty password, a trivialpassword (e.g., sa for the sa user in SQL Server), or one of the default pass-words (e.g., change_on_install for the SYS user in Oracle) A data accessassessment will look at all applications and users in terms of how they aresigning onto the database It will alert you when, for example, the samelogin name is being used for a large number of different network nodes.This is a serious vulnerability and a weakness in the database and applica-tion environment as a whole In another such example, it can report on

assess-Figure 11.2

Login/logout

audit trail.

11.3 The role of auditing 343

assess-Data access assessment tools allow you to build assessments by definingwhich database environments should be inspected and which tests to run(Figure 11.6) For each test, you specify a weight (used later to compute onetelling score) and a minimum value that defines compliance The assess-ment is then run based on full audit trails that are continuously collectedand therefore assess real usage of the database The end result of such anassessment is a security scorecard (Figure 11.7), which shows you both ahigh-level score (which is a weighted average of various security dimensions,

Figure 11.3

Defining the rules

that will run as

part of the audit.

344 11.4 The importance of segregation of duties

details per security dimension, and recommendations per security sion) and historical charts showing you how close you are to compliance atevery point in time

dimen-Finally, the last role of audit and auditing is as an integral part of rity There is no security without audit This is not merely a by-product ofhuman nature, the effectiveness of deterrence, and so on Auditing reportsand audit results are important tools in spotting problems and fixing them

All regulations try to deal with a set of human behaviors such as ness, greed, sloppiness, laziness, and so forth In doing this, the regulationsuse two main techniques: (1) guidelines so that people cannot too looselyinterpret the regulations to their benefit and (2) segregation of duties Ofthe two, segregation of duties and the use of multiple audit layers is the

untruthful-Figure 11.4

A compliance

report based on the

selected rules.

11.4 The importance of segregation of duties 345

Chapter 11

main and most effective way to ensure compliance The basic idea is thatyou cannot trust the process to a single individual or a single group butneed to build the process in a way so that you have multiple layers of

346 11.4 The importance of segregation of duties

audit—each one ensuring that the previous group did not do anythinginappropriate For example, SOX is full of refinements that discuss whatmanagement should do, what internal audit should do, what external auditshould do, and so on These refinements are all related to the most funda-mental requirement in SOX and all other regulations—that of segregation

of duties Segregation of duties is a must, and if an implementation does

Figure 11.7

Security scorecard.

11.5 Implement a sustainable solution 347

A DBA should not be able to change an audit trail This almost ately means that using the built-in database auditing features is question-able and that if you do decide to use these features, you will have to putmany check and balances in place Alternately, you can choose to use anexternal system that maintains an independent audit trail These systemstend to have a security orientation and preserve an audit trail that cannot bemodified, has nonrepudiation attributes, can be used for investigations, andcan have a different owner This approach not only complies far better withregulations, but it also removes some of the work that the DBA needs to do(since the DBA is usually overburdened with other tasks and views auditing

immedi-as the leimmedi-ast important timmedi-ask)

The need for good security and auditing is certainly felt today, but it willbecome even more prominent in the next few years Environments are notbecoming simpler; instead, they are becoming increasingly more complex.Regulations, too, are not a passing fad and are here to stay for the longrun Complying with all of these policies, whether they are driven by a reg-ulation or by internal best practices, is a need and a requirement that willpersist Therefore, when you are thinking about how and what you imple-ment, you must address the question of whether what you are doing is sus-tainable for the long run When you implement a solution for addressingSOX, GLBA, or any of the other regulations, think of it as something thatyou will need to perform every year, possibly multiple times during a year,and sometimes even throughout the year It makes sense to work hard onetime to put a system in place that will remove much of the headache forthe years to come; it does not make too much sense to solve the problemnow through a lot of work and have to do it all over again three monthsfrom now

Sustainability means a few things First, you need to use tools that will

do most of the work for you You really don’t want to sift through endless

348 11.6 Summary

logs of information; you want the information to be stored in case you need

it, but you want exceptions and compliance violations to be quickly fied for you Second, you need to be able to get information at multiple lev-els For example, you need a high-level view such as the scorecard of Figure11.7, but you also need to be able to drill down to the SQL details when ananomaly shows up Third, you must implement a solution that will sustainchange Requirements will be constantly changing in terms of what toaudit, who to audit, when to audit, and so on If every such change willrequire a lot of work, then you will go crazy over time You need a system inwhich changing requirements can be satisfied by simple changes to policies

identi-or repidenti-orting definitions Finally, the solution should be well-packaged andself-maintaining Keeping all of this information usually means anotherdatabase of some sort You do not want the added nightmares of having tomaintain this database, archive it, back it up, and tune it (not to mentionaudit it) You need a self-contained solution that addresses all of theseissues All of these topics are further discussed in Chapter 13

As mentioned in the previous chapter, the key to a good auditingimplementation is to understand what the requirements are and to usereverse mapping to see what requirements you can check off using theauditing categories listed in this chapter This chapter can therefore beused as a catalog from which you can pick audit trails to implement, andpossibly in what order

When you walk into a meeting in a corporate office, the first thing you’reasked to do is sign in at the front desk Among other things, this ensuresthat the company has a full log of anyone who came into the building,which may be useful to track down and investigate “who done it” whensomething goes wrong This log usually records who you are, when youcame in, and when you left The same process is true for any database, andthe first category of auditing that is required in most environments is a fullaudit trail of anyone who has signed onto the database

You will need to record two events for this audit category: an event forthe sign-on and an event for the sign-off For each such event, you need tosave at least the login name used for signing on and a timestamp for the

350 12.1 Audit logon/logoff into the database

event, but you should consider recording additional information Thisincludes the TCP/IP address of the client initiating the connection and theprogram used to initiate the connection For example, in an Oracle envi-ronment, you will want to know if the connection was initiated from SQLPlus, TOAD, and such tools as opposed to a data source in Excel or a J2EEserver

In addition to these two events, you should also record all failed loginattempts In fact, failed login events are probably even more important thansuccessful logins from a security point of view Failed login attempts are notonly recorded for auditing and compliance purposes; they are often used asthe basis for alerts and even for account lockout

Although you may keep these three event types in the same file or table,you will probably report on them differently Successful logon/logoffreports are not something most people look at unless they are doing somekind of investigation, because these logs reflect normal operations Apartfrom investigations, an exception could be comparing files from differentperiods to see if patterns are changing However, excessive failed logins arecertainly an interesting security report, and many people periodically look

at the breakdown of these failed login attempts based on the followingdimensions:

Logon and logoff activity can be audited using database features or byusing an external database security solution All database vendors supportthis basic auditing function, and because the number of these events israther small (at least when compared with the number of events you mayget when auditing actual SQL calls), there is little performance penalty inhaving the database perform this level of auditing

12.1 Audit logon/logoff into the database 351

Chapter 12

In Section 9.6you saw how to implement this type of audit trail in DB2using event monitors and how to implement this type of audit trail in SQLServer using traces While the context in that section was actually one of ahacker trying to plant a Trojan that collects this information to be used inlaunching an attack, the methods shown are precisely what you would use

to create a login/logout audit trail in DB2 or SQL Server Oracle has morethan one way to produce this audit trail, but perhaps the easiest one is usingsystem-level triggers that have been around since Oracle 8i

Just as an Oracle trigger fires when you insert or update a row, a level trigger fires at specific system events such as logon, logoff, and DDLexecution Let’s see how to implement this type of audit trail

system-First, create a table where you will keep the information:

create table user_login_audit (

user_id varchar2(30), session_id number(8), host varchar2(30), login_day date,

login_time varchar2(10), logout_day date,

logout_time varchar2(10) );

Next, create the trigger to be fired upon a new login:

create or replace trigger user_login_audit_trigger AFTER LOGON ON DATABASE

Figure 12.1

Failed login

reports.

352 12.1 Audit logon/logoff into the database

BEGIN insert into user_login_audit values(

user, sys_context('USERENV','SESSIONID'), sys_context('USERENV','HOST'), sysdate,

to_char(sysdate, 'hh24:mi:ss'), null,

null );

logout day update user_login_audit set

logout_day = sysdate where

sys_context('USERENV','SESSIONID') = session_id;

logout time update

user_login_audit set

logout_time = to_char(sysdate, 'hh24:mi:ss') where

sp_configure "auditing", 1 go

sp_audit "dbaccess", "all", "all", "on"

go

12.1 Audit logon/logoff into the database 353

Chapter 12

Implementing alerting or account lockout based on failed loginsrequires support from either your database vendor or your database securitysolution If you use the database to generate the audit trail for login/logoutand your database vendor implements account lockout capabilities, thenyou can set that up within your database environment For example, in Sec-tion 4.4you saw how to set up an Oracle password policy In another envi-ronment (e.g., SQL Server 2000), you cannot do this using native databasefeatures and need to either write code that inspects the Windows event loglooking for collections of failed logins or use an external security system.When using an external security system, you can use a SQL firewall thatwill block any connection using the login name after a certain number offailed login attempts In this case, the database will not even get the connec-tion attempts because they would be rejected at the firewall level Anotheroption (which does not require you to put a security system in front of thedatabase) is to use database procedures, as shown in Figure 12.2 In this casethe auditing system generates an alert when the number of failed loginsexceeds a certain threshold The alert is sent to a system that is responsible

to connect to the database and call a procedure that locks out the account.This system would typically also notify the DBA that this action has beentaken so that an investigation would be initiated and the account released ifneeded

354 12.2 Audit sources of database usage

In addition to creating an audit trail, login information can be used tocreate a baseline that may help you in identifying anomalies A baseline foruser login activity is a mapping of “normal” login behavior Such a baseline

is built by looking at all login activity over the course of a certain period oftime (e.g., a week, a month) The baseline is built by listing all possiblecombinations and classifying them For example, you can classify logins bynetwork location, username, source programs, and time of day, in whichcase a baseline may look similar to the following:

This baseline says that based on all of the login activity seen in the vant recording period, user1 always comes in from 192.168.1.168 (e.g., it isthe application server) and may be connected at any time during the day.User2 is used to connect to the database from Excel, is used from multiplenodes on the network all within the 192.168 subnet, and is not used out-side of normal business hours Finally, user3 is used when access is initiatedfrom isql, works over the weekend, and can come from any node on the10.10.10 subnet

rele-Once you have this baseline, you can report on or alert on divergencefrom normal operations If, for example, you see a successful login usinguser1 but from an IP address that is different from 192.168.1.168 andusing a tool such as SQL Navigator, then either your environment haschanged or possibly someone managed to take the username and passwordfrom the application server and is using it to extract information from yourdatabase (see Section 5.1).As another example, a login using user2 at 2 a.m.can be suspicious It may just be that someone is working late, but depend-ing on your environment, sensitivity, and how locked down your environ-ment needs to be, it may be something you need to look into

Related to the auditing of login activity is the auditing of client sourceinformation This includes auditing which network node is connected tothe database (e.g., using an IP address or a host name) and auditing whichapplication is being used to access the database

Although this information is normally one of the values you should ture when you audit database connections, it is often important to capture

cap-12.2 Audit sources of database usage 355

Chapter 12

this information at a SQL call level In addition to knowing that a user nected using Excel rather than the SAP system, you may also need to knowwhether a certain update was performed from an Excel spreadsheet asopposed to the SAP system Therefore, the source program is often datathat you should collect per query and per database operation that you want

con-to keep in the audit trail, especially if the IP address uniquely identifies auser If your architecture is based on client/server, then the source IPaddress often identifies a unique user (a person) In this case, tracking andreporting on the IP address per SQL call is as good as reporting on whichend user did what operation and looked at what data—a valuable audittrail If, on the other hand, you use an application server architecture, thenthe IP address will not help you identify and report on the end user and youwill have to resort to techniques learned in Chapter 6

Another decision that you may need to make when auditing and senting audit information has to do with whether you present raw data orwhether you present it as data that is easier to consume For example, theleft side of Figure 12.3 shows which source programs are used to access theSQL Server running on 155.212.221.84 This information is useful to peo-ple who know the environment intimately The report on the right side ofFigure 12.3 is meaningful to more people, who don’t care about the IPaddress but know what the HR database is, and people who don’t knowwhat Aqua Data Studio is but understand the risks associated with a devel-oper tool logged into the production HR database

pre-The issue of data abstraction is not only related to auditing the clientsource of database usage It is a general topic relevant to all audits that arediscussed in this chapter However, as Figure 12.4 shows, it is especiallyimportant in source identification, where IP addresses may not be meaning-ful but where hostnames or even labels attached to nodes are informative

Figure 12.3 Viewing database information (IP and application type) in raw form and

in business terms.