tag:blogger.com,1999:blog-4088979.post4263638466380696500..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: The Revolution Will Be MonitoredRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-4088979.post-57749510767482004192007-01-14T09:47:00.000-05:002007-01-14T09:47:00.000-05:00Richard, with regard to your comment about not hav...Richard, with regard to your comment about not having requirements ofr intercepting outbound traffic due to multiple protocol tunnels. Has anyone in the industry taken a look at exploiting enterprise management systems, combined with running multiple tunnels, to create an overlay network? Seems to me, that most IDS shops ignore traffic if it appears to be coming from authorized network/computer management tools by default. That's a perfect path, as it does not require 'hacking' the OSes/Apps directly, just take over the managmement system. Most of the leading vendors appear to have comms between agents and central controllers that are fairly easy to subvert/inject, etc., since the rpc variants most of the vendors use for comms can be subject to well-engineering exploits. I have seen ptacek/monstano talk at BH, and think that's something of interest to network monitoring types in that if you can't fix something, at least figure out how to 'monitor' it, so you can determine if something bad is going on. <br /><br />If you want to hide on someone else's network, make sure you look like everyone else, mix in with the crowd/noise, and be the little thing that doesn't stand out. So look like standard administrative traffic/functions.<br /><br />Attacking C2 systems has always been a military strategy, and if everyone is expected to live on the 'Net, and allow C2 of major functions of society, then shouldn't those systems be somewhat secure? Thanks for your thoughts in advance....Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-88745991559019348602007-01-10T12:45:00.000-05:002007-01-10T12:45:00.000-05:00A certain large global firm I was with until recen...A certain large global firm I was with until recently has gone with the latter strategy, at least for emails. If messages were important to you, either print them or save them to a personal folder; otherwise, they are going in the bit bucket and officially are not retained after 30 days.<br /><br />This wasn't in the US though... does it say what time period the information has to be available for? I'm expecting companies to go to a time-limited full retention strategy. That way there is not question as to what is available while placing some bounds on storage space at the same time. Albeit differing circumstances might dictate otherwise as mentioned by Bob above.<br /><br />Cheers!Jason Meltzerhttps://www.blogger.com/profile/05689158632756750517noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-54054642619022285522007-01-10T12:33:00.000-05:002007-01-10T12:33:00.000-05:00Agreed, at least in the financial industry the tre...Agreed, at least in the financial industry the trend is for much more data retention. The problem then becomes data management. The cost for storage becomes monumental in a large environment. We had a requirement to be able to collect 120TB of log data every 90 days and the cost for that per month was on the order of $40,000+...and that wasn't all of our data, mostly system and security log data. Most of the major log retention solutions and SIM/SIEM solutions are fighting this battle now; hence, you see Network Intelligence getting bought by EMC, LogLogic increasing their event and device capacity etc.<br />At one time we also implemented argus on every single IDS we had, and loaded these files hourly to a central server. While these files were useful for all types of analysis, the amount of data we collected soon overwhelmed our capacity, even though it was netflow information only. This is definitely the direction we are headed and will play well into the hands of Niksun and Sandstorm’s NetIntercept…Anonymousnoreply@blogger.com