Penetration Testing mailing list archives
Re: WebServices Testing
From: Joseph McCray <joe () learnsecurityonline com>
Date: Fri, 06 Oct 2006 10:26:24 -0400
A couple of things to consider: 1. If you are dealing with NIST then the project is probably .gov related - so documentation is going to be the key here. Know that this application accreditation is a "living document" that is going to be revisited yearly. Sad to say, but a lot of the testing in this realm isn't very TECHNICAL. From a technical prospective this audit will be easy. At the end of the day it ends up being a "check the box" type of security audit. You generally don't NEED to be 31337 to do this type of audit so don't be scared if you don't know how to test for http request smuggling. What makes it hard is the fact that it is so friggin tedious. 2. Since this accreditation is going to be revisited regularly you really need to ensure that you and/or your security team are part of the Software Development Life Cycle (SDLC). Look at the recommendations on page 12 of the draft item number 2 is going to be your bread and butter (as far as the documentation is concerned). Make sure that there is transactional logging in everything (yes, I literally mean everything), and if it's not there it just needs to be documented when it will be there, or why you don't have it there. 3. Most .gov agencies in the middle of NIST are usually reluctant to go for it, but ALWAYS recommend a 3rd party code audit from a reputable firm. You are going to be dealing with the newest web technologies like SOAP, AJAX, J2EE - and of course they are going to want to communicate with other .gov agencies and share data blah blah blah - bro have fun - it's going to be a mess even develop it well. Again, 3rd party code audit. 4. Gov types think that as long as the app has something really expensive for authentication then it's secure so make sure that all authentication methods/types are thoroughly documented. If the agency has the money to spend - go for the good toys (RSA). Think multi-factor authentication ALL THE TIME. Then document, document, document, document, document, document. Some specific steps that I would recommend. 1. Establish a Change Control Board (CCB). This is a group of high level management (not the geeks) that meets at least a month to discuss and approve/disapprove of changes made to the app. 2. Require EVERYONE to submit Technical Assessment Memorandums (TAM) to the CCB for changes to be made. If people want to change the application in ANY way, or fix a bug require them to submit a TAM to the CCB for management approval of the change so you can keep your docs in order as well. This ensures management level buy-in, and proper updates to all other documentation (Backup/Restore, Emergency Response, Disaster Recovery, etc) to include these new changes. 3. Having the CCB meet at least once a month will save you and your Designated Approving Authority (DAA). The rest of the stuff will be situation specific. Shoot me an email you need more in-depth info. Like a lot of other security guys that thought an audit was performed while sitting at a root prompt - I went through a few years of an "INFORMATION ASSURANCE" experience on the both the DITCAPP and NIST sides of the security world. Good luck bud. Support http://www.ApostropheOr1Equals1DashDash.com/ On Thu, 2006-10-05 at 14:56 -0400, dallas jordan wrote:
I am tasked with doing some security testing on a new web services application our client is rolling out. I have never really tested a web service app before and I am looking for some guidance. I have reviewed the NIST 800-95 to get me started. I was wondering if anyone could give me some pointers on things to look for, that are specific to web services, or could offer up any good resources to review. Thanks in advance.
-- Joe McCray Toll Free: 1-866-892-2132 Email: joe () learnsecurityonline com Web: https://www.learnsecurityonline.com Learn Security Online, Inc. * Security Games * Simulators * Challenge Servers * Courses * Hacking Competitions * Hacklab Access
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- WebServices Testing dallas jordan (Oct 05)
- Re: WebServices Testing mailing lists (Oct 05)
- RE: WebServices Testing Paul Melson (Oct 06)
- Re: WebServices Testing Jamie Riden (Oct 06)
- Re: WebServices Testing Joseph McCray (Oct 06)
- <Possible follow-ups>
- Re: WebServices Testing revnic (Oct 06)
- Re: WebServices Testing mailing lists (Oct 08)
- Re: WebServices Testing mailing lists (Oct 08)
- RE: WebServices Testing Paul Melson (Oct 09)
- Re: WebServices Testing mailing lists (Oct 05)