Mr Tancredi said Verisign's fraud detection kit would help "decrease the time between the attack being launched and the brokerage being able to respond".

Before now, he said, brokerages relied on counter measures such as restrictive stock trading or analysis packages that only spotted a problem when money had gone.

Verisign's software is a module that brokers can add to their in-house trading system that alerts anti-fraud teams to look more closely at trades that exhibit certain behaviour patterns.

"What this self-learning behavioural engine does is look at the different attributes of the event, not necessarily about the computer or where you are logging on from but about the actual transaction, the trade, the amount of the trade," said Mr Tancredi.

"For example have you liquidated all of your assets in stock that you own in order to buy one penny stock?" he said. "Another example is when a customer who normally trades tech stock on Nasdaq all of a sudden trades a penny stock that has to do with health care and is placing a trade four times more than normal."

This is a good use of data mining because, as I said previously:

Data mining works best when there's a well-defined profile you're searching for, a reasonable number of attacks per year, and a low cost of false alarms.

Another news article here.

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS ???vulnerability??? in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this ???bug??? is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time ??? the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan???s invention of the technique (this also assumes prior art) ??? with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the ???entire web??? could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn???t already exist in their DNS server???s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or ???eyeballs??? away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes ???taking over the entire web??? is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker???s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack ??? prior to disclosing the invention, there were likely few, if any attackers with ???prior art??? that mirrored this technique. It is anybody???s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so ??? I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let???s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

With all this talk and reporting about security concerns, lets change the channel for a moment and assess the potential security benefits of Cloud Computing.

In my view, there are some strong technical security arguments in favour of Cloud Computing - assuming we can find ways to manage the risks.

With this new paradigm come challenges and opportunities.  The challenges are getting plenty of attention - I’m regularly afforded the opportunity to comment on them, plus obviously I cover them on this blog.  However, lets not lose sight of the potential upside.

In this post, I walk through seven technical security benefits.  Some are immediate, others may arise over time and have conditions attached (some unstated for the sake of brevity).  However, I’m including the longer-range benefits now to raise awareness.  Some of the outcomes listed are available today without the Cloud, but they are either complex and slow to implement (and thus less likely to happen) or prohibitive for capital cost reasons.  I don’t claim this is a definitive list - it reflects where my thinking is today.

Some benefits depend on the Cloud service used and therefore do not apply across the board.  For example; I see no solid forensic benefits with SaaS.  Also, for space reasons, I’m purposely not including the ‘flip side’ to these benefits, however if you read this blog regularly you should recognise some.

On a sidenote, I believe the Cloud offers Small and Medium Businesses major potential security benefits.  Frequently SMBs struggle with limited or non-existent in-house INFOSEC resources and budgets.  The caveat is that the Cloud market is still very new - security offerings are somewhat foggy - making selection tricky.  Clearly, not all Cloud providers will offer the same security.

Seven Technical Security Benefits of the Cloud

1. Centralised Data

• Reduced Data Leakage: this is the benefit I hear most from Cloud providers - and in my view they are right.  How many laptops do we need to lose before we get this?  How many backup tapes?  The data “landmines” of today could be greatly reduced by the Cloud as thin client technology becomes prevalent.  Small, temporary caches on handheld devices or Netbook computers pose less risk than transporting data buckets in the form of laptops.  Ask the CISO of any large company if all laptops have company ‘mandated’ controls consistently applied; e.g. full disk encryption.  You’ll see the answer by looking at the whites of their eyes.  Despite best efforts around asset management and endpoint security we continue to see embarrassing and disturbing misses.  And what about SMBs?  How many use encryption for sensitive data, or even have a data classification policy in place?
• Monitoring benefits: central storage is easier to control and monitor.  The flipside is the nightmare scenario of comprehensive data theft.  However, I would rather spend my time as a security professional figuring out smart ways to protect and monitor access to data stored in one place (with the benefit of situational advantage) than trying to figure out all the places where the company data resides across a myriad of thick clients!  You can get the benefits of Thin Clients today but Cloud Storage provides a way to centralise the data faster and potentially cheaper.  The logistical challenge today is getting Terabytes of data to the Cloud in the first place.

2. Incident Response / Forensics

• Forensic readiness: with Infrastructure as a Service (IaaS) providers, I can build a dedicated forensic server in the same Cloud as my company and place it offline, ready for use when needed.  I would only need pay for storage until an incident happens and I need to bring it online.  I don’t need to call someone to bring it online or install some kind of remote boot software - I just click a button in the Cloud Providers web interface.  If I have multiple incident responders, I can give them a copy of the VM so we can distribute the forensic workload based on the job at hand or as new sources of evidence arise and need analysis.  To fully realise this benefit, commercial forensic software vendors would need to move away from archaic, physical dongle based licensing schemes to a network licensing model.
• Decrease evidence acquisition time: if a server in the Cloud gets compromised (i.e. broken into), I can now clone that server at the click of a mouse and make the cloned disks instantly available to my Cloud Forensics server.  I didn’t need to “find” storage or have it “ready, waiting and unused” - its just there.
• Eliminate or reduce service downtime: Note that in the above scenario I didn’t have to go tell the COO that the system needs to be taken offline for hours whilst I dig around in the RAID Array hoping that my physical acqusition toolkit is compatible (and that the version of RAID firmware isn’t supported by my forensic software).  Abstracting the hardware removes a barrier to even doing forensics in some situations.
• Decrease evidence transfer time: In the same Cloud, bit fot bit copies are super fast - made faster by that replicated, distributed filesystem my Cloud provider engineered for me.  From a network traffic perspective, it may even be free to make the copy in the same Cloud.  Without the Cloud, I would have to a lot of time consuming and expensive provisioning of physical devices.  I only pay for the storage as long as I need the evidence.
• Eliminate forensic image verification time: Some Cloud Storage implementations expose a cryptographic checksum or hash.  For example, Amazon S3 generates an MD5 hash automagically when you store an object.  In theory you no longer need to generate time-consuming MD5 checksums using external tools - its already there.
• Decrease time to access protected documents: Immense CPU power opens some doors.  Did the suspect password protect a document that is relevant to the investigation?  You can now test a wider range of candidate passwords in less time to speed investigations.

3. Password assurance testing (aka cracking)

• Decrease password cracking time: if your organisation regularly tests password strength by running password crackers you can use Cloud Compute to decrease crack time and you only pay for what you use.  Ironically, your cracking costs go up as people choose better passwords ;-).
• Keep cracking activities to dedicated machines: if today you use a distributed password cracker to spread the load across non-production machines, you can now put those agents in dedicated Compute instances - and thus stop mixing sensitive credentials with other workloads.

4. Logging

• “Unlimited”, pay per drink storage: logging is often an afterthought, consequently insufficient disk space is allocated and logging is either non-existant or minimal.  Cloud Storage changes all this - no more ‘guessing’ how much storage you need for standard logs.
• Improve log indexing and search: with your logs in the Cloud you can leverage Cloud Compute to index those logs in real-time and get the benefit of instant search results. What is different here?  The Compute instances can be plumbed in and scale as needed based on the logging load - meaning a true real-time view.
• Getting compliant with Extended logging: most modern operating systems offer extended logging in the form of a C2 audit trail.  This is rarely enabled for fear of performance degradation and log size.  Now you can ‘opt-in’ easily - if you are willing to pay for the enhanced logging, you can do so.  Granular logging makes compliance and investigations easier.

5. Improve the state of security software (performance)

• Drive vendors to create more efficient security software: Billable CPU cycles get noticed.  More attention will be paid to inefficient processes; e.g. poorly tuned security agents.  Process accounting will make a comeback as customers target ‘expensive’ processes.  Security vendors that understand how to squeeze the most performance from their software will win.

6. Secure builds

• Pre-hardened, change control builds: this is primarily a benefit of virtualization based Cloud Computing.  Now you get a chance to start ’secure’ (by your own definition) - you create your Gold Image VM and clone away.  There are ways to do this today with bare-metal OS installs but frequently these require additional 3rd party tools, are time consuming to clone or add yet another agent to each endpoint.
• Reduce exposure through patching offline: Gold images can be kept up securely kept up to date.  Offline VMs can be conveniently patched “off” the network.
• Easier to test impact of security changes: this is a big one.  Spin up a copy of your production environment, implement a security change and test the impact at low cost, with minimal startup time.  This is a big deal and removes a major barrier to ‘doing’ security in production environments.

7. Security Testing

• Reduce cost of testing security: a SaaS provider only passes on a portion of their security testing costs.  By sharing the same application as a service, you don’t foot the expensive security code review and/or penetration test.  Even with Platform as a Service (PaaS) where your developers get to write code, there are potential cost economies of scale (particularly around use of code scanning tools that sweep source code for security weaknesses).

Your Thoughts?

What benefits do you see that I haven’t included in the above list?  Where do you agree/disagree and importantly, why?

Yesterday, Microsoft published the new Security Intelligence Report for the 2nd half of 2007. (home page is http://www.microsoft.com/sir, and the download page is here).

As one of the contributors for the report, I'd like to highlight the findings summary for the Industry vuln trends:

• Vulnerability disclosures decreased by about 5 percent in 2007, reversing a multiyear trend of increasing disclosures. Almost all of this decrease was observed in the second half of the year, which had the fewest disclosures since 2H05.
  
• Despite the decrease, the number of new disclosures across the industry remains in the thousands, with the number of disclosures in 2007 surpassing that of every other year in the study except 2006.
  
• The Common Vulnerability Scoring System (CVSS) used to score vulnerabilities in the NVD was revised in 2007 to increase its accuracy, consistency, and applicability. Retroactively applying the new formula to vulnerabilities disclosed in previous years classifies a much higher percentage of vulnerabilities as High-severity than was previously
  the case. The vulnerabilities disclosed in 2007 continue this trend, with High-severity vulnerabilities accounting for about half of the total number of vulnerabilities.
  
• Vulnerabilities requiring a Low-level of complexity in order to exploit accounted for
  about half of all vulnerabilities disclosed in 2H07. Although this number is relatively
  large, the number has declined significantly from earlier periods.

Here is the high level trend chart from the report:

Regards ~ Jeff

1. In the bottom right hand corner of the video window is a Menu button. Click it.
2. The video temporarily shrinks and the URL of the video displayed. Click the Copy to Clipboard button (this copies the YouTube video URL to your clipboard).
3. Go to the keepvid.com site. (There are a number of Web sites and programs that can save YouTube videos to your PC. Google save youtube for more options.)
4. Paste the YouTube video URL saved in your clipboard to the text box at the top of the KeepVid Web page.
5. Click the Download button.
6. Two options are displayed - .flv Low Quality and .mp4 High Quality. Click the link of your choice to start downloading. (A file named get_video is saved. Rename it to something a little more meaningful.)
   

In the case of the 3Com-Bain-Huawei merger it is spelled "sell Tipping Point". As has been widely reported since this deal was announced, the fact that a Chinese company would own a substantial stake in an IPS/security vendor has caused significant heartburn within the Federal Government. This same issue kept Sourcefire from being acquired by Checkpoint (I bet that 200+ million looks good right about now).  Todays article in the Washington Times indicates that Bain has officially notified the Treasury Department of its mitigation proposals including the selling off of Tipping Point.

In my mind the question is: Will that be enough?  Is it only the Tipping Point stuff that causes the issue?  Does 3Com have other sensitive technology.  I don't know, but I am sure the recent arrest of 4 Chinese people on espionage type of charges did not help the Bain position. Also, do you spin Tipping Point off as a public entity. If not do you find an acceptable buyer.  Does the fact that the buyer would have to be a US based company decrease the potential buyer pool, making Tipping Point less valuable?  All of these are great questions that are going to need answers before this deal is finalized.  In the meantime is being in M&A limbo taking its toll on 3Com.  Questions, questions, questions, but I don't have the answers.