EPoS_Attach_5_ASDS_STIG_Version_4_Release_3_April_2017.htm

HTM file 2 MB Posted Oct 11, 2017

Attached to: Electronic Point of Sale (EPoS) and Supporting Services
Solicitation number: SP4703-17-R-CB01
Issued by: Defense Logistics Agency Aviation

About this file

Written by GovTribe AI · Dec 30, 2023

This is a Request for Proposal (RFP) from the Defense Logistics Agency Aviation seeking a turn-key hardware and software solution to capture fuel retail transactions at military service stations, mobile ground fueling operations, and aviation fueling for mobile airfield operations. The RFP is solicitation number SP4703-17-R-CB01 for an Electronic Point of Sale (EPoS) and supporting services. The contract will be awarded as a Firm-Fixed-Price IDIQ with a base period of five years plus ten one-year options, for a total of fifteen years. Offerors must provide devices, software, installation, and sustainment for the fuel transaction capture solution. The North American Industry Classification System Code 541519 for other computer related services applies, with a small business size standard of $27.5 million. Proposals are due by the date specified in the attached solicitation. The Defense Logistics Agency Aviation is the contracting agency.

From the source

Attachment 5

Text of this file

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:cdf="http://checklists.nist.gov/xccdf/1.1" xmlns:dc="http://purl.org/dc/elements/1.1/"><HEAD><META content="IE=5.0000" http-equiv="X-UA-Compatible">

UNCLASSIFIED </TITLE>

<BODY>

UNCLASSIFIED

<IMG width="1100" height="330" align="center" src="ASDS%20STIG%20Version%204%20Release%203%20April%202017_files/DoD-DISA-logos-as-JPEG.jpg">   Application Security and Development Security Technical Implementation Guide Version: 4 Release: 3 28 Apr 2017 XSL Release 1/29/2015     Sort by:   Vulid Description: This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.

_____________________________________________________________

Group ID (Vulid):  V-69239 Group Title: SRG-APP-000001 Rule ID: SV-83861r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000010 Rule Title: The application must provide a capability to limit the number of logon sessions per user. Vulnerability Discussion:  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 DoS attacks. This requirement may be met via the application or by utilizing information system session control provided by a web server or other underlying solution that provides 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. This requirement addresses concurrent sessions for individual system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. Mitigations:  APSC-DV-000010 Mitigation Control:  Use web or application server session management capabilities to limit the number of user application sessions or build session management capabilities into the application. Check Content:

For production environments; Review the system documentation, identify the number of application user logon sessions allowed per user, identify the methods utilized for user session management or have application administrator describe how the application implements user session management. Utilize the management interface that is used to set the user session values, or examine configuration files in order to review user session configuration settings. Ensure the number of sessions allowed per user is specified in accordance with the organizational requirements. For development environments; have the developer provide design documentation or demonstrate how the application is designed to limit the number of simultaneous user logon sessions. If the application is not configured to limit the number of logon sessions per user as defined by the organization, this is a finding. Fix Text: Design and configure the application to specify the number of logon sessions that are allowed per user.   CCI: CCI-000054

_____________________________________________________________

