baker - botnet mitigation incentives problem

8/2/2019 Baker - Botnet Mitigation Incentives Problem

1/21

Botnet Mitigation: Is there a solution to the cybersecurity

incentives problem?

Todd M. Baker

I. Introduction

Cybersecurity has become a serious concern for individuals, businesses and nations,

and as society becomes more dependent on technology, finding solutions to cyber threats is

starting to gain the attention of policy makers. The Obama administration recently released

its cybersecurity plan for America, which addresses all kinds of threats from cyber warfare

to identity theft1. The NIST has also created a cybersecurity roadmap that is currently in

the RFC stage, and is attracting comments from private individuals, technology companies,

and technology industry think tanks2. Of all the cybersecurity issues being discussed, one

seems to rise to the top of the list of concerns botnets.

Botnets are dangerous networks of compromised computers, usually under the control

of a criminal organization, that serve as a platform for launching cyber attacks3. The

computers that are part of the botnet are known as zombies, and the controller is known as

a botherder. The networks can be very large, some have been estimated to consist of more

1See The Comprehensive National Cybersecurity Initiative, Whitehouse.gov,

http://www.whitehouse.gov/sites/default/files/cybersecurity.pdf.2http://www.nist.gov/itl/greenpapercomments.cfm.

3See Johannes M. Bauer & Michel J.G. van Eeten, Cybersecurity: Stakeholder incentives, externalities,

and policy options, 33 Telecomm. Poly 706, 706-07 (2009); Jennifer A. Chandler,Liability for BotnetAttacks, 5 Can. J.L. & Tech. 13, 13-14 (2006); T. Luis de Guzman, Unleashing a Cure for the BotnetZombie Plague: Cybertorts, Counterstrikes, and Privileges , 59 Cath. U. L. Rev. 527, 528-529 (2010).


2/21

than 12 million zombie computers4. The reason these networks are such a threat is their

ability to use a huge number of computers at the same time. The size allows them to

overwhelm network security measures, evade capture by masking the source of the attacks,

and profit from types of attacks that would not be worthwhile otherwise 5.

The networks are created by cyber criminals through a variety of means. The most

common method is exploiting vulnerabilities in computer operating systems and Internet

applications. These vulnerabilities allow hackers to install bots through malicious HTML

code on otherwise valid websites, through embedded code in PDF files, or by trojan horses

in email attachments6. Other methods include infected files on peer-to-peer file-sharing

sites, exploiting backdoors left by previous malware infections, and cracking weak

passwords.7

Botnets are used to send spam, to circulate malware (such as viruses), to steal

confidential information, to launch distributed denial of service (DDoS) attacks, and to

extort protection money from Web sites by threatening such attacks.8 Denial-of-service

attacks essentially shutdown the victims website or network by flooding it with traffic

from the zombie computers. The amount of traffic that can be sent by the largest botnets

4See Brian Krebs, Mariposa Botnet Authors May Avoid Jail Time, Krebs on Security

(http://krebsonsecurity.com/2010/03/mariposa-botnet-authors-may-avoid-jail-time/) (last accessed Dec.21, 2001) (stating that the Mariposa botnet contained upwards of 12 million zombie computers); TylerMoore, The economics of cybersecurity: Principles and policy options, 3 Intl. J. Critical InfrastructureProtection 103, 105 (2010).

the Reactor Mailer botnet ran from 2007 to 2009, at its peak sending more than 180billion spam messages per day, 60% of the global total; at least 220,000 infectedcomputers participated in the Reactor Mailer botnet each day. The Zeus botnet, bycontrast, uses key logger sof tware to steal online credentials that are relayed back to thebotnet herder; the botnet is estimated to be as large as 3.6 million computers.

5Jennifer A. Chandler,Liability for Botnet Attacks, 5 Can. J.L. & Tech. 13, 13 (2006)

6Id. at 14

7Id.

8Id.


3/21

can overwhelm even the best protected networks. These attacks can be used to extort

protection money from the victim9, or they can be part of a larger military offensive as we

saw in the Russian attacks on Estonia and Georgia in 200710. These botnet attacks pose a

massive threat to our national security considering how reliant our economy and

infrastructure are on technology.

The other uses of botnets are problematic as well. It has been estimated that over 80%

of all spam is sent though botnets, and the cost of dealing with this much spam is estimated

to surpass 10 billion dollars per year11. Botnets are also used to anonymize the traffic

associated with other hacking attacks, which provides cover to the attackers making it

much more difficult for law enforcement to apprehend them. These hidden attacks are

likely to be directed at high-value targets such as banks and critical infrastructure assets12.

It appears that botnets are going to continue to pose a threat into the future if nothing is

done to curb their growth. Over the past decade, cyber criminals have begun to change

their motives from personal satisfaction to monetary reward.13 Most botnets are controlled

by organized crime rings, and are rented to other criminals for considerable amounts of

money.14 This ability to generate income offers a powerful incentive for cyber criminals to

9Id.

10Johannes M. Bauer & Michel J.G. van Eeten, Cybersecurity: Stakeholder incentives, externalities,

and options, 33 Telecomm. Poly 706, 707 (2009)The DDoS attacks on Estonia in 2007 and the spread of the cryptic Conficker wormthat, early in 2009, paralyzed parts of the British and French military as well asgovernment and health institutions in other countries, are recent examples of attacks onnations and their civil and military infrastructures.

11Wikipedia, Spam (electronic), http://en.wikipedia.org/wiki/Spam_(electronic) (as of Dec. 21, 2011,

17:13 GMT).12

