“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.

Vegas for ETA, onward to TRISC!!

I’m excited for this next week of travel- the Electronic Transactions Association is hosting their annual expo in Las Vegas this week. I was there last year, this is a conference focused on the true payment industry (read: not a whole lot of security folks- these are the banks and payment technology organizations)

The PCI Security Standards Council will be meeting to discuss the upcoming PCI Quality Assurance Program, as well as the content and timeframes around the Payment Application Data Security Standard (PA-DSS). It will be a great time to reconnect with friends at the Payment Brands, while discussing the upcoming PCI-DSS update, as well as the guidance language clarifying Requirement 6.6.

Many of my clients and peers are eagerly awaiting the release of some of this guidance, I certainly look forward to hearing guidance from the Council on the spirit and intended outcomes of these updates!

I have an evil 6 A.M. departure from Vegas for meetings in Dallas, TX on Thursday and Fort Worth on Friday. I have a lazy weekend of riding planned before rushing off to join RSnake in San Antonio, Texas for TRISC ( the Texas Regional Infrastructure Security Conference.) I will be presenting a variation on Jer’s Website Vulnerability Statistics talk, and looking forward to Robert’s “Why I don’t use web-app scanners … all the time” talk.

If you’re in the neighborhood, come support the conference!

RSA Reflections

RSA put on another great conference last week in San Francisco. For the uninitiated, the RSA Security Conference is the premier corporate security conference with attendance to the tune of seventeen thousand people. It is a fantastic place to see what’s hot, what technologies are up-and-coming (they tend to have the little booths *not* in the middle of the show floor), as well as putting faces with names.

RSA is as much about the business side of marketing, research, and innovation as it is about professional networking. The after hours event did San Francisco justice- the food and drinks served in the vendor receptions (and parties) were absolutely stellar.

I was on ‘booth babe’ patrol (err, duty) and enjoyed a continual stream of collegues, teammates, friends, and some very impressive prospects and inquisitors. There was an exhausting volume of traffic at our booth, the questions and discussion only confirmed- Application Security is certainly no longer academic, and corporations concerns are growing.

Walking the conference floor before the show was intimidating, giant booths, colors, displays, screens, squawking wireless microphones, and people racing around making final adjustmensts for the show. Even after the show was live, I think Walt’s Blog probably had the best description of the expo floor, “The expo floor is like Blade Runner meets the Cairo souk in a train wreck.” I was struck by a couple things before the show started:

1) What’s up with all the booths playing with a Wii and/or Rock Band??

2) Every other booth with PCI solutions in a box?!

3) ILP and DLP are still gaining traction. (will rant on this in a later post)

As a QSA, I was stuck that so many organizations could ‘sell’ PCI compliance, I wonder how much confusion those displays and sales pitches create for those being audited. There were some fantastic thoughts and discussion on vendors using PCI and compliance for marketing leverage, Rob and Walt had similar experiences. Michael Dahn has posted a great reflective piece on his RSA vendor experience, and brings an elegance to those lessons learned.

I am convinced PCI is going to maintain velocity and buzz for the next year, it certainly has given a much needed boost in putting security on corporate radar.