kriterion 0.0.1

data/lib/kriterion/version.rb

@@ -0,0 +1,3 @@
+class Kriterion
+  VERSION = "0.0.1"
+end

data/lib/kriterion/worker.rb

@@ -0,0 +1,280 @@
+require 'json'
+require 'logger'
+require 'net/http'
+require 'benchmark'
+require 'kriterion'
+require 'kriterion/logs'
+require 'kriterion/item'
+require 'kriterion/report'
+require 'kriterion/metrics'
+require 'kriterion/section'
+require 'kriterion/standard'
+
+require 'pry'
+
+class Kriterion
+  class Worker
+    include Kriterion::Logs
+
+    attr_reader :uri
+    attr_reader :queue
+    attr_reader :queue_uri
+    attr_reader :standards
+    attr_reader :backend
+    attr_reader :metrics
+
+    def initialize(opts = {})
+      logger.level = if opts[:debug]
+                       Kriterion::Logs::DEBUG
+                     else
+                       Kriterion::Logs::INFO
+                     end
+
+      # Set up connections
+      @uri       = opts[:uri]
+      @queue     = opts[:queue]
+      @queue_uri = URI("#{@uri}/q/#{@queue}")
+      @metrics   = Kriterion::Metrics.new
+
+      # Set up the backend
+      # TODO: Clean this up and make fully dynamic
+      backend_name = opts[:backend] || 'mongodb'
+      case backend_name
+      when 'mongodb'
+        require 'kriterion/backend/mongodb'
+        Kriterion::Backend.set(
+          Kriterion::Backend::MongoDB.new(
+            hostname: opts[:mongo_hostname],
+            port:     opts[:mongo_port],
+            database: opts[:mongo_database],
+            metrics:  metrics
+          )
+        )
+      end
+
+      @backend = Kriterion::Backend.get
+
+      # TODO: Work out how workers are going to get the list of standards frmo the API runner
+      # TODO: Remove placeholder code
+      standards_dir   = File.expand_path('standards', Kriterion::ROOT)
+      @standards      = Kriterion.standards([standards_dir])
+    end
+
+    def process_report(report)
+      report  = Kriterion::Report.new(report)
+
+      # Check if the report contains any relevant resources
+      standard_names     = standards.keys
+      relevant_resources = report.resources_with_tags(standard_names)
+
+      return nil if relevant_resources.empty?
+
+      logger.info "Processing report with #{relevant_resources.count} relevant resources"
+
+      # Purge all old events relevant to this node, they will be re-added
+      backend.purge_events! report.certname
+
+      # Process the report
+      affected_standards = relevant_resources.group_by do |resource|
+        # Select the standard tag
+        stds = (resource.tags & standard_names)
+
+        raise 'Found a resource that was relevant to more than one standard. This is not yet supported' if stds.length > 1
+
+        stds[0]
+      end
+
+      affected_standards.each do |name, resources|
+        standard = backend.get_standard(name, recurse: true)
+        unless standard
+          # If the standard doesn't yet exist in the backed, add it
+          standard = Kriterion::Standard.new(@standards[name])
+          logger.debug "Adding starndard #{standard.name} to backend"
+          backend.add_standard(standard)
+          # TODO: See if there is a better way to deal with this, the reason I'm
+          # doing this is that I want to make sure that there is not difference
+          # between a newly created object and one that came from the database
+          standard = backend.get_standard(name, recurse: true)
+        end
+
+        resources.each do |resource|
+          # Get the section tag
+          section_tag = resource.tags.select do |t|
+            standard.item_syntax.match(t)
+          end
+
+          # TODO: Make this work
+          raise 'Found a resource relevant to multiple sections' if section_tag.length > 1
+
+          section_tag = section_tag.first
+
+          # Go though all sections and subsections and create them if required
+          captures = standard.item_syntax.match(section_tag).captures - [nil]
+
+          # Convert the captures to a list of sections, but excluse the last one
+          # because that will be the name of the item
+          parent_sections = captures_to_sections(standard, captures[0..-2])
+
+          # If there are no captures then this is a direct child of a standard
+          if captures.nil?
+            section = standard
+          else
+            section = parent_sections.reduce(standard) do |previous, current|
+              # If the section already exists return it
+              if previous.find_section(current)
+                previous.find_section(current)
+              else
+                # This is a new section that does not yet exist in the database,
+                # we therefore need to get the details and all them all in
+                current_section_name = if previous.is_a? Kriterion::Standard
+                                         current
+                                       elsif previous.is_a? Kriterion::Section
+                                         [
+                                           previous.name,
+                                           current
+                                         ].join(standard.section_separator)
+                                       end
+
+                # Get the details from the standards database (name, description
+                # etc.)
+                current_section = @standards[name]['sections'].select do |s|
+                  s['name'] == current_section_name
+                end[0]
+
+                if current_section.nil?
+                  previous
+                else
+                  # Create the new section object
+                  current_section['standard']    = standard.name
+                  current_section['parent_type'] = previous.type
+                  current_section['parent_uuid'] = previous.uuid
+                  current_section = Kriterion::Section.new(current_section)
+
+                  # Add the section to the backend
+                  backend.add_section(current_section)
+                  current_section
+                end
+              end
+            end
+          end
+
+          # Create and add the item if it doesn't yet exist
+          item = case section.items.select { |i| i.id == section_tag }.count
+                 when 1
+                   # The item already exists, return it
+                   section.items.select { |i| i.id == section_tag }[0]
+                 when 0
+                   # The item does not exist, create it, add to the database,
+                   # then return it
+                   item_details = @standards[name]['items'].select do |i|
+                     i['id'].upcase == section_tag.upcase
+                   end[0]
+                   item_details['parent_uuid']  = section.uuid
+                   item_details['parent_type']  = section.type
+                   item_details['section_path'] = captures
+                   backend.add_item(Kriterion::Item.new(item_details))
+                 else
+                   raise "Found muliple sections with the id #{section_tag}"
+                 end
+
+          # Add extra contextual data to that resource
+          resource.parent_uuid = item.uuid
+
+          # Add the new resource to the backend if it doesn't exist
+          unless item.resources.include? resource
+            item.resources << resource
+            backend.add_resource(resource)
+          end
+
+          # Inform the database that this node is unchanged if we have no events
+          if resource.events.empty?
+            backend.add_unchanged_node(resource, report.certname)
+          end
+
+          # Add all events to the database
+          resource.events = resource.events.map do |event|
+            event          = Kriterion::Event.new(event)
+            event.certname = report.certname
+            event.resource = resource.resource
+            backend.add_event(event)
+            event
+          end
+
+          metrics[:update_compliance] += Benchmark.realtime do
+            # Finally update the compliance details for this resource and its
+            # parent item
+            backend.update_compliance! resource
+            backend.update_compliance! item
+
+            # Find all of the parent sections and update the compliance on them
+            # Don't recalculate the compliance of the standard yet, wait until
+            # the end.
+            item.parent_names(standard.section_separator).each do |parent|
+              # TODO: Complete this so that it updates the compliance of
+              # everything. It's probably better if we re-query this stuff from
+              # the database to reduce the chances of race conditions
+              result = backend.find_sections(
+                name: parent,
+                standard: standard.name
+              )
+              result.each { |r| backend.update_compliance! r }
+            end
+          end
+        end
+
+        # Reload the standard as new sections may have been added
+        standard = backend.get_standard(name, recurse: true)
+
+        metrics[:update_compliance] += Benchmark.realtime do
+          # Recalculate the compliance of a given standard once it is done
+          backend.update_compliance! standard
+        end
+      end
+    end
+
+    def run
+      while true do
+        # Connect and check if there is anythong on the queue
+        # TODO: Change this so that they listen properly
+        logger.debug "GET #{queue_uri}"
+        begin
+          response = Net::HTTP.get_response(queue_uri)
+
+          case response.code
+          when '204'
+            logger.debug 'Queue empty, sleeping...'
+            sleep 3
+          when '200'
+            logger.debug 'Got a report, parsing...'
+            report = JSON.parse(JSON.parse(response.body)['value'])
+            logger.info "Processing report: #{report['host']} #{report['time']}"
+
+            metrics[:total_processing] += Benchmark.realtime do
+              process_report(report)
+            end
+
+            metrics.print
+          end
+        rescue Timeout::Error, Errno::EINVAL, Errno::ECONNRESET, EOFError,
+               Net::HTTPBadResponse, Net::HTTPHeaderSyntaxError,
+               Net::ProtocolError, Errno::ECONNREFUSED, SocketError => e
+          logger.error "Error while running: #{e}"
+          logger.info 'Sleeping...'
+          sleep 3
+        end
+      end
+    end
+
+    private
+
+    def captures_to_sections(standard, captures)
+      sections = []
+
+      captures.each_index do |index|
+        sections << captures[0..index].join(standard.section_separator)
+      end
+
+      sections
+    end
+  end
+end

