PCI Compliance for IBM i

By Robin Tatam, Director of Security Technologies

Meeting the Payment Card Industry Data Security Standard (PCI DSS) is a fact of life for any organization that processes credit or debit card information. Version 2 of the Standard was released in October 2010, so I thought we’d take a look at PCI compliance on IBM i and how the PowerTech products can help you meet PCI requirements.

The PCI standard consists of 12 main requirements. This month we cover the first six requirements; we’ll complete the set next month.

Requirement 1. Install and maintain a firewall configuration to protect cardholder data

While firewalls have long been regarded as necessary to protect the corporate perimeter, the most recent PowerTech State of IBM i Security study shows that 46% of servers provide no restrictions to internal users.

Exit points allow you to monitor requests that originate through network services such as FTP, DDM, and ODBC. These services provide file transfer, remote data access, and even command entry. As the leading commercial exit program solution, PowerTech Network Security acts as a firewall to the servers’ network openness and provides auditing and user access control through 30-plus network exit points.

Requirement 2. Do not use vendor-supplied defaults for system passwords and other security parameters

In this day and age, changing shipped defaults might seem like an obvious requirement and one that wouldn’t need to be spelled out. However, the 2011 State of IBM i Security study continues to warn us that servers often are left with IBM-shipped default passwords; less than 11% of libraries restrict public access; and almost 95% of new objects allow anyone to view, change, and even delete data.

PowerTech Compliance Monitor can help you comply with this requirement by reporting on hundreds of security metrics, including system values that control passwords and users with default passwords. It helps you identify which systems are in and, more importantly, out of compliance with your published policy.

Requirement 3. Protect stored cardholder data

Data encryption can be an important part of protecting stored cardholder information. You should encrypt all communications to ensure that confidential data is not transmitted to display screens in plain text. You can use IBM-supplied encryption interfaces—which may require extensive application modification—or a commercial encryption solution.

If you are unable to effectively encrypt data (and you can prove your case), the PCI standards allow for “compensating controls.” One example of a compensating control is PowerTech Network Security, which provides access control to database files from the network, and can be highly effective when combined with traditional controls such as object-level security.

Requirement 4. Encrypt transmission of cardholder data across open, public networks

Similar to Requirement 3, encrypting data when it is transported across open networks is a critical part of data protection. You can use technologies, such as secure socket layer (SSL) and Secure Shell (SSH). The PCI DSS 2.0 standard no longer permits the use of Wireless Encryption Protocol, (commonly found in home wireless networks), since it is easily broken. You can encrypt IBM i databases using IBM-supplied encryption interfaces or by using a commercial encryption solution.

Requirement 5. Use and regularly update anti-virus software or programs

IBM i enjoys the envious reputation of being highly virus-“resistant” (no one wants to go out on a limb and guarantee it as virus-“proof”). However, while its object structure makes a traditional viral infection unlikely, there are many other forms of malicious intent.

According to the PCI standard, any server that could be exposed to malware is required to use up-to-date anti-virus software. Despite its unique infrastructure, many PCI Qualified Security Assessors (QSAs) take issue with IBM i not having such software. And, if you use the Integrated File System (IFS) for file storage, it is possible for the server to host any traditional virus.

Requirement 6. Develop and maintain secure systems and applications

Developing and using secure applications is an important aspect of data protection. While IBM i system patches (PTFs) are obtained directly from IBM, many shops run on an unsupported operating system version, and without a policy for applying patches in a timely fashion.

Change control processes are a key component of complying with this requirement, and numerous commercial applications exist to aid the promotion of application programs into a production environment. PCI requires procedures that review application code for coding vulnerabilities and, starting in June 2012, will require a risk ranking for newly discovered security vulnerabilities.

That covers the first six requirements. For a more in-depth discussion of these requirements, download our white paper, “PCI Compliance for Power Systems Running IBM i.” We’ll cover the last six requirements in the April issue. See you then!

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

IBM i Open Source Security Policy Now Available

