kriterion 0.0.1

data/standards/stig_juniper_srx_sg_alg.json

@@ -0,0 +1,155 @@
+{
+  "name": "stig_juniper_srx_sg_alg",
+  "date": "2018-04-04",
+  "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": "Juniper SRX SG ALG Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-66003",
+      "title": "For User Role Firewalls, the Juniper SRX Services Gateway Firewall must employ user attribute-based security policies to enforce approved authorizations for logical access to information and system resources.",
+      "description": "Successful authentication must not automatically give an entity access to an asset or security boundary. The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. All DoD systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access.\n\nAuthorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset.\n\nThe Juniper Technical Library, Understanding User Role Firewalls, explains this Juniper SRX functionality in detail. This function integrates user-based firewall policies. Administrators can permit or restrict network access of employees, contractors, partners, and other users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning. User role firewalls are more feasible with sites that do not have production workload and are used for employees to access network resources as opposed to large-scale datacenter environments.\n\nUser role firewalls trigger two actions, retrieval of user and/or role information associated with the traffic, and determine the action to take based on six match criteria within the context of the zone pair.\n\nThe source-identity field distinguishes a user role firewall from other types of firewalls. If the source identity is specified in any policy for a particular zone pair, it is a user role firewall. The user and role information must be retrieved before policy lookup occurs. If the source identity is not specified in any policy, user and role lookup is not required.\n\nTo retrieve user and role information, authentication tables are searched for an entry with an IP address corresponding to the traffic. If an entry is found, the user is classified as an authenticated user. If not found, the user is classified as an unauthenticated user.\n\nThe username and roles associated with an authenticated user are retrieved for policy matching. Both the authentication classification and the retrieved user and role information are used to match the source-identity field.\n\nCharacteristics of the traffic are matched to the policy specifications. Within the zone context, the first policy that matches the user or role and the five standard match criteria determines the action to be applied to the traffic.\"",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66303",
+      "title": "The Juniper SRX Services Gateway must generate log records when firewall filters, security screens and security policies are invoked and the traffic is denied or restricted.",
+      "description": "Without generating log records that log usage of objects by subjects and other objects, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nSecurity objects are data objects which are controlled by security policy and bound to security attributes.\n\nBy default, the Juniper SRX will not forward traffic unless it is explicitly permitted via security policy. Logging for Firewall security-related sources such as screens and security policies must be configured separately. To ensure firewall filters, security screens and security policies send events to a Syslog server and local logs, security logging must be configured one each firewall term.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66305",
+      "title": "The Juniper SRX Services Gateway Firewall must generate audit records when unsuccessful attempts to access security zones occur.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nAccess for different security levels maintains separation between resources (particularly stored data) of different security domains.\n\nThe Juniper SRX Firewall implements security zones which are configured with different security policies based on risk and trust levels.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66307",
+      "title": "The Juniper SRX Services Gateway Firewall must be configured to support centralized management and configuration of the audit log.",
+      "description": "Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.\n\nThe DoD requires centralized management of all network component audit record content. Network components requiring centralized audit log management must have the capability to support centralized management. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Ensure at least one Syslog server and local files are configured to support requirements. However, the Syslog itself must also be configured to filter event records so it is not overwhelmed. A best practice when configuring the external Syslog server is to add similar log-prefixes to the log file names to help and researching of central Syslog server. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX). This requirement does not apply to audit logs generated on behalf of the device itself (management).\n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured and only to local files.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66309",
+      "title": "In the event that communications with the Syslog server is lost, the Juniper SRX Services Gateway must continue to queue traffic log records locally.",
+      "description": "It is critical that when the network element is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.\n\nSince availability is an overriding concern given the role of the Juniper SRX in the enterprise, the system must not be configured to shut down in the event of a log processing failure. The system will be configured to log events to local files which will provide a log backup. If communication with the syslog server is lost or the server fails, the network device must continue to queue log records locally. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local log data with the collection server.\n\nBy default, both traffic log and system log events are sent to a local log file named messages. You can create a separate log file that contains only traffic log messages so that you do not need to filter for traffic log messages. This makes it easier to track usage patterns or troubleshoot issues for a specific policy. \n\nA best practice is to add log-prefixes to the log file names to help in researching the events and filters to prevent log overload. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66311",
+      "title": "The Juniper SRX Services Gateway Firewall must disable or remove unnecessary network services and functions that are not used as part of its role in the architecture.",
+      "description": "Network devices 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 SRX. These 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\nServices that may be related security-related, but based on the role of the device in the architecture do not need to be installed. For example, the Juniper SRX can have an Antivirus, Web filter, IDS, or ALG license. However, if these functions are not part of the documented role of the SRX in the enterprise or branch architecture, then these the software and licenses should not be installed on the device. This mitigates the risk of exploitation of unconfigured services or services that are not kept updated with security fixes. If left unsecured, these services may provide a threat vector.\n\nOnly remove unauthorized services. This control is not intended to restrict the use of Juniper SRX devices with multiple authorized roles.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66313",
+      "title": "The Juniper SRX Services Gateway Firewall must not be configured as an NTP server since providing this network service is unrelated to the role as a firewall.",
+      "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 SRX. These 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 Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated. \n\nThe SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66315",
+      "title": "The Juniper SRX Services Gateway Firewall must not be configured as a DNS proxy since providing this network service is unrelated to the role as a Firewall.",
+      "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 SRX. These 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 Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated. \n\nThe SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66317",
+      "title": "The Juniper SRX Services Gateway Firewall must not be configured as a DHCP server since providing this network service is unrelated to the role as a Firewall.",
+      "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 SRX. These 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 Juniper SRX is a highly configurable platform that can fulfil many roles in the Enterprise or Branch architecture depending on the model installed. Some services are employed for management services; however, these services can often also be provided as a network service on the data plane. Examples of these services are NTP, DNS, and DHCP. Also, as a Next Generation Firewall (NGFW) and Unified Threat Management (UTM) device, the SRX integrate functions which have been traditionally separated. \n\nThe SRX may integrate related content filtering, security services, and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Depending on licenses purchased, gateways may also include email scanning, decryption, caching, VPN, and DLP services. However, services and capabilities which are unrelated to this primary functionality must not be installed (e.g., DNS, email server, FTP server, or web server).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66319",
+      "title": "The Juniper SRX Services Gateway Firewall must be configured to prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services, as defined in the PPSM CAL, 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\nDoD continually assesses the ports, protocols, and services that can be used for network communications. Some ports, protocols or services have known exploits or security weaknesses. Network traffic using these ports, protocols, and services must be prohibited or restricted in accordance with DoD policy. The PPSM CAL and vulnerability assessments provide an authoritative source for ports, protocols, and services that are unauthorized or restricted across boundaries on DoD networks.\n\nThe Juniper SRX 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66321",
+      "title": "The Juniper SRX Services Gateway Firewall must terminate all communications sessions associated with user traffic after 15 minutes or less of inactivity.",
+      "description": "Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.\n\nThis control does not imply that the device terminates all sessions or network access; it only ends the inactive session.\n\nSince many of the inactivity timeouts pre-defined by Junos OS are set to 1800 seconds, an explicit custom setting of 900 must be set for each application used by the DoD implementation. Since a timeout cannot be set directly on the predefined applications, the timeout must be set on the any firewall rule that uses a pre-defined application (i.e., an application that begins with junos-), otherwise the default pre-defined timeout will be used.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66323",
+      "title": "The Juniper SRX Services Gateway Firewall providing content filtering must protect against known and unknown types of Denial of Service (DoS) attacks by implementing statistics-based screens.",
+      "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 \nJuniper SRX Firewall DoS protections can be configured by either using a Screen or within the global flow options. Screens, also known as IDS-options, block various layer 3 and 4 attacks. Screen objects are configured with various screen-specific options and then assigned to a zone. The Juniper SRX can be configured with Screens to protect against the following statistics-based DoS attacks: IP sweeps, port scans, and flood attacks.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66325",
+      "title": "The Juniper SRX Services Gateway Firewall must implement load balancing on the perimeter firewall, at a minimum, to limit the effects of known and unknown types of Denial of Service (DoS) attacks on the network.",
+      "description": "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 ALG to many DoS attacks.\n\nThis requirement applies to the network traffic functionality of the device as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technologies, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented.\n\nThe Juniper SRX provides a number of methods for load balancing the traffic flow. The device can be configured for filter based forwarding, per flow load balancing, per-packet load balancing, or High Availability (HA) using additional hardware. Since the firewall is considered a critical security system, it is imperative that perimeter firewalls, at a minimum, be safeguarded with redundancy measures such as HA.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66327",
+      "title": "The Juniper SRX Services Gateway Firewall must protect against known types of Denial of Service (DoS) attacks by implementing signature-based screens.",
+      "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.\n\nJuniper SRX Firewall DoS protections can be configured by either using a Screen or within the global flow options. Screens, also known as IDS-options, block various layer 3 and 4 attacks. Screen objects are configured with various screen-specific options and then assigned to a zone. The Juniper SRX can be configured with Screens to protect against the following signature-based DoS attacks: ICMP based attacks such as ping of death, IP based attacks such as IP spoofing and teardrop, and TCP based attacks such as TCP headers and land.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66329",
+      "title": "The Juniper SRX Services Gateway Firewall must block outbound traffic containing known and unknown DoS attacks to protect against the use of internal information systems to launch any Denial of Service (DoS) attacks against other networks or endpoints.",
+      "description": "DoS attacks can take multiple forms but have the common objective of overloading or blocking a network or host to deny or seriously degrade performance. If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. The Juniper SRX must include protection against DoS attacks that originate from inside the enclave, which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. These attacks can be simple \"floods\" of traffic to saturate circuits or devices, malware that consumes CPU and memory on a device or causes it to crash, or a configuration issue that disables or impairs the proper function of a device. For example, an accidental or deliberate misconfiguration of a routing table can misdirect traffic for multiple networks.\n\nThe Juniper SRX Firewall uses Screens and Security Policies to detect known DoS attacks with known attack vectors. However, these Screens and policies must be applied to outbound traffic using zones and interface stanzas. \n\nTraffic exits the Juniper SRX by way of interfaces. Security zones are configured for one or more interfaces with the same security requirements for filtering data packets. A security zone implements a security policy for one or multiple network segments. These policies must be applied to inbound traffic as it crosses both the network perimeter and as it crosses internal security domain boundaries.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66331",
+      "title": "The Juniper SRX Services Gateway Firewall must only allow inbound communications from organization-defined authorized sources routed to organization-defined authorized destinations.",
+      "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\nTraffic enters the Juniper SRX by way of interfaces. Security zones are configured for one or more interfaces with the same security requirements for filtering data packets. A security zone implements a security policy for one or multiple network segments. These policies must be applied to inbound traffic as it crosses the network perimeter and as it crosses internal security domain boundaries.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66333",
+      "title": "The Juniper SRX Services Gateway Firewall must be configured to fail securely in the event of an operational failure of the firewall filtering or boundary protection function.",
+      "description": "If a boundary protection device fails in an unsecure manner (open), information external to the boundary protection device may enter, or the device may permit unauthorized information release.\n\nSecure failure ensures when a boundary control device fails, all traffic will be subsequently denied.\n\nFail secure is a condition achieved by employing information system mechanisms to ensure in the event of operational failures of boundary protection devices at managed interfaces (e.g., routers, firewalls, guards, and application gateways residing on protected subnetworks commonly referred to as demilitarized zones), information systems do not enter into unsecure states where intended security properties no longer hold.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66335",
+      "title": "The Juniper SRX Services Gateway Firewall must deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).",
+      "description": "A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed.\n\nAs a managed interface, the ALG must block all inbound and outbound network communications traffic to the application being managed and controlled unless a policy filter is installed to explicitly allow the traffic. The allow policy filters must comply with the site's security policy. A deny all, permit by exception network communications traffic policy ensures that only those connections which are essential and approved, are allowed.\n\nBy default, Junos denies all traffic through an SRX Series device using an implicit default security policy exists that denies all packets. Organizations must configure security policies that permits or redirects traffic in compliance with DoD policies and best practices. Sites must not change the factory-default security policies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66337",
+      "title": "The Juniper SRX Services Gateway Firewall must configure ICMP to meet DoD requirements.",
+      "description": "Providing too much information in error messages risks compromising the data and security of the application and system.\n\nOrganizations carefully consider the structure/content of error messages. The required information within error messages will vary based on the protocol and error condition. Information that could be exploited by adversaries includes ICMP messages that reveal the use of firewalls or access-control lists.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66339",
+      "title": "The Juniper SRX Services Gateway Firewall must continuously monitor all inbound communications traffic for unusual/unauthorized activities or conditions.",
+      "description": "If inbound 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 Juniper SRX is a highly scalable system which, by default, provides stateful or stateless continuous monitoring when placed in the architecture at either the perimeter or internal boundaries. \n\nUnusual/unauthorized activities or conditions may include unusual use of unusual protocols or ports and attempted communications from trusted zones to external addresses. \n\nInterfaces with identical security requirements can be grouped together into a single security zone. By default, once a security policy is applied to a zone, the Juniper SRX continuously monitors the associated zone for unusual/unauthorized activities or conditions based on the firewall filter or screen associated with that zone.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66341",
+      "title": "The Juniper SRX Services Gateway Firewall must continuously monitor outbound communications traffic for unusual/unauthorized activities or conditions.",
+      "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 Juniper SRX is a highly scalable system which can provide stateful or stateless continuous monitoring when placed in the architecture at either the perimeter or internal boundaries. Unusual/unauthorized activities or conditions may include unusual use of unusual protocols or ports and attempted communications from trusted zones to external addresses.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66343",
+      "title": "The Juniper SRX Services Gateway Firewall must generate an alert to, at a minimum, the ISSO and ISSM when unusual/unauthorized activities or conditions are detected during continuous monitoring of communications traffic as it traverses inbound or outbound across internal security boundaries.",
+      "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\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\nIn accordance with CCI-001242, the ALG which provides content inspection services is a real-time intrusion detection system. These systems must generate an alert when detection events from real-time monitoring occur as required by CCI-2262 and CCI-2261. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n\nUnusual/unauthorized activities or conditions may include large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66345",
+      "title": "The Juniper SRX Services Gateway Firewall must generate an alert that can be forwarded to, at a minimum, the ISSO and ISSM when threats identified by authoritative sources 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 ALG generates an alert that 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.\n\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 ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n\nAuthoritative sources include USSTRATCOM warning and tactical directives/orders including Fragmentary Order (FRAGO), Communications Tasking Orders (CTOs), IA Vulnerability Notices, Network Defense Tasking Message (NDTM), DOD GIG Tasking Message (DGTM), and Operations Order (OPORD).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66347",
+      "title": "The Juniper SRX Services Gateway Firewall must generate an alert that can be forwarded to, at a minimum, the ISSO and ISSM when DoS incidents 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 ALG generates an alert that 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.\n\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\nCJCSM 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.\n\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG 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"
+    }
+  ]
+}