data/standards/cis_red_hat_enterprise_linux_7.json

@@ -0,0 +1,34 @@
+{
+  "name": "cis_red_hat_enterprise_linux_7",
+  "date": "2016-02-06",
+  "description": "This document provides prescriptive guidance for establishing a secure configuration posture for Red Hat Enterprise Linux 7 systems running on x86 and x64 platforms. This document was tested against Red Hat Enterprise Linux 7.2. The guidance within broadly assumes that operations are being performed as the root user. Non-root users may not be able to access certain areas of the system, especially after remediation has been performed. It is advisable to verify root users path integrity and the integrity of any programs being run prior to execution of commands and scripts included in this benchmark.",
+  "title": "CIS Red Hat Enterprise Linux 7 Benchmark",
+  "version": "2.1.0",
+  "item_syntax": "^(\\d+)\\.?(\\d+)?\\.?(\\d+)?\\.?(\\d+)?\\.?(\\d+)?\\.?(\\d+)?\\.?(\\d+)?$",
+  "section_separator": ".",
+  "sections": [
+    {
+      "name": "1",
+      "title": "Initial Setup",
+      "description": "Items in this section are advised for all systems, but may be difficult or require extensive preparation after the initial setup of the system."
+    },
+    {
+      "name": "1.7",
+      "title": "Warning Banners",
+      "description": "Presenting a warning message prior to the normal user login may assist in the prosecution of trespassers on the computer system. Changing some of these login banners also has the side effect of hiding OS version information and other detailed system information from attackers attempting to target specific exploits at a system. Guidelines published by the US Department of Defense require that warning messages include at least the name of the organization that owns the system, the fact that the system is subject to monitoring and that such monitoring is in compliance with local statutes, and that use of the system implies consent to such monitoring. It is important that the organization's legal counsel review the content of all messages before any system modifications are made, as these warning messages are inherently site-specific. More information (including citations of relevant case law) can be found at http://www.justice.gov/criminal/cybercrime/ \n\n**Note:** The text provided in the remediation actions for these items is intended as an example only. Please edit to include the specific text for your organization as approved by your legal department."
+    },
+    {
+      "name": "1.7.1",
+      "title": "Command Line Warning Banners",
+      "description": "The `/etc/motd`, `/etc/issue`, and `/etc/issue.net` files govern warning banners forstandard command line logins for both local and remote users."
+    }
+  ],
+  "items": [
+    {
+      "id": "1.7.1.1",
+      "title": "Ensure message of the day is configured properly (Scored)",
+      "description": "The contents of the `/etc/motd` file are displayed to users after login and function as a message of the day for authenticated users.\n\nUnix-based systems have typically displayed information about the OS release and patch level upon logging in to the system. This information can be useful to developers who are developing software for a particular OS platform.",
+      "severity": "high"
+    }
+  ]
+}

