PowerTech Releases 2011 “State of IBM i Security” Study

By Robin Tatam, Director of Security Technologies

PowerTech recently unveiled the 2011 edition of its unique “State of IBM i Security” study. Unfortunately, there’s still a lot of room for improvement for the average IBM i shop.

This year’s statistics were aggregated from 243 systems of all shapes and sizes, serving applications to virtually every industry. And, while regulatory compliance is the common driver for many customer conversations, it appears that mandates to secure IBM i servers and data still haven’t been fully realized.

Published annually since 2004, the study highlights six areas of IBM i security configuration:

• System Auditing
• System Security Values
• Powerful User Profiles
• Network Access
• Public Authority
• User and Password Management

PowerTech’s free Compliance Assessment tool is used to collect, analyze, and report on the assessed systems, and a simple opt-in feature allows the data to be shared anonymously with PowerTech. To assess your own server (with or without sharing your findings), request a Compliance Assessment.

Password Management
The average server in this year’s study contained 829 users and 914 libraries, along with more than 300 inactive profiles (those not used in the 30 days preceding the assessment), and 68 profiles with default passwords (the password matches the profile name). With a powerful built-in database, user security is one of the most critical aspects of IBM i security. Large numbers of profiles with default passwords indicate overuse of an unfortunate IBM parameter default setting, and an excessive number of old profiles means there is very little oversight of profile housekeeping.

Powerful User Profiles

Users often are given special authority privileges that far exceed their documented business requirement. It’s unusual to find an IBM i server where base users should be able to access any object (*ALLOBJ), or end the system to a restricted state (*JOBCTL). However, we often see that most servers have an over-abundance of both!

System Security
Security Level 40 (the minimum level recommended by IBM), continues to be the standard on the majority of servers reviewed, but that left almost 60 servers running on a level with known vulnerabilities, including being able to run jobs as another (potentially more powerful) user. With a documented “upgrade” path, and the ability to predict issues before committing, there are few legitimate reasons not to be running at a recommended level. Of course, IBM’s adoption of security level 40 as the current default has contributed to this shift towards compliance.

System Auditing
On a slightly more positive note, we did see an increase in the number of servers that use IBM i built-in auditing. In 2011, the percentage of systems collecting events into the security audit journal (QAUDJRN) was 87%. Of course, evidence suggests that this function is often used primarily to capture system events for high availability solutions, rather than for security. The common lack of commercial forensics capability supports this theory, as it’s difficult to effectively review large event logs manually.

Network Access Control
Surprisingly, almost half of the systems are running without any firewall protection to oversee access from powerful desktop interfaces such as FTP, ODBC, and remote command. In addition to providing a supplemental layer of protection, a commercial-grade exit point firewall is the recommended way to provide visibility to these types of transactions. As a result, there may be a large cross-section of user activity that remains transparent—including executing operating system commands—even on those servers with QAUDJRN actively configured.

Data Access
Public authority to objects and libraries remains very problematic in 2011. Most systems still haven’t been configured to enforce object-level security, instead requiring that a user only needs to provide a valid user profile and password combination. This is a contributing factor to why default passwords represent such significant exposure. The menu-based security model often found in legacy applications broke down with the advent of advanced TCP-based interfaces. Exit point firewalls can mitigate some of the risk associated with little or no object security, but implementing strong object authorities is recommended as the basis of a multi-layered security infrastructure.

This is just a brief overview of the 2011 study. Read the complete white paper here.

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

Q & A with Paulie Culin

Dear Paulie,
Can Compliance Monitor show me when someone creates new user profiles?

A: It sure can. By simply modifying or filtering reports that already exist, you can create just about any report that you might need.

The information you need is contained in at least two existing reports. The first (and fastest) is the (T:CP) User Profile Changes report found in the Log File report group. This report shows the Actions for CHGUSRPRF, CRTUSRPRF, RSTUSRPRF, DST reset of QSECOFR, and QSYRESPA API. With some fast filtering on these Actions, you have the ability to create five different reports!

In your case, you need to filter on the Actions field for CRTUSRPRF. (Depending on the release of Compliance Monitor you have installed, you might need to use wildcards in your filter, such as %CRT%.)

Created profile information also is available in the (T:CO) Created Objects report, located in the Log File report group. Simply filter on the Object Type field with %USRPRF%. (Hint: You can use this same filter on the (T:DO) Deleted Objects report to identify deleted user profiles.)

Once you’ve filtered the report, rename it and save it to your personal report group for future use.

Learn more with PowerTech Webinars and online training.

