I Have All Object Authority And I’m Not Afraid To Use It!

By Robin Tatam, Director of Security Technologies
Lord Acton, a British historian, introduced us to the expression “Power tends to corrupt; absolute power corrupts absolutely!” While the true source of these words of wisdom is sometimes disputed, the gist is simple enough: Being in a position of supreme power or authority often leads to a person abusing that power. That’s certainly how most dictators got started!

When it comes to security on IBM Power Servers running IBM i, a common challenge for many organizations is the number of users with too much power. These users can potentially circumvent application controls, override security restrictions for themselves and others, change critical server configuration settings, and even cover their tracks while they do it.

As you’ll learn in this first part of a two-part article, “All Object” (*ALLOBJ) authority is probably the best known and most feared authority within the IBM i security and auditing community. However, there are many other way that users can exceed their appropriate level of access.

What are we afraid of?

Let’s start by defining what a “powerful” user is. While there’s no textbook definition, for our purposes, it’s any user that meets at least one of the following criteria:

• One or more of eight special authorities (administrator privileges)
• Excessive private authority to critical objects
• Command line privileges through one or more interfaces

This consolidation of authorities is represented in the following table:

If consolidated authority gives a user access beyond their business requirement, there’s an increased risk that they will view, change, or delete data.

In the 2012 PowerTech “State of IBM i Security” study, the servers audited averaged 58 users with *ALLOBJ special authority. This is “root” access with unrestricted authority to every object on the system. Almost as concerning, 119 users had “Job Control” (*JOBCTL) authority, which provides the ability to start and stop jobs and subsystems. On average, a total of 992 users on the servers were audited.

Typically, command line privileges are required to invoke commands that allow data or server access. It’s often argued that there’s only a minimal risk if a user has authority to an object or function, but lacks the access to the commands to access the object or run the function.

One mistake many organizations make is thinking that the only way to enter commands is through the command line on a “green screen.” This is just one of several ways that users can enter commands. Some methods do not even require command line permissions—yes, you read that correctly!

There is also overlap with several system configuration controls, including:

• The security level (QSECURITY) of the server
• The level of *PUBLIC authority to critical objects
• The configuration of a command’s runtime setting for “allow limited users”

During the nine years that PowerTech has tracked statistics, we’ve seen a shift towards servers attaining the minimum recommended security level of 40. (It’s likely that a good portion of those migrations originated from the change made by IBM in the default level on newer servers, but it’s still a good shift.)

Many people are surprised to learn that much of a user’s “hidden” power is not in the form of administrative privileges, but a result of permissive public authority. Unlike other platforms, where no authority granted means no access, IBM i provides users a default authority called *PUBLIC. Problems develop when public authority remains at its shipped default value of *CHANGE, which gives any user the ability to view, change, and delete data.

In every edition of the State of IBM i Security since 2004, permissible public access forces us to include average users in the definition of “powerful” users.

The study also identifies two alarming configuration vulnerabilities regarding public authority:

• Only 21% of libraries on the sampled systems restricted *PUBLIC access. This means that any user can access 79% of libraries and attempt to access the objects inside. If best-practices dictate that the public be given the least amount of access, we are falling far short of this goal.
• Only 4% of newly created objects are restricted from *PUBLIC access. Combine this with the open library authority and it’s obvious that data access is not being controlled.

Many components have to be configured correctly to control powerful users. Next month we’ll explore ways to identify, contain, and audit the activities of these users.

Watch for Part 2 in the May edition of PowerNews.

—————————————————————————————-

Monitor, Capture, and Send Log Events With PowerTech Interact

By Paulie Culin, Senior Security Consultant

In recent years, regulatory initiatives like Sarbanes-Oxley, HIPAA, PCI, and GLBA have placed increased emphasis on the need to monitor and secure sensitive information. For example, The Payment Card Industry (PCI) Data Security Standard dictates one of the most stringent requirements of all—logs must be reviewed daily, and a minimum of three months of logs must be available for analysis.

This has led to the advent of a new class of security solution known as “Security Information and Event Management” (SIEM). Here’s how it works:  SIEM solutions typically use a simple and widely accepted protocol known as syslog to gather data from devices in the network. The syslog sender sends small text messages (often less than 1024 bytes) containing “payload’” that documents a monitored event to a syslog daemon or syslog server. The SIEM solution accepts a feed from the syslog server, and uses “correlation engines” to look for trends and patterns in the payload. (Some even provide event escalation and alerting for incident management and response.)

With a customer base that includes over 98% of the Fortune 500 and an estimated 350,000 systems in service, the IBM i systems house some of the most sensitive information in the world, making interaction with a SIEM solution a critical requirement.

PowerTech Interact lets you monitor, capture, and send over 500 different log events to a SEIM console. (IBM’s ISS Site Protector format is also supported.) Interact offes real-time monitoring of:

• Security Audit Journal (QAUDJRN)
• Critical OS Messages (QSYSMSG or QSYSOPR)
• PowerTech Authority Broker (Privileged User Tracking)
• PowerTech Network Security (FTP, ODBC, Remote Command)

Interact takes the raw event data and converts it into a meaningful format for easy review. Cryptic audit journal details are simplified into plain English statements such as:

“System Value QSECURITY was changed from 40 to 30” or “An invalid password was entered for user profile QSECOFR.”

You don’t need to fill your SIEM solution with unnecessary events. Interact lets you select or omit event notifications based on key characteristics:

• Event Type
• User ID
• IP Address
• Time and Day of Week

With Interact, you’ll enjoy all of the benefits of real-time event notification, while satisfying audit and regulatory requirements.

To learn more about Interact, visit www.powertech.com, or call 800-915-7700 (USA) to speak to a Regional Sales Manager.

—————————————————————————————-

Dear Paulie,
I am configuring a new install of Interact and have entered the correct IP address of our syslog server. I see the monitored events in the PLIEVTMSGQ, but not on the syslog server. What am I doing wrong?

A: IBM acknowledges that a certain API in IBM i does not return the correct IP address. A simple workaround is to reconfigure the Interact syslog server location to use a qualified system name instead of the IP address.

For example:

Syslog server location . . : yoursyslogserver.yourcompany.com

Dear Paulie,
How do I back up Interact?

A: You must stop Interact before backing up the active files. Use the ENDPLIAMON command to end the product. When the monitors complete their shutdown procedures, run the SAVLICPGM command.

After the backup completes, restart the monitors using the command, STRPLIAMON STROPT(*CHKPT). A checkpoint was set at the time of shutdown. When Interact restarts, it should find the checkpoint and begin reporting from there.

Note: Other checkpoints are made while the monitors are running. (The interval between checkpoints is configurable.) Checkpoints allow Interact to go back and find events that occurred while the product was inactive.

—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

The Road To Security Starts with a Compliance Assessment

By Robin Tatam, Director of Security Technologies

New Year. New Budget. It’s the time many companies decide to start a security project. However, there’s often a lack of clear direction regarding the tasks and priorities of securing your IBM i system.

Sometimes, there are known vulnerabilities that clearly need to be mitigated as soon as possible—such as application users running with *ALLOBJ special authority. But, often there isn’t a thorough understanding of what’s wrong with a server’s configuration or what should be addressed first.

One approach to this problem is to hire a security consultant to perform a full audit of the environment and map out the priority of the resolutions. Unfortunately, the number of professionals that truly understand IBM i security is small; the number that you can hire to perform a good quality audit is even smaller. As a result, those professionals typically are very busy and command a premium fee for their services.

Scan Your System Security in Just 10 Minutes

