Rick Vanover

Pulling compliance audits, procedures and practice together

In my last post I mentioned that it is worth the effort when drafting work instructions that match actual practice. Now, I want to take that one step further and hit on a point that can many of us that go through compliance audits.

In a perfect world, compliance audits are a quick check under the hood and a handshake. Unfortunately, they are much more involved than that. One practice point that I want to share that can help the compliance audit practice is related to structuring work instructions and established procedures to meet compliance requirements. For things like software updates and critical vulnerability scans, you can make your life simpler by a little forward thought. Take for instance PCI audit requirements for software update frequency, if your work procedures are written to the requirements of PCI you are one step ahead of the game. Further, if you address your authoritative system inventory with a procedure that is used to perform periodic security scans; the compliance requirements, documentation requirements and actual practice go full-circle without any additional work.

Saving additional work is critical. Having disparate compliance efforts, documented procedures, and actual practices are just asking for things to get out of sync. The investment in making the procedures match compliance requirements is not a new one, but common sense for those with any regulatory footprint. This can assist staff that are new to compliance requirements as well as make business plans clear in time-critical situations such as a company acquisition.

Do you write your procedural inventory to the compliance requirements? If so, share your efficiency tips below.

Gauging the value of procedures and work instructions

Revision-controlled documents such as procedures and work-instructions are a beautiful thing. Sure, the work required to establish the documentation up front can be significant. But the reward can pay off with smooth transitions between staff members or departments as well as consistency across systems.

A good practice point that I have found useful to ensure that procedures and work instructions are correct is to engage another person to literally pick up and run with it. This can be a new hire, temporary employee or even an existing IT staff member that has developed strengths in other areas. We frequently strive to develop procedures and work instructions so that “even a monkey could do it.” But, how frequently do we actually do that?

The value of a hand-off for procedures and work instructions can be measured by its effectiveness to a new person assigned to work in technology areas related to the documentation. This will identify issues such as:

-Out of date versions of software titles
-Updated procedures that may have changed
-Clarity of the procedures
-Ensuring that nothing is omitted from the steps
-Identify unforeseen prerequisites (such as permissions)

Other benefits come from validating the correctness of procedures and work instructions as well. The effectiveness is truly measured once a person with no expectation or prior knowledge of the technologies in question is assigned to perform the procedure or work instruction.

Moving away from NAT for testing

For test and development systems, one practice over the years to allow developers to build test systems or applications has been to use network address translation or NAT. NAT basically puts some device in front of other systems. Development teams can use NAT a number of ways. These include running a virtual machine behind a host’s network, a network appliance or firewall rules.

NAT is bad for testing for a number of reasons. The primary reason is because the test system is behind a (presumed) protected device, there is no pressure to put security as a priority in the test process. Practice points such as weak password, application defaults, unnecessary network configurations and other items leave the test system at risk for propagating poor configuration and practice forward in the lifecycle.

Instead of using NAT, many organizations are using dedicated networks for test and development purposes. There can be firewall rules in and out of the network, yet within the network the test systems are fully present. These dedicated networks can also be configured to be fully isolated or connected upward for important things such as Windows Updates for Microsoft systems.

NAT is a limited in real practice for development cycles. What may not be known is what developers are doing individually with local virtual machines on desktops that may be using NAT.

The governing principle is to treat all levels of test and development with the same network rules that you may subject them to in a live environment.

Requirements-based provisioning useful in all aspects of IT

At some point in time, we all have likely engaged with some level of requirements-based testing (RBT) or development. While RBT is generally a fundamental in software quality, there can be limitations and cons as described in this Software Quality Insights tip. In my professional IT work, I currently focus primarily on infrastructure and related technologies. But that is not to say that we cannot take a page from the requirements-based disciplines.

One of the most frustrating situations in the new build process of any system or collection of systems is when others have applied technologies without defining requirements. This frequently arises in disaster recovery, system availability or business continuity arenas. While the development and application teams want to provision a highly-available solution, there can be a disconnect between the internal decisions and what infrastructure teams can provide.

The current IT landscape offers infrastructure professionals many options in protection and availability. This is made possible by virtualization, load-balancing solutions and a matured backup software space. My approach has been for the application and development teams to provide the availability requirements for a technology solution. This usually involves defining two important terms:

Recovery Time Objective (RTO) – How much time would be required to recover from any system-level failure that would make the system and business process available.

Recovery Point Objective (RPO) – A defined requirement for point-in-time recoverability for the business process.

The RTO and RPO work together to determine what availability and recovery would be provided to a business process. Infrastructure professionals can play this game quite well now with the current landscape of tools and technologies. Be sure to engage them as appropriate in the system provisioning process.

Software test environments: Overlooked in licensing?

There is no doubt that test environments are the lifeblood of high-quality technology solutions. In a recent discussion with another IT professional, the issue of test environment licensing came up and clearly became a grey area that is applied differently between organizations. In the case of Microsoft licensing, larger enterprises have a distinct advantage to licensing test environments when engaged in Microsoft Software Assurance (SA). While there may be slight differences of what differentiates a test and QA environment, generally a QA system has a longer lifespan. Further, QA systems usually are fully licensed in all regards like their production counterparts.

Fine print and vague or missing clauses are common in software licensing, and test environment licenses share those same ills. For organizations that do not maintain Microsoft SA, the base operating system licensing can be very expensive to maintain for Windows Server, SQL Server database and other systems. For the operating system, evaluation licenses can usually accommodate temporary use. For ongoing use, the practice and options become unclear. The Microsoft SQL Server product continues to offer a free edition, Microsoft SQL Server 2008 Express. The issue from a test/QA standpoint becomes if using the Express edition is representative of the end configuration or product being tested.

This is not an issue for the most part for organizations utilizing free products end-to-end, such as Linux for an operating system and open databases such as MySQL. There may be licensing considerations if any commercial tools or other licensed software titles are used or tested, however.

How are you approaching this topic? Ideally all systems are licensed the same way, but the informal tiers of testing may be omitted from an organization’s larger licensing initiative. Share your comments below on test environment licensing.

Why video modes matter in software testing and configuration

In my software testing work, I’ve found that video configuration consistency is a critical factor in a system’s performance and behavior under test conditions and an important factor in delivering technology in the intended fashion.  Naturally, traditional resolution requirements for a consistent experience are only one part of video’s critical role, which can encompass everything from video adapters, driver version, video configuration, resolution, refresh rate, any console interaction mechanisms and the number of monitors running that configuration.

I recently talked with David Wren about the importance of video configuration’s importance. Wren is the managing director of PassMark software, a leading system benchmark software provider. Wren offers that video configuration is important when ensuring a solution is to function as expected. One example where this was an issue for a Windows-based system was the recent issue with Nvidia drivers on Windows Vista. Some video adapter models have had ten or more driver releases since November 2007.

Beyond driver issues, which Wren states can be notoriously buggy, 2D and 3D video performance can be point to watch in the test process. For software implementations that are not graphics intensive, such as text-based screen activity, the performance is relatively unimportant. When graphics are introduced, then the video performance is critical. This can include playing high-quality videos, games, or graphics rendering with design software. PassMark maintains a benchmark website of video card performance benchmarks that is updated daily, and the results for the same tests on different platforms show varied results.

These factors and more are especially relevant in today’s media-rich technology landscape. Many of the various high quality media will likely perform differently under circumstances where various video configurations are in use, making benchmarks a critical part of the test process.