Part of PowerTech’s mission is to advance awareness of the security challenges faced by companies every day. Because security and compliance issues are constantly evolving, we’ve updated our open source Security Policy for Power Systems running IBM i. The policy includes the elements you need to consider to minimize unauthorized access to proprietary information and technology.

Areas covered in the Security Policy include:

• Physical Security
• Data Recoverability
• Data Access Security
• User Profile Security
• System Configuration
• Network Configuration Settings
• Library Authority
• Auditing
• Plus a list of additional areas you might want to consider.

The Security Policy is available as a PDF file to use as is, and as a Microsoft Word file that you can use a base for defining your own policy. View and download the Security Policy today.

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

Q & A with Paulie Culin

Dear Paulie,
What do I need to know about backing up Network Security 6?

A: When you perform a SAVLIB on the Network Security library, it saves everything except the following files:

• PLKCAP
• PLKCAPCNT

Both of these files are used for captured transactions. So, if the Summarization process is active, the files are not saved because they are open for update.

To perform a full backup, use the Save While Active parameter on the SAVLIB command to back up the entire library.
For example, enter the following command to save the entire library, plus the two captured transaction files:

SAVLIB LIB(PTNSLIB) DEV(TAP01) SAVACT(*LIB) SAVACTWAIT(30) SAVACTMSGQ(QSYSOPR)

Learn more with PowerTech Webinars and online training.

Request a demo.

Come to Las Vegas—but don’t gamble with your security!

By Jill Martin, Product Support Manager

Save the date! Join us in Las Vegas, September 22–23, 2011, for two days of security-related topics, product-related sessions, and the opportunity to talk to experts in IBM i security!

Today, more companies than ever are under pressure to comply with regulations, legislation, and best practice requirements—and they need help. Users often tell us that they want to learn more about the auditing tools that come with IBM i. And, they’re looking for more and better ways to use the products they’ve already invested in.

Here’s how we can help. PowerTech is bringing together a group of industry, product, and security experts for a two-day IBM i Security Conference.

Want to know what PowerTech has been up to lately? Have ideas for future enhancements? This is a great place to talk to the people making these decisions and driving the product line forward.

In addition to two tracks of informative sessions to choose from, you’ll also have the opportunity to sit down, one-on-one, with an expert who’ll answer your questions or walk through the products. You’ll leave knowing how to secure your system, or with tips and techniques to help you in your next audit.

Watch for more information on this upcoming event, including details on how to register. We look forward to seeing you there!

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

Database Monitoring with DataThread

By Paulie Culin, Training and Services Consultant

DataThread, PowerTech’s new database audit and workflow offering, is designed to help you maintain compliance with today’s audit and regulatory requirements. Its unique workflow and notification module help you automate paper and labor-intensive processes in any IBM i environment. And, it does this without any modifications to your applications!

DataThread uses the extensive database management functions of the IBM i DB2 database to detect and capture changes to any database record, retaining only the fields you select.

Here’s a quick overview on how DataThread works.

1. Specify the file and library to watch and the types of changes to track (Change, Delete, Add, Read).



2. Select the fields you want to monitor and specify how each should be tracked (for example, Always or Changes only).
3. Activate the configuration. The DataThread Validation panel displays your configuration.

When DataThread captures changes to the database, you can view them on your system or in a report.

Each DataThread capture contains the following information:

• File
• Library
• Member
• Unique Transaction Number
• Date/Time
• Program Name/Method (ODBC, SQL, DFU)
• Action (Update, Add, Delete, Read)
• User Profile and description (user’s name)
• Electronic signature (if required)
• Signature comment (if required or entered)
• Reason code (user defined, such as APP, REJ, HLD)
• Captured fields (changed values display in red)

You also can add a workflow, such as the following:

• Set record-level conditions
• Set field level conditions, (=, >, <, >10%, <$5000.)
• Notify a person or group
• Send (publish) the capture to a data queue
• Call a program
• Submit a job

You can even require an electronic signature for specific changes.

DataThread helps you meet the most stringent industry requirements. Learn more about DataThread.

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

