RE: WebAppSec Training Courses in UK

["Glyn" <glyng () bigfoot com>]

Hiya,

I've addressed you points inline.

G

> -----Original Message-----
> From: securityarchitect () hush com [mailto:securityarchitect () hush com]
>
> With respect I think your description of security assessment
> training is woefully inadequate in today's world. Penetration 
> testing is a snapshot at best and a time trial at worst. 

All security review, audit and assessment represent a snapshot, and are
subject to prevailing practice and disclosure.  This relates
particularly to infrastructure vulnerability assessments (e.g. those
based on tool output, announced vulnerability data and manual research)
and, to a degree, conceptual assessments relating to architectural
review and best practice audit (bespoke design, configuration, coding or
deployment).  A good assessment consultant will both detail specific
fixes within the environment and make strategic recommendations to
mitigate against future or chained attacks through hitherto unreleased
problems.  The scope of recommendations may well include policy and
procedural changes as well as 'download this patch'.

Application Security Assessment (pen-testing) was merely the third of my
proposed broad categories.  The first two address secure design and
build - strategies for longer term security.

> Having ran some teams for some well known consulting
> companies in the past I know all to well the business model 
> and why its pushed so hard by them. Now working in corporate 
> America I also see why we the clients (yeah we as in my 
> company and others at like minded user groups who 
> surprisingly do talk) are getting very frustrated with some 
> security consulting companies and training companies. 

Indeed, many consultancies (but by no means all) are focussed on their
own interpretation and methodologies rather than listening to client
requirements.  The security services industry evolves based on feedback
from such user-groups, and many of us are active members of them.  The
client dictates the 'product', we add to and provide it where
appropriate.

> <rant>
> Firstly there is little accountability. Its perceived as an
> art and not a science and therefore you really have little 
> confidence that all of the things that should have been 

Hence projects such as OWASP and OSSTMM proposing methodologies and
inviting comment and contributions.  There is a shocking lack of
accreditation within the IT industry, including security and
particularly within the security assessment fields.  In the absence of
such qualifications, open-source frameworks provide real benchmarks by
which to measure service providers.

> tested were. Secondly with 78% of attacks being from insiders
> (see FBI reports) , looking at the hard crunchy outside is of 

This typically relates to successful infrastructure attacks, but is
still true in many cases (the prevalence of hybrid threats and worms
have shifted the balance back towards the external threat, however,
according to recent figures from the DTI, FBI and others).  Indeed,
application insecurities highlight the implications of the soft centre
within the hard shell.

> little value. Too many companies reports read  "High
> Vulnerability - Parameter tampering". After the sticker shock 
> you read between the lines and find out you can change the 
> page colour and they have made an incredible leap of faith 
> from that to saying you "may" be able to login in with 
> another users username. An indicator of parameter tampering 

IMHO, security assessment (as opposed to black box pentesting) isn't
about detailing 'a' way into an environment, it's about identifying 'any
and all', i.e. the most likely risks that may be exploited, and
proposing mitigating strategies.  

That is the philosophy I describe to potential clients, and the one by
which I perform said assessments.

I agree that there are many that rely on shock value to intimate value.
That is why public, open source guidelines are important.

For the most part, people accept the insecurities of computer systems.
Its no longer relevant to prove a break-in is possible, as that leaves
the client feeling exposed and with no way forward.  The successful
outcome is to eliminate most of the threat, and mitigate against the
rest (which may be a non-technical solution, e.g. insurance)

> in one place can lead to it in another. It's the consulting
> fluff syndrome. You've all heard it before I am sure. "These 
> sessionID's don't look random". Well test the randomness if 
> you have a math degree! If not look for the source of 
> randomness and if /urandom is used then call it out. 
> </rant>

<rant>I have a mathematics and computer science degree and apply it
where relevant.</rant> ;)

There are those that use a shoddy assessment and shock tactics to push
product sales.  They should be identified early in the tender process.

There are those that aim to provide a full and comprehensive assessment
suite for its own sake, not as a door opener to further sales.