Tyler Moore, The economics of cybersecurity: Principles and policy options, 3 Intl. J. CriticalInfrastructure Protection 103, 105 (2010).13

Chandler, supra note 5, at 1314

Id.


4/21

continue creating botnets and developing new ways to use them. Also, the increase in

broadband internet availability will bolster the strength of the networks by increasing their

available bandwidth.

In this paper, I will discuss the current state of botnet mitigation techniques, and why

they have not been sufficient to stop the spread of botnets. Then I will discuss how the key

players in the information and communications technology (ICT) ecosystem suffer from an

incentives problem in relation to cybersecurity, and how this lack of proper incentives has

led to the ineffectiveness of current botnet mitigation strategies. Finally, I will explore

several proposed solutions to this incentives problem, and come to some conclusions as to

the strategy that the United States should adopt going forward.

II. Current Botnet Mitigation Methods and Their Limitations

Botnets are not a new phenomenon, and many different methods have been used over

the years to help prevent or block their use. The solutions cover the gamut from legal

liability for the botherders, to technical solutions such as antivirus and firewall software.

On the legal front, statutes such as the Computer Fraud and Abuse Act 15 seek to criminalize

the computer crimes that botnets are used to commit. Law enforcement has had some

success with shutting down botnets. The FBI has an initiative called Operation: Bot Roast,

which was created to disrupt and disassemble bot herders.16 Several botnets have been

shut down by the FBI through this operation, and at least six individuals have been charged

or convicted of computer crimes. One of the highest profile take downs was theAncheta

1518 U.S.C. 1030 (2008)

16Wikipedia, Operation Bot Roast, http://en.wikipedia.org/wiki/Operation_Bot_Roast (as of Dec. 21,

2011, 17:46 GMT).


5/21

case, where 20-year-old Jeanson Ancheta was captured in a sting and pleaded guilty to four

felony 1030 charges in connection with his creation of a 500,000-plus computer botnet. 17

Through operations like this, law enforcement is keeping pressure on these cyber criminals

and are certainly helping slow botnet growth.

While legal solutions have had some successes, there are substantial issues that limit

their effectiveness. The largest challenge is presented by the international scope of these

crimes that creates all kinds of jurisdictional and procedural issues that are very hard to

overcome. One particular case demonstrates this well. In May 2009, a huge botnet named

Mariposa was taken down by the Spanish security firm, Panda.18 The botnet had been used

to steal sensitive data from over 800,000 individuals, and this data was used to fraudulently

access the victims bank accounts. Three Spanish men were arrested for building the

botnet, but due to insufficient cybercrime laws in Spain, they may never see any jail time. 19

Owning and operating a botnet alone is not a crime in Spain, so the prosecution will need

to prove that they were also committing the fraud. The problem is that these men were

renting the botnet out to other organizations, and were not directly involved in the identity

theft and bank account fraud. While most developed countries have developed cybercrime

legislation, examples like this show some of the difficulty that can arise in international

jurisdictions.

The distributed nature of botnets also presents considerable forensic challenges to law

enforcement. Attacks move so quickly and are spread out through so many different