Compliance Monitor 3—IBM i Auditing for Today

By Robin Tatam, Director of Security Technologies

Audits are a way of life in today’s regulated world. One of the best ways to minimize the impact of an audit is with Compliance Monitor 3, the newest version of the most powerful reporting solution available for IBM i.

Here are some of the new things you’ll find in Compliance Monitor 3:

• A powerful browser-based interface that makes it easy to specify report requirements and to display the collected information.
• An “intelligent” pre-checker utility that helps you verify your server meets the requirements for the new version. You can run the pre-checker in advance so your install (or upgrade from a previous version) proceeds successfully.
• 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, native and IFS object reports, and authority adoption information.
• An automated install process, so you’re up and running faster, and generating reports sooner.

Of course, all the powerful features that previously established Compliance Monitor as the premier audit solution—consolidated reporting across partitions, compliance scorecards, scheduled collections, and powerful filtering and forensic analysis of audit journal events—are still there in Version 3.

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

Q & A with Paulie Culin

Dear Paulie,
I need to run some security-related reports. Do you have any suggestions?

A: IBM i allows you to monitor security-related events. Here are a few tips if you have the proper authority:

1. Look for QAUDJRN in QSYS to make sure that security auditing is enabled on your system. If it doesn’t exist, use the Change Security Auditing (CHGSECAUD) command to set up security auditing. Specify either *DFTSET or *ALL in the Auditing values parameter. Use theCPYAUDJRNE command to extract audit journal entries, and the Display Security Auditing (DSPSECAUD) command to display information on current security auditing values.
2. You’ll need the QSYSMSG message queue to capture critical system messages. The system automatically sends messages to it instead of QSYSOPR, where they often go unnoticed.
3. Use the Security Tools (GO SECTOOLS) to run reports and work with system security settings. The Security Tools menu offers several useful reports that you can run interactively, schedule, or submit to batch.

Of course, these methods can be cumbersome, time-consuming, and difficult to interpret. PowerTech’s Compliance Monitor simplifies security-related reporting.

Learn more with PowerTech Webinars and online training.

Request a demo.

Innovation and Airline Food: 2010 in Review

By Robin Tatam, Director of Security Technologies

For the first PowerNews of 2011, I’d like to step back from our traditional format and share some personal reflections on my year at PowerTech, and on things to come in the New Year.

New: Receive PowerNews in Print!

PowerTech from the Inside

I’m happy to report that, in 2010, PowerTech and Help/Systems continued to focus on customers. We hosted meetings, where we shared glimpses of our future and listened to your feedback on development and other issues. In response to the sessions, we released a great database monitoring solution. Overall, our customers reiterated what we already knew: we aren’t perfect, but we can be proud of our solutions and service.

Product-wise, 2010 brought a major update to our popular Network Security solution, including exciting features like object-level rule support, and a stronger infrastructure design to support future enhancements. As I write, our team is putting the finishing touches on Compliance Monitor 3, and we’ll roll out further enhancements throughout 2011. I can’t wait to see your reaction to these upgrades.

On the training front, we launched several great online classes in 2010, with more options coming in 2011. Watch for a Compliance Monitor class to complement the existing Network Security and Authority Broker classes. For those with a tight budget, this is an inexpensive way to gain expert training.

Life on the Road

Readers of my blog know that my objectives last year often involved boarding passes and suitcases, as I traveled to cities including Seattle, Orlando, Dallas, and New York. For those keeping track, here are some of my 2010 travel statistics:

If the lighthouse didn’t throw you, consider the number of hours I spent with my 6’ 6” frame crammed inside a Boeing 767.

Longest flight: Minneapolis to London, 4,015 miles
Shortest flight: Minneapolis to Chicago, 355 miles

High-Water Marks

I do whatever it takes to reach my customers. Last year, I rode planes, trains, cars, taxis, shuttle buses, untold miles of moving walkway—even an airboat (I’m not kidding!).

I baked in the sun and froze in the snow, though I managed to evade the Metrodome’s collapsing roof.