A better option is to start with PowerTech’s Compliance Assessment, a unique tool that can scan an IBM i server in less than 10 minutes and display the results in a dynamic browser-based application. When I contract with customers to perform a deep-dive audit, I always start with this scan so I know something about the environment I’m walking into. It also helps them justify the expense of the full audit.

The assessment runs from a networked PC and requires the Adobe Flash plug-in, Java runtime environment (JRE), and TCP access to your server running IBM i. A PowerTech security consultant helps you interpret the findings. And, you can rerun the assessment multiple times over a 7-day period, against any partitions you like, allowing you to make changes to your setup and test the effect of your changes.

Six Areas of Configuration

The Compliance Assessment reviews six critical areas of configuration, including:

System Security
The most influential components of IBM i configuration are found in a number of system values. The most important ones for security, such as the server’s master security level (QSECURITY), are compared to best practices to ensure you’re building on a solid foundation.

User Access
Users often have access to data through powerful desktop tools like FTP, ODBC, and remote command. IBM included more than 30 hooks (exit points) in the operating system to allow programs to verify the authenticity of requests originating from these tools. We check to see if any programs are being used to provide protection.

User Security
A user profile is the most important control between an end-user and the application data. Correctly configuring and maintaining profiles is critical to ensuring user credentials are not compromised. Reviewing numerous problem areas such as profile inactivity, default passwords, and public accessibility helps ensure those profiles are as strong as they can be.

Public Authority
Users who have permission to use a command line or to run tools like Excel often can access data without going through the approved application. IBM i has a unique authority called *PUBLIC that applies to all users that aren’t explicitly granted or denied access. This section determines if *PUBLIC access to your application libraries has been secured (see Figure 1).

Figure 1: The Public Authority section shows user access to system libraries.

System Auditing
IBM i contains powerful auditing features—once they’re correctly activated. Often this is not the case, or the events being collected are insufficient. Verification of the configuration can provide peace of mind that you have a comprehensive log of events. The assessment also checks if the system has a log reporting tool installed to provide forensic analysis of the logged data.

Admin Rights
A common vulnerability is overly powerful users. Administrative rights—known as special authorities—often are granted to users without business justification. Reviewing the assignment of these authorities can ensure that there are no surprises when someone uses an authority they don’t understand (see Figure 2).

Figure 2: The Admin Rights section shows how may users have special authorities.

After analyzing the results, you can review the recommended steps to remediate the vulnerabilities. Or, simply ask the PowerTech security expert how our comprehensive suite of solutions can help.

The Compliance Assessment is a great starting point for any security project. Isn’t it time you learned the current state of security on your servers?
—————————————————————————————-

Command Access Can Bring Unexpected Consequences

By Robin Tatam, Director of Security Technologies

Does this sound familiar? You recently experienced an “unplanned outage” after an administrator inadvertently issued a PWRDWNSYS command while mentoring a new operator. While the administrator was authorized to perform this type of system task, there certainly was no desire to run it in the middle of the workday with the IBM default of RESTART(*NO)!

Is there a way to enforce restrictions on users who typically are authorized to run commands?

Commands = Power

Commands are objects, and you can grant and revoke authority to them much the same as any application object. Some commands require that the person executing them have certain special authorities. (In the case of the embarrassing PWRDWNSYS command, the user needed *JOBCTL special authority.) Unfortunately, once these requirements are met, the operating system does nothing additional to oversee execution of the command. This means that a user who is authorized to a command has total control of when and how it’s executed.

Control Command Use with Command Security

PowerTech Command Security is a rule-based security solution that’s designed specifically to audit and control commands. To configure Command Security, you start by selecting which commands you want to monitor. Then, specify the conditions under which the command should be controlled. Finally, define the actions to take when those conditions are met. Conditions can be based on a value specified on a command parameter, the name of the requesting user or group profile, the calling program, the requester’s IP address, or a number of other powerful and flexible filters. If a condition is met, Command Security performs the actions you’ve defined. Actions can include overriding a parameter (like the RESTART parameter!), sending a message, or even preventing the command from executing.

While there are endless ways to use Command Security to control the command use on a system, consider the following common, and simple-to-configure, scenarios:

1. Permit security administrators to run the CHGUSRPRF command, but only if they’re listed on a specific “change-allowed” authorization list.
2. Notify the high availability administrator whenever someone creates a new library to determine if it should be a candidate for replication.
3. Prevent any user from deleting an audit journal receiver.
4. Block the use of DFU (STRDFU, UPDDTA) and STRSQL commands on critical files.
5. Prevent programmers from using CRTRPGPGM or CRTCLPGM commands to compile directly into a production library

And last, but certainly not least:

6. Reject a Power Down System command from anyone but QSECOFR, if it’s between the hours of 8 a.m. and 5 p.m., the RESTART parameter is set to *NO, and the command was issued from an interactive command line.

For many companies, managing their most powerful users is a constant struggle. Command Security lets you add an extra level of security to your commands, without preventing critical users from performing their jobs.
—————————————————————————————-

Dear Paulie,
What are libraries @@$PTABPTF, PABPLPTF, and PABPTF0003?

A: These are Authority Broker PTF libraries. Feel free to delete them. If you have performed an upgrade to Authority Broker, you also may find two additional libraries, PL#$PRDUP and PN450TMPF. You can delete these libraries, as well.

Dear Paulie,
How can I omit some of the “noise” from my Authority Broker reports?

A: Do the following to specify what to exclude from your reports:

1. From the Authority Broker main menu, select option 5, Use Authority Broker Configuration Menu
2. Next, select option 10, Work with Programs to be excluded from reports
3. Enter the name of the object/library/object type/user profile that you want to exclude from the audit report.

—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

Remember the IFS!

By Robin Tatam, Director of Security Technologies

Ask any security professional which area of IBM i security is most often ignored and chances are that the unanimous response is a chorus of “the Integrated File System.” Although it’s been around since V3R1, the Integrated File System, or IFS, remains a shrouded mystery that represents significant risk to many IBM i organizations.

One popular misconception is that the IFS is a separate and distinct file structure that was added to store and serve PC files, and if you don’t store PC files on your IBM i system, there’s nothing to worry about. Part of this misconception comes from the fact that when the IFS first appeared, the entire system save (GO SAVE, option 21) procedure was expanded to include an IFS save in addition to saving native objects and DLOs (the original mechanism used to serve PC files.)

The Real IFS

In reality, IFS is the umbrella term for all of the various file systems, including native objects in the /QSYS.lib folder and DLOs in the /QDLS folder. In fact, if you look at the help text for a full system save, you’ll see that an IFS save simply omits the paths to items already saved by traditional save commands. Technically, the entire server can be backed up by saving the IFS (although the Licensed Internal Code can’t restore the operating system if saved in that format).

IFS Security Risks are Real

So, why is there a security risk associated with the IFS? It starts with the fact that you work with the IFS using your normal IBM i credentials. The system interface doesn’t differentiate how a user profile accesses data. If you can sign on to a green screen application, you also can potentially access the IFS. As with network interfaces such as FTP and ODBC, if your native objects are secured using only menu or application-level security, a user may have sufficient object authority to read, change, or delete data; even basic read-only rights allow data to be leaked. This is because IBM i ships with a public authority default of *CHANGE. If your security administrators or application vendors haven’t secured your application objects (and most haven’t), users have unlimited access to the data.

It’s easy to access IFS directories using powerful tools like IBM Navigator for i and Windows Explorer, both of which provide users with the ability to exercise their full IBM i authorities. A user can casually delete a folder in Windows Explorer, only to find out later that it was an application library on the server. Unfortunately, there’s no recycling bin and no undelete for these folders. With permissive public authority and the common over-assignment of All Object (*ALLOBJ) special authority, this is an expensive mistake that can happen in the blink of an eye. If that’s not enough to make you sit up and take notice, be aware that activities that don’t violate the permission levels of an object typically aren’t audited!