Request a demo.

PCI Compliance for IBM i—Pt. 2

By Robin Tatam, Director of Security Technologies

Last month, we covered the first six of the twelve PCI requirements. This month, we look at the final six requirements and how the PowerTech products can help you meet them.

Requirement 7. Restrict access to cardholder data by business need-to-know

Limiting data access to users with a proven business need may seem obvious, but IBM i users often have overly-powerful user profiles; and open public access makes private data easy to display and even change.

The first step is to establish role-based access controls. Public access always should be configured as deny-by-default, and authorized users granted authority based on their role. PowerTech Authority Broker allows emergency access when necessary, and handles the auditing and reporting necessary for regulatory compliance.

To restrict access through “open” interfaces, such as such as FTP and ODBC, an exit program solution, such as Network Security, allows you to police network interfaces.

Requirement 8. Assign a unique ID to each person with computer access

To access IBM i functions, users need a user profile and password. To ensure accountability, each user must be uniquely identifiable to the system. PowerTech Authority Broker helps you comply with this requirement by allowing you to grant controlled access to users through “special” user profiles. DataThread lets you monitor and audit database changes. And, Compliance Monitor helps you monitor system values and user profiles for compliance to your security policy.

Requirement 9. Restrict physical access to cardholder data

Companies can spend thousands of dollars to secure their data, but ignore the physical security of their servers. Ensure that sensitive areas have access controls, such as key cards and access logs, and visitors are easily identifiable. Monitor entry doors by video surveillance and keep the data from cameras for at least three months.

You also should determine the sensitivity of the data on your storage media, and have a plan for the safe disposal of information.

Requirement 10. Track and monitor all access to network resources and cardholder data

IBM i integrates security into the operating system, making it easy to start auditing user activities without much configuration using the Change Security Auditing (CHGSECAUD) command.

However, performing a forensic analysis on the collected audit entries can be challenging, as IBM does not provide any reporting or notification tools. PowerTech fills in the missing pieces with its security solutions: Compliance Monitor helps you ensure your systems are configured properly; Interact provides real-time monitoring of changes; Authority Broker audits the activities of powerful users; DataThread provides real-time monitoring of database access down to the record and field level.

Requirement 11. Regularly test security systems and processes

PCI requires that you scan your systems quarterly to ensure that alerts are generated and that failures are taken care of. For IBM i servers on an internal network, testing should include connecting via common data protocols such as FTP and ODBC. PowerTech Network Security provides intrusion detection and prevention capabilities via exit points, and can be implemented in combination with the IBM i IDS capabilities.

Integrity monitoring for critical files also is a key component of this requirement. DataThread database-level monitoring works with the object auditing controls in the operating system to fulfill the requirement.

Requirement 12. Maintain a policy that addresses information security for all personnel

Surprisingly, many security-conscious organizations don’t maintain a security policy for their IBM Power Systems servers. Policies not only define the intended standards, they also provide a measure of how well your processes meet those standards. Even if a policy isn’t perfect, it’s a starting point for performing a compliance review.

PCI compliance requires that you have a policy and that you can prove you are following it. You need to do a thorough review of your security policy standards and determine if you are following its requirements. PowerTech’s security solutions help you comply with these requirements, and prove that compliance.

That concludes our review of the 12 PCI requirements. For a more in-depth discussion of these requirements and how PowerTech can help you meet them, download our white paper, “PCI Compliance for Power Systems Running IBM i.”

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

Security Officer or Security Nightmare?

By Robin Tatam, Director of Security Technologies

Unfortunately, the security officer (and that includes programmers and system administrators) represents the biggest security threat to many shops. Often, regular users are asked to fulfill security roles without any formal training or experience. They’re just the users who “know the most” and so they become responsible for administering security. According to PowerTech’s annual “State of IBM i Security” study, many users carry powerful capabilities without any associated business need.

With most illegal or illicit activities, the perpetrator usually needs a combination of means, opportunity, and motive.

• Means—Security officers and other power users often have advanced skills and knowledge so they can access applications, manipulate data, and configure system controls—including security controls. If there’s a loophole in your security infrastructure, a security officer probably can find it!
• Opportunity—As the most powerful users on the system, security personnel have constant opportunity. Special authorities, such as *ALLOBJ, grant complete, uncontrolled access to every object on the system.
• Motive—A lack of motive is the only saving grace for most organizations. As system guardians, most security officers take their responsibility seriously. But they’re human. We all like to believe that nothing could ever compromise our scruples, but that mortgage payment or college tuition bill isn’t going to pay itself.

