Data breaches are unfortunately becoming a regular item in news reports these days. As a result, IT teams everywhere are scrambling to making sure they're using every available security control to protect the sensitive data they own.
Performance data collection tools are an area that's easy to overlook because you don't intuitively think about those types of tools collecting business data values from your system. The default behavior of the DB2 for i database monitor tool is to collect data values used by your application's SQL requests. Thus, there's the possibility of your database monitor collections containing sensitive data values.
Let's explore further how this sensitive data exposure occurs before discussing the new security support available to protect these data values. Assume that an application executes the following SQL SELECT statement to retrieve the last name and security pin code associated with a particular bank card account.
SELECT last_name, pin_code FROM accounts WHERE card_number = :host_var
If a database monitor is active while the application is running, then DB2 generates several records of monitor data. This monitor data includes the text of the SQL statement that was executed and how the SQL statement was executed by the DB2 engine (table scan, index scan, etc.).
The database monitor does not record the actual values that are returned to the application by the Select statement. So for this SQL request, the database monitor collection will not contain any data values for account holders' names or security pin codes. The data security exposure exists because of the host variable reference on the SQL statement.
The database monitor tool records and stores the values of the host variables because there are times the performance of an SQL statement can be noticeably different based on the actual value assigned to a host variable. In this example, that means the database monitor collection will contain the different card number values that the application has assigned to the host variable for each execution of this Select statement. These host variable values can then be easily retrieved by running queries against the database monitor collection file or using the graphical monitor analysis tools provided by System i Navigator.
The following figure contains a portion of the Visual Explain output that can be easily generated by using the Show Statements analysis interface for an SQL performance monitor collection. As you can see from the circled item, this output contains a card number value of 5431 right below the SQL statement text. Assuming the application assigned a valid card number to the host variable, any person working with a database monitor collection now has access to this sensitive data value.
Figure 1: Visual Explain output shows host variable values captured by database monitor.
One immediate reaction to this security exposure would be to just ban the usage of the database monitor tool. However, this tool is very useful for identifying performance bottlenecks or debugging SQL functional problems. That's why IBM has recently provided a new control for the database monitor tool that enables sensitive data values to be secured while this tool collects data about your SQL requests.
Appropriately enough, the value of this new control is Secure. To prevent the actual host variable value from being accessed, you can specify a value of *SECURE for the HOSTVAR parameter on the STRDBMON command or select the Secure setting for this parameter, as shown in the following figure that depicts the graphical monitor wizard interface.
Figure 2: Graphical monitor interface enables host variable values to be secured.
With a secured database monitor collection, all of the database monitor analysis interfaces—including your own queries—will simply display a value of *SECURE for the host variable values associated with this SQL statement. So the Visual Explain output for a secured collection will look like the following for our example Select statement.
Figure 3: Visual Explain output shows secured host variable values from database monitor.
This secure database monitor support is available only on systems running the IBM i 7.1 and 7.2 operating system releases that have applied the following Database Group PTF levels:
- IBM i 7.2: SF99702, Level 3
- IBM i 7.1: SF99701, Level 32
You should now be equipped to eliminate a possible leak of sensitive data values that might have been a threat of making your company a candidate for an upcoming news report.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online