Discovery, Data Collection, and Analysis

In this section you will learn how to perform basic discovery in order to identify existing authorized network activity, and how to analyze this data in preparation for configuring your security implementation.

Discovery

After you have activated Exit Point Manager it's time to monitor your system in order to identify the servers that are reporting current network traffic and then identify the specific transactions on those servers.

Identifying Network Activity

NOTE: If you are not using the Insite web UI, you do not have access to the Dashboard, and will need to identify network traffic by auditing your servers. Skip ahead to "Auditing Servers."

To identify network activity, you can first refer to the Exit Point Manager Dashboard. The Dashboard reveals all transactions that have passed through Exit Point Manager's active servers (see Activating Powertech Exit Point Manager). The activity reported on the Dashboard reveals which servers you may want to begin auditing.

Auditing Servers

To identify specific transactions you must configure Audit Flags to instruct Exit Point Manager to retain access information. After the access information has been collected, Exit Point Manager’s Reports can be used to identify the origin and other information about each transaction. This is the information that will be used to define access control rules.

Exit Point Manager’s default (*PUBLIC) User Rules apply to all (*ALL) Functions on all servers that permit remote access. Each is defined to inherit (*) the Audit (Aud) value from the product's global system values.

  1. On the Powertech Exit Point Manager portion of the Insite Navigation Pane, select Rules to open the Rules screen.
  2. Click  and select the following filter options:
    • Sort By: User/Location
    • Filter By: Server
  3. Click to dismiss the sort/search/filter options.
  4. Scroll down, if necessary, to view the rules marked *PUBLIC.
Rules screen

On the Main Menu choose 2 to view the Work with Security by User screen that displays the Aud value for each default rule.

All default rules are configured to inherit the Aud value from the global System Values.

By default, Exit Point Manager’s global Audit Flag is set to Yes (retain) for all servers. This global setting can be configured in the Edit Product Defaults screen using the web browser interface (or the Work with System Values panel using the green screen). This means that immediately after activation, Exit Point Manager is configured to audit all transactions on all servers.

Auditing all server requests can produce an overwhelming amount of data to evaluate, especially if you are unfamiliar with the amount of data your system generates. There can also be performance considerations, such as an increased frequency of journal receiver generation, and some CPU impact. To address these issues, you may decide to selectively audit a smaller number of servers (by setting some servers to No and others to Yes), complete the process of adding rules to secure those servers (as described later under Adding the Initial Rule Set), and then set Audit to Yes for a different selection of servers, and repeat the process. For example, if on the Dashboard you noticed a high number of FTP transactions, you may want to focus on just those servers first. While this approach extends the overall amount of time required for a complete analysis, it also reduces the amount of data that is collected in a given period to a more manageable level.

  1. On the Navigation Pane, select Product Configuration. To save time, we'll set the Product Default for Audit to No, then specify the individual servers you want to audit.
  2. Select System Values (Product Defaults) (the top option).
  3. Set Audit to No and click Save. All the *PUBLIC rules now inherit this setting.
  4. On the Navigation Pane, click Rules.
  5. On the Rules screen, identify the *PUBLIC user rules (see previous steps).
  6. Choose the *PUBLIC user rule for a server you would like to Audit. Under Audit, select Yes.
Edit Rule screen
  1. Choose Save. Repeat for the remaining *PUBLIC servers you would like to audit.
  1. From the Main Menu, choose 2 to show the Work with Security by User panel.
  2. Enter 2 for the *PUBLIC rule of a server you would like to audit.
  3. For Audit, change * to Y if you would like to audit the server. Change Audit to N to specify you would not like to audit the server. (Note that alternatively you could change the global Audit setting to N and leave the Audit value on the servers you do not want to audit to *, but specifying this value at the server level makes it easier to reference later.)
NOTE: Without the collected audit information you will not be able to create audit reports for data traffic analysis.

After setting the Audit value to Yes for select servers, the next step is to allow your system time to accumulate data.

Data Collection

A common question is: “How long should I let data collection run, and how much is enough?” While auditing is never ‘complete,’ there does come a point when enough data has been collected in order to facilitate sound decisions. Because the stream of data collection may ebb and flow over time, determining the correct point in time is essential. The correct point for your organization will depend on your assessment of critical events that must be considered before audit rules can be put in place. Consider auditing over ranges of time that would show typical daily or weekly traffic patterns for your environment. It is also preferable to include periods of time with anomalies that may occur only, for example, on weekends or during month-end processing.

Audited Traffic Data for Reporting

Audit traffic is retained in Journal receivers. The default journal upon installation is the IBM-supplied journal QAUDJRN. However, you are not limited to using QAUDJRN.

Review your journal receiver retention policy. Removing the journal receivers will remove the ability to run audit reports for the date ranges the receivers cover. If the receivers are removed from the system, restoration from backups will be necessary to report over date range.

Recommendation – Use an alternate journal if QAUDJRN is not your preference. See IBM documentation for details.

Initial Data Review and Analysis

  1. On the Navigation Pane, select Reports.
  2. Click Add and choose Intrusion Detection - Server/Function Report.
Add Report
  1. Create the report using the following settings:
    • Name: "Server Function Report"
    • Transactions: *ALL
    • Server *ALL
    • Function: *ALL
    • For Detail Level, choose Summary.
    • For Date Range, specify the number of days you would like the report to include. For the first report, a week is usually a reasonable duration. For Date Range, choose Specific to indicate the report should include a specific start and end date. Choose Non Specific to include a period of time previous to the time the report is run.