Can You Secure the IFS?

Because IFS authority can be complex, time consuming, and prone to over-securing, the IFS often is ignored in a company’s security plan. It’s best if you make changes in manageable phases, and document changes so they can be undone if necessary.

So, what can you do and where do you start? In a recent blog, I said that the best security practices result from the synergy between three components: IBM i controls, PowerTech solutions, and administrator deployment.

IBM i Controls

While it may seem that the “ball was dropped” with IFS security, the reality is that IBM i can protect an object (or “stream file” in IFS terminology) from any user or access method—but only if the authorities are configured correctly. IFS authority is built on a UNIX-type model and uses different terminology. Authority templates used to secure the data rights of native objects including *USE, *CHANGE, and *EXCLUDE are replaced with combinations of read (*R), write (*W), and execute (*X) permissions.

The following table shows a comparison between native IBM i and IFS data authorities.

IBM ships public permission to the base IFS folder (commonly referred to as the “root”) as *RWX. Change this to *RX to prevent users from creating new objects and folder structures in the root. The other IBM-supplied folder structures under the root typically are configured correctly and should not be changed.

The /QSYS.LIB folder structure contains the operating system and user libraries, and is the most sensitive folder in the IFS. Users rarely require access to this structure via the IFS. This is fortunate because they can do extensive damage in a short amount of time. IBM i has a special authorization list, QPWFSERVER, designed to prevent anyone without *ALLOBJ special authority from accessing this critical folder. QPWFSERVER ships with public=*USE. Change this immediately to public=*EXCLUDE. You can grant users who have a business need to access this structure, but lack *ALLOBJ special authority, private authority to the authorization list. File shares should be mapped to specific libraries (or files) to reduce the amount of damage these users can do. Remember, users with *ALLOBJ special authority cannot be restricted from any object—native or IFS.

Add PowerTech Security Solutions

Control User Access: PowerTech’s popular exit point monitoring solution, Network Security, enhances IBM i controls with powerful access and auditing functions. It allows you to observe and restrict activities such as copying, opening, and deleting stream files without the complexity and overhead of maintaining IBM i authorities. You can monitor IFS directories to notify security personnel if users attempt to access files to which they have no authority. And, because this functionality rides on top of the operating system’s authority checks, it’s effective with *ALLOBJ users.

Network Security silently audits all IFS activities. Typically, organizations start using Network Security reports to build a knowledge base of legitimate access before they define access control rules. These rules can be based on the general activity (copy, delete, create), or on the stream file or directory affected. Rules can be for a single user, a group profile, or the IP address of a user’s workstation. You can make the rules as permissive or restrictive as you wish, and gain visibility and control that you can’t attain with IBM i. Network Security also provides security for your native objects by controlling user access through powerful interfaces such as FTP, ODBC/JDBC, and remote command.

Control Command Use: Next, secure the WRKLNK command to control IFS access from a user’s 5250 session. Its public authority default of *USE means that any user with command line permission can access the same structures as the desktop tools mentioned earlier. Other commands allow users to create and change directories, and work with, change, and display authorities. Authorize only the users who need legitimate access to these commands.

PowerTech’s Command Security is the answer to command restriction requirements. It can control how and when any command can be executed. Command Security can evaluate environment conditions and perform actions when a user—including those with *ALLOBJ special authority—invokes a monitored command. Actions include stopping the command from being executed, modifying the command, and sending a notification message. And, it maintains a complete command use audit trail for auditors.

You Can Secure The IFS!

Combining IBM i controls with PowerTech solutions helps close the door on IFS vulnerability. By following a few simple recommendations, IFS security risks disappear. Enhance the security of your IBM server by looking to the most trusted partner in IBM i security: PowerTech.
—————————————————————————————-

Audit Tested & Audit Approved Instant Authority!

By Robin Tatam, Director of Security Technologies

The profile swap is a powerful authority inheritance technique. Introduced by IBM to support TCP/IP services, a profile swap allows a job to change midstream and run under a different profile than the one that started it. For example, when the FTP server starts, its “listener” jobs start and run under the QTCP profile. However, when a user logs in to FTP and issues a request, you want to run the authority check against the user rather than QTCP. To handle this, the operating system switches from the QTCP profile to the logged-in user before executing the request.

To see this support in the operating system, run the Display Job (DSPJOB) command and select option 1. You’ll see the traditional job name, user, and number at the top of the screen, and the “current user profile.” This normally contains the job user, but also indicates when there’s an active profile swap. Programmers should note that the RTVJOBA command was enhanced with the Current User (CURUSER) parameter to retrieve the current active user separately from the original job user. (Unless the job user is to be retrieved regardless of an active swap, I recommend using CURUSER, since this parameter still returns the job user information if there’s no active swap.)

People often ask if a profile swap is the same as adopting authority—a programmatic technique that allows a user to add the authority of an application program object’s owner. Authority adoption provides a temporary elevation of authority, but there are some distinct differences between adoption and a profile swap:

• Authority adoption only works for native object access, not IFS objects. A profile swap works for both native objects and IFS environments.
• Adoption is cumulative for each program called —the default setting allows authorities to accumulate. You can adopt the authority of multiple profiles as additional programs are called.
• Profile swapping releases the authority of the original profile before assigning the authority of the swap profile. This allows you to lower the authority of a user (for example, swap a user with *ALLOBJ special authority to a profile that has read-only rights before they access a function.)
• Adoption never changes who the underlying profile is during the adoption process. In contrast, a profile swap literally changes the user to the target user—almost as if they had signed on. The user assumes run-time attributes beyond authorities, such as a default output queue and command line access.

PowerTech Authority Broker removes the “heavy lifting” associated with profile swaps, and enhances the functionality beyond the API support in the operating system.

Authority Broker users can use preauthorized swap profiles for a temporary authority change. You can run the swap from a command line, or embed it in a program. This makes the swap transparent to end users (think contractors and software vendors). Real-time notifications can advise managers and auditors when users temporarily alter their authority (see Figure 1). And, you can run detailed reports of command line activities after they’re done. Plus, Authority Broker supports segregation of duties, time-restricted switching, tamper-proof logging, and activity exporting.

Authority Broker satisfies regulatory requirements by controlling and auditing profile swaps.

—————————————————————————————-

Dear Paulie,
I would like to have a process to delete old Compliance Monitor assessments and logs from both my Consolidator and Endpoints.

A: You can control the age and number of assessments stored on the Consolidator by following these easy steps:

1. From the Compliance Monitor web interface, right-click on the Consolidator and select Properties.
2. Select the Collection Aging tab and enter the values that best reflect your needs.

All product logs are kept on the Consolidator and are controlled by the collection aging configuration. Therefore, there is nothing to maintain on the Endpoint systems.

Dear Paulie,
Is it possible to see the messages generated for Interact on my IBM i server?

A: You can see the messages that Interact will forward to your enterprise monitor by entering the following command:

DSPMSG MSGQ(PTINTERACT/PLIEVTMSGQ)
—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

Resolve to Take Security Seriously in 2012

By Robin Tatam, Director of Security Technologies

Now that we’ve rolled through another New Year’s celebration, we’ve left behind one of the worst years on record for data breaches. Privacyrights.org, a consumer advocacy organization, reports that 2011 witnessed a staggering 547 breaches involving more than 30 million records. Companies ranged from small non-profits to industry giants such as Bank of America, Sony, and Epsilon. Interestingly, 86 of those breaches (involving almost 120,000 records) involved insiders with some level of legitimate access. With mitigation costs now surpassing an estimated $200 per record breached, we’re talking about some pretty serious money!