Group ID (Vulid):  V-69241 Group Title: SRG-APP-000295 Rule ID: SV-83863r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000060 Rule Title: The application must clear temporary storage and cookies when the session is terminated. Vulnerability Discussion:  Persistent cookies are a primary means by which a web application will store application state and user information. Since HTTP is a stateless protocol, this persistence allows the web application developer to provide a robust and customizable user experience. However, if a web application stores user authentication information within a persistent cookie or other temporary storage mechanism, this information can be stolen and used to compromise the users account. Likewise, HTML 5 provides the developer with a client storage capability where application data larger than the 4K cookie size limit can be stored on the local client. While this can be beneficial to the developer, this is considered insecure storage and should not be used for storing sensitive session or security tokens. A cross site scripting attack can put this data at risk. Web applications must clear sensitive data from files and storage areas on the client when the session is terminated. Check Content:  Review application design documentation and interview application administrator to identify how the application makes use of temporary client storage and cookies. Identify cookie and web storage locations on the client. Clear all browser cookies and web cache. Log on to the application and perform several standard operations, noting if the application ever prompts the user to accept a cookie. If prompted by the browser to save the user ID and password (decline to save the user ID and password), this is a finding. Log out of the application and close the browser. Reopen the browser and examine the stored cookies. The cookies displayed should be related to the application website. The procedure to view cookies will vary according to the browser used. Some modern browsers are making use of SQLite databases to store cookie data so use of a SQLite db reader/browser may be required. Open the cookies related to the application website and search for any identification or authentication information. While authentication information can vary on a per application basis, this is most often specified as "username=x", or "password=x". If the web application prompts the user to save their password, or if a username or password value exists within a cookie or within local storage locations, even if hashed, this is a finding. The application may use means other than cookies to store user information. If the reviewer detects an alternative mechanism for storing information locally, examine the data storage to ensure no authentication or other sensitive information is present. Fix Text: Design and configure the application to clear sensitive data from cookies and local storage when the user logs out of the application.   CCI: CCI-002361

_____________________________________________________________

Group ID (Vulid):  V-69243 Group Title: SRG-APP-000295 Rule ID: SV-83865r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000070 Rule Title: The application must automatically terminate the non-privileged user session and log off non-privileged users after a 15 minute idle time period has elapsed. Vulnerability Discussion:  Leaving a user’s application session established for an indefinite period of time increases the risk of session hijacking. Session termination terminates an individual user's logical application session after 15 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application. Check Content:  Ask the application representative to demonstrate the configuration setting where the idle time out value is defined. Alternatively, logon with a regular application user account and let the session sit idle for 15 minutes. Attempt to access the application after 15 minutes of inactivity. If the configuration setting is not set to time out user sessions after 15 minutes of inactivity, or if the regular user session used for testing does not time out after 15 minutes of inactivity, this is a finding. Fix Text: Design and configure the application to terminate the non-privileged users session after 15 minutes of inactivity.

CCI: CCI-002361

_____________________________________________________________

Group ID (Vulid):  V-69245 Group Title: SRG-APP-000295 Rule ID: SV-83867r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000080 Rule Title: The application must automatically terminate the admin user session and log off admin users after a 10 minute idle time period is exceeded. Vulnerability Discussion:  Leaving an admin user's application session established for an indefinite period of time increases the risk of session hijacking. Session termination terminates an individual user's logical application session after 10 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application. Check Content:  Ask the application representative to demonstrate the application configuration setting where the idle time out value is defined for admin users. Alternatively, logon with an admin user account and let the session sit idle for 10 minutes. Attempt to access the application after 10 minutes of inactivity. If the configuration setting is not set to time out admin user sessions after 10 minutes of inactivity, or if the session used for testing does not time out after 10 minutes of inactivity, this is a finding. Fix Text: Design and configure the application to terminate the admin users session after 10 minutes of inactivity.   CCI: CCI-002361

_____________________________________________________________

Group ID (Vulid):  V-69247 Group Title: SRG-APP-000296 Rule ID: SV-83869r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000090 Rule Title: Applications requiring user access authentication must provide a logoff capability for user initiated communication session. Vulnerability Discussion:  If a user cannot explicitly end an application session, the session may remain open and be exploited by an attacker. Applications providing user access must provide the ability for users to manually terminate their sessions and log off. Check Content:  If the application does not provide an interface for interactive user access, this is not applicable. Log on to the application with a valid user account. Examine the user interface. Identify the command or link that provides the logoff function. Activate the user logoff function. Observe user interface and attempt to interact with the application. Confirm user interaction with the application is no longer possible. If the user session is not terminated or if the logoff function does not exist, this is a finding. Fix Text: Design and configure the application to provide all users with the capability to manually terminate their application session.

CCI: CCI-002363

_____________________________________________________________

