Actually the idea of reassigning keys after a predefined period of time isn't a bad idea.
But no I wasn't implying that you said anything negative about OSSEC. :) We're big on open source when we can use it (which we do pretty heavily), but OSSEC is widely used, actively developed, easy to use and a good product, so we will continue to use it. We just need to rethink whether or not our initial plan is a good one. I'm now thinking it's not ;) ________________________________________ From: [email protected] [[email protected]] on behalf of loyd. darby [[email protected]] Sent: Tuesday, December 21, 2010 11:58 PM To: [email protected] Subject: Re: [ossec-list] Securely deploying OSSEC If you got the impression I am knocking OSSEC, I am not. On a LAN or private network there is no point in looking at another product because it is free and it rocks. I believe when you cross hostile networks (the cloud) the rules change. Static PSK is no more secure than having a strong password that never gets changed. There are other products that use three party authenticated agents and encrypted traffic with all the trimmings but if you need that, they will find you. The ones I know are ridiculously expensive and am not selling anything but the idea that open source is cool and developers who make it get hero status in my book. Fips is a pain and does not really improve security of communications in transit, it is all about securing the endpoints and protecting the executing code and junk like that. I guess what caused my reservation is the fact that if a key compromise did happen, you could be spied on forever and you would not be able to detect it. An operational control of assigning new keys to the clients frequently would mitigate that. On 12/21/2010 04:21 PM, Michael Starks wrote: > On 12/21/2010 12:53 PM, loyd. darby wrote: >> I agree with this assessment up to a point. For most of us security is >> about balancing risk, technology and financial constraints. >> The log data that ossec moves generally does no contain the keys to the >> store but would be useful in helping a bad guy case the joint. To use >> the log data to compromise your network, they would have to be a chain >> of other security failures. If the network you are protecting serves up >> dental records for a neighborhood clinic, OSSEC is probably going to >> meet or exceed your requirements. If the network is a federal reserve >> bank, you are going to have to wrap it inside some more robust >> cryptographic and operational controls. > > I'm a bit confused. What part of my response do you not agree with? I > was basically just reiterating how OSSEC works. > > As to your point about not meeting some federal requirements, it may > be true in some cases--the cryptography, for example, may have to be > FIPS validated, but that does not mean that OSSEC is not suitable to > an environment where strong protections are needed. > > OSSEC is the only software I know of that goes to the lengths it does > to protect the transport of logs. I would love to hear about some > other examples--I just may not know--but the SIEMs and log management > products I have worked with do not seem to care too much about log > transport. Logs are transported using regular RPC methods, FTP, syslog > and in other unauthenticated, clear-text ways. OSSEC does > authentication, encryption and even replay protection. Who else does? -- R. Loyd Darby, OSSIM-OCSE Project Manager DOC/NOAA/NMFS Infrastructure coordinator Southeast Fisheries Science Center 305-361-4297
