On Thu, Jul 17, 2008 at 1:30 PM, Brooks Garrett <bg_at_brooksgarrett.com>
wrote:
> We have settled on SharePoint as our Computer Security Incident
> Response Management System. It seems the ability to modify the system
> is a key factor with us!
... must. resist. urge. to bring up the argument that a closed source
system with an API does not equal an ability to modify said system...
crud. resistance was futile ;-)
> My question before I start coding my own application, are you guys
> using any particular templates/applications/etc with your SharePoint
> installations that suit this purpose?
I don't have any templates/applications for sharepoint, but it may be
helpful to take a look at RTIR and see if any of the features it has
would be a value to your needs. Probably the best place to find that
list of features is on the comparision to the vanilla RT product:
http://bestpractical.com/rtir/comparison.html
I'm unsure how workable it would be to add any of these features to the
code you're doing in the framework you've been given (I could see
maybe creating a webpart for whois lookups, or traceroute, or such?)
> In other words, if you are using SharePoint as an IMS, how are you
> doing it?
I'm not in the position of using SharePoint as an IMS, a fact for which
I'm fairly thankful. I can't imagine it making a decent solution for
such a product honestly, but then, I don't know what your requirements
for such a product are.
On the upside, I just got a lot happier about the crappy system I
am currently working on migrating to for Incident Response, because
"at least it's not SharePoint" =)
The product itself "as is" doesn't lend itself well to IMS as I think
of it ((eg. ticketing, customer interaction/feedback, useful tools like
whois/traceroute, etc.). The list features that it provides are fairly
rudimentary IMO, and the Document Libararies etc. I can't see being
all that useful in incident response, beyond having a repository of
process docs or such.
I can say that I currently do use SharePoint to manage documentation
around investigation of incidents, and find it to be lacking. Specifically
I've noticed a number of oddities around datestamps on the
documents.
But then, my exposure to SharePoint hasn't included working with a
homegrown codebase on top of the framework, and it could be that
many of the faults I find are simply the results of an insufficiently
'tweaked' environment.
Good luck with the endeavor, and honestly, I'd be interested in
hearing from you after it's been in production for a bit to see
how it's working out for you.
--
jason
Received on Jul 18 2008