Group ID (Vulid):  V-69249 Group Title: SRG-APP-000297 Rule ID: SV-83871r1_rule Severity: CAT III Rule Version (STIG-ID): APSC-DV-000100 Rule Title: The application must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions. Vulnerability Discussion:  If a user is not explicitly notified that their application session has been terminated, they cannot be certain that their session did not remain open. Applications with a user access interface must provide an explicit logoff message to the user upon successful termination of the user session. Check Content:  If the application does not provide an interface for interactive user access, this is not applicable. Log on to the application with a valid user account. Examine the user interface. Identify the command or link that provides the logoff function. Activate the user logoff function. If the application does not provide an explicit logoff message indicating the user session has been terminated, this is a finding. Fix Text: Design and configure the application to provide an explicit logoff message to users indicating a successful logoff has occurred upon user session termination.

CCI: CCI-002364

_____________________________________________________________

Group ID (Vulid):  V-69251 Group Title: SRG-APP-000311 Rule ID: SV-83873r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000110 Rule Title: The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in storage. Vulnerability Discussion:  Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These 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. One 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. Classify the system hosting the application with default classification. Treat all unmarked data at the highest classification as the overall hosting system is classified. If there is no classification, mark system high. Mitigations:  APSC-DV-000110 Mitigation Control:  Classify the system hosting the application with default classification. Treat all unmarked data at the highest classification as the overall hosting system is classified. If there is no classification, mark system high. Create POAM documentation and plan to create and retain data markings within application. Check Content:  Review the application documentation and interview the application administrator. Determine if the application processes classified, FOUO, or other data that is required to be marked and identify if the application requirements specify data markings of any other types of data. If the application does not contain classified, FOUO, or other data that is required to be marked, this requirement is not applicable. Review the database or other storage mechanism and have the application administrator identify and demonstrate how the application assigns and maintains data markings while the data is in storage. Typical methods for marking data include utilizing a table or data base field that contains the marking information and associating the marking information with the data. If application data required to be marked is not marked and does not retain its marking while it is being stored, this is a finding. Fix Text: Design and configure the application to assign data marking and ensure the marking is retained when the data is stored.   CCI: CCI-002262

_____________________________________________________________

Group ID (Vulid):  V-69253 Group Title: SRG-APP-000313 Rule ID: SV-83875r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000120 Rule Title: The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in process. Vulnerability Discussion:  Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These 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. One 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 process. If the security attributes are lost when the data is being processed, there is the risk of a data compromise. Check Content:

Review the application documentation and interview the application administrator. Identify if the application requirements include data marking. Also determine if the application processes classified, FOUO or other data that is required to be marked. If the application does not contain classified, FOUO or have data marking requirements, this requirement is not applicable. Access the user interface for the application and navigate through the application. Perform several application actions that will manipulate data contained within the application. For example, create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Perform an edit action on the test data that does not edit the marking itself or perform any other form of data processing such as assigning the data to another users work queue for review or printing the data, ensure the data marking is retained throughout the data processing actions. If application data required to be marked does not retain its marking while it is being processed by the application, this is a finding. Fix Text: Design and configure the application to retain the data marking when processing data.   CCI: CCI-002263

_____________________________________________________________

Group ID (Vulid):  V-69255 Group Title: SRG-APP-000314 Rule ID: SV-83877r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000130 Rule Title: The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission. Vulnerability Discussion:  Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These 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. One 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 transmission. If the security attributes are lost when the data is being transmitted, there is the risk of a data compromise. Check Content:

Review the application documentation and interview the application administrator. Identify if the application requirements include data marking also determine if the application processes classified, FOUO or other data that is required to be marked. Access the user interface for the application and navigate through the application. Perform an application action that will transmit marked data that is contained within the application. If the application does not contain classified, FOUO or have data marking requirements, or if the application does not transmit data, this requirement is not applicable. E.g., create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Initiate the application processes to transmit data. Access remote system or have person with access to remote system verify the data marking is retained after the data transmission. If application data required to be marked does not retain its marking when it is being transmitted by the application, this is a finding. Fix Text: Design and configure the application to retain the data marking when transmitting data.   CCI: CCI-002264

