August 2016 SAFE Newsletter
By Shivani Malik
The Forgotten Scan: Web Application Vulnerability Scanning
Every financial organization, in accordance with regulatory principles, implements vulnerability scanning to assist in protecting highly confidential consumer information, like social security numbers and account information from potential malicious attackers. But does the financial organization have the correct types of vulnerability scans in place based on the financial organizations risk outlook and business model?
Most community financial institution’s and small to medium sized financial firms rely heavily on third party providers to manage their networks so they can retain focus on their business, including a reliance on vulnerability scanning and remediation. The financial organization is ultimately responsible for protecting confidential consumer information therefore it is important that vulnerability scans are conducted, but more importantly based on the risk profile and business model of the financial organization, it needs to ensure that the correct vulnerability scans are in place.
Most financial organizations implement network-based vulnerability scans, which can detect network attacks such as DDoS attacks and protocol spoofing, as well as unauthorized systems on the network or insecure connections to business partners. Additionally, most financial organizations implement host based vulnerability scans that identify security risks that result from internal misuse or hackers using a compromised system. Due to community financial institutions and small to medium sized financial firms’ reliance on third party web based applications, the rise of mobile banking applications, and the use of the a financial organization’s own internal websites, it is important that these financial organizations consider implementing robust web application vulnerability scans to further protect the organization's network.
Web application vulnerability scans are necessary because attackers are altering code on regular and mobile websites utilizing this as a back door to gain more access to the network and potentially confidential consumer information. Internal websites marked as safe are a prime target for this type of malicious behavior. Attackers compromise the financial organization’s website, place malicious code on a certain page, and then send spear-phishing emails to a few employees. The majority of organizations whitelist their own website and therefore the employees blindly follow the internal link directly to the malicious code, giving the attacker an easily obtained backdoor to the financial organization’s network.
Furthermore, many financial organizations think by implementing two factor authentication, role based access, as well as change control and monitoring they have optimal protection. This is not the case. Many sophisticated attackers can utilize an area of a web page that does not require authentication and gain access to databases and/or files. The attacker will then change fields, say the deposit account number, in the database, thereby allowing for a transfer of funds into a fraudulent account. This change will go undetected because it was a direct modification of the database requiring no authentication.
The bottom line is: Websites that are seemingly innocuous may become entry points for damaging malicious activity so it is important that web application vulnerability scanning is implemented, and more importantly that it is actively managed and monitored.
Six Simple Steps to Implementing a Web Application Vulnerability Management System
Generally speaking there are six (6) simple steps to implement a robust web application vulnerability management system.
1. Track and Categorize Web Applications
The first step in building a robust web application vulnerability management system is to first identify allowable web applications. All other web applications should be blocked from use on the financial organizations network. Next you want to classify each of the identified web applications based on priority of importance for assessing any remediation activity.
2. Purchase a Web Application Scanning device.
When investigating web application scanning devices, a financial organization wants to ensure that the device can scan the web applications defined in step one. Purchasing a device that can only scan .com sites when the majority of the organization’s identified sites are .net would not serve a purpose. Furthermore, the device should be able to scan the specified types of authentication used within the web application, URL rewrite rules, and/or anti-cross site request forgery mechanisms.
3. Verify Vulnerabilities against Inventory
The web application vulnerability scanning devices should be configured correctly to eliminate false positives and improve detection of actual vulnerabilities. Incorrect configuration could lead to disastrous results.
4. Classify and rank risks
Remediating every type of vulnerability at the same time is impracticable. Prioritizing the order of remediation focusing on the most critical issues that affect your most important web applications first, and working your way to the lowest priority, will assist in ensuring increased protection.
5. Up-to-date Patching
In order for the vulnerability scanner to work at its optimal level, patches must be installed regularly and kept current.
6. Management and Monitoring
The configurations and logged activity from the device should be monitored and reviewed regularly to ensure continued protection based on the ever changing web application environment.
By implementing these six steps a financial organization can easily manage its web applications vulnerability management program.
Fill in the blank.
The three major types of vulnerability scans are:
1. Network-Based Vulnerability Scan; 2. Host Based Vulnerability Scans; 3. Web Application Vulnerability Scans
Information Security Tip of the Month:
Web application vulnerability scanning is an essential layer of protection for financial organizations in the wake of consumer facing mobile applications.