[Owasp-leaders] Feedback on Potential New OWASP Project

Wed Jan 20 11:35:05 EST 2010

2. My interpretation of adaptive access is that your access depends on how
you connect. Are you at your desk on the intranet? Or via a VPN connection?
Or on your iPhone?  Or in a hostile foreign country?  Carrier pigeon?  etc.
You might require stronger authentication or you might limit access
depending on the context.  Adaptation might not only  be limited to the
user, you might adapt access based on other context, such as time of day,
current security alert level, weather, etc.  If you're thinking of doing
this, remember that implementing the contextual information and the actual
access checks isn't the hard part. The difficulty is managing all the data
and rules in a scalable way.

3. I really like the idea of a "Visibility API".  Applications should have
interfaces that 1) report on security configuration, 2) identify possible
misconfiguration, and 3) possibly even enable security testing.  This really
goes right to the heart of the problem with applications security - nobody
has any idea how secure or insecure the apps they're using are.  Ivan
Ristic's SSL Labs <https://www.ssllabs.com/ssldb/analyze.html?d=owasp.org>
project is doing a fantastic job at making security visible.  But wouldn't
it be easier and better to report this from the inside?  Why shouldn't an
application provide it's own "Software
<http://www.aspectsecurity.com/documents/Aspect_HCSS_Brief.ppt>  Facts"
label?

--Jeff

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Sethi, Rohit
Sent: Wednesday, January 20, 2010 9:53 AM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project

1.      James, I like the idea of adding more specific guidance around
database interaction. We'll probably have to spend time investigating this
before adding it into the next release. As Dinis said, let's start with a
primary focus on presentation tier and then move forward if we're successful
in getting the manifesto adopted

2.      If I understand your comment about adaptive access, I think this is
referring to something along the lines of IP geolocation and tying  a
particular session to a region (e.g. country). This warrants further
investigation as well. Does anyone know of any frameworks that provide this
already?

3.      I think this falls outside the scope of the manifesto

Rohit Sethi

Director, Professional Services

Security Compass

http://www.securitycompass.com <http://www.securitycompass.com/> 

Direct : 888-777-2211 ext. 102

Mobile: 732.546.4473

Twitter: rksethi

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of McGovern, James
F. (eBusiness)
Sent: Tuesday, January 19, 2010 9:36 AM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project

Still noodling enterprisey developer behavior and came across a few other
scenarios:

1. I don't think we should focus solely on the MVC parts of the framework.
Much of the guidance to date regarding access and persistence to data is
also done insecureley. For example, if a developer decides to use Hibernate,
should a DBA still do DB security? of course, but the challenge here is one
of moving things higher up into the application. Taking this thought one
step deeper, what should we do with the growing popularity of the
Entity-Attribute-Value (EAV) style of DBs being pushed by cloud vendors,
Azure and even used in many SAAS implementations. Applying grant/revoke to
third-normal form databases no longer applies and requires a framework in
the app to get the right security model.

2. How should a framework thing about adaptive access? For example, I enter
my credentials on my bank site and I am proven that my credentials are a
directory entry, but I may be accessing from a different computer, possibly
in another country.

3. Let's look at the reporting side of the equation and ignore runtime for a
moment. We have all heard of SoX, etc. Wouldn't an auditor love a way to say
enumerate all the "roles" an application supports without reading code?
Could things that auditors care about be made discoverable? Its one thing to
enumerate a role, but how can you define which roles are in conflict (e.g.
accounts receivable vs accounts payable) and then apply the proper
enforcement

  _____  

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Sethi, Rohit
Sent: Monday, January 18, 2010 11:22 PM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project

James, thanks for the continued comments. We can certainly include #1 in the
next draft.

Multi-tenancy is a hot topic today. With respect to application frameworks,
I believe the most fundamental security concerns boils down to horizontal
privilege escalation. In light of some of the suggestion from Paco Hope on
SC-L, we're thinking of narrowing rather the scope of what we're making
recommendations on for this round. I'd like to include some built-in
mechanism for horizontal access control but would rather see it in practice
first before recommending it broadly.

