ibm / servicenow-guardium-vulnerability-assessment Goto Github PK

Describe the bug
Online doc shows roles of x-ibm-guard.admin and x-ibm-guard.user, it should be x_ibmrt_gdpva.admin and x_ibmrt_gdpva.user

Steps to Reproduce
See online documentation

Summary

• Guardium app is attempting to aggregate all test results and then import into ServiceNow
• If there are many managed units, each with a lot of data, this causes an enormous JavaScript object to be built in memory

Solution

• Use a unique ServiceNow process (sn_vul_integration_process) to import and process results for each managed unit

Describe the bug
Currently the Guardium app uses hard-coded rules to match a Guardium Data Source to a ServiceNow Database Instance or Database Catalog entry. As a good citizen, the app should run CI Lookup Rule to determine the match.

Steps to Reproduce

1. Go to IBM Guardium > Configuration > Integrations
2. Execute the IBM Guardium - Data Sources integration (scheduled job)
3. Go to Discovered Items
4. Notice any linked CMDB_CI entry happened due to hard-coded rules

Expected behavior
I can write or modify a CI Lookup Rule to link a Guardium Data Source with any ServiceNow CMDB entry

Current behavior:

• Daily kicks off parallel processing of each central manager and exits
• Parallel processing kicks off parallel integration runs of all integrations that have no dependencies
• Dependent integrations wait until parents are finished

Desired behavior:

• Daily kicks off parallel jobs and waits for completion of all of them

Summary

Since this app works in conjunction with ServiceNow's Vulnerability Response and Configuration Compliance modules, offer a link to ServiceNow documentation for both modules.

Describe the bug

• Original UUID 912d85fd87940110387c64280cbb35dc was linked to a change in sn_vul_app_vul_scan_summary table which caused an issue with app certification scan
• Fix is to replace UUID with a new value 400d30552fa0111049572f2ef699b65a to break the link with sn_vul_app_vul_scan_summary
• Cannot resubmit app with new UUID using old scope
• Fix is to replace scope x_ibmrt_guard with new scope
• Close (withdraw) application for certification
• Create a brand new application for certification
• Receive credit for withdrawn application

Describe the bug

• Guardium Security Assessment Detail contains Test Result Details column which can contain more than 4000 characters.
• The data is copied into a ServiceNow field that has a maximum of 4000 characters

Recommendation

• If the data is greater than 4000 chars, put the entire data into an attachment

Summary

• In some environments, DB Instance "Contains" DB Catalog
• DB Catalog has a reference to the parent DB Instance but it may be empty, use cmdb_rel_ci relationship when reference is empty

Parent (db instance) > Contains:Contained-by > Child (db catalog)

Request

• Do not use full test description as the third-party test id. Instead, use a short notation like: Guardium-12345 where 12345 is the TEST_ID from Guardium.

Rationale

• The third-party test id is limited to 255 characters (in VR)
• The third-party test name field is limited to 512 characters
• Customer prefers to quickly see Guardium test definitions with a short ID

Current behavior:

On new data source import into ServiceNow:

• Create Discovered Item
• Create Unmatched Item
• Run CI Lookup Rules that are active and have source = IBM Guardium Integration

Desired behavior:

On new data source import into ServiceNow:

• Create Discovered Item
• Create Unmatched Item
• Run CI Lookup Rules that are active and name contains "Guardium"

Test results from Security Assessment Export report needs to append these additional fields:

• Test Result > Test Id
• Test Result > Result Details
• Test Result > Threshold String
• VA Summary > First Fail Datetime

Where the data will be inserted into Vulnerable Item and Configuration Compliance test results.

• Test Id > used to find the corresponding sn_vul_third_party_entry and sn_vulc_test
• Result Details > sn_vul_detection.proof (HTML), sn_vulc_result.actual_values
• Threshold String >sn_vul_detection.proof (HTML), sn_vulc_result.expected_values
• First Fail Datetime > sn_vul_detection.first_found, sn_vulc_result.first_seen

Comments

• x_ibmrt_gdpva.user role should have READ-ONLY access to all Guardium records
• x_ibmrt_gdpva.user role should not have WRITE access to any Guardium record

Summary

• Discovered Item has a value for last_auth_scan_date but the view shows last_scan_date.

Details

• GuardiumProcessorDatasource.insertDiscoveredItem()

                    sn_dis.setValue('last_auth_scan_date',
                        new GlideDateTime(this.integrationRunGr.getValue('sys_created_on')));

• Go to CI Lookup Rules
• Notice Guardium "Reference" rule script compares "correlation_id" to Guardium data source name

This request is to simplify the script to a field-matching rule

Steps

• Import Guardium data sources
• Select any Discovered Item created by Guardium
• Notice "Reapply CI Lookup Rule" does not run on the selected item

Describe the bug
Old configuration compliance test results do not show new First Seen, Actual Value, Expected Value data

Steps to Reproduce

