How is Our Data Protected on the VSA and in the Veracode Production Environment?
- All customer flaw information on the VSA is stored in memory unless there is a service interruption, in which case it is temporarily stored, encrypted, on disk.
- Midpoints are strictly tunnels to route traffic. No customer data or private keys are ever stored on the midpoints.
- All data transferring to and from the VSA is encrypted when in motion and at rest in the Veracode infrastructure.
- Scan event data is sent via Transport Layer Security (TLS) from the VSA to the jobservice.
- Communications between the VSA and Veracode are encrypted via OpenSSH between the VSA and the midpoint, as well as encrypted over OpenVPN between the VSA and midpoint.
Do I Need a Midpoint?
No, VSAs can operate without a midpoint, if necessary. However, the lack of a midpoint impacts Veracode’s ability to perform flaw verification and assist in debugging complicated login or crawl scripts.
How is the VSA Hardened against Intrusion?
- An encrypted file system on the VSA to protect all customer data
- A custom, locked-down shell that only gives access to commands necessary for VSA configuration
- The restricted shell is only accessible via a terminal and not over the network
- VSA activities are always audited
- All non-essential programs and services are disabled or removed from the VSA
- There are no open ports other than those explicitly needed (1194, 443, 80)
- The SSH to the VSA is only available over the encrypted tunnel from the midpoint.
What Type of Data is Sent to and from the VSA? How is it Secured?
The VSA communicates with two Veracode infrastructure components: the jobservice and the midpoint. The jobservice queues job requests and processes scan results. The VSA exchanges operating system and scan engine updates, scan configuration, scan progress, and flaw information with the jobservice. The midpoint troubleshoots scans and flaw verifications. Due to the higher level of privileges required to perform these activities, each VSA has its own midpoint to isolate activity and reduce the damage that an attack could cause on the reliability or integrity of a midpoint.
How Does Veracode Secure the Information Exchanged with the Jobservice and the Midpoint?
The VSA communicates with the jobservice using HTTPS. The VSA communicates with the midpoint using OpenVPN. All connections are initiated by the VSA and encrypted using end-to-end SSL.
What Ports Does the VSA Use?
- Port 80 (HTTP) - to test connections back to Veracode.
- Port 1194 (UDP) - for OpenVPN connections to the midpoint, if available. If this port is blocked (as part of the firewall configuration), the VSA uses port 443 (HTTPS) or port 80 (using TLS) for communication with the midpoint. Because UDP can maintain a higher performance connection than HTTPS, port 1194 is used when available.
- Port 443 (HTTPS) - for communication with the jobservice at all times.
- Port (configurable) - for remote syslog logging. It supports TCP, UDP, as well as TLS-based security, for sending VSA logs to a customer-provided syslog server.
Can I configure the VSA Logging?
Yes, the VSA supports logging to a customer-controlled syslog server. The VSA sends application-specific logs, login events from Veracode dynamic scan engineers, as well as auditd, yum, iptables, ssh, sudo and cron logs to a configured server. To configure syslog logging, please see the VSA Configuration Guide for step-by-step instructions.
How Has Veracode Tested the VSA Architecture?
- The Veracode Security Research team designed the entire VSA architecture to limit the risk exposure of customer environments.
- All developers working on the VSA are trained in secure coding practices.
- Developers and security research conduct extensive code and design reviews throughout the development process.
- All new functionality is reviewed by Security Research during design, development and test phases.
- All internally developed code is scanned using the Veracode application security testing tools and is not used until all issues are resolved (remediated or mitigated).
- All third-party code is scanned using the Veracode application security testing tools and is not used until all issues are resolved (remediated or mitigated).
- The Security Research team has performed manual penetration testing against the entire VSA architecture.
- Third-party manual penetration testing is performed at least once a year.
Who Has Access to the VSAs in My Environment?
VSAs are accessible by Veracode Dynamic Scan Engineers (DSEs). DSEs are a team of engineers in the Veracode Dynamic Operations team, which is focused on dynamic scan operations. This team is located in the Veracode HQ at 65 Network Drive, Burlington MA. The team goes through background checks before on-boarding and Veracode security training. Access to customer VSAs is restricted to this team and only when connecting from Veracode’s network.
To access a customer’s VSA, the DSEs must log into a single controlled server in Veracode’s network. Veracode is currently finalizing a process where upon login, Veracode DSEs will be put into a restricted shell that does not allow them direct access to key material. Once they select a customer’s VSA to access, their login information (username) is forwarded to the VSA for tracking purposes.
How Do I Know When a DSE Accesses My VSA?
VSAs are configurable to send all logs to a network-based syslog server, and then configured login events from Veracode DSEs are captured and sent to this server. To configure syslog logging, please see the VSA Configuration Guide for step-by-step instructions.