10 Frequently Asked Questions

1.

What is IWS?

2.

How is IWS different from any other existing leakage protection products in the market?

3.

Why is it important to have a outbound security system like IWS on top of other existing inbound security systems, such as Web Application Firewall (WAF) or Intrusion Prevention System (IPS)?

4.

What are the various types of content supported by IWS? Can IWS be easily customised to detect specific type(s) of sensitive data if necessary?

5.

Can tightening of quality control in web servers related activity (pre and post implementation) eliminate the need for IWS?

6.

Where should I deploy IWS in my organization?

7.

Will IWS affect overall network throughput?

8.

Does IWS support High Availability feature for mission critical system and support Load Balancing for high performance system?

9.

How should I deploy IWS if there are multiple web servers distributed over various locations in various countries?

10.

Why is iNFOTECT focussed on detecting leakages from web servers? Can I use IWS to monitor other servers eg. email / instant messaging servers?

10 Frequently Asked Questions and Answers
 

1

What is IWS?

 

 

IWS stands for “Insight for Web Server”. As the name implies, IWS provides outbound security protection for web servers, regardless whether they are Internet-facing or Intranet-facing web servers.

top

 

2

How is IWS different from any other existing leakage protection products in the market?

 

 

Existing leakage protection products are primarily focused on protecting against leakages from corporate LAN environment. For instance, some solutions provide leakages protection for USB drives, laptops, employees sending out sensitive emails or posting sensitive content to the Internet. Few, if any, provides protection against leakages from web servers which are usually situated on the DMZ (de-militarised zone) segment in a corporate network infrastructure.

In addition, most, if not all, existing leakage protection products require extensive tagging or fingerprinting to identify the types of information to protect. Though this approach may be understandable for protection in the corporate LAN environment, it is hardly acceptable when it is applied to the web servers in the DMZ zone. For instance, one will find it difficult to justify activation of entire staff to assist in the tagging and fingerprinting just to protect leakages from web servers. Such approach by other leakage protection products are too much to ask from end users when protecting web servers. Instead, IWS offers a much simplified, easy-to-deploy solution to protect leakages from web servers – no tagging or fingerprinting is required. IWS is able to detect sensitive information out of the box. (Refer to Q4 for the list of supported types of sensitive information).

Furthermore, other information leakage products cannot effectively protect against source code leakages from web servers. If a web application has been allowed to be uploaded to the web servers, the other information leakage products are not able to differentiate when the web application is malfunctioning and starts to throw out source codes or overly informative debug messages.

Hence, these generic information leakage products designed to protect against leakages from a corporate LAN environment are not suitable nor effective in its protection against web servers related leakages as compared to dedicated solutions such as IWS.

Lastly, existing DLP solutions cannot prevent defaced or maliciously compromised webpages from being shown to the public, while IWS can.

top

 

3

Why is it important to have a outbound security system like IWS on top of other existing inbound security systems, such as Web Application Firewall (WAF) or Intrusion Prevention System (IPS)?

 

 

Existing security systems provide good protection against incoming attacks from external sources. IWS complements such systems by extending the protection profile to include protection against outgoing information leakages.

Although some WAFs are able to scan outgoing traffic, their ability in this area is very limited. This is understandable as WAFs are primarily focused on incoming threats. For instance, though some WAFs claim they can detect sensitive information such as credit card and Social Security numbers, they are not able to detect presence of such information if the information is contained in common document formats such as Microsoft Office or PDF files. In addition, WAFs are usually not able to detect presence of leakages of source codes as they are not equipped to distinguish between source codes and normal English text. For these areas, IWS has made use of patented technologies to achieve what WAFs cannot do.

For IPS, again as their name implies, their focus is in protecting against intrusions, not leakages.

Likewise, existing WAF or IPS solutions cannot prevent defaced or maliciously compromised web pages from being shown to the public, while IWS can.

Hence, IWS complements WAFs and IPS to provide a more comprehensive protection to your organisation.

Please access the Comparison Matrix for a more detailed comparison.

top

 

4

What are the various types of content supported by IWS? Can IWS be easily customised to detect specific type(s) of sensitive data if necessary?

 

 

Out of the box, IWS protects against:

a. Leakage of source code
b. Leakage of software debug messages
c. Leakage of system configuration
d. Leakage of personal information
e. Leakage of financial information
f. Leakage of healthcare information
g. Display of defaced/hacked web pages
h. Display of maliciously compromised web pages

IWS also allows users to detect other types of sensitive information, without the need to learn a new scripting or programming language. Customised detection logic can be added via web-based custom editor.

top

 

5

Can tightening of quality control in web servers related activity (pre and post implementation) eliminate the need for IWS?

 

 

Good quality control processes and procedures are important and should still be implemented and followed even when security systems are present.
On the other hand, just as no one will say that good development processes and procedures can remove the need for web application firewalls, tightening of quality control does not remove the need for a information leakage system for web servers.
From our research, there are 4 main causes of information leakage from web servers:

a. compromised web servers
b. web application errors
c. server errors
d. sensitive documents left on web servers


At best, we expect good quality control can reduce the risks from server errors and sensitive documents left on web servers. Leakages due to compromised web servers or web application errors may not be that easily detected by quality control processes.

 

6

Where should I deploy IWS in my organization?

 

 

IWS is usually deployed “in front” of the web servers it is protecting, hence it is situated between any existing network firewall/web application firewalls/intrusion prevention systems and the web servers.

As IWS can be used to protect Internet-facing and Intranet-facing web servers, it can be located in the same network segments where these servers are located.

top

 

7

Will IWS affect overall network throughput?

 

 

IWS products are designed to sustain high throughput. With IWS running in interception mode, user experience can even be better due to the high performance proxy cache and load balancing features within IWS. With IWS in monitoring mode, there is no impact as IWS will situated in an out-of-band segment.

top

 

8

Does IWS support High Availability feature for mission critical system and support Load Balancing for high performance system?

 

 

Yes, IWS products support high availability and load balancing.

top

 

9

How should I deploy IWS if there are multiple web servers distributed over various locations in various countries?

 

 

As a best practice, it is recommended to deploy IWS nearer to where the web servers are located. Hence, in a distributed web server architecture with different access gateways to the Internet, multiple nodes of IWS should be deployed to the distributed sites while still remain centrally-managed via a secure web-based management console.

If all the distributed web servers shared a common gateway to the Internet, one can choose to deploy more advanced models of IWS, which are built to support very high throughput, near the common Internet gateway.

top

 

10

Why is iNFOTECT focussed on detecting leakages from web servers? Can I use IWS to monitor other servers eg. email / instant messaging servers?

 

 

IWS only provides information leakage protection for web servers. Depending on the market conditions, iNFOTECT will decide whether to develop a similar product for email servers and instant messaging servers.

top

     
Comparison Matrix

Static Code Analyzer

Web Application Firewall

Common DLP Products

iNFOTECT IWS
Leakage due to compromised or infected web servers

Not applicable

Not applicable when web server is already infected.

Not applicable, as they do not protect production web servers.

Protect against leakages even when web server is infected from internal sources.

Excellent tool to complement existing security systems.

Transmission of malicious codes to innocent visitors to your web site

Not applicable

Not applicable when web server is already infected.

Not applicable, as they do not protect production web servers.

Protect against further transmission of malicious codes to website visitors even when web server is infected.

Leakage due to application vulnerabilities

Focus is on vulnerabilities detection, though it can help to identify potential points for SQL injection attacks.

Unable to detect leakages, such as revealing too much information beyond what is required.

Focus is on preventing malicious requests that may result in leakage.

Has good protection against leakage of credit card numbers, but ineffective if information is stored in PDF or Office documents.

No protection against leakage from normal HTTP requests to vulnerable applications.

Focus is on preventing leakage from trusted LAN or user endpoints.

They do not protect leakage from web servers.

Identify leakages for any programming loopholes, regardless of complexity of workflow or document formats.

Excellent tool to complement QA process to identify leakage from applications before cutting over to production

Leakage due to server errors or misconfiguration

Not capable.

Can block common misconfiguration such as directory listing or access to sensitive configuration files.

No protection against source code leakage from malfunctioned application server or verbose debug messages.

Not applicable, as they do not protect production web servers.

Identify leakages for any server error or misconfiguration.

Excellent tool to complement change management process to verify changes to production do not result in leakage.

Leakage due to backup files left on web servers

Not capable.

Some may come with ability to identify backup files with duplicated file names

Can prevent access to backup files by allowing only acceptable file extensions in HTTP requests.

Not useful if the backup files are using acceptable file extensions.

Not applicable, as they do not protect production web servers.

Identify leakages for any backup file, regardless of extensions or file names.

Excellent tool to complement change management process to verify changes to production do not result in leakage.

Leakage due to malicious or accidental uploading

Not capable.

Can block common document extensions, such as CSV and SQL files.

No protection against leakage from allowed extensions, such as HTML, PDF or DOC files.

Not applicable, as they do not protect production web servers.

Identify leakages for any document extensions.

Can also detect if published content is non-decipherable for further investigation.

Excellent tool to complement change management process to verify changes to production do not result in leakage.

Public disclosure of defaced / hacked web server

Not capable.

Not all are capable.

Not applicable, as they do not detect web defacement.

Prevent public disclosure of defaced or hacked web server.

Excellent to reduce impact of attacks, such as avoiding reputation risks.

Infection of innocent visitors to your compromised web site

Not capable.

Not all are capable.

Not applicable, as they do not detect malicious web attacks.

Prevent public disclosure of malicious content from compromised web sites. Malicious content includes malicious iframes, XSS, obfuscated Javascript, malicious HTML5 and etc.

Excellent to reduce impact of attacks, such as avoiding reputation risks.