“What is a Web-Facing Application?”

I hear this question often, “In PCI Requirement 6.6, what is a Web-Facing Application?” When discussing web applications in the enterprise, which applications are relevant to Requirement 6.6? Obviously we’re counting the e-commerce web application where we sell widgets and accept credit cards for payment, but what about your business partner portal? What about the HR application used only by employees? How about that application hosted on your intranet? This discussion is about how I have approached and classified web applications during my onsite PCI audits.

The notion of what applications may be ‘Web-Facing’ is a function of where application requests originate. Regardless of where a web application server is physically or logically located on a corporate network, the theory of what is internet accessible is very much a function of how or where a request comes from.

The term ‘Web-Facing’ can be interpreted a couple of ways, let’s unravel how a web application may be classified, and how this can affect our security strategy:

• Web Applications that are Visible or Accessible from the Internet
  This is the broadest and most widely accepted interpretation of a ‘web-facing’ application. This is a web application that is designed and delivered with the intent of access by individuals or organizations over the public internet.

  A key thought is that this type of application would exposed to the broadest base of potential users, whether they are ‘friendly’ or ‘malicious’. These applications will know the least about their potential users.

  These applications are ABSOLUTELY web-facing, those involving credit cards are IN SCOPE unless proven otherwise.

• Outward Facing Web Applications (Business to Business access, or accessible to a limited scope)
  This would be an application accessible to a restricted set of specific users or users of a controlled network. Requests to an ‘Outward Facing’ application would be limited by source- a partner network (coming from a semi-trusted network), over a VPN (already authenticated), or some other presumably identified non-internal source.

  The idea of an ‘Outward Facing’ application is this notion that requests are coming from a semi-known source. An unsafe assumption, but the idea here is to narrow the source of requests- think of these as semi-public applications.

  Outward Facing applications involving credit cards will be IN SCOPE unless proven otherwise.

• Intranet Web Applications (generally intended for exclusive access on an internal, corporate network)
  These are classic ‘internal’ applications. Think about a corporate intranet- some internal web applications for travel planning, requisitioning time off or office supplies, benefits, or any other web application intended exclusively for internal corporate use only.

  *IF* there are intranet applications involving credit cards, they *MAY* be in scope.

As with any systems or applications handling credit card data, precautions and protective measures must be reflect the vulnerability of the system and the exposure to attack. For the record, internet-based hacking of internal (non-public) applications is happening in the wild (read Jeremiah’s post – Intranet hack targeting AT&T 2Wire DSL modems.) Does this mean your intranet application is at risk? Maybe, maybe not. What *is* noteworthy is that non-public applications are accessible through CSRF- these attacks will continue to evolve.

What is most important is the discussion of due care. All organizations have budgets, and most likely several applications to assess and protect. Taking measures to organize applications based upon data sensitivity, exposure or likelihood of attack, and what is being done.

Bottom line– does PCI require the testing of internal or intranet web applications? I’m not sure this is easily defined. My encouragement to the asking organization is to at least get an idea of how solid or vulnerable an application is- the network perimeter no longer creates the safe harbor we once enjoyed.

Beyond PCI, web applications will soon be completely ubiquitous. We probably won’t be calling them web applications for much longer. Authentication mechanisms are getting stronger, and applications are becoming more accessible (does your bank allow for balance checks from your cell phone?).

My hope is that the bar will be raised, that enterprise risk teams will acknowledge the accessibility of web applications, and focus on identifying vulnerabilities for all applications- and managing risks based not upon vulnerabilities in chosen applications, but as a function of threat, severity, and relative costs.

Tags: Compliance, PCI 6.6, Uncategorized, Web-Facing