The Security Skeptic

Demosthenes Ikonomou and Panagiotis Saragiotis published an article in the ENISA Journal titled Technologies for Improving the Resilience of the Networks that evaluates the effectiveness of IPv6, DNSSEC and MPLS in improving the resilience of public eCommunication networks. I'll assume that eCommunication networks are IP based, that we're really talking about the Internet, that eCommunication network is a pop culture appellation and I'm out of touch:-)

The authors focus on describing the positive properties and potential value additions of each technology. The article serves as an interesting executive summary of a longer ENISA report, RESILIENCE FEATURES OF IPv6, DNSSEC AND MPLS: Resilience of communication networks. This paints a somewhat inaccurate picture of the report, which concludes that all these technologies "have the potential to improve resilience to some degree, although some of the resilience improving features may be overstated by advocates. In some cases there are even important concerns about increased risksto resilience by using these technologies."

I don't believe the authors make certain a compelling case for IPv6 contributing to resilience more so than IPv4. The authors point to IPv6's large address space and claim that this will make opportunistic attacks such as worms against IPv6 hosts. They claim reconnaissance probing (scanning) will be hard if not impractical. These are mere inconveniences for modern attackers and won't eliminate opportunistic attacks. At most, we could concede that IPv6's vast address space will alter attack forms but opportunistic attacks won't disappear. Instead, the characteristics of what will be labeled an opportunistic attack will change as attackers adapt to a new protocol deployment. The authors also point to the mandatory implementation of IPSEC in IPv6 and argue that encryption and authentication will be available when needed. IPSEC is a good example of how service availability and scalability are different beasts: the challenge of deploying IPSEC has little to do with whether the security protocol is available and everything to do with choosing and deploying an authentication method that scales to large numbers of users. The authors also underestimate the power of the installed base of SSL and the scalability of a transport versus IP level solution. SSL/TLS is ubiquitous, easier to deploy, and able to support widely accepted single and multi-factor authentication methods in multi-vendor deployment scenarios.

IPv6 is, for better or worse, the successor protocol to IPv4, but let's not fool ourselves into believing it's more than it is. After more than a decade of extending the IPv4 infrastructure to accommodate scale, performance, and resiliency needs during a profound period of Internet growth, IPv6 is "incidental" and brings nothing to the table but more addresses and an unfortunate upgrade. We are only changing protocols because we are the victims of success and we have waited so long to do it that all the intended incremental value of v6 over v4 is overtaken by events.

The authors did a nice job of explaining DNSSEC's value, although I would have liked to see them take a less academic approach, broaden their vision,and explicitly mention how DNSSEC would help mitigate redirection (DNS response rewriting, SAC032). I realize this is a MITM attack, but a concrete example of commercial abuse would have been refreshing. The article doesn't talk about problems operators encounter when implementing DNSSEC, nor does it talk about some of DNSSEC's problem areas (resolver and traffice overhead, the challenge of deployment when a hierarchical trust model is required, key rollover). These are covered to a degree in the full report.

The article doesn't explain whether IPv6/MPLS networks are better than IPv4/MPLS networks. It speaks to the ability to provide protection (basically, a pre-computed alternative route) and restoration services, but it fails to mention IP level routing alternatives to MPLS that provide similar resiliency characteristics, possibly without the considerable configuration complexity MPLS introduces.. (Frankly, I think the report makes more of route convergence following a failure than is merited). The longer report sheds more light on deployment considerations and the MPLS section alone is worthwhile if you download the PDF and are about to shy away from reading an 80 page report.

I never envy authors who are tasked with writing executive summaries. In this case, the authors explain the benefits of IPv6, DNSSEC, and MPLS well enough but they do a disservice to the full report by only catering to the positive and avoid the negative. I do think you will get more out of the full report, even if you read it in chunks. I'm not fully in agreement with either the article or report, but the report will give you a clearer and better balanced discussion of the evaluation process that led to the conclusions and assertions.

Archived at http://www.securityskeptic.com/arc20090701.htm#BlogID735 by Dave Piscitello  

