V1R2 changes
DBN-6300 IDPS STIG V1R2 (2024-07-24) replaced V1R1 (2017-09-12): 17 checks added, 16 removed. It has 17 checks, against 16 in V1R1.
V1R2 checklistV1R1 checklist Compare V1R1 and V1R2 in STIG Compare
- 17 added
- 16 removed
- 0 updated
Added in V1R2 (17)
- V-237556CAT IIIn the event of a logging failure, caused by loss of communications with the central logging server, the DBN-6300 must queue audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools.
- V-237557CAT IIIn the event of a logging failure caused by the lack of log record storage capacity, the DBN-6300 must continue generating and storing audit records if possible, overwriting the oldest audit records in a first-in-first-out manner.
- V-237558CAT IIThe DBN-6300 must generate log events for detection events based on anomaly analysis.
- V-237559CAT IIThe DBN-6300 must install system updates when new releases are available in accordance with organizational configuration management policy and procedures.
- V-237560CAT IITo help detect unauthorized data mining, the DBN-6300 must detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
- V-237561CAT IITo protect against unauthorized data mining, the DBN-6300 must monitor for and detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
- V-237562CAT IITo protect against unauthorized data mining, the DBN-6300 must detect SQL code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
- V-237563CAT IITo protect against unauthorized data mining, the DBN-6300 must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code/input fields.
- V-237564CAT IITo protect against unauthorized data mining, the DBN-6300 must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
- V-237565CAT IIThe DBN-6300 must support centralized management and configuration of the content captured in audit records generated by all DBN-6300 components.
- V-237566CAT IIThe DBN-6300 must off-load log records to a centralized log server.
- V-237567CAT IIThe DBN-6300 must integrate with a network-wide monitoring capability.
- V-237568CAT IIThe DBN-6300 must continuously monitor inbound communications traffic between the application tier and the database tier for unusual/unauthorized activities or conditions at the SQL level.
- V-237569CAT IIThe DBN-6300 must off-load log records to a centralized log server in real time.
- V-237570CAT IIWhen implemented for protection of the database tier, the DBN-6300 must be logically connected for maximum database traffic visibility.
- V-237571CAT IIWhen implemented for discovery protection against unidentified or rogue databases, the DBN-6300 must provide a catalog of all visible databases and database services.
- V-264430CAT IThe DBN-6300 IDPS must be using a version supported by the vendor.
Removed since V1R1 (16)
- V-64977CAT IITo help detect unauthorized data mining, the DBN-6300 must detect code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
- V-64999CAT IIIn the event of a logging failure, caused by loss of communications with the central logging server, the DBN-6300 must queue audit records locally until communication is restored or until the audit records are retrieved manually or using automated synchronization tools.
- V-65001CAT IIIn the event of a logging failure caused by the lack of log record storage capacity, the DBN-6300 must continue generating and storing audit records if possible, overwriting the oldest audit records in a first-in-first-out manner.
- V-65003CAT IIThe DBN-6300 must generate log events for detection events based on anomaly analysis.
- V-65005CAT IIThe DBN-6300 must install system updates when new releases are available in accordance with organizational configuration management policy and procedures.
- V-65007CAT IITo protect against unauthorized data mining, the DBN-6300 must monitor for and detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
- V-65009CAT IITo protect against unauthorized data mining, the DBN-6300 must detect SQL code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
- V-65011CAT IITo protect against unauthorized data mining, the DBN-6300 must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code/input fields.
- V-65013CAT IITo protect against unauthorized data mining, the DBN-6300 must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
- V-65015CAT IIThe DBN-6300 must support centralized management and configuration of the content captured in audit records generated by all DBN-6300 components.
- V-65017CAT IIThe DBN-6300 must off-load log records to a centralized log server.
- V-65019CAT IIThe DBN-6300 must integrate with a network-wide monitoring capability.
- V-65021CAT IIThe DBN-6300 must continuously monitor inbound communications traffic between the application tier and the database tier for unusual/unauthorized activities or conditions at the SQL level.
- V-65023CAT IIThe DBN-6300 must off-load log records to a centralized log server in real time.
- V-65025CAT IIWhen implemented for protection of the database tier, the DBN-6300 must be logically connected for maximum database traffic visibility.
- V-65059CAT IIWhen implemented for discovery protection against unidentified or rogue databases, the DBN-6300 must provide a catalog of all visible databases and database services.
How these changes are found
Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V1R2 no longer has.
Comparing other releases, or this one against an older release? Pick any two in STIG Compare.