Is Penetration Testing of shielded applications still required? Will testers still find vulnerabilities?
Yes, Penetration testing of shielded applications is absolutely recommended. Testers are required to find vulnerabilities which have not previously been discovered or provided to RedShield for mitigation; and are not addressed by default shield policies. Such newly discovered vulnerabilities should then be provided to RedShield in order to mitigate, or fixed in code immediately if this is an option.
Shielding is only fully effective when penetration test reports are provided in this way - shielding is a much faster alternative to fixing vulnerabilities in code; but is not a magic bullet and benefits from this input.
Please see below for further notes on this.
How does RedShield mitigate complex or unique application vulnerabilities?
RedShield achieves complete mitigation of complex application vulnerabilities by collaborating with third party penetration testers, and customising Advanced Shield Objects from our library to address penetration test findings.
RedShield scanning engines can discover and mitigate many types of vulnerabilities automatically, but shielding is most effective when penetration test results and any other sources of vulnerability information are shared with our team, and we are authorised to implement the required shield objects to address known vulnerabilities. RedShield analysts and engineers are available 24x7 to assist with this process. Following a penetration test of an application, RedShield requests that all customers securely share vulnerability findings with our team at the earliest opportunity.
Is RedShield Cloud compatible with web analytics such as Google Analytics?
Does RedShield Cloud have any effect on Search Engine Optimisation?
Generally no, however a small improvement in page load times will often help with SEO and this would be expected for applications running via RedShield Cloud.
Will page load times and site performance be affected?
We usually see page load times improve, as well as server CPU and memory load reducing due to the TCP optimisations introduced by RedShield Cloud. Caching may also be enabled by request which can have a very significant beneficial effect on page load times and server load.
Our web servers make calls out to other services. Will this be affected?
No. Outbound connectivity from the web server will go directly via its normal path. RedShield is in-path only for incoming client requests, and corresponding server responses.
Are there any other effects to be aware of?
Client IP Address: All traffic will come from the RedShield IP address ranges of each local PoP, or point of presence. Some applications may use the client's real IP address when writing server logs; these logs may need to be changed to take the IP address from the X-Forwarded-For header instead of the IP header in the packet. Most web servers make this easy, as it is a very common architecture used by load balancers and Content Distribution Networks (CDNs).
***** PLEASE DISABLE ANY REACTIVE IP BLOCKING OR BLACKLISTING FUNCTIONS *****
Please note that IP address blacklisting scripts and security devices may inadvertently lock out the RedShield Cloud IP addresses, which will block all traffic to all users.
Load Balancers: Some load balancers may use the client IP address as a means to distribute traffic to one or more servers. By default, IP-based load balancing of traffic from RedShield Cloud will be ineffective, and one server will end up taking all the load. RedShield recommends cookie insertion or load balancing based on the X-Forwarded-For header which RedShield Cloud inserts into each request, containing the client's real IP address. If these methods are not available, ask your service delivery team about source IP address pools or RedShield Server Load Balancing.
Server failover is also available for RedShield Cloud customers and will be discussed during setup. To request additional server IPs for resilience please raise a support ticket via the standard channels.
TCP Connection Multiplexing: By default, RedShield Cloud aggregates many TCP connections into a smaller number of connections, to improve efficiency of the network, offload servers, and prevent connection floods from being passed to the server. In rare cases some applications cannot tolerate this, however we generally pick this up during the setup process. Application, firewall and server administrators will see greatly reduced connection numbers as a result. This is normal, and generally a desirable aspect of RedShield Cloud's architecture.
Please advise if you would like this feature disabled (note that special arrangements will need to be made if your site requires support for more than 64,000 concurrent connections).
Considerations for Operations Teams:
SSL/TLS Certificate expiry
For applications which use SSL, it is critical to keep the certificate up to date. Where possible, RedShield administrators will advise customers of upcoming deadlines for certificate renewal; however customers have overall responsibility for maintaining server infrastructure and must keep these certificates updated.
Updated certificates are also required for RedShield Cloud proxy infrastructure, and RedShield administrators will remind customers when SSL certificates on our own systems are due for renewal. Customers are required to purchase new certificates prior to expiry of the current certificate. When a new certificate has been purchased, a RedShield support ticket must be opened and the certificate and private key uploaded via the RedShield Vault secure upload facility (Refer to Securely Exchanging Files And Data With RedShield).
Server IP Address Changes
If your server IP address changes, you must raise a ticket with the RedShield operations team in order to have traffic sent to the new server. In most cases no DNS changes are required in order to complete the migration. If both old and new servers are available for a migration period (this may be quite short, anything over one hour) this migration may be completed without affecting any traffic.
RedShield Vulnerability Intelligence - Vulnerability Importation, Scanning and Analysis
RedShield Cloud includes a license of Vulnerability Intelligence (VI) for each shielded asset. RedShield VI is a fully managed network and application vulnerability scanner, which utilises multiple commercial scanning engines and correlates results for removal of false positives, and further analysis of Critical and High risk results by the RedShield Analyst team. Running regular vulnerability scans assists in the management of security policies by providing continuous assurance that policies are correctly configured and effective against emerging threats.
Please note that only non-authenticated scanning is conducted by default. More intensive scanning and penetration testing is highly recommended for all applications. Vulnerabilities discovered should be securely shared with RedShield at the earliest opportunity to facilitate Advanced Shielding, mitigating the risk of application compromise ahead of code remediation.
What do we need to consider when activating scanning?
RedShield VI is designed to cause minimal load and risk of disruption to applications. Security tests are performed without harming user data or applications themselves. VI is designed to run during business hours against production systems but may be scheduled to run daily, weekly or at other intervals, at a nominated time of day.
When scanning is first run, it is helpful to have an administrator watching over servers and systems to ensure that everything goes smoothly, and to assist RedShield with answers to any information required during the initial scan.