Colleague Laura Mather begins a series of blogs describing how e-crime affects people every day. Laura makes an important observation at the outset of this series. Online scams are highly sophisticated now. In the past, security pundits could look at an e-scam and pompously conclude, "Jeez, only an idiot could fall for that". Today, educated, intelligent and computer-savvy individuals are *targets* because they usually have savings, assets, or credit. The criminals recognize they are smarter than the low hanging fruit and they've spiced up their attacks to deceive this more cautious, thoughtful class of victims.

Laura will highlight two cases of fraud in this series: a Nigerian inheritance scam and an online work-from-home drop-ship scam. My reaction is, "An educated, intelligent, computer savvy individual fell for one of these?" I'm eager to learn more. I encourage you to visit Silver Tail Blog, read Laura's introduction, and look for the case studies as Laura publishes them.

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID722 by Dave Piscitello  

Eugene Schultz wrote a nice piece in the August 2008 issue of the ISSA Journal on Identity Management. What I like about this particular article is that it is it's neither hype nor hard sell. Instead, Schultz gets to the heart of the hard realities of deploying identity management. Let me quote some of the good insights from this article and explain why they are spot on.

Schultz claims that it's critically important to achieve "a genuine understanding of the fundamental difference between identity management and identity management technology". I agree. Many IDM projects start and fail with the proposition that the organization simply needs new identity management technology to improve its security. A war story shared by one of my colleagues serves as a good lesson for any organization that's about to launch an IDM initiative. My colleague's organization had several minor incidents, all related to password sharing. How was this problem presented to management? "We have too many passwords to remember so staff often ask colleagues to share accounts when they forget their own." The organization introduced a slick RADIUS/AAA appliance to implement single sign-on but retained a user accounts policy that allowed short, static passwords. In this scenario, the organization had done as much to make an attacker's life simpler as it has to eliminate the problems created by password sharing. Password related incidents continued and with graver results. The lesson? Identity management requires careful planning at several levels - policy, education, technology, and implementation - to assure that the organization makes considerable gains in the security's Triple-As while continuing to meet the information networking needs of the organization.

Schultz also claims that an Identity management effort is "good only to the degree that the resulting mechanisms and processes are pervasive..." and that it must affect "every access to every system, network, application and database - with no exceptions." I strongly agree. An organization can't enforce an identity policy that applies to staff but makes exceptions to executives, or a policy that fails to address the challenges that guests, contractors, and mobility introduce. Similarly, an organization can't enforce an identity policy that is readily circumvented by staff who choose to ignore policy for expediency's sake, install a departmental database, and use the built-in user account system.

I'd also encourage Schultz and readers to consider expanding his notion of pervasive to apply to every access, by every user, from any endpoint. The most prevalent and pernicious activities besieging the Internet today are impersonation attacks. Thus, I strongly encourage anyone who is considering Identity Management to consider identities beyond the traditional Triple-A (Authentication, Authorization, Auditing) but also in the contexts of authenticity (data integrity and data origin verification) and admission control (verifying that an endpoint device poses no threat to an organization's information and networking asset before granting a user access via that endpoint device). For more on this Quint-A approach, read Improve your branch office security, one "A" at a time.

I've only scratched the surface of the many good insights Schultz offers in his article. He emphasizes the importance of developing requirements, setting criteria to assure that the identity solution scales well and is not overly complex, and determining that the solution is compatible with the existing IT environment (remember, it must be pervasive!). A very good read, indeed.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID701 by Dave Piscitello  

Susan Crawford, a visiting associate professor at Yale Law School, was recently asked to give testimony to the U.S. House of Representatives' Committee on the Judiciary, Task Force on Competition Policy and Antitrust Laws. The subject of the hearing was, broadly, net neutrality and free speech on the Internet, or specifically, whether Internet access network providers should be allowed to discriminate based on the origin and content of traffic they transport. In her testimony, Susan speaks to three issues that form the bases of the net neutrality issue: (1) the Internet is rapidly supplanting all former communications infrastructures and will soon become an indispensable delivery mechanism for all forms personal and business communications, information and entertainment; (2) Internet access providers operate today as "an unregulated duopoly with enormous market power that has every incentive to discriminate against speech (and products and services)", and (3) Congressional action is needed to ensure, in advance, that access to the Internet is provided in a nondiscriminatory fashion.

Susan does a marvelous job of juxtaposing the concept of "common carriage" (serving customers without discrimination) as historically provided in telegraphy, telephony, etc. against the Internet, which is capable of supporting a a virtually limitless set of applications *and* providing a global platform for free speech. Susan explains how the Internet disrupts the traditional perception of "one network, one service (application)" more dramatically than any predecessor network and how traditional markets and demarcation points of private operators who are major players in transport are threatened by this shift in paradigms. She offers examples of the measures and business practices private operators propose and use to protect their traditional markets and explains how these actions not only fail to serve the public interest but are characteristically discriminatory and sufficiently arbitrary as to threaten innovation. Susan also calls attention to the even more disconcerting consequences of content and origin discrimination: censorship and information "cleansing".

Crawford's is a remarkably complete and thoroughly insightful account of the net neutrality and free speech issue. I haven't found any discussion on this topic that comes close to being this informative. I strongly encourage you to read it.

You can find Susan Crawford's testimony here.

Archived at http://www.securityskeptic.com/arc20080301.htm#BlogID677 by Dave Piscitello  

WebProNews reporter Jason Lee Miller does an admirable job of characterizing the debate over the existence or non-existence of domain name front running in his article, Domain Frontrunning: A Ghost In The Machine. I like this guy. He did his homework to the point of getting the chronology of events as well as the meat of the matter correct. In particular, he honed in on several of the most important statements from the SSAC report on Domain Name Front Running by emphasizing that the SSAC found no evidence of frontrunning in the 120 complaints submitted and SSAC doesn't say that front running doesn't happen, only that SSAC could find no evidence that it did among those 120 complaints. He accurately reported counter-statements by Jon Nevett that domain name front running does exist, that Network Solutions had evidence to prove it, and that confidentiality agreements with client prevented him from disclosing details. He also obtained some very sharply worded quotes from Jay Daley, author of a Nominet position paper debunking the existence of front running, who challenged Nevett's claims and insisted on seeing the data. Read the article, and expect to read more on this topic here in the future. SSAC didn't find a smoking gun among the 120 claims submitted by Internet users, but as a long-time X-files fan, I'll leave you with, "The truth is out there... somewhere."

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID674 by Dave Piscitello  

I meant to write about the Pwnie Awards *before* they were awarded but real work interfered with blogging.

The Pwnie Awards celebrate the achievements and failures of security community. My favorite awards this year are:

• Most Overhyped Bug, to the MacBook 3^rd party wireless driver vulnerability. I love Apple Computer, but this incident could easily have earned them the

• Lamest Vendor Response Award. Amusingly enough, this award went to the OpenBSD team, who wouldn't admit that a reported bug was indeed a bug. Core Security had to demonstrate how an IPV6 packet processing vulnerability could be remotely exploited before the folks at OpenBSD took a serious look at the problem.

I don't want to steal the Pwnie Award's thunder so visit the page and enjoy reading the rest of the awards. I only wish they'd come up with more awards categories. If we have enough embarrassing code in the wild to devote entire months to Apple, ActiveX, PHP and perhaps MySpace bugs, surely we can concoct additional categories.

Archived at http://www.securityskeptic.com/arc20070801.htm#BlogID637 by Dave Piscitello  

I found an article at TechRepublic entitled 9 things IT managers should think about in 2007 (you may need to subscribe to download the pdf). I like the concept of giving IT managers cues for 2007, but of the nine Shannon offers, these in particular need sharpening.

• Bigger is not better. Shannon suggests that "the ability to mask problems by overbuilding hardware does not mean we've solved the issue--it just hides the problem for a time. Similarly, the ability to build a data center in a rack doesn't mean that doing so is a good idea." I'm inclined to take issue with this point because it only considers overbuilding in one context. Other principle reasons for overbuilding are to provide "extreme case" capacity, to assure capacity is present in situations where measuring or estimating capacity, need, and growth are difficult, and even to simply invest for the future with budget you presently have that may not be available at a future time. Bigger may not always be better, but I'd rather err on the side of bigger than smaller.

• New does not mean stable. True, however early adopters are often faced with a problem no current technology or practice solves and so are forced to endure bleeding; simply put, they have no choice. Perhaps a corollary to this observation might be, "bleeding edge adopters should understand and factor triage into their planning".

• Virtual devices still reside on physical hardware. Shannon suggests that "at the end of the day, all those virtual servers live on a physical box somewhere. That box needs the same maintenance and support it always did and more, now that we've added yet more layers of complexity." I'm not certain why maintenance and support are harder with one box than many, but I think Shannon's latter point is more important: the *conceptual* and configuration complexity we add are often overlooked when we virtualize. I still find it useful to diagram networks and server farms as if they were all self-standing units, scribble the configurations for each, and draw a big fat box labeled "chassis" around them:-)

• Follow-through matters as much as execution. This is cleverly put, but I think some steps are absent in this missive and we should tease these out carefully. If I understand Shannon correctly, she's suggesting that you "Define an objective. Define an implementation plan that satisfies the objective. Execute the implementation plan. And finally, verify that the plan meets the objective."

• One-size-fits-all never fits anyone at all. Shannon claims that "Boilerplates, best practices, and the fabled “industry leaders” all suggest that one solution will fit every situation. We just have to ram it into our environment and everything will magically transform into rainbows and bluebirds." I think this is way off mark. Perhaps fabled marketing wonks and analysts who are paid to create and push markets make such claims, but no respected practitioner or consultant believes this. (Boilerplates) templates offer *examples* of how one might design a solution and those hasty or lazy enough to adopt a boilerplate without a careful analysis of the implications reap what they sow. Similarly, best practices are codicils of "what appears to work for a good many folks in similar situations to yours". The key words here are "appear" and "similar" - simply put, best practices should be treated as adaptable methods and not as exacting standards.

• It's better to invest time than to spend it. This is clever but not that helpful. Let me expand on this since I think it's a hugely important issue. IT must balance three T's: time, talent and technology. Today, the tendency is to throw technology at a problem and in so doing, reduce the need for talent (expertise) and reduce time. I recall my colleague Chris Blask saying, "Computers are fast and people are smart." Invest first in talent. Give them time to plan and choose technology that will allow them to be smart, *fast*, and you'll have spent your own time wisely.

• Failure is always an option, so fail early and often. This is an excellent point. The only thing I'd add is that IT managers should foster an environment where failure is understood as a possible outcome, but failures are treated as opportunities to learn and improve.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID582 by Dave Piscitello  

David Strom's recent Web Informant column considers whether Cisco, like past industry giants IBM, DEC, and ATT, is now ripe to be challenged and dethroned by a leaner, meaner, and hungrier upstart. The column can be found at http://strom.wordpress.com/2006/05/11/is-cisco-vulnerable/.

I found myself mulling over related questions: has Cisco reached the point where it acquires rather than innovates to stay competitive, and is it acquiring in reaction rather than anticipation of market opportunities and needs?

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID525 by Dave Piscitello  

The beauty of the web is that the newspaper "delivered to your door" can come from any corner of the globe. You can't appreciate how valuable this is until you live on an island with a small town, small circulation newspaper in a heartland of conservative Republicanism.

Three interesting articles and Op-Eds on Internet Governance appear in the Washington Times, New Zealand Herald, and The Times of India. The Washington Times editorial blasts the U.N. failing to include technology executives and experts onto the 40-member working group on Internet Governance (WGIG). I took a look at the member list and while I would not go so far as to call this "a team of bureaucrats" I agree there are no signs that Silicon Valley is directly represented. If nothing else, this Op-Ed illustrates the "let the Internet govern itself" attitude of tenured Internauts.

The New Zealand Herald column by Peter Griffin offers a somewhat centrist approach. Peter's column appears to say, "I've read all the proposals and alternatives. Some are truly scary and others rather petty. Overall, things aren't frightfully broken so can't we be like Miss Congeniality and focus our attention on more important matters like 'world peace'?"

The Times of India is a good example of the community that feels the U.N. should have oversight. The article claims that India is in favor of models for Internet Governance that exhibit inclusion, inter-governmental and multilateral representation, and broad (multi-) stakeholdership, and identifies two models among the four proposed by the U.N.'s WGIG as "in line with India's thinking". Both models move oversight from the U.S. Department of Commerce and into the U.N. This is pretty much the antithesis of the opinion expressed in the Washington Times.

You rarely find a broad spectrum of perspectives and opinions on any one subject in a small town paper. The Internet offers such a rich opportunity for sharing knowledge, opinions and ideas. Pray that the folks who ultimately decide where and how the Internet is governed don't lose sight of the value of a single international resource.

Archived at http://www.securityskeptic.com/arc20050701.htm#BlogID435 by Dave Piscitello  

Steve Fallin wrote an interesting piece at WatchGuard Wire on Skype. In the piece, Steve explains how skype adapts to and evades firewall egress filtering policies. Skype is exactly the kind of application I write about in my blog #418.

Steve's reaction to Skype and P2P's that behave like Skype is one of fear and awe. Steve and I share a fear of applications like Skype because they defeat perimeter security policies. Blocking them involves touching desktops (yuck), adding more NIDS, reactionary policies, and an unproductive rejection of innovation. Steve suggests that Skype may be the wave of the future, and maybe we should look at P2P as a paradigm for network security.

I agree with Steve that P2Ps present a paradigm shift in application behavior that "perimeter mentality" security measures can't block or defeat. I find Steve's speculation both intriguing and consistent with recursively layered architectures. HTTP is in one sense becoming the link level protocol (PPP) of distributed applications. You could think of all the diversity above HTTP as a multiprotocol application network. If history repeats, we'll reject multiprotocol networks, weather a mulitprotocol war and one protocol and application architecture will emerge as the victor.

Before this comes to pass, however, I believe admission control technology will evolve to allow IT to "examine the DNA" of an endpoint before it is admitted. Today, network admission control is still in its infancy. It focuses on whether an endpoint is infected with malicious code, which is nice, but not nearly enough. I see admission control evolving to a point where an organization can check that authorized software, appropriate licenses, and local system security configuration all satisfy policy before a device is admitted to a network.

I can also imagine a time when sensitivity labels might be associated with files. An endpoint might be barred from connecting to networks where its presence on the network would expose that information to unauthorized access and misuse, and (importantly) make the network operator accountable and liable for accepting it as well as how it is used once accepted. Today, organizations worry about information leaks; for example, if you operate under HIPAA regs, you worry that a patient's medical information will be disclosed to unauthorized parties. But organizations should also worry about situations where illegal files are introduced into their network. Is it easier for you to block endpoints that have images of child pornography, or provide evidence in a court of law that you did not knowingly possesses these files after they'd been uploaded to your server?

If you have an opinion about Scott's commentary, visit WatchGuard Wire. If you have an opinion about mine, contact me.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID421 by Dave Piscitello  

Find time to read William Finnegan's commentary, Homeland Insecurity, in the February 7, 2005 issue of The New Yorker.

In the column, Finnegan refers to Stephen Flynn's book, America the Vulnerable, where Flynn draws an analogy between the current state of U.S. "preparedness" against terrorism and the eight months following Hitler's invasion of Germany in 1939, dubbed The Phony War. Finnegan provides facts, background and statistics to corroborate Flynn's analogy, including a sobering look at how the Department of Homeland Security, DOD, Justice Department and Bush Cabinet compete rather than cooperate, and how operators of critical infrastructures and airlines have successfully lobbied to avoid the expense of improving industrial security practices.