_____________________________________________________________

Group ID (Vulid):  V-69257 Group Title: SRG-APP-000014 Rule ID: SV-83879r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000160 Rule Title: The application must implement DoD-approved encryption to protect the confidentiality of remote access sessions. Vulnerability Discussion:  Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection 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. Check Content:  Review the application documentation and interview the system administrator. Identify the application encryption capabilities and methods for implementing encryption protection. For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon.

Click on the padlock icon and examine the connection information. Determine if TLS encryption is used to secure the session. For non-web based applications, determine the TCP/IP port, protocol and method used for establishing client connections to the remote server. Review application configuration settings to ensure encryption is specified and via TLS. If the connection is not secured with TLS, this is a finding. Fix Text: Design and configure applications to use TLS encryption to protect the confidentiality of remote access sessions.   CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69259 Group Title: SRG-APP-000015 Rule ID: SV-83881r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000170 Rule Title: The application must implement cryptographic mechanisms to protect the integrity of remote access sessions. Vulnerability Discussion:  Without integrity protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection.

Without integrity protection mechanisms, unauthorized individuals may be able to insert inauthentic content into a remote session. The encryption strength of mechanism is selected based on the security categorization of the information. Check Content:

Review the application documentation and interview the system administrator. Identify the application encryption capabilities and methods for implementing encryption protection. For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon.

CCI: CCI-001453

_____________________________________________________________

Group ID (Vulid):  V-69261 Group Title: SRG-APP-000015 Rule ID: SV-83883r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000180 Rule Title: Applications with SOAP messages requiring integrity must include the following message elements:-Message ID-Service Request-Timestamp-SAML Assertion (optionally included in messages) and all elements of the message must be digitally signed. Vulnerability Discussion:  Digitally signed SOAP messages provide message integrity and authenticity of the signer of the message independent of the transport layer. Service requests may be intercepted and changed in transit and the data integrity may be at risk if the SOAP message is not digitally signed. Functional architecture aspects of the application security plan identify the application data elements that require data integrity protection. Check Content:

Review the application documentation, system security plan, application architecture diagrams and interview the application administrator. Review the design document for web services using SOAP messages. If the application does not utilize SOAP messages, this check is not applicable. Review the design document and SOAP messages. Verify the Message ID, Service Request, Timestamp, and SAML Assertion are included in the SOAP message. If they are included, verify they are signed with a certificate. If SOAP messages requiring integrity do not have the Message ID, Service Request, Timestamp, and SAML Assertion signed, or if any part of the message is not digitally signed, this is a finding. Fix Text: Design and configure the application to sign the following message elements for SOAP messages requiring integrity: - Message ID - Service Request - Timestamp - SAML Assertion - Message elements   CCI: CCI-001453

_____________________________________________________________

Group ID (Vulid):  V-69279 Group Title: SRG-APP-000014 Rule ID: SV-83901r1_rule Severity: CAT I Rule Version (STIG-ID): APSC-DV-000190 Rule Title: Messages protected with WS_Security must use time stamps with creation and expiration times. Vulnerability Discussion:  The lack of time stamps could lead to the eventual replay of the message, leaving the application susceptible to replay events which may result in an immediate loss of confidentiality. Check Content:

Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. If the application does not utilize WS-Security tokens, this check is not applicable. Examine the contents of a SOAP message using WS Security; all messages should contain time stamps, sequence numbers, and expiration. If messages using WS Security do not contain time stamps, sequence numbers, and expiration, this is a finding. Fix Text: Design and configure applications using WS-Security messages to use time stamps with creation and expiration times and sequence numbers.   CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69281 Group Title: SRG-APP-000014 Rule ID: SV-83903r1_rule Severity: CAT I Rule Version (STIG-ID): APSC-DV-000200 Rule Title: Validity periods must be verified on all application messages using WS-Security or SAML assertions. Vulnerability Discussion:  When using WS-Security in SOAP messages, the application should check the validity of the time stamps with creation and expiration times. Time stamps that are not validated may lead to a replay event and provide immediate unauthorized access of the application. Unauthorized access results in an immediate loss of confidentiality. Check Content:

