Web Application Scanning

Web Application Scanning

KNOW MORE ABOUT Web Application Scanning

What is Web Application Scanning

A Web Application Scanner is an automated security program that searches for software vulnerabilities within Web applications. A Web application scanner first crawls the entire website, analyzing in-depth each file it finds, and displaying the entire website structure. After this discovery stage, it performs an automatic audit for common security vulnerabilities by launching a series of Web attacks. Web application scanners check for vulnerabilities on the Web server, proxy server, Web application server and even on other Web services. Unlike source code scanners, web application scanners don’t have access to the source code and therefore detect vulnerabilities by actually performing attacks.

In a vulnerability assessment we scan a web application to identify anything an attacker could potentially use against us (some assessments also look for compliance/configuration/standards issues, but the main goal in a VA is security). We can do this with a tool, service, or combination.
A web application vulnerability assessment is very different than a general vulnerability assessment where we focus on networks and hosts. In those we scan ports, connect to services, and use other techniques to gather information
revealing the patch levels, configurations, and potential exposures of our infrastructure. Even “standard” web applications are essentially custom; we need to dig a little deeper, examine application function and logic, and use more customized assessments to determine if a web application is vulnerable. With so much custom code and
implementation, we have to rely less on known patch levels and configurations, and more on actually banging away at
the application and testing attack pathways. Custom code means custom vulnerabilities.

Automated tools help the user making sure the whole website is properly crawled, and that no input or parameter is left unchecked.  Automated web vulnerability scanners also help in finding a high percentage of the technical vulnerabilities, and give you a very good overview of the website’s structure, and security status.  Thanks to automated scanners, you can have a better overview and understanding of the target website, which eases the manual penetration process.

  • Compliance: Like it or not, security controls are mandated by government regulation, industry standards & requirements, and contractual agreements. We like to break compliance into three separate justifications — industry or regulatory mandated controls (PCI web application security requirements), non-mandated controls that avoid other
    compliance violations (data protection to avoid breach disclosure), and investments to reduce the costs of compliance
    (lower audit costs or TCO). The average organization uses all three factors to gauge web application security
  • Fraud Reduction: Depending on your ability to accurately measure fraud, it can be a powerful driver and justification for
    security investments. In some cases you can directly measure fraud rates and show how they can be reduced with
    specific security investments. Keep in mind that you may not have the right infrastructure to detect and measure this
    fraud in the first place, which might itself provide sufficient justification. Penetration tests are also useful for justifying
    investments to reduce fraud — a test may show previously unknown avenues for exploitation that could be under active
    attack or open to future attack. You can use the penetration test to estimate potential fraud and map that to security
    controls to reduce losses to acceptable levels.
  • Cost Savings: As we mentioned in the compliance section, some web application security controls can reduce the cost of compliance (particularly audit costs), but there are additional opportunities for savings. Using web application security tools and processes through development and maintenance can reduce the need for and costs of manual processes or controls to remediate software defects and flaws, and may help create general efficiency improvements. We can also calculate cost savings from incident reduction, including incident response and recovery costs.
  • Availability: When dealing with web applications, we look at both total availability (uptime), and service availability (loss
    of part of the application due to attack or to repair a defect). For example, while it’s somewhat rare to see a complete site outage due to a web application security issue (although it definitely happens), it’s not unusual to see an outage of a payment system or other functionality. We also see cases where due to active attack a site needs to shut down some of its own services to protect users, even if the attack didn’t break the services directly.
  • User Protection: While this isn’t quantifiable to a dollar amount, a major justification for investment in web security is to
    protect users from being compromised by their trust in you (yes, this has reputation implications, but we cannot precisely
    quantify them). Attackers frequently compromise trusted sites not to steal from that site, but to use it to attack the site’s
    users. Even if you aren’t concerned with fraud resulting in direct losses to your organization, it’s a problem if your web
    application is used to defraud your users. Most organization derive value or direct revenue from customer data, and there
    is an implied custodial duty to protect the information you have gathered and use.
  • Reputation Protection: While many models attempt to quantify a company’s reputation and potential losses due to
    reputation damage, the reality is all those models are bunk — there is no accurate way to measure the potential losses associated with a successful attack. Despite surveys indicating users switch to competitors if you lose their information, or that you’ll lose future business, real world reports show that user behavior rarely aligns with survey responses. For example, TJX was the largest retail breach notification in history, yet sales went up after the widely reported incident. But just because we can’t quantify reputation damage doesn’t mean it isn’t an important factor in justifying web application security. Just ask yourself (or management) how important that application is to the public image of your organization, and how willing you or they are to accept the risk of losses ranging from defacement to lost customer information to downtime. User, investor, and partner trust in your company and services is complicated, and while it does not track directly with site security, trust remains important to the overall value of the business.
  • Breach Notification Costs: Aside from fraud, we also see direct losses associated with breach notifications (if sensitive information is involved). Ignore all the fluffy reputation/lost business/market value estimates and focus on the hard dollar costs of making a list, sending out notifications, and staffing the call center for customer inquiries. You might also factor in the cost of credit monitoring, if you’d offer that to your customers.

    You will know which combination of these works best for you based on your own organizational needs and management priorities, but the key takeaway should be that you likely need to mix quantitative and qualitative assessments to prioritize your investments. If you’re dealing with private information (financial/retail/healthcare), compliance drivers and breach notification mixed with cost savings are your best option. For general web services user protection & reputation, fraud reduction and availability are likely at the top of your list. And let’s not forget that many of these justifications are just as relevant for internal applications. Whatever your application, there is no shortage of business (as opposed to technical) reasons to invest in web application security.