New Report screen
  1. Click Save to save the report. You return to the Reports screen.
  2. Click to the right of Server Function Report and choose Submit. A message should appear in the lower left indicating the report has been submitted successfully.
  3. Click Spooled Files in the Navigation Pane.
  4. The report you just submitted will be at the top of the list. Click it to view.

The summary of transactions on audited servers is a starting point for planning your security configuration.

Your audit results may not show traffic on each of the audited servers. A typical system will show activity on 12-15 servers with the heaviest activity on 6-8 servers. Some may not be used at all in your environment. (If you don’t see traffic, remember it is also possible your system did not generate activity during the captured time range). If a server is not being used, it can be blocked to prevent all access, accidental or malicious.

For your initial review, you can identify the servers with and without activity in a general transaction summary. To do this, run a report that displays all transactions on all the servers you are auditing.

  1. From the Exit Point Manager Main Menu (green screen), choose option 80, then 6 to view the Extract Audited Transactions panel.
  2. Page down to show the Occurrence Period parameter, and specify the desired time period. For the first report, a week is usually a reasonable duration (*THISWEEK). Also specify the starting day in the First Day of Week field.
  3. Press F10 for more options.
  4. For Report Style, enter *SUMMARY to generate a summary by server only.
  1. Press Enter to run the report.
  2. Press F14 to view Submitted Jobs, then move your cursor to the bottom (most recent) AUDIT job and type 8, Work with Spooled Files, then press Enter. (The amount of time it takes for the spooled file to appear will depend on the number of transactions).
  3. Choose option 5 to display the report.

The summary of transactions on audited servers is a starting point for planning your security configuration.

Your audit results may not show traffic on each of the audited servers. A typical system will show activity on 12-15 servers with the heaviest activity on 6-8 servers. Some may not be used at all in your environment. (If you don’t see traffic, remember it is also possible your system did not generate activity during the captured time range). If a server is not being used, it can be blocked to prevent all access, accidental or malicious.

For your initial review, you can identify the servers with and without activity in a general transaction summary. To do this, run a report that displays all transactions on all the servers you are auditing.

Reviewing Server Transactions

Now that your server summary has revealed the servers that are being used, you can review the transaction history on those servers to identify unauthorized activity or automated service profiles that do not require auditing.

NOTE: User profiles used for automated tasks can contribute to heavy volumes of traffic that do not represent human action or a security threat. Once identified, auditing for these profiles (or more efficiently, groups that include several or all of these profiles) can be turned off to reduce the ‘noise’ of automated activity, so that effort can be concentrated on dealing with activity from real users. The IBM-supplied user profiles beginning in “Q” (QSECOFR, QTCP) are usually service accounts (but not always). On reports, service accounts can often be identified by repetitive activity, or activity at regular intervals.
  1. On the Navigation Pane, select Reports.
  2. Click Add and choose Intrusion Detection - Server/Function Report.
  3. Your settings should include the server that yielded a large amount of transactions from your initial data review, and specify a time range. The best time range will be long enough to acquire a representative sample of transactions, but short enough to avoid excessive transactions in the tens of thousands or more. Use the following settings:
    • Name: "Server Function Report [server name]"
    • Transactions: *ALL
    • Server [server name] (e.g. *DATAQSRV)
    • Function: *ALL
    • For Date Range, specify the number of days you would like the report to include. For the first report, a week is usually a reasonable duration. For Date Range, choose Specific to indicate the report should include a specific start and end date. Choose Non Specific to include a period of time previous to the time the report is run.
    • For Detail Level, choose Transaction.
  4. Click Save to save the report. You return to the Reports screen.
  5. Click to the right of Server Function Report and choose Submit. A message should appear in the lower left indicating the report has been submitted successfully.
  6. Click Spooled Files in the Navigation Pane.
  7. The report you just submitted will be at the top of the list. Click it to view. The summary of transactions on audited servers is a starting point for planning your security configuration.

Your audit results may not show traffic on each of the audited servers. A typical system will show activity on 12-15 servers with the heaviest activity on 6-8 servers. Some may not be used at all in your environment. (If you don’t see traffic, remember it is also possible your system did not generate activity during the captured time range). If a server is not being used, it can be blocked to prevent all access, accidental or malicious.

For your initial review, you can identify the servers with and without activity in a general transaction summary. To do this, run a report that displays all transactions on all the servers you are auditing.

  1. From the Main Menu, choose option 80, then 3 to view the Server Function Reports menu.
  2. Choose 4, (Selected Server, All Functions) All Transactions.
  3. Next to Server, enter the server that yielded a large amount of transactions from your initial data review, and specify a time range. The best time range will be long enough to acquire a representative sample of transactions, but short enough to avoid excessive transactions in the tens of thousands or more.
  4. Press Enter to run the report.
  5. Press F14 to work with submitted jobs.
  6. Enter 8 for the job and press Enter. Scroll to identify profiles that submit repetitive transactions. Notice in the example below, the PLCM2ADM profile submits a transaction every 5 seconds.
display Spooled File panel
Service accounts usually exhibit repetitive activity at regular intervals.

Now that you have discovered the servers with activity, and identified the users and transactions on those servers, you can begin implementing your security configuration by defining your own custom access control rules.