With all of the current investment and focus on legislative compliance, how is this still possible? How can huge multi-national companies continue to fall so hard? It’s actually not that hard to understand. In my opinion, too many companies focus on achieving compliance at the expense of security.

Guidelines Are Simply a Beginning

A simple analogy is to think of obtaining your first driver’s license. As young adults, we study a handbook and take a test to verify that we understand and are compliant with the basic laws of the road. But, do we let newly “certified” drivers loose on busy highways with the expectation that they are now perfect drivers and will never get into an accident? Of course not! The guidelines (hopefully) help us avoid making basic mistakes, but there are many other factors to consider.

One flaw in the guidelines is the assumption that everyone else is adhering to the same rules—something that every speed limit sign and red light camera shows isn’t true. Experienced drivers understand that many things aren’t included in the handbook. We have to expect the unexpected, adapt and use learned experiences to read between the lines, and improvise—sometimes with little or no warning—to avoid an unplanned disaster.

The same is true of computer security. Regulations like Sarbanes-Oxley and HIPAA were never meant to intricately detail how to protect your IBM i database from misuse. These two common regulations (and many others) are basic guidelines regarding access to critical business data. Focusing solely on satisfying compliance can be misguided, and might lead an organization to assume they are secure. In 2011, hundreds of new organizations joined the ranks of those that discovered the reality of making this assumption.

Don’t Sacrifice Security for Compliance

Compliance is an important objective, but it shouldn’t be pursued at the expense of a comprehensive security plan. In fact, taking the time to build and implement a solid security infrastructure will make that objective easier to achieve. New business processes and procedures typically will be required by a compliance standard, but the technology aspect of compliance usually is left to interpretation by an auditor who is often unfamiliar with IBM i. It’s critical, therefore, that you don’t rely on compliance directives as the sole guideline to protecting data access.

Using the analogy of new drivers, testing is important to ensure that we understand and acknowledge the basic rules of the road. However, it’s ultimately the focus on learning and employing good driving skills that’s going to have the greatest impact on the likelihood, magnitude, and consequence of an accident.

Make the Commitment Today

Businesses need to get smarter and become more committed to security. They must allocate a budget to assess and mitigate the largest risks and acknowledge that controls probably will be compromised at some point. The goal is to develop a plan to address possible breach scenarios BEFORE you find yourself in the middle of one. The plan should include the deployment of technology for the timely detection and alerting of a problem, and training of employees designated to respond and react. This is not just theoretical—a number of recent breaches involved warning signs that were not responded to correctly. Many employees never receive adequate training on their company’s security tools, leading to a false sense of security by management.

Look at the Big Picture

Don’t secure only the data at rest in the data center; look at the entire data lifecycle. And, expect the unexpected. Many of last year’s breaches involved collecting credit card information from point-of-sale (POS) devices and ATMs. This came from skimming devices, employee theft, and unauthorized replacement devices at retail store cash registers! We cannot control the intent of the criminal element so we have to devise better ways to deter, detect, and respond. Similarly, lost and stolen laptops might be out of your corporate control, but securing the data stored on them isn’t. And, while we might not classify this like a traditional breach, the Ponemon Institute reports that it happens 637,000 times at U.S. airports every year!

For most organizations, corporate budgets have been established for the upcoming year. If yours doesn’t include money for security-related projects, focus on fully leveraging your existing investments and staff resources for now. Ensure that employees are trained and are optimizing their tools. Remember, while we hope that this year is a vast improvement over last, it’s never too early to start planning for next year.

In 2012, let’s start taking security more seriously.
—————————————————————————————-

Generate and Distribute Audit Reports Automatically

By Robin Tatam, Director of Security Technologies

Remember the humorous MasterCard commercials from a few years ago? In my mind, I see one of them going like this:

• State-of-the-art, 64-bit, multi-core Power7 hardware: $225,000
• Highly securable IBM i operating system: $100,000
• Discovering you can generate and distribute audit reports automatically: PRICELESS

This joke probably isn’t too funny to anyone who’s responsible for generating audit reports from IBM i. Despite the server’s incredible security infrastructure, auditing remains primarily a thankless, manual chore. And, let’s face it, any task that’s thankless and manual probably won’t get done. Even with a commercial audit tool, a user must decide what reports to run, and then compile and interpret the results.

A Basic Audit Scenario

A common report request from auditors is for a list of the powerful users on the system. Your first question is likely to be “what is a powerful user?” Unfortunately, there’s no official auditor’s dictionary (wouldn’t that be nice!)—each auditor has different criteria.

Maybe you can omit IBM-supplied profiles, disabled profiles that haven’t signed on for at least 45 days, and any profiles without a password. They’ll ask for each of those reports separately. Then, don’t forget to include the users from all 15 production IBM i partitions, preferably on a single report so it’s easier to process.

Here’s one way to accomplish this task:

Step 1: Run IBM’s user profile report (PRTUSRPRF) to dump the configuration data for ALL defined users. Print a hard copy of the report, or figure out how to use Navigator for i to download it to your PC.

Step 2: Manually review each user profile to see if it meets the auditor’s criteria—and hope you don’t have too many profiles to deal with! Don’t forget special authorities of the sixteen possible group profiles the user might belong to in case any authority is inherited. Oh, and the report doesn’t include the number of days since prior sign-on, so you’ll have to determine what the date was 45 days ago, and check that manually. And, you’ll also have to manually exclude the “known” users from the report each time.

Step 3: Document the name of the users that remain.

Step 4: Return to Step 1 and repeat for the next server.

Step 5: Aggregate the results into a single report (somehow) and distribute it to the auditor (somehow) in a secure manner.

Step 6: Prepare to prove to the auditor that the information hasn’t been tampered with (since you’re likely to be one of those powerful users). Also, expect to be asked for a lot more than one simple report.

This is a fictitious scenario, but it’s not unrealistic. It doesn’t take very long to realize that the process is tedious, time-consuming, and expensive; not to mention error-prone and arguably considered self-policing.

A Basic Audit Scenario (Revised)

Compliance Monitor has the reports you need. Powerful (and modifiable) filters you can apply to the data make child’s play out of creating custom audit reports. And, its assessment scheduling and distribution function allows you to run reports at regular intervals across multiple systems and distribute them on completion.

Let’s take another look at that scenario, now using Compliance Monitor 3:

Step 1: Point and click to select the systems to assess.

Step 2: Point and click to select from the hundreds of available reports.

Step 3: Specify the run schedule (optional) and distribution requirements.

Step 4: Sit back and relax.

You can send the reports automatically via e-mail as individual files, or bundled into a password-protected (and encrypted) zip file. Report files can be editable, or PDFs that are digitally signed to reassure auditors that the information hasn’t been tampered with. If you prefer, you can place the reports in the IFS for the user to access.

Compliance Monitor offers batch scheduling and e-mail distribution of audit reports. (Click to enlarge)

Compliance Monitor eliminates the burden of audit reporting. Its hundreds of report options give visibility to static information, such as user profiles and system values, as well as dynamic events recorded into the security audit journal, QAUDJRN. Priceless—YES!
—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
Some of my Authority Broker reports are blank, even though I know there was activity during the requested time period. What would cause this?

A: Authority Broker records its activities to the security audit journal, QAUDJRN. When you request an Authority Broker activity report, the journal receivers on your system are checked for the entries that correspond to the date and time range specified. If the receivers that contain those entries have been removed from your system, the report will be blank. You’ll need to restore the receiver(s) to get the information you want.