On my way, I met great customers and took in fantastic sights. I memorialized many of them in landscape photographs that brighten my office and my blog. I hope you enjoy them as much as I enjoy taking them.

Beautiful Las Vegas, Nevada.

A Steady Pulse

For now, I’m home again. I smile when I think back to one year ago, when our competitors were suggesting that PowerTech had no future. In reality, PowerTech’s heartbeat is stronger than ever, as our recent growth illustrates.

It was a great year, but the best is ahead.

Fire up the airboat.

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

7 Habits of Highly Secure Companies: Part III

By Robin Tatam

Please enjoy the final entry in my 7 Habits series. Feel free to go back and review Part I and Part II.

Habit 5: Use Existing Technology

Security companies spend millions of dollars to develop and perfect their solutions, so take advantage of their efforts.

Alternatively, you could hire staff to develop and support your own technology, but auditors frown upon self-policing.

You could also spend hours manually reviewing log entries and events, but automated solutions can notify you of actions. And what about activities the operating system cannot see, such as downloading payroll files via FTP?

In these cases, and many others, commercial security technologies can be extremely helpful. However, you must be sure to deploy them properly, and, in the case of IBM i, leverage your operating system’s built-in security controls.

Habit 6: Monitor Ongoing Compliance

Security isn’t a destination; it’s a journey. But this doesn’t mean you should dawdle. If you manage to elude mandates or regulations, you still have corporate and ethical responsibilities to your clients, customers, and employees.

The easiest way to meet your obligations is to implement and maintain a robust security infrastructure. Ongoing compliance checks help you maintain your high security levels.

Your initial assessment helped shape your security policy and subsequent server configuration; compliance checks should verify that you are doing what your policy states. Find the causes of non-compliant items, and take steps to prevent them from recurring.

In addition to compliance checks, use security tools to stay abreast of important events. Don’t wait until the end of the month to discover you had a non-compliance situation three weeks earlier. A good security solution makes constant analysis less daunting.

The Powertech suite of products.

Habit 7: Plan for the Future

In the tech world, things are never the same tomorrow. Consider the technologies of ten years ago, and the ways in which we secured them.

Since then, we’ve experienced great technological innovation, challenges, and change. Your business must react to change to stay competitive,  and do it while complying with changing standards, laws, and regulations.

Compliance requirements will evolve, but they won’t go away. For example, privacy laws that began in California quickly rolled into forty other states, and a federal law may follow. Always keep your eyes on the horizon.

Master the 7 Habits

By reviewing and mastering the seven habits I’ve presented to you over the past few months, you can become and remain secure, no matter what the future brings.

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

Q & A with Paulie Culin

Dear Paulie,
I upgraded to Network Security version 6 and imported my security rules. How do I remove the old product libraries?

A: First, locate the old product library(s):

WRKOBJ OBJ(POWER*) OBJTYPE(*LIB)

Next, check for any object locks:

WRKOBJLCK OBJ(POWER5XX) OBJTYPE(*LIB)

If there are NO locks, you are OK to delete the old product libraries.

If there are locks, DO NOT DELETE THE OLD LIBRARY.

You may need to activate the new exit programs in Network Security 6. The activation process will recycle the server jobs, release the locks, and allow you to continue.

Learn more with PowerTech Webinars and online training.

Request a demo.

By Oshan Indika

Over the years, users have relied on commands like STRSQL and RUNSQL to provide instant and powerful access to the data on their Power Systems servers. All types of users—from programmers to system administrators to end users—use these commands as their primary interface for extracting and updating data.

However, allowing a user to view, update, and even delete data without control by the normal application, represents a serious system vulnerability. While some might argue that you can control these activities using object authority, it is a huge risk to depend entirely on object security. It’s better to have an in-depth strategy using a layered approach to protect your vital data assets.

The STRSQL Problem
One major issue with the STRSQL command is that there is no record of the SQL string used to read, update, or delete the data. Although the user has the option to save the details of the SQL session, there is no enforcement or log file created, and they can simply exit the session without saving it. If the user journals the data files, you can see the before and after results in the data, but it’s still difficult to get the full picture without the originating SQL statement.

