Admin Alert: Things to Think About in a Power i Development Environment

Working in both public and private companies during my career, I’ve been subjected to my share of IT audits. My impression is that while auditors are usually very savvy about your production environment, there are other issues that maybe they should be looking at but don’t. If your production environment is in tip-top shape, audit-wise, here are some other things you might consider looking at to avoid trouble.

Why Aren’t Auditors More Interested in Development Environment Infrastructure?

Not to give anyone ideas, but I’ve always wondered why auditors don’t investigate development environments as seriously as they audit production environments. After all, a sloppy development environment can create all kinds of issues, such as:

• Unintentional and (possibly) intentional access to recent production data and production-like output
• Data damage that occurs due to confusion as to whether a user is on the production or the test environment
• Producing look-alike production output and sending it to live users and customers

Here are some fairly common security-breach situations that can occur with a poorly designed test environment.

Data Issues

My experience is that it’s fairly common practice to refresh a development environment with data from a production system backup tape. After all, how better to test a planned software change than with actual production data? Development system data may be a little older than production system data, but many times it is recycled production system data and should be protected as such.

Cloning production data to a development environment can create a number of issues, including:

• Programmers, contractors, and end users who are security officers in the development environment. Even though data is securely locked down in production, test users and especially programmers many times have all object authority or security officer access in the development environment. This causes a problem in that if you’re copying live data to the development environment for testing, these users may be able to view (somewhat aged) production data in the test system. And it could be production data they’re normally prevented from seeing.
• Possibility of fraud or mistaking test output for real production documents. Depending on how your test environment is set up, users may be able to send test production output to real-life customers and other departments in your organization. This can include sending test EDI transactions, shipment notices, printing checks, approving credit card transactions, viewing company financial information, viewing payroll data, accessing company payments, and a lot of other unintentional and (possibly) intentional output production. This can cause a lot of problems if users and customers accidentally receive test data and start processing it as live data.

Now while the idea of a production environment is to let your programmer and contractors make changes without putting production data at risk, you can also inadvertently set up some of the situations outlined here, if you’re not careful. Here are some common sense procedures for protecting recycled production in a test environment.

• Be stingy with all object or security officer access in the test environment. It’s extremely difficult to lock down menu options, files, or functions if everyone on the test system is a security officer with all object authority. The more you can control access in the test system, the less chance someone will be able to accidentally or intentional misuse the system. If a user is testing shipping changes, for example, he probably doesn’t need access to financial data. If you’re recycling production data to the test system, the test system should be (almost) as secure as the production system. This may not be possible with all your programmers, but you should at least consider what each individual user should be able to access in the test environment and implement appropriately.
• Don’t connect production output devices to your test system. If your users are going to be testing document changes, don’t allow them to print real-looking documents to production printers such as your check printer, high-speed laser printers in a warehouse, or invoice printers. Restrict where they can send output and there will be less chance of test output being mistaken for the real thing. Better yet, designate some printers and other devices as test devices only that are located in their own physically separate area from where production users collect their printed output.
• Restrict fax, email, and Internet transmission methods on the test system. You can reduce the chances that a programmer can accidentally send data to an outside user or another system by restricting access to your fax server, FTP server, and the email send commands. If all of your test system users aren’t security officers, then you can restrict access to functions such as email and fax commands, and data transfer commands. If feasible, you may also want to block outside Internet access in your firewall for your development environment.

Development Environment Versus Development Partition Versus Development Machine

Most shops host development environments in one of the following ways.

1. As a separate environment on the production system that can be controlled either through menu access, user profiles, or through separate library lists.
2. On a separate logical partition (LPAR) on the same machine as the production environment, where a test version of the production environment is duplicated to a second LPAR, complete with its own test database, controlled user profiles, and copies of all third-party software.
3. On a separate machine partition, complete with its own database, user profiles, and third-party software.

There are pros and cons with each type of implementation, but the most dangerous setup is to host your development environment on the same machine as your production box, where access is controlled through menu options, user profiles, and library lists. This architecture has many of the data issues listed above. However, because both production and test versions of your software reside on the same machine, it’s easier to corrupt data by overlaying or refreshing production files when you’re trying to refresh your test data.

Authority can also become a problem with having production and test environments on the same machine. If your programmers need to be security officers or have all object authority because they literally need to access every object in the test environment, this may not be a good alternative. If you can, it’s generally better if you host your test environment on a different partition than your production data.

It’s usually fairly easy to create a second test partition on your production machine, and that will satisfy any requirements to physically separate production and test data. The minimum requirements you need for a second partition are a spare Ethernet card and some leftover disk drives, memory, and CPU. And for a test partition, you may not even need that much memory or CPU. Depending on the amount of CPW on your production hardware, you may be able to create a workable test environment by just using .1 to .25 of a processor. After all, you probably won’t have a lot of users on the test environment and sub-second response time usually isn’t an issue here.

Hosting a test environment on a separate partition avoids a lot of the authority and production-test data confusion you might find when hosting it on a production machine. The downside, however, is that it’s more expensive to run third-party software applications on a second partition. You may have to buy separate licenses to run each of your third-party applications on a second partition. Many packages will offer a cheaper development license for running their software on a test partition, but a large number of the major packages do charge you extra for running their software on a second partition.

Running your test environment on a separate iSeries, System i, or Power i machine is equivalent to running it on a second partition, security-wise. However, it will be much more expensive to run third-party applications on a second machine because with the exception of replication software, you won’t be able to piggyback your software licenses from your production partition to a second test machine. Running your test environment on a separate machine also means that you have to have access to a separate machine, which may not be the case for smaller companies. If you have a Capacity Back-Up (CBU) system, it might be tempting to put your development partition on the CBU, freeing up your production machine to totally concentrate on business needs. However, if you set up a development partition on your CBU machine, you may be violating your IBM license agreement for using the CBU, which generally states that you are only using the machine for backup, not production purposes.

For security and practicality, your best choice for hosting your test environment is to put it on a separate partition on your production. This way, you can securely put up a wall between your test and production systems and you can keep your external licensing costs down at a reasonable rate.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot