The Security Skeptic

At the San Jose Network World Security Tour, an attendee asked an interesting pair of questions regarding archived data protection.

How can you ensure that archived data are tamper proof?

A popular means of protecting archived data against tampering is to employ encryption. If you only wish to verify that archived data have not been modified, you can compute a hash of the data using an MD-5 or SHA-1 algorithm when you create the archive. Save the hash separately from the archive. When you choose to restore or access the archive, compute the hash of the data you restore, and compare this hash to the one you computed and stored when you created the archive. If the values are identical, the archive has not been altered.

You can also digitally sign a hash when you compute it. This provides a means to verify the identity of the party who created the archive. And of course, you can use a bulk encryption algorithm to encrypt the entire archive to protect the data from unauthorized disclosure.

Many products are available to perform these functions, including Pretty Good Privacy Desktop.

The second question regarding archived data is interesting as well:

How can you ensure that archived data are deleted after a desired retention period expires?

This is achieved by marrying a scheduling process with a secure deletion/erasure technology. When archiving data, you must identify the retention period for the data. When that period expires, the scheduler should pass the archived data to a program that can securely erase the data. If you are using removable media, this process may involve some manual intervention, e.g., arms and legs activities to place the media in a device where software can delete the archived data from the media. Finally, you may wish to shred removable media (DVD, tape, even hard drives) to prevent digital dumpster diving and unauthorized data recovery.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID460 by Dave Piscitello  

Once some folks learn to recognize phishing email, they ruminate over the fundamental evil inherent in a phishing attack, and become tempted to protest or retaliate in some way. Resist temptation! Here's why...

Always bear in mind that phishers are criminals. Most sensible people would resist the temptation to stroll into a hideout and ask all the burglars present to stop surveilling your home, because they would justly fear (physical) retaliation. Visiting a phishing web site is essentially the same act. You are putting yourself at the mercy of whatever measures the phisher chooses to employ at his web site to protect himself, or to do more evil. Phishing web sites are not safe neighborhoods. Consider:

• While you are satisfying your indignation completing a web form with "leave me alone you evil SOB" in all the forms fields, the web site may be uploading a keylogger to your PC.
• Should you find an "unsubscribe" mailto or link at the phishing web site and add your email address, you are simply confirming to the phisher that your email is actively in use and inviting more spam and phishing email.

Leave protests to automated services like BlueSecurity (bluesecurity.com), report abuse to spam to antispam services like spamcop (spamcop.net), to antispam vendors (Barracuda, Postini, et. al.), or to the FTC (forward spam to UCE at FTC.GOV).

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID459 by Dave Piscitello  

Time for another question from the Network World Security Tour. I promise this series won't devolve into a text version of StrongBad eMail from HomeStarRunner.com...

How can spyware websites continue to operate once they are discovered?

Once spyware infests a computer, its mission is to spy upon the PC user, or to redirect or force the user to visit an affiliate web site. A second and equally important goal for spyware is to evade detection, so that it can continue its primary mission. Several observations can be made from this behavior.

• Spyware is stealthware. It's hard for an average user to know which web site installed spyware on his PC; in fact, most spyware-affiliated websites are discovered by antispyware software research teams and antispyware activists who trawl the net in search of offenders.
• Legal action is not "rapid response. Once spyware-affiliated web sites are discovered, the first response by antispyware software vendors and activists is commonly one of technology and countermeasure (e.g., add the site to a blacklist, analyze the spyware installer sample to obtain a signature and identify removal procedures, etc.). This is in my opinion the right response because it can have a material and immediate affect. Moreover, reporting and "hunting down" spyware-affiliated sites is a time-consuming process of tracking down the operators, determining which if any laws have been broken, and obtaining the cooperation of judicial and law enforcement systems to terminate operations or take the operators into custody is formidable for professionals, and more than the average user can tackle with any hope of success.
• The numbers work against us.Even if (enforceable) international laws existed, the number of spyware-affiliated web sites is estimated in the hundreds of thousands, making the task of enforcing the laws practically impossible.

As you see, it's not a simple matter of "weak international laws" as was suggested by the tour attendee who submitted this question. Spyware is yet another example of a virtual arms race, and for the moment, we're losing the battle.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID458 by Dave Piscitello  

In a recent a Seattle Times editorial, Sex, the Internet and the future, *Harvard-educated* Shaunti Feldhahn strongly decries the creation of the XXX top level domain (TLD), claiming that approval will "negatively affect untold millions of households worldwide".

Frankly, I was entirely ambivalent about this editorial and remain undecided about the creation of XXX, but the fact that Ms. Feldhahn threw her Harvard education in play as an implicit declaration of her intellectual superiority ticked me off.

I find (at least) three statements in Ms. Feldhahn's editorial lack accuracy and credibility.

The .XXX proposal claims that it will "move all pornography to one type of domain", but "Pornographers could keep all current domains, and merely add .xxx ones — they anticipate more than 100,000 new sites in the first year."

The New sTLD RFP Application for .XXX makes no claim that all pornography will move to one sTLD. It is extremely unlikely that 100,000 new web *sites* would be created. The .XXX Application estimates the size of the adult entertainment community at about 100,000 individuals. On average, these individuals have registered 10-20 domain names. This name-to-registrant ratio helps me make an important point. The same porn sites will simply have even more aliases than they have today! The pornography industry has proven itself remarkably adept at re-purposing and cross-linking their content. There are certainly millions of content "objects" of adult nature, but concluding that 100,000 new names equates to 00,000 new web sites suggests poorer reasoning skills than I expect from a Harvard grad.

If the fact that it's not more porn, but (mostly) the same porn reachable using different names is hard to grasp, think of a .BIBLE sTLD. Chances are that many of the web sites that already have names in one of the gTLDs wouldn't abandon their existing names, but might *also* register in .BIBLE because the context is valuable.

"Blocking porn sites would become harder, not easier."

Nearly all the content blocking technology I've used and reviewed - and I'll openly admit I haven't used every product, but I venture that I've used more than Ms. Feldhahn - has the ability to use a "wildcard" mechanism. Simply put, if you block the .XXX TLD (e.g., DENY *.XXX), then you block access to every name and hence site within the TLD, end of story. Blocking .XXX of course doesn't mitigate the already-complex process of identifying pornography hosted at sites with gTLD and ccTLD domain names, but the introduction of .XXX doesn't worsen this problem. It's important to note that if there were some mechanism to *force* adult entertainment to only use names from .XXX, the content blocking at the TLD level would probably satisfy the majority of households if not Ms. Feldhahn's.

"Consumer protections would be voluntary and self-enforced"

What the application does claim is that a carefully operated sTLD for adult entertainment may provide a means whereby consumer protections can be implemented. The .XXX applicants (ICM and IFFOR) will "incorporate a best business practices provision into the registrant’s domain name registration agreement and will develop compliance mechanisms to address non-adherence." The objective is to stem illegal and/or questionable business practices, e.g., the use of spyware, and reduce incidents of credit-card fraud, etc. Obviously, we don't know exactly how this will work from the application, but concluding that the protections would be voluntary and self-enforced is a rather *liberal* interpretation. Admittedly, any penalty that an sTLD might enforce, such as the loss of a domain name, would not be as severe as a public caning, but you can't always get what you want.

I also believe that credit card companies will work with the .XXX registry and registrars to provide registrants with financial incentives to behave. And while adult entertainment businesses may not care a whit about the negative impact of their product on untold millions of households worldwide, they absolutely care about money.

I remain undecided about .XXX, Ms. Feldhahn. I don't think it poses a clearer and more eminent danger than the one with which we must already contend, but I'm not convinced it will have any material impact on how we deal with porn on the 'net. But you don't help your cause if you choose to editorialize, evangelize, or campaign against .XXX, and fail to do your homework.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID457 by Dave Piscitello  

I have time to answer another question from the Network World Security Tour before I leave for a campus visit with my son. Again, I'll try to answer as I would if we'd had the opportunity during the Tour Q & A.

With the convergence of network and security devices, how does an organization guarantee the security of the security device?

This would have been my choice for "best question". Let's begin by considering the core software of a security device. The software model that I think results in a very reliable and trustworthy security device is one that is custom-purposed for security and security only. The code is very tight. No unnecessary software and services are included, and the code is carefully reviewed by security professionals. Protocol handlers and proxies are written to strictly conform to standards and interpret these in the most conservative manner possible.

Now, when security appliances begin incorporating routing, load balancing, and other networking functions, the security of the appliance *can* be put at risk. Why? Because security and complexity are opposing forces. Increasing the number and complexity of functions a device must support makes accurate and secure software development more difficult, and is one of many causes of exploitable code. A second consideration is "conservation of talent". The number of extremely competent security programmers is really quite small. The same is true for programmers who understand the routing protocols commonly used today. Even when a technology company finds competencies in both areas, that company still needs an extremely competent user interface design team that can keep the UI intuitive and feature-rich. Designing a UI for a security appliance is in my opinion extremely hard. Policy assertion through a UI must result in an unambiguous implementation or the organization will be more vulnerable to configuration error.

So how does an organization guarantee the security of a security device? If you are truly fearful of feature-creep, then you might choose best of breed and use singly-purposed devices in your network. But even this deployment is subject to configuration error, due to the degree of policy coordination you must introduce.

The simple answer is "test the hell out of your deployment". But this sort of empirical approach will tax any organization's manpower beyond most risk analysis. I'm not certain that an empirical method will ever suffice. Technology changes at too rapid a pace, as does policy.

Perhaps organizations can use "track record" effectively. Look at how widely deployed a device is. Get a measure of how the security community regards a device. How frequently is the device mentioned by experts as a candidate to solve a security problem of the nature and scale as yours? How frequently are vulnerabilities reported against the device you're investigating? How broad is the knowledge base and available expertise to administer the device? These metrics may seem to bias against the adoption of emerging technology, but if yours is an extremely risk-averse organization, you are probably *not* a candidate for bleeding-edge implementation. Internet history also illustrates that reputation builds (or deteriorates) as rapidly as technology: if a security product is disruptive enough to attract attention, it will undergo considerable scrutiny by security experts who will probably put it through more man-years of tortuous testing in laboratories than you could justify in your organization.

This was a long answer, and probably *not* what you wanted to hear. The short answer is "it's hard to do, expensive, and time consuming", which explains why it's not done all that often.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID456 by Dave Piscitello  

My DSL service is restored.

Six months ago, I investigated an apparent PPPoE interoperability problem between my ISP's router and new firmware release for my firewall. My ISP's IT folks suggested I specify a static IP rather than accept a dynamic IP assignment so that they could see if we could "force" the addition of a frame route to my /28 subnet following PPP negotiation. This unusual configuration worked, and we left the workaround in place in anticipation of a patch from the ISP's router vendor.

Two nights ago, my network dropped off the Internet. Upon investigation, and after the obligatory "forced march" through several levels of customer and technical support, I learned that my ISP had moved my access line to a new switch. The switch, of a different manufacturer, wouldn't complete PPPoE negotiations with the workaround configuration I'd applied to my Firebox.

The Lesson: I lost two days of service because I failed to document a temporary configuration change. That change not only became "permanent", but an eventual liability.

The good (?) news is that while testing the configuration with the "router guys" at Hargray, one of the techs noticed that my bandwidth was only 768 and that I was subscribed to 2 Mbps, so he corrected this as well.

I don't want to think about how long I've been operating at a third of the bandwidth I was entitled to... but if I were to guess, I'd say, "six months?"

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID455 by Dave Piscitello  

I'm participating in a multi-city security tour for Network World. Today, in Boston, attendees submitted so many questions about security that we could not answer all of them during the Q & A session. I promised to answer "some" on my blog, and will do so over the next few days.

How secure is IIS 6 on a Windows 2003 server with the Lockdown tool? Are other precautions necessary?

I wrote about IIS lockdown in a Watchguard Live Advisory column, How to Harden Your Microsoft Web Server. At the time, my web server was Win2K, but I've since experimented with and concluded Lockdown and URLscan are just as effective on W2K3. Properly configured for the types of content users can get from and post to your web site, it's a useful tool.

Other precautions, however, are necessary. How much time, talent and budget you invest on configuration ("hardening"), security hardware and host IDS of course depends on the type of service you run from your web.

If I had answered this in "real time", I'd have mentioned this subset of precautions:

• Begin by hardening your server OS and filesystem according to industry best practices (my column has some useful references, and you'll find more at MSDN and other sites dedicated to Windows server and IIS.
• Review any scripts you use to confirm they are not exploitable.

• Consider file system integrity software and commercial host intrusion detection software, if budget permits.

• Restrict management access.

• Audit not only your web traffic, but events related to web site administration as well.

• Investigate how 3^rd party advertising (e.g., Google AdSense), search, info feeds, and web site statistics sites operate, and (important!) what information they collect from visitors before you include such features on your site, and make certain these are reflected in your privacy policy.

Web sites that perform financial and merchant transactions and host regulated content (medical records) have substantially different risk profiles than a "free content" site like mine, and of course merit considerably more attention with respect to protecting (transaction) data integrity and unauthorized disclosure.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID454 by Dave Piscitello  

"Coping with Adobe Acrobat Plug-in" was one of the reasons I switched from Microsoft Internet Explorer to Firefox. My experiences with Acrobat and IE - over several years, on dozens of PCs of varying manufacture, using XP and Windows 2000 - lead me to conclude that these children really don't play well together and perhaps never will. I won't lay the blame entirely on Acrobat or Microsoft for the too frequent corrupted registries, failed installations and upgrades, and wretchedly incomplete "uninstall" incidents, but I did reach the point where I decided that opening a PDF in IE was A Bad Idea.

I had hoped that Acrobat and the new kid on the block would get along. And to date, they do. Mostly. One remaining gripe I have is that, irrespective of whether IE or Firefox is the browser, using Acrobat impairs my "broadband experience". The delay I inflict when opening a PDF file in a browser window is comparable to a timeout on resolving a domain name, which I coarsely define as "seconds past my patience threshold". In fact, I am often on the verge of concluding the page is not reachable when the PDF file finally appears.

Worse still is the delay when I try to visit a new URL in the same (tabbed) or new window. Maybe it's not worse, just "the same". I'm not a software engineer and admit without reservation that I don't fully appreciate the interaction of browser and plug-in software. Perhaps "release the PDF file from memory and visit this 3K page of HTML" requires some amazingly complex processing sequence. Frankly, I'm really not interested enough in this behavior to investigate at the process and traffic analysis levels. I only know that I dread dealing with PDF in a browser window and have modified my behavior to accommodate software shortcomings. This is a virtual world corollary to crossing the street to avoid the bullies who steal your lunch money.

If I'm really in a hurry and I've located the file using a Google search, I'll view the HTML. While the rendering is generally imperfect, I avoid the "launch delay". Is this a big deal? Honestly, if the PDF is a 2 page brochure, I can sometimes glean what I want from the page in the time that the Acrobat reader plug-in loads. If I'm in no hurry, or I see that the PDF is more than a megabyte (the "warning Will Robinson" threshold), I save the PDF and launch Acrobat Reader directly. Maybe this just seems faster, but while Reader is launching, I can use my browser. Remember that "release the PDF file from memory..." comment I made earlier? Try this sequence for a taste of frustration. Open a PDF file in a tabbed window in Firefox. Now open a second tabbed window. Return to the window with the PDF file and try to visit a different page. Try to switch to the second tabbed window you opened.

N o t h i n g   i s   h a p p e n i n g . . . (1 2 3 4 5 ...) ...

Before you ask, the same phenomenon occurs if you try to switch between "un-tabbed" windows (in IE as well).

Why am I griping about this? I'm hoping that someone of you knows some obscure Windows Registry setting or optimization, i.e.,

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Aggravating_Reader_PlugIn_delay

No? Go figure...

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID453 by Dave Piscitello  

Gunter Ollman has compiled a guide to Pharming attacks that is worth a look. The Pharming Guide begins with a thorough consideration of DNS and name (host) resolution services. This chapter sets the table for a thoughtful classification and careful examination of Pharming attack vectors and methods attackers use. Gunter describes a wide range of attacks, including:

• How rogue DHCP and Web Proxy servers can be used to redirect hosts on LANs and WLANs to an attacker's DNS server.
• Domain hijacking, similar domain name ("one letter off"), and Botnet name server registration attacks.
• Attacks against vulnerable DNS server configurations and DNS servers that are not current with critical patches and hot fixes.
• DNS spoofing attacks, including DNS cache poisoning, DNS ID spoofing, and the Birthday attack.
• Attacks against autoresolvers and search engines (e.g., page rank escalation).

If you weren't aware that there were so many types of DNS attacks, you should at least look at this chapter.

The paper concludes with a list of countermeasures and defenses IT staff can implement to minimize an organization's exposure to DNS attacks. Gunter's companion paper, Security Best Practice - Host Naming and URL Conventions, offers additional security measures organizations can consider when choosing and adding domain names and when establishing an organization's URL composition strategy.

Enjoy.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID452 by Dave Piscitello  

During a risk assessment, you identify and ascribe a dollar value to the (electronic) assets of your organization. Assets may include materials for which you have copyrights and patents, intellectual property, research, databases containing accounting, personal or similarly sensitive or regulated material, strategic and marketing plans. Any-thing "networked" that would cause you financial harm, expose you to embarrassment or legal action, inhibit or damage your ability to operate your business, or place you in violation of a government regulation is an asset.

Some assets aren't as tangible as others. The availability of your network infrastructure, your servers, and your endpoint devices is an asset. If you are an e-merchant or conduct a meaningful part of your business or derive substantial revenue electronically, availability is an asset. Actually, loss of availability is a liability: every minute you are not processing transactions and selling goods represents lost income. Companies whose communications and distributed processing for a manufacturing production line or parcel delivery service could be delayed or blocked by an attacker are as much at risk for loss related to availability as e-merchants.

Once you identify assets and have assessed their value, identify the risks to attack or threats each asset is exposed to. Unintended or malicious disclosure of pharmaceutical research, formulae or testing is a serious threat to a drug company. Disclosure of a patient's medical information is a serious threat to a hospital, and a violation of U.S. Federal Law. Modification of data is another kind of threat. Consider how a change the 4^th or 5^th decimal place of an interest rate used in amortizations will affect interest ac-crued or paid out. Imagine how a change in the 8^th decimal place of the value of pi might affect calculations critical to an unmanned space probe at NASA .

When developing a security policy, it's helpful to create a table or matrix. Identify

• Assets, their value, and location
• The nature of threats to each asset (disclosure, modification, theft, loss…),
• The ways in which assets are vulnerable to attack, for example,
  • Unintended or inappropriate disclosure of passwords, identity cards, etc., leading to unauthorized system or facility access,
  • Unauthorized file access, leading to unauthorized disclosure or destruction of sensitive information,
  • File integrity compromise, leading to errors in calculations, production problems, hazardous conditions, etc.
  • Unauthorized Operating System access, leading to misuse, inappropriate use, or malicious operation,
  • Denial of service or forced system or (server) software failure, leading to ser-vice interruptions, loss of revenue and business communications,
  • Theft of equipment, possibly leading to many of the above attacks.
• How you intend to remove (mitigate) or minimize the threat (file permissions and encryption measures you will take to protect file accuracy and availability; prevent unauthorized access; ways you will detect and block a denial of service attack…).

If you don't know what's at risk, and what threatens your assets, how can you take measures to protect them? If you don't know how much is at stake should an asset be lost, destroyed, stolen, or disclosed to unauthorized parties, how can you determine if you're spending enough or too much to protect them? Similarly, if you don't know the approximate per minute or hourly value of offering e-merchant service, how can you determine if you are taking adequate measures to remain on line?

Risk, threat, and vulnerability assessment can be a very complex process, and it's important that you have credible valuation of assets should you seek financial restitution in courts of law following an attack. Hire certified outside security auditors to perform a risk, threat and vulnerability assessment. If you choose to perform these assessments yourself, review guidelines established by organizations like The Information Systems Audit and Control Association & Foundation (ISACA) before you pursue this yourself.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID451 by Dave Piscitello  

I had the good fortune to work alongside Dr. David Clark (MIT), on a number of projects during the early days of MCInet. During that time, David always emphasized "scalability and security" as important metrics of good architecture and design. Since then, when studying a problem, I typically ask (myself), "can you deploy this solution across a large and geographically dispersed population, securely?"

Events like Hurricane Katrina illustrate that a legitimate answer to such a question is "no". Unfortunately, people and particularly the popular press don't acknowledge that "no" is an appropriate answer to problems that are not easily solved when large populations are involved, especially when the large numbers exceed practical and even imaginable limits.

Fear, frustration, and anger cloud and color our thinking where human suffering is involved. What begins as "Someone should be able to make this situation better" devolves into, "Someone didn't do his or her job, people are suffering as a consequence, and someone must be held accountable."

In most situations, I believe strongly in accountability. However, I also believe metrics play an important role in accountability. In the case of Hurricane Katrina, all foreseeable and imaginable upper bounds to the scale and extent of a natural disaster were exceeded. Holding anyone's feet to the coals following a disaster of this magnitude, especially while the crisis persists, is pointless.

If we set our emotions aside a moment, we generally acknowledge that problems are rarely solvable when there are no limits (upper bounds). We can anticipate and propose solutions to problems like "feed a dozen family members in your home on Thanksgiving Day", "feed a thousand people at a charity event in a hotel", and even "feed 10,000 people in a dozen hurricane shelters" because the problems are bounded. If only 10,000 people were affected by only the hurricane, FEMA would very likely have met the challenge.

Try designing a solution to, "feed and relocate the combined populations of possibly every Gulf Coast community between Texas and the Florida panhandle, including the largest city in Louisianna, with little or no highway or navigable water access, no injuries or loss of life, for an indeterminate time frame".

The problem is Biblical in proportion. No one at FEMA put, "able to feed thousands from a single basket of fishes and bread" on his or her resume. Let's acknowledge human limitations in our haste to ease human suffering and put ourselves in the shoes of those asked to do the impossible.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID450 by Dave Piscitello