One way to control this is to revoke authority to the STRSQL command object so that no one can run the command from the command line. Then, require users to use a tool, such as Navigator for i, to run their SQL statements. However, you need to ensure that the tool is available only for the people who require it, and that only selected functions are installed, since it provides capabilities beyond SQL.

Taking Control
Any SQL statements run from Navigator for i go through the *SQLSVR (ODBC) exit point, so you can use an exit program, such as PowerTech’s Network Security, to monitor them. That way, you’re in full control of who can run SQL directives against the data, with an audit trail of all user requests.

With PowerTech Network Security you can control a user’s access by:

• Location (TCP/IP information)
• User profile or group profile
• SQL command (PREPARE, EXECUTE, FETCH, and so on)

Network Security also helps you meet compliance standards and regulations (such as PCI and SOX) that require a full event log of network transactions executed against the server. If you have a Security Information and Event Management (SIEM) solution, the transactions can trigger real-time notifications sent in Syslog format using PowerTech Interact.

Beyond Green Screen
PowerTech Network Security can override a user’s authority level to grant them more or less authority. For example, you can take a user profile with *ALLOBJ special authority and override its SQL requests to allow only read access to data. This is impossible using green screen controls.

With solutions, like Network Security from PowerTech, you enjoy full control and documentation of SQL commands, a solid strategy to protect your system and key data, and peace of mind.

Oshan Indika has more than a dozen years of IT experience in enterprise infrastructure management, including system administration on a variety of platforms, (System i [AS/400], Windows, UNIX, Linux, and Solaris); LAN/WAN network administration (frame relay); and security firewalls. He is a Certified Information Systems Security Professional (CISSP) and Certified Information Systems Auditor (CISA). Previously, he held CCNA and MCP certifications in network and systems management.

Learn more with PowerTech Webinars and online training.

Request a demo.

by Robin Tatam, Director of Security Technologies

Habit 3: Assess Current Standing

Last month, we discussed identifying standards for your security infrastructure. The important next step is measuring yourself against them.

The results may startle you the first time, but it is better to discover gaps yourself than leave your system vulnerable.

As you review the findings of your security audit, determine if your server’s security configuration needs to be adjusted, or if the security policy needs to be adapted to better match business requirements.

Don’t Judge Yourself
When considering how to conduct your assessment, know that self-assessment is not as effective as a professional review. An impartial expert can zero in on deficiencies in your policy, whereas your IT staff might not be objective in assessing the controls they design and maintain.

After all, who wants to audit their own work?

Free Resources
PowerTech can get you started quickly, with a free, high-level assessment (see Figure 1) that compares your IBM i server against industry best practices. The process takes about ten minutes, and an IBM i security specialist analyzes the findings with your team.

PowerTech also performs deep-dive assessments to provide detailed information on dozens of security configuration areas. Our customers sometimes use these assessments as a precursor to a formal audit.

Figure 1 – PowerTech Offers Free Compliance Assessments of IBM i Servers

Habit 4: Perform Security Event Logging and Review

According to PowerTech’s annual State of IBM i Security study, almost 20% of IBM i shops still don’t practice event logging (see Figure 2).

This number would likely be higher if we excluded those using system events for High Availability (HA) replication, rather than for security monitoring. This is one of the lowest rates we found since we started keeping records in 2004.

Figure 2 – Systems Using the IBM i Audit Journal

Anticipate Audits
Most regulatory and industry compliance standards require user activities and system events to be logged and stored for subsequent forensic analysis.

The collection of audit data is a built-in function of the operating system; however, you have to configure it.

PowerTech has information resources and security specialists to help you with the activation. After you determine what types of activities should be audited, there are several operating system commands you can use.

Better Save than Sorry
The challenge for most enterprises lies in reviewing large volumes of event log data, which is best handled by a commercial solution.

Even if there is no way to review raw log data (the operating system only includes basic extraction commands), collecting the data lets you load a tool after a security event and review what was collected.