You should consider automating your Authority Broker reports to prevent future problems. Schedule the LEVENTRPT command in a job scheduler, such as Robot/SCHEDULE. Press F4 to display the command prompt panel and complete the command parameters.

Dear Paulie,
How can I determine if the latest version of Compliance Monitor will run on my system?

A: Compliance Monitor Version 3 includes a Windows executable “pre-checker” utility (CM3CHECKER) that determines if your system meets the product’s prerequisites. You can run the pre-checker prior to a new install or an upgrade. The pre-checker uses an installation wizard to send a save file to your system, where you can restore it and run the program. When it completes, it generates a spooled file that identifies any prerequisites you might be missing.

The pre-checker also is available as a separate download from the PowerTech website.
—————————————————————————————-
Learn more with PowerTech Webinars and online training.

Request a demo.

by Robin Tatam, Director of Security Technologies

“When it comes to breaches of security, it’s not a matter of ‘if’ but rather ‘when’.”
—Frank Abagnale

I’ve spoken to many audiences in my security career about how nothing good comes of the mindset that “it’ll never happen to me.” Unfortunately, I was reminded of my own vulnerability recently when I discovered that my beloved road bicycle had been “removed” from my (supposedly) secured underground garage. It’s not just the financial loss; it’s the lost confidence that I have in the security of the garage, and the guarded suspicion with which I now eye the other residents of my fairly small community. Although this type of crime is purely for material or financial gain, it tends to make you question the overall level of security, including your personal safety and that of your family.

I prefer to believe that the vast majority of people are good and honest, and the exceptions are those more driven by greed and selfishness. This personal event served as a good, albeit painful, reminder that it’s naive to assume that people won’t take advantage of a situation from which they might profit. Sometimes that situation might arise from an easy temptation; sometimes from a deliberate and planned act. But, we need to assume that, sooner or later, it will happen to all of us.

Costs of a Security Breach

Data theft typically is harder to detect than traditional theft because stolen data continues to reside on the server it was taken from. The latest PowerTech “State of IBM i Security” study reports that more than 10% of IBM i systems still don’t use the auditing functionality included in the operating system. These companies have zero visibility to security-related events. Many of the others are collecting events—but for purposes other than security forensics; and many have no procedures or training on how to interpret the data they collect. This leaves only a small contingent that is proactively reviewing the logs and knows how to recognize and escalate a critical event.

When a corporate breach occurs, you experience many of the same emotions as in a personal loss. The initial panic of discovery can lead to confusion and, unfortunately, sometimes to blame. This can result in recrimination and even job loss. There are costs associated with the remediation and, according to the renowned Ponemon Institute, these costs now exceed $200 per record breached. If the breach requires disclosure to the affected parties, there’s likely to be an accompanying loss of confidence in the corporate brand and it’s tough to put an exact value on that. Sadly, we don’t put much credence on the costs to prevent, nor the costs to remediate and litigate, until we are in the unenviable position of paying for them.

How a Breach Occurs

A common misconception is that all breaches are initiated from outside the perimeter firewall, and are the result of a user operating with malicious intent.

The reality is that an estimated 60 to 70% of lost, stolen, or damaged data is caused by a user inside the network. After all, if a user profile and password are your primary security control, you probably have a large number of users who are able to access data—and not all via the approved application mechanism. Many data issues are the result of legitimate functions where the user was unaware they were causing an issue; for example, uploading a spreadsheet of data directly to a production file without realizing that the spreadsheet was a filtered view.

You should be aware that your regular business insurance may not cover losses incurred as a result of a data breach; especially if it’s determined that the root cause was inadequate security controls. This forces the organization to shoulder the full burden of the cost, which can run into millions of dollars.

The Best Defense

While no security infrastructure is ever 100% safe, you can remove the IBM i data from residing on the “low hanging branch” and make it more viable for someone to pick a different target. A defense-in-layers approach makes it easier to detect and shut down events before they cause serious harm. This can include object-level security, network exit programs, application controls, and alerting and reporting tools. The more layers you deploy, the more you increase the likelihood that you will prevent—or at least detect—unauthorized activity before an unauthorized user gets at, or away with, the asset. Sure, it’s not free to implement a good security infrastructure, but I think it’s safe to say that, in the long run, it’s cheaper that the alternative.

We acknowledge:
It WILL happen to us eventually.

Oh, and if you’re wondering “Who is Frank Abagnale?,” you can see a dramatization of his life in the 2002 movie “Catch Me If You Can,” starring Leonardo DiCaprio and Tom Hanks. His life as a confidence trickster led to him becoming one of the world’s authorities on fraud.
—————————————————————————————-

IBM i Solution Edition for Help/Systems

Purchase any software solution from Help/Systems (Robot Automated Operations Solution); PowerTech (IBM i security solutions); SEQUEL Software (data access/analysis and productivity software); Bytware (anti-virus and monitoring solutions for IBM i) and enjoy big discounts on training, services, and IBM POWER7 systems.

For details, contact your local IBM Business Partner, or Doug Fulmer at dougfulmer@helpsystems.com, or visit our IBM i Solution Edition web page.
—————————————————————————————-

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam, Director of Security Technologies

A Compliance Monitor batch assessment is the same as any other assessment, but it doesn’t require human intervention to run, or to distribute the resulting reports. We’ll show you how easy it is to set up your batch assessments so they run at regularly scheduled times.

1. Sign in to Compliance Monitor using the user profile under which you want your batch assessment to run.
2. Right-click the Consolidator and select Batch Assessments/Reporting.
3. On the Batch Assessments and Report Distribution window, click New to define a new batch assessment. To create a new batch assessment definition from an existing definition, select the assessment name and click Copy. You also can edit an existing batch definition; just double-click the assessment name, or select the assessment and click Edit.

Defining a Batch Assessment
You can define a batch assessment by following these four simple steps:

Step 1: Batch Report Information
Enter a name and description for the assessment. Specify a scheduling option: Not Scheduled (the assessment will be started manually); Use the Consolidator’s internal scheduler; or Use Robot/SCHEDULE (Robot/SCHEDULE must be installed on the Consolidator system).

Step 2: Systems to collect data
Select the Endpoint systems from which to collect data when the batch assessment runs. Click Add Selected to add the selected endpoints to the assessment.

Step 3: Select the reports for this assessment
Select the reports to include in the batch assessment. Selecting a report category (instead of individual reports) allows you to add or remove reports from the category without having to modify the batch assessment definition. The batch assessment runs the reports in the report category at the time the assessment runs.

If your report selection includes object-based reports, you specify object limits using the Object Limits tab. The Consolidator default is preconfigured for some common object types; you can define a new filter to limit the assessment to the objects required by your reports.

If your report selection includes log file reports, you must specify log file criteria using the Log File Options tab. You can limit the assessment by source and the date range of the log file data.

Step 4: Batch Report Output
Specify how to handle the completed reports from the batch assessment. You can store reports as separate files, or combined into a single .zip file, which can be secured with an optional password. You also can specify the format of the files.

Compliance Monitor can e-mail the reports to selected recipients or place them in the IFS.

Click Next to specify access control settings for the batch assessment. Then, click Finish to save the batch assessment definition.

Running Your Batch Assessment
You can run a batch assessment manually to check if it is defined correctly by clicking Run Now on the Batch Assessments and Report Distribution window. This overrides any schedule that is defined for the assessment.

To view the run history (including diagnostics) of a batch assessment, select the batch name on the Batch Assessments and Report Distribution window and click History. To view the run history of all batch assessments, click Show.