data/standards/stig_juniper_srx_sg_idps.json

@@ -0,0 +1,179 @@
+{
+  "name": "stig_juniper_srx_sg_idps",
+  "date": "2017-07-07",
+  "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": "Juniper SRX SG IDPS Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-66009",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must install updates for predefined signature objects, applications signatures, IDPS policy templates, and device software when new releases are available in accordance with organizational configuration management policy and procedures.",
+      "description": "Failing to update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. \n\nThe IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be updated, including application software files, anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.\n\nUpdates must be installed in accordance with the CCB procedures for the local organization. However, at a minimum: \n\n1. Updates designated as critical security updates by the vendor must be installed immediately.\n\n2. Updates for predefined signature objects, applications signatures, IDPS policy templates, and device software must be installed immediately.\n\n3. Updates for application software are installed in accordance with the CCB procedures.\n\n4. Prior to automatically installing updates, either manual or automated integrity and authentication checking is required, at a minimum, for application software updates.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66377",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must provide audit record generation capability for detecting events based on implementation of policy filters, rules, and signatures.",
+      "description": "Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe Juniper SRX with IDP-enabled policies has the capability to capture and log detected security violations and potential security violations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66383",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must enforce approved authorizations by restricting or blocking the flow of harmful or suspicious communications traffic within the network as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "The flow of all communications traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data.\n\nRestricting the flow of communications traffic, also known as Information flow control, regulates where information is allowed to travel as opposed to who is allowed to access the information and without explicit regard to subsequent accesses to that information.\n\nThe IDPS will include policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses internal network boundaries. The IDPS monitors for harmful or suspicious information flows and restricts or blocks this traffic based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.\n\nThe PPSM CAL addresses internal network boundaries restrictions based on traffic type and content such as ports, protocols and services. The Juniper SRX denies all traffic.\n\nIDPS inspection will only be performed on the traffic matching the security policies where IDPS is enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66385",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must restrict or block harmful or suspicious communications traffic between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.",
+      "description": "The IDPS enforces approved authorizations by controlling the flow of information between interconnected networks to prevent harmful or suspicious traffic does spread to these interconnected networks.\n\nInformation flow control policies and restrictions govern where information is allowed to travel as opposed to who is allowed to access the information. The IDPS includes policy filters, rules, signatures, and behavior analysis algorithms that inspects and restricts traffic based on the characteristics of the information and/or the information path as it crosses external/perimeter boundaries. IDPS components are installed and configured such that they restrict or block detected harmful or suspect information flows based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.\n\nOnce an attack object in the IPS policy is matched, the SRX can execute an action on that specific session, along with actions on future sessions. The ability to execute an action on that particular session is known as an IDPS action. IDPS actions can be one of the following: No-Action, Drop-Packet, Drop-Connection, Close-Client, Close-Server, Close-Client-and-Server, DSCP-Marking, Recommended, or Ignore. IP actions are actions that can be enforced on future sessions. These actions include IP-Close, IP-Block, and IP-Notify\n\nThis includes traffic between interfaces that are associated within the same security zone (intra-zone traffic). Traffic is permitted between security zones by configuring security policies from a source security zone to the destination security zone. IDPS inspection will only be performed on the traffic matching the security policies where IDPS is enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66387",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must provide audit record generation with a configurable severity and escalation level capability.",
+      "description": "Without the capability to generate audit records with a severity code it is difficult to track and handle detection events.\n\nWhile auditing and logging are closely related, they are not the same. Logging is recording data about events that take place in a system, while auditing is the use of log records to identify security-relevant information such as system or user accesses. In short, log records are audited to establish an accurate history. Without logging, it would be impossible to establish an audit trail.\n\nThe IDPS must have the capability to collect and log the severity associated with the policy, rule, or signature. IDPS products often have either pre-configured and/or a configurable method for associating an impact indicator or severity code with signatures and rules, at a minimum.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66395",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must block outbound traffic containing known and unknown DoS attacks by ensuring that rules are applied to outbound communications traffic.",
+      "description": "The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. \n\nInstallation of IDPS detection and prevention components (i.e., sensors) 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\nTo comply with this requirement, the IDPS must inspect outbound traffic for indications of known and unknown DoS attacks. Sensor log capacity management along with techniques which prevent the logging of redundant information during an attack also guard against DoS attacks. This requirement is used in conjunction with other requirements which require configuration of security policies, signatures, rules, and anomaly detection techniques and are applicable to both inbound and outbound traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66399",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must block outbound traffic containing known and unknown DoS attacks by ensuring that signature-based objects are applied to outbound communications traffic.",
+      "description": "The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. \n\nTo perform signature-based attacks on the Juniper SRX IDPS device, create a signature-based attack object.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66401",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must block outbound traffic containing known and unknown DoS attacks by ensuring that anomaly-based attack objects are applied to outbound communications traffic.",
+      "description": "The IDPS must include protection against DoS attacks that originate from inside the enclave which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. \n\nTo perform anomaly-based attacks on the Juniper SRX IDPS device, create an anomaly-based attack object.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66403",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment.",
+      "description": "Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an email attachment or embedded in other file formats not traditionally associated with executable code. \n\nWhile the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.\n\nTo monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66405",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must block any prohibited mobile code at the enclave boundary when it is detected.",
+      "description": "Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an email attachment or embedded in other file formats not traditionally associated with executable code. \n\nWhile the IDPS cannot replace the anti-virus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented, which provide preemptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by anti-virus or malicious code solution vendors.\n\nTo block known prohibited mobile code or approved mobile code that violates permitted usage requirements, the IDPS must implement policy filters, rules, signatures, and anomaly analysis.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66407",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS must prevent 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 detect attacks that use unauthorized data mining techniques to attack 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. \n\nIDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66409",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS must 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 detect attacks that use unauthorized data mining techniques to attack 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.\n\nIDPS component(s) with the capability to prevent code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66411",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS 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 detect attacks that use unauthorized data mining techniques to attack 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.\n\nIDPS component(s) with the capability to prevent SQL code injections must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66413",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS must detect 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 detect attacks that use unauthorized data mining techniques to attack 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.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation to protect against unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66415",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS 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 that use unauthorized data mining techniques to attack 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.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation. These components must include rules and anomaly detection algorithms to monitor for atypical application behavior, commands, and accesses.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66417",
+      "title": "To protect against unauthorized data mining, the Juniper Networks SRX Series Gateway IDPS 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 that use unauthorized data mining techniques to attack 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.\n\nIDPS component(s) with anomaly detection must be included in the IDPS implementation to monitor for and detect unauthorized data mining. These components must include rules and anomaly detection algorithms to monitor for SQL injection attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66419",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must protect against or limit the effects of known and unknown types of Denial of Service (DoS) attacks by employing rate-based attack prevention behavior analysis.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users.\n\nInstallation of IDPS detection and prevention components (i.e., sensors) 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 Juniper SRX must be configured with screens using the Firewall STIG, but must also be configured for anomaly-based protection using various locally developed anomaly-based attack objects.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66421",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must protect against or limit the effects of known and unknown types of Denial of Service (DoS) attacks by employing anomaly-based detection.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users.\n\nInstallation of IDPS components (i.e., sensors) 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.\n\nDetection components that use pattern recognition pre-processors 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.\n\nThis requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself. The Juniper SRX must be configured with screens using the Firewall STIG, but must also be configured for anomaly-based protection using various locally developed anomaly-based attack objects.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66423",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must protect against or limit the effects of known types of Denial of Service (DoS) attacks by employing signatures.",
+      "description": "If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. \n\nInstallation of IDPS detection and prevention components (i.e., sensors) 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.\n\nDetection components that use signatures can detect known attacks by using known attack signatures. Signatures are usually obtained from and updated by the IDPS component vendor. These attacks include SYN-flood, ICMP-flood, and Land Attacks.\n\nThis requirement applies to the communications traffic functionality of the IDPS as it pertains to handling communications traffic, rather than to the IDPS device itself. The Juniper SRX must be configured with screens using the Firewall STIG to protect against flood and DOS attacks type attacks, but must also be configured for anomaly-based protection",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66425",
+      "title": "The IDPS must send an alert to, at a minimum, the ISSO and ISSM when intrusion detection events are detected that indicate a compromise or potential for compromise.",
+      "description": "Without an alert, security personnel may be unaware of intrusion detection incidents that require immediate action and this delay may result in the loss or compromise of information.\n\nIn accordance with CCI-001242, the IDPS is a real-time intrusion detection system. These 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 IDPS 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. The Juniper SRX IDPS can be configured for email alerts.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66427",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must generate an alert to, at a minimum, the ISSO and ISSM when root-level intrusion events that provide unauthorized privileged access 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\nCJCSM 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 I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. 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\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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. The Juniper SRX IDPS can be configured for email alerts.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66429",
+      "title": "The IDPS must send an alert to, at a minimum, the ISSO and ISSM when DoS incidents 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\nCJCSM 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 I, II, IV, and VII detection events) will require an alert when an event is detected.\n\nAlerts messages must include a severity level indicator or code as an indicator of the criticality of the incident. 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\nAlerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The IDPS 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. The Juniper SRX IDPS can be configured for email alerts.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66431",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must automatically install updates to signature definitions.",
+      "description": "Failing to automatically update malicious code protection mechanisms, including application software files, signature definitions, and vendor-provided rules, leaves the system vulnerable to exploitation by recently developed attack methods and programs. An automatic update process ensures this important task is performed without the need for Security Control Auditor (SCA) intervention.\n\nThe IDPS is a key malicious code protection mechanism in the enclave infrastructure. To ensure this protection is responsive to changes in malicious code threats, IDPS components must be automatically updated, including anti-virus signatures, detection heuristics, vendor-provided rules, and vendor-provided signatures.\n\nIf a DoD patch management server or update repository having the tested/verified updates is available for the IDPS component, the components must be configured to automatically check this server/site for updates and install new updates. \n\nIf a DoD server/site is not available, the component must be configured to automatically check a trusted vendor site for updates. A trusted vendor is either commonly used by DoD, specifically approved by DoD, the vendor from which the equipment was purchased, or approved by the local program's CCB.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66433",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must perform real-time monitoring of files from external sources at network entry/exit points.",
+      "description": "Real-time monitoring of files from external sources at network entry/exit points helps to detect covert malicious code before it is downloaded to or executed by internal and external endpoints. Using malicious code, such as viruses, worms, Trojan horses, and spyware, an attacker may gain access to sensitive data and systems.\n\nIDPSs innately meet this requirement for real-time scanning for malicious code when properly configured to meet the requirements of this STIG. However, most products perform communications traffic inspection at the packet level.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66435",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must drop packets or disconnect the connection when malicious code is detected.",
+      "description": "Configuring the IDPS to discard and/or redirect based on local organizational incident handling procedures minimizes the impact of this code on the network.\n\nOnce an attack object in the IPS policy is matched, the SRX can execute an action on that specific session, along with actions on future sessions. The ability to execute an action on that particular session is known as an IDPS action. IDPS actions can be one of the following: No-Action, Drop-Packet, Drop-Connection, Close-Client, Close-Server, Close-Client-and-Server, DSCP-Marking, Recommended, or Ignore. IP actions are actions that can be enforced on future sessions. These actions include IP-Close, IP-Block, and IP-Notify",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66437",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must send an immediate alert to, at a minimum, the Security Control Auditor (SCA) when malicious code is detected.",
+      "description": "Without an alert, security personnel may be unaware of an impending failure of the audit capability, and the ability to perform forensic analysis and detect rate-based and other anomalies will be impeded.\n\nThe IDPS generates an immediate (within seconds) alert which notifies designated personnel of the incident. Sending a message to an unattended log or console does not meet this requirement since that will not be seen immediately. These messages should include a severity level indicator or code as an indicator of the criticality of the incident.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66439",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must have only active Juniper Networks licenses.",
+      "description": "If the IDP or UTM licenses are allowed to lapse, the Juniper SRX IDPS can still inspect traffic and continue to use the outdated signature database for rules, objects, and dynamic groups. However, updates to the signature database cannot be downloaded from Juniper Networks. This puts the network at risk since the updates are used to addresses new CERT and IAVM vulnerabilities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66441",
+      "title": "The Juniper Networks SRX Series Gateway IDPS must either forward the traffic from inbound connections to be more deeply inspected for malicious code and Layer 7 threats, or the Antivirus and Unified Threat Management (UTM) license must be installed, active, and policies and rules configured.",
+      "description": "UTM is an industry term that was coined to define Layer 7 protection against client-side threats. This does not include IPS (which also has protection against server-to-client attacks) but rather technologies such as network-based antivirus protection, URL filtering, antispam solutions, and content filtering. IPS is primarily focused on network-based attacks on protocols, and is stream based, meaning that it processes traffic inline without modifying it as a stream. This works great from a performance perspective to detect attacks against services and applications. UTM, on the other hand, is meant more for protecting against files that are transmitted on top of the network streams. Although IPS might be more geared for detecting an overflow of the parser of the network stream, it isn’t as well geared for detecting threats within files. That is, it certainly can detect such file-based attacks, but attackers can go to great lengths to encode, encrypt, and obfuscate files to perform some malicious action—and it is very difficult to detect these attacks in Stream mode.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_juniper_srx_sg_ndm.json

@@ -0,0 +1,443 @@
+{
+  "name": "stig_juniper_srx_sg_ndm",
+  "date": "2017-01-05",
+  "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": "Juniper SRX SG NDM Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-66015",
+      "title": "If the loopback interface is used, the Juniper SRX Services Gateway must protect the loopback interface with firewall filters for known attacks that may exploit this interface.",
+      "description": "The loopback interface is a logical interface and has no physical port. Since the interface and addresses ranges are well-known, this port must be filtered to protect the Juniper SRX from attacks.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66443",
+      "title": "For local accounts, the Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when local accounts are created.",
+      "description": "An authorized insider or individual who maliciously creates a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously created.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n\nAlthough, based on policy, administrator accounts must be created on the AAA server, thus this requirement addresses the creation of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66445",
+      "title": "The Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when the local accounts (i.e., the account of last resort or root account) are modified.",
+      "description": "An authorized insider or individual who maliciously modifies a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously modified.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n \nAlthough, based on policy, administrator accounts must be modified on the AAA server, thus this requirement addresses the modification of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66447",
+      "title": "The Juniper SRX Services Gateway must generate alerts to the management console and generate a log record that can be forwarded to the ISSO and designated system administrators when the local accounts (i.e., the account of last resort or root account) are deleted.",
+      "description": "An authorized insider or individual who maliciously delete a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously deleted.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n\nAlthough, based on policy, administrator accounts must be deleted on the AAA server, this requirement addresses the deletion of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).\n\nAccounts can be disabled by configuring the account with the built-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66449",
+      "title": "The Juniper SRX Services Gateway must be configured to use a centralized authentication server to authenticate privileged users for remote and nonlocal access for device management.",
+      "description": "Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.\n\nThe Juniper SRX supports three methods of user authentication: local password authentication, Remote Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access Control System Plus (TACACS+). RADIUS and TACACS+ are remote access methods used for management of the Juniper SRX. The local password method will be configured for use only for the account of last resort; however, it will not be used for remote and nonlocal access or this will result in a CAT 1 finding (CCI-000765).\n\nThis requirement references identification and authentication and does not prevent the configuration of privileges using the remote template account (CCI-000213).",
+      "severity": "high"
+    },
+    {
+      "id": "V-66451",
+      "title": "If SNMP is enabled, the Juniper SRX Services Gateway must use and securely configure SNMPv3.",
+      "description": "To prevent non-secure protocol communications with the organization's local SNMPv3 services, the SNMP client on the Juniper SRX must be configured for proper identification and strong cryptographically-based protocol for authentication.\n\nSNMPv3 defines a user-based security model (USM), and a view-based access control model (VACM). SNMPv3 USM provides data integrity, data origin authentication, message replay protection, and protection against disclosure of the message payload. SNMPv3 VACM provides access control to determine whether a specific type of access (read or write) to the management information is allowed.\n\nThe Junos operating system allows the use of SNMPv3 to monitor or query the device for management purposes. Junos does not allow SNMPv3, of any type, to be used to make configuration changes to the device. SNMPv3 is disabled by default and must be enabled for use. SNMPv3 is the DoD-preferred method for monitoring the device securely. If SNMPv3 is not being used, it must be disabled. The following commands will configure SNMPv3. The Junos operating system allows the use of FIPS approved protocols for both authentication (SHA1) and for privacy (AES128). These protocols should be used to ensure secure management connections.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66453",
+      "title": "For nonlocal maintenance sessions using SNMP, the Juniper SRX Services Gateway must use and securely configure SNMPv3 with SHA to protect the integrity of maintenance and diagnostic communications.",
+      "description": "Without cryptographic integrity protections, information can be altered by unauthorized users without detection.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n \nThe Juniper SRX allows the use of SNMP to monitor or query the device in support of diagnostics information. SNMP cannot be used to make configuration changes; however, it is a valuable diagnostic tool. SNMP is disabled by default and must be enabled for use. SNMPv3 is the DoD-required version, but must be configured to be used securely.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66455",
+      "title": "For nonlocal maintenance sessions using SNMP, the Juniper SRX Services Gateway must securely configure SNMPv3 with privacy options to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.",
+      "description": "Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n \nTo protect the confidentiality of nonlocal maintenance sessions, SNMPv3 with AES encryption to must be configured to provide confidentiality. The Juniper SRX allows the use of SNMPv3 to monitor or query the device in support of diagnostics information. SNMP cannot be used to make configuration changes; however, it is a valuable diagnostic tool. SNMP is disabled by default and must be enabled for use. SNMPv3 is the DoD-required version, but must be configured to be used securely.",
+      "severity": "high"
+    },
+    {
+      "id": "V-66457",
+      "title": "The Juniper SRX Services Gateway must automatically terminate a network administrator session after organization-defined conditions or trigger events requiring session disconnect.",
+      "description": "Automatic session termination addresses the termination of administrator-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). \n\nConditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. These conditions will vary across environments and network device types.\n\nThe Juniper SRX can be configured to limit login times or to logout users after a certain time period if desired by the organization. These setting are configured as options on the login class to which they apply.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66459",
+      "title": "For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account creation events.",
+      "description": "Upon gaining access to a network device, an attacker will often first attempt to create a persistent method of reestablishing access. One way to accomplish this is to create a new account. Notification of account creation helps to mitigate this risk. Auditing account creation provides the necessary reconciliation that account management procedures are being followed. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66461",
+      "title": "For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account modification events.",
+      "description": "Upon gaining access to a network device, an attacker will often first attempt to modify existing accounts to increase/decrease privileges. Notification of account modification events help to mitigate this risk. Auditing account modification events provides the necessary reconciliation that account management procedures are being followed. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66463",
+      "title": "For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account disabling events.",
+      "description": "When device management accounts are disabled, user or service accessibility may be affected. Auditing also ensures authorized, active accounts remain enabled and available for use when required. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66465",
+      "title": "For local accounts created on the device, the Juniper SRX Services Gateway must automatically generate log records for account removal events.",
+      "description": "Auditing account removal actions will support account management procedures. When device management accounts are terminated, user or service accessibility may be affected. Auditing also ensures authorized active accounts remain enabled and available for use when required. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nAn AAA server is required for account management in accordance with CCI-000370. Only a single account of last resort is permitted on the local device. However, since it is still possible for administrators to create local accounts either maliciously or to support mission needs, the SRX must be configured to log account management events.\n\nTo log local account management events, ensure at least one external syslog server is configured to log facility any or facility change-log, and severity info or severity any.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66467",
+      "title": "The Juniper SRX Services Gateway must generate an alert message to the management console and generate a log event record that can be forwarded to the ISSO and designated system administrators when accounts are disabled.",
+      "description": "An authorized insider or individual who maliciously disables a local account could gain immediate access from a remote location to privileged information on a critical security device. Sending an alert to the administrators and ISSO when this action occurs greatly reduces the risk that accounts will be surreptitiously disabled.\n\nAutomated mechanisms can be used to send automatic alerts or notifications. Such automatic alerts or notifications can be conveyed in a variety of ways (e.g., telephonically, via electronic mail, via text message, or via websites). The ALG 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. Alerts must be sent immediately to designated individuals. Alerts may be sent via NMS, SIEM, Syslog configuration, SNMP trap or notice, or manned console message.\n\nAlthough, based on policy, administrator accounts must be disabled on the AAA server,  this requirement addresses the disabling of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66469",
+      "title": "The Juniper SRX Services Gateway must automatically generate a log event when accounts are enabled.",
+      "description": "Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Notification of account enabling is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO). Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.\n\nAccounts can be disabled by configuring the account with the build-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66471",
+      "title": "The Juniper SRX Services Gateway must generate an immediate alert message to the management console for account enabling actions.",
+      "description": "In order to detect and respond to events that affect network administrator accessibility and device processing, network devices must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\nAccounts can be disabled by configuring the account with the built-in login class \"unauthorized\". When the command is reissued with a different login class, the account is enabled.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66473",
+      "title": "The Juniper SRX Services Gateway must enforce the assigned privilege level for each administrator and authorizations for access to all commands by assigning a login class to all AAA-authenticated users.",
+      "description": "To mitigate the risk of unauthorized privileged access to the device, administrators must be assigned only the privileges needed to perform the tasked assigned to their roles. \n\nAlthough use of an AAA server is required for non-local access for device management, the SRX must also be configured to implement the corresponding privileges upon user login. Each externally authenticated user is assigned a template that maps to a configured login class.\n\nAAA servers are usually configured to send a Vendor Specific Attribute (VSA) to the Juniper SRX. The device uses this information to determine the login class to assign to the authenticated user. Unless a VSA is returned from the AAA server, externally-authenticated users are mapped to the “remote” user by default. Remote user is a special default account in Junos OS. If this default account, or another designated remote user account, is not configured, then only externally-authenticated users with a returned VSA of a local template account are permitted login. If the remote user is configured, all externally-authenticated users without a returned VSA default to the remote user account's configured login class. All externally-authenticated users with a returned VSA inherit the login class configured for each respective template account.\n\nJunos OS provides four built-in login classes: super-user (all permissions), operator (limited permissions), read-only (no change permissions), and unauthorized (prohibits login). Because these classes are not configurable by the system administrator, they should not be used except for the unauthorized class which may be used for the remote user to deterministically prohibit logins from externally-authenticated users without a returned VSA. Therefore, all template user accounts, and the local account of last resort, should use custom, user-defined, login classes.\n\nExternally-authenticated users maintain two account names in Junos OS: the user and login names. The user name is the local template account name and the login name is the authenticated user’s external account name. Junos OS links the names to determine permissions, based upon login class, but uses the external account name for logging. Doing so permits multiple, individually-authenticated users, to be mapped to the same template account, and therefore enforce uniform permissions for each group of administrators, while also attributing any logged changes to the appropriate individual user.\n\nTemplate accounts are differentiated from local accounts by the presence of an authentication stanza; only the local account of last resort should have an authentication stanza.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66475",
+      "title": "The Juniper SRX Services Gateway must enable log record generation for DoD-defined auditable events within the Juniper SRX Service Gateway.",
+      "description": "Without the capability to generate log records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nDoD has defined the list of events for which the device will provide an audit record generation capability. These events as the following which are individually called out in other CCIs: \n\n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);\n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and\n(iii) All account creation, modification, disabling, and termination actions.\n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured by default to local files. \n\nEnsure the Syslog server and local files are configured to support requirements. A best practice when configuring the external Syslog server is to add similar log-prefixes to the log file names to help and researching of central Syslog server. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66477",
+      "title": "For local log files, the Juniper SRX Services Gateway must allocate log storage capacity in accordance with organization-defined log record storage requirements so that the log files do not grow to a size that causes operational issues.",
+      "description": "In order to ensure network devices have a sufficient storage capacity in which to write the logs, they need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial device setup if it is modifiable. \n\nThe amount allocated for the organization-defined audit record storage requirement will depend on the amount of storage available on the network device, the anticipated volume of logs, and how long the logs are kept on the device. Since the Syslog is the primary audit log, the local log is not essential to keep archived for lengthy periods, thus the allocated space on the device should be low.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66479",
+      "title": "The Juniper SRX Services Gateway must generate an immediate system alert message to the management console when a log processing failure is detected.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required. Without an immediate alert for critical system issues, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system). \n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded.\n\nWhile this requirement also applies to the configuration of the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX can also be configured to generate a message to the administrator console or send via email for immediate messages.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertaining to errors encountered by system processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66481",
+      "title": "In the event that communications with the events server is lost, the Juniper SRX Services Gateway must continue to queue log records locally.",
+      "description": "It is critical that when the network device is at risk of failing to process logs as required, it take action to mitigate the failure. Log processing failures include: software/hardware errors; failures in the log capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to log failure depend upon the nature of the failure mode. \n\nSince availability is an overriding concern given the role of the Juniper SRX in the enterprise, the system must not be configured to shut down in the event of a log processing failure. The system will be configured to log events to local files, which will provide a log backup. If communication with the Syslog server is lost or the server fails, the network device must continue to queue log records locally. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local log data with the collection server.\n\nA best practice is to add log-prefixes to the log file names to help in researching the events and filters to prevent log overload. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX). Thus, the Juniper SRX will inherently and continuously capture events to local files to guard against the loss of connectivity to the primary and secondary events server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66483",
+      "title": "The Juniper SRX Services Gateway must record time stamps for log records using Coordinated Universal Time (UTC).",
+      "description": "If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. UTC is normally used in DoD; however, Greenwich Mean Time (GMT) may be used if needed for mission requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66485",
+      "title": "The Juniper SRX Services Gateway must implement logon roles to ensure only authorized roles are allowed to install software and updates.",
+      "description": "Allowing anyone to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. This requirement applies to code changes and upgrades for all network devices.\n\nFor example audit admins and the account of last resort are not allowed to perform this task.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66487",
+      "title": "The Juniper SRX Services Gateway must be configured to synchronize internal information system clocks with the primary and secondary NTP servers for the network.",
+      "description": "The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on log events and other functions. \n\nMultiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must utilize an authoritative time server and/or be configured to use redundant authoritative time sources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66489",
+      "title": "The Juniper SRX Services Gateway must be configured to use an authentication server to centrally manage authentication and logon settings for remote and nonlocal access.",
+      "description": "Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device. \n\nThe Juniper SRX supports three methods of user authentication: local password authentication, Remote Authentication Dial-In User Service (RADIUS), and Terminal Access Controller Access Control System Plus (TACACS+). RADIUS and TACACS+ are remote access methods used for management of the Juniper SRX. The local password method will be configured for use only for the account of last resort.\n\nTo completely set up AAA authentication, create a user template account (the default name is remote) and specify a system authentication server and an authentication order. See CCI-000213 for more details. The remote user template is not a logon account. Once the AAA server option is configured, any remote or nonlocal access attempts are redirected to the AAA server. Since individual user accounts are not defined on the SRX, the authentication server must be used to manage individual account settings.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66491",
+      "title": "The Juniper SRX Services Gateway must be configured to use an authentication server to centrally apply authentication and logon settings for remote and nonlocal access for device management.",
+      "description": "Centralized application (e.g., TACACS+, RADIUS) of authentication settings increases the security of remote and nonlocal access methods. This control is a particularly important protection against the insider threat. Audit records for administrator accounts access to the organization's network devices can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each network device.\n\nThis requirement references identification and authentication and does not prevent the configuration of privileges using the remote template account (CCI-000213).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66493",
+      "title": "The Juniper SRX Services Gateway must use DoD-approved PKI rather than proprietary or self-signed device certificates.",
+      "description": "To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs.\n\nThe SRX generates a key-pair and a CSR. The CSR is sent to the approved CA, who signs it and returns it as a certificate. That certificate is then installed. \n\nThe process to obtain a device PKI certificate requires the generation of a Certificate Signing Request (CSR), submission of the CSR to a CA, approval of the request by an RA, and retrieval of the issued certificate from the CA.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66495",
+      "title": "The Juniper SRX Services Gateway must generate an alarm or send an alert message to the management console when a component failure is detected.",
+      "description": "Component (e.g., chassis, file storage, file corruption) failure may cause the system to become unavailable, which could result in mission failure since the network would be operating without a critical security traffic inspection or access function.\n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nWhile this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX must also be configured to generate a message to the administrator console.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertain to errors encountered by system processes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66497",
+      "title": "The Juniper SRX Services Gateway must be configured to prohibit the use of unnecessary and/or nonsecure 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 unused or unnecessary physical and logical ports/protocols on information systems.\n\nThe control plane is responsible for operating most of the system services on the SRX. The control plane is responsible not only for acting as the interface for the administrator operating the device, but also for controlling the operation of the chassis, pushing the configuration to the data plane, and operating the daemons that provide functionality to the system. The control plane operates the Junos OS, which is a FreeBSD variant. \n\nThe Juniper SRX control plane services include, but are not limited to, the following: Management Daemon (MGD), Routing Protocol Daemon (RPD) (e.g., RIP, OSPF, IS-IS, BGP, PIM, IPv6 counterparts), User interfaces (SSH, J-Web, NetConf), File system interfaces (SCP), Syslogd (DNS, DHCP, NTP, ICMP, ARP/ND, SNMP), Chassisd, JSRPD (HA clustering).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66499",
+      "title": "For nonlocal maintenance sessions, the Juniper SRX Services Gateway must remove or explicitly deny the use of nonsecure protocols.",
+      "description": "If unsecured protocols (lacking cryptographic mechanisms) are used for sessions, the contents of those sessions will be susceptible to manipulation, potentially allowing alteration and hijacking of maintenance sessions.\n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nTools used for nonlocal management and diagnostics with the Juniper SRX include SSH but may also include compatible enterprise maintenance and diagnostics servers. Regardless of the tool used, the Juniper SRX must permit only the use of protocols with the capability to be configured securely with integrity protections. Specifically, use SSH instead of Telnet, SCP instead of FTP, and SNMPv3 rather than other versions SNMP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66501",
+      "title": "The Juniper SRX Services Gateway must authenticate NTP servers before establishing a network connection using bidirectional authentication that is cryptographically based.",
+      "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk, such as remote connections.\n\nThe Juniper SRX can only be configured to use MD5 authentication keys. This algorithm is not FIPS 140-2 validated; thus, a CAT 1 finding is allocated in CCI-000803. However, MD5 is preferred to no authentication at all.\n\nThe trusted-key statement permits authenticating NTP servers. The Juniper SRX supports multiple keys, multiple NTP servers, and different keys for each server; add the “key <key number>” parameter to the server statement to associate a key with a specific server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66503",
+      "title": "The Juniper SRX Services Gateway must ensure SSH is disabled for root user logon to prevent remote access using the root account.",
+      "description": "Since the identity of the root account is well-known for systems based upon Linux or UNIX and this account does not have a setting to limit access attempts, there is risk of a brute force attack on the password. Root access would give superuser access to an attacker. Preventing attackers from remotely accessing management functions using root account mitigates the risk that unauthorized individuals or processes may gain superuser access to information or privileges.\n\nA separate account should be used for access and then the administrator can sudo to root when necessary.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66507",
+      "title": "The Juniper SRX Services Gateway must ensure access to start a UNIX-level shell is restricted to only the root account.",
+      "description": "Restricting the privilege to create a UNIX-level shell limits access to this powerful function. System administrators, regardless of their other permissions, will need to also know the root password for this access, thus limiting the possibility of malicious or accidental circumvention of security controls.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66509",
+      "title": "The Juniper SRX Services Gateway must ensure TCP forwarding is disabled for SSH to prevent unauthorized access.",
+      "description": "Use this configuration option to prevent a user from creating an SSH tunnel over a CLI session to the Juniper SRX via SSH. This type of tunnel could be used to forward TCP traffic, bypassing any firewall filters or ACLs, allowing unauthorized access.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66511",
+      "title": "The Juniper SRX Services Gateway must be configured with only one local user account to be used as the account of last resort.",
+      "description": "Without centralized management, credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. \n\nLocal accounts are configured using the local password authentication method which does not meet the multifactor authentication criteria. The account of last resort is a group authenticator which does not provide nonrepudiation, thus must be used only rare cases where the device must be accessed using the local console and an individual authenticator is not possible, including when network access is not available.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66513",
+      "title": "The Juniper SRX Services Gateway must implement replay-resistant authentication mechanisms for network access to privileged accounts.",
+      "description": "A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nThere are 2 approved methods for accessing the Juniper SRX which are, in order of preference, the SSH protocol and the console port.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66515",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce a minimum 15-character password length.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.\n\nCompliance with this requirement also prevents the system from being configured with default or no passwords.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66517",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by setting the password change type to character sets.",
+      "description": "Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nThe password change-type command specifies whether a minimum number of character-sets or a minimum number of character-set transitions are enforced. The DoD requires this setting be set to character-sets.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66519",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one upper-case character be used.",
+      "description": "Use of a complex passwords helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66521",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one lower-case character be used.",
+      "description": "Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66523",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one numeric character be used.",
+      "description": "Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66525",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort), the Juniper SRX Services Gateway must enforce password complexity by requiring at least one special character be used.",
+      "description": "Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nPassword complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66527",
+      "title": "For local accounts using password authentication (i.e., the root account and the account of last resort) the Juniper SRX Services Gateway must use the SHA1 or later protocol for password authentication.",
+      "description": "Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.\n\nThe password format command is an optional command that specifies the hash algorithm used for authenticating passwords. The options are MD5, SHA1, or DES. SHA1 is recommended because it is a FIPS-approved algorithm and provides stronger security.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66529",
+      "title": "For nonlocal maintenance sessions using SSH, the Juniper SRX Services Gateway must securely configure SSHv2 Message Authentication Code (MAC) algorithms to protect the integrity of maintenance and diagnostic communications.",
+      "description": "To protect the integrity of nonlocal maintenance sessions, SSHv2 with MAC algorithms for integrity checking must be configured. \n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe SSHv2 protocol suite includes Layer 7 protocols such as SCP and SFTP which can be used for secure file transfers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66531",
+      "title": "For nonlocal maintenance sessions using SSH, the Juniper SRX Services Gateway must securely configured SSHv2 with privacy options to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.",
+      "description": "To protect the confidentiality of nonlocal maintenance sessions when using SSH communications, SSHv2, AES ciphers, and key-exchange commands are configured. \n\nNonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. \n\nThe SSHv2 protocol suite includes Layer 7 protocols such as SCP and SFTP which can be used for secure file transfers. The key-exchange commands limit the key exchanges to FIPS and DoD-approved methods.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66533",
+      "title": "For nonlocal maintenance sessions, the Juniper SRX Services Gateway must ensure only zones where management functionality is desired have host-inbound-traffic system-services configured.",
+      "description": "Add a firewall filter to protect the management interface. Note: The dedicated management interface (if present), and an interface placed in the functional zone management, will not participate in routing network traffic. It will only support device management traffic.\n\nThe host-inbound-traffic feature of the SRX is an additional layer of security for system services. This function can be configured on either a per zone or a per interface basis within each individual security zone. By default, a security zone has all system services disabled, which means that it will not accept any inbound management or protocol requests on the control plane without explicitly enabling the service at either the interface or zone in the security zone stanzas.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66535",
+      "title": "The Juniper SRX Services Gateway must immediately terminate SSH network connections when the user logs off, the session abnormally terminates, or an upstream link from the managed device goes down.",
+      "description": "This setting frees device resources and mitigates the risk of an unauthorized user gaining access to an open idle session. \n\nWhen sessions are terminated by a normal administrator log off, the Juniper SRX makes the current contents unreadable and no user activity can take place in the session. However, abnormal terminations or loss of communications do not signal a session termination, thus a keep-alive count and interval must be configured so the device will know when communication with the client is no longer available. The keep-alive value and the interval between keep-alive messages must be set to an organization-defined value based on mission requirements and network performance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66537",
+      "title": "The Juniper SRX Services Gateway must terminate a device management session after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.",
+      "description": "Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session. Quickly terminating an idle session also frees up resources. \n\nThis requirement does not mean that the device terminates all sessions or network access; it only ends the inactive session.\n\nUser accounts, including the account of last resort must be assigned to a login class. Configure all login classes with an idle timeout value. Pre-defined classes do not support configurations, therefore should not be used for DoD implementations. The root account cannot be assigned to a login-class which is why it is critical that this account be secured in accordance with DoD policy.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66539",
+      "title": "The Juniper SRX Services Gateway must terminate a device management session if the keep-alive count is exceeded.",
+      "description": "Configuring the keep-alive for management protocols mitigates the risk of an open connection being hijacked by an attacker.\n\nThe keep-alive messages and the interval between each message are used to force the system to disconnect a user that has lost network connectivity to the device. This differs from inactivity timeouts because the device does not wait the 10 minutes to log the user out but, instead, immediately logs the user out if the number of keep-alive messages are exceeded. The interval between messages should also be configured. These values should be set to an organization-defined value based on mission requirements and network performance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66541",
+      "title": "The Juniper SRX Services Gateway must configure the control plane to protect against or limit the effects of common types of Denial of Service (DoS) attacks on the device itself by configuring applicable system options and internet-options.",
+      "description": "DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.\n\nJuniper SRX uses the system commands, system internet-options, and screens to mitigate the impact of DoS attacks on device availability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66543",
+      "title": "The Juniper SRX Services Gateway must limit the number of sessions per minute to an organization-defined number for SSH to protect remote access management from unauthorized access.",
+      "description": "The rate-limit command limits the number of SSH session attempts allowed per minute which helps limit an attacker's ability to perform DoS attacks. The rate limit should be as restrictive as operationally practical.\n\nJuniper Networks recommends a best practice of 4 for the rate limit, however the limit should be as restrictive as operationally practical. \n\nUser connections that exceed the rate-limit will be closed immediately after the connection is initiated. They will not be in a waiting state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66545",
+      "title": "The Juniper SRX Services Gateway must reveal log messages or management console alerts only to the ISSO, ISSM, and SA roles).",
+      "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. Additionally, sensitive account information must not be revealed through error messages to unauthorized personnel or their designated representatives.\n\nAlthough, based on policy, administrator accounts must be created on the AAA server, thus this requirement addresses the creation of unauthorized accounts on the Juniper SRX itself. This does not negate the need to address this requirement on the AAA server and the event monitoring server (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66547",
+      "title": "The Juniper SRX Services Gateway must be configured to use Junos 12.1 X46 or later to meet the minimum required version for DoD.",
+      "description": "Earlier versions of Junos may have reached the end of life cycle support by the vendor. Junos 12.1X46 is not a UC APL certified version, while 12.1X46 is UC APL Certified. The SRX with Junos 12.1X46 has been NIAP certified as a firewall and VPN. Junos 12.1X46 contains a number of enhancements, particularly related to IPv6, that are relevant to the STIG.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-66549",
+      "title": "The Juniper SRX Services Gateway must limit the number of concurrent sessions to a maximum of 10 or less for remote access using SSH.",
+      "description": "The connection-limit command limits the total number of concurrent SSH sessions. To help thwart brute force authentication attacks, the connection limit should be as restrictive as operationally practical\n\nJuniper Networks recommends the best practice of setting 10 (or less) for the connection-limit.\n\nThis configuration will permit up to 10 users to log in to the device simultaneously, but an attempt to log an 11th user into the device will fail. The attempt will remain in a waiting state until a session is terminated and made available.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66551",
+      "title": "The Juniper SRX Services Gateway must generate a log event when privileged commands are executed.",
+      "description": "Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat.\n\nAll commands executed on the Juniper SRX are privileged commands. Thus, this requirement is configured using the same syslog command as CCI-000172.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66553",
+      "title": "For local accounts created on the device, the Juniper SRX Services Gateway must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.",
+      "description": "By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced.\n\nJuniper SRX is unable to comply with the 15-minute time period part of this control.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66555",
+      "title": "The Juniper SRX Services Gateway must display the Standard Mandatory DoD Notice and Consent Banner before granting access.",
+      "description": "Display of the DoD-approved use notification before granting access to the network device ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.\n\nThe Standard Mandatory DoD Notice and Consent Banner must be displayed before the user has been authenticated.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66557",
+      "title": "The Juniper SRX Services Gateway must allow only the ISSM (or administrators/roles appointed by the ISSM) to select which auditable events are to be generated and forwarded to the syslog and/or local logs.",
+      "description": "Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.\n\nThe primary audit log permissions are set on the Syslog server, not the Juniper SRX. However, it is a best practice to also keep local logs for troubleshooting and backup. These logs are subject to access control requirements.\n\nThis configuration is a two-step process. Part of the configuration must be performed on the AAA server. After a user successfully logs on, the AAA sever passes the template or role of the user to the Juniper SRX. Each AAA template or role is mapped to a login class on the Juniper SRX. \n\nOn the Juniper SRX, the class name, audit-admin, is recommended as a best practice because it follows the naming convention used in NIAP testing and is self-documenting.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66559",
+      "title": "The Juniper SRX Services Gateway must generate log records when successful attempts to configure the device and use commands occur.",
+      "description": "Without generating log records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. \n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured by default to local files. \n\nEnsure at least one Syslog server and local files are configured to support requirements. However, the Syslog itself must also be configured to filter event records so it is not overwhelmed. A best practice when configuring the external Syslog server is to add similar log-prefixes to the log file names to help and researching of central Syslog server. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX).",
+      "severity": "low"
+    },
+    {
+      "id": "V-66561",
+      "title": "The Juniper SRX Services Gateway must generate log records when changes are made to administrator privileges.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66563",
+      "title": "The Juniper SRX Services Gateway must generate log records when administrator privileges are deleted.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66565",
+      "title": "The Juniper SRX Services Gateway must generate log records when logon events occur.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66567",
+      "title": "The Juniper SRX Services Gateway must generate log records when privileged commands are executed.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66569",
+      "title": "The Juniper SRX Services Gateway must generate log records when concurrent logons from different workstations occur.",
+      "description": "Without generating log records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66571",
+      "title": "The Juniper SRX Services Gateway must generate log records containing the full-text recording of privileged commands.",
+      "description": "Reconstruction of harmful events or forensic analysis is not possible if log records do not contain enough information. \n\nOrganizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. \n\nWhile the Juniper SRX inherently has the capability to generate log records, by default only the high facility levels are captured and only to local files. \n\nEnsure at least one Syslog server and local files are configured to support requirements. However, the Syslog itself must also be configured to filter event records so it is not overwhelmed. A best practice when configuring the external Syslog server is to add similar log-prefixes to the log file names to help and researching of central Syslog server. Another best practice is to add a match condition to limit the recorded events to those containing the regular expression (REGEX).",
+      "severity": "low"
+    },
+    {
+      "id": "V-66573",
+      "title": "For local logging, the Juniper SRX Services Gateway must generate a message to the system management console when a log processing failure occurs.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process logs as required. Without this alert, the security personnel may be unaware of an impending failure of the log capability and system operation may be adversely affected. \n\nAlerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less). Automated alerts can be conveyed in a variety of ways, including, for example, telephonically, via electronic mail, via text message, or via websites.\n\nLog processing failures include software/hardware errors, failures in the log capturing mechanisms, and log storage capacity being reached or exceeded.\n\nWhile this requirement also applies to the event monitoring system (e.g., Syslog, Security Information and Event Management [SIEM], or SNMP servers), the Juniper SRX must also be configured to generate a message to the administrator console.\n\nSyslog and SNMP trap events with a facility of \"daemon\" pertain to errors encountered by system processes.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66595",
+      "title": "The Juniper SRX Services Gateway must have the number of rollbacks set to 5 or more.",
+      "description": "Backup of the configuration files allows recovery in case of corruption, misconfiguration, or catastrophic failure. The maximum number of rollbacks for the SRX is 50 while the default is 5 which is recommended as a best practice. Increasing this backup configuration number will result in increased disk usage and increase the number of files to manage. Organizations should not set the value to zero.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66597",
+      "title": "The Juniper SRX Services Gateway must specify the order in which authentication servers are used.",
+      "description": "Specifying an authentication order implements an authentication, authorization, and accounting methods list to be used, thus allowing the implementation of redundant or backup AAA servers. These commands also ensure that a default method or order will not be used by the device (e.g., local passwords).\n\nThe Juniper SRX must specify the order in which authentication is attempted by including the authentication-order statement in the authentication server configuration. \n\nRemote logon using password results in a CAT 1 finding (CCI-000765) for failure to use two-factor authentication. Thus, if the account of last resort uses only password authentication, this configuration prevents remote access. DoD policy is that redundant AAA servers are required to mitigate the risk of a failure of the primary AAA device.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66599",
+      "title": "The Juniper SRX Services Gateway must detect the addition of components and issue a priority 1 alert to the ISSM and SA, at a minimum.",
+      "description": "The network device must automatically detect the installation of unauthorized software or hardware onto the device itself. Monitoring may be accomplished on an ongoing basis or by periodic monitoring. Automated mechanisms can be implemented within the network device and/or in another separate information system or device. If the addition of unauthorized components or devices is not automatically detected, then such components or devices could be used for malicious purposes, such as transferring sensitive data to removable media for compromise.\n\nAlerts must be sent immediately to the designated individuals (e.g., via Syslog configuration, SNMP trap, manned console message, or other events monitoring system).",
+      "severity": "low"
+    },
+    {
+      "id": "V-66601",
+      "title": "The Juniper SRX Services Gateway must terminate the console session when the serial cable connected to the console port is unplugged.",
+      "description": "If a device management session or connection remains open after management is completed, it may be hijacked by an attacker and used to compromise or damage the network device.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66603",
+      "title": "The Juniper SRX Services Gateway must implement service redundancy to protect against or limit the effects of common types of Denial of Service (DoS) attacks on the device itself.",
+      "description": "Service redundancy, may reduce the susceptibility to some DoS attacks.\n\nOrganizations must consider the need for service redundancy in accordance with DoD policy. If service redundancy is required then this technical control is applicable.\n\nThe Juniper SRX can configure your system to monitor the health of the interfaces belonging to a redundancy group.",
+      "severity": "low"
+    },
+    {
+      "id": "V-66605",
+      "title": "For nonlocal maintenance sessions, the Juniper SRX Services Gateway must explicitly deny the use of J-Web.",
+      "description": "If unsecured functions (lacking FIPS-validated cryptographic mechanisms) are used for management sessions, the contents of those sessions are susceptible to manipulation, potentially allowing alteration and hijacking.\n\nJ-Web (configured using the system services web-management option) does not meet the DoD requirement for management tools. It also does not work with all Juniper SRX hardware. By default, the web interface is disabled; however, it is easily enabled.",
+      "severity": "high"
+    }
+  ]
+}