Security officers have a professional responsibility to acknowledge that they need to be secured as much as—actually more than—the data entry clerk. Security controls should apply to everyone.

Authority Broker is the best way to ensure a secure environment. It helps you manage your powerful user profiles, including QSECOFR, while allowing key personnel to perform critical tasks. And, it comes with usage controls, notification, timing restrictions, activity tracking, and reporting.

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

Q & A with Paulie Culin

Dear Paulie,
What do I need to know about mirroring PowerTech Network Security 6?

A: Unless the replication is a full system save/restore, you should be aware of the following before mirroring Network Security:

• You must have completed a prior install on the target system to create the following objects: profiles, authorization lists, commands in QGPL, PTWRKMGT subsystem, and unregistered exit points.
• Network Security cannot be active on the target system (exit programs must not be registered).
• The target system must have a valid Network Security license; no grace period is available.

Exclude the following objects from mirroring:

• PLK280SPC2—User space (*USRSPC)
• PLK999U—User space (*USRSPC)
• PLK860DA— Data area (*DTAARA)
• PTCAPJRN—Journal (*JRN) and associated receivers
• CAPJRNnnnn—(*JRNRCV)
• PWRJRN—Journal (*JRN) and associated receivers
• PWRJRNnnnn—(*JRNRCV)
• PNSCAPSUMQ—Data queue (*DTAQ)
• PSSTMS—Data queue (*DTAQ)

Learn more with PowerTech Webinars and online training.

Request a demo.

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.

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.

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.

Robin Tatam

Hopefully, you reviewed and configured your System i server’s system values as part of your security procedures. If not, you should take the time to familiarize yourself with these values to understand how they impact security. With each new release of the operating system, IBM adds more system values (information about how to use these values is available in the Memo To Users and at the online Information Center). And, once these values are set, you must ensure they stay that way. But, manually comparing values is both labor intensive and error prone—there are better approaches.

IBM Lock Down

Starting with V5R2 of the operating system, IBM offered the ability to lock selected system values using System Service Tools (SST). This lock down prevents even the most powerful users from making changes. However, many people won’t use this feature because they aren’t comfortable with the SST interface and they are afraid they won’t be able to unlock these values later.

Compliance Monitor, the leading IBM i audit forensics and report solution from PowerTech, offers two ways to help with this process:

Event Monitoring

If you are auditing *SECURITY events in the audit journal, modifying any system value causes an SV event to be written. Compliance Monitor can report the details of those events, including information about the value change and the user that initiated the change. And, if a value is changed and then returned to its original value, Compliance Monitor registers two separate change events.

Scorecard Analysis

Compliance Monitor’s System Scorecard (see Figure 1) provides a rapid, point-in-time compliance check of key system values against policy. System values are graded using a weighted scale that you can specify to create an overall compliance rating. You can use its Best Practices policy to determine whether a system is well configured and its Policy Editor to customize the policy for special requirements. Compliance Monitor performs its analysis and presents an easy-to-read dashboard report that you can use to prove compliance to auditors, or to highlight policy discrepancies that need to be fixed.

Figure 1: A Sample System Value Scorecard

Compliance Monitor’s unique architecture lets you apply a centralized policy to any number of end point reporting systems, or each end point can have a custom policy. For example, all production partitions could use one central policy, while each Development and Test partition has their own policy. And, international organizations can use different policies based on each country’s requirements and regulations.

Figure 2: Compliance Monitor’s Integrated Policy Editor

You can define system value requirements with flexibility. After you select the system value you want to review (Figure 3), you can specify whether a certain setting is allowed, disallowed, or required. Then, you can define both a severity and the penalty to assess during the analysis if the value becomes non-compliant. Finally, if a system value should not be included in the review, you can select Allow any value and the attribute settings are ignored.

Figure 3: Policy Settings for the QSECURITY System Value

You can export and import policies between systems for easy administration. And, the policy editor lets you access normal system values and other attributes, such as whether changes are allowed to security system values.

Real-time Alerting

If you want to be notified when a system value is modified, you can use PowerTech Interact for real-time alerts of activities, including QAUDJRN events. With Interact, you can communicate with enterprise monitoring solutions, and escalate events to cell phones or using e-mail with powerful tools like Robot/CONSOLE and Robot/ALERT.

Working Together

To keep your system secure and compliant, you need to work with IBM i security controls to set your system values properly and ensure they remain in compliance. PowerTech’s Compliance Monitor and Interact bring together event monitoring, scorecard analysis, and real-time alerts for a complete security compliance solution.