—————————————————————————————-

IBM i Solution Edition for Help/Systems

Purchase any software solution from Help/Systems (Robot Automated Operations Solution); PowerTech (IBM i security solutions); SEQUEL Software (data access/analysis and productivity software); Bytware (anti-virus and monitoring solutions for IBM i) and enjoy big discounts on training, services, and IBM POWER7 systems.

For details, contact your local IBM Business Partner, or Doug Fulmer at dougfulmer@helpsystems.com, or visit our IBM i Solution Edition web page.

—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
I’m cleaning up my system and would like to delete an old Network Security product library. Will this create any problems?

A: Before deleting the library, you first must determine if any of the objects in the library are still in use. You can check for object locks by using the WRKOBJLCK command against the library.

WRKOBJLCK OBJ(library_name) OBJTYPE(*LIB)

If no locks are found, you can delete the library. If the WRKOBJLCK command finds jobs with a lock, do not delete anything. Call PowerTech technical support for further assistance.

Dear Paulie,
How can I autostart Compliance Monitor after an IPL?

A: Simply add the STRPTCMCSL command to QSTRUP. Keep in mind that the endpoint monitors start on their own once they receive a request.

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam, Director of Security Technologies

On September 22 and 23, almost 70 IBM i security professionals converged on the Rio All-Suite Hotel and Casino in Las Vegas for the 2011 IBM i Security Event of the Year. The conference brought together a veritable “Who’s Who” of guest speakers, with years of combined security experience on the platform. Speakers included John Earl of Townsend Security, Patrick Botz of Botz & Associates, and Jeff Uehling of IBM. Tom Garcia, founder and CEO of InfoSight, gave an alarming keynote speech on Security in a Web 2.0 World.

One highlight of the event was a presentation by ethical “hacker” Sabino Marquez on social engineering. He showed attendees a number of eye-opening ways that private data can be compromised without any real technical breach.

Other sessions of interest included an Introduction to IBM i Security, Biometric Authentication, Security Best Practices, and Encryption. We also held a series of sessions on the PowerTech product line to help participants become more familiar with our auditing and security solutions. An Ask-the-Experts panel gave attendees the opportunity to discuss their security concerns with all the speakers at once.

Of course, we also made time for some fun and prizes at an evening reception, and with a conference-wide Great Security Mystery game, a variation of the game of “Clue” with an IBM i security theme.

Altogether, the Security Event was a great success and we truly enjoyed meeting and talking with all the participants.

—————————————————————————————-

Beware of Skimming—It’s Closer Than You Think

By Robin Tatam, Director of Security Technologies

If you’ve been following security news this year, you’re probably familiar with the methods that thieves use to steal information. One of the most frightening techniques is “skimming,” the act of collecting credit card data as the card is swiped through a magnetic reader. This means that criminals are intercepting credit and debit card transactions long before the data is able to be secured in the database.

One method used by skimmers is a concealed physical modification to an ATM or point of sale (POS) device. Despite the use of PCI-approved POS devices, these devices have been brazenly swapped out with compromised devices that then pass the card number and PIN information to a nearby perpetrator.

The technology has advanced to where even a diligent employee or consumer is sometimes unable to detect its presence. Keyboard overlays may even supply the associated PIN number over a Bluetooth connection. Sadly, this means that you could very well be the unwitting victim of credit card fraud even before the ATM has had time to dispense your cash.

Anyone Can Be A Target
Often, it’s the smaller retailers who are the targets for this type of attack. One reason might be that they typically have fewer staff, making it an easy task to distract those that are working. Unattended checkout lanes allow an accomplice to move in and tamper with a POS device. No amount of database and server technology can prevent this form of social engineering attack. Even in countries that have migrated toward chip-based cards and readers, thieves have been known to disable the chip-reading sensor, forcing the card owner to swipe the card on the device.

A recent case in the news here in Minnesota illustrates another strategy. It involved a 16-year-old girl who was stealing credit card information from customers who used the drive-thru window at the local McDonald’s where she worked. She hid the skimming device behind the window and copied the information when the customers handed her their card. The thefts weren’t discovered until customers began noticing unauthorized charges to their accounts.

How Do You Defend Against Skimming?
Analyzing card use may be the best way to detect this type of crime, but that means card issuers are forced to work in a reactive mode. One thing is certain: the increasing frequency and sophistication of these types of attacks are going to have card issuers working hard to develop more sophisticated prevention and detection measures.

So, how do you defend yourself against skimming attacks? The best defense is still to be aware of the practice and pay attention when you use your debit or credit card. Look carefully at the ATM or POS device and if something doesn’t seem right, walk away. It’s better to be cautious than be the victim of theft.

—————————————————————————————-

IBM i Solution Edition for Help/Systems

Purchase any software solution from Help/Systems (Robot Automated Operations Solution); PowerTech (IBM i security solutions); SEQUEL Software (data access/analysis and productivity software); Bytware (anti-virus and monitoring solutions for IBM i) and enjoy big discounts on training, services, and IBM POWER7 systems.

For details, contact your local IBM Business Partner, or Doug Fulmer at dougfulmer@helpsystems.com, or visit our IBM i Solution Edition web page.

—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
Before we run a Compliance Assessment, we’d like to know what it creates on our system and how we can remove it when finished??

A: The PowerTech Compliance Assessment installs and runs directly from a PC. The executable program creates a PowerTech program group on your PC and FTPs the product to your system, where it runs the assessment and opens the results in a web browser. The product does not change any system values or attributes.

The Compliance Assessment creates the following objects at install:

To remove the objects, simply enter the Delete Licensed Program (DLTLICPGM) command for product 1PTCA01

Learn more with PowerTech Webinars and online training.

Request a demo.

PowerTech announces the addition of batch scheduling and automated report distribution to Compliance Monitor, its popular security auditing solution.

Compliance Monitor is the premier IBM i audit solution, providing consolidated reporting across partitions, compliance scorecards, powerful filtering, and forensic analysis of audit journal events. The addition of batch scheduling gives you the option to run audit reports at off-peak hours to avoid interfering with production systems. Plus, automated audit report distribution ensures managers have the reports they want to see when they arrive at work.

Batch scheduling joins the valuable features already part of Compliance Monitor 3, including:

• A powerful browser-based interface that makes it easy to specify report requirements and display the collected information.
• Several new reports, including a predefined report category designed to help gaming organizations comply with Nevada’s Minimum Internal Control Standards (MICS). Other new reports cover security system values added in IBM i 6.1 and 7.1, native and IFS object reports, and authority adoption information.
• An “intelligent” pre-checker utility that can verify the server meets the requirements for installation.
• An automated install process so you can start auditing your system sooner.

Learn more about Compliance Monitor 3.

—————————————————————————————-

When Good Guys Turn Bad

By Robin Tatam, Director of Security Technologies

I frequently preach to security audiences about the dangers of “insider threat,” and I think it’s something that can’t be emphasized enough.

While many organizations assume that a breach of their perimeter defenses represents the greatest risk, studies show that the majority of data that’s lost, stolen, or damaged, happens as a result of an authorized user operating inside the firewall. On IBM i, this can be attributed partly to the fact that many organizations base their security on the legacy model of menus and command line restrictions. Unfortunately, with IBM i support of powerful TCP/IP services, a user isn’t always presented with a menu or restricted from executing commands. A user simply has to supply a user profile and password—something that most users are given as soon as they’re hired—to gain full access to the data assets. Each year, our “State of IBM i Security” study shows that many companies use easily decipherable user profile naming conventions and require only simple passwords. Too often, administrators leave doors to their systems open by allowing numerous enabled profiles with default passwords.