Ask the application representative for the design document. Review the design document for web services. If the application does not utilize WSS or SAML assertions, this requirement is not applicable. Review the design document and verify validity periods are checked on all messages using WS-Security or SAML assertions. If the design document does not exist, or does not indicate validity periods are checked on messages using WS-Security or SAML assertions, this is a finding. Fix Text: Design and configure the application to use validity periods, ensure validity periods are verified on all WS-Security token profiles and SAML Assertions.   CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69283 Group Title: SRG-APP-000014 Rule ID: SV-83905r2_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000210 Rule Title: The application must ensure each unique asserting party provides unique assertion ID references for each SAML assertion. Vulnerability Discussion:  SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject> element. SAML assertion identifiers should be unique across a system implementation. Duplicate SAML assertion identifiers could lead to unauthorized access to a web service. Check Content:  Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Review the design document and verify SAML assertion identifiers are not reused by a single asserting party. If the design document does not exist, or does not indicate SAML assertion identifiers which are unique for each asserting party, this is a finding. Fix Text: Design and configure each SAML assertion authority to use unique assertion identifiers.   CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69285 Group Title: SRG-APP-000014 Rule ID: SV-83907r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000220 Rule Title: The application must ensure encrypted assertions, or equivalent confidentiality protections are used when assertion data is passed through an intermediary, and confidentiality of the assertion data is required when passing through the intermediary. Vulnerability Discussion:  SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject> element. The confidentially of the data in a message as the message is passed through an intermediary web service may be required to be restricted by the intermediary web service. The intermediary web service may leak or distribute the data contained in a message if not encrypted or protected. Check Content:  Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. If the application does not utilize WS-Security tokens, this check is not applicable. Verify all WS-Security tokens are transmitted via an approved encryption method. If the design document does not exist, or does not indicate all WS-Security tokens are only transmitted via an approved encryption method, this is a finding. Fix Text: Encrypt assertions or use equivalent confidentiality when sensitive assertion data is passed through an intermediary.

CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69287 Group Title: SRG-APP-000014 Rule ID: SV-83909r1_rule Severity: CAT I Rule Version (STIG-ID): APSC-DV-000230 Rule Title: The application must use the NotOnOrAfter condition when using the SubjectConfirmation element in a SAML assertion. Vulnerability Discussion:  SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject>

element. When a SAML assertion is used with a <SubjectConfirmation>

element, a begin and end time for the <SubjectConfirmation> should be set to prevent reuse of the message at a later time. Not setting a specific time period for the <SubjectConfirmation>, may grant immediate access to an attacker and result in an immediate loss of confidentiality. Check Content:

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the <SubjectConfirmation> element. All messages should contain the <NotOnOrAfter> element. This can be accomplished if the application allows the ability to view XML messages or via a protocol analyzer like Wireshark. If SOAP messages do not contain <NotOnOrAfter> elements, this is a finding. Fix Text: Design and configure the application to use the <NotOnOrAfter> condition when using the <SubjectConfirmation> element in a SAML assertion.

CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69289 Group Title: SRG-APP-000014 Rule ID: SV-83911r1_rule Severity: CAT I Rule Version (STIG-ID): APSC-DV-000240 Rule Title: The application must use both the NotBefore and NotOnOrAfter elements or OneTimeUse element when using the Conditions element in a SAML assertion. Vulnerability Discussion:  SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject> element. When a SAML assertion is used with a <Conditions> element, a begin and end time for the <Conditions> element should be set in order to specify a timeframe in which the assertion is valid. Not setting a specific time period for the <Conditions> element, the possibility exists of granting immediate access or elevated privileges to an attacker which results in an immediate loss of confidentiality. Check Content:

and <NotOnOrAfter> or <OneTimeUse> element when in a SAML Assertion.

This can be accomplished using a protocol analyzer such as Wireshark. If SOAP using the <Conditions> element does not contain <NotBefore> and <NotOnOrAfter> or <OneTimeUse> elements, this is a finding. Fix Text: Design and configure the application to implement the use of the <NotBefore> and <NotOnOrAfter> or <OneTimeUse> when using the <Conditions>

element in a SAML assertion.   CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69291 Group Title: SRG-APP-000014 Rule ID: SV-83913r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000250 Rule Title: The application must ensure if a OneTimeUse element is used in an assertion, there is only one of the same used in the Conditions element portion of an assertion. Vulnerability Discussion:  Multiple <OneTimeUse> elements used in a SAML assertion can lead to elevation of privileges, if the application does not process SAML assertions correctly. Check Content:  Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the OneTimeUse element; all messages should contain only one instance of a <OneTimeUse> element in a SAML assertion. This can be accomplished using a protocol analyzer such as Wireshark. If SOAP message uses more than one, OneTimeUse element in a SAML assertion, this is a finding. Fix Text: When using OneTimeUse elements in a SAML assertion only allow one, OneTimeUse element to be used in the conditions element of a SAML assertion.

CCI: CCI-000068

_____________________________________________________________

Group ID (Vulid):  V-69293 Group Title: SRG-APP-000014 Rule ID: SV-83915r1_rule Severity: CAT II Rule Version (STIG-ID): APSC-DV-000260 Rule Title: The application must ensure messages are encrypted when the SessionIndex is tied to privacy data. Vulnerability Discussion:  When the SessionIndex is tied to privacy data (e.g., attributes containing privacy data) the message should be encrypted. If the message is not encrypted there is the possibility of compromise of privacy data. Check Content:  Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using a SessionIndex in the SAML element AuthnStatement. Verify the information which is tied to the SessionIndex. If the SessionIndex is tied to privacy information, and it is not encrypted, this is a finding. Fix Text: Encrypt messages when the SessionIndex is tied to privacy data.   CCI: CCI-000068

_______________…

This is the start of the file's text. The full file is on GovTribe.

Other files

