What changed in DBN-6300 IDPS STIG V1R2V1R2 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.

  • 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.