Proof of Concept

Definition of Scope




Version  2.2.1
Date February 2017












© 2017 All Rights Reserved, RedSocks B.V. 

The following information, hereafter referred to "the customer" in this document. 


1.  Summary

This document describes the requirements and needs for the successful execution of a RedSocks Malicious Threat Detection Proof of Concept (PoC).
This document is also intended to set the expectations of the PoC according to the capabilities of the RedSocks Solutions.


1.1 Proof of Concept

The RedSocks MTD PoC is intended for a customer who wishes to experience the operations and effectiveness of the appliance in a live environment. Because every environment has different characteristics and operational specifications there is a need for information about those specifics.  This document describes the need for this information. A Proof of Concept usually only encompasses one (1) RedSocks Malicious Threat Detection (MTD) and one (1) probe (hardware or virtual appliances)


1.2 RedSocks solution management overview

RedSocks is specialized in detecting and fighting malware. This 100% Dutch company provides the RedSocks Malicious Threat Detection (MTD) as network appliance. This innovative appliance analyses digital traffic flows in real-time on the basis of lists of malicious indicators and algorithms compiled by the RedSocks Malware Intelligence Team. The members of this team are highly experienced specialists
in finding new threats on the Internet and translating them into state-of-the-art malware detection. The RedSocks appliance detects malware, malicious behavior and potential data leakage in network traffic and in doing so provides an effective solution for a healthy network and safer IT-facilities for an efficiently operating organization.


1.3 Confidentiality

RedSocks recognizes the confidentiality level of the details requested in this document. As such this document is only intended for the use by RedSocks and the customer and only for the purpose of the PoC. The contents and scope of this document will never be shared in any form (digital, in print, writing or any other form) without explicit written permission from the customer.


1.4 RedSocks End User License Agreement

When conduction a Proof of Concept the customer agrees with all the terms and conditions of the RedSocks EULA in respect to this product and the use of this product – please refer to appendix A.

2.  Required Information

The following forms contain the information required by RedSocks to successfully plan, implement and evaluate the PoC. The information provided will assist RedSocks in identifying key dates, contacts and technical specifications. When the customer has any documentation he/she considers important and valuable in the successful execution of the PoC please attach it / them at the bottom of this document.

2.1 PoC Success Criteria

2.2 Virtual Appliances - System requirements 

vMTD Minimum Recommended
VMware software     VMware ESXi 5.1 & higher     VMware ESXi 5.1 & higher    
Storage capacity 140 GB 140 GB
CPU cores 4 8
Memory 8 GB 8 GB


vProbe    Minimum Recommended
VMware software     VMware ESXi 4.1 & higher     VMware ESXi 4.1 & higher    
Storage capacity 15 GB 15 GB
CPU cores 2 4
Memory 4 GB 8 GB



2.3 Preparations by the customer

In order to guarantee a fully functional implementation of the RedSocks solution and to gain maximum results of the POC some preparations have to be made by the customer.


1)     Mirrored Traffic (SPAN ports):  The RedSocks solution analyses all outgoing traffic. To enable this one or more traffic mirroring have to be configured on the infrastructure of the customer. Traffic mirroring is to be configured before the traffic passes through a proxy server and/or a NAT device (like a firewall). This enables the RedSocks solution to pinpoint the infected machine internally either based on the IP-address or the MAC-address of the device.
Appendix C – Positioning the RedSocks MTD, provides more information on the best location for generating mirrored traffic.

2)     IP Addresses and Information: For the implementation and configuration of the RedSocks solution some IP addresses, DNS information, etc. are required. Please refer to paragraph 2.6 of this document.

3)     Internet connectivity: The RedSocks solution requires Internet access to be able to download the Threat Intelligence updates. This is done using SSL (port 443). The RedSocks also needs to be able to resolve domain names through a DNS server. Connectivity with the Internet can be direct or via a proxy server. No data is send to RedSocks!

4)     In case of an implementation of virtual appliances please make sure the minimum requirements as stated in paragraph 2.2.2 can be met.

5)     In case of an implementation of the hardware appliances please make sure in total 2 U rack space is available. Network cables (UTP) are to be provided by the customer. The appliances are shipped with standard C14 (male) / C13 (female) power cables. If other cables are required, these are to be provided by the customer. A keyboard (USB) and monitor (VGA) need to be available on location of implementation.

