I'm going to cut bits of this cos' it's getting too hard to read. On Tue, 4 Dec 2001, todd glassey wrote: > > Todd -- I don't think you seem snotty. > > Thanks - I was just a little acerbic in my wording I think though. > so you're going to argue with me about whether or not you were snotty? okay, maybe you were snotty! ;-) > So in response to the question on what to do? my take is that this list > could actually produce something other than just the list content. It could > produce a set of BCP's for how we do it today and ways we can make it > better. Who better to do this than the Systems Admins? and think of the > value of developing an operations model to address this. The Auditors would > love us for this since it gives them an arms length from it. > Yep, which is one of the things I'd like to do with this paper I've been working on for decades -- throw it to the list as a launching point for these more detailed documents. > As to the HR people, they should have separate systems. HIPAA regulatory > compliance really mandates it, no other risk model makes sense (IMHO) > because of the criminal penalties attached to screwing up on HIPAA.. > yes, but. unless things have changed drastically in the last two years (they may well have), I know that most of the vendors of healthcare code -- database systems and the like -- were years away from implementing access control and authentication requirements that were consistent with HIPAA demands. and i've never met a hospital sys-admin who was going to rewrite the doctor's front end GUI app to support kerberos if the vendor didn't do it. HIPAA compliance will force a lot of security improvements, but it doesn't help much today. ..... > We have talked about this before, you and I - The answer is to create > pre-packaged "operations templates" and a set guidelines for using them, or > as a group we could work with people who are implementing these. I think > this is a more savvy group of SysAdmins through and we could set these up > better than a lot of the other efforts in this area. This means building a > set of models and all the pre-set configurations. It probably also means > actually implementing one to test it which could be fun - Bruce might even > subsidize it I would think. Unfortunately I don't think this piece is an effort which Bruce or Counterpane would fund, cos' it's what we do -- outsourced log management -- so whilst The Job has no issues with me working on attack data and syslog configs and building lots of cool databases, we have an infrastructure to do the distributed log aggregation and management. I can probably kibbitz, but C-pane isn't going to fund testing logging infrastructures, aside from our own. Alas. Although if I set up syslog-ng in my lab just to see how it works... What I can do -- I've been talking to Toby Kohlenberg at Intel about this (hi Toby!) -- is to provide a repository for log configurations, integration advice, and syslog/SNMP data generated by attacks. This is of course the genesis of the Web site. Toby and I have been kicking around the idea of doing a sort of "Attack of the Month" project -- like the Honeynet's scan of the month -- where we'd pick an exploit and ask people to run it on different platforms, vulnerable and not vulnerable, and then send this list the log data and configuration details -- whereupon I'd get it into a database and work up swatch and logsurfer configs. We each get lots of data we wouldn't otherwise see, and no one has to wait to be hacked to figure out how to detect the attacks. But this is front end stuff, and doesn't help with the best practices piece. Except for helping define the sorts of things that the monitoring should be able to detect, once the central infrastructure is in place. > > Oh and to add value to the process the rest of the world needs to be in on > it too. So we do this in conjunction with other standards orgs like CASPR > and the IETF so that the technologies are widely dispersed for commentary > and adoption. > What I'd really like is a quick and dirty, "here's what you can do right now that you might not have thought of" that we could post -- to give people a place to start while the longer-term projects were in place. > > > Look the projects I would suggest are: > > 1) Setting up and operating a secured Logging > Infrastructure/Service - i.e. pick several templates and then decsribe them > at reference level. Working with Event Representation as well since this is > critical for evidentiary processes. > > 2) Forensic Log Management Processes - Setting standards for long > term data storage and proofing - - i.e. pick logging methods and develope > operations templates and then decsribe them at reference level. > > 3) Multi-Event Logging, Management, and Query Access to events and > event streams. This piece, of course, makes fixing the network protocols and data authentication look really easy... --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Tue Dec 04 2001 - 17:37:17 PST