From: Joseph McCray (joe@learnsecurityonline.com)
Date: Fri Oct 06 2006 - 10:26:24 EDT
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
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:08 EDT