Exactly three months ago, the whole IT sector was waiting with bated breath for April 1. The latest DOWNAD/Conficker variant–WORM_DOWNAD.KK–was poised to strike. We know that on that day, it would attempt to access 500 of 50,000 websites and download new malicious files. This led to fears–somewhat misplaced–that new, possibly damaging payloads could cause severe problems, not just for systems already affected by DOWNAD but the Internet as a whole. Many sectors assumed the worst.

April 1 came and went, and… nothing happened. Several days later, another variant appeared, but without the Internet ending (as some of the worst reporting would have led readers believe) most people believed that DOWNAD, as a major threat, was gone.

While it may no longer be as in the news at it was at its height, DOWNAD didn’t suddenly go away. Recent estimates from the Conficker Working Group place the number of unique IP addresses affected by the top 3 DOWNAD variants at well over 5 million. Even considering the group’s disclaimer of putting the number of actually infected systems at only 25-75% of that number, a minimum of 1.25 million infected systems is nothing to laugh at.

The Trend Micro World Virus Tracking Center (WTC) numbers bear this out as well. Almost 790,000 systems were found to be infected with DOWNAD variants in the first three months of the year. In the three succeeding months, that number was almost 1.9 million. Clearly, DOWNAD did not decide to quietly go away.

In addition, out of the public eye, DOWNAD went off and did something with all those infected systems: it went off and formed its own botnet. This was documented in mid-April by Advanced Threat Researchers Paul Ferguson and Ivan Macalintal. The short version, however, is simpler: DOWNAD was used to create a botnet. These can be used for the usual range of threats: spam, Denial of Service attacks, spreading FAKEAV malware, and so on.

Like it or not, malware threats are part of what users have to deal with day in, day out. Like anything people deal with regularly, people become used to malware threats. What was once noteworthy and unusual becomes dull and ordinary. However, this in fact does not make the threat any less dangerous. If anything, it can be argued that it makes the threat more dangerous, as users are more likely to be caught unaware of a threat that may not be something they’re looking out for.

In a very real way, threats like DOWNAD become part of the background noise that is a part of life on the Internet. While it may be unrealistic to expect individual users to keep in mind all threats, but good computing practices will help immensely. The most important one may be: keep your software up to date. This is particularly true for your operating system–a properly patched system would have been proof against most DOWNAD variants. Trend Micro users would have been protected via the Smart Protection Network, of course, but closing the underlying vulnerability would still have been essential.

The price of using your computer freely in today’s Internet may well be constant and unceasing vigilance.

Post from: TrendLabs | Malware Blog - by Trend Micro

Three Months Later: Where’s DOWNAD?

Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. 

A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:

Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets.

Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. 

So applying the flat tax, our Jones Widget's budget look like this

Notice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets.

Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. 

Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA.

So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems

There's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it.

Security budgets are often based on combination of last year's spending, this year's threat du jour(s), and "best" practices, i.e. what everyone else is doing. None of these help to address the main goal of information security which is to protect the assets of the business. The normal security budgeting process results in overspending (as a percentage) on network security, because that's how the budget grew organically starting from the 90s. 

A simple three step process to achieving a Security Budget that maps to business reality rather than security silver bullet fantasies is as follows:

Step 1. Gather the relevant data for where the enterprise is investing its dollars in IT. Let's assume our company is Jones Widgets.

Step 2. Apply a "flat tax" for security budgeting, for this example let's say 7%, so if Jones Widgets invests $5M in its Customer relationship systems, $2M in Order Management, and $1M in ERP, this is the starting point for assigning priorities on security budgets. This is the part that security people miss, you don't need to do asset valuation - there is a whole group of people in the business that have already done that for you. Your job is to enable the intent that they have already clearly communicated in budget decisions. 

So applying the flat tax, our Jones Widget's budget look like this

Notice that the starting point in this step is aligning the budget with overall Enterprise IT spending. Its not based on whatever area that infosec happened to invest in last year, or what someone at a conference said, its about starting by aligning with what your business values. Its not about security foo-fa-ra, its about Jones Widgets.

Step 3. Efficacy. Let's assume that the Customer Management and ERP systems are behemoth packages that are purchased third party apps, and the Order management system is built in house so you have the source code. The way that you choose to deliver security to third party purchased systems versus the ones where you design, build, and deploy the code will vary. So the next step after initially rationalizing the budget is to assess what's the most effective security I can get for each area. 

Its not that the business budget should trump the infosec budget, but its a very useful starting point. Moving off of those priorities should require a statement of efficacy that some security dollars are better spent in say the Order Management system, because the company controls the code. So if Jones Widgets' Order Management system is built in house, and the business relies on that to process orders, if that Order Management asset is compromised then its not like Jones Widgets can go and buy another Order system off the shelf from a vendor. Its their core business, their DNA.

So let's assume that Jones Widgets wants to scan its code, invest time in threat modeling and so on for its core business asset. This results in pulling 20% in from the ERP and Customer systems

There's no need to get wrapped around the axle on asset valuation, the business gives you a starting point, use it. Then only move away from that when you can make a concrete case on improving efficacy by altering priorities. Or put another way - its your job. Do it.