File	Type	Posted
Epos_Amend_0005.zip	ZIP file	Dec 20, 2017
Epos_Q&A__4.zip	ZIP file	Dec 20, 2017
15 EPoS Attach 15 Group 2 Task Order 3 Fixed Installation_Sustainment PWS 20171113 CC.docx	DOCX document	Dec 18, 2017
8 EPoS Attach 8 Solution Demonstration 20171213 CC.docx	DOCX document	Dec 18, 2017
12 EPoS Attach 12 Group 1 Task Order 1 Active Directory PWS 20171113 CC.docx	DOCX document	Dec 18, 2017
13 EPoS Attach 13 Group 2 Task Order 1 Fixed Software Development PWS 20171113 CC.docx	DOCX document	Dec 18, 2017
EPoS Attach 19 Pricing Sheet for Group 3 Mobile Devices 20171113 CC.xlsx	XLSX spreadsheet	Dec 18, 2017
SP470317RCB01 Amend 0004.pdf	PDF	Dec 18, 2017
2 EPoS Attach 2 Evaluation Factors for Award 20171207 CC.DOCX	DOCX document	Dec 18, 2017
16 EPoS Attach 16 Group 3 Task Order 1 Mobile Device Integration PWS 20171201 CC.docx	DOCX document	Dec 18, 2017
14 EPoS Attach 14 Group 2 Task Order 2 Fixed Software Sustainment PWS 20171113 CC.docx	DOCX document	Dec 18, 2017
Attachment 20 - Location and Pump Details Sorted.xlsm	XLSM spreadsheet	Dec 18, 2017
3 EPoS Attach 3 IDIQ Performance Work Statement 20171213 CC.docx	DOCX document	Dec 18, 2017
EPoS Attach 17 Pricing Sheet for Group 1 Active Directory Services 20171113 CC.xlsx	XLSX spreadsheet	Dec 18, 2017
1 EPoS Attach 1 Instructions to Offerors 20171207 CC.DOCX	DOCX document	Dec 18, 2017
9 EPoS Attach 9 Cybersecurity Demonstration 20171201 CC.docx	DOCX document	Dec 18, 2017
EPoS Attach 18 Pricing Sheet for Group 2 Fixed Facility Devices 20171113 CC.xlsx	XLSX spreadsheet	Dec 18, 2017
EPoS Attach 4 List of Fixed Device Locations Oct 2017 Revised 20171113 CC.xlsx	XLSX spreadsheet	Dec 18, 2017
Epos_Q&A__3.zip	ZIP file	Dec 14, 2017
SP470317RCB01_Amend_0003.pdf	PDF	Dec 6, 2017
Epos_Q&A__2.zip	ZIP file	Dec 4, 2017
SP470317RCB01_Amend_0002.pdf	PDF	Nov 16, 2017
SP470317RCB01_Amend_0001.pdf	PDF	Nov 3, 2017
EPoS_Attach_13_Group_2_Task_Order_1_Fixed_Software_Development_PWS_20170820.docx	DOCX document	Oct 11, 2017
EPoS_Attach_10_Key_Personnel_Resume_Template_20170803.docx	DOCX document	Oct 11, 2017
EPoS_Attach_15_Group_2_Task_Order_3_Fixed_Installation_Sustainment_PWS_20170820.docx	DOCX document	Oct 11, 2017
EPoS_Attach_19_Pricing_Sheet_for_Group_3_Mobile_Devices_20170823.xlsx	XLSX spreadsheet	Oct 11, 2017
EPoS_Attach_14_Group_2_Task_Order_2_Fixed_Software_Sustainment_PWS_20170820.docx	DOCX document	Oct 11, 2017
EPoS_Attach_18_Pricing_Sheet_for_Group_2_Fixed_Facility_Devices_20170822.xlsx	XLSX spreadsheet	Oct 11, 2017
EPoS_Solicitation_SF1449_20171011.docx	DOCX document	Oct 11, 2017
EPoS_Attach_12_Group_1_Task_Order_1_Active_Directory_PWS_20170820.docx	DOCX document	Oct 11, 2017
EPoS_Attach_17_Pricing_Sheet_for_Group_1_Active_Directory_Services_20170822.xlsx	XLSX spreadsheet	Oct 11, 2017
EPoS_Attach_3_IDIQ_Performance_Work_Statement_20170913.docx	DOCX document	Oct 11, 2017
EPoS_Attach_4_List_of_Fixed_Device_Locations_Sept_2017.xlsx	XLSX spreadsheet	Oct 11, 2017
EPoS_Attach_16_Group_3_Task_Order_1_Mobile_Device_Integration_PWS_20170820.docx	DOCX document	Oct 11, 2017
EPoS_Attach_2_Evaluation_Factors_for_Award_20170821.docx	DOCX document	Oct 11, 2017
EPoS_Attach_11_Past_Performance_Questionnaire_20170622.docx	DOCX document	Oct 11, 2017
EPoS_Attach_6_Windows_10_STIG_Version_1_Release_9_April_2017.htm	HTM file	Oct 11, 2017
EPoS_Attach_1_Instructions_to_Offerors_20171011.docx	DOCX document	Oct 11, 2017
EPoS_Attach_7_Employee_Confidentiality_Non-Disclosure_of_Non-Public_Information.docx	DOCX document	Oct 11, 2017
EPoS_Attach_9_Cybersecurity_Demonstration_20170819.docx	DOCX document	Oct 11, 2017
EPoS_Attach_8_Solution_Demonstration_201708131.docx	DOCX document	Oct 11, 2017

Show all 42

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

File details come from the government source that posted it. Updated Nov 14, 2017.