[Owasp-pci-project] More clarification on separation

[McGovern, James F (HTSC, IT)]

 Several thoughts:

1. I bet if you were to walk into a large enterprise and ask them if a
WAF is an application, they would give you a deer in the headlight
reaction. There are things that folks think of as application and things
they think of as infrastructure (historically speaking) and I think PCI
draws the line somewhat differently. Helping folks make the mental shift
is a good thing.

2. So, if I exposed an application through SSL VPN to a partner, is this
considered public facing? What about other intermediary type approaches?

3. Can we define responsibilities around the notion of an application
owner more strictly? In most shops, this is a financial construct and
maybe SoX but definetely not security-minded.

-----Original Message-----
From: Trey Ford [mailto:ford.trey at gmail.com] 
Sent: Tuesday, June 02, 2009 12:34 PM
To: McGovern, James F (HTSC, IT)
Cc: Owasp-pci-project at lists.owasp.org
Subject: Re: [Owasp-pci-project] More clarification on separation

I spent some time pondering this- I see two different questions here
that need solving:
1) What applications fall into scope?
2) How is an application defined?

~~~~~~~~~~
1) What applications fall into scope?
~~~~~~~~~~
An obvious first micro project is building an OWASP stance on how to
define the web application scope for PCI work.

We need to determine the 'right questions to ask,' stuff like:

1) What, from an application security perspective, will need to be
included in a PCI audit?
1a) Would the penetration testing scope reflect all systems that offer
attack vectors to that application actually (storing / processing /
transmitting) Cardholder Data (CHD)?
1b) These application WILL vary based upon which requirements we're
talking about. Requirement 6.6 speaks to 'public facing web
applications' while 11.3.2 calls for 'external and internal penetration
testing'.

2) Based upon network architecture, what web applications will be
included in scope- what systems are in the same 'logical network
security realm) (like it or not, the QSA will start with network
architecture- we need to help them see past firewalls)

3) What AUDIT CHECKPOINTS can be used to determine relationships that
will add other web applications to scope?
(read: non appsec experts can look for or take samples for (is this even
possible!?)
3a) DOM relationships
3b) crossdomain.xml
3n) ...

N) ...
> I took a swipe at some of this stuff in that playbook for 6.6 I built,
we really need to build a scoping playbook.

~~~~~~~~~~
2) How is an application defined?
~~~~~~~~~~
This is a favorite debate in my line of work, and PCI does not have have
a formal definition.  Given that the OWASP community is considered a
circle of application security experts and we're having this discussion
is noteworthy.  This isn't clear or straight forward, and may be as much
philosophical as it is tactical.  Questions like this underscore how a
compliance body like PCI may be interested in our support and guidance
on issues like this.

Applications can be defined in so many ways- it could be anything from a
couple elegant lines of code, and range in definition the other other
extreme of the entirety of a portal (as in, not just the framework,
authentication structure, and management UI, but including absolutely
EVERY application inside the portal!).

Further greying the boundaries of this discussion will be dependencies
or associations such as cookie or DOM relationships, the crossdomain.xml
implicating others, dependencies on supporting systems such as LDAP or
SSO, shared databases and web services, and business logic layers that
are operating in a less than exclusive manner with 'the in-scope'
application.  (Where I work, we laugh about how, for the most part, if
you call it an application, it is probably an
application.)

I think that ultimately this becomes a function of architecture and
philosophy- from a testing standpoint we have a pretty simple
approach- whatever we can find that gives us an attack vector, anything
that may weaken the security of the environment.  I submit this approach
while expedient for testers does not effectively support the
(remediation/security/development) teams.  I am willing to bet that the
application owners know who is responsible for what.  There may be
wisdom in mapping back to the application boundaries as imposed by the
(owners/architects).  This imposes a little more leg work up front, but
will allow the testing and remediation cycle to scale.

In the long run, (auditors/testers) can use application boundaries as
defined by the organization handing cardholder data (CHD).  Regardless
of what they call an application, the (auditor/tester) will dump
everything implicated by our PCI Application Scoping Playbook into the
scope of the PCI assessment.

~Trey

On Mon, Jun 1, 2009 at 10:54 AM, McGovern, James F (HTSC, IT)
<James.McGovern at thehartford.com> wrote:
> If internal resources are being used, they should be organizationally 
> separate from the management of the application being tested.
>
> So, how can we measure? Is it about reporting to the same boss? How 
> many bosses away? What about dotted-line?
>
> ************************************************************
> This communication, including attachments, is for the exclusive use of

> addressee and may contain proprietary, confidential and/or privileged 
> information.  If you are not the intended recipient, any use, copying,

> disclosure, dissemination or distribution is strictly prohibited.  If 
> you are not the intended recipient, please notify the sender 
> immediately by return e-mail, delete this communication and destroy
all copies.
> ************************************************************
>
> _______________________________________________
> Owasp-pci-project mailing list
> Owasp-pci-project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-pci-project
>
>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information.  If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited.  If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************