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?