Point 3 is very interesting. Deep linking is sometimes a genuine application
need. That said, some web application frameworks provide page flow
capabilities; one model would be to add optional page flow enforcement by
tracking the user's navigation history on the server and allowing or denying
access to a given page based on the page the user is currently on. For
example, a user is only allowed to access Page 3 after coming from page 2;
direct access after page 1 or any other page would result in authorization
failure. As I type this I'm pretty sure I've seen it before but can't
remember where off-hand. Does anyone know of a framework that does this
automatically? 

As for the entitlements piece, it looks like another aspect of
authorization. Should user jmcgovern have access to policy XYZ742 and not
ABC153? That depends - should users of the role 'OWASP' have access to that
policy? Should only user jmcgovern have access to that policy? Should all
users who have purchased a certain coverage have access to that policy? I
believe that a framework can help developers by providing ubiquitous access
to authorization-relevant data, but developers ultimately need to determine
authorization criteria on a case by case basis. 

4 & 5 sit in that nebulous area between reliability and availability. We can
certainly make an argument that these are relevant to security, but I'm
worried that they only begin to scratch the surface of a much larger domain.
We could probably throw things like inefficient garbage collection in the
same grouping.  For the first cut, we'll probably stay away from all but the
most obvious Denial of Service protections and re-evaluate what goes into
the next cut.

We included file upload in the last version, but we need to get more
specific about it. Configuring ICAP for virus scanning seems to be a
generally reasonable requirement; how often is it actually done by an
application server rather than a caching or proxy server?

Cheers,

Rohit Sethi

Director, Professional Services

Security Compass

http://www.securitycompass.com <http://www.securitycompass.com/> 

Direct : 888-777-2211 ext. 102

Mobile: 732.546.4473

Twitter: rksethi

From: owasp-leaders-bounces at lists.owasp.org
[mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of McGovern, James
F. (eBusiness)
Sent: Friday, January 15, 2010 9:19 AM
To: owasp-leaders at lists.owasp.org
Subject: Re: [Owasp-leaders] Feedback on Potential New OWASP Project

Additional feedback:

1. More enterprisey comments: First, I am probably blissfully ignorant of
certain open publishing rules, but I firmly believe that all papers should
contain the BIOs of the folks who have written them. I tend to like the
templates for documents published by Gartner more than the IEEE stuff.

2. Can we apply some analysis to how a framework should handle multitenancy
and its security considerations? For example, Liferay Enterprise Portal, eXO
and others support multitenancy but have slightly different takes. Which is
the better model going forward from a security perspective? Used as
examples, focus on model not analysis of product. This however challenges
somewhat what the definition/granuality of framework we should target.

3. A developer asked me an interesting question today in which I could only
offer sage wisdom. They wanted to understand how a framework should handle
deep linking. I decomposed this question into two thoughts of which the
first is whether there is control on doing such a thing. You may not want
deep linking where you want to control flow and at other times, you want the
exact opposite. Control flow is good to prevent against business logic
flaws, etc. The second part of the question is how to think about
entitlements around data. For example, if you saw the link:
http://www.aetna.com/medical/getmyrecord.jsp?policy=XYZ742, the obvious
stuff like parameter tampering comes to mind, but how do we associate the
given subject with this policy as part of a validation model.

4. Are we fans that web application frameworks may want to provide
capability for graceful degradation, quiescing traffic or having a way of
making certain portions of an application unavailable based on a schedule or
other trigger? On one of our portals, I know we have some functions where we
can support 10K concurrent where others if we had 100 users hitting
simultaneously, things would break bad. What should a framework do in this
regard?

5. How does a framework work in a clustered environment? Should every object
be required to implement serializable or things crash? 

6. If you hava a framework that builds XML on the fly, does it provide
special protections for things like credit card?

************************************************************
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.
************************************************************
************************************************************
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.
************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-leaders/attachments/20100120/633db6d7/attachment-0001.html 