Finnegan describes the DHS as "the discouraged, disjointed beast that Michael Chertoff will soon inherit". He concludes the comment with a profound but hopefully not prophetic quote from Flynn...

"The United States is going through its own version of the Phony War. The French and the British did not seriously prepare, when they had the time, for the new style of blitzkrieg warfare that Hiltler had introduced in Eastern Europe. By May 1940, when he invaded France, it was too late."

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID368 by Dave Piscitello  

Jody Patilla sent me a link to a very interesting - and sobering - article in the Economist. Move over, Big Brother... examines how pop technology like camera and video cell phone technology takes us beyond the Orwellian notion that "Big brother is watching you" to "everyone is watching you, and digitally recording what many of us consider private actions". The Economist calls this a process of *democratising surveillance*...

You really ought to read this column. I've complained about the difficulties of obtaining a cell phone without a built-in camera. Apparently, my cell phone needs lie well outside the public norm, as camera phone sales, approaching 200 million units annually, outnumber digital camera sales by a factor of three, and film cameras by a factor of four. This phenomenal figure underscores the column's concern that (illegal) surveillance is essentially commoditized (i.e., "cheap": consider how many of these phone are free with an annual service contract, and how even discarded models can continue to have *interesting* applications).

The Economist doesn't paint an entirely negative picture, and cites some benefits news media and parents can derive. It also mentions how politicians and social icons must re-think how they act in public, given that anyone within lens range is a potential papparazzi. The concluding paragraph sums up the situation nicely...

"The surveillance society is on its way, just as privacy advocates have long warned. But it has not taken quite the form they imagined. Increasingly, it is not just Big Brother who is watching but lots of little brothers, too."

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID361 by Dave Piscitello  

For the past two years, I've hosted the SC chapter web site of the ISSA. I maintained a security library of hundreds of security articles worth reading. Unfortunately, we could not muster sufficient numbers to meet ISSA chapter criteria. Last month, I retired http://www.issa-sc.org.

I have relocated the security library to http://www.securityskeptic.com/library.htm. I am also in the process of adding more articles and resources. The library has approximately 500 resources listed, and my goal is to double this by 2005.

If you have read a security article worth recommending to your peers, please email the hyperlink to me and I'll add it.

Archived at http://www.securityskeptic.com/arc20040901.htm#BlogID308 by Dave Piscitello  

I read a good article by K. K., Mookhey at SecurityFocus.com today, entitled, "Common Security Vulnerabilities in e-commerce systems". The article corroborates much of what I harp about when I get on my "Sad and Deplorable State of Internet Security" soapbox.

In my Networld+Interop 2004 presentation, Implementing Strategic Security, I have a slide titled, "What should you fear most?" The item list includes three common vulnerabilities Mookhey discusses:

Shoddy software: COTS and yours. In the Background section, Mookhey observes that web developers "not very well versed with secure programming techniques". It's not just web developers, of course, but nearly all developers. We haven't reached a point where secure coding is regarded as a worthwhile best practice. I preach this as well (Interop '03, February '03 BCR article). Want proof? Visit US-CERT and examine the Vulnerabilities Database. 11 of the top 20 are buffer, heap, and integer overflows. Five others are input validation. 80% of the problems relate to how we write software!

Haste-to-market technology. I explain how we too often put software, hardware, and a security policy implementation into production without sufficient testing. Mookhey states, "errors are exacerbated by the rush to meet deadlines in the fast-moving e-commerce world".

Shoddy operations. Misconfiguration of systems is the other leading cause of incidents. One of the most common offenses is failing to remove default configuration settings that leave systems exposed to attacks: Mookhey mentions how Microsoft SQL's default settings leave databases vulnerable to privilege escalation attacks.

Mookhey's full article can be found here. It's a good read.

When I rail against common practices, I worry that I'll come off as being *anti-technology*. Finding articles that corroborate my opinions brings that "safety in numbers" relief. Mookhey's is one of many columns I've read that conclude, "it's the software, stupid!"