While we might acknowledge the possibility of an application user exceeding their authority to access restricted data, or using authorized data in an unapproved way (for example, downloading information to a USB device), what happens when a trusted IT employee goes rogue?

Dealing With Rogue Employees Isn’t Always Easy
A recent article by Tam Harbert in Computerworld magazine, “When Trusted IT Pros Go Bad,” gave some shocking real-world examples that illustrate how the most dangerous users in any environment are those with powerful access and the knowledge to use it. When a user holds a position of trust, it can be that much more difficult to identify and remedy the situation.

The article highlighted the challenges faced by some employers when they were unable to simply fire an employee who possessed the virtual keys to the kingdom. One company went as far as concocting a ruse to send a rogue employee on an urgent cross-country flight! This provided a window of several hours for other staff to change passwords and secure the IT assets he had administrator access to. Such extreme measures became necessary after it came to light that the employee owned a company that had sold more than a half-million dollars in pirated software to his employer.

Another company made the mistake of incorrectly handling the firing of an extremely powerful employee after they discovered evidence of various illegal activities. While the employee’s manager and a security guard hurried to his office, a human resources representative called the employee to tell him to stay put. Unfortunately, suspecting he had been discovered, the employee had time to delete an encryption key ring. This ring contained the only copies of encryption keys for about 25 employees in the legal and contract departments. (The article pointed out the irony in that many companies don’t back up this type of information due to its sensitive nature!) This had the effect of permanently encrypting the data and amounted to an estimated 18 person-years of lost productivity.

Corporate embarrassment can be an additional challenge posed by rogue employees. Companies prefer not to shine a spotlight on the fact that their controls were breached by one of their own. Take the case of the system administrator who brought down a Fortune 500 company with “logic bombs” designed to cause entire banks of servers to crash. Originally a star performer in the IT department, the employee was granted immunity from prosecution in return for her help in fixing the issue, and also with the agreement to never speak publicly about the incident. According to Larry Ponemon, a renowned security researcher, the company didn’t want her “going on Oprah and talking about how she broke the backbone of a Fortune 500 company.”

What Motivates a Rogue Employee?
The motivation for any employee to turn rogue typically falls into one of two categories: financial gain and revenge. When that user operates within the “circle of trust,” it can be difficult to detect illegal activities as they often have greater access and can cover their tracks. Examples of employees seeking financial gain include hacking ATMs to dispense cash but not record the transaction (Bank of America), and stealing valuable computer code (Goldman Sachs). Revenge usually manifests itself in internal damage to the infrastructure or data assets. Attacks in recent years have included code set to destroy data on nearly 5,000 servers (Fannie Mae), and a disgruntled worker who included logic that affected 1,000 computers and caused about $3 million in damages (UBS PaineWebber).

It’s unlikely you’ll ever be able to totally eradicate the risk of malicious intent by powerful and trusted internal users, but you can implement strong controls to ensure that these people are treated with the same caution as any other user. People are human, and a powerful title does not (or rather should not) place someone above reproach or suspicion. That’s certainly a lesson that corporate America has learned the hard way during recent years!

Control Powerful Users With Authority Broker
PowerTech Authority Broker can help you control and manage powerful profiles on IBM i systems. By reclaiming the excessive power and freedom that these administrator-class users often enjoy, and by providing an audit trail of their activities, it becomes easier to build in the necessary safeguards to ensure that you are not the next victim of one of these horror stories.

Editor’s Note: Robin often blogs about the latest security breaches in the news. Follow his blog for his thought-provoking look at the state of security in companies today. He usually includes some pretty cool photos, too.

—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
Can I save my report with custom filters in Compliance Monitor, and run it again?

A: Yes! Compliance Monitor is very flexible and allows you to save your custom filters, columns, and sort criteria so you can use them again and again.

The easiest way to get started is to select an assessment that is available through Compliance Monitor. First, run the assessment and, when the report is ready for viewing, open the completed report in the Compliance Monitor browser. Use the Columns/Sorting tab to add or remove columns in the report, and adjust the Sort by options to determine the first, second, or even third level of sorting. Next, use the Filters tab to display the default filters available for this report. You also can create a new filter or copy existing filters to further customize your report.

Once you’ve selected the columns and sort criteria and added your filters, the report displays with your changes. When you close the report, you’ll be prompted to save your changes with a custom name in a custom report group. After you’ve saved your changes, you can request your new custom report to run in the future or schedule it using the new Batch Assessments/Reporting feature of Compliance Monitor 3.

Learn more with PowerTech Webinars and online training.

Request a demo.

PowerTech Releases Command Security

The newest member of the PowerTech line of security products is Command Security, a rule-based security solution that lets you audit and control selected commands.

With Command Security, you can prevent unauthorized users from executing a monitored command, allow only authorized users to execute certain commands, control the situations when a command is allowed, and monitor and secure commands used by other applications.

Plus, Command Security records monitored command use in a secure journal and provides a complete audit trail to meet government legislation and industry regulations.

“Not all commands have the potential for misuse,” says Robin Tatam, PowerTech Director of Security Technologies. “Command Security gives users the flexibility to control just the commands and situations that could compromise system data or security. Plus, it works with almost any IBM i command and can control commands in third-party applications. It’s a great addition to the PowerTech security suite.”

For more information on commands and how Command Security helps you control their use, see “Commands Never Die!” below.

—————————————————————————————-

Commands Never Die! Stay in Command of Your Command Line

By Oshan Indika, Security Consultant, CISSP, CISA

From its earliest days, the primary means of interaction with a computer has been through a command line. Everything was text based and application programs used menu systems for navigation.

Starting in the early ’90s, many operating systems transitioned to a graphical user interface (GUI). But, surprisingly, the command line has survived—especially among power users, administrators, and geeks (like me). Although great strides have been made on the GUI front, there’s still a unique role for the command line in IT.

When it comes to IBM i, the command line hasn’t changed over the years and still plays an important role, maybe more than in other operating systems. IBM has done a great job in improving the GUI capabilities of the OS. However, power users, developers, and administrators still consider the command line their primary mode of interaction with the system. The reason for this popularity may be due to some easy-to-use features:

• Prompting: You can prompt all commands directly from the command line to display its parameters.
• Command Help: Context-sensitive help is available on all IBM i commands.
• Ease of finding commands: The commands use standardized abbreviations, making them easy to find quickly. For example, change is CHG, display is DSP, program is PGM, user is USR, and so on. If you want to see all verb (such as CHG) or subject (such as USR) commands, go to the respective menus by entering GO VERB or GO SUBJECT. In addition, for each abbreviation there is a corresponding menu that starts with the letters CMD. So, for example, to see all DSP commands, simply run the command GO CMDDSP. This is one of my favorite ways of browsing commands on the system.

Commands = Power
The ease of use of command line access also gives the user a lot of power. Coupled with a higher authority level, a user with command line access can do almost anything on the system. Some commands (like DSPMSG) are harmless, but others can change security configurations (like CHGSYSVAL) or create/modify/delete user profiles (like WRKUSRPRF). To reduce the risk of users running powerful commands, system administrators often remove the ability to run commands by setting the Limit capabilities parameter in the user profile to *YES.

Although this stops users from running commands from a workstation session, there are other ways to run a command. Two of the most commonly used access methods are Remote Command and FTP. For Remote Command, you must have IBM System i Access for Windows installed on your PC. In many environments, it’s installed by default. And, FTP clients are found in almost any operating system.