data/standards/stig_a10_networks_adc_alg.json

@@ -0,0 +1,209 @@
+{
+  "name": "stig_a10_networks_adc_alg",
+  "date": "2016-04-15",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.",
+  "title": "A10 Networks ADC ALG Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-67957",
+      "title": "The A10 Networks ADC, when used for TLS encryption and decryption, must be configured to comply with the required TLS settings in NIST SP 800-52.",
+      "description": "SP 800-52 provides guidance on using the most secure version and configuration of the TLS/SSL protocol. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks which exploit vulnerabilities in this protocol.\n\nThis requirement applies to TLS gateways (also known as SSL gateways) and is not applicable to VPN devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol thus are in scope for this requirement. NIS SP 800-52 provides guidance.\n\nSP 800-52 sets TLS version 1.1 as a minimum version, thus all versions of SSL are not allowed (including for client negotiation) either on DoD-only or on public facing servers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67959",
+      "title": "The A10 Networks ADC, when used to load balance web applications, must enable external logging for accessing Web Application Firewall data event messages.",
+      "description": "Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nExternal logging must be enabled for WAF data event messages. Create a server configuration for each log server, and then add a TCP or UDP port to each server configuration, with the port number on which the external log server listens for log messages.",
+      "severity": "low"
+    },
+    {
+      "id": "V-67961",
+      "title": "The A10 Networks ADC must send an alert to, at a minimum, the ISSO and SCA when connectivity to the Syslog servers is lost.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAudit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Possible audit processing failures also include the inability of device to write to the central audit log.\n\nThis requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations, (i.e., all audit data storage repositories combined), or both.\n\nThis does not apply to audit logs generated on behalf of the device itself (management).",
+      "severity": "low"
+    },
+    {
+      "id": "V-67963",
+      "title": "The A10 Networks ADC must not have unnecessary scripts installed.",
+      "description": "Information systems are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the device. Unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.\n\nThe A10 Networks ADC can use a TCL-based scripting language called aFleX. Scripts used by an A10 Networks ADC must be documented so that Administrative and Security personnel understand them.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67965",
+      "title": "The A10 Networks ADC must use DNS Proxy mode when Global Server Load Balancing is used.",
+      "description": "Unrelated or unneeded proxy services increase the attack vector and add excessive complexity to the securing of the device. Multiple application proxies can be installed on many devices. However, proxy types must be limited to related functions.\n\nThe A10 Networks ADC is capable of DNS-based Global Server Load Balancing (GSLB), which uses Domain Name Service (DNS) to expand load balancing to larger scales, including globally. Global Server Load Balancing can operate in either Proxy mode or Server mode. In Proxy mode, all DNS queries arriving at the DNS Proxy IP address are forwarded to the existing DNS server. In Server mode, the device directly responds to queries for specific service IP addresses in the GSLB zone and can reply with A, AAAA, MX, NS, PTR, SRV, and SOA records. For all other records, the ACOS device will attempt Proxy mode unless configured as fully authoritative.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67967",
+      "title": "The A10 Networks ADC must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types); organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.\n\nThe device must be configured to prevent or restrict the use of prohibited ports, protocols, and services throughout the network by filtering the network traffic and disallowing or redirecting traffic as necessary. Default and updated policy filters from the vendors will disallow older version of protocols and applications and will address most known non-secure ports, protocols, and/or services. However, sources for further policy filters are the IAVMs and the PPSM requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67969",
+      "title": "The A10 Networks ADC when used for TLS encryption and decryption must validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation.",
+      "description": "A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate.\n\nCertification path validation includes checks such as certificate issuer trust, time validity and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.\n\nThe A10 Networks ADC can be configured to use Open Certificate Status Protocol (OCSP) and/or certificate revocation lists (CRLs) to verify the revocation status of certificates. OCSP is preferred since it reduces the overhead associated with CRLs.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67973",
+      "title": "The A10 Networks ADC must not have any unnecessary or unapproved virtual servers configured.",
+      "description": "A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed.\n\nA virtual server is an instance where the device accepts traffic from outside hosts and redirects traffic to one or more real servers. In keeping with a deny-all, permit-by-exception policy, the services that the device provides to outside hosts must be only those that are necessary, documented, and approved.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67975",
+      "title": "The A10 Networks ADC, when used to load balance web applications, must strip HTTP response headers.",
+      "description": "Providing too much information in error messages risks compromising the data and security of the application and system. HTTP response headers can disclose vulnerabilities about a web server. This information can be used by an attacker. The A10 Networks ADC can filter response headers; this removes the web server’s identifying headers in outgoing responses (such as Server, X-Powered-By, and X-AspNet-Version).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67977",
+      "title": "The A10 Networks ADC, when used to load balance web applications, must replace response codes.",
+      "description": "Providing too much information in error messages risks compromising the data and security of the application and system. HTTP response codes can be used by an attacker to learn how a web server responds to particular inputs. Certain codes reveal that a security device or the web server defended against a particular attack, which enables the attacker to eliminate that attack as an option. Using ambiguous response codes makes it more difficult for an attacker to determine what defenses are in place. The A10 Networks ADC can be configured to cloak 4xx and 5xx response codes for outbound responses from a web server. The acceptable HTTP response codes are contained in the preconfigured WAF policy file named \"allowed_resp_codes\".",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67979",
+      "title": "To protect against data mining, the A10 Networks ADC must detect and prevent SQL and other code injection attacks launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections.\n\nThe A10 Networks ADC contains a WAF policy file that provides a basic collection of SQL special characters and keywords that are common to SQL injection attacks. The terms in this policy file can trigger commands in the back-end SQL database and allow unauthorized users to obtain sensitive information. If a request contains a term that matches a search definition in the “sqlia_defs” policy file, the device can be configured to sanitize the request of the SQL command or deny the request entirely. The \"sanitize\" option uses more processor cycles than the preferred option of “drop”.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67981",
+      "title": "To protect against data mining, the A10 Networks ADC must detect and prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67983",
+      "title": "To protect against data mining, the A10 Networks ADC providing content filtering must prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information.\n\nSQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67987",
+      "title": "To protect against data mining, the A10 Networks ADC providing content filtering must detect code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational databases may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67989",
+      "title": "To protect against data mining, the A10 Networks ADC providing content filtering must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational databases may result in the compromise of information.\n\nSQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67991",
+      "title": "To protect against data mining, the A10 Networks ADC providing content filtering as part of its intermediary services must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.",
+      "description": "Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational applications may result in the compromise of information.\n\nInjection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database, or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67993",
+      "title": "The A10 Networks ADC being used for TLS encryption and decryption using PKI-based user authentication must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certificate Authorities (CAs) for the establishment of protected sessions.",
+      "description": "Non-DoD approved PKIs have not been evaluated to ensure that they have security controls and identity vetting procedures in place which are sufficient for DoD systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users.\n\nThe authoritative list of DoD-approved PKIs is published at http://iase.disa.mil/pki-pke/interoperability. DoD-approved PKI CAs may include Category I, II, and III certificates. Category I DoD-Approved External PKIs are PIV issuers. Category II DoD-Approved External PKIs are Non-Federal Agency PKIs cross certified with the Federal Bridge Certification Authority (FBCA). Category III DoD-Approved External PKIs are Foreign, Allied, or Coalition Partner PKIs.\n\nDeploying the device with TLS enabled will require the installation of DoD and/or DoD-Approved CA certificates in the trusted root certificate store of each proxy to be used for TLS traffic.\n\nThis requirement focuses on communications protection for the application session rather than for the network packet.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67995",
+      "title": "The A10 Networks ADC must protect against TCP and UDP Denial of Service (DoS) attacks by employing Source-IP based connection-rate limiting.",
+      "description": "If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.\n\nDetection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components. This requirement applies to the communications traffic functionality of the device as it pertains to handling communications traffic, rather than to the device itself.\n\nThe A10 Networks ADC provides Source-IP based connection-rate limiting to mitigate UDP floods and similar attacks. Source-IP based connection-rate limiting protects the system from excessive connection requests from individual clients. If traffic from a client exceeds the configured threshold, the device should be configured to lock out the client for a specified number of seconds. During the lockout period, all connection requests from the client are dropped. The lockout period ranges from 1-3600 seconds (1 hour); there is no default value.",
+      "severity": "high"
+    },
+    {
+      "id": "V-67997",
+      "title": "The A10 Networks ADC must implement load balancing to limit the effects of known and unknown types of Denial of Service (DoS) attacks.",
+      "description": "Although maintaining high availability is normally an operational consideration, load balancing is also a useful strategy in mitigating network-based DoS attacks. If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Load balancing provides service redundancy which reduces the susceptibility of the enclave to many DoS attacks. Since one of the primary purposes of the Application Delivery Controller is to balance loads across multiple servers, it would be extremely unusual for it to not be configured to perform this function.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-67999",
+      "title": "The A10 Networks ADC must enable DDoS filters.",
+      "description": "If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume, type, or protocol usage. Detection components that use signatures can detect known attacks by using known attack signatures. Signatures are usually obtained from and updated by the vendor.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68001",
+      "title": "The A10 Networks ADC, when used to load balance web applications, must examine incoming user requests against the URI White Lists.",
+      "description": "Unrestricted traffic may contain malicious traffic, which poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.\n\nAccess control policies and access control lists implemented on devices that control the flow of network traffic (e.g., application level firewalls and Web content filters), ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet or CDS) must be kept separate.\n\nThe URI White List defines acceptable destination URIs allowed for incoming requests. The White List Check compares the URI of an incoming request against the rules contained in the URI White List policy file. Connection requests are accepted only if the URI matches a rule in the URI White List. Note: A URI Black List can also be configured, which takes priority over a URI White List. However, since deny-all, permit by exception is a fundamental principle, a URI White List is necessary.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68005",
+      "title": "The A10 Networks ADC, when used to load balance web applications, must enable external logging for WAF data event messages.",
+      "description": "Without coordinated reporting between separate devices, it is not possible to identify the true scale and possible target of an attack.\n\nExternal logging must be enabled for WAF data event messages. External logging is activated once the WAF template that uses the logging template is bound to an HTTP/HTTPS virtual port.",
+      "severity": "low"
+    },
+    {
+      "id": "V-68009",
+      "title": "The A10 Networks ADC must enable logging for packet anomaly events.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nThese systems must generate an alert when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The device must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.\n\nThe A10 Networks ADC must be configured to generate a log message when IP anomalies are detected.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68011",
+      "title": "The A10 Networks ADC must enable logging of Denial of Service (DoS) attacks.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. CJCSM 6510.01B, \"Cyber Incident Handling Program\", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The device must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.\n\nThe A10 Networks ADC must be configured to generate a log message when IP anomalies and DoS attacks are detected.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68013",
+      "title": "The A10 Networks ADC, when used for load-balancing web servers, must not allow the HTTP TRACE and OPTIONS methods.",
+      "description": "HTTP offers a number of methods that can be used to perform actions on the web server. Some of these HTTP methods can be used for nefarious purposes if the web server is misconfigured. The two HTTP methods used for normal requests are GET and POST, so incoming requests should be limited to those methods.\n\nAlthough the HTTP TRACE method is useful for debugging, it enables cross-site scripting attacks. By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE method. The HEAD, GET, POST, and CONNECT methods are generally regarded as safe. For a WAF template, the GET and POST are the default values and are the safest options, so restriction the methods to GET and POST is recommended.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68015",
+      "title": "The A10 Networks ADC must reveal error messages only to authorized individuals (ISSO, ISSM, and SA).",
+      "description": "Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can give configuration details about the network element. Limiting access to system logs and administrative consoles to authorized personnel will help to mitigate this risk. However, user feedback and error messages should also be restricted by type and content in accordance with security best practices (e.g., ICMP messages).\n\nIn the A10 Networks ADC, the audit log is maintained in a separate file separate from the system log. Access to the audit log is role-based. The audit log messages that are displayed for an admin depend upon that administrator’s role (privilege level). Administrators with Root, Read Write, or Read Only privileges who view the audit log can view all the messages, for all system partitions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68019",
+      "title": "The A10 Networks ADC must, at a minimum, off-load audit log records onto a centralized log server.",
+      "description": "Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised.\n\nOff-loading is a common process in information systems with limited audit storage capacity. The audit storage on the device is used only in a transitory fashion until the system can communicate with the centralized log server designated for storing the audit records, at which point the information is transferred. However, DoD requires that the log be transferred in real time which indicates that the time from event detection to off-loading is seconds or less.\n\nThis does not apply to audit logs generated on behalf of the device itself (management).",
+      "severity": "low"
+    },
+    {
+      "id": "V-68021",
+      "title": "The A10 Networks ADC, when used for load balancing web servers, must deploy the WAF in active mode.",
+      "description": "The Web Application Firewall (WAF) supports three operational modes - Learning, Passive, and Active. Active is the standard operational mode and must be used in order to drop or sanitize traffic. Learning mode is used in lab environments to initially set thresholds for certain WAF checks and should not be used in production networks. Passive mode applies enabled WAF checks, but no action is taken upon matching traffic. This mode is useful in identifying false positives for filtering. Only Active mode filters web traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68023",
+      "title": "If the Data Owner requires it, the A10 Networks ADC must be configured to perform CCN Mask, SSN Mask, and PCRE Mask Request checks.",
+      "description": "If outbound communications traffic is not continuously monitored, hostile activity may not be detected and prevented. Output from application and traffic monitoring serves as input to continuous monitoring and incident response programs.\n\nThe A10 Networks ADC can be configured to mask data traversing outbound through the device. This is useful in preventing data exfiltration. If any data must be masked before it leaves the enclave (such as Credit Card Numbers, Social Security Numbers, or other sensitive information), a WAF template can be configured with CCN Mask, SSN Mask, and PCRE Mask Request checks. The Mask Request check depends on what information must be masked. This includes using Perl Compatible Regular Expressions (PCRE) for custom masks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68025",
+      "title": "The A10 Networks ADC must protect against ICMP-based Denial of Service (DoS) attacks by employing ICMP Rate Limiting.",
+      "description": "If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type.\n\nDetection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components. \n\nThe A10 Networks ADC provides an ICMP Rate Limiting feature that monitors the rate of ICMP traffic and drops ICMP packets when the configured thresholds (the normal rate) are exceeded.",
+      "severity": "high"
+    },
+    {
+      "id": "V-68027",
+      "title": "The A10 Networks ADC must protect against TCP SYN floods by using TCP SYN Cookies.",
+      "description": "A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target in an attempt to consume resources, making the device unresponsive to legitimate traffic. TCP SYN Cookies are commonly implemented by the Operating System on endpoints, but are also often implemented on network devices.\n\nA10 Networks ADCs provide protection against TCP SYN flood attacks by using SYN cookies. SYN cookies enable the device to continue to serve legitimate clients during a TCP SYN flood attack without allowing illegitimate traffic to consume system resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-68029",
+      "title": "The A10 Networks ADC must be a FIPS-compliant version.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nFIPS compliance is mandated for many functions of network devices. The A10 Networks ADC platforms are either FIPS-compliant versions or non-compliant versions. It is necessary to deploy the FIPS-compliant versions of the model(s). FIPS versions are identified by the designation \"FIPS\" in the stock keeping unit (SKU).",
+      "severity": "high"
+    },
+    {
+      "id": "V-68105",
+      "title": "The A10 Networks ADC must generate an alert to, at a minimum, the ISSO and ISSM when threats identified by authoritative sources (e.g., IAVMs or CTOs) are detected.",
+      "description": "Without an alert, security personnel may be unaware of major detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nThe device generates an alert which notifies designated personnel of the Indicators of Compromise (IOCs) which require real-time alerts. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise.\nSince these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The device must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.",
+      "severity": "medium"
+    }
+  ]
+}