WIXLIB

Remove *AUDIT Special Authority from UsersUsers with *ALLOBJ and *AUDIT special authorityhave the potential to configure what types ofevents and users are audited. They can also turnthe auditing function on and off. If the organizationsupports a separate auditor role, then *AUDITauthority should be removed from any otheruser. It should be noted that users that possess*ALLOBJ can potentially grant themselves *AUDITspecial authority.Control Access to Auditing-Related CommandsThere are numerous commands that can impactthe integrity of the IBM i auditing function andshould be secured. As a powerful supplementallayer, PowerTech Command Security (PTCS) canprevent abuse by standard and powerful users —for example, users with *ALLOBJ special authority—using flexible, rule-based restrictions.Many commands should be considered as candidatesfor lockdown, although this is difficult to do againstpowerful users without a solution such as CommandSecurity. The commands listed below pertain only tothe auditing function and are not guaranteed to be theonly commands that could compromise the integrityof the auditing repository.The following commands are shipped with PUBLIC(*USE) and require that the user have authority toaccess the objects impacted by the delete operation.They require no special authority and should besecured from abuse by all users:DLTLIBDLTJRNRCVDelete LibraryDelete Journal ReceiverThe following command is shipped with PUBLIC(*EXCLUDE) and requires that the user have access tothe command, the QAUDJRN audit journal, and the oldand new receivers. It requires no special authority andshould be secured from abuse by powerful users:CHGJRNChange JournalThe PowerTech Group, Inc.www.powertech.com info@powertech.comThe following commands are shipped with PUBLIC(*USE) and require that the user possess *AUDITspecial authority. They should be secured from abuseby powerful users:CHGUSRAUDCHGOBJAUDCHGAUDChange User AuditingChange Object AuditingChange Auditing (IFS)The following command is shipped with PUBLIC(*EXCLUDE) and requires that the user have access tothe command, plus *AUDIT special authority in orderto change the QAUDxxx system values. It should besecured from abuse by powerful users:CHGSYSVALChange System ValueThe following command requires that the user have*ALLOBJ and *AUDIT special authorities. It should besecured from abuse by powerful users:CHGSECAUDChange Security AuditingThe audit function included within IBM i doesn’ttypically encompass activities that originate fromthe network (e.g. FTP or ODBC). This is an importantconsideration and is discussed in the “Network Access”section.For more detailed information on IBM i auditing, referto the PowerTech paper “Security Auditing in the RealWorld,” available for download at www.powertech.com.System ValuesAs previously mentioned, the IBM i operating systemdetermines many of its configuration settings througha mechanism called System Values. Although notall system values are considered critical to security,a majority should be protected and monitored forchanges.Baseline ComparisonSystem values should be compared against apolicy baseline on a regular basis. Exceptionsbetween the baseline and actual values shouldbe reported immediately, the cause determinedand made compliant as soon as feasibly possible.p. 5

This comparison can be performed manually froma printed list or using a purpose-built auditingsolution such as PowerTech Compliance Monitor. Monitor For Changes Logged To QAUDJRNBaseline comparisons work well for a point-intime validation. However, there remains a riskthat a program or user could change a systemvalue and subsequently change it back beforenon-compliance can be detected by baselinecomparison. In addition to baseline verification, it’sstrongly recommended that auditing be configuredto include *SECURITY events, and that the eventlog be reviewed for “SV” entries indicating that asystem value was altered.To automate this process, PowerTech providestwo powerful solutions. Compliance Monitor isdesigned to search on any event logged withinQAUDJRN and generate easy-to-read forensicreports of the results. PowerTech Interact canmonitor QAUDJRN for the arrival of a loggedevent and escalate a notification in real-time toa message queue, ISS console, or SIEM (syslog)solution.Prevent Unauthorized Change Using PowerTechCommand SecurityCommand Security is a command line monitoringsolution. It controls how and when a commandcan be executed through a powerful combinationof selective conditions and associated actions. Asan exit program solution, it’s even effective againstpowerful users—a set of users that were previouslyconsidered unstoppable. Although it’s capable ofmonitoring any command, in the current context itshould be configured to monitor the CHGSYSVALcommand.Lock Down Via SSTIBM i permits a subset of system values to belocked in order to prevent alteration by any user.This restriction was provided to eliminate the riskof programs or users changing system valueswithout permission; and is performed inside theconfinement of System Service Tools (SST) toencompass users with *ALLOBJ special authority.The PowerTech Group, Inc.www.powertech.com info@powertech.comUnlike Command Security, this capability is all-ornothing; but is still recommended as it provides anadditional layer of security. The list of “lockable”system values for the installed operating systemrelease can be found in the help text of theCHGSYSVAL command.Anti-VirusNo discussion about operating system integrity wouldbe complete without covering the ongoing challengeof viruses and malicious code. Unlike other popularoperating systems, IBM i’s unique infrastructure ishighly virus-resistant. This is partly due to the fact thatit’s not possible to change an object from one type toanother. In Windows, for example, an object’s type isbased upon its filename extension. This means you cansimply rename a file to change its type—for example,making an executable appear to be a .pdf document.This type of object manipulation is not possible in IBM idue to protection provided by HSP.Viral infection typically entails the virus embeddingand hiding executable code inside other objects. IBM iobject binaries cannot be modified without recreatingthe object and cannot masquerade as anything buttheir original object type. This prevents the initialinfection and spread of viral code.Other file systems remain vulnerable to viral infectionand should be monitored using a commercial anti-virussolution, such as StandGuard Anti-Virus (SGAV).Powered by McAfee, SGAV is a native IBM i solutionthat is fully integrated with the operating system’s ownanti-virus enablement features. This solution providesscheduled, on-demand, and open/close scanning offiles stored in the Integrated File System (IFS), as wellas Lotus Domino databases, AIX, and Linux. All normalanti-virus capabilities are available, including thedownload of up-to-date virus signatures from McAfeeand infected object quarantine and cleansing.It should be noted that malicious code can be writtenfor IBM i, just as it can on any server. A program thatperforms a Power Down System (PWRDWNSYS)command could be configured as the server’s “startup” program and cause a frustrating and costlyp. 6

