tag:blogger.com,1999:blog-4088979.post113452059875673624..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Non-Technical Means Unearth Best IntrusionsRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-4088979.post-28576937832114740552010-10-28T18:20:45.994-04:002010-10-28T18:20:45.994-04:00Well you are ALL wrong. Niku published their usern...Well you are ALL wrong. Niku published their usernames and passwords in a WebEx meeting that was open to the public.<br /><br />They published the URL to their server, a username and a password. Then, when logged in, a document listing the entire employee directory gave all the other usernames and passwords.<br /><br />Still, the government prosecutes Business Engine for taking advantage of Niku's blundering. That should not have happened. By publishing their UN/PW's, they have forfeited any Trade Secret claims to their information, and then there is no case as the information downloaded was 'worthless'...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-60869621417979695732008-03-25T16:56:00.000-04:002008-03-25T16:56:00.000-04:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-49767700315893099332008-02-12T05:17:00.000-05:002008-02-12T05:17:00.000-05:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1135000336202370022005-12-19T08:52:00.000-05:002005-12-19T08:52:00.000-05:00I think this story and the comments posted deserve...I think this story and the comments posted deserve a lot more discussion. I will try to keep my comments as brief as I can.<BR/><BR/>First of all, statements to the effect that NIDS or NSM simply doesn't work here are VERY common in my experience and unecessarily restrict the scope of what the term NIDS can be applied to. There seems little recognition that application-level IDS have been envisioned, described, and implemented for many years -- just have a look at Dorothy Denning's 1987 paper, "An Intrusion-Detection Model" and note the scope of detection suggested around authenticated users. Even the application security experts are caught up in this thinking to the extent that they will also declare that "IDS doesn't work" [for intrusions via web apps] and then define a completely passive approach to detecting web app intrusions [literally a web-app IDS] to be something called a "web app firewall." This makes little sense to me because I believe a "web app IDS" and a "web app firewall" should be two different things with diffent capabilities.<BR/><BR/>Secondly, there is a legitimate difference in the levels of abstraction required for detection and monitoring of networks versus applications. If what characterizes good NSM is packet-level detection, traffic analysis, full packet capture, and TCP session flows then perhaps we need a term like ASM (application security monitoring) to characterize appropriate application-level detection, application analytics, full content capture, and application session flows (not TCP flows). Clearly this suggests a different set of tools from snort + squil for example. In this regard, ASM does not need to be network-based though I think that is the best approach to achieve the goals. (As an aside, an ASM device deployed to defend a web application can generally decrypt SSL traffic)<BR/><BR/>Thirdly, as to the earlier comment pointing out that this case suggests lax security on the part of the victims, well that is often the case with applications. In application security today there is a great deal of emphasis on preventing, discovering, and fixing common vulnerabilities seen in web apps. However, there is little emphasis on capabilities to detect intrusions, conduct incident response, or properly audit application usage. To quote Richard, "prevention eventually fails," and we still need to be able to answer the questions Richard posed, but we also need the right application-level and user-level tools to do so.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1134744223005136932005-12-16T09:43:00.000-05:002005-12-16T09:43:00.000-05:00Agree with the anon poster. This isn't an IDS/IPS...Agree with the anon poster. This isn't an IDS/IPS event. There's no way sales documents from the recent Nike meeting should have been available via any kind of Internet connected machine. Stealing is wrong in every case. Unfortunately for the victims, they could have avoided the entire problem by practicing some very basic security 101 principles like network segmentation and token-based VPNs for network access. Anyone who calls themselves a Chief Information Officer *should* have known better.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1134671655619768422005-12-15T13:34:00.000-05:002005-12-15T13:34:00.000-05:00I'm not so sure that network security monitoring w...I'm not so sure that network security monitoring would have helped you here. Enterprise computing is moving everything to application level transactions. Most critical business information is already passed via HTTP/SSL/XML/SOAP. Many application attacks do not use a technique that would even produce an attack signature that could be seen by network level monitoring. Even if it did, you’d have to figure out how to get it decrypted for a second to look at it. But if you did, what would you see? HTTP traffic… GET’s, POST’s, I guess you could spot obvious SQL injections but what about subversion of application logic?<BR/><BR/>I’d be willing to bet that the intrusion here wouldn’t show up in an IDS or any other NSM tool. It would look like normal HTTP (or HTTPS) traffic. I guess you could spend TONS of time writing custom IDS rules to watch for improper application access… but wouldn’t the business be better off using that time (money) writing better applications and testing applications?<BR/><BR/>If someone broke into a company’s CRM software and stole sales information, business plans, etc... that just might end up being far more costly than if a cracker rooted Apache on the box and setup an IRC bot. NSM would catch the script kiddie and his bot, but not your competitor.<BR/><BR/>I think that NSM is still important to keep and eye on what you can. However I think that NSM must work with applications and correlate (ack!) information to spot malicious activity. <BR/><BR/>This type of thing is already being seen with Cisco's push into application (XML, SOA, etc.) products.Trevorhttps://www.blogger.com/profile/12281134549524739274noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1134661766634862632005-12-15T10:49:00.000-05:002005-12-15T10:49:00.000-05:00This comment has been removed by a blog administrator.Trevorhttps://www.blogger.com/profile/12281134549524739274noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1134523641957774962005-12-13T20:27:00.000-05:002005-12-13T20:27:00.000-05:00Article I read on this said they had a training we...Article I read on this said they had a training web site with braindead usernames/pws and which (it would seem) was not separated adequately from their production data/systems.Anonymousnoreply@blogger.com