17Debra Wong Chang, Botherder Dealt Record Prison Sentence for Selling and Spreading Malicious

Computer Code, Cybercrime.gov, http://www.cybercrime.gov/anchetaArrest.htm.18

Krebs, supra note 4.19

Id.


6/21

computers, that trying to find the original source is like finding a needle in a haystack. It is

usually not until after the attack is complete that the computer forensic teams can sift

through the logs and find out where the command-and-control servers are located. By this

time, it is often too late because the botherder has simply moved the servers to new IP

addresses or domains. It becomes a game of cat and mouse, with law enforcement often

one-step behind.

Another key botnet defense strategy has been trying to block the infection at the host

computer level. Technical solutions such as antivirus software and firewalls have become

prevalent on almost all Windows-based computers. This software has helped slow the

spread of malware by blocking common vulnerable Internet ports on computers, and

allowing the detection and removal of known malware. It has not done a great job of

blocking botnets however. In order for these protective measures to work, they must be

told what to look for, and this is done through updating antivirus definitions.

Unfortunately, botnets have been able to use a combination of previously unknown

vulnerabilities and rootkits to install themselves in a way that typical antivirus software

cannot detect.20 Moreover, the safety that these products promise has given computer end-

users a false sense of security, which may actually increase the risk of compromise.21

20Wikipedia,Rootkit, http://en.wikipedia.org/wiki/Rootkit (as of Dec. 21, 2011, 18:30 GMT).

Rootkit detection is difficult because a rootkit may be able to subvert the software thatis intended to find it. Detection methods include using an alternative, trusted operatingsystem; behavioral-based methods; signature scanning; difference scanning; andmemory dump analysis. Removal can be complicated or practically impossible,especially in cases where the rootkit resides in the kernel; reinstallation of the operatingsystem may be the only available solution to the problem.

21See Bauer, supra note 10


7/21

Software developers have also attempted to secure their products by patching the

vulnerable pieces of code before hackers can take advantage of the security hole. While

they have always attempted to find and fix flaws and vulnerabilities in their products, it

used to be quite difficult to get the updates installed on end-users computers.22 Within the

last few years however, this problem has been addressed through automatic updates, and

this has greatly increased the speed at which computers become patched.23 This is very

important as most botnets spread through unpatched software vulnerabilities, and it does

appear to be having a positive effect on botnet mitigation.24 Still, it is nearly impossible

for developers to find and fix all the flaws before the attackers do, so all this does is cause

the attackers to work faster and quietly, so as to not tip off the developers about the flaws

they are exploiting.

The other effective mitigation practice has come from Internet Service Providers (ISPs).

ISPs are uniquely positioned to be able to monitor and detect botnet activity, and then

either block the malicious traffic or log it and assist law enforcement in apprehending the

attacker. They have been instrumental in shutting down several botnets over the past

several years25, and will be a key part of a future botnet mitigation strategy. Unfortunately,

many ISPs have refused to cooperate with law enforcement, and because of the distributed

nature of botnets, it will be necessary to have a majority of ISPs working together to be

successful.

22Chandler, supra note 5

23Microsoft Security Intelligence Report, http://www.microsoft.com/security/sir/default.aspx, (2011).

24Id.

25Microsoft,Battling the Rustock Threat,

http://www.microsoft.com/security/sir/story/default.aspx#!rustock.


8/21

III. The Incentives Problem

The single most identified problem with malware and botnet mitigation is that there is

an incentives problem when it comes to providing cybersecurity.26

Most botnet attacks

target individual companies and individuals, so the majority of the involved actors do not

suffer the direct consequences of the attacks. End-users may see some spam in their inbox,

but most of it is filtered by their ISP. Some end-users will be the victims of identity theft

due to an attack against a bank or other company holding their personal data, but most will

not recognize that is was caused by a botnet, and those not directly affected will not even

likely know it occurred due to the lack of breach notifications. Some ISPs may have their

networks slowed during a DDoS from their customers that are part of a botnet, but it is

easy to pass along the extra bandwidth costs to the customers. And while some software

developers may see their market share decrease due to insecure software, consumers have

proven they are more concerned with familiarity and ease-of-use than security features. 27

Because most of the actors in the ICT ecosystem do not feel the direct effects of security

breaches, they choose to only implement the minimum amount of cybersecurity. This has

brought some security researchers to conclude that cybersecurity should be viewed as a

