|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
RE: WebAppSec Training Courses in UK
Date: Wed Dec 04 2002 - 10:39:40 EST
Hmmm,
>>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 tested were<<
Yes, but we accept these limitations when engaging a security firm to cover those areas where we may have limited experience or time. People accepting poor quality output from a security assessment are themselves to blame as much as the 'market' is for foisting solutions that may have limited applicability to reducing 'real risks' they are likely to encounter.
>>Someone once used a great analogy. If you're testing for cancer would you
take someone's temperature? <<
This is a poor analogy for security and risk asessment. We don't test for temperature but instead try to reduce the patients desire to smoke, drink or otherwise ingest stuff that would increase the risk of cancer. If they have cancer, you are too late pal.....
>>Assess strategically not tactically. Asses how security is baked into the
development process and not just in a deployment scenario.<<
It would be wonderful if I had the chance to build security in from the start of every development project. Whilst continuing to educate developers (who are often churning through new staff) about security best practice, I still have to rely upon assessments to catch transgressions.
The usability industry is no stranger to this scenario; In many cases, clients ask usability consultants to find problems with an interface that has *already been developed*. The same situation exists with web application security - in many cases, I'm asked to identify problems that shouldn't have arisen in the first place. Whinging about this doesn't address the problems though - I have to educated developers but this doesn't obviate the need to perform some level of app security testing, often late in the development cycle (for late, read 1 week before release).
In the abscence of security conscious developers, we have to rely upon education AND compliance testing during a project. I personally think that many of the services offered to 'assess' security from established companies are pretty lame these days. They cannot possibly understand the background that the developers have, understand 'bad practice' that has established itself within a company or provide assessments that leverage internal knowledge of where vulnerabilities may lie. We accept these limitations of any assessments that may be provided and direct them appropriately towards areas that we know are weak. It isn't that we suggest that you do only one or the other - there is a place for education and a need for verification.
What I'm worried about is that many companies will seek to exploit app vulnerabilities to clients without addressing the underlying problems with the platforms and development approach.
Craig.
This is a poor analogy for security and risk asessment. We don't test for temperature but instead try to reduce the patients desire to smoke, drink or otherwise in
securityarchitec
t@hush.com To: dan@idsec.com, glyn.geoghegan@corsaire.com
cc: webappsec@securityfocus.com
03/12/02 19:08 Subject: RE: WebAppSec Training Courses in UK
With respect I think your description of security assessment training is woefully inadequate in todays world. Penetration testing is a snapshot at best and a time trial at worst. 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.
<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 tested were. Secondly with 78% of attacks
being from insiders (see FBI reports) , looking at the hard crunchy outside
is of 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 color 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 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>
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 theyre ill, you still need to locate the problem (offending code) to treat it.
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. In a structured meaningful test you need to firstly sit down and understand the security requirements. How can you ever 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.
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).
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).
Web application security assessment is far more than a pen 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 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 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 strategically not tactically. Asses how security is baked into the development process and not just in a deployment scenario.
On Tue, 03 Dec 2002 01:54:14 -0800 Glyn Geoghegan
<glyn.geoghegan@corsaire.com> wrote:
>You also need to determine whether the training you want is
Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2
Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427
Notice: This email is confidential and may contain copyright material of the John Lewis Partnership. If you are not the intended recipient, please notify us immediately and delete all copies of this message. (Please note that it is your responsibility to scan this message for viruses).
John Lewis plc Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN
Websites: http://www.johnlewis.com and http://www.waitrose.com Received on Wed Dec 4 10:54:25 2002
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:45 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |