On 12/21/2010 01:04 PM, Jarred White wrote:
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.

OSSEC is granular enough where you can secure remote deployments. You could, for example, configure a downstream server to write alerts to a local syslog. Then install a client for an upstream server looking at that local file, which then sends just the alerts upstream. It's protected in transit just like normal OSSEC traffic. If this were done over the Internet, it's not the transport I would worry about, it would be the potential packet loss due to using UDP. So in this context, I might use something to wrap a TCP layer around it.

As to the MSP scenario, I am doing just that, so I know it can be done. The technology part is not hard--the time-consuming part is the documentation, change management, developing pretty reports, etc.:)

Reply via email to