If so many people believe we've identified the root causes of security problems, why do we still struggle to make systems and networks secure?

Archived at http://www.securityskeptic.com/arc20040401.htm#BlogID241 by Dave Piscitello  

Bruce Schneier has written a sobering look at the U.S. policy of fingerprinting foreigners in his January 15, 2004 issue of CRYTPO-GRAM. In his editorial, Bruce considers the expense of this undertaking, collateral costs such as retaliation, and the folly of presuming that fingerprinting is an effective way to combat terrorism.

I quote an outstanding remark amid many outstanding remarks in this column, which gives me hope that Americans will tire of this neo-McCarthyism and insist on changes in November:

America's security comes from our freedoms and our liberty. For over two centuries we have maintained a delicate balance between freedom and the opportunity for crime. We deliberately put laws in place that hamper police investigations, because we know we are a more secure because of them. We know that laws regulating wiretapping, search and seizure, and interrogation make us all safer, even if they make it harder to convict criminals."

Archived at http://www.securityskeptic.com/arc20040201.htm#BlogID202 by Dave Piscitello  

Dave Strom has been publishing the Web Informant for, well, forever. [Web-Informant] #350, 12 November 2003: Amazon opens up offers an insightful look into Amazon's foray into Web Services. This informant lives up to its name and reputation, visit strom.com and read it!

Archived at http://www.securityskeptic.com/arc20031101.htm#BlogID162 by Dave Piscitello  

Kevin Beaver's cynical column from August 2002 is in the spotlight again at SecurityFocus. I thought of some corollaries to his list:

To #3, don't patch your software, add, "but if you must, patch immediately on production systems, there's little point testing a patch - after all, how often do vendors botch the patch itself?".

To #10, rely solely on technology, add, "never read the manuals or help files, they can't possibly assist you in configuring your system correctly".

To #12, don't monitor your systems, add, "but if you must, don't bother reviewing log and event data, most of it's 'noise' anyway..."

To #13, don't back up your data add, "and while you're at it, don't back up your configuration data as well".

If you think of any to add, let me know...

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID149 by Dave Piscitello  

Matthew Tanase's article discusses the merits of transparent or bridging firewalls. When a device bridges rather than routes, it's not identifiable in the IP level packet stream (no TTL decrement, for example). Bridging is also helpful in topologies where addressing is a problem. A good read.

Matthew also hosts The Security Blog. I found some interesting reading there as well.

Archived at http://www.securityskeptic.com/arc20031001.htm#BlogID150 by Dave Piscitello  

I look forward to receiving Bruce Schneier's Crypto-Gram newsletter. I don't necessarily enjoy or agree with everything Bruce writes about but I almost always find something interesting, amusing, and educational (maybe that should be OR...)

In the August 15 2003 Issue, Bruce writes about the dangers inherent in using WYSIWYG word processors like Microsoft Word, which incorporate all sorts of information in the documents users generate, and the fact that most users are entirely unaware of this behavior.

What kind of information? In a paper entitled Scalable Exploitation of, and Responses to Information Leakage Through Hidden Data in Published Documents, Simon Byers explains that individual names, email, organizational affiliations, collaborators, information about the creator's file system and printers... open Word and view Tools | Options and see for yourself. Simon explains how this information can be misused (identity theft) and also points out that it might be used to combat plagiarism.

Bruce cites three interesting/embarrassing incidents involving recovery of hidden text in his August 15, 2003, all embarrassing circumstances. I won't share them here: read Bruce's newsletter!

Archived at http://www.securityskeptic.com/arc20030901.htm#BlogID114 by Dave Piscitello  

Operating System (OS) fingerprinting is a method whereby an attacker or pen-tester attempts to identify the operating system running on a host based on the responses that system returns. The comparison of this analysis technique to fingerprinting is based on the fact that Windows and *NIX Operating Systems, as well as router, switch and even security system software respond differently to received packets when unexpected and erroneous information is encoded in the packet (commonly though not exclusively TCP and IP) headers.

