Non-Technical Means Unearth Best Intrusions
Thanks again to the latest SANS NewsBites, I learned of an interesting trade secret theft case. From the CNET News story:
"John O'Neil, former CEO of Business Engine Software, pleaded guilty in a San Francisco federal court on Wednesday to conspiracy to download and steal the trade secrets of software competitor Niku over a 10-month period...
From October 2001 until July 2002, Business Engine used the passwords to gain unauthorized access to Niku's systems more than 6,000 times and downloaded over 1,000 confidential documents containing trade secrets, the complaint alleged. The stolen documents included technical specifications, product designs, prospective customers, customer proposals, client account information and pricing.
Niku discovered the break-in after a Business Engine salesman made an unsolicited call to one of Niku's prospective clients, a Nike employee who happened to be related to Niku's chief information officer, Warren Leggett. The call raised suspicion because the Nike employee was not ordinarily responsible for software purchasing decisions, had never heard of Business Engine and had no idea how the salesman had obtained his contact information, according a declaration by Leggett.
The incident prompted Leggett to examine his company's computer logs and files from his recent meeting with Nike. He quickly determined from a trail of Internet network addresses that someone from outside the company had been stealing files. Leggett was able to trace the intrusions back to Business Engine by using Internet domain registration information and publicly available Internet tools." (emphasis added)
Whoa. Niku has been 0wn3d for 10 months, and accessed "more than 6,000 times," before a freak family relation caused the right gears to mesh. What kind of security did Niku have (or not have) that would let a compromise continue undetected and unimpeded for so long?
The sad fact is that many of the most interesting intrusions (i.e., not worms, or bots, or viruses) are discovered by non-technical means. Once a company is clued in to the fact they have a breach, the question becomes one of scoping the incident. For example:
Most organizations are not collecting the NSM data they need to answer these questions. Is yours?
"John O'Neil, former CEO of Business Engine Software, pleaded guilty in a San Francisco federal court on Wednesday to conspiracy to download and steal the trade secrets of software competitor Niku over a 10-month period...
From October 2001 until July 2002, Business Engine used the passwords to gain unauthorized access to Niku's systems more than 6,000 times and downloaded over 1,000 confidential documents containing trade secrets, the complaint alleged. The stolen documents included technical specifications, product designs, prospective customers, customer proposals, client account information and pricing.
Niku discovered the break-in after a Business Engine salesman made an unsolicited call to one of Niku's prospective clients, a Nike employee who happened to be related to Niku's chief information officer, Warren Leggett. The call raised suspicion because the Nike employee was not ordinarily responsible for software purchasing decisions, had never heard of Business Engine and had no idea how the salesman had obtained his contact information, according a declaration by Leggett.
The incident prompted Leggett to examine his company's computer logs and files from his recent meeting with Nike. He quickly determined from a trail of Internet network addresses that someone from outside the company had been stealing files. Leggett was able to trace the intrusions back to Business Engine by using Internet domain registration information and publicly available Internet tools." (emphasis added)
Whoa. Niku has been 0wn3d for 10 months, and accessed "more than 6,000 times," before a freak family relation caused the right gears to mesh. What kind of security did Niku have (or not have) that would let a compromise continue undetected and unimpeded for so long?
The sad fact is that many of the most interesting intrusions (i.e., not worms, or bots, or viruses) are discovered by non-technical means. Once a company is clued in to the fact they have a breach, the question becomes one of scoping the incident. For example:
- What happened/is happening?
- What systems are or may be affected?
- What information did the intruder copy, change, or destroy? (violations of confidentiality, integrity, or availability)
- When did the intruder first gain unauthorized access?
- When was the last time the intruder accessed victim systems?
Most organizations are not collecting the NSM data they need to answer these questions. Is yours?
Comments
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?
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.
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.
This type of thing is already being seen with Cisco's push into application (XML, SOA, etc.) products.
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.
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)
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.
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.
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'...