kriterion 0.0.1

data/standards/stig_application_security_requirements_guide.json

@@ -0,0 +1,1961 @@
+{
+  "name": "stig_application_security_requirements_guide",
+  "date": "2011-12-28",
+  "description": "None",
+  "title": "Application Security Requirements Guide",
+  "version": "None",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-26664",
+      "title": "The application must be able to define the maximum number of concurrent sessions for an application account globally, by account type, by account, or a combination thereof. ",
+      "description": "Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to Denial of Service attacks.\n\nThis requirement addresses concurrent session control for a single information system account and does not address concurrent sessions by a single user via multiple system accounts. \n\nThis requirement may be met via the application or by utilizing information system session control provided by a web server with specialized session management capabilities.  If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application.  \n\nThe organization will need to define the maximum number of concurrent sessions for an information system account globally, by account type, by account, or a combination thereof and the application shall enforce that requirement.\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26665",
+      "title": "The application must ensure that the screen display is obfuscated when an application session lock event occurs. ",
+      "description": "A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. \n\nThe session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. \n\nWhen the application design specifies the application rather than the operating system will determine when to lock the session, the application session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. \n\nAn example of obfuscation is a screensaver creating a viewable pattern that overwrites the entire screen rendering the screen contents unreadable.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26666",
+      "title": "The application must support the requirement to initiate a session lock after an organization defined time period of system or application inactivity has transpired. ",
+      "description": "A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence.  Rather than relying on the user to manually lock their application session prior to vacating the vicinity, applications need to be able to identify when a user's application session has idled and take action to initiate the session lock.\n\nThe session lock is implemented at the point where session activity can be determined and/or controlled. This is typically at the operating system-level and results in a system lock, but may be at the application-level where the application interface window is secured instead. The organization defines the period of inactivity that shall pass before a session lock is initiated so this must be configurable.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26671",
+      "title": "Applications must ensure that users can directly initiate session lock mechanisms which prevent further access to the system. ",
+      "description": "A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. \n\nThe session lock is implemented at the point where session activity can be determined. This is typically at the operating system-level, but may be at the application-level. Rather than be forced to wait for a period of time to expire before the user session can be locked, applications need to provide users with the ability to manually invoke a session lock so users may secure their application should the need arise for them to temporarily vacate the immediate physical vicinity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26672",
+      "title": "The application must have the ability to retain a session lock remaining in effect until the user re-authenticates using established identification and authentication procedures.",
+      "description": "A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. \n\nThe session lock is implemented at the point where session activity can be determined. This is typically determined and performed at the operating system-level, but in some instances it may be at the application-level.  \n\nRegardless of where the session lock is determined and implemented, once invoked the session lock shall remain in place until the user re-authenticates.  No other system or application activity aside from re-authentication shall unlock the system.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26673",
+      "title": "The application must maintain and support the use of organization defined security attributes to stored information.  ",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.   \n\nOne example includes marking data as classified or FOUO.  These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in storage.  If the security attributes are lost when the data is stored, there is the risk of a data compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26674",
+      "title": "The application must support and maintain the binding of organization defined security attributes to information in process.  ",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nOrganizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these security attributes must maintain the binding of these security attributes to the data while it is being processed. \n\nIf the application does not maintain the data security attributes while it processes the data, there is a risk of data compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26675",
+      "title": "The application must maintain and support the use of organization defined security attributes to information in transmission.  ",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.  \n\nOrganizations define the security attributes of their data (e.g., classified, FOUO). Applications generating and/or processing data assigned these organization defined security attributes must maintain the binding of these attributes to the data when the data are transmitted.\n\nIf the application does not maintain the data security attributes when it transmits the data, there is a risk of data compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26676",
+      "title": "The application must dynamically reconfigure security attributes in accordance with an identified security policy as information is created and combined. ",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.  \n\nOrganizations define the security attributes of their data (e.g., classified, FOUO).\n\nWhen application data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics.\n\nIf the application does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that classified data may become comingled with unclassified data resulting in a data compromise.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26677",
+      "title": "The application must provide the capability to specify administrative users and grant them the right to change application security attributes pertaining to application data.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nSecurity attributes are typically associated with internal data structures (e.g., records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the organizational information security policy.\n\nOrganizations define the security attributes of their data (e.g., classified, FOUO, sensitive).\n\nChanging security attributes within an application is usually performed by a person or persons who have been delegated the task and the associated responsibilities accorded to application administrative personnel.\n\nApplications creating and/or assigning security attributes to data must have the flexibility to allow authorized staff to change these security attributes.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26678",
+      "title": "The application must maintain the binding of security attributes to information with sufficient assurance that the information/attribute association can be used as the basis for automated policy actions.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.  \n\nExamples of application security attributes are classified, FOUO, sensitive,  etc. \n\nApplications maintaining the binding of organization defined security attributes to data must ensure the information-attribute associations can be used as a basis for automated policy actions.\n\nThe integrity of security attribute values is critical to ensuring that automated policy actions are performed accurately.  Examples of automated policy actions include automated access control decisions (e.g., Mandatory Access Control decisions), or decisions to release (or not release) information (e.g., information flows via cross domain systems).  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26679",
+      "title": "The  application must allow authorized users to associate security attributes with information.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nExamples of application security attributes are classified, FOUO, sensitive,  etc. \n\nThroughout the course of normal usage, authorized users of applications that handle sensitive data will have the need to associate security attributes with information. Applications that maintain the binding of organization defined security attributes to data must ensure authorized users can associate security attributes with information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26680",
+      "title": "The application must display security attributes in human-readable form on each object output from the system to system output devices to identify an organization-identified set of special dissemination, handling, or distribution instructions using organization-identified human readable, standard naming conventions.",
+      "description": "Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.  \n\nThese attributes are typically associated with internal data structures (e.g., records, buffers, files, registry keys) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nExamples of application security attributes are classified, FOUO, sensitive,  etc. \n\nSecurity attributes need to be displayed in human readable form in order to determine how the data should be disseminated, handled and what distribution instructions apply to the data.  When applications generate or output data, the associated security attributes need to be displayed.\n\nObjects output from the information system include pages, screens, or equivalent. \n\nOutput devices include printers and video displays on computer terminals, monitors, screens on notebook/laptop computers and personal digital assistants. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26681",
+      "title": "Applications providing remote access capabilities must utilize approved cryptography to protect the confidentiality of remote access sessions. ",
+      "description": "Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nRemote network access is accomplished by leveraging common communication protocols and establishing a remote connection.  These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN).  Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised.  Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26682",
+      "title": "Applications providing remote access connectivity must use cryptography to protect the integrity of the remote access session. ",
+      "description": "Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nRemote network access is accomplished by leveraging common communication protocols and establishing a remote connection.  These connections will typically occur over the public Internet, the Public Switched Telephone Network (PSTN) or sometimes both.  Since neither of these internetworking mechanisms are private nor secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and potentially modified.  Cryptography provides a means to secure the remote connection so as to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of integrity.  The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26684",
+      "title": "The application must employ automated mechanisms to facilitate the monitoring and control of remote access methods.",
+      "description": "Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection.  These connections will occur over the public Internet.  \n\nRemote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nAutomated monitoring of remote access sessions allows organizations to audit user activities on a variety of information system components (e.g., servers, workstations, notebook/laptop computers) and to ensure compliance with remote access policy.\n\nRemote access applications such as those providing remote access to network devices and information systems and are individually configured with no monitoring or automation capabilities increase risk and makes remote user access management difficult at best.\n\nApplications providing remote access capability need to provide the ability to automatically monitor and control remote user sessions.  This includes the capability to directly trigger actions based on user activity or pass information and or data to a separate application or entity that can then perform automated tasks based on the information. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26685",
+      "title": "Applications providing remote access must have capabilities that allow all remote access to be routed through managed access control points.",
+      "description": "This requirement relates to the use of applications providing remote access services.  Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nRemote network access is accomplished by leveraging common communication protocols and establishing a remote connection.  These connections will typically occur over either the public Internet or the Public Switched Telephone Network (PSTN).   \n\nPlease note, utilization of a virtual private network when adequately provisioned with appropriate security controls, is considered an internal network and is not considered remote access.\n\nWithout centralized control of inbound connections, management of these access points is difficult at best.  It is critical that applications providing or offering remote access capabilities also have the capability to route the access through managed access control points. \n\nOne example is the use of software applications such as PCAnywhere or Terminal Services.  Rather than having PCAnywhere installed on multiple systems, remote access software must have the capability to be centrally managed and controlled so there are not multiple disparate access points into the environment.\n\nApplications providing remote access must have capabilities that allow all remote access to be routed through managed access control points.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26686",
+      "title": "The application must monitor for unauthorized remote connections to the information system on an organization-defined frequency.",
+      "description": "Organizations need to monitor for unauthorized remote access connections to information systems in order to determine if break-in attempts or other unauthorized activity is occurring.  There are already other SRG requirements for applications to generate audit connection logs to record connection activity. It is for the organization to determine which of those audited connections is unauthorized.  \n\nThis task is usually handled by the IDS, log alarming or some other security mechanism specifically designed to automate and address this requirement.  \n\nThis requirement is NA for applications not designed to monitor for unauthorized remote connections to information systems.  Applications designed to meet this requirement must be able to do so on an organization-defined frequency.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26687",
+      "title": "The application must ensure remote sessions for accessing an organization-defined list of security functions and security-relevant information are audited.",
+      "description": "Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nRemote network and system access is accomplished by leveraging common communication protocols to establish a remote connection.  These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN).  Neither of these internetworking mechanisms is private or secure and they do not by default restrict access to networked resources once connectivity is established.  \n\nNumerous best practices are employed to protect remote connections such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues and provide evidence needed for forensic investigations post security incident.  \n\nWhen organizations define security related application functions or security-related application information, it is incumbent upon the application providing access to that data to ensure auditing of remote connectivity to those resources occurs in support of organizational requirements. \n\nRemote access to security functions (e.g., user management, audit log management, etc.) and security relevant information requires the activity be audited by the organization. Any application providing remote access must support organizational requirements to audit access or organization-defined security functions and security-relevant information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26688",
+      "title": "Applications must support the capability to disable network protocols deemed by the organization to be nonsecure except for explicitly identified components in support of specific operational requirements.",
+      "description": "This control is related to remote access but more specifically to the networking protocols allowing systems to communicate.  Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless.  \n\nSome networking protocols allowing remote access may not meet security requirements to protect data and components. Bluetooth and peer-to-peer networking are examples of less than secure networking protocols.  \n\nThe DoD Ports, Protocols, and Services Management (PPSM) program provides implementation guidance on the use of IP protocols and application and data services traversing the DoD Networks in a manner supporting net-centric operations.  \n\nApplications implementing or utilizing remote access network protocols need to ensure the application is developed and implemented in accordance with the PPSM requirements.  In situations where it has been determined that specific operational requirements outweigh the risks of enabling an insecure network protocol, the organization may pursue a risk acceptance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26692",
+      "title": "The application must monitor for unauthorized connections of mobile devices to organizational information systems.",
+      "description": "Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices).  \n\nOrganization-controlled mobile devices include those devices for which the organization has the authority to specify and the ability to enforce specific security requirements.\n\nUsage restrictions and implementation guidance related to mobile devices include, configuration management, device identification and authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall), scanning devices for malicious code, updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared).\n\nIn order to detect unauthorized mobile device connections, organizations must first identify and document what mobile devices are authorized. \n\nMonitoring for unauthorized connections is usually handled by configuration management software, log alarming, IDS, or some other security mechanism specifically designed to automate and address this requirement.  \n\nThis requirement is NA for applications not designed to monitor for unauthorized connections to information systems.  Applications designed to meet this requirement must be able to do so according to organizational usage restrictions and policy.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26693",
+      "title": "Applications must not enable information system functionality providing the capability for automatic execution of code on mobile devices without user direction.",
+      "description": "Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices).  \n\nAuto execution vulnerabilities can result in malicious programs being automatically executed.  Examples of information system functionality providing the capability for automatic execution of code are Auto Run and Auto Play.  Auto Run and Auto Play are components of the Microsoft Windows operating system dictating what actions the system takes when a drive is mounted. This requirement is designed to address vulnerabilities arising when mobile devices such as USB memory sticks or other mobile storage devices are automatically mounted and applications are automatically invoked without user knowledge or acceptance.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26699",
+      "title": "Applications must provide automated mechanisms for supporting user account management. The  automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management capabilities.",
+      "description": "A comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. Examples include but are not limited to using automation to take action on multiple  accounts designated as inactive, suspended or terminated or by disabling accounts located in non-centralized account stores such as multiple servers.\n\nEnterprise environments make application user account management challenging and complex.  A user management process requiring administrators to manually address account management functions adds risk of potential oversight.\n\nAutomated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26701",
+      "title": "The application must provide a mechanism to automatically terminate accounts designated as temporary or emergency accounts after an organization-defined time period.",
+      "description": "Temporary application accounts could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.  \n\nTo address this, in the event temporary application accounts are required, the application must ensure that accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period.  Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or data compromised. \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26703",
+      "title": "The application must be capable of automatically disabling accounts after a 35 day period of account inactivity.",
+      "description": "Users are often the first line of defense within an application.  Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly pertaining to their own account. Inactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.  \n\nAttackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26705",
+      "title": "Applications must support the requirement to automatically audit account creation.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. \n\nAuditing of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.  \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26706",
+      "title": "Applications must support the requirement to automatically audit account modification.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. \n\nAuditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leveraging complimentary technology providing this capability or a combination thereof.\n\nAutomated account auditing processes greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes.  \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26730",
+      "title": "The application must automatically audit account disabling actions and notify appropriate individuals.",
+      "description": "When application accounts are disabled, user accessibility is affected.  Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals, so they can investigate the event.  \n\nSuch a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.  \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms meeting or exceeding access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to, Active Directory and LDAP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26731",
+      "title": "The application must automatically audit account termination and notify appropriate individuals.",
+      "description": "When application accounts are terminated, user accessibility is affected.  Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events affecting user accessibility and application processing, applications must audit account terminating actions and notify the appropriate individuals, so they can investigate the event.  Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. \n\nTo address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms meeting or exceeding access control policy requirements. Examples include but are not limited to, Active Directory and LDAP.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26732",
+      "title": "Applications must support the organizational requirement to automatically monitor on atypical usage of accounts.",
+      "description": "Atypical account usage is behavior that is not part of normal usage cycles. For example, user account activity occurring after hours or on weekends.  \n\nA comprehensive account management process will ensure that an audit trail which  documents the use of application user accounts and as required, notifies administrators and/or application owners exists.  \n\nSuch a process greatly reduces the risk that compromised user accounts will continue to be used by unauthorized persons and provides logging that can be used for forensic purposes. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26733",
+      "title": "Service Oriented Architecture (SOA) based applications must dynamically manage user privileges and associated access authorizations.",
+      "description": "Web services are web applications providing a method of communication between two or more different electronic devices.  They are normally used by applications to provide each other with data.  \n\nThe World Wide Web Consortium (W3C) defines a web service as:\n\"a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically, Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using Simple Object Access Protocol (SOAP) messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards\".\n\nWeb services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management.  While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. \n\nService Oriented Architecture (SOA) based applications need to take this possibility into account and leverage dynamic access control methodologies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26734",
+      "title": "The application must employ automated mechanisms enabling authorized users to make information sharing decisions based on access authorizations of sharing partners and access restrictions on information to be shared.",
+      "description": "User based collaboration and information sharing applications present challenges regarding classification and dissemination of information generated and shared among the application users. These types of applications are intended to share information created and stored within the application;  however, not all users have a need to view all data created or stored within the collaboration tool.  \n\nCollaboration tools and all applications handling information that may be restricted in some manner (e.g., privileged medical, contract-sensitive, proprietary, personally identifiable information, special access programs/compartments) must provide the capability to automatically enable authorized users to make information sharing decisions based upon access authorizations.  \n\nDepending on the information-sharing circumstance, the sharing partner may be defined at the individual, group, or organization level and information may be defined by specific content, type, or security categorization. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26735",
+      "title": "The application must enforce approved authorizations for logical access to the system in accordance with applicable policy.",
+      "description": "Strong access controls are critical to securing application data. Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) must be employed by applications, when applicable, to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains) in the information system.\n\nConsideration should be given to the implementation of an audited, explicit override of automated mechanisms in the event of emergencies or other serious events. If encryption of stored information is employed as an access enforcement mechanism, the cryptography used is FIPS 140-2 (as amended) compliant.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26737",
+      "title": "The application must enforce dual authorization, based on organizational policies and procedures for organization-defined privileged commands.",
+      "description": "Dual authorization requires 2 distinct approving authorities to approve the use of an application  command prior to it being invoked.  This capability is typically reserved for specific application functionality where the application owner, data owner or organization requires an additional assurance that certain application commands are only invoked under the utmost authority. When a policy is defined stating that certain commands contained within an application require dual-authorization before they may be invoked, or when an organization defines a set of application related privileged commands requiring dual authorization, the application must support those requirements. \n\nDue to potential delays in obtaining secondary approvals prior to executing commands, dual authorization mechanisms should not be utilized when an immediate response is necessary in order to ensure public and/or environmental safety. If, after due consideration, it is determined the benefit of dual authorization outweighs identified risks, the organization must establish documented procedures, assign specific personnel to provide approvals and establish operational exercises assuring that any risks to public safety, environmental safety or otherwise, are minimized. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26748",
+      "title": "Applications must enforce non-discretionary access control policies over users and resources where the policy rule set for each policy specifies:\naccess control information (i.e., attributes) employed by the policy rule set (e.g., position, nationality, age, project, time of day).",
+      "description": "Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). \n\nNon-discretionary access controls are controls determined by policy makers, are managed centrally or by a central authority and may not be changed at the discretion of ordinary application users.  Data protection requirements may result in a non-discretionary access control policy being specified as part of the application design. \n\nNon-discretionary access controls are employed at the application level to restrict and control access to application data thereby providing increased information security for the organization.  \n\nPolicy rule sets would be developed to establish that each user receives only the information to which the user is authorized.  The policy rule set will specify that each application user account will be assigned attributes including information such as position, nationality, age, project, time of data, etc.\n\nApplications must enforce these non-discretionary access control policies over application users and resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26750",
+      "title": "The application must enforce Discretionary Access Control (DAC) policy allowing users to specify and control sharing by named individuals, groups of individuals, or by both, limiting propagation of access rights and includes or excludes access to the granularity of a single user.",
+      "description": "Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). \n\nDAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong.  It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly.\n\nData protection requirements may result in a DAC policy being specified as part of the application design.  Discretionary access controls would be employed at the application level to restrict and control access to application objects and data thereby providing increased information security for the organization.  \n\nWhen DAC controls are employed, those controls must limit sharing to named application users, groups of users or both.  The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user.\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26751",
+      "title": "The application must prevent access to organization-defined security-relevant information except during secure, non-operable system states.",
+      "description": "Security-relevant information is any information within the information system that can potentially impact the operation of security functions in a manner possibly resulting in failure to enforce the system security policy or maintain isolation of code and data.  Organizations may define specific security relevant information requiring protection.\n\nFiltering rules for routers and firewalls, cryptographic key management information, key configuration parameters for security services, and access control lists are examples of security-relevant information. \n\nSecure, non-operable system states are states in which the information system is not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, shutdown). \n\nAccess to these types of data is to be prevented unless the system is in a maintenance mode or has otherwise been brought off-line.  The goal is to minimize the potential a security configuration or data may be dynamically and perhaps, surreptitiously overwritten or changed (without going through a formal system change process that can document the changes).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26752",
+      "title": "Applications providing information flow control must enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nFrom an application perspective, flow control is established once application data flow modeling has been completed.  Data flow modeling can be described as:\n\nthe process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities transforming data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). \n\nOnce the application data flows have been identified, corresponding flow controls can be applied at the appropriate points.\n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination.  Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path.\n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nApplications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26754",
+      "title": "Applications providing information flow control must enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nFrom an application perspective, flow control is established once application data flow modeling has been completed.  Data flow modeling can be described as:\n\nthe process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system, and data flows (routes by which data can flow). \n\nOnce the application data flows have been identified, corresponding flow controls can be applied at the appropriate points.\n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information that is marked as classified but is being transported to an unapproved destination.  Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path.\n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nApplications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26755",
+      "title": "Applications providing information flow control must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nFrom an application perspective, flow control is established once application data flow modeling has been completed.  Data flow modeling can be described as:  the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). \n\nOnce the application data flows have been identified, corresponding flow controls can be applied at the appropriate points.\n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination.  Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path.\n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nApplications providing information flow control capabilities must use explicit security attributes on information, source, and destination objects as a basis for flow control decisions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26767",
+      "title": "Applications providing information flow control must provide the capability for privileged administrators to enable/disable security policy filters.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nFrom an application perspective, flow control is established once application data flow modeling has been completed.  Data flow modeling can be described as:  the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). \n\nOnce the application data flows have been identified, corresponding flow controls can be applied at the appropriate points.\n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination.  Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path.\n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establishing configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nA crucial part of any flow control solution is the ability to create policy filters. Policy filters serve to enact and enforce the organizational policy as it pertains to controlling data flow. \n\nOrganization-defined security policy filters include, for example,  file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. \n\n- Structured data permits the interpretation of its content by virtue of elements that are understandable by an application and are indivisible. \n- Unstructured data refers to masses of (usually) digital information that does not have a data structure or does have a data structure that is not easily readable by a machine. Unstructured data consists of two basic categories: (i) bitmap objects that are inherently non language-based (i.e., image, video, or audio files); and (ii) textual objects based on a written or printed language (i.e., commercial off-the-shelf word processing documents, spreadsheets, or emails).\n\nApplications providing information flow control must provide the capability for a privileged administrator to enable/disable security policy filters.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26768",
+      "title": "Applications providing information flow controls must provide the capability for privileged administrators to configure security policy filters to support different organizational security policies. ",
+      "description": "\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nFrom an application perspective, flow control is established once application data flow modeling has been completed.  Data flow modeling can be described as:  the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow). \n\nOnce the application data flows have been identified, corresponding flow controls can be applied at the appropriate points.\n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet and blocking information marked as classified but is being transported to an unapproved destination.  Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. Flow control is based on the characteristics of the information and/or the information path.\n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nA crucial part of any flow control solution is the ability to create policy filters. Policy filters serve to enact and enforce the organizational policy as it pertains to controlling data flow. \n\nOrganization-defined security policy filters include, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. \n\n- Structured data permits the interpretation of its content by virtue of atomic elements that are understandable by an application and indivisible. \n- Unstructured data refers to masses of (usually) digital information does not have a data structure or does have a data structure that is not easily readable by a machine. Unstructured data consists of two basic categories: (i) bitmap objects that are inherently non language-based (i.e., image, video, or audio files); and (ii) textual objects based on a written or printed language (i.e., commercial off-the-shelf word processing documents, spreadsheets, or emails).\n\nApplications providing information flow control must provide the capability for privileged administrators to configure security policy filters to support different security policies.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26769",
+      "title": "Applications providing flow control must identify data type, specification and usage when transferring information between different security domains so policy restrictions may be applied.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nAn example of flow control restrictions includes: keeping export controlled information from being transmitted in the clear to the Internet. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., users, networks, devices) within information systems and between interconnected systems. \n\nApplication specific examples of flow control enforcement can be found in information protection software (e.g., guards, proxies, application layer gateways and cross domain solutions) employing rule sets or establish configuration settings restricting information system services or provide message-filtering capability based on content (e.g., using key word searches or document characteristics).  \n\nFlow control is based on the characteristics of the information and/or the information path. Applications providing flow control must identify data type, specification, and usage when transferring information between different security domains so policy restrictions may be applied.\n\nA Security domain is defined as a domain implementing a security policy and is administered by a single authority.\n\nData type, specification and usage includes, using file naming to reflect the type of data being transferred and limiting data transfer based on file type. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26770",
+      "title": "Applications, when transferring information between different security domains, must decompose information into policy-relevant subcomponents for submission to policy enforcement mechanisms. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nPolicy enforcement mechanisms include the filtering and/or sanitization rules applied to information prior to transfer to a different security domain.  \n\nParsing transfer files facilitates policy decisions on source, destination, certificates, classification, subject, attachments, and other information security-related component differentiators. \n\nPolicy rules for cross domain transfers include, limitations on embedding components/information types within other components/information types, prohibiting more than two-levels of embedding, and prohibiting the transfer of archived information types.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26771",
+      "title": "Applications, when transferring information between different security domains, must implement or incorporate policy filters that constrain data object and structure attributes according to organizational security policy requirements. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nExamples of constraints include ensuring: (i) character data fields only contain printable ASCII; (ii) character data fields only contain alpha-numeric characters;  (iii) character data fields do not contain special characters; (iv) maximum field sizes and file lengths are enforced based upon organization-defined security policy.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26772",
+      "title": "Applications designed to control information flow must provide the ability to detect unsanctioned information being transmitted across security domains. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application layer gateways, cross domain guards, content filters) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nActions to support this requirement include, but are not limited to: checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26773",
+      "title": "Applications must provide the ability to prohibit the transfer of unsanctioned information in accordance with security policy. ",
+      "description": "The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nActions to support this requirement include, but are not limited to: checking all transferred information for malware, implementing dirty word list searches on transferred information, and applying the same protection measures to metadata (e.g., security attributes) that is applied to the information payload.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26774",
+      "title": "Applications must provide the ability to enforce security policies regarding information on interconnected systems. ",
+      "description": "The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nTransferring information between interconnected information systems of differing security policies introduces risk that such transfers violate one or more policies. While security policy violations may not be absolutely prohibited, policy guidance from information owners/stewards is implemented at the policy enforcement point between the interconnected systems. Specific architectural solutions are mandated, when required, to reduce the potential for undiscovered vulnerabilities. \n\nArchitectural solutions include: (i) prohibiting information transfers between interconnected systems (i.e., implementing access only, one way transfer mechanisms); (ii) employing hardware mechanisms to enforce unitary information flow directions; and (iii) implementing fully tested, re-grading mechanisms to reassign security attributes and associated security labels. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26775",
+      "title": "Applications must uniquely identify source domains for information transfer.",
+      "description": "The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nAttribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26776",
+      "title": "Applications must uniquely authenticate source domains for information transfer.",
+      "description": "The information system enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nAttribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26777",
+      "title": "Applications must uniquely identify destination domains for information transfer.",
+      "description": "The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. \n\nInformation flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nAttribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26779",
+      "title": "The application must bind security attributes to information to facilitate information flow policy enforcement.",
+      "description": "The application enforces approved authorizations for controlling the flow of information within the system and between interconnected systems in accordance with applicable policy. Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information.  \n\nAttribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  Binding security attributes to information allows policy enforcement mechanisms to act on that information and enforce policy.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26782",
+      "title": "Applications providing information flow control must track problems associated with the binding of security attributes to data. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information.  \n\nAttribution, (e.g., the ability to attribute actions to certain individuals) is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  \n\nIn order to identify problems that may occur when binding security attributes to information, tracking and or auditing of these binding events must take place.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26786",
+      "title": "Applications must enforce information flow control using protected processing domains (e.g., domain type-enforcement) as a basis for flow control decisions.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nInformation flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. Information flow enforcement using explicit security attributes can be used, for example, to control the release of certain types of information. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26788",
+      "title": "Applications must enforce information flow using dynamic control based on policy that allows or disallows information flow based on changing conditions or operational considerations.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nA few examples of flow control restrictions include: keeping export controlled information from being transmitted in the clear to the Internet, blocking outside traffic claiming to be from within the organization and not passing any web requests to the Internet that are not from the internal web proxy. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems and between interconnected systems. \n\nFlow control is based on the characteristics of the information and/or the information path. Flow control is also based on the characteristics of the information and/or the information path. Specific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways, guards, encrypted tunnels, firewalls, and routers) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics).  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26790",
+      "title": "Applications must prevent encrypted data from bypassing content-checking mechanisms. ",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nInformation flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. When data is encrypted, devices and software designed to examine data content so as to detect attacks or malicious code are unable to accomplish the task unless they are capable of unencrypting the data. Example includes decrypting email in order to scan attachments.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26791",
+      "title": "Applications must enforce organization-defined limitations on the embedding of data types within other data types.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nInformation flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. \n\nEmbedding of data within other data is often used for the surreptitious transfer of data.  For example, embedding data within an image file (e.g., .jpg) is referred to as Steganography and is used to circumvent protections in place to protect information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26792",
+      "title": "Applications must enforce information flow control on metadata.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nInformation flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information flows not explicitly allowed by the information flow policy. \n\nMetadata is defined as data providing information about one or more other pieces of data such as;  purpose of the data, author/creator of the data, network location of where data was created, and application specific data information. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26810",
+      "title": "The information system must enforce organization-defined one-way flows using hardware mechanisms.",
+      "description": "This is a requirement to enforce information flow with a hardware device or mechanism.  By definition, this is not related to software applications.  This is expected to be addressed via hardware.\n\nDoes not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26811",
+      "title": "Applications must use security policy filters as a basis for making information flow control decisions.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nInformation flow enforcement mechanisms compare security attributes on all information (data content and data structure), source and destination objects, and respond appropriately (e.g., block, quarantine, alert administrator) when the mechanisms encounter information not explicitly allowed by the information flow policy. \n\nSecurity policy filters are defined by the organization and include, dirty word filters, file type checking filters, structured data filters, unstructured data filters, metadata content filters, and hidden content filters. \n\n- Structured data typically describes data intended for storage in a data management system such as a relational database.\n- Unstructured data refers to masses of digital information that do not have a data structure such as word processing documents, email, pictures, audio, and video.\n- In the case of unstructured data, metadata is considered to be data about the data in question. \n- In the case of structured data, metadata is considered to be data about the containers of the data. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26819",
+      "title": "Applications providing information flow control must uniquely authenticate destination domains when transferring information.",
+      "description": "Information flow control regulates where information is allowed to travel within an information system and between information systems (as opposed to who is allowed to access the information) and without explicit regard to subsequent accesses to that information. \n\nSpecific examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, application gateways, guards, cross domain systems) employing rule sets or establish configuration settings restricting information system services, provide a packet-filtering capability based on header information, or message-filtering capability based on content (e.g., using key word searches or document characteristics). \n\nAttribution, (e.g., the ability to attribute actions to individuals), processes or systems, is a critical component of a security concept of operations. \n\nThe ability to identify source and destination points for information flowing in an information system, allows forensic reconstruction of events when required, and increases policy compliance by attributing policy violations to specific organizations/individuals.  \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26820",
+      "title": "In support of information flow requirements, applications must track problems associated with information transfer.",
+      "description": "When an application transfers data, there is the chance an error or problem with the data transfer may occur.  Applications need to track failures and any problems encountered when performing data transfers so problems can be identified and remediated.  \n\nSome potential issues with a failed or problematic data transfer include:  leaving sensitive data in a processing queue indefinitely, partial or incomplete data transfers, and corrupted data transfers.  Tracking problems with data transfers also serves to create a forensic record that can be retained to assist in investigations regarding the flow of application data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26821",
+      "title": "Applications must support organizational requirements to implement separation of duties through assigned information access authorizations.",
+      "description": "Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action.  \n\nAdditionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26827",
+      "title": "Application users must utilize a separate, distinct administrative account when accessing application security functions or security-relevant information. Non-privileged accounts must be utilized when accessing non-administrative application functions. The application must provide this functionality itself or leverage an existing technology providing this capability.",
+      "description": "This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy such as Role Based Access Control (RBAC) is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. \n\nAudit of privileged activity may require physical separation employing information systems on which the user does not have privileged access.\n\nTo limit exposure and provide forensic history of activity when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions.\n\nIf feasible, applications should provide access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26830",
+      "title": "Applications must be able to function within separate processing domains (virtualized systems), when specified, so as to enable finer-grained allocation of user privileges.",
+      "description": "Applications must employ the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.  \n\nEmploying virtualization techniques to allow greater privilege within a virtual machine, while restricting privilege to the underlying actual machine is an example of providing separate processing domains for finer-grained allocation of user privileges.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26845",
+      "title": "The application must produce audit records containing sufficient information to establish what type of events occurred.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes:  time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26847",
+      "title": "The application must produce audit records containing sufficient information to establish when (date and time) the events occurred.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes:  time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26848",
+      "title": "The information system must provide additional protection for mobile devices accessed via login by purging information from the device after organization-defined number of consecutive, unsuccessful login attempts to the mobile device.",
+      "description": "Mobile devices present additional risks related to attempted unauthorized access.  If they are lost, stolen or misplaced, attempts can be made to unlock the device by guessing the pin.  In order to address this risk, mobile devices shall provide additional protection enabling the device to automatically wipe itself clean and purge itself of any and all data. \n\nThis does not apply to applications.  This is a requirement for Mobile Devices (smart phones, PDAs, etc) to be able to purge themselves of data if x number of failed login attempts occur.\n\nThis requirement applies only to mobile devices for which a login occurs (e.g., personal digital assistants and smart phones) and not to mobile devices accessed without a login such as removable media. In certain situations, this requirement may not apply to mobile devices if the information on the device is encrypted with sufficiently strong encryption mechanisms, making purging unnecessary. The login is to the mobile device, not to any one account on the device. \n\nTherefore, a successful login to any account on the mobile device resets the unsuccessful login count to zero. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26849",
+      "title": "The application must produce audit records containing sufficient information to establish where the events occurred.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes:  time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. \n\nWithout sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26851",
+      "title": "The application must produce audit records containing sufficient information to establish the sources of the events.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to:  time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. \n\nWithout information establishing the source of activity, the value of audit records from a forensics perspective is questionable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26853",
+      "title": "Applications must have the capability to limit the number of failed login attempts based upon an organization defined number of consecutive invalid attempts occurring within an organization defined time period.",
+      "description": "Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26855",
+      "title": "The application must enforce the organization-defined time period during which the limit of consecutive invalid access attempts by a user is counted.",
+      "description": "Anytime an authentication method is exposed, so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo aid in defeating these attempts, organizations define the number of times that a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26856",
+      "title": "Applications, when the maximum number of unsuccessful attempts are exceeded, must automatically lock the account/node for an organization-defined time period or lock the account/node until released by an administrator IAW organizational policy. ",
+      "description": "Anytime an authentication method is exposed so as to allow for the utilization of an application, there is a risk that attempts will be made to obtain unauthorized access. \n\nTo defeat these attempts, organizations define the number of times a user account may consecutively fail a login attempt. The organization also defines the period of time in which these consecutive failed attempts may occur. \n\nBy limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced.  Limits are imposed by locking the account. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26858",
+      "title": "Applications must display an approved system use notification message or banner before granting access to the system.  ",
+      "description": "Applications are required to display an approved system use notification message or banner before granting access to the system providing privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and states that: \n\n(i) users are accessing a U.S. Government information system; \n(ii) system usage may be monitored, recorded, and subject to audit; \n(iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties; and \n(iv) the use of the system indicates consent to monitoring and recording.\n\nSystem use notification messages can be implemented in the form of warning banners displayed when individuals log in to the information system. \n\nSystem use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist.  \n\nUse this banner for desktops, laptops, and other devices accommodating banners of 1300 characters. The banner shall be implemented as a click-through banner at logon (to the extent permitted by the operating system), meaning it prevents further activity on the information system unless and until the user executes a positive action to manifest agreement by clicking on a box indicating “OK”.\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"\n                                                                               \n\nFor Blackberries and other PDAs/PEDs with severe character limitations use the following:\n\n\"I've read & consent to terms in IS user agreem't.\"\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26860",
+      "title": "The application must produce audit records that contain sufficient information to establish the outcome (success or failure) of the events.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited to: time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. \n\nSuccess and failure indicators ascertain the outcome of a particular event.  As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26862",
+      "title": "The application must retain the notification message or banner on the screen until users take explicit actions to logon to or further access.",
+      "description": "To establish acceptance of system usage policy, a click-through banner at application logon is required. The banner shall prevent further activity on the application unless and until the user executes a positive action to manifest agreement by clicking on a box indicating \"OK\". The text of this banner should be customizable in the event of future user agreement changes. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26864",
+      "title": "The application must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes:  time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26865",
+      "title": "Applications must display an approved system use notification message or banner before granting access to the system.  \n",
+      "description": "Applications must display an approved system use notification message or banner before granting access to the system.  \n\nThe banner shall be formatted in accordance with the DoD policy \"Use of DoD Information Systems - Standard Consent and User Agreement\".  The message banner shall provide privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance and shall state that:\n \n(i) users are accessing a U.S. Government information system; \n(ii) system usage may be monitored, recorded, and is subject to audit; \n(iii) unauthorized use of the system is prohibited and subject to criminal and civil penalties;\n(iv) the use of the system indicates consent to monitoring and recording;\n(v) in the notice given to public users of the information system, shall provide a description of the authorized uses of the system.\n\nSystem use notification messages are implemented in the form of warning banners displayed when individuals log in to the information system. System use notification is intended only for information system access including an interactive login interface with a human user and is not intended to require notification when an interactive interface does not exist. \n\nThe banner shall state:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided\nfor USG-authorized use only.\nBy using this IS (which includes any device attached to this IS), you consent to the\nfollowing conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes\nincluding, but not limited to, penetration testing, COMSEC monitoring, network\noperations and defense, personnel misconduct (PM), law enforcement (LE), and\ncounterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine\nmonitoring, interception, and search, and may be disclosed or used for any USG authorized\npurpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect\nUSG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI\ninvestigative searching or monitoring of the content of privileged communications, or\nwork product, related to personal representation or services by attorneys,\npsychotherapists, or clergy, and their assistants. Such communications and work product\nare private and confidential. See User Agreement for details.\"\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26868",
+      "title": "Applications must include organization-defined additional, more detailed information in the audit records for audit events identified by type, location, or subject.\n\n",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.   Audit record content that may be necessary to satisfy the requirement of this control, includes:  time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.\n\nIn addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events. These events may be identified by type, location, or subject. \n\nAn example of detailed information that the organization may require in audit records is full-text recording of privileged commands or the individual identities of group account users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26871",
+      "title": "To support DoD requirements to centrally manage the content of audit records, applications must provide the ability to write specified audit record content to a centralized audit log repository.  ",
+      "description": "Information system auditing capability is critical for accurate forensic analysis.  Audit record content that may be necessary to satisfy the requirement of this control, includes but is not limited:  time stamps, source and destination IP addresses, user/process identifiers, event descriptions, application specific events, success/fail indications, filenames involved, access control or flow control rules invoked. \n\nCentralized 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.  When organizations define application components requiring centralized audit log management, applications need to support that requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26879",
+      "title": "Applications upon successful logon, must display to the user the date and time of the last logon (access).",
+      "description": "Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. \n\nThis requirement is intended to cover both traditional interactive logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26881",
+      "title": "In order to inform the user of failed login attempts made with the users account, the application upon successful logon/access must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access. ",
+      "description": "Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. \n\nThis requirement is intended to cover both traditional logons to information systems and general accesses to information systems that occur in other types of architectural configurations (e.g., service oriented architectures). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26882",
+      "title": "Applications must allocate audit record storage capacity.  ",
+      "description": "In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles.  The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26883",
+      "title": "In order to inform the user of the number of successful login attempts made with the users account, the application must notify the user of the number of successful logins/accesses occurring during an organization-defined time period.",
+      "description": "Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of successful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.  \n\nThis requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26884",
+      "title": "The application must notify the user of the number of unsuccessful login/access attempts occurring during an organization-defined time period.",
+      "description": "Users need to be aware of activity that occurs regarding their application account. Providing users with information regarding the number of unsuccessful attempts made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.\n\nThis requirement is intended to cover both traditional logons to information systems and general accesses to information systems occurring in other types of architectural configurations (e.g., service oriented architectures). In order to inform the user of the number of unsuccessful login attempts made with the users account.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26886",
+      "title": "Applications must notify users of  organization-defined security-related changes to the user’s account occurring during the organization-defined time period.",
+      "description": "Some organizations may define certain security events as events requiring user notification.  An organization may define an event such as a password change to a user's account occurring outside of normal business hours as a security related event requiring that the application user be notified. In those instances, where organizations define such events, the application must notify the affected user or users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26887",
+      "title": "Applications must configure their auditing to reduce the likelihood of storage capacity being exceeded.",
+      "description": "Applications need to be cognizant of potential audit log storage capacity issues.  During the installation and/or configuration process, applications should detect and determine if adequate storage capacity has been allocated for audit logs.  \n\nDuring the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient enough to meet storage requirements.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26888",
+      "title": "The application must protect against an individual falsely denying having performed a particular action.",
+      "description": "Non-repudiation of actions taken is required in order to maintain application integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. \n\nNon-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26889",
+      "title": "Applications themselves, or the logging mechanism the application utilizes, must provide a warning when allocated audit record storage volume reaches an organization-defined percentage of maximum audit record storage capacity.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include:  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nIf audit log capacity were to be exceeded then events subsequently occurring will not be recorded. Organizations shall define a maximum allowable percentage of storage capacity serving as an alarming threshold (e.g., application has exceeded 80 % of log storage capacity allocated) at which time the application or the logging mechanism the application utilizes will provide a warning to the appropriate personnel. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26890",
+      "title": "The application must associate the identity of the information producer with the information.",
+      "description": "Non-repudiation supports audit requirements to provide the appropriate organizational officials the means to identify who produced specific information in the event of an information transfer. \n\nThe nature and strength of the binding between the information producer and the information are determined and approved by the appropriate organizational officials based on the security categorization of the information and relevant risk factors. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26891",
+      "title": "Applications must validate the binding of the information producer’s identity to the information.",
+      "description": "Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document.\n\nThis non-repudiation control enhancement is intended to mitigate the risk that information gets modified between production and review. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26892",
+      "title": "The application must provide a real-time alert when organization-defined audit failure events occur.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include:  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. \n\nOrganizations shall define audit failure events requiring an application to send an alarm.  When those defined events occur, the application will provide a real-time alert to the appropriate personnel.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26893",
+      "title": "Applications must maintain reviewer/releaser identity and credentials within the established chain of custody for all information reviewed or released.",
+      "description": "Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. Non-repudiation services can be used to determine if information originated from an individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Non-repudiation services are obtained by employing various techniques or mechanisms (e.g., digital signatures, digital message receipts).\n\nWhen it comes to data review and data release, there must be a correlation between the data that is reviewed and the person who performs the review.  If the reviewer is a human or if the review function is automated but separate from the release/transfer function, the application associates the identity of the reviewer of the information to be released with the information and the information label. \n\nIn the case of human reviews, this requirement provides appropriate organizational officials the means to identify who reviewed and released the information. In the case of automated reviews, this control enhancement helps ensure only approved review functions are employed. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26894",
+      "title": "The application must validate the binding of the reviewer’s identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.",
+      "description": "This non-repudiation control enhancement is intended to mitigate the risk that information could be modified between review and transfer/release particularly when transfer is occurring between security domains.  \n\nIn those instances where the application is transferring data intended for release across security domains, the application must validate the binding of the reviewer’s identity to the information at the transfer/release point prior to release/transfer from one security domain to another security domain.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26896",
+      "title": "The application must provide the capability to compile audit records from multiple components within the system into a system-wide (logical or physical) audit trail that is time-correlated to within organization-defined level of tolerance.",
+      "description": "Audit generation and audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). \n\nThe events occurring must be time-correlated on order to conduct accurate forensic analysis.  In addition, the correlation must meet a certain tolerance criteria.  For instance, the organization may define that the time stamps of different audited events must not differ by any amount greater than ten seconds.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26900",
+      "title": "The application must produce a system-wide (logical or physical) audit trail composed of audit records in a standardized format.",
+      "description": "Audits records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events).  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26901",
+      "title": "The application must provide audit record generation capability for defined auditable events within defined application components.",
+      "description": "Audit records can be generated from various components within the information system (e.g., network interface, hard disk, modem etc.). From an application perspective, certain specific application functionalities may be audited as well.\n\nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked).\n\nOrganizations define which application components shall provide auditable events. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26902",
+      "title": "The application must allow designated organizational personnel to select which auditable events are to be audited by specific components of the system.",
+      "description": "Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, certain specific application functionalities may be audited, as well.\n\nThe list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked).\n\nOrganizations may define the organizational personal accountable for determining which application components shall provide auditable events.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26903",
+      "title": "Applications must generate audit records for the DoD selected list of auditable events. ",
+      "description": "Audit records can be generated from various components within the information system. The list of audited events is the set of events for which audits are to be generated. \n\nThis set of events is typically a subset of the list of all events for which the system is capable of generating audit records (i.e., auditable events). \n\nDoD shall select the list of auditable events and applications must generate audit records for those events.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26904",
+      "title": "The application must initiate session auditing upon start up.",
+      "description": "Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26905",
+      "title": "The application must provide the capability to capture, record, and log all content related to a user session.",
+      "description": "While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to capture, record, and log all content related to a particular user's application session.  \n\nThese instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned.  Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. \n\nThese monitoring events occur at the application layer and as such maybe required to be conducted at a host system however in some cases network monitoring may be involved as well.\n\nApplications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations.  This includes the capability to capture, record, and log all content related to an established user session. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26906",
+      "title": "The application must provide the capability to remotely view/hear all content related to an established user session in real time.",
+      "description": "While a great deal of effort is made to secure applications so as to prevent unauthorized access, in certain instances there can be valid requirements to listen/hear or view all content related to a particular user's application session in real time as it occurs.  \n\nThese instances are reserved for monitoring or investigative purposes supported through policy and are officially sanctioned.  Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations. \n\nThese monitoring events occur at the application layer and as such, may be required to be conducted at a host system however in some cases network monitoring may be involved as well.\n\nApplications must support valid monitoring requirement capabilities performed in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations.  This includes the capability to remotely view/hear all content related to an established user session in real time. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26907",
+      "title": "The application must use organization-defined replay-resistant authentication mechanisms for network access to privileged accounts.",
+      "description": "An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nTechniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26908",
+      "title": "The application must use organization-defined replay-resistant authentication mechanisms for network access to non-privileged accounts.",
+      "description": "An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nTechniques used to address this include protocols using nonce's (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security), and time synchronous or challenge-response one-time authenticators. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26909",
+      "title": "Applications required to identify devices must uniquely identify and authenticate an organization-defined list of specific and/or types of devices before establishing a connection.",
+      "description": "Device authentication is a solution enabling an organization to manage both users and devices.  It is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. \n\nDevice authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. \n\nThe application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. \n\nThe required strength of the device authentication mechanism is determined by the security categorization of the information system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26910",
+      "title": "Applications managing devices must authenticate devices before establishing remote network connections using bidirectional authentication between devices that are cryptographically based.",
+      "description": "Device authentication is a solution enabling an organization to manage devices.  \n\nIt is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. \n\nDevice authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. \n\nThe application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. \n\nThe required strength of the device authentication mechanism is determined by the security categorization of the information system. \n\nRemote network connection is any connection with a device communicating through an external network (e.g., the Internet). \n\nBidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26911",
+      "title": "Applications managing network connections for devices must authenticate devices before establishing wireless network connections by using bidirectional authentication that is cryptographically based.",
+      "description": "Device authentication is a solution enabling an organization to manage devices.  \n\nIt is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. \n\nDevice authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device, as deemed appropriate by the organization. \n\nThe application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. \n\nThe required strength of the device authentication mechanism is determined by the security categorization of the information system.  \n\nBidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26912",
+      "title": "Applications managing network connectivity must have the capability to authenticate devices before establishing network connections by using bidirectional authentication that is cryptographically based.",
+      "description": "Device authentication is a solution enabling an organization to manage both users and devices.  \n\nIt is an additional layer of authentication ensuring only specific pre-authorized devices operated by specific pre-authorized users can access the network. \n\nDevice authentication requires unique identification and authentication that may be defined by type, by specific device, or by a combination of type and device as deemed appropriate by the organization. \n\nThe application typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area networks. \n\nThe required strength of the device authentication mechanism is determined by the security categorization of the information system.  \n\nBidirectional authentication provides a means for both connecting parties to mutually authenticate one another and cryptographically based authentication provides a secure means of authenticating without the use of clear text passwords. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26913",
+      "title": "Web services applications establishing identities at run-time for previously unknown entities must dynamically manage identifiers, attributes, and associated access authorizations.",
+      "description": "Web services are web applications providing a method of communication between two or more different electronic devices.  They are normally used by applications to provide each other with data.  \n\nThe W3C defines a web service as:\n\"a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically Web Services Description Language or WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards\".\n\nWeb services provide different challenges in managing access than what is presented by typical user based applications. In contrast to conventional access control approaches which employ static information system accounts and predefined sets of user privileges, many service-oriented architecture implementations rely on run time access control decisions facilitated by dynamic privilege management.  While user identities remain relatively constant over time, user privileges may change more frequently based on the ongoing mission/business requirements and operational needs of the organization. \n\nIn contrast to conventional approaches to identification and authentication which employ static information system accounts for preregistered users, many service-oriented architecture implementations rely on establishing identities at run time for entities that were previously unknown. Dynamic establishment of identities and association of attributes and privileges with these identities are anticipated and provisioned. Pre-established trust relationships and mechanisms with appropriate authorities to validate identities and related credentials are essential.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26914",
+      "title": "Applications must support organizational requirements to disable user accounts after an organization-defined time period of inactivity.",
+      "description": "Users are often the first line of defense within an application.  Active users take notice of system and data conditions and are usually the first to notify systems administrators when they notice a system or application related anomaly, particularly if the anomaly is related to their own account. \n\nInactive user accounts pose a risk to systems and applications. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.  \n\nAttackers that are able to exploit an inactive user account can potentially obtain and maintain undetected access to an application. Applications need to track periods of user inactivity and disable application accounts after an organization-defined period of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or will have data compromised. \n\nManagement of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.\n\nTo avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26915",
+      "title": "The application must support organizational requirements to enforce minimum 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. \n\nPassword length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password is, the lower the number of possible combinations that need to be tested before the password is compromised. \n\nUse of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26916",
+      "title": "The application must support organizational requirements to prohibit password reuse for the organization-defined number of generations.",
+      "description": "Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. \n\nTo meet password policy requirements, passwords need to be changed at specific policy based intervals.  \n\nIf the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26917",
+      "title": "The application must enforce configurable traffic volume thresholds representing auditing capacity for network traffic.",
+      "description": "It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken 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. \n\nOne method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data.  The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged.  Applications and/or logging mechanisms employed by applications must take steps to enforce configurable volume thresholds representing the auditing capacity for network traffic.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26918",
+      "title": "The application must support organizational requirements to enforce password complexity by the number of upper case characters used.",
+      "description": "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. \n\nUse of a complex password helps to increase the time and resources required to compromise the password. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26919",
+      "title": "The application must support organizational requirements to enforce password complexity by the number of lower case characters used.",
+      "description": "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. \n\nThe more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26920",
+      "title": "The application must support organizational requirements to enforce password complexity by the number of numeric characters used.",
+      "description": "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. \n\nThe more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26921",
+      "title": "The application must support organizational requirements to enforce password complexity by the number of special characters used.",
+      "description": "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 in determining how long it takes to crack a password. \n\nThe more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised. \n\nUse of a complex password helps to increase the time and resources required to compromise the password. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26922",
+      "title": "The application must support organizational requirements to enforce the number of characters that get changed when passwords are changed.",
+      "description": "Passwords need to be changed at specific policy based intervals.  \n\nIf the information system or application allows the user to consecutively reuse extensive portions of their password when they change their password, the end result is a password that has not had enough elements changed to meet the policy requirements.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26923",
+      "title": "The application must support organizational requirements to enforce password encryption for storage.",
+      "description": "Applications must enforce password encryption when storing passwords.  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 and easily compromised.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26924",
+      "title": "The application must support organizational requirements to enforce password encryption for transmission.",
+      "description": "Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26925",
+      "title": "Applications must enforce password minimum lifetime restrictions.",
+      "description": "Password minimum lifetime is defined as:  the minimum period of time, (typically in days) a user's password must be in effect before the user can change it. \n\nRestricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy based intervals, however if the application allows the user to immediately and continually change their password then the password could be repeatedly changed in a short period of time so as to defeat the organizations policy regarding password reuse.\n\nThis would allow users to keep using the same password over and over again by immediately changing their password X number of times.  This would effectively negate password policy. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26926",
+      "title": "Applications must enforce password maximum lifetime restrictions.",
+      "description": "Password maximum lifetime is defined as:  the maximum period of time, (typically in days) a user's password may be in effect before the user is forced to change it. \n\nPasswords need to be changed at specific policy based intervals as per policy.  Any password no matter how complex can eventually be cracked.  \n\nOne method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords there is the risk that the system and/or application passwords could be compromised.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26927",
+      "title": "The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path with status information to an accepted trust anchor.",
+      "description": "A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. \n\nWhen there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be for example a Certification Authority (CA).  A certification path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. \n\nPath validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted.  \n\nStatus information for certification paths includes, certificate revocation lists or online certificate status protocol responses. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26928",
+      "title": "The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key.",
+      "description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information.  \n\nIf the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and can pretend to be the authorized user. \n\nBoth the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26929",
+      "title": "The application must protect audit data records and integrity by using cryptographic mechanisms.",
+      "description": "Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data.  An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26930",
+      "title": "Applications must ensure that PKI-based authentication maps the authenticated identity to the user account.",
+      "description": "The cornerstone of the PKI is the private key used to encrypt or digitally sign information.  The key by itself is a cryptographic value that does not contain specific user information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26932",
+      "title": "The application must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.",
+      "description": "To prevent the compromise of authentication information such as passwords during the authentication process,  the feedback from the information system shall not provide any information that would allow an unauthorized user to compromise the authentication mechanism.  \n\nObfuscation of user provided information when typed into the system is a method used in addressing this risk. \n\nFor example, displaying asterisks when a user types in a password, is an example of obscuring feedback of authentication information.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26933",
+      "title": "The application must protect the audit records generated as a result of remote accesses to privileged accounts and the execution of privileged functions.",
+      "description": "Protection of audit records and audit data is of critical importance.  Care must be taken to ensure privileged users cannot circumvent audit protections put in place. \n\nAuditing might not be reliable when performed by an information system which the user being audited has privileged access to. \n\nThe privileged user could inhibit auditing or directly modify audit records.  To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus, limiting the users with audit-related privileges. \n\nReducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access or by using storage media that cannot be modified (e.g., write-once recording devices).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26934",
+      "title": "The application must support the enforcement of logical access restrictions associated with changes to application configuration. ",
+      "description": "When dealing with access restrictions pertaining to change control, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26935",
+      "title": "The application must use mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.",
+      "description": "Encryption is only as good as the encryption modules utilized. Unapproved cryptographic module algorithms cannot be verified, and cannot be relied upon to provide confidentiality or integrity and DoD data may be compromised due to weak algorithms. \n\nApplications utilizing encryption are required to use approved encryption modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.  \n\nFIPS 140-2 is the current standard for validating cryptographic modules and NSA Type-X (where X=1, 2, 3, 4) products are NSA certified hardware based encryption modules. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26937",
+      "title": "The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).",
+      "description": "Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nNon-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access such as accessing a web server.  \n\nAccordingly, a risk assessment is used in determining the authentication needs of the organization. \n\nScalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26938",
+      "title": "The application must support the organizational requirement to employ automated mechanisms enforcing access restrictions.",
+      "description": "When dealing with access restrictions pertaining to change control, it should be noted, any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals should be allowed to obtain access to information system components for the purposes of initiating changes, upgrades, and modifications.  \n\nAccess restrictions for change also include application software libraries. \n\nExamples of access restrictions include, physical and logical access controls, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26939",
+      "title": "Applications that are designed and intended to address incident response scenarios must provide a configurable capability to automatically disable an information system if any of the organization defined security violations are detected.",
+      "description": "When responding to a security incident a capability must exist allowing authorized personnel to disable a particular system if the system exhibits a security violation and the organization determines an action is warranted. \n\nOrganizations shall define a list of security violations that warrant an immediate disabling of a system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26940",
+      "title": "The application must support the employment of automated mechanisms supporting the auditing of enforcement actions.",
+      "description": "Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. \n\nAccess restrictions for change also include software libraries. \n\nExamples of access restrictions include:  physical and logical access controls, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26941",
+      "title": "Applications related to incident tracking must support organizational requirements to employ automated mechanisms to assist in the tracking of security incidents.",
+      "description": "Incident tracking is a method of monitoring networks and systems for activity indicative of viral infection or system attack. \n\nMonitoring for this type of activity provides the organization with the capability to proactively detect and respond to attacks. Automated mechanisms for tracking security incidents and collecting/analyzing incident information include, the Einstein network monitoring device and monitoring online Computer Incident Response Centers (CIRCs) or other electronic databases of incidents. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26943",
+      "title": "Applications must prevent the installation of organization-defined critical software programs not signed with a certificate that has been recognized and approved by the organization.",
+      "description": "Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nAccordingly, software defined by the organization as critical software may be signed with a certificate recognized and approved by the organization.  \n\nExamples of critical software programs and/or modules include, for example, patches, service packs, software libraries and where applicable, device drivers.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26944",
+      "title": "Applications scanning for malicious code must scan all media used for system maintenance prior to use.",
+      "description": "There are security-related issues arising from software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer installed on a system in order to troubleshoot system traffic, or a vendor installing or running a diagnostic application in order to troubleshoot an issue with a vendor supported system).\n\nThis requirement ensures the media containing the application is scanned for malicious code prior to use. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26945",
+      "title": "The organization must employ automated mechanisms to restrict the use of maintenance tools to authorized personnel only.",
+      "description": "The intent of this control is to address the security-related issues arising from the software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer introduced for the purpose of a particular maintenance activity).  \n\nThis is an organizational requirement to utilize automated mechanisms in order to prevent maintenance tools from being utilized by unauthorized personnel. This requirement does not address application characteristics and does not apply.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26946",
+      "title": "The application must support the enforcement of a two-person rule for changes to organization-defined application components and system-level information.",
+      "description": "Regarding access restrictions for changes made to organization defined information system components and system level information.  Any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.  \n\nA two person rule requires two separate individuals acknowledge and approve those changes.  Two person rule for changes to critical application components helps to reduce risks pertaining to availability and integrity.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26947",
+      "title": "The organization must audit non-local maintenance and diagnostic sessions.",
+      "description": "Non-local 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 in order to conduct system diagnostics.  \n\nThis is an organizational requirement to audit non-local maintenance sessions. This does not address an application characteristic and does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26948",
+      "title": "Applications used for non-local maintenance sessions must protect those sessions through the use of a strong authenticator tightly bound to the user.",
+      "description": "Non-local 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\nIdentification and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions must be consistent with the network access requirements in IA-2. Strong authenticators include, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.\n\nExamples of types of applications used for non-local maintenance and diagnostic activities are provided below.  Use as an example does not imply compliance with policy requirements or approval for use.   Examples include but are not limited to:\n\n- Terminal Services\n- Remote Desktop\n- Dameware\n- VNC (all variants)\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26949",
+      "title": "Applications must limit privileges to change the software resident within software libraries (including privileged programs).",
+      "description": "When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n\nIf the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nThis requirement is contingent upon the language in which the application is programmed as many application architectures in use today incorporate their software libraries into and make them inseparable from their compiled distributions rendering them static and version dependant.  However, this requirement does apply to applications with software libraries accessible and configurable as in the case of interpreted languages.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26950",
+      "title": "The organization must protect non-local maintenance sessions by separating the maintenance session from other network sessions with the information system by either physically separated communications paths; or logically separated communications paths based upon encryption.",
+      "description": "This is a requirement that maintenance needs to be done on a separate interface or encrypted channel to segment maintenance activity from regular usage.\n\nThis does not address an application characteristic and does not apply.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26952",
+      "title": "Applications must automatically implement organization-defined safeguards and countermeasures if security functions (or mechanisms) are changed inappropriately.",
+      "description": "Any changes to the application components of the information system can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to the application components for purposes of initiating changes, including upgrades and modifications.\n\nIn order to ensure a prompt response to unauthorized changes to application security functions or security mechanisms, organizations may define countermeasures and safeguards that monitoring applications must undertake in the event these types of changes occur.  This degree of functionality is typically built into a support architecture providing change management and/or system monitoring capabilities.  \n\nAutomatic implementation of safeguards and countermeasures includes:  reversing the change; halting the system; or triggering an audit alert when an unauthorized modification to a critical security file or process occurs.  \n\nExamples of such support architecture include but are not limited to: HIDS, change management software or file/process monitoring software. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26953",
+      "title": "The application must employ cryptographic mechanisms to protect the integrity and confidentiality of non-local maintenance and diagnostic communications.",
+      "description": "Non-local 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 act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information, and potentially sensitive application data. \n\nWhen applications provide a remote management capability that is inherent to the application, the application needs to ensure the communication channels used to remotely access the system are adequately protected. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26954",
+      "title": "The application must employ strong identification and authentication techniques when establishing non-local maintenance and diagnostic sessions",
+      "description": "Non-local 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 act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information and potentially sensitive application data. \n\nWhen applications provide a remote management capability that is inherent to the application, the application needs to ensure the identification and authentication techniques used to remotely access the system are strong enough to protect the system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26955",
+      "title": "Configuration management applications must employ automated mechanisms to centrally manage configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. \n\nSecurity-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nSecurity-related parameters include:  registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.  \n\nRather than visiting each and every system when making application configuration changes, organizations will employ automated tools that can make changes across all systems.  This greatly increases efficiency and manageability of systems and applications in a large scale environment.  To support this requirement, configuration management applications will employ automated mechanisms to centrally manage configuration settings and applications, in general, will ensure that they do not hinder the use of such tools. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26956",
+      "title": "Configuration management applications must employ automated mechanisms to centrally apply configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. \n\nSecurity-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nSecurity-related parameters include: registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.  \n\nRather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems.  This greatly increases efficiency and manageability of systems and applications in a large scale environment.  \n\nCentrally apply means to apply settings from a centralized location.  In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies.  This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution.\n\nTo support this requirement, configuration management applications will employ automated mechanisms to centrally apply configuration settings and applications in general will ensure they do not hinder the use of such tools.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26957",
+      "title": "Configuration management applications must employ automated mechanisms to centrally verify  configuration settings.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. \n\nSecurity-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. \n\nSecurity-related parameters include:  registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.  \n\nRather than visiting each and every system when making configuration changes, organizations will employ automated tools that can make changes across all systems.  This greatly increases efficiency and manageability of systems and applications in a large scale environment.  \n\nCentrally verify means to verify settings have taken effect from a centralized location.  In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies.  This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution.\n\nTo support this requirement, configuration management applications will employ automated mechanisms to centrally verify configuration settings and applications in general will ensure they do not hinder the use of such tools.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26958",
+      "title": "Configuration management applications must employ automated mechanisms to centrally respond to unauthorized changes to configuration settings. ",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. \n\nSecurity-related parameters are those parameters impacting the security state of the system, including parameters related to meeting other security control requirements. \n\nSecurity-related parameters include:  registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.  \n\nResponses to unauthorized changes to configuration settings can include:  alerting designated organizational personnel, restoring mandatory/organization-defined configuration settings, or in the extreme case, halting affected information system processing.  \n\nCentrally respond means to respond to unauthorized changes to settings have taken effect from a centralized location.  In order to accommodate large scale environments, centralized solutions may also employ distributed systems used as configuration management proxies.  This is allowable as long as these systems are centrally managed and controlled as part of the overall configuration management solution.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26959",
+      "title": "Configuration management solutions must track unauthorized, security-relevant configuration changes.",
+      "description": "Configuration settings are the configurable security-related parameters of information technology products that are part of the information system. \n\nSecurity-related parameters are those parameters impacting the security state of the system including parameters related to meeting other security control requirements. \n\nSecurity-related parameters include:  registry settings; account, file, and directory settings (i.e., permissions); and settings for services, ports, protocols, and remote connections.  \n\nIncident Response teams require input from authoritative sources in order to investigate events that have occurred. Configuration management solutions are a logical source for providing information regarding system configuration changes.  Unauthorized, security-relevant configuration changes must be incorporated into the organization’s incident response capability to ensure such detected events are tracked for historical purposes.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26961",
+      "title": "Applications must adhere to the principles of least functionality by providing only essential capabilities.",
+      "description": "Information systems are capable of providing a wide variety of functions and services.  Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).  \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives.  Examples include, but are not limited to:  installing advertising software, demo's or browser plugins not related to requirements or providing a wide array of functionality not required for every mission, yet cannot be disabled. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26962",
+      "title": "The application must support the organizational requirements to specifically prohibit or restrict the use of unauthorized functions, ports, protocols, and/or services.",
+      "description": "Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nAdditionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services)  but doing so increases risk over limiting the services provided by any one component.  \n\nTo support the requirements and principles of least functionality the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26963",
+      "title": "To support the requirements and principles of least functionality, the application must support organizational requirements regarding the use of automated mechanisms preventing program execution on the information system in accordance with the organization-defined specifications.",
+      "description": "Information systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). \n\nStandard operating procedure for placing an information system into a production environment includes creating a baseline configuration of the system.  The baseline configuration provides information about the components of the information system (e.g., the standard software load for a workstation, server, network component, or mobile device including operating system/installed applications with current version numbers and patch information), network topology, and the logical placement of the component within the system architecture. \n\nIt is sometimes convenient to provide multiple services from a single information system, but doing so increases risk when compared to limiting the services provided by any one system.   This is particularly true when these services have conflicting missions, user communities or availability requirements.\n\nThis requirement addresses the need to provide an automated mechanism that will prevent the execution of programs not associated with the established baseline configuration.\n\nThis is a requirement to disable services as part of the baseline process and provide automated tools that monitor the system and prevent unauthorized system processes from executing. \n\nThis requirement will apply to configuration management applications, HIDS applications and other similar types of applications designed to manage system processes and configurations. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26964",
+      "title": "The organization must employ automated mechanisms, per organization-defined frequency, to detect the addition of unauthorized components/devices into the information system.",
+      "description": "Information deemed to be necessary by the organization to achieve effective property accountability can include: hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. \n\nThis is not an application requirement. This requirement is regarding information system component inventory.  The purpose is to require organizations to employ an automated mechanism to inventory and detect when new devices and components are installed into information systems. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26965",
+      "title": "Applications must implement transaction recovery for systems that are transaction-based.",
+      "description": "Application recovery and reconstitution constitutes executing an information system contingency plan that is comprised of activities that restore essential missions and business functions. \n\nDatabase management systems and transaction-based processing systems are examples of information systems that are transaction-based. Transaction rollback and transaction journaling are examples of mechanisms supporting transaction recovery.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26966",
+      "title": "Backup / Disaster Recovery oriented applications must be capable of backing up user-level information per a defined frequency. ",
+      "description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nUser-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user generated data is backed up at a defined frequency.  This includes data stored on file systems, within databases or within any other storage media.\n\nApplications performing backups must be capable of backing up user-level information per the DoD defined frequency.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26967",
+      "title": "The application must reject or delay, as defined by the organization, network traffic generated above configurable traffic volume thresholds.",
+      "description": "It is critical when a system is at risk of failing to process audit logs as required; actions are automatically taken to mitigate the failure or risk of failure. \n\nOne method used to thwart the auditing system is for an attacker to attempt to overwhelm the auditing system with large amounts of irrelevant data.  The end result being audit logs that are either overwritten and activity thereby erased or disk space that is exhausted and any future activity is no longer logged. \n\nIn many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26968",
+      "title": "The application must invoke a system shutdown in the event of an audit failure, unless an alternative audit capability exists.",
+      "description": "It is critical when a system is at risk of failing to process audit logs as required; it takes action to mitigate the failure. If the system were to continue processing without auditing enabled, actions can be taken on the system that cannot be tracked and recorded for later forensic analysis. \n\nAudit processing failures include; software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.  \n\nIn many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. This forces the application to detect and take actions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26969",
+      "title": "The application must support and must not impede organizational requirements to conduct backups of system-level information contained in the information system per organization-defined frequency.",
+      "description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nSystem-level information includes:  system-state information, operating system and application software, and licenses. \n\nBackups shall be consistent with organizational recovery time and recovery point objectives. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26970",
+      "title": "The application must alert designated organizational officials in the event of an audit processing failure.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Audit processing failures include;  software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26971",
+      "title": "The application must support and must not impede organizational requirements to conduct backups of information system documentation including security-related documentation per organization-defined frequency. ",
+      "description": "Information system backup is a critical step in maintaining data assurance and availability. \n\nInformation system and security related documentation contains information pertaining to system configuration and security settings.  \n\nBackups shall be consistent with organizational recovery time and recovery point objectives. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26972",
+      "title": "The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). ",
+      "description": "To assure accountability and prevent unauthorized access, organizational users shall be identified and authenticated. \n\nOrganizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n\nUsers (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization which outlines specific user actions that can be performed on the information system without identification or authentication. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26973",
+      "title": "The application must use multifactor authentication for network access to privileged accounts.",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA privileged account is defined as:  \nAn information system account with authorizations of a privileged user. \n\nNetwork Access is defined as: \nAccess to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26974",
+      "title": "The application must be capable of taking organization-defined actions upon audit failure (e.g., overwrite oldest audit records, stop generating audit records, cease processing, notify of audit failure).",
+      "description": "It is critical when a system is at risk of failing to process audit logs as required; it detects and takes 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.  Applications are required to be capable of either directly performing or calling system level functionality performing defined actions upon detection of an application audit log processing failure.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26975",
+      "title": "The application must use multifactor authentication for network access to non-privileged accounts.",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA non-privileged account is defined as:  \nAn information system account with authorizations of a regular or non-privileged user. \n\nNetwork Access is defined as: \nAccess to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, Internet). \n\nApplications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26976",
+      "title": "To support audit review, analysis and reporting the application must integrate audit review, analysis, and reporting processes to support organizational processes for investigation and response to suspicious activities.",
+      "description": "Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner.  \n\nAudit review, analysis and reporting are all activities related to the evaluation of system activity through the inspection and analysis of system log data. \n\nSome examples include but are not limited to:  organizational requirements to cooperate with legal counsel and/or auditors in order to provide reports on certain types of system activity or analyzing system logs to ascertain sources or causes of certain system activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26977",
+      "title": "The application must use multifactor authentication for local access to privileged accounts.",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA privileged account is defined as an information system account with authorizations of a privileged user. \n\nLocal Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26978",
+      "title": "The application must use multifactor authentication for local access to non-privileged accounts.",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. \n\nLocal Access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26979",
+      "title": "Applications authenticating users must ensure users are authenticated with an individual authenticator prior to using a group authenticator.",
+      "description": "To assure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated.  \n\nA group authenticator is a generic account used by multiple individuals.  Use of a group authenticator alone does not uniquely identify individual users.  An example of a group authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'sa' account or a \"helpdesk\" account.\n\nFor example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role.  This method provides for unique individual authentication prior to using a group authenticator.\n\nSome applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.\n\nThere may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication.  An example of this type of access is a web server which contains publicly releasable information. These types of accesses are allowed but must be explicitly identified and documented by the organization.\n  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26980",
+      "title": "Applications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device that is separate from the information system gaining access.  ",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA privileged account is defined as an information system account with authorizations of a privileged user.  \n\nNetwork access is defined as; any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection.\n\nOut Of Band 2 Factor Authentication (OOB2FA) is defined as:  when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. \n\nFor example, a mobile device such as a smart phone is registered within the application to an application user.  Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process.\n\nOOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user.  \n\nApplications using multifactor authentication when accessing privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-26981",
+      "title": "Applications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. \n",
+      "description": "Multifactor authentication is defined as: using two or more factors to achieve authentication. \n\nFactors include: \n(i) something a user knows (e.g., password/PIN); \n(ii) something a user has (e.g., cryptographic identification device, token); or \n(iii) something a user is (e.g., biometric). \n\nA non-privileged account is defined as an information system account with authorizations of a non-privileged user or simply, a regular user.\n\nNetwork access is defined as any access to an information system by a user (or process acting on behalf of a user) where said access is obtained through a network connection.\n\nOut Of Band 2 Factor Authentication is defined as: when one of the authentication factors is provided by a device that is separate from the system that is used to gain access. \n\nFor example, a mobile device such as a smart phone is registered within the application to an application user.  Upon a successful authentication, the system sends instructions to the registered mobile device in the form of on-screen prompts instructing the user on how to complete the login process.\n\nOOB2FA employs separate communication channels where at least one is independently maintained and trusted to authenticate an end user.  \n\nApplications using multifactor authentication when accessing non-privileged accounts via the network must provide one of the factors by a device separate from the information system gaining access. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27011",
+      "title": "The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems.",
+      "description": "A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. \n\nAuthoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27012",
+      "title": "The application must perform data origin authentication and data integrity verification on all resolution responses received whether or not local client systems explicitly request this service.",
+      "description": "A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. \n\nAuthoritative DNS servers are examples of authoritative sources owning DNS data. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27013",
+      "title": "The information systems that collectively provide name/address resolution service for an organization must be fault-tolerant.",
+      "description": "A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative DNS servers, one configured as primary and the other as secondary. Additionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). \n\nWith regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). \n\nThis requirement addresses the need to have redundant DNS servers and does not apply to DNS application functionality.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27014",
+      "title": "Applications that collectively provide name/address resolution service for an organization must implement internal/external role separation.",
+      "description": "A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least two authoritative domain DNS servers, one configured as primary and the other as secondary. \n\nAdditionally, the two servers are commonly located in two different network subnets and geographically separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an internal role, only process name/address resolution requests from within the organization (i.e., internal clients). \n\nDNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address ranges, explicit lists). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27015",
+      "title": "Application must ensure  authentication of both client and server during the entire session. An example of this is SSL Mutual Authentication.\n",
+      "description": "This control focuses on communications protection at the session, versus packet level. \n\nAt the application layer, session IDs are tokens generated by web applications to uniquely identify an application user's session. Web applications utilize session tokens or session IDs in order to establish application user identity.  Proper use of session IDs addressed man-in-the-middle attacks including session hijacking or insertion of false information into a session. This control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented architectures providing web-based services). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27016",
+      "title": "Applications must terminate user sessions upon user logout or any other organization or policy defined session termination events such as idle time limit exceeded.",
+      "description": "This requirement focuses on communications protection at the application session, versus network packet level. \n\nSession IDs are tokens generated by web applications to uniquely identify an application user's session.   Applications will make application decisions and execute business logic based on the session ID. Unique session identifiers or IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker.  Unique session IDs help to reduce predictability of said identifiers.  Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session.  If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.  When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that particular user session.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27017",
+      "title": "Applications providing a login capability must also provide a logout functionality to allow the user to manually terminate the session.",
+      "description": "Manually terminating an application session allows users to immediately depart the physical vicinity of the system they are logged into without the risk of subsequent system users reactivating or continuing their application session.  User's who log into applications must have the ability to manually terminate their application session.  \n\nWithout an observable manual logout capability provided by the application, the user will have no means of manually terminating their application session.  Their session could remain active until which time the inactivity period expires and the application automatically logs the user out.  This increases the likelihood that the next subsequent user of the system could pick up on the previous user's session and continue utilizing the application as the previous user.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27018",
+      "title": "Applications must generate a unique session identifier for each session.",
+      "description": "This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. \n\nUnique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker.  Unique session identifiers help to reduce predictability of said identifiers.  Unique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session.  If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27019",
+      "title": "Applications must recognize only system-generated session identifiers.",
+      "description": "This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. \n\nUnique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker.  Unique session identifiers help to reduce predictability of said identifiers.  \n\nUnique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session.  If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27020",
+      "title": "Applications must generate unique session identifiers with organization-defined randomness requirements.",
+      "description": "This requirement focuses on communications protection at the application session, versus network packet level. The intent of this control is to establish grounds for confidence at each end of a communications session in the ongoing identity of the other party and in the validity of the information being transmitted. \n\nUnique session IDs are the opposite of sequentially generated session IDs which can be easily guessed by an attacker.  Unique session identifiers help to reduce predictability of said identifiers.  \n\nUnique session IDs address man-in-the-middle attacks including session hijacking or insertion of false information into a session.  If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.\n\nOrganizations can define the randomness of unique session identifiers when deemed necessary (e.g., sessions in service-oriented architectures providing web-based services). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27021",
+      "title": "Applications must be built to fail to a known safe state for defined types of failures.",
+      "description": "Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. \n\nFailure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. \n\nFailure in a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability.  Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission/business processes. \n\nAn example is a firewall that blocks all traffic rather than allowing all traffic when a firewall component fails.  This prevents an attacker from forcing a failure of the system in order to obtain access.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27023",
+      "title": "Only a Honey Pot information system and/or application must include components that proactively seek to identify web-based malicious code. Honey Pot systems must be not be shared or used for any other purpose other than described.",
+      "description": "A Honey Pot is an organization designated information system and/or application that includes components specifically designed to be the target of malicious attacks for the purpose of detecting, deflecting, and analyzing such attacks. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27024",
+      "title": "Applications must take needed steps to protect data at rest and ensure confidentiality and integrity of application data. ",
+      "description": "This control is intended to address the confidentiality and integrity of\ninformation at rest in non-mobile devices and covers user information and system information.  Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use.  \n\nUser data generated, as well as, application specific configuration data needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, and filtering routers and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27025",
+      "title": "Applications must isolate security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The application must isolate security functions from non-security functions.",
+      "description": "Security functions are defined as \"the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based\".  \n\nDevelopers and implementers can increase the assurance in security functions by employing well-defined security policy models, structured, disciplined, and rigorous hardware and software development techniques, and sound system/security engineering principles. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27027",
+      "title": "Applications must meet organizational requirements to implement an information system isolation boundary that minimizes the number of non-security functions included within the boundary containing security functions.",
+      "description": "The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27029",
+      "title": "Applications must meet organizational requirements to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.",
+      "description": "The information system isolates security functions from non-security functions by means of an isolation boundary (implemented via partitions and domains) controlling access to and protecting the integrity of, the hardware, software, and firmware that perform those security functions. The information system maintains a separate execution domain (e.g., address space) for each executing process.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27030",
+      "title": "The application must protect the integrity of information during the processes of data aggregation, packaging, and transformation in preparation for transmission.",
+      "description": "Information can be subjected to unauthorized changes (e.g., malicious and/or unintentional modification) at information aggregation or protocol transformation points. It is therefore imperative the application take steps to validate and assure the integrity of data while at these stages of processing. \n\nFor example, an application developer may determine based upon application requirements that various application data must accumulate in a processing queue where the application analyses, packages or transforms the data pending a data transfer.  A window of time now exists where if an attacker were to gain access to the data residing in the application queue they could potentially compromise that data or alter results.  The application must ensure the integrity of data that is pending transfer is maintained. If the application were to simply transmit aggregated, packaged or transformed data without ensuring the data was not manipulated during these processes, then the integrity of the data may be called into question.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27031",
+      "title": "Applications required to be non-modifiable must support organizational requirements to provide components that contain no writeable storage capability.  These components must be persistent across restart and/or power on/off.",
+      "description": "Organizations may require applications or application components to be non-modifiable or to be stored and executed on non-writeable storage. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image and eliminates the possibility of malicious code insertion. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27032",
+      "title": "Applications must, for organization-defined information system components, load and execute the operating environment from hardware-enforced, read-only media.",
+      "description": "Organizations may require the information system to load the operating environment from hardware enforced read-only media. The term operating environment is defined as the code upon which applications are hosted, for example, a monitor, executive, operating system, or application running directly on the hardware platform. \n\nHardware-enforced, read-only media include, CD-R/DVD-R disk drives. Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27033",
+      "title": "Applications must support organizationally-defined requirements to load and execute from hardware-enforced, read-only media.",
+      "description": "Use of non-modifiable storage ensures the integrity of the software program from the point of creation of the read-only image. Organizations may require the information system to load specified applications from hardware enforced read-only media.  Hardware-enforced, read-only media include, CD-R/DVD-R disk drives.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27034",
+      "title": "Applications must prevent unauthorized and unintended information transfer via shared system resources.",
+      "description": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27035",
+      "title": "Applications must not share resources used to interface with systems operating at different security levels.\n",
+      "description": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Shared resources include, memory, input/output queues, and network interface cards. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27036",
+      "title": "Applications must protect against or limit the effects of the organization-defined or referenced types of Denial of Service (DoS) attacks.",
+      "description": "A variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. For example, boundary protection devices can filter certain types of packets to protect devices on an organization’s internal network from being directly affected by DoS attacks. \n\nEmploying increased capacity and bandwidth combined with service redundancy may reduce the susceptibility to some DoS attacks. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27037",
+      "title": "Applications must preserve any organization-defined system state information in the event of a system failure.",
+      "description": "Failure in a known state can address safety or security in accordance with the mission/business needs of the organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. \n\nPreserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27039",
+      "title": "Applications must restrict the ability of users to launch Denial of Service (DoS) attacks against other information systems or networks.",
+      "description": "When it comes to DoS attacks most of the attention is paid to ensuring that systems and applications are not victims of these attacks.  \n\nWhile it is true that those accountable for systems want to ensure they are not affected by a DoS attack, they also need to ensure their systems and applications are not used to launch such an attack against others.  To that extent, a variety of technologies exist to limit, or in some cases, eliminate the effects of DoS attacks. \n\nFor example,  boundary protection devices can filter certain types of packets to protect devices from being directly affected by denial of service attacks. Limiting system resources that are allocated to any user to a bare minimum may also reduce the ability of users to launch some DoS attacks. \n\nApplications and application developers must take the steps needed to ensure that users cannot use these applications to launch DoS attacks against other systems and networks.  An example would be designing applications to include mechanisms that throttle network traffic so that users are not able to generate unlimited network traffic via the application. \n\nThe methods employed to counter this risk will be dependent upon the potential application layer methods that can be used to exploit it.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27040",
+      "title": "Applications must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.",
+      "description": "In the case of application DoS attacks, care must be taken when designing the application so as to ensure that the application makes the best use of system resources.  SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance.  Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.  \n\nThe methods employed to meet this requirement will vary depending upon the technology the application utilizes.  However, a variety of technologies exist to limit, or in some cases, eliminate the effects of application related DoS attacks.  Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27041",
+      "title": "Applications must limit the use of resources by priority and not impede the host from servicing processes designated as a higher-priority.",
+      "description": "Priority protection helps prevent a lower-priority process from delaying or interfering with the information system servicing any higher-priority process. This control does not apply to components in the information system for which there is only a single user/role. The application must limit the use of resources by priority.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27042",
+      "title": "Applications functioning in the capacity of a firewall must check incoming communications to ensure the communications are coming from an authorized source and routed to an authorized destination.",
+      "description": "In regards to boundary controls such as routers and firewalls, examples of restricting and prohibiting communications are: restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27043",
+      "title": "The application must be capable of implementing host-based boundary protection mechanisms for servers, workstations, and mobile devices.",
+      "description": "A host-based boundary protection mechanism is a host-based firewall. Host-based boundary protection mechanisms are employed on mobile devices, such as notebook/laptop computers, and other types of mobile devices where such boundary protection mechanisms are available. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27044",
+      "title": "The organization must isolate organization-defined key information security tools, mechanisms, and support components from other internal information system components via physically separate subnets with managed interfaces to other portions of the system.",
+      "description": "The application must isolate organization-defined key information security tools, mechanisms, and support components from other internal information system components via physically separate subnets with managed interfaces to other portions of the system.\n\nThis is a physical separation requirement and is not applicable.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27046",
+      "title": "The information system must route all networked, privileged accesses through a dedicated, managed interface for purposes of access control and auditing.",
+      "description": "Managed interfaces employing boundary protection devices include:  proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in effective security architecture (e.g., routers protecting firewalls and application gateways residing on a protected sub network commonly referred to as a demilitarized zone or DMZ).\n\nThis is a configuration requirement to route privileged access through a dedicated managed interface (e.g., firewall) and does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27047",
+      "title": "Boundary protection applications must prevent discovery of specific system components (or devices) composing a managed interface.",
+      "description": "Firewall control requirement for isolating and preventing the discovery of management interfaces. This control enhancement is intended to protect the network addresses of information system components that are part of the managed interface from discovery through common tools and techniques used to identify devices on a network.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27048",
+      "title": "Applications designed to enforce protocol formats must employ automated mechanisms to enforce strict adherence to protocol format.  ",
+      "description": "Automated mechanisms used to enforce protocol formats include, deep packet inspection firewalls and XML gateways. These devices verify adherence to the protocol specification (e.g., IEEE) at the application layer and serve to identify significant vulnerabilities that cannot be detected by devices operating at the network or transport layer.  It is impractical to expect protocol format inspection to be conducted manually.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27049",
+      "title": "Boundary protection applications must fail securely in the event of an operational failure.",
+      "description": "Fail secure is a condition achieved by the application of a set of information system mechanisms to ensure that in the event of an operational failure of a boundary protection device at a managed interface (e.g., router, firewall, guard, application gateway residing on a protected sub network commonly referred to as a demilitarized zone), the system does not enter into an unsecure state where intended security properties no longer hold. A failure of a boundary protection device cannot lead to, or cause information external to the boundary protection device to enter the device, nor can a failure permit unauthorized information release.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27050",
+      "title": "Boundary protection applications must be capable of preventing public access into the organization’s internal networks except as appropriately mediated by managed interfaces.",
+      "description": "Access into an organization's internal network and to key internal boundaries must be tightly controlled and managed. Applications monitoring and/or controlling communications at the external boundary of the system and at key internal boundaries must be capable of preventing public access into the organization’s internal networks except as appropriately mediated by managed interfaces.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27051",
+      "title": "Any software application designed to function as a firewall must be capable employing a default deny all configuration. ",
+      "description": "A firewall default deny is a firewall configuration setting that will force the administrator to explicitly allow network or application traffic rather than allowing all traffic by default.  The purpose is to prevent unmanaged access into the internal network or in the case of an application firewall, to application content, features, or functionality.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27052",
+      "title": "Applications providing remote connectivity must prevent remote devices that have established a non-remote connection with the system from communicating outside of the communications path with resources in external networks.",
+      "description": "This control enhancement is implemented within the remote device (e.g., notebook/laptop computer) via configuration settings that are not configurable by the user of that device. An example of a non-remote communications path from a remote device is a virtual private network. When a non-remote connection is established using a virtual private network, the configuration settings prevent split-tunneling. Split-tunneling might otherwise be used by remote users to communicate with the information system as an extension of that system and to communicate with local resources such as, a printer or file server. Since the remote device, when connected by a non-remote connection, becomes an extension of the information system, allowing dual communications paths such as split-tunneling would be, in effect, allowing unauthorized external connections into the system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27053",
+      "title": "Proxy applications must support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy applications must also be configurable with organization-defined lists of authorized and unauthorized websites.",
+      "description": "External networks are networks outside the control of the organization. Proxy servers support logging individual Transmission Control Protocol (TCP) sessions and blocking specific Uniform Resource Locators (URLs), domain names, and Internet Protocol (IP) addresses. Proxy servers are also configurable with organization-defined lists of authorized and unauthorized websites.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27054",
+      "title": "Applications performing extrusion detection must be capable of denying network traffic and auditing internal users (or malicious code) posing a threat to external information systems.",
+      "description": "Detecting internal actions that may pose a security threat to external information systems is sometimes termed extrusion detection. Extrusion detection at the information system boundary includes the analysis of network traffic (incoming as well as, outgoing) looking for indications of an internal threat to the security of external systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27055",
+      "title": "The information system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.",
+      "description": "Restricting external web traffic only to organizational web servers within managed interfaces and prohibiting external traffic that appears to be spoofing an internal address as the source are examples of restricting and prohibiting communications.   The same can be said for the monitoring of the traffic.\n\nThe information system must monitor and control communications at the external boundary of the information system and at key internal boundaries within the system.\n\nThis is a boundary control requirement to use firewalls and proxy servers to control communications and is not an application requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27056",
+      "title": "The information system must connect to external networks or information systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.",
+      "description": "Managed interfaces employing boundary protection devices include:  proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in an effective security architecture (e.g., routers protecting firewalls and application gateways residing on a protected sub-network commonly referred to as a demilitarized zone or DMZ).\n\nThis is a boundary control requirement to route traffic through managed firewalls and proxies deployed according to an architectural design.  This is a network configuration issue not an application requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27057",
+      "title": "Applications must protect the integrity of transmitted information.",
+      "description": "Ensuring the integrity of transmitted information requires that applications take feasible measures to employ security during data transport.  Examples include but are not limited to SSL, TLS and IPSEC, and VPN. This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. \n\nWhen it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. \n\nThis is a network requirement regarding the use of dedicated circuits and does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27058",
+      "title": "Applications must employ cryptographic mechanisms to recognize changes to information during transmission unless otherwise protected by alternative physical measures.",
+      "description": "Ensuring the integrity of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to recognize changes to information.  This is usually achieved through the use of checksums, cryptographic hash or message authentication. \n\nAlternative physical protection measures include, Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation.\n\nThis is a requirement for PDS systems to use cryptographic mechanisms and is not an application requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27059",
+      "title": "The application must maintain the integrity of information during aggregation, packaging, and transformation in preparation for transmission.",
+      "description": "Ensuring the confidentiality of transmitted information requires that applications take feasible measures to employ transmission layer security.  This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. \n\nWhen it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. \n\nWhen transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPSEC.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27060",
+      "title": "Applications must protect the confidentiality of transmitted information.",
+      "description": "Ensuring the confidentiality of transmitted information requires that applications take feasible measures to employ security mechanisms during data transmission.  Examples include but are not limited to, SSL, TLS, IPSec, and VPN.   This requirement applies to communications across internal and external networks. If the organization is relying on a commercial service provider for transmission services as a commodity item rather than a fully dedicated service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed security controls for transmission integrity. \n\nWhen it is infeasible or impractical to obtain the necessary security controls and assurances of control effectiveness through appropriate contracting vehicles, the organization either implements appropriate compensating security controls or explicitly accepts the additional risk. \n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27061",
+      "title": "The application must employ cryptographic mechanisms preventing the unauthorized disclosure of information during transmission unless the transmitted data is otherwise protected by alternative physical measures.",
+      "description": "Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission.  This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. \n\nAlternative physical protection measures include, Protected Distribution Systems (PDS). PDS are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27062",
+      "title": "Applications must maintain the confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.  When transmitting data, applications need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPSEC.  ",
+      "description": "Preventing the disclosure of transmitted information requires that applications take measures to employ some form of cryptographic mechanism in order to protect the information during transmission.  This is usually achieved through the use of Transport Layer Security (TLS), SSL VPN, or IPSEC tunnel. \n\nAlternative physical protection measures include, protected distribution systems. Protective Distribution Systems (PDS) are used to transmit unencrypted classified NSI through an area of lesser classification or control. In as much as the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic and physical safeguards to deter exploitation. Refer to NSTSSI No. 7003 for additional details on a PDS.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27063",
+      "title": "The application must check the validity of data inputs.",
+      "description": "Invalid user input occurs when a user inserts data or characters into an applications data entry fields and the application is unprepared to process that data.  This results in unanticipated application behavior potentially leading to an application or information system compromise.  Invalid user input is one of the primary methods employed when attempting to compromise an application.  \n\nAll applications need to validate the data users attempt to input to the application for processing. Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, acceptable values) are in place to verify that inputs match specified definitions for format and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally interpreted as commands.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27064",
+      "title": "The application must identify potentially security-relevant error conditions.",
+      "description": "The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27065",
+      "title": "The application must only generate error messages that provide information necessary for corrective actions without revealing organization-defined sensitive or potentially harmful information in error logs and administrative messages that could be exploited. ",
+      "description": "Any application providing too much information in error logs and in administrative messages to the screen risks compromising the data and security of the application and system. The structure and content of error messages needs to be carefully considered by the organization and development team. \n\nThe extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements.  Sensitive information includes, account numbers, social security numbers, and credit card numbers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27066",
+      "title": "The application must restrict error messages so only authorized personnel may view them.",
+      "description": "If the application provides too much information in error logs and administrative messages to the screen, this could lead to compromise.  The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27067",
+      "title": "Applications must support the requirement to activate an alarm and/or automatically shut down the information system if an application component failure is detected.  This can include conducting a graceful application shutdown to avoid losing information.",
+      "description": "Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining systems security fail to function, the system could continue operating in an insecure state. The organization must be prepared and the application must support requirements that specify if the application must alarm for such conditions and/or automatically shut down the application or the system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27068",
+      "title": "Applications providing patch management capabilities must support the organizational requirements to install software updates automatically.",
+      "description": "Security faults with software applications and operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, must also be  addressed expeditiously. \n\nAnytime new software code is introduced to a system there is the potential for unintended consequences. There have been documented instances where the application of a patch has caused problems with system integrity or availability.  Due to information system integrity and availability concerns, organizations must give careful consideration to the methodology used to carry out automatic updates. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27069",
+      "title": "Applications serving to determine the state of information system components with regard to flaw remediation (patching) must use automated mechanisms to make that determination.  The automation schedule must be determined on an organization-defined basis and any solution utilized must support the scheduling requirement.",
+      "description": "Organizations are required to identify information systems containing software affected by recently announced software flaws (and potential vulnerabilities resulting from those flaws) and report this information to designated organizational officials with information security responsibilities (e.g., senior information security officers, information system security managers, information systems security officers). To support this requirement, an automated process or mechanism is required.  \n\nThis role is usually assigned to patch management software that is deployed in order to track the number of systems installed in the network, as well as, the types of software installed on these systems, the corresponding versions, and the related flaws that require patching. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27070",
+      "title": "The application must support organizational requirements to employ automated patch management tools to facilitate flaw remediation to organization-defined information system components.  Patch management tools must be automated.",
+      "description": "The organization (including any contractor to the organization) shall promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling, shall also be  addressed expeditiously. Due to information system integrity and availability concerns, organizations shall give careful consideration to the methodology used to carry out automatic updates. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27071",
+      "title": "The application must automatically update malicious code protection mechanisms, including signature definitions. Examples include anti-virus signatures and malware data files employed to identify and/or block malicious software from executing.",
+      "description": "Anti-virus and malicious software detection applications utilize signature definitions in order to identify viruses and other malicious software.  These signature definitions need to be constantly updated in order to identify the new threats that are discovered every day.  All anti-virus and malware software shall come with an update mechanism that automatically updates these signatures. The organization (including any contractor to the organization) is required to promptly install security-relevant malicious code protection software updates (e.g., anti-virus signature updates and hot fixes). Malicious code includes, viruses, worms, Trojan horses, and Spyware. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27072",
+      "title": "The application must prevent non-privileged users from circumventing malicious code protection capabilities. ",
+      "description": "Malicious code protection software must be protected so as to prevent a non-privileged user or malicious piece of software from disabling the protection mechanism. A common tactic of malware is to identify the type of malicious code protection software running on the system and deactivate it. Malicious code includes, viruses, worms, Trojan horses, and Spyware. \n\nExamples include the capability for non-administrative user's to turn off or otherwise disable anti-virus.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27073",
+      "title": "Applications must provide the capability to centralize the review and analysis of audit records from multiple components within the system.",
+      "description": "Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. \n\nSegregation of logging data to multiple disparate computer systems is counter-productive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27075",
+      "title": "Malicious code protection applications must update malicious code protection mechanisms only when directed by a privileged user.",
+      "description": "Malicious code protection software must be protected to prevent a non-privileged user or malicious piece of software from manipulating the protection update mechanism. \n\nMalicious code includes, viruses, worms, Trojan horses, and Spyware. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27077",
+      "title": "Applications must support organizational requirements restricting users from introducing removable media into the information system. ",
+      "description": "Malicious code is known to propagate via removable media such as, floppy disks, USB or flash drives, and removable hard drives.  \n\nIn order to prevent propagation and potential infection due to malware contained on removable media, the information system must be able to restrict and/or limit the use of removable media. Applications must not be designed so as to circumvent or otherwise disable this protection requirement. \n\nThis is a requirement to restrict users from inserting removable media into a system.  This is not an application requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27078",
+      "title": "The organization must employ malicious code protection mechanisms at information system entry and exit points to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means. ",
+      "description": "In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves via information system entry and exit points. \n\nInformation system entry and exit points include:  firewalls, electronic mail servers, web servers, proxy servers, and remote-access servers. Malicious code includes viruses, worms, Trojan horses, and Spyware. \n\nThe requirement states that anti-virus and malware protection applications must be used at entry and exit points. This does not apply to applications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27079",
+      "title": "The organization must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.",
+      "description": "In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and Spyware. \n\nApplications providing malicious code protection must support organizational requirements to employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and eradicate malicious code transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.  \n\nThe requirement states that malicious code protection mechanisms such as anti-virus must be used on workstations, servers and mobile computing devices.  This does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27082",
+      "title": "Applications providing malicious code protection must support organizational requirements to update malicious code protection mechanisms (including signature definitions) whenever new releases are available in accordance with organizational configuration management policy and procedures.",
+      "description": "Malicious code protection mechanisms include, but are not limited to, anti-virus and malware detection software. In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes, viruses, worms, Trojan horses, and Spyware. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27084",
+      "title": "Applications scanning for malicious code must support organizational requirements to configure malicious code protection mechanisms to perform periodic scans of the information system on an organization-defined frequency.",
+      "description": "Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes, viruses, worms, Trojan horses, and Spyware. It is not enough to simply have the software installed.  This software must periodically scan the system to search for malware on an organization defined frequency. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27085",
+      "title": "The application must provide an audit reduction capability.",
+      "description": "Audit reduction is used to reduce the volume of audit records in order to facilitate manual review.  Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. \n\nThis is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. Audit reduction does not alter original audit records. \n\nAn audit reduction capability provides support for near real-time audit review and analysis requirements and after-the-fact investigations of security incidents. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27086",
+      "title": "Applications providing malicious code protection must support organizational requirements to configure malicious code protection mechanisms to perform real-time scans of files from external sources as the files are downloaded, opened, or executed in accordance with organizational security policy.",
+      "description": "Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nMalicious code includes, viruses, worms, Trojan horses, and Spyware. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27087",
+      "title": "Applications providing malicious code protection must support organizational requirements to be configured to perform organization-defined action(s) in response to malicious code detection.",
+      "description": "Malicious code protection mechanisms include but are not limited to anti-virus and malware detection software. In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. \n\nApplications providing this capability must be able to perform actions in response to detected malware.  Responses include, but are not limited to, quarantine, deletion, and alerting.\n\nMalicious code includes, viruses, worms, Trojan horses, and Spyware. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27088",
+      "title": "Applications providing malicious code protection must support organizational requirements to address the receipt of false positives during malicious code detection, eradication efforts, and the resulting potential impact on the availability of the information system. ",
+      "description": "In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes, viruses, worms, Trojan horses, and Spyware.  Applications providing this capability must have an ability to address the issue of false alerts.  False alerts can overwhelm reporting and administrative interfaces making it difficult to identify the true threat.  A filtering capability that serves to identify and remove false positives is often employed to address this issue.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27089",
+      "title": "Applications must provide a report generation capability for audit reduction data.",
+      "description": "In support of Audit Review, Analysis, and Reporting requirements,  audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review.  \n\nBefore a security review is conducted, information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance.  This is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. \n\nIn order to identify and report on what (repetitive) data has been removed via the use of audit reduction, the application must provide a capability to generate reports containing what values were removed by the audit reduction. \n\nAudit reduction does not alter original audit records.  An audit reduction capability provides support for near real-time audit review and analysis based on policy based requirements and after-the-fact investigations of security incidents. \n\nReporting tools employing audit reduction methods must not alter the original audit data.  An example of a tool employing audit reduction methods is the Windows Event Viewer tool which is used to view and analyze audit logs on Windows systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27090",
+      "title": "Intrusion detection software must be able to interconnect using standard protocols to create a system wide intrusion detection system.",
+      "description": "When utilizing intrusion detection software, monitoring components are usually dispersed throughout the network, such as, when utilizing HIDS and multiple NIDS sensors.  In order to leverage the capabilities of intrusion detection systems to get a complete overall view of network and host activity, these separate components must be able to report and react to activity they detect. \n\nNon-standard or custom communication protocols do not provide the reliability and veracity required of an enterprise class intrusion detection system. An example of a custom protocol includes, but is not limited to, vendor specific communication protocols that have not undergone IETF RFC evaluation and/or are not in common use throughout the Internet as a whole.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27092",
+      "title": "For those instances where the organization requires encrypted traffic to be visible to information system monitoring tools, the application transmitting the encrypted traffic must make provisions to allow that traffic to be visible to specific system monitoring tools.",
+      "description": "There is a recognized need to balance encrypting traffic versus the need to have insight into the traffic from a monitoring perspective. \n\nFor some organizations, the need to ensure the confidentiality of traffic is paramount; for others, the mission-assurance concerns are greater. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27093",
+      "title": "The organization must analyze outbound communications traffic at the external boundary of the system (i.e., system perimeter).",
+      "description": "Anomalies within the information system include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses.  \n\nThis is a requirement to analyze outbound traffic.  This does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27094",
+      "title": "The organization must analyze outbound communications traffic at selected interior points within the system (e.g., subnets, subsystems), as deemed necessary, to discover anomalies. ",
+      "description": "Anomalies within the information system include, for example, large file transfers, long-time persistent connections, unusual protocols and ports in use, and attempted communications with suspected malicious external addresses.   \n\nThis is a requirement to analyze outbound traffic at selected interior points.  This does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27095",
+      "title": "The organization must employ a wireless intrusion detection system to detect attack attempts to the information system.\n",
+      "description": "Wireless intrusion detection monitors wireless network traffic for known attack patterns and notifies IA staff members when possible attacks are detected.\n\nThis is a network monitoring traffic analysis requirement to deploy wireless IDS. This does not apply to applications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27096",
+      "title": "The organization must employ a wireless Intrusion Detection System (IDS) to detect potential compromises/breaches to the information system.\n\n",
+      "description": "Wireless IDS is used to detect and alarm on known attack patterns.\n\nThis is a requirement to deploy wireless IDS network monitoring. This does not apply to applications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27097",
+      "title": "Applications providing malware and/or firewall protection must monitor inbound and outbound communications for unauthorized activities or conditions.",
+      "description": "Unusual/unauthorized activities or conditions include internal traffic indicating the presence of malicious code within an information system or propagating among system components, the unauthorized export of information, or signaling to an external information system. \n\nEvidence of malicious code is used to identify potentially compromised information systems or information system components. \n\nExamples of applications that provide monitoring capability for unusual/unauthorized activities include, but are not limited to, Intrusion Detection, Anti-Virus and Malware etc.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27101",
+      "title": "Applications that detect and alarm on security events such as Intrusion Detection, Firewalls, Anti-Virus, or Malware must provide near real-time alert notification.  ",
+      "description": "When an intrusion detection security event occurs it is imperative the application that has detected the event immediately notify the appropriate support personnel so they can respond accordingly.  \n\nLack of this capability increases the risk that attacks will go unnoticed or responses will be delayed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27102",
+      "title": "Applications providing IDS and prevention capabilities must prevent non-privileged users from circumventing intrusion detection and prevention capabilities.",
+      "description": "Any application providing intrusion detection and prevention capabilities must be architected and implemented so as to prevent non-privileged users from circumventing such protections. This can be accomplished through the use of user roles, use of proper systems permissions, auditing, logging, etc.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27103",
+      "title": "Applications providing notifications regarding suspicious events must include the capability to notify an organization-defined list of response personnel who are identified by name and/or by role.",
+      "description": "Incident response applications are by their nature designed to monitor, detect, and alarm on defined events occurring on the system or on the network.  A large part of their functionality is accurate and timely notification of events.  Notifications can be made more efficient by the creation of notification groups containing members who would be responding to a particular alarm or event.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27105",
+      "title": "The application must support taking organization-defined list of least-disruptive actions to terminate suspicious events. ",
+      "description": "System availability is a key tenet of system security. Organizations need to have the flexibility to be able to define the automated actions taken in response to an identified incident. This includes being able to define a least disruptive action that the application takes to terminate suspicious events.  A least disruptive action may include initiating a request for human response rather than blocking traffic or disrupting system operation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27107",
+      "title": "The application must enforce organizational requirements to protect information obtained from intrusion monitoring tools from unauthorized access, modification, and deletion.",
+      "description": "Intrusion monitoring applications are by their nature designed to monitor and record network and system traffic and activity.  They can accumulate a significant amount of sensitive data, examples of which could include user account information and application data not related to the intrusion monitoring application itself. \n\nIntrusion monitoring tools also obtain information that is critical to conducting forensic analysis on attacks occurring within the network.  This data may be sensitive in nature. Information obtained by intrusion monitoring applications in the course of evaluating network and system security needs to be protected. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27114",
+      "title": "The application must terminate all sessions and network connections when non-local maintenance is completed.",
+      "description": "Non-local 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 act of managing systems and applications includes the ability to access sensitive application information such as system configuration details, diagnostic information, user information and potentially sensitive application data. \n\nWhen applications provide a remote management capability that is inherent to the application, the application needs to ensure all sessions and network connections are terminated when non-local maintenance is completed. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27116",
+      "title": "The application must either implement compensating security controls or the organization explicitly accepts the risk of not performing the verification as required. ",
+      "description": "Application security functional testing involves testing the application for conformance to the applications security function specifications, as well as, for the underlying security model. The need to verify security functionality applies to all security functions. The conformance criteria state the conditions necessary for the application to exhibit the desired security behavior or satisfy a security property for example, successful login triggers an audit entry. \n\nOrganizations may define conditions requiring verification and the frequency in which such testing occurs. Security function testing usually occurs during the development phase and can in some instances occur in the production phase if the developer provides the security conformance criteria or if the conformance criteria can be established.  There are application testing frameworks available that can perform functional testing on production systems however they are limited in their applicability and are language or product centric. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27117",
+      "title": "Applications must respond to security function anomalies in accordance with organization-defined responses and alternative action(s).",
+      "description": "The need to verify security functionality applies to all security functions. \n\nFor those security functions not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include, startup, restart, shutdown, and abort.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27118",
+      "title": "Applications employed to write data to portable digital media must use cryptographic mechanisms to protect and restrict access to information on portable digital media. ",
+      "description": "When data is written to portable digital media such as thumb drives, floppy diskettes, compact disks, magnetic tape, etc., there is risk of data loss. \n\nAn organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. \n\nOrganizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. Fewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. \n\nIn these situations, it is assumed the physical access controls where the media resides provide adequate protection. The employment of cryptography is at the discretion of the information owner/steward. \n\nThe selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. \n\nThe strength of mechanisms is commensurate with the classification and sensitivity of the information. \n\nWhen the organization has determined the risk warrants it, data written to portable digital media must be encrypted.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27120",
+      "title": "Applications must support organizational requirements to employ cryptographic mechanisms to protect information in storage.",
+      "description": "When data is written to digital media such as, hard drives, mobile computers, external/removable hard drives, personal digital assistants, flash/thumb drives, etc., there is risk of data loss and data compromise. \n\nAn organizational assessment of risk guides the selection of media and associated information contained on that media requiring restricted access. Organizations need to document in policy and procedures, the media requiring restricted access, individuals authorized to access the media, and the specific measures taken to restrict access. \n\nFewer protection measures are needed for media containing information determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed the physical access controls where the media resides provide adequate protection. \n\nAs part of a defense-in-depth strategy, the organization considers routinely encrypting information at rest on selected secondary storage devices. The employment of cryptography is at the discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based upon maintaining the confidentiality and integrity of the information. \n\nThe strength of mechanisms is commensurate with the classification and sensitivity of the information.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27121",
+      "title": "Applications must provide notification of failed automated security tests.",
+      "description": "The need to verify security functionality applies to all security functions. \n\nFor those security functions not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include, startup, restart, shutdown, and abort.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27125",
+      "title": "Application software used to detect the presence of unauthorized software must employ automated detection mechanisms and notify designated organizational officials in accordance with the organization-defined frequency.",
+      "description": "Scanning software is purpose built to check for vulnerabilities in the information system and hosted applications and is also used to enumerate platforms, software flaws, and improper configurations.  \n\nOrganizations are required to scan for vulnerabilities in information systems and hosted applications on an organization defined frequency and/or randomly in accordance with an organization defined process. \n\nScanning software includes the capability to scan for specific functions, applications, ports, protocols, and services that should not be accessible to users or devices and for improperly configured or incorrectly operating information flow mechanisms.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27127",
+      "title": "The organization (or information system) must enforce explicit rules governing the installation of software by users.",
+      "description": "If provided the privilege, information system users have the ability to install software. This can create security related issues if the users install unapproved or insecurely written software. \n\nThe organization shall identify what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect).  \n\nThis is an OS requirement and does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27128",
+      "title": "The application must terminate the network connection associated with a communications session at the end of the session or after an organization-defined time period of inactivity.",
+      "description": "This requirement applies to both internal and external networks. \n\nTerminating network connections associated with communications sessions include, de-allocating associated TCP/IP address/port pairs at the operating-system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. \n\nThe time period of inactivity may, as the organization deems necessary, be a set of time periods by type of network access or for specific accesses. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27130",
+      "title": "The application must establish a trusted communications path between the user and organization-defined security functions within the information system.",
+      "description": "The application user interface must provide an unspoofable and faithful communication channel between the user and any entity trusted to manipulate authorities on the user's behalf. \n\nA trusted path shall be employed for high-confidence connections between the security functions of the information system and the user (e.g., for login). ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27131",
+      "title": "Applications involved in the production, control, and distribution of  symmetric cryptographic keys must use NIST-approved or NSA-approved key management technology and processes.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nIn addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27132",
+      "title": "Applications involved in the production, control, and distribution of  symmetric and asymmetric cryptographic keys must use NIST-approved or NSA-approved key management technology and processes.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nIn addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27134",
+      "title": "Applications involved in the production, control, and distribution of  asymmetric cryptographic keys must use must use approved PKI Class 3 certificates or prepositioned keying material.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nIn addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27135",
+      "title": "Applications must provide automated support for the management of distributed security testing.",
+      "description": "The need to verify security functionality applies to all security functions. \n\nFor those security functions that are not able to execute automated self-tests the organization either implements compensating security controls or explicitly accepts the risk of not performing the verification as required. Information system transitional states include:  startup, restart, shutdown, and abort.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27136",
+      "title": "Applications involved in the production, control, and distribution of asymmetric cryptographic keys must use approved PKI Class 3 or class 4 certificates and hardware tokens that protect the users private key.",
+      "description": "Cryptographic key management and establishment can be performed using manual procedures or automated mechanisms with supporting manual procedures. \n\nIn addition to being required for the effective operation of a cryptographic mechanism, effective cryptographic key management provides protections to maintain the availability of the information in the event of the loss of cryptographic keys by users. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27137",
+      "title": "Applications utilized for integrity verification must detect unauthorized changes to software and information.",
+      "description": "Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27139",
+      "title": "Applications that are utilized to address the issue of SPAM and provide protection from SPAM must automatically update any and all SPAM protection measures including signature definitions.",
+      "description": "Originators of SPAM emails are constantly changing their source email addresses in order to defeat SPAM countermeasures; therefore, SPAM software must be constantly updated to address the changing threat.  A manual update procedure is labor intensive and does not scale well in an enterprise environment which necessitates an automatic update capability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27140",
+      "title": "The application must implement required cryptographic protections using cryptographic modules complying with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. \n\nUse of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27141",
+      "title": "The organization must employ malicious code protection mechanisms at information system entry and exit points to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, web accesses, removable media, or other common means.",
+      "description": "Unsolicited email messages otherwise known as SPAM are known to be one of the primary vectors for the propagation of many types of attacks including phishing attacks.  SPAM and malware protection techniques include examining email messages, files, and web traffic at border gateways or proxies to determine if the traffic contains SPAM or some other type of malware.\n\nThis is a requirement to deploy SPAM protection at certain locations on the network.  This requirement does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27143",
+      "title": "The organization must employ malicious code protection mechanisms at workstations, servers, or mobile computing devices on the network to detect and take action on unsolicited messages transported by electronic mail, electronic mail attachments, and web accesses.\n",
+      "description": "Senders of SPAM messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify SPAM messages, it is critical that SPAM protection mechanisms are kept current.\n\nUnsolicited email messages otherwise known as SPAM are known to be one of the primary vectors for the propagation of many types of attacks including phishing attacks. SPAM and malware protection techniques include examining email messages, files, and web traffic at border gateways or proxies to determine if the traffic contains SPAM or some other type of malware.\n\nThis is a requirement to utilize SPAM prevention and anti-virus/malware software on workstations, servers, and laptops. This requirement does not apply to applications. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27144",
+      "title": "Applications that serve to protect organizations and individuals from SPAM messages must incorporate update mechanisms updating protection mechanisms and signature updates when new application releases are available in accordance with organizational configuration management policy and procedures.",
+      "description": "Senders of SPAM messages are continually modifying their tactics and source email addresses in order to elude protection mechanisms. To stay up-to-date with the changing threat and to identify SPAM messages, it is critical that SPAM protection mechanisms are kept current.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27145",
+      "title": "Applications must provide the capability to automatically process audit records for events of interest based upon selectable, event criteria.",
+      "description": "Audit reduction is used to reduce the volume of audit records in order to facilitate manual review.  Before a security review information systems and/or applications with an audit reduction capability may remove many audit records known to have little security significance. \n\nThis is generally accomplished by removing records generated by specified classes of events, such as records generated by nightly backups. \n\nAn audit reduction capability provides support for near real-time audit review and analysis based on policy requirements regarding what must be audited on the system and after-the-fact investigations of security incidents.  It is important to recognize audit reduction does not alter original audit records.  \n\nAudit reduction and reporting tools do not alter original audit records. \n\nTo leverage the complete capability of audit reduction, the application must possess the ability to specify and automatically process certain event criteria that are selectable in nature.  In other words, a system administrator (SA) may be performing a manual review of audit data to identify a particular problem. The SA has determined that backup activity and network connections from a particular host comprise the bulk of the events.  However, these events are not related to the activity being investigated.  The application must be able to automatically process these audit records for audit reduction purposes rather than making the administrator manually process them.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27146",
+      "title": "Applications must use internal system clocks to generate time stamps for audit records.",
+      "description": "Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. \n\nTime stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27147",
+      "title": "The application must synchronize with internal information system clocks which in turn, are synchronized on an organization-defined frequency with an organization-defined authoritative time source. ",
+      "description": "Determining the correct time a particular application event occurred on a system is critical when conducting forensic analysis and investigating system events.  \n\nSynchronization of system clocks is needed in order to correctly correlate the timing of events that occur across multiple systems. To meet that requirement the organization will define an authoritative time source and frequency to which each system will synchronize its internal clock.  \n\nAn example is utilizing the NTP protocol to synchronize with centralized NTP servers. Time stamps generated by the information system shall include both date and time. The time may be expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. \n\nApplications not purposed to provide NTP services should not try to compete with or replace NTP functionality and should synchronize with internal information system clocks that are in turn synchronized with an organization defined authoritative time source.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27148",
+      "title": "The application must protect audit information from any type of unauthorized access. ",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve.   In addition, access to audit records provides information an attacker could potentially use to his or her advantage.\n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from any and all unauthorized access.  This includes read, write, copy, etc.\n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design.  Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. \n\nAdditionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application.  If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27150",
+      "title": "Applications must employ FIPS-validated cryptography to protect unclassified information.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. \n\nUse of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27152",
+      "title": "The application must protect audit information from unauthorized modification.",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification.  \n\nThis requirement can be achieved through multiple methods which will depend upon system architecture and design.  Some commonly employed methods include ensuring log files enjoy the proper file system permissions, and limiting log data locations.  \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27153",
+      "title": "Applications must employ NSA-approved cryptography to protect classified information.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. \n\nNSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as:\n\n“Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed.\nDeveloped using established NSA business processes and containing NSA approved algorithms\nare used to protect systems requiring the most stringent protection mechanisms.”\n\nNSA-approved cryptography is required to be used for classified information system processing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27154",
+      "title": "Applications must employ FIPS-validated cryptography to protect unclassified information when such information must be separated from individuals who have the necessary clearances yet lack the necessary access approvals.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data.  FIPS 140-2 Security Requirements for Cryptographic Modules can be found at the following web site: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf.\n\nAlthough persons may have a security clearance, they may not have a \"need to know\" and are required to be separated from the information in question.  Applications must employ FIPS validated cryptography to protect unclassified information from those individuals who have no \"need to know\".\n\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27155",
+      "title": "Applications must employ FIPS-validated or NSA-approved cryptography to implement digital signatures.",
+      "description": "Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or un-tested encryption algorithms undermines the purposes of utilizing encryption to protect data. \n\nThe integrity and reliability of the algorithms used to generate digital signatures is just as important as those used to encrypt data.  \n\nDigital signatures provide non-repudiation and authenticity of a message or document, therefore, it is imperative that applications employ FIPS validated algorithms when generating digital signatures to be applied to unclassified data and NSA approved algorithms when generating signatures to be applied to classified data.\n\nThis application requirement is not applicable.  This requirement is addressed by CCI-001342 which requires applications to meet policy and legal requirements regarding the use of approved encryption technology.  CCI-001342 is a comprehensive cryptography requirement that mandates the use of FIPS-validation or NSA-approved cryptography when using digital signatures.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27159",
+      "title": "The application must protect the integrity and availability of publicly available information and applications.",
+      "description": "The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications with such protection likely being implemented as part of other security controls. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27160",
+      "title": "The application must protect audit information from unauthorized deletion.",
+      "description": "If audit data were to become compromised then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized deletion.  This requirement can be achieved through multiple methods which will depend upon system architecture and design.  \n\nSome commonly employed methods include:  ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access and backing up log data to ensure log data is retained.  \n\nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.\n\nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27162",
+      "title": "The information system or supporting environment must block both inbound and outbound traffic between instant messaging clients that are independently configured by end users and external service providers.",
+      "description": "Blocking restrictions do not include instant messaging services configured by an organization to perform an authorized function. \n\nThis requirement specifies blocking any external IRC chat clients that are not configured and managed by the organization.  This requirement does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27163",
+      "title": "The application must protect audit tools from unauthorized access.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. \n\nIt is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access.  \n\nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.\n\nAudit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27164",
+      "title": "The application must protect audit tools from unauthorized modification.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.  \n\nIf the tools are compromised it could provide attackers with the capability to manipulate log data. It is, therefore, imperative that audit tools be controlled and protected from unauthorized modification. \n\nAudit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27165",
+      "title": "The application must protect audit tools from unauthorized deletion.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n\nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data.  If the tools are deleted, it would affect the administrator’s ability to access and review log data.  \n\nAudit tools include but are not limited to OS provided audit tools, vendor provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27166",
+      "title": "The application must have the capability to produce audit records on hardware-enforced, write-once media.",
+      "description": "Applications are typically designed to incorporate their audit logs into the auditing sub-system hosted by the operating system.  However, in some instances application developers may decide to forego the audit capabilities offered by the operating system and maintain application audit logs separately.  \n\nThe protection of audit records from unauthorized or accidental deletion or modification requires that information systems be able to produce audit records on hardware enforced write-once media.  \n\nApplications that do not write audit records to a resource (e.g., underlying OS or separate system) that is capable of producing audit records on hardware enforced, write-once media must provide the capability to do so.  This requirement is related to backup of records and not real-time creation of audit records.\n\nExamples of such hardware devices include, but are not limited to: CD-R or DVD-R.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27168",
+      "title": "The application must support the requirement to back up audit data and records onto a different system or media than the system being audited on an organization-defined frequency.",
+      "description": "Protection of log data includes assuring log data is not accidentally lost or deleted.  Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27169",
+      "title": "Software and/or firmware used for collaborative computing devices must prohibit remote activation excluding the organization-defined exceptions where remote activation is to be allowed.",
+      "description": "Collaborative computing devices include, networked white boards, cameras, and microphones. Collaborative software examples include instant messaging or chat clients. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27170",
+      "title": "The application must associate security attributes with information exchanged between information systems.",
+      "description": "When data is exchanged between information systems, the security attributes associated with said data needs to be maintained.  \n\nSecurity attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nSecurity attributes may be explicitly or implicitly associated with the information contained within the information system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27171",
+      "title": "The application must validate the integrity of security attributes exchanged between systems.",
+      "description": "When data is exchanged between information systems, the security attributes associated with said data needs to be maintained.  \n\nSecurity attributes are an abstraction representing the basic properties or characteristics of an entity with respect to safeguarding information, typically associated with internal data structures (e.g., records, buffers, files) within the information system and used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. \n\nSecurity attributes may be explicitly or implicitly associated with the information contained within the information system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27172",
+      "title": "Applications must support organizational requirements to issue public key certificates under an appropriate certificate policy or obtain public key certificates under an appropriate certificate policy from an approved service provider.",
+      "description": "For user certificates, each organization attains certificates from an approved, shared service provider, as required by OMB policy. \n\nFor federal agencies operating a legacy public key infrastructure cross-certified with the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will suffice. \n\nThis control focuses on certificates with a visibility external to the information system and does not include certificates related to internal system operations, for example, application-specific time services. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27173",
+      "title": "Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must implement detection and inspection mechanisms to identify unauthorized mobile code",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. \n\nPolicy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27174",
+      "title": "Applications designed to address malware issues and/or enforce policy pertaining to organizational use of mobile code must take corrective actions, when unauthorized mobile code is identified.",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. \n\nPolicy and procedures related to mobile code, address preventing the development, acquisition, or introduction of unacceptable mobile code within the information system. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27175",
+      "title": "Applications utilizing mobile code must meet policy requirements regarding the acquisition, development, and/or use of mobile code.  ",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. \n\nDoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27176",
+      "title": "Applications designed to enforce policy pertaining to organizational use of mobile code must prevent the download and execution of prohibited mobile code.",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27177",
+      "title": "Applications designed to enforce policy pertaining to the use of mobile code must prevent the automatic execution of mobile code in organization-defined software applications and require organization-defined actions prior to executing the code.",
+      "description": "Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. \n\nUsage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations.  \n\nOrganization-defined software may be a specific application, web site or web sites in general. Organization-defined actions include but are not limited to:  alerts to the user, logging actions, a centralized alarm, or any combination thereof.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27178",
+      "title": "The application must separate user functionality (including user interface services) from information system management functionality.",
+      "description": "Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. \n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods, as appropriate. \n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. \n\nThis may include isolating the administrative interface on a different domain and with additional access controls. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27179",
+      "title": "The application must prevent the presentation of information system management-related functionality at an interface utilized by general (i.e., non-privileged) users.",
+      "description": "Information system management functionality includes, functions necessary to administer databases, network components, workstations, or servers, and typically requires privileged user access. \n\nThe separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, combinations of these methods, or other methods as appropriate. \n\nAn example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different domain and with additional access controls. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27180",
+      "title": "The application must provide additional data origin and integrity artifacts along with the authoritative data the system returns in response to name/address resolution queries.",
+      "description": "This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service. \n\nA Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. \n\nInformation systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27181",
+      "title": "Applications, when operating as part of a distributed, hierarchical namespace, must provide the means to indicate the security status of child subspaces and (if the child supports secure resolution services) enable verification of a chain of trust among parent and child domains.",
+      "description": "This control enables remote clients to obtain origin authentication and integrity verification assurances for the host/service name to network address resolution information obtained through the service.\n\n A Domain Name System (DNS) server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. \n\nInformation systems using technologies other than the DNS to map between host/service names and network addresses provide other means to assure the authenticity and integrity of response data. The DNS security controls are consistent with, and referenced from, OMB Memorandum 08-23. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-27182",
+      "title": "The application must perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources when requested by client systems.",
+      "description": "A recursive resolving or caching Domain Name System (DNS) server is an example of an information system providing name/address resolution service for local clients. \n\nAuthoritative DNS servers are examples of authoritative sources. Information systems using technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity and integrity of response data. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-29188",
+      "title": "Applications handling data requiring \"data at rest\" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information that is at rest unless otherwise protected by alternative physical measures.",
+      "description": "This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information.  Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system.  Alternative physical protection measures include, protected distribution systems.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-29189",
+      "title": "Applications must isolate security functions enforcing access and information flow control from both non-security functions and from other security functions.",
+      "description": "Application functionality is typically broken down into modules that perform various tasks or roles.  Examples of non-privileged application functionality include, but are not limited to, application modules written for displaying data or printing reports. \n\nApplication security functionality that performs security tasks such as enforcing access and information flow control requires additional system privilege and can have a large impact on the security of the application and its data.  Rather than allowing the entire application access to this security functionality, application developers must isolate these critical functions from non-privileged application functions and other security functions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30532",
+      "title": "The information system must protect wireless access to the system using encryption.",
+      "description": "Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x, and Bluetooth. \n\nWireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines and control of organization-controlled facilities.\n\nWhen systems connect to a wireless access point there is a requirement to authenticate.  Authentication applies to user, device, or both as necessary. Authentication data needs to be protected by encryption. \n\nThis is a wireless access requirement regarding WAP encryption. This requirement does not apply to applications.\n",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30533",
+      "title": "The information system must protect wireless access to the system using authentication.",
+      "description": "Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x, and Bluetooth. \n\nWireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines and control of organization-controlled facilities.\n\nWhen systems connect to a wireless access point they need to be authenticated by the WAP. Authentication applies to user, device, or both as necessary. \n\nThis is a wireless access requirement regarding WAP authentication. This requirement does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30570",
+      "title": "The application must enforce requirements for remote connections to the information system.",
+      "description": "Applications that provide remote access to information systems must be able to enforce remote access policy requirements or work in conjunction with enterprise tools designed to enforce policy requirements.  Examples of policy requirements include but are not limited to; authorizing remote access to the information system, limiting access based on authentication credentials and monitoring for unauthorized access. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30571",
+      "title": "Applications must enforce requirements regarding the connection of mobile devices to organizational information systems.",
+      "description": "Applications designed to manage the connection of mobile devices to information systems must be able to enforce organizational connectivity requirements or work in conjunction with enterprise tools designed to enforce policy requirements.  \n\nMobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and portable computing and communications devices with information storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices).\n\nOrganizational connectivity requirements may include usage restrictions and implementation guidance related to mobile devices.  \n\nFor example, the organization may require the device be part of the configuration management environment or may require mandatory protective software be installed prior to connecting to the infrastructure (e.g., malicious code detection or a firewall).  \n\nScanning devices for malicious code may be required prior to connecting as well as updating virus protection software, scanning for critical software updates and patches, conducting primary operating system (and possibly other resident software) integrity checks, and disabling unnecessary hardware (e.g., wireless, infrared).\n\nAn example of information system functionality that may need to be disabled prior to connecting includes the capability for automatic execution of code such as AutoRun and AutoPlay.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30572",
+      "title": "The application must disable network access by unauthorized components/devices or notify designated organizational officials.",
+      "description": "Maintaining system and network integrity requires all systems on the network are identified and accounted for.  Without an accurate accounting of systems utilizing the network, the opportunity exists for the introduction of rogue systems.  The significance of this manner of security compromise increases exponentially over time and could become a persistent threat.  Therefore, organizations must employ automated mechanisms to detect the addition unauthorized devices. \n\nInformation deemed to be necessary by the organization to achieve effective property accountability can include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical location), software license information, information system/component owner, and for a networked component/device, the machine name and network address. \n\nThe monitoring for unauthorized components/devices on information system networks may be accomplished on an ongoing basis or by the periodic scanning of organizational networks for that purpose. Automated mechanisms can be implemented within the information system and/or in another separate information system or device.\n\nApplications that are designed as systems configuration management solutions or other solutions developed specifically to fill the role of identifying or managing systems in the enterprise must be able to either disable the identified device or notify the appropriate personnel when new systems have been introduced into the environment.  ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30573",
+      "title": "The organization must protect against unauthorized physical connections across the boundary protections implemented at an organization-defined list of managed interfaces.",
+      "description": "This is a requirement to protect against physically by-passing the firewall interfaces by moving ethernet cables.  This does not apply to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30574",
+      "title": "The information system must automatically terminate emergency accounts after an organization-defined time period for each type of account.",
+      "description": "Emergency application accounts are typically created due to an unforeseen operational event or could ostensibly be used in the event of a vendor support visit where a support representative requires a temporary unique account in order to perform diagnostic testing or conduct some other support related activity. When these types of accounts are created, there is a risk that the temporary account may remain in place and active after the support representative has left.  \n\nIn the event emergency application accounts are required, the application must ensure that accounts designated as temporary in nature shall automatically terminate these accounts after an organization-defined time period.  Such a process and capability greatly reduces the risk that accounts will be misused, hijacked, or application data compromised. \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements.  Such an integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP.\n\nThe application must provide or utilize a mechanism to automatically terminate accounts that have been designated as temporary or emergency accounts after an organization defined time period.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30575",
+      "title": "The application must notify appropriate individuals when accounts are created.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. \n\nNotification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.  \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. \n\nApplications must support the requirement to notify appropriate individuals upon account creation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30576",
+      "title": "The application must notify appropriate individuals when accounts are modified.",
+      "description": "Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify or copy an existing account. \n\nNotification of account modification is one method and best practice for mitigating this risk. A comprehensive account management process will ensure that an audit trail which documents the modification of application user accounts and notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created or modified and provides logging that can be used for forensic purposes.  \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP. \n\nApplications must support the requirement to notify appropriate individuals when accounts are modified.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30582",
+      "title": "The application must notify appropriate individuals when account disabling actions are taken.",
+      "description": "When application accounts are disabled, user accessibility is affected.  Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must audit account disabling actions and, as required, notify as required the appropriate individuals so they can investigate the event.  Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes.    \n\nTo address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements.  Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. \n\nExamples of enterprise level authentication/access mechanisms include but are not limited to Active Directory and LDAP.\n\nApplications must notify, or leverage other mechanisms that notify, the appropriate individuals when accounts disabling actions are taken.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30583",
+      "title": "The application must notify appropriate individuals when accounts are terminated.",
+      "description": "When application accounts are terminated, user accessibility is affected.  Accounts are utilized for identifying individual application users or for identifying the application processes themselves. \n\nIn order to detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals when an account is terminated so they can investigate the event.  Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. \n\nTo address the multitude of policy based audit requirements, and to ease the burden of meeting these requirements, many application developers choose to integrate their applications with enterprise level authentication/access/audit mechanisms that meet or exceed access control policy requirements. Examples include but are not limited to Active Directory and LDAP.\n\nThe application must automatically notify the appropriate individuals when accounts are terminated.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30584",
+      "title": "Applications utilizing mobile code must meet DoD-defined mobile code requirements.",
+      "description": "Decisions regarding the deployment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include but are not limited to:  Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. \n\nDoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. \n\nApplications utilizing mobile code must meet policy requirements regarding the deployment, and/or use of mobile code. ",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30589",
+      "title": "The application must use cryptographic mechanisms to protect the integrity of audit tools.",
+      "description": "Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data.  Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.  \n\nIt is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.  \n\nTo address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced.  An example is a checksum hash of the file or files.\n\nApplications that function as audit tools must use cryptographic mechanisms to protect the integrity of the tools or allow cryptographic protection mechanisms to be applied to their tools.  All applications must not impede or hamper this requirement.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30590",
+      "title": "The application must employ automated mechanisms to alert security personnel of inappropriate or unusual activities with security implications.",
+      "description": "Applications will typically utilize logging mechanisms for maintaining a historical log of activity that occurs within the application.  This information can then be used for diagnostic purposes, forensics purposes or other purposes relevant to ensuring the availability and integrity of the application.  \n\nWhile it is important to log events identified as being critical and relevant to security, it is equally important to notify the appropriate personnel in a timely manner so they are able to respond to events as they occur.\n\nSolutions that include a manual notification procedure do not offer the reliability and speed of an automated notification solution. Applications must employ automated mechanisms to alert security personnel of inappropriate or unusual activities that have security implications.  If this capability is not built directly into the application, the application must be able to integrate with existing security infrastructure that provides this capability.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30592",
+      "title": "Applications utilizing Discretionary Access Control (DAC) must enforce a policy that limits propagation of access rights.",
+      "description": "Discretionary Access Control  (DAC) is based on the premise that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control.  An example of DAC includes user controlled file permissions.  DAC models have the potential for the access controls to propagate without limit resulting in unauthorized access to said objects.\n\nWhen applications provide a discretionary access control mechanism, the application must be able to limit the propagation of those access rights.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30593",
+      "title": "Applications that utilize Discretionary Access Control (DAC) must enforce a policy that Includes or excludes access to the granularity of a single user.",
+      "description": "DAC is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment.\n\nDAC allows the owner to determine who will have access to objects they control.  An example of DAC includes user controlled file permissions.\n\nIncluding or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single user basis.\n\nApplications that utilize Discretionary Access Control (DAC) must enforce a policy that includes or excludes access to the granularity of a single user.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30596",
+      "title": "The application must ensure the acquisition of mobile code to be deployed in information systems meets organization-defined mobile code requirements.",
+      "description": "Decisions regarding the acquisition of mobile code within organizational information systems need to include evaluations that determine the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations. \n\nDoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems.  Mobile code that is acquired for use and deployment in DoD information systems must meet DoD policy requirements\n\nThis requirement relates to the acquisition of mobile code.   The purpose is to ensure DoD organizations review applications which utilize mobile code to ensure they adhere to DoD mobile code policy prior to acquiring these applications and introducing them into the DoD environment.  This is not an application specific requirement and is Not Applicable to applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-30597",
+      "title": "The application must prevent the execution of prohibited mobile code.",
+      "description": "Decisions regarding the utilization of mobile code within organizational information systems needs to include evaluations which help determine the potential for the code to cause damage to the system if used maliciously. \n\nMobile code technologies include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed on organizational servers and mobile code downloaded and executed on individual workstations.\n\nApplications can prevent the execution of prohibited mobile code by leveraging architectures that provide a virtual execution environment sometimes referred to as a \"sandbox\".  The mobile code is executed within this isolated environment apart from the hosts indigenous operating environment which allows for mobile code capability restrictions and helps to prevent malicious code from accessing system resources and data. \n\nPolicy and procedures related to mobile code address preventing the introduction of unacceptable mobile code within the information system.  The DoDI 8552.01 policy pertains to the use of mobile code technologies within DoD information systems. \n\nThe application must prevent the execution of prohibited mobile code.\n",
+      "severity": "medium"
+    }
+  ]
+}