> Someone once used a great analogy. If you're testing for
> cancer would you take someone's temperature? Would you look 
> at their eyeballs? Hell No! Get them on the cat scan machine. 
> Even if the eyeballs are dilated and you can tell they're ill, 
> you still need to locate the problem (offending code) to treat it.

You may apply the aforementioned tests to eliminate many of the
hypochondriacs before spending good money on the cat-scan...

> One of the things I liked when I spoke to the OWASP testing
> people was how they are going to cover what I think should be 
> included in a web application security testing methodology. 

Agreed.

> In a structured meaningful test you need to firstly sit down
> and understand the security requirements. How can you ever 

Firstly, the business requirements and aspirations.

> say there is a problem unless you know the requirements and
> how it should be? Secondly you need to understand the 
> application architecture. That's an assessment in itself! How 
> are people using JNDI, LDAP JMS <insert architecture 
> component of choice here>. People are finally realizing that 
> XSS is easily cured with a proper architecture;-) You don't 
> fix it tactically, you fix it strategically. 

Again, the aim of OWASP appears to be to raise awareness of commonly
made, and exploitable, mistakes; and therefore eliminate them.
Furthermore, it aims to propose strategic and practical guidelines to
eliminate bad, and insecure, practice.
 
> Then there is a technical assessment which is where most
> people think the pen test comes in. But think of this. My 
> requirements have shown that sessions timeout after 20 mins 
> and my architecture review shows I use the servlet container 
> config (server.xml) to do it and the controller servlet to 
> enforce it. I can sit there with a perl script and make a 
> request every 21 mins to each url (dumb in my opinion) or I 
> can parse web.xml and server.xml for the config. Ones a much 
> more effective way to technically test the requirements have 
> been implemented IMHO. A pen test may have a place in 
> ensuring that stuffs functioning as it should be that's where 
> it belongs again IMHO, flamesOff(security, architect). 

I agree - the ideal assessment scenario, for me, is:
1/ Review the design from a security perspective,
2/ Ensure it has been implemented as expected.

> And then there's a security source code review, a web
> application security management review (what happens when it 
> goes down, who reviews logs, what policy exists to manage the 
> security of the application). 

Agreed.  Policy and procedure are not glamorous, but are essential to
the security of an environment.  Code reviews can be a time consuming
and costly exercise.  An application assessment bridges the
middle-ground (as early infrastructure penetration tests did),
mitigating against the highest impact, most exposed risks - setting
precedents for a securer environment.

> Web application security assessment is far more than a pen

Agreed.

> test. They are prevalent because consulting companies can
> pull the wool of clients eyes with buzz words and hacker 
> speak, not to mention the business model that works well for 

I would, and could, not work for those with such a cynical view.  Many
on this list would agree.

> the consulting companies. If you pay 40K for a hit and run
> that's good business. But if you fix the first hole and have 

Cowboys are getting nowhere in this market!  Clients (rightly) expect a
road-map for a secure future, not a demonstration of a breach for their
$40k.  "Any and all" vulnerabilities, not "a" vulnerability - the
minimum requirement.

> to pay $40K for the next then its not economical and the
> client will soon feel ripped of. 
> And why does this relate to training? Well people IMHO need 
> to be trained that web application security assessment 
> consists of many things not just how to own a web server in 
> 20 mins or how to test for XSS from the outside. Assess 

Yes, there are a number of aspects.  From architecture, to design, to
deployment.  And once those relating to the infrastructure are
considered, one must review the application(s) themselves.  It's usually
the brand and data we're trying to protect, and the application by
definition is often the highest exposure of that risk.

> strategically not tactically. Asses how security is baked
> into the development process and not just in a deployment scenario.

My point precisely.  Workshops and training to enlighten developers.
Peer review to validate designs and project plans.  Code and application
assessment to ensure the project runs securely to schedule.

> On Tue, 03 Dec 2002 01:54:14 -0800 Glyn Geoghegan
> <glyn.geoghegan () corsaire com> wrote:
<snip>