[Owasp-standards] PCI-WASS constraints and goals

owasp-standards-admin at lists.sourceforge.net owasp-standards-admin at lists.sourceforge.net
Thu Dec 22 02:08:15 EST 2005


Hi
 
I see 2 threads here:
 
1) content driven
I see an interesting link with the "Testing" Project.
If the requirements (=standard) are clearly defined and should be
"testable", the testing project should come up with the testing
approach?
 
2) project management driven
 
What I propose is to put together a first draft of a project charter (I
already posted a similar suggestion to the T10 list):
 
In the project charter we define the goals of what we want to do:
clear deliverables (=WHAT)
clear approach (=HOW)
clear workpackages (including timing=milestones and involved people, the
WHO and WHEN)
 
The project charter TOC would go like:
1. Management summary
2. Introduction (with business case, including reasons, costs and
benefits)
3. Purpose
4. Background
5. Project Definition (including Objectives, Approach and Scope)
6. Deliverables
7. Constraints, Assumptions and Prerequisites
8. Interfaces (very important: should we include VISA/MC in project?)
9. Quality
10. Project Controls and Risks
11. Reporting
12. Project Planning
 
I am willing to put together a first Word draft v0_1, but I will need
input on the above TOC.
 
We can then later on measure the success of the standards project
against the charter.
 
Full disclosure: Since achieving Prince2 Practitioner certification (you
can compare it with PMI project mgr) I drive my colleagues nuts with
this project mgmt stuff.
 
regards,
 
Seba
Belgian OWASP Chapter Leader

________________________________

	From: owasp-standards-admin at lists.sourceforge.net
[mailto:owasp-standards-admin at lists.sourceforge.net] 
	Sent: woensdag 21 december 2005 23:44
	To: owasp-standards at lists.sourceforge.net
	Subject: RE: [Owasp-standards] PCI-WASS constraints and goals
	
	

	Mike,

	Sounds great I agree about keeping this project high-level and
having a testable list of requirements would be helpful I think to
anyone building applications around credit card processing etc.

	So where is the project up to?, Do you need people to get
involved and how?

	Is someone starting to enhance the strawman document and
assigning different taks?

	 

	I suppose what I would like to see is timeframes and
goals/responsibilities for the project. EG lets get the project rolling.


	I think talking about the issues definitely needs to happen
though I would like to see something starting to happen from enhancing
and drafting a format.

	 

	I am more then keen to get involved in the project if the
project team wishes..

	(Btw who is the project team?)

	 

	Regards

	Justin

	 

	
________________________________


	From: owasp-standards-admin at lists.sourceforge.net
[mailto:owasp-standards-admin at lists.sourceforge.net] 
	Sent: Wednesday, 21 December 2005 10:25 PM
	To: owasp-standards at lists.sourceforge.net
	Subject: [Owasp-standards] PCI-WASS constraints and goals

	 

	It looks like we are getting a good number of subscribers to
this list, and more importantly some great comments and feedback.  I'd
like to thank everyone for their contributions and involvement, and hope
that this project continues in this way. 

	 

	Looking at some of the posting thus far, I think I'd like to
step in with a new post and clarify some of the constraints and goals of
this project.  I've mentioned them a bit in some replies to other posts,
but having a fresh post for new subscribers to see, and to give a place
for existing subscribers to comment on the entire project as a whole. 

	 

	First off, although I've mentioned PCI in the project title and
description, the goal is for OWASP to recommend what we arrive at at the
end of this project to PCI as a replacement for the "OWASP Top Ten"
currently in place in the existing requirements.  However, my intention
is to try and develop this standard to be as stand-alone as possible so
many other people can benefit from it, not just those that transmit
credit card data (many many other web apps transmit "sensitive" data,
and these should be able to benefit from it as well).  The only reason
that I've mentioned PCI to start with is that they already have a very
good set of requirements (but network, not web-app focused), in a nice
structured format, and are closely matched with the other goal of this
project - why go re-inventing the wheel if there already is a public
document that fits may of the intentions of the project :) 

	 

	Which brings us on to the other goal.  The aim of this project
is to generate a list of *testable* requirements that a *minimally*
secure web application should pass.  I'm explicitly calling out
"minimal" as there's certainly some best-practices and technologies that
go to improve the security of an application, but we shouldn't try to
prescribe any of them.  We are aiming at a baseline that hopefully will
change over the years.   Also, this project is focused at the *testing*
side of SDLC - although there's been some great comments about
architecture and defence-in-depth, these things are very difficult to
test for, especially in a black-box methodology (which most
testing/audits are carried in).  So I'd like to try and stay focused on
that. 

	 

	Finally, bear in mind that if we are successful here, a lot of
interested parties may want to utilize such a requirements checklist.
This is a double-edged sword.  On the one hand we have the goal of
security - ensuring that the standard is meaningful and does actually
protect web applications.  In contrast, if the requirements are
wholesale adopted, they have to be appropriate for *existing*
applications - we should call-out the impact companies and vendors may
have in complying, especially with legacy applications.  So, this isn't
a blue-sky project, and any potential problems should be discussed here
as well (for example, one of my colleagues pointed out the number of
banks that still use 4-digit PIN's for passwords - this could be a major
hurdle and we should at least talk about other such issues). 

	 

	Although we are initially discussing the requirements, and what
they consist of, any post on how we should test for them or any other
off-topic (but related) posts are very welcome.

	 

	Well, once again, thanks for all that have taken a look, or
contributed in some way.  I look forward to seeing more subscribers, and
lively discussion :)

	 

	Cheers,

	Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.owasp.org/pipermail/owasp-standards/attachments/20051222/d2f83385/attachment.html 


More information about the Owasp-standards mailing list