public good due to the large number of externalities involved.28

26See Moore, supra note 12 at 107; Bauer, supra note 10 at 707; David Worthington, What Can Be

Done About Software Security,http://www.sptechweb.com/content/article.aspx?ArticleID=30849&print=true; Chandler, supra note 5.27

Microsoft has remained the market leader in operating system sales despite being the most insecure28

See Bauer, supra note 10 at 707.Although it is mostly provided by private players, cybersecurity has strong public goodcharacteristics. Therefore, from a societal perspective, a crucial question is whether thecosts and benefits taken into account by market players reflect the social costs andbenefits. If that is the case, decentralized individual decisions also result in an overalldesirable outcome (e.g., a tolerable level of cybercrime, a desirable level of security).However, if some of the costs are borne by other stakeholders or some of the benefits


9/21


10/21

reduced compatibility, and the availability of software licenses that hold the developers

harmless for damages due to insecure software.32

The negative externalities continue with Internet service providers. ISPs incentives are

a little more balanced than developers, but there are still strong security-reducing

incentives at work.33 First, the cost of designing and implementing network security

monitoring and detection equipment such as intrusion detection systems can be quite high.

Furthermore, these systems require constant updating and maintenance. Like developers,

ISPs also have legal provisions limiting their liability for losses related to cyber attacks,

which is certainly a security-reducing incentive. Finally, the cost of customer acquisition

in the ISP market is quite high due to the significant interruption changing providers

causes, so any measure that may encourage customers to leave is avoided if at all possible.

While some customers may prefer using an ISP that is security conscious, most would not

be happy if these new security measures at all inhibited their use of the Internet, which they

certainly would have to do in order to be effective.

Thankfully, ISPs also have some security-enhancing incentives. First, the cost of

supporting their customers infected computers is quite high help desk call centers,

additional infrastructure, and spam filtering all eat into ISPs already low profit margins.

The relatively highly competitive market can also be security-enhancing in that a bad

reputation (think AOL) can easily sway customers to other providers. Overall, ISPs have

32Id.

33Id.


11/21


12/21

With this in mind, it becomes apparent that the ultimate solution to cybersecurity threats

will require changing the risk model.

IV. Proposed Solutions

There have been many proposals aimed at aligning the interests of the ICT ecosystem

with cybersecurity goals. I will discuss the three major proposals in this section: tort

liability for software developers, tort liability for negligent end-users, and finally

regulation and potential liability for ISPs. Each of these proposals has the potential of

reducing cyber threats, and in the end, a combination of approaches may be necessary.

A. Tort Liability for Software DevelopersTort liability for software developers has been discussed for some time and in many

different forms.37 The proposals have based liability on general negligence law, product

liability law, or professional malpractice law.38 Each liability framework has potential pros

and cons, and all have received significant pushback from the software development

community.

There have been several cases against software developers for breaches of security,

where the plaintiff has attempted to use negligence law to impose liability upon the

developers.39 However, applying current negligence law to cybersecurity breaches has not

been effective for the most part due to some critical limitations of negligence law. First,

to state a claim for negligence, a plaintiff must plead and prove that: (1) the software

37See Michael D. Scott, Tort Liability for Vendors of Insecure Software: Has the Time Finally Come?,

67 Md. L. Rev. 425 (2008); Schneier, supra note 30.38

See Scott, supra note 37.39

See Scott, supra note 37 at 442.


13/21

vendor owed a duty to the plaintiff; (2) the vendor breached its duty; (3) the breach of duty

was a cause-in-fact of the plaintiffs injury; (4) the breach was a proximate cause of the

plaintiffs injury; and (5) the plaintiff suffered compensable damages as a result of that

breach.40

Meeting all of these elements is quite challenging for plaintiffs due to the nature of

software vulnerabilities. First, it is not clear that software developers owe any duty to their

customers whatsoever. In fact, almost all end user license agreements expressly disclaim

any duties or warranties.41 Assuming a court did find a duty, the plaintiff would need to

show the developer breached that duty by not exercising reasonable care to make his acts

safe for others.42 This would require proof that the developer could have used more

secure development methods but failed to do so. This kind of proof would be hard to

obtain due to the non-standardized and rapidly changing nature of the software

development industry.

Proving causation would be equally difficult as the plaintiff would first need to show

that but for the software defect the damages would not have occurred or that the defect