Fyodor's nmap is the most widely used and flexible tool for performing OS fingerprinting proactively. But fingerprinting by actively scanning, even if done as stealthily as imaginable, leaves evidence (hmmm... you might say it leaves fingerprints!). It also changes traffic patterns.

Techniques to fingerprint Operating Systems passively - based entirely on packets received rather than returned - are very interesting alternatives for security auditing purposes. Several projects demonstrate you can successfully identify OSs based on captured packets that give an accurate signature of popular operating systems.

Kevin Trimm provides a nice overview of passive OS fingerprinting in a column at SecurityFocus.com. He mentions two tools, Siphon and p0f. Give 'em a look.

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID101 by Dave Piscitello  

Hendrik Hertzberg offers the best characterization of Right Wing Radio I've read in a long long while in the August 11, 2003 issue of New Yorker Magazine. In his Radio Daze comment in the Talk of the Town section, he explains that

"...right-wing radio is niche entertainment for the spiritually unattractive. It succeeds because a substantial segment of the right-wing rank and file enjoys listening, hour after hour, as smug, angry, disdainful middle-aged men spew raw contempt at reified enemies, named and unnamed. The radiocons seldom offer analysis or argument. To the chronically resentful, they offer the sadistic consolation of an endless sneer..."

Let's see. The radio conservatives includes Bob "could my voice be any more irritating" Grant, Rush "to the refrigerator" Limbaugh, Mark "if I were any more right I couldn't be wrong" Levin, and Michael "how appropriately surnamed" Savage.

I'd say Hendrik's hit the mark, spot on...

Archived at http://www.securityskeptic.com/arc20030801.htm#BlogID98 by Dave Piscitello  

Evan Harris has published an interesting paper describing a method of thwarting SPAM at Message Transfer Agents rather than at the user level.

The article, The Next Step in the Spam Control War: Greylisting, explains how MTAs can exploit a characteristic of spamming applications that Evan calls "fire and forget": basically, spam engines blast through their lists of recipients once, and apparently ignore SMTP errors. Harris explains that by blocking initial mail delivery attempts (distinguishable by "triplets" the MTA maintains), and returning a temporary failure code, spamming applications are thwarted but legitimate mail is not permanently blocked.

This looks like an interesting but probably short-lived solution. Spammers will eventually break down and expand their grubby little applications to circumvent the block attempts.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID74 by Dave Piscitello  

Lance Spitzner, a pioneer in Honyepots and Honeynets, has published an interesting column at SecurityFocus.com entitled "Honeypots: Are they Illegal?" This is coincidental to a four-part series Network World has delivered through push email that describes Honeypots (I commented on the 1st of these in an earlier blog).

If you are unfamiliar with the subject, read my honeypots primer at Core Competence's web site.

Although he qualifies his commentary by disclaiming any authority on legal issues, Lance offers helpful opinions about the legality of honeypots in three areas: entrapment, liability and privacy.

I absolutely concur that honeypots are not a form of entrapment: attackers aren't coerced into breaking into computers, and entrapment is a moot issue if you are not a member or agent of law enforcement.

Privacy, Lance tells us, is a mirky water. I particularly like his recommendation regarding banners and the benefit they bring (read the column!).

Lastly, there's liability: if an attacker uses your honeypot to deface Microsoft's home page, are you liable? More importantly, are you any more liable than if they used any other computer under your administration?

Honest, read the column. Buy Lance's book. Visit the Honeynets project.

Archived at http://www.securityskeptic.com/arc20030601.htm#BlogID72 by Dave Piscitello  

My friend and colleague, Jim McCabe, has just published an updated version of his excellent book. The second edition is as excellent a resource as the first, with attention paid to technologies that have been developed since the first, and related, new design considerations.

I've written the Foreword to the 2nd Edition, as I had the 1st. The editor complimented me by excerpting from my Foreword on the back cover.

Archived at http://www.securityskeptic.com/arc20030501.htm#BlogID56 by Dave Piscitello