Some Misconceptions

1. My website is such a small fish in the Internet ocean that no respectable hacker would lower himself to even take a look.

Hackers are usually running automated scripts or tools to look for websites with vulnerbilities. Whatever you do, do not believe the size of the ocean makes a difference to the hackers. The sharks have you covered, however small you might be.

The hackers might turn your site without your knowledge into a malware distribution point, a Command and Control point of a botnet army, or a XSS farm.

2. You can't get to our web application data when we have system secured by intrusion systems.

Web applications provide an electronic interface to data. Network firewalls such as the IDS (intrusion detection system) and the IPS (intrusion prevention system) cannot prevent web application attacks.

Network firewalls check the data traffic to the web server through the signatures and protocols of the user queries to the server not the intent of the request body being sent.  Only web application security solutions which filter all queries and data at the access point to web applications on multiple levels – both statically and dynamically – provide proactive protection against so far unknown attacks.  

3. Web application security must already be ensured during development.

Most of today's web developers are not formally trained in web security. Security measures are not built into the design. Developers can only take into account those risks that are known at the time of application development. However, by the time a project is deployed, it may face attacks which were still unknown during development. 

4. Our web applications are secure because we are compliant with the Payment Card Industry Data Security Standard (PCI DSS).

PCI DSS is a secure standard for transferring credit card info between the merchants and the credit card issuers.  This security standard is only a minimum standard of due care. If organizations do not secure their whole environments above and beyond  PCI DSS, the compliance process does not reliably secure your web applications.

5. Our web applications are secure because we have deployed commercial web security product(s).

This response is a common misconception in security. Just because a security vendor’s web site or product collateral says that the product will make your web application more secure does not in fact make it so. Security products, just like the applications they are protecting, have flaws if used incorrectly.  Security products you deploy need to be update in all aspects of security.

6. Our web applications are secure because we use SSL (Secure Socket Layer).

An e-commerce site is not automatically secure just because it displays a SSL image seal. The SSL certificate purchased from a reputable certificate authority (CA) only provides an encrypted data transmission channel to mitigate network sniffing (clear text) and website spoofing (phishing) attack.The use of SSL does not prevent direct attacks on the web application itself. In fact, many attackers prefer to target SSL-enabled web applications because the encrypted channel can help them hide their activities from other network-monitoring devices.

7. Our web applications are secure because we have alerts demonstrating that we blocked web attacks.

Evidence of blocked attack attempts is good but is not enough. Providing evidence of blocked attacks is a useful metric, but organizations really need to know if any successful attacks occurred.  More general indicators of the effectiveness of security detection accuracy should include:
    • Attacks detected (true positive): a number (#) and a percentage (%) of the total web transactions per day. 
    • Missed attacks (false negative): a number (#) and a percentage (%) of the missed attacks of the total web general indicator of the effectiveness of security detection accuracy transactions per day. 
    • Blocked traffic (false positive): a number (#) and a percentage (%) of the blocked traffic of t he total web transactions per day. Blocking legitimate customer traffic is disruptive in nature and may mean missed revenue. 
    • Attack detection failure rate: should be represented as a percentage (%) derived by adding false negatives and false positives and then dividing by true positives. 
8. Our web applications are secure because we have not identified any abnormal behavior.

Most websites use their host web server’s logging mechanisms to log the requests and response codes, which provides insufficient logging detail. 
    • Hacker attacks on web applications often don’t leave any tracks and remain undetected, because the data is not deleted nor changed – all applications continue to function normally and no system accesses are recorded.
    • Electronic data theft cannot normally be differentiated from normal application access. Consequently, organizations will not know whether someone had access to sensitive data via a vulnerability for a long time already. 
    • A 500 Internal Server Error status code does not indicate what causes the error, because the parameter data sent to the application in the POST requests is in the request body rather than in a QUERY_STRING value that can be logged by web server.
    • The log does not contain information on what data returned within the outbound HTTP response. The log does not include important request header information such as cookies, POST request bodies, or any logging of outbound data. Without these clues, we don't know what data the hacker actually stole. The lack of robust and comprehensive HTTP audit logs is one of the main reasons why organizations cannot conduct proper incident response for web-related incidents.
    • Using only alert-centric events as indicators of potential incidents about known malicious behaviors would not secure web applications, because new or stealthy attack methods emerge constantly.