If there is no audit data, no tool can reconstruct it.

You are typically required to plan for event log data retention, and should defer decisions about retention periods to corporate auditors or legal advisors.

Get our full State of IBM i Security study here.

Learn more with PowerTech Webinars and online training.

Request a demo.

Q: How can I use PowerTech Network Security to globally prevent users from updating data via Open Database Connectivity (ODBC)?

Note: Before implementing global rules, run audit reports against the server to make sure you do not prevent necessary access.

A: From the Work with Security by Server screen, locate the SQL server (*SQLSRV) and place UA in the field to Edit User Authorities.  Add your user ID, and set the CAPTURE flag to YES (Cap = Y). Perform an update.

From the Main Menu, select the Work with Captured Transactions option. Then, locate the UPDATE transaction you performed. Place a 1 next to it to MEMORIZE the transaction. This opens the transaction for you to edit.

1.    Change the User to *PUBLIC.
2.    Change the Authority to *REJECT.
3.    Change the Transaction to UPDATE%.

To add users or groups who are exempt from this rule, give them an authority of  *OS400. Also, we recommend that you change the Send Messages option to *YES.

This configuration prevents users from updating data via Open Database Connectivity (ODBC).

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam

Although this article’s title is a play on the name of Stephen R. Covey’s motivational book series, my intent is serious: to highlight important habits companies must consider as part of an overall strategy for first becoming secure, and then compliant. These aren’t the only habits you’ll need, but they are imperative for organizations struggling to get started.

Over the next three months, I will explain what the seven habits mean to your organization and describe how to put them into practice successfully.

Habit 1: Break the Ostrich Syndrome

The first habit to adopt—or break, depending on how you look at it—is to realize and acknowledge that the server is NOT inherently secure.

Before you consider suing IBM for two decades of false advertising, or write to me politely questioning my expertise, realize that I said secure and not securable. The distinction comes from the fact that the server ships from the factory with its security configuration virtually wide-open. To be fair, IBM hasn’t ever claimed that you are going to be secure simply by plugging your server into an AC outlet and turning the power on. It’s staggering how many assessments we perform each year that show critical application data accessible through tools like Microsoft Excel. Or through free or cheap desktop tools connecting through services such as FTP, DDM, or remote command.

Don’t count on old standbys
Also, relying solely on legacy security mechanisms such as command line limitations and applications menus might not offer an appropriate level of security. Whether it’s programmer workload or a lack of IBM i object security knowledge, application developers do not put much thought into the security aspect of their programs. Many commercial application vendors add little value when it comes to securing the data in their application; customers often suffer from a false sense of security when purchasing these products.

Minimizing security risk takes money, time, and expertise. It also requires foresight and honesty. Habit #1 requires us to acknowledge risk so we can decide how to address it.

Habit 2: Develop a Security Policy

In a blog post, I announced that PowerTech security writers were updating our popular open-source security policy. If you don’t have a policy to oversee the numerous security controls and procedures in your environment—both for IBM i and beyond—you stand little chance of being able to maintain a secure configuration for any period of time.

Have you ever wondered why you have to repeat the dreaded task of cleaning out your garage, basement or attic annually? If so, it’s likely you don’t have a policy to control the use and placement of the contents in those locations. The bottom line is that computer servers don’t secure themselves! Even with the best intentions, we are only human and usually become complacent unless we have controls and procedures in place.

Balance is good policy
Consider developing a policy based on industry best practices. From there, customize the policy with an assessment of compliance levels in your environment. This allows you to establish balance between allowing the business to function and establishing the security that prevents it from being abused.

It’s important that the security policy not be designed and implemented only within the IT department. To be successful there needs to be executive sponsorship and management buy-in. This ensures the standards contained within the policy are consistent and enforceable within corporate directives.