cycle of power up and power down events. Althoughtechnically not a virus, this is definitely malware andgood security practices, such as monitoring andprotecting system values, should be utilized to reducethis risk.SQL LANGUAGESlanguagesSQL SIZING- SQL standard list of database limitsSYSJARCONTENTS- registry of classes related to JavaroutinesSYSJAROBJECTSConfiguration FilesIt is critical that user authorities be closely guarded,and access by privileged users be monitored, using acombination of profile and object auditing. PowerTechAuthority Broker manages the temporary assignmentof administrator privileges and the monitoring ofpowerful users, and can reduce the risk associatedwith system access by these users.Some examples of files that should not be directlyaccessed include:Library QSYS (or iASP equivalent):- registry of all physical files, logicalfiles, SQL tables, views, indexes,packages, and aliases.QADBXRDBD- registry and configuration foraccessing remote databases.Library QSYS2 (or iASP equivalent):SYSROUTINES- registry of jarids related to JavaroutinesMuch of the operating systems configuration ishandled via system values. However, database files doexist that contain elements of system configuration.Generally, these system files are secured from users.However, in many organizations the proliferation ofusers with powerful administrative rights like *ALLOBJmakes these objects vulnerable.QADB*- SQL standard list of supported- registry of all user-defined routines(functions & procedures)SYSROUTDEP- registry of all routine dependenciesSYSPARMS- registry of all routine parametersSYSSEQOBJECTS- registry of all sequence objectsSYSTYPES- registry of all user-defined typesSYSVARIABLES- registry of all global variablesSYSVARIABLEDEP- registry of all global variabledependenciesSYSIXADV- index advice tableSQL FEATURES- SQL standard list of supportedSYSTEXT*- registry of Omnifind configurationXSR*- registry of all XML schemas(XSROBJECTS)Library QRECOVERY (or iASP equivalent):QDBAL*- ALTER TABLE status filesQDBIX*- Create index build status filesQDBRG*- Reorganize status filesQDBTI*- Omnifind text index build status filesQADBERAP- Asynchronuos index rebuild(EDTRBDAP equivalent)QSQ901S- SQL -901 LoApplication IntegrityIf your organization stores data in DB2 files, there’sa good chance that much of that information isconsidered “critical” to the application that maintainsit and the business unit that owns it.The objective of file integrity monitoring within theapplication layer is to ensure that critical data is onlyaccessed by authorized users through approvedapplications, thereby assuring its availability andaccuracy.Powerful users, such as administrators andprogrammers, usually have access to productiondata. Regulatory compliance often demands thatthis be revoked to prevent unauthorized activitiesor accidental mishaps. Even though not directlyrelated to FIM, user management solutions should beevaluated to ensure consistent profile configuration,and to audit and control user access to productiondata. PowerTech’s PowerAdmin and Authority Brokersolutions were designed specifically to address theserequirements and satisfy compliance regulations.featuresThe PowerTech Group, Inc.www.powertech.com info@powertech.comp. 7

