[OWASP-GUIDE] Full review observations

[Andrew van der Stock]

ISO 17799:

We should be aligning ourselves with known standards, as we ourselves
have no real standing in the standards bodies, and customers of mine
(who are consumers of security services) love hearing that they are
complying with standards. With some of my customers, it's the only way
they can justify a security spend.

ISO 17799 might not be freely available, but it is an international
standard, and you can freely participate in its being updated through
ISO right now. 

Actually, 17799 is a Code of Practice, but it's where the security
industry is at right now and therefore has additional weight over and
above just a code of practice. At my previous company, and my current
company, we treat it is a starting point as it's pretty lax. 

We should also choose Common Criteria over the 20+ year old Orange Book.
CC is open, and openly available. But it is not ISO 17799, which many
govt depts have to comply with. Also CC evaluations are extremely
expensive and don't usually prove very much due to the way you can
evaluate yourself. Taken in context, CC controls are useful, however:

The org:
http://www.commoncriteria.org/

The docs:
http://www.commoncriteria.org/cc/cc.html


I think it would be useful that our recommendations meet the basic
requirements of 17799, and adopt many of the more useful CC controls.

Access Control:

I work in Australia, and when I travel overseas, I am always amazed at
how far ahead we often are, mostly without realizing it. Almost all the
sites I review are for large corporate customers. The following points
are nearly always the common things they have from a security
infrastructure point of view:

* strong, two factor authentication (usually SecurID & RSA ACE server)
authenticating against an LDAP server) 
* role based authorization against an LDAP database 
* usually include something like Netegrity's Siteminder or Directory
Smart

I can count on one hand, without resorting to binary, the number of
times I've seen an Internet web application site of any major importance
authorizing roles against say Active Directory or /etc/group or using
DAC security features as the primary authorization mechanism. Often I
see sites that ignore the DAC features (ie Everyone:Full Control on the
web content), but that is usually fixed up pretty quickly once spotted. 

Intranet sites are different. I've seen plenty that do nearly everything
I mentioned in the last paragraph, mostly Sharepoint Portal Server.

I've never seen MAC in production, and I've done plenty of work over the
last 12 years. Maybe if I were in a defense organization, I might see
it, but it's basically rare. I'd prefer us to get DAC and RBAC right and
then put in a historical note about MAC (that's at least accurate). I
certainly would be the wrong person to re-write the MAC section as I've
had no practical experience with it (and I doubt many have). 

Support models:

Microsoft does an n-2 support model, others might do a 5 year life span.
It's essentially a well known statement by the developer about how they
are going to handle security in old versions. For example, in NetBSD,
-current, 1.6.x, 1.5.x will be fixed, and 1.4.x may be fixed. When 1.7
or 2.0 comes out, sayonara 1.4.x. 

Developers should be upfront with their customers/users about what will
be fixed. I recommend the n-2 model, it works fairly well and works with
the often 3 year IT lifecycle model. My point is for the Guide to
recommend to developers to state this explicitly what their policy is
(which might even be that they have no policy). 

Methodology:

The reason I suggest this is simple. The places that have chosen a
development standard, coding guidelines, and good practices like
adopting a shared code library, usually produce the highest quality
code, usually has test cases and documentation, the code is generally
maintainable and by accident, is often more secure than otherwise might
have occurred. As I said, I'm partial to XP at it works best with
security, but I don't mind not stating which one. 

I don't see Methodology (with a capital M) prescribing things like
defect management, change control, etc. I have worked with "developers"
who are simply graphic designers who can barely use DreamWeaver. These
places have no security at all. The best places I have worked at have
all had some form of development management in place. Part of that is a
chosen Methodology and the other items I mention. Not mentioning these
things is an error. Given the aggressive content delivery schedule for
2.0, I'm happy for this to be discussed after 2.0 is released. 

Password quality and crypto:

I'm just finished reviewing a site that has 6 digit account numbers and
four digit PINs. I was able to brute force any account in less than a
minute, even if I didn't know the account number. Password quality is
alive and well, which is why I mention it. Even basic things like
forcing the use of certain variable lengths, capitals and punctuation
(within reason) will assist in making a password harder to crack. I
think it merits inclusion. 

Every time I see home-grown crypto or badly implemented SSL, I strongly
suggest to my customers to start over. I totally agree with you on that
one. But crypto has nearly nothing to do with password quality, only its
storage (which of course, should be one way hashed using SHA1... let the
flames begin). I see them as two separate and distinct entities. 

On "best practice":

True, it's completely overused and abused. :) Terminology is just that.
For example, I never use the word "hack" or "hacker" in any of my
documents. No great fuss from my end if "Best Practice" never appears in
the Guide. :)

Before OWASP, it was really hard to get developers to do anything. Now I
have done many successful reviews using OWASP as my guide and leaving
them with a copy (love the free bit!). It's really easy to show them how
they are lacking and how easy it is to fix things up. 

Thanks,
Andrew

-----Original Message-----
From: Alex Russell [mailto:alex at netWindows.org] 
Sent: Friday, 13 December 2002 11:43 AM
To: owasp-guide at lists.sourceforge.net; Andrew van der Stock
Subject: Re: [OWASP-GUIDE] Full review observations

[...]
I'm not sure I agree with (let alone understand) what you're trying to
say.
[...]
DAC is what's available on almost all systems out of the box (and what
most 
people deploy), although MAC can be coerced with "trusted" hardening of 
some OSes (such as Solaris, SeLinux, and NT w/ C2 patches). Pure RBAC is

rarely used on an OS or Webapp level, so I think that getting ALL of our

descriptions complete and correct would be the best way to handle this.

> also should talk about strong authentication, such as two factor
tokens,
> smart cards, X.509 client-side certs and the like.

Perhaps.

[...]
> * pick a support model (ie n-2 versions will be supported?)

could you please elaborate on this?

> * use a Methodology. I am partial to XP, but pick one!

Mark, what do you think about backing a methodology in the Guide? I for
one 
am skiddish.

> * use a revision control tool
>   - regression control

makes good sense to me.
[...]
this comes pretty close to prescribing a methodology, something I"m 
squeemish about. I'm willing to be convinced.

[...]
ISO 17799 is not a Free standard. Tying ourselves to it is anti-ethical
for 
an Open Source project (note the license on the Guide for
clarification).

> Password quality and key space is an important aspect of access
control.
> It's not mentioned by the guide. 17799 has a bunch of things to say
> about it as well.

Bah, they're more or less red herrings (I know I'm going to get falmed
for 
that), but seriously, poorly implemented or understood crypto is a much 
more dangerous and common problem than someone brute forcing a keyspace.

Anyone that's focusing on keyspace exhaustion in this day and age had 
better either have the NSA as a credible part of their threat model, 
otherwise they're wasting their time.

> System configuration - we need to make some generalized best practice
> statements here. This is a huge area where I spend most of my time
> exploiting when doing pen-tests.

So long as the phrase "best practice" never occurs in the document, I'm
all 
for suggestions = )


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3269 bytes
Desc: not available
Url : http://lists.owasp.org/pipermail/owasp-guide/attachments/20021213/8d3049ec/attachment.bin