Put security in the right hands
A good security policy has multiple layers, often beginning with non-technical corporate directives, general access and use statements, and moving to specific configurations and procedures for the technologies in use. Don’t make the mistake of involving executives in technical decisions—generally, they don’t understand or care. Place the responsibility for interpretation and documentation in the hands of a security officer. Then, have the security administrator set and monitor the configuration to ensure compliance with the security policy.

Your security policy should be a dynamic document with a defined lifespan. This helps guarantee that you remain abreast of changes in your business, your industry, and technology.

Next month, we’ll discuss security assessments and event logging as we continue through the 7 Habits of Highly Secure Organizations.

Learn more with PowerTech Webinars and online training.

Request a demo.

By Robin Tatam

According to PowerTech’s “State of IBM i Security” study, approximately 20% of enterprises don’t perform system, user, or object audits. When you factor in those that capture only a few event types, those that don’t do anything with data once it is captured, and those that use event data for purposes other than security, you end up with a river of events flowing through the cracks, completely unnoticed.

Luckily, PowerTech Compliance Monitor includes centralized compressed storage for audit journal events from multiple partitions.

Why Don’t People Audit?
Why aren’t administrators rushing to take advantage of an operating system with the built-in ability to collect event information? Auditing is the topic of many PowerTech Webinars, as well as a popular subject for presentations at COMMON and regional user groups. I have noticed three main reasons people don’t audit:

1.  Lack of awareness and understanding of auditing functions
Ignorance might be bliss in some aspects of life, but in security auditing, it’s never a good thing. You can’t expect to see anything unless you turn on the function—akin to turning on a flashlight in a dark hallway. Fortunately, the operating system contains a simple command, Change Security Auditing (CHGSECAUD), that performs the heavy lifting. PowerTech can provide the background knowledge to help you configure it to collect data efficiently.

2.  Poor forensics capability
Without a good forensics solution, audit data is just raw data without business benefit. IBM i contains a basic extract command, but you still need to write queries or programs to make much sense of it. Collecting but not reviewing event data is better than not collecting—at least data is there if you need it. But, it is better to have an efficient way to search, filter, and extract entries from the generated audit data.

3.  Insufficient storage space for overwhelming volumes of journal data
Although disk management is not directly related to auditing, anyone who has turned on auditing can testify to what I’m talking about. Large systems can generate gigabytes of data daily. Not only does this make a forensics solution an absolute must, it also requires careful consideration for the DASD units that house the audited data. You can and should be selective about how and what is audited, and you should save audit data frequently for disaster recovery. But, making recent events accessible quickly while consuming less disk space is usually more desirable.

Compliance Monitor Has An Answer
PowerTech, the market leader in security solutions for IBM i, can teach you how to configure the operating system’s auditing controls efficiently. Then, you use Compliance Monitor to address the challenges of reasons number two and three.

One of the advanced features of Compliance Monitor is its ability to harvest audit journal data. You choose the data you want from one or more endpoint partitions based on the audit journal code, then transfer and store the information on a central partition. A built-in scheduler in the graphical reporting console (see Figure 1) allows you to transfer data on a regular schedule on the days and times convenient for your business.

Figure 1: Compliance Monitor lets you specify schedule and event types to harvest and store.

The harvested data is stored on the central partition in compressed form. Imagine keeping 30 days of audit history online in the same amount of disk space previously consumed by just 3 days of data. When you need the data for forensic reporting, Compliance Monitor automatically handles the decompression–you don’t have to worry about locating and manually restoring journal receivers from tape, or transferring immense files using FTP.

Compliance Monitor helps you search, filter, and extract entries from your audited data.

Learn more about Compliance Monitor or request a Free Webinar demo.

Q: We license several PowerTech products and sometimes I have a hard time remembering the various product commands. Can I put them on a menu?

We’ve already created one for you. It’s called the PowerTech Products Menu, and it’s available FREE from our Web site. It has everything you need to access your licensed products, start and end Compliance Monitor system monitors, and display product information.

Just follow the simple steps below and you’re ready to go.  Enjoy!

1. Download the PowerTech Products Menu from our Web site (you must be logged in to the site).
2. Create a save file on the System i using the following command:CRTSAVF QGPL/P1PTUT01
3. FTP the product menu save file to the System i and execute the following command:

RSTLICPGM LICPGM(1PTUT01) DEV(*SAVF) SAVF(QGPL/P1PTUT01)

4. Enter the command GO POWERTECH from a command prompt to display the menu.

PowerTech Product Menu

Paul “Paulie” Culin is a Senior Security Engineer with the PowerTech Group. As a product expert, his role at PowerTech includes managing client training and implementation services, as well as hosting security presentations, Webinars, and product demonstrations. Paul has thirteen years of experience in the security field.

Robin Tatam

It’s interesting to talk to the IBM i community about viruses and anti-virus software. The subject comes up frequently during my travels and it’s an item that I think each enterprise should evaluate. In general, people seem to fall into two groups: either they think it’s pointless based on what they’ve heard about IBM i, or they are completely onboard with the idea and are running anti-virus software on their IBM i systems.

According to Wikipedia, a virus is a form of malware that can copy itself from one computer to another. (There are many types of malware, including Trojan horses, worms, adware and spyware. Most of us are familiar with these.) I prefer my own definition: Any unauthorized code—active or dormant—designed to perform a function that is not part of a company’s official application initiative.

IBM i has long been touted as being impenetrable to viruses. Partly because of its native object structure that prevents executable code from being embedded inside non‑executable objects. For example, you can’t hide program code inside a database, file‑type object. I have heard reports of a virus being technically possible inside IBM i, but they are far from prevalent and are usually dismissed by security officers.

However, there are important exceptions: Traditional library and object structures might not be as susceptible to viruses as a Windows server, but other structures are. For example, the Integrated File System (IFS) can easily contain infected files. Often, client-server type applications such as Lotus Domino, WebSphere, and the Navigator for i, have access to the IFS. And, outside users often use an IBM i disk as a shared network repository. A virus in the IFS is a significant threat—during a viral outbreak, most IBM i servers remain connected to the network which can cause recurring infection.

Some companies scan IBM i network drives from another network server, but this is not a good idea. Trying to remotely scan thousands of IFS objects means a strong chance of poor scanning performance and a significant increase in network bandwidth use (which translates to slower network communication for everyone). Plus, there are increased risks from the shared read/write requirement and the use of a common profile with *ALLOBJ authority.

Bytware, PowerTech’s sister company and the only supplier of a native IBM i anti‑virus solution powered by a commercial-grade scan engine, notes the following about IBM i viruses:

• IBM i is not free from virus threats and can host and spread viruses
• Viruses can be undetected on IBM i and can attack other systems
• Undetected viruses can pass through IBM i mail
• The IFS is the perfect host for viruses

IBM provides exit points to allow a program such as StandGuard Anti‑Virus from Bytware to scan. StandGuard Anti‑Virus:

• Was designed for IBM i, System p, AIX, Linux on x86, and Domino servers
• Is powered by McAfee commercial scanning engine
• Cannot be disabled by viruses
• Has both green screen and GUI interfaces
• Uses IBM i scanning for both on-demand and open/close scanning
• Uses object integrity scanning to protect IBM digital signatures

My advice is to examine how you use your IBM i file structures. If files are written to or read from the IFS, anti-virus protection is critical. If you’re not sure, give Bytware a call at 775-851-2900 and they’ll be happy to help. And don’t forget, anti‑virus software is necessary for some regulation compliance, such as requirement 5 of the Payment Card Industry’s PCI-DSS standards.

There are other types of malicious code threats. Imagine a startup program that performs a PWRDWNSYS command! Even though this might not be considered a “virus”, it would be extremely disruptive to a production environment. Or, what about an unauthorized program registered as a password change validation program that illegally records user passwords as they are set.

With the team of StandGuard Anti-Virus and PowerTech’s Compliance Monitor and Interact, you can make short work of any of these threats. This team can monitor and report any changes to system values, such as QSTRUPPGM or QPWDVLDPGM, before they become a problem. Visit www.bytware.com and www.powertech.com for more information.