The IBM i operating system contains severalmechanisms to support the concept of FIM, althoughthey weren’t specifically designed for security integritymonitoring and do not exhibit all of the characteristicsof a modern FIM solution. They do, however, providethe necessary foundation for application developersand commercial providers to build FIM solutions.JournalingIBM i includes an integrated DB2 database with theability to capture changes made to database objects.This function is known as journaling, and it can trackthe before and after image of a database record.Originally used for recovery purposes, it is commonlyused for high availability replication, and can also beused to generate an audit trail.As with the security audit journal, the data collectedby the database journaling function is stored in journalreceivers, which are simply containers much like astructureless file.There are two main considerations when journalingis used for non-audit purposes (for example for highavailability replication or application recovery) versus FIM.RetentionAfter a non-audit data change has been safelywritten to the disk, or replicated successfully toa high availability system (two common uses forjournaling), there is no further use for the journaldata. High availability applications are oftenconfigured to purge non-audit journal informationafter 24 hours. The retention requirement for auditjournal data is typically longer than for non-auditdata. Some regulatory standards call for changedata to be retained for 12 months or longer, soawareness of retention requirements in crucial.Before and After ImagesJournaling can be configured to capture therecord’s original (“before”) data and the changed(“after”) data. With non-audit journaling, only thechanged data may be required, however with auditjournaling for FIM, it is typical to capture andstore the before and after images.The PowerTech Group, Inc.www.powertech.com info@powertech.comThe main technical challenge with journaling forthe purpose of auditing is that the captured datais unformatted, rendering manual analysis difficultand extremely time consuming. There are nocolumns to parse the data and no key fields to sortit. There are also no search capabilities, reporting,or alerting functions. After a change is made to thedata, the journal receiver contents must be displayedand manually analyzed to determine if the changewas authorized. Unfortunately, this process is notconducive to the timely discovery of illicit activity,allowing a perpetrator plenty of time to completetheir activities.Journaling is capable of recording events that impactdata (add, update, delete) but not the viewing ofa data record. In some cases, simply viewing thedata could be construed as a breach and should bemonitored. For example, perhaps payroll or medicalinformation should only be displayed within theconfines of the approved application. Depending onthe sensitivity of the data, being able to determine thetype and scope of a breach can prove highly valuableand this functionality should be provided by a readcapable monitoring technique, such as triggers.Despite these limitations, journaling remains therecommended approach to audit database changes.Enhancing its functionality to detect activities in realtime, to differentiate between irregular and normalbusiness activity, and to escalate the notificationof violations yields significant Return On SecurityInvestment (ROSI).Organizations don’t typically benefit from notificationof every single event in a large file. Criteria mustbe specified to indicate the normal source of thoseevents, which fields are critical, and the acceptablerange of data values. This enables the business todetermine if a change is a normal business transactionmade via an approved application. Reducing thenumber of false or unimportant alerts prevents theover-notification that typically leads to complacencyand overlooking when an unauthorized event doesoccur.p. 8

The following table lists examples of data events thatmay require selective handling.DatabaseEventEventDatabaseCustomer name changes viaMaintenance ApplicationAuditAudit DesiredDesiredNOSTRJRNPFENDJRNPFStart Journaling Physical FileEnd Journaling Physical FileOther commands, such as DLTJRNRCV and CHGJRNshould be controlled as already described under EventLog Integrity.TriggersCustomer A/R balance changes(by more than 100,000)YESSalary increases by more than 10%(via maintenance application)YESSalary increases by more than 10%(via DFU)YES ALERTDeletion of an Accounts PayableRecordbe restricted—especially when used against auditjournal receivers. Some examples include:YESThe benefit of reacting selectively extends beyondsecurity—it enables raised awareness to the presenceof any database issue, including inventory errors andaccounting inaccuracies.Many customers have found success usingPowerTech’s DataThread. Originally written for thehighly regulated pharmaceutical industry, this solutioncomplements IBM i journaling with selective auditing,notification, and logging capabilities. If a databaseis already journaled for other purposes, such as highavailability, the existing journal receivers can be used.A trigger is a database function within DB2 thatpermits an application program to be invoked duringvarious database operations. There are four triggerevents that can be used to monitor a file: INSERTCHANGEDELETEREADUsing the Add Physical File Trigger (ADDPPFTRG)command, triggers can be set to “fire” before or afterthe activity on the file has occurred.Triggers are able to provide similar functionality todatabase journaling by accessing the before and afterimage of a database record, although performance isoften a consideration due to the overhead of programinvocation. Trigger programs should be carefully testedto establish the impact on application performancewhen added.Once configured, DataThread diligently observes fileactivity for data events that are outside the boundsof normal business activities, based on rules specifiedwithin the product. DataThread monitors selectivechanges in a single field, or logs every data event thatimpacts the entire file.Journaling is designed to capture and store databaserecord images; however, the functionality of a triggerprogram is controlled by the programmer that writesit. A trigger program receives information about adata event. Depending on the type of event, this mayinclude the before and after image of the record.This can then be acted upon in any manner, includingstoring the before and after image in a log or evenoverriding the data before it is written to disk.Journal commands should be audited and controlledusing command line restrictions, object access, and amodern command monitoring solution like PowerTechCommand Security. Journal-related commands shouldThere are disadvantages to using triggers for auditpurposes, not least of which is that every triggerprogram has to be written. Many auditors frownupon the conflict of interest in self-policing whenThe PowerTech Group, Inc.www.powertech.com info@powertech.comp. 9

an organization’s own programmers are involved inbuilding the monitoring controls. Building, testing, andmaintaining security applications with the necessaryrobust functionality is not a priority for most I.T.departments—especially when there are commercialsolutions available.integration of a messaging solution into the triggerprogram. An electronic signature function enforcesaccountability by tying a database event to a user. Thisis accomp

The primary intent of file integrity monitoring is to detect unauthorized configuration changes. As such, on IBM i the discussion may more appropriately be called simply "integrity monitoring." Operating System Integrity A major concern for audit and security personnel is the risk that a server's operating system will become