1. Update IBM Guardium Data Protection to v11.5 with Patch 525
2. Synchronize VA test results
3. Notice First Seen, Actual Value, Expected Value do not have new values

Steps

In ServiceNow:

• Add a v11.4 central manager
• Add a v12.0 central manager
• Notice test definitions are only imported from the first (v11.4) cm

Summary

The ServiceNow attribute TCP port(s) supports more than one value for the database instance.

Details

• Database import (CI Lookup Rules) only match if tcp_port has one value.

if (oQuery.query.tcp_port == gr_cm.getValue('tcp_port')) {

• Database export (to Guardium) does not expect multiple values and fails if there are invalid chars in the tcp_port field

"port": gr_ds.getValue('tcp_port') || '',

Describe the bug

• Not everyone has access to ServiceNow Application Log to view information on import and export data. The request is to duplicate the logs in a table scoped to this application.

Summary

• Configure and run integrations
• If vulnerable items are created, they will appear in IBM Guardium > Test Result Dashboard
• Currently VIT created by other integrations are appearing in the list. It is expected that only Guardium VIT will be in the list.

Describe the bug
Cannot publish due to incorrect scope.

Steps to Reproduce

1. Go to My Company Applications
2. Click on IBM Guardium Vulnerability Assessment
3. Click Publish To ServiceNow Store
4. Notice error you cannot

This is due to incorrect prefix. It must be x_ibmrt_

Summary

Add active toggle to Guardium collectors to:

• avoid running jobs on them
• avoid collecting data from them

Current behavior of "Daily" integration

• Run each integration in parallel
• For those integrations that also reach out to managed units, run serially
• Some integrations have dependencies on other integrations (for instance, test details depends on database and test definition entries). Currently defined as ServiceNow documents.

Proposed behavior of "Daily" integration

• Run each integration in parallel
• For those integrations that also reach out to managed units, run those in parallel
• Create an in-memory map of integrations with dependencies and information about whether needed for partial sync and if it calls managed units

Request: disable Managed-Aggregator by default
Reason: aggregator does not normally run a VA test, it aggregates test results from other collectors

"Mark as False Positive" action on Vulnerable Item and Remediation Task

• Once approved, create a Guardium test exception with no end date

Yosef requests a way to sign-off on Test Exception (Approval Process)

Customer’s flow is for DBA to request VA exception , provide justification , end date (and other necessary fields for VA exception to be created) and once approved, exception is created in Guardium to make sure rerun of the test doesn’t fail until approved end-date. As customer may be running VA on thousands of servers, it has to be automated to be sustainable.

Summary

• Vulnerable Item has an existing Request Exception button
• An approval process is created from this button
• Once this is approved, create a Guardium Test Exception for the test and CMDB

Details

• Create a business rule to listen for change on table: sn_vul_change_approval
• When approval_state=1 then create Guardium Test Exception
• The approval record has a reference to the Vulnerable Item
• The Vulnerable Item has a reference to the test and CMDB records

An integration run may kick off multiple integration processes. Each of those processes could share the same oauth token.

Summary

• Guardium 11.5 has a new "User defined" table where additional information can be added to any Guardium test definition
• The Guardium report Available VA tests - detailed will be amended with these 3 new fields for a patch in v11.5 and v12.0

Request

• User defined reference one > IF value == severity THEN sn_vul_third_party_entry.severity, sn_vulc_test.source_severity
• User defined reference one > sn_vul_third_party_entry.solution, sn_vulc_test.description
• User defined reference two > sn_vul_third_party_entry.solution, sn_vulc_test.description
• User defined notes > sn_vul_third_party_entry.solution, sn_vulc_test.description

Each Guardium test result has information about the Database "Full Version" information. This information might be used to determine severity or priority of a Vulnerable Item.

This is a request to provide a Guardium Setting to allow / deny update of the cmdb_ci model_number field.

There are many CVE test definitions from Guardium that do not contain CVSS Attack Vector and other CVSS attributes. Fetch the data from NIST directly:
https://nvd.nist.gov/developers/vulnerabilities

GET:
https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2019-1010218
https://services.nvd.nist.gov/rest/json/cves/2.0?cweId=CWE-287

RESPONSE:
https://csrc.nist.gov/schema/nvd/api/2.0/external/cvss-v3.1.json
https://csrc.nist.gov/schema/nvd/api/2.0/external/cvss-v3.0.json
https://csrc.nist.gov/schema/nvd/api/2.0/external/cvss-v2.0.json

Summary

• Vulnerable Item has a button Rescan
• It is expected that this will kick off the Guardium assessment test associated with the Vulnerable Item

Details

• Create a new table to link sn_vul_detection with Guardium test result
• Guardium test result should also be linked to Guardium assessment test
• Listen to Rescan event
• Lookup most recent sn_vul_detection linked to the VIT
• Lookup test result and assessment test
• Kick off assessment job