{ "name": "stig_arista_mls_dcs-7000_series_l2s", "date": "2016-03-29", "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.", "title": "Arista MLS DCS-7000 Series L2S Security Technical Implementation Guide", "version": "1", "item_syntax": "^\\w-\\d+$", "section_separator": null, "items": [ { "id": "V-60813", "title": "The Arista Multilayer Switch must enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.", "description": "Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. \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 which 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.\n\nEnforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet filtering capability based on header information, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).", "severity": "medium" }, { "id": "V-60821", "title": "The Arista Multilayer Switch must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies.", "description": "Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. \n\nExamples of flow control restrictions include blocking outside traffic claiming to be from within the organization, and not passing any web requests to the Internet not from the internal web proxy. Additional examples of restrictions include: keeping export-controlled information from being transmitted in the clear to the Internet, and blocking information marked as classified, but which 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, and devices) within information systems.\n\nEnforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet filtering capability based on header information, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).", "severity": "medium" }, { "id": "V-60823", "title": "The Arista Multilayer Switch must uniquely identify all network-connected endpoint devices before establishing any connection.", "description": "Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFor distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.\n\nThis requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including, but not limited to, workstations, printers, servers (outside a datacenter), VoIP Phones, and VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply.", "severity": "medium" }, { "id": "V-60825", "title": "The Arista Multilayer Switch must authenticate all endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.", "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity on the network. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk (e.g., remote connections).\n\nBidirectional authentication solutions include, but are not limited to, IEEE 802.1x and Extensible Authentication Protocol (EAP) and Radius server with EAP-Transport Layer Security (TLS) authentication.\n \nA network connection is any connection with a device that communicates through a network (e.g., local area network, wide area network, or the Internet).\n\nAuthentication must use a form of cryptography to ensure a high level of trust and authenticity.", "severity": "medium" }, { "id": "V-60827", "title": "The Arista Multilayer Switch must re-authenticate all endpoint devices every 60 minutes or less.", "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity on the network. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk (e.g., remote connections).\n\nBidirectional authentication solutions include, but are not limited to, IEEE 802.1x and Extensible Authentication Protocol (EAP) and Radius server with EAP-Transport Layer Security (TLS) authentication.\n \nA network connection is any connection with a device that communicates through a network (e.g., local area network, wide area network, or the Internet).\n\nAuthentication must use a form of cryptography to ensure a high level of trust and authenticity. Re-authentication must occur to ensure session security.", "severity": "medium" }, { "id": "V-60829", "title": "The Arista Multilayer Switch must re-authenticate 802.1X connected devices every hour.", "description": "Without re-authentication, users may access resources or perform tasks for which they do not have authorization. \n\nIn addition to the re-authentication requirements associated with session locks, organizations may require re-authentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances:\n\n(i) When authenticators change; \n(ii) When roles change; \n(iii) When security categories of information systems change; \n(iv) When the execution of privileged functions occurs; \n(v) After a fixed period of time; or\n(vi) Periodically.\n\nWithin the DoD, the minimum circumstances requiring re-authentication are privilege escalation and role changes. \n\nThis requirement only applies to components where this is specific to the function of the device or has the concept of user authentication (e.g., VPN or ALG capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management).", "severity": "medium" }, { "id": "V-60831", "title": "The Arista Multilayer Switch must authenticate 802.1X connected devices before establishing any connection.", "description": "Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.\n\nFor distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of authentication claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide authentication decisions (as opposed to the actual authenticators) to the services that need to act on those decisions.\n\nThis requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including, but not limited to, workstations, printers, servers (outside a datacenter), VoIP Phones, and VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply. \n\nDevice authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system.", "severity": "medium" } ] }