was at least a substantial factor in causing the damage, and that the damages were a

foreseeable result of the defect. The reason these could be difficult to prove is that in order

for a software defect to turn into damage, a third party hacker must have exploited the

defect. This criminal act could be seen as an intervening cause, and intervening causes

traditionally break the causation chain. The defendants would argue that the hacker had

actually caused the damage and that liability should rest with him. Courts have generally

40Id.

41Schneier, supra note 30.

42Restatement (Second) of Torts 4 (1965)


14/21

held that, except under extraordinary circumstances, a party is entitled to assume that third

parties will not commit intentional criminal acts.43

These limitations in applying negligence law to software developers have led some to

suggest that product liability law should be used.44 Under this theory, software would be

treated like any other product, and defects would be handled under a strict liability

framework. The Second Restatement describes a design defect as occurring when the

foreseeable risks of harm posed by the product could have been reduced or avoided by the

adoption of a reasonable alternative design . . . and the omission of the alternative design

renders the product not reasonably safe.45 The key here would be the foreseeability of the

damage caused by the defect. Plaintiffs would argue that it is widely known that software

defects cause significant damage in the way of lost data, intellectual property theft, and

network downtime. Defendants could counter that it is impossible to foresee how software

is going to behave until it is released into the market and installed in a customers

environment. Courts would most likely side with the defendants due to the immense

complexity of modern software and the overwhelming task of predicting its behavior.

The third proposed method of finding developers liable is under professional

malpractice law.46 Under the doctrine of professional malpractice, one who is deemed a

professional will owe the other a duty to act not just as a reasonable person under the

circumstances, as required by negligence law, but to meet a high standard that of a

43See Scott, supra note 37 at 451.


45Restatement (Second) of Torts 402A (1965)

46See Scott, supra note 37.


15/21

professional in that particular field.47 The key word in that definition is professional,

because in order for the law to apply, the industry must be one in which people are licensed

according to certain predefined standards. Software development probably does not

qualify under this test because of the lack of professional standards, and the multitude of

different certifying organizations, and several courts have declined to impose malpractice

law on the profession.48 It is possible, however, that recent changes to the profession have

brought it closer to the definition of a profession, and if courts were once again asked to

consider the question, they could find differently. In particular, if a company had hiring

standards that required a certain certification or education, and it was found that a

developer was not following those standards, then it certainly would not be unreasonable

for a court to find malpractice.

Under any of the proposed liability frameworks, there are some serious concerns about

the effects developer liability would have on the software industry. Society has benefited

greatly from innovation when it comes to computer software, and many people fear that

imposing liability would significantly hamper innovation. Many of the most impactful

programs have been written by individuals or small startups who would find it difficult to

rationalize buying professional liability insurance or risking personal liability for

developing software that may never turn a profit. It could also have a detrimental effect on

the opensource software community that relies heavily on individual volunteers. This risk

would need to be addressed by any changes in the law that made it possible to hold

developers liable.


48Id.


16/21

B. Tort Liability for End-UsersFinding end-users liable for the torts committed by their zombie computers is another

proposed solution for increasing security incentives. [T]he common law of negligence

can be extended to govern the liability of individual zombies for botnet attacks

[even though] the owners of zombie computers are not committing intentional torts.49

The law allows these end-users to be liable for being negligent in carelessly permitting

their computers to cause harm to other computers.50 The negligence cause of action

suffers from many of the same limitations discussed previously in the section on

negligence liability for software developers. Plaintiffs would still have difficulties finding

a breached duty, and proving causation. In a majority of jurisdictions, the botherder would

be seen as an intervening cause and would break the causation chain.51

To establish end-user liability, most jurisdictions would need to create a continuing

duty of care to other network users. 52 This would most likely require legislative action, as

courts do not appear to be ready to make the change on their own. I do not expect that this

would ever occur due to the almost certain public uproar that would result. Most people

would probably find this solution akin to punishing the victim since it is so difficult to keep

a computer safe on the Internet today.

C. Regulation and Potential Liability for ISPsOf all the proposed solutions for mitigating botnet activity and incentivizing the

adoption of cybersecurity measures, regulation of ISPs appears to be the most realistic and

49See Guzman, supra note 3 at 538.

50Id.

51Id. at 548.

52Id. at 554.


17/21


18/21

The first step would be to regulate the detection of botnet behavior. There are several

