I'm actually our infosec director here, so security is my main focus at our org. Like most people, we have a layered security architecture that involves restricting access to the LAN from the outside and using encryption when and where it's feasible, so my real concern is not with other employees on the LAN. Having said that, and understanding that log data doesn't represent an immediate vector for attack, it is very undesirable to have that stuff floating around in plain text. But after hearing some other explanations of how people believe the communication works, I am less concerned about someone inside the LAN getting access to info they shouldn't have and more concerned about remote deployments.
One user suggested not even trying to do this with OSSEC, which I'm now thinking may be the right approach. What we're really trying to do is force OSSEC into an MSP sort of deployment and it's really not intended for that, so it probably makes the most sense to remotely deploy and configure an OSSEC server at each of those locations and push up only the most important alerts to select folks. Thanks for all the feedback. By the way, we got our copy of the Syngress book in, and I highly recommend it. It fills in a lot of blanks left by the documentation on the website and wiki. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of loyd. darby Sent: Tuesday, December 21, 2010 12:53 PM To: [email protected] Subject: Re: [ossec-list] Securely deploying OSSEC 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. On 12/20/2010 06:39 PM, Michael Starks wrote: > On 12/20/2010 12:54 PM, Jarred White wrote: >> Hello. I'm trying to find a way to remotely deploy OSSEC to some of >> our remote sites and have it report back to us on server health/security. >> There is no direct connection to the remote network, so any reporting >> would need to happen over the Internet since VPN is out of the question. > > As other have noted, OSSEC encrypts all communications symmetrically > with Blowfish. Each client has a unique key, so if one is compromised, > your entire infrastructure is not at risk. > > Additionally, since OSSEC uses UDP, and UDP is vulnerable to replay > attacks (even while encrypted), a counter is added to prevent any > replay of captured traffic. OSSEC will, by default, drop any packets > with a duplicate counter. > > There may also be a random pad used for keep-alive messages..I am not > entirely sure about that. > > Finally, also by default, OSSEC will restrict by source IP, so that > also makes it difficult to inject traffic. > > I think you'll find that these protections are pretty much > state-of-the-art when it comes to log transport. I don't think you'll > find better in many other products, open source or commercial. > -- R. Loyd Darby, OSSIM-OCSE Project Manager DOC/NOAA/NMFS Infrastructure coordinator Southeast Fisheries Science Center 305-361-4297