These remote command capabilities add another layer of complexity to command access. From a security viewpoint, it’s important to monitor which commands are executed on the system, regardless of where they were entered. You should at least monitor commands with the potential to alter or delete data and system configurations.

Auditing Isn’t the Full Solution
One way to track the commands being run by users is to turn on command auditing for specific user profiles using the Change User Auditing command:

CHGUSRAUD USRPRF(OSHAN) AUDLVL(*CMD)

When auditing is on, the operating system writes a CD entry in the system audit journal (QAUDJRN) whenever the specified user executes a command.

There are two important things missing in this solution. First, you won’t know immediately when a user enters a command that could impact the whole system; you’ll only know the next time you run the audit report. Second, there’s no way to control which commands a user can and cannot run.

Control Command Use with Command Security
The best way to control commands is to use PowerTech Command Security. Using Command Security, you identify which commands you want to monitor, specify the conditions under which the command should be secured, and define the actions to take when the conditions are met.

With Command Security, you can:

• Allow the command to execute as it was entered.
• Prevent the command from being executed.
• Notify an administrator when the command is issued.
• Modify the command in a predefined way (from substituting command keywords to replacing the entire command).

There’s no doubt that the need to run commands will remain one of the most important aspects of maintaining a system in the foreseeable future. It’s also important to allow users to run commands in a controlled manner, without jeopardizing the integrity of the system. With Command Security, you remain in total command of your command line.

—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
Can I transfer SecurityAudit from one system to another for D/R testing?

A: Yes. However, because the system name and license information is hard coded in the product, you’ll need keys specific to the new machine or partition. You also must run a special command before re-licensing.

Make sure the SecurityAudit product library is in your library list. Enter the LUPDSYSSA command and press F4 to display the command prompt. Enter the System name, Serial# and LPAR ID, and specify Yes (Y) for Recreate License objects. Press Enter.

When the SecurityAudit Main Menu displays, select option 61. Then, select option 4 on the Administration menu to enter the new license code.

Q: Dear Paulie,
How can I monitor a specific user’s commands?

A: You can audit the commands entered by a specific user using the Change User Auditing (CHGUSRAUD) command. Specify the user profile to audit and *CMD for the AUDLVL parameter. Once you start auditing, Compliance Monitor, SecurityAudit, and Interact can provide visibility to the user’s commands by using the CD audit entries in the audit journal.

Note: An easier way to monitor and control user commands is to use PowerTech’s new Command Security. See the articles in this issue for more information.

Learn more with PowerTech Webinars and online training.

Request a demo.

Help/Systems Completes Acquisition of DataThread

On June 3, Help/Systems, the world’s leader in systems management solutions, announced the acquisition of DataThread high-performance database monitoring software from Innovatum. PowerTech, a Help/Systems company, has offered DataThread since 2010 as an addition to its suite of IBM i security products. The acquisition of DataThread offers users another level of security monitoring as part of the PowerTech product line.

DataThread allows you to automate and centralize your IBM i database access and activity monitoring, while providing real-time notification, authorization, reporting, and regulatory compliance capabilities. DataThread’s auditing capabilities help you meet the stringent compliance regulations required by PCI, Sarbanes-Oxley, HIPAA, FDA, and other domestic and international regulations.

“Adding DataThread to the PowerTech product line is very exciting,” said Jim Cassens, Help/Systems Director of Business Development. “It reinforces Help/Systems’ commitment to bringing world-class solutions to the security and compliance market space. It also helps “super-charge” the PowerTech line for growth by adding another solution that’s in high demand by customers who need to satisfy compliance regulations.”

“DataThread is a perfect fit for PowerTech,” added Robin Tatam, PowerTech Director of Security Technologies. “It complements the PowerTech product line to provide a seamless security solution. DataThread is a solid product and we will continue to invest in development to make it an even greater asset for users of the PowerTech security products.”

—————————————————————————————-

Using a Custom Journal for Network Security Audit Entries

By Jill Martin, Product Support Manager

Have you ever wondered what happens to all the events that are logged through the exit points that Network Security monitors? Have you ever tried to pull events from QAUDJRN, just to have it get bogged down by all the other entries stored there? Did you know that you have options?

Network Security comes configured to monitor all traffic through your exit points to a secure audit journal (QAUDJRN by default). What we often find is that users new to Network Security—or even those who have been using it for awhile—may be collecting a lot of data, but aren’t managing that data very efficiently.

Evaluate Your Audited Events
PowerTech made the decision long ago to send event history to a secure repository and store audited events in the system audit journal, QAUDJRN. This works great when you are first getting started with Network Security and aren’t sure what types of events you need to collect and store. Plus, you probably already have a practice in place for cleanup. But, once you have a feel for what is happening on your system, you (or your auditors) might have some different recommendations for how long to keep the exit point data. And, these requirements could differ from the requirements for the other types of entries stored in QAUDJRN (such as system events or traffic related to your high availability software).

Define a Custom Journal

The good news is that changing where this information is stored is a simple three-step process:

1. Identify a new journal to use for the Network Security entries. If you don’t already have a journal defined, create a new journal receiver.

Create a journal receiver for Network Security.

2. Define a new journal specifically for Network Security. You also should define a process for saving and deleting your journal receivers to clean up the entries.

Define a journal for Network Security events.

3. After you’ve created the new journal, use the Network Security Configuration Menu and Work with the System Values screen to change the Log Journal Name and Library to the new journal.

Change the system value to point to the new journal.

Going forward, all reports will pull the Network Security entries from the new journal receivers. Note: If you have entries that previously were logged into QAUDJRN, you may want to request reports over your existing data before changing the system value.

Report on Network Security Events
Network Security can feed events to Interact in real time, or allow Compliance Monitor to print reports over Network Security traffic. These events come from the journal you specified in Network Security and the products continue to interface with the new journal in place. Note: Compliance Monitor reports show only data from the journal currently configured in Network Security.

Once you’ve separated Network Security entries from QAUDJRN, you can manage the archive process independently and improve your report performance because they no longer need to parse through all your other journal entries.

—————————————————————————————-

Register for the IBM i Security Event of the Year

Early Bird Special Expires Soon—Don’t Miss Out!

Have you registered yet for the 2011 IBM i Security Event of the Year? The last date to receive the Early Bird price of $500 is July 29. Don’t miss out on this exciting event—or the great price for registering early. Get more information and register now!

—————————————————————————————-

Q & A with Paulie Culin

Dear Paulie,
What are the system requirements for Compliance Monitor 3.01?

A: A system running the Compliance Monitor 3.01 Consolidator requires the following:

• IBM i (i5/OS, OS/400) version V5R4 or higher
• Java 1.6 32-bit (required minimum)
• 256 MB of disk space
• IBM i V5R4: PTF Group SF99291 (level 18 or greater) installed
• IBM i V6R1: PTF Group SF99562 (level 6 or greater) installed

A pre-checker utility, CM3CHECKER, helps you identify any prerequisites that you are missing. You can download CM3CHECKER separately to make sure your system is ready.

Dear Paulie,
Can I upgrade my existing 2x version of Compliance Monitor to version 3.01?

A: Absolutely! Before you start, run the pre-checker, CM3CHECKER, and back up the Compliance Monitor 2 Consolidator library (PTCMT2) as part of a full system save or using the following command:

SAVLICPGM LICPGM(1PLCMT2) DEV(*SAVF) SAVF(QGPL/CM2BACKUP)

The upgrade process is completely automated. Simply download the Compliance Monitor 3.0 Installer to your PC and follow the install instructions. Once the upgrade completes, your Compliance Monitor 2 users, reports, and groups are available.

Learn more with PowerTech Webinars and online training.

Request a demo.