concerns to be addressed in this step from the technical means to privacy implications.

There are many different technical methods to detect botnet activity, but all involve doing

some level of inspection of the traffic between the ISP and their customer. The traffic

would be inspected for known botnet command-and-control server addresses, and for signs

of common botnet attacks. The list of known botnet addresses would be compiled by

various security organizations and other ISPs, and would be centrally stored in a

government-operated database. This database would improve over time through the

combined efforts of the ICT security organizations. Inspecting traffic for certain

destination addresses would not be intrusive, and should not raise any privacy red flags.

Searching for signs of botnet activity could also be done fairly non-intrusively, but it would

at least require inspecting the port and protocol of the traffic. This is the area of inspection

that raises privacy concerns due to the fact that the ISP could use deep packet inspection

or other techniques that can also be used for monitoring customers Internet traffic or

tracking their online behavior.53 These privacy concerns would need to be addressed

either in the regulation or in separate privacy regulations. ISPs should also be given limited

liability for any data breach that occurs through their inspections to encourage compliance

with the regulations.

After detection, ISPs should have a predefined plan for reporting the activity to the

central database of known security threats. This database would be used by other ISPs for

detection purposes, but would also be very useful for law enforcement agencies when they

53Maxim Weinstein, Comments on FCC cybersecurity roadmap RFC,

http://www.stopbadware.org/pdfs/fcc-roadmap-comments.pdf(Sept. 23, 2010)


19/21

are performing criminal investigations. The data would need to be anonymized to protect

the identity of the compromised customers, and ISPs would need to once again be given

limited liability for sharing the data.

Once the threat has been identified, the customer should be notified that their computer

has been compromised. The ISP is in a unique role to identify the specific household in

which the device is operating. This implies a responsibility on the part of ISPs to notify

their customers.54 This initial notification can be as simple as an e-mail or text message,

but could also be accomplished by a letter or phone call if it is determined that customers

would respond better to those types of communications. It should contain the type of

malware detected, the time it was detected, and some suggested remediation methods.

Several detection and notification initiatives are underway around the world. The

Australian Internet Security Initiative is a government-led effort to collect bot data from

multiple providers, parse it out by specific ISP, and feed the data to the relevant ISPs.

Those ISPs agree, in exchange for the data, to notify their customers about the infected

machines.55 Germany has also recently started the Anti-Botnet-Advisory Centre, a private

industry initiative aimed at supporting citizens in protecting their computers from botnets.

Both of these initiatives can serve as good examples of the types of detection and

notification that is most effective.

A more controversial method that could be used is quarantining customers computers

if the customer fails to remedy the infection after a set period of time. This would

effectively shut down the threat posed by the compromised computer, but could also be

54Id.

55Id.


20/21

seen as overreaching. Essentially, once a customer was notified and failed to fix the issue,

any Internet requests from their computers would be redirected to a walled garden56,

wherein they will find detailed remediation instructions, including download links for

removal tools.57

The final part of a complete ISP botnet remediation scheme should be the creation of a

central helpdesk. This would certainly be controversial due to the cost involved, but it

should be possible to develop a payment structure that requires software developers, ISPs

and end-users to share the cost. For example, a small tax, say 1 percent, could be levied on

all revenue generated from software sales and internet access fees, which would put some

of the burden on developers and ISPs. Additionally, each time a user called the helpdesk

they could be charged a minimal fee ($10 perhaps). In a system like this, all of the actors

would share the cost of protecting and remediating malware and botnets, and this makes

economic sense since cyber security is a public good.

V. Conclusions

Botnets and other cybersecurity attacks continue to pose a significant threat to the

future of the Internet as an economic engine of prosperity. It is apparent that even in light

of large investments in cybercrime law enforcement, criminal law alone will not be enough

to stem the growth of these threats. The ICT ecosystem actors that have the greatest ability

to combat these threats currently do not have proper incentives to invest heavily in

56A predefined site or small number of sites that would allow the customer to learn about the malware

infection, and would offer assistance in remediating the problem.57

The Australian Internet Security Initiative has created a site like this that can be found athttp://icode.net.au. The site contains a section devoted to educating users on how to avoid infections,an area that provides self-help instructions and downloads, and a list of local computer professionalsthat can be hired to help deal with the infection. Once the computer has been cleaned, full Internetaccess is reinstated.


21/21

baker - botnet mitigation incentives problem

Documents