2.4 Timelines for the PoC

The below table describes the timeline of the PoC. It is important to recognize that the responsibility for making the preferred dates of each milestone lies with different parties. Please make sure that all the parties involved are aware of their respective responsibilities and the attached timeline(s).

Preparations by <<the customer>>:

  • Working span port on network segment(s) to be monitored
  • Availability of IP addresses    

Implementation of the PoC equipment

  • Installation and configuration of the RedSocks Security solution at the customer site. The policy implemented is the base policy.   

Tuning session

  • During the tuning session (preferably one week after the implementation) the log information is examined together with <>. Based on the results a custom whitelist is created.

Collect RedSocks Equipment.

  • At the end of the PoC the RedSocks equipment is collected and shipped back to RedSocks. The log information is extracted from the RedSocks MTD to enable RedSocks Security to write the agreed reports. (A signed NDA warrants the confidential treatment of the data)

PoC Evaluation Session

  • The results of the PoC will be presented to <<the customer>>.
  • In addition, two reports will be handed over in person to <<the customer>>:
    • RedSocks PoC Evaluation and Advice - High Level rapport describing the PoC results)
    • RedSocks Threat Intelligence Report - Technical report describing the threats discovered during the PoC)


2.5 PoC Agreements

To assure that the best results are achieved during the PoC the following agreements are effective:


·       Implementation will be done as described in the, by <<the customer>> completed, PoC Definition of Scope.

·       A mutually signed NDA (Non-Disclosure Agreement) is in place

·       A mutually signed Loan Agreement is in place

·       <<the customer>> agrees that RedSocks will have access to the log information collected by the RedSocks MTD

·       No confidential information (log information and reports) will be sent via e-mail, unless PGP encryption is available.

·       During the PoC Evaluation Session the appropriate people (for example the Security Officer, IT Manager, decision makers, DPO, etc) are present.

2.6 Technical Details of the PoC implementation

The implementation of the RedSocks solution requires the installation and configuration of the MTD (Malicious Threat Detection) and the RedSocks Probe.


The function of the Probe is to extract the meta data (flow information) from the outgoing traffic and send it to the MTD. The MTD than analyzes the meta data and alerts in case of malware infections.


The management interface (GUI) of the MTD has to have access to the Internet and be able to download hourly updates. Making this possible, please make sure that the following traffic from the RedSocks MTD has to be allowed:


Traffic Type  Port     Comments    
DNS (internal or external)     UDP/TCP 53    

The MTD needs a DNS server for name resolving

Remark: External address resolving is needed!    
NTP (internal or external)     UDP 123     If available a NTP server can be configured to get the correct timestamps in the logging – optional 
SMTP (internal)     TCP 25     If desired the MTD can send e-mail alerts – optional    
RedSocks updates (external)     TCP 80 & 443    

The MTD download the updates from the Internet via HTTP and HTTPS.


RedSocks Update servers:

· (via https)

· (via https)

· (via https)

· (via https)

· (via https)


Ubuntu Update servers:

* (via http & https)    


The management interface of the probe will send the meta data (flow information) to the MTD using the IPFIX protocol. Please make sure the following traffic from the Probe to the MTD is allowed:

Traffic Type     Port     Comments    
IPFIX destination Port     UDP 2055     IPFIX data send from the Probe to the MTD    


The RedSocks MTD requires 2 IP-addresses and information about the facilitating IP and Internet services such as DNS, SMTP, NTP and Gateways. 

NOTE: It is strongly advised to place the management interface (Eth1) of the MTD and the flow interface (Eth2) of the MTD in different network segments.

If the internal clients and servers make use of an explicit proxy server(s) (configured in the web browser) the details regarding the proxy server port numbers is required for the configuration of the RedSocks solution.

Regarding the configuration of the RedSocks MTD and the detection policy is it important to configure the trusted DNS and SMTP (mail) servers. RedSocks will detect any usage any DNS and SMTP (mail) servers not being the trusted servers and report them as Rogue Servers.

Go to top
JSN Educare is designed by | powered by JSN Sun Framework