The Security Skeptic

Product life cycle management can be loosely defined as all the activities a vendor engages in to launch, develop, market, mature (or evolve) a product. Some products reach a point at which they can no longer adapt or evolve, and hence vendors end the life of a product. A noteworthy, recent EOL example in the security market is the Cisco PIX.

Users, especially enterprise administrators, contend with product life cycle management in a very meaningful way. They monitor a product's evolution and in many cases, they press vendors to add (or kill) features, improve performance and security, etc. They must stay informed so that they are not caught unprepared should a vendor choose to EOL a product; for example, if an admin ran a Cisco PIX only shop, he ought to have kept informed regarding the future of this firewall and ought to have considered what he would employ "post PIX".

Today, users have a longer life cycle to manage than vendors, one that includes hype cycle management. The hype cycle begins before a product announcement. Hype that sparks the cycle takes many forms: new standards and regulations, demonstrations of prototypes at trade shows, trade pub and street talk. Soon, *THIS NEW THING* is widely heralded as the most disruptive technology since, well, the last most disruptive technology.

Consider this tale of two C*Os and their experiences with the iPhone. The first C*O shows up at a senior management retreat with an iPhone, announcing that "this is so freaking cool". This begets a must-have attitude that trickles down from management, which begets an organization-wide buying frenzy, which begets a business imperative directed at IT to "integrate iPhones with our enterprise mail system and corporate web apps". To accommodate iPhone adoption, a planned 802.1x/network access controls project is dropped from the budget. There's always next year.

This C*O failed to manage the hype cycle and allowed enthusiasm for a consumer grade product to snowball into a mobility issue that resulted in an unplanned network deployment, funded at the expense of an important security initiative.

I know a second COO whose response to exactly this situation serves as a five-star example of hype cycle management. When iPhone was announced, this COO sent an "all hands" email with the subject line "iPhone". He acknowledged the awesome coolness of iPhone and that he desperately wanted one. However, he tempered his enthusiasm when he realized that interoperability issues would prevent him from accessing intranet services that were essential and that an important network and security upgrade would have to be sacrificed to accommodate iPhone adoption. He asked all hands to temper their enthusiasm, be patient while IT investigated iPhone integration, and promised that the organization would do its best to accommodate new mobile technologies. This COO jumped in front of the bus as it was departing and yelled "stop!" but in doing so, he acknowledged the desirability of the new technology rather than dismissing it. He explained why iPhone adoption was problematic, reminding rather than rebuffing staff that the mission and business of the organization takes priority over having a cool handheld. Lastly, he empowered IT by announcing that iPhone adoption would be studied.

If you study these scenarios carefully, I'm pretty certain you can tease out a set of "best practices" for hype cycle management.

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

Who is Cary Duffy Marsan and why is she so interested in IPv6 when (apparently) few others are?

Cary Duffy Marsan is Senior Editor, Enterprise Applications for Network World magazine. Why she is interested in IPv6 is a mystery, but she has done some "responsible journalism" by publishing a series of articles on IPv4 address exhaustion (February 2008) and transition (switching) to IPv6 (December 2007). The February 2008 article, "Who's afraid of IPv4 address depletion? Apparently no one." has particularly dismal statistics from BT INS, who claim that only 1 in 3 service providers support IPv6 and 2 per cent of IT professionals have migrated their organizations to IPv6. Yes, two (2), and if that's a misprint, it's not mine.

Comments posted to both articles are predictable: NAT will save us. No, it will not. China will have IPv6, so it's well past time for the US to enter the addressing arms race. Sigh...

The December 2007 interview with Jim Bound, IPv6 guru, is not much help. Bound is quoted as saying, "There’s no one-size-fits-all transition plan. The first thing is to upgrade the infrastructure. You need to get your network plumbing in order so that IPv6 can co-exist and be interoperable with IPv4."

No "one-size-fits-all" transition plan? There's no plan, period, Jim. If "NAT will save us" is the war cry of the IPv6 averse part of the community, then "dual stack will save us" is the counter-cry of the IPv6 advocates who've left the hard nuts in deployment for someone else to crack. Dual stack frustrates me to no end. It's engineering hand-waving, blue-smoke and mirrors. It's interesting in the context of a core switching infrastructure but offers relatively little insight at the network edge, where many of us operate, and on endpoints, where nearly all of us live. Here's a tough nut to crack, folks: endpoints that have only IPv4 addressed interfaces will hang around for decades, and before they disappear entirely from the face of the addressable universe, the number of addressable *public* interfaces will exceed 2**32; in fact, you'll have endpoints with IPv6 only addressable interfaces long before then.

Everyone is worrying about address exhaustion, and this thinking is too narrow. Whether you think IPv4 address exhaustion is imminent or not, you better be thinking about ways you will accommodate *application* communications between IPv4 and IPv6 only hosts, not only for client-server applications but peer to peer as well, because apparently, few others are.

And while you're expanding your thinking regarding IPv4 and IPv6, think a bit more carefully about security. As my study of IPv6 firewall support among commercial firewalls suggests, few others are thinking about this issue as well.

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

Voting is a privilege in the United States (our Constitution does not guarantee a "right to vote", only that our Congress is elected by "The People"). Voting is conducted as a secret ballot to assure integrity of the process, i.e., to ensure that a citizen is not coerced into voting for a particular candidate.

We hold primary elections to choose candidates for presidential elections As we approach the dates for South Carolina primary elections, campaigners and pollsters are as numerous, annoying, and *destructive* as locusts.

Destructive? Absolutely.

IMO, asking a citizen to disclose who he (or she) intends to vote for compromises the intended private act of casting a ballot. It's no different from asking an individual to share what he'll use as a password or PIN. Aggregating responses by citizens who treat the privilege of voting so lightly that they willingly disclose their vote undermines the integrity of the vote in several, destructive ways.

• No pollster or campaigner has asked me if I am citizen and entitled to vote, nor can they repudiate any claim that I make in this regard. This taints the sampling.
• Pollsters and campaigners have no way to determine if I lie or if I will change my vote; this, too, taints the sampling.
• Pollsters and campaigners can demonstrate statistically that the stated margin of error used to compensate for invalid responses is accurate. The skeptic in me concludes that the published margin of error is one that seems plausible to people who put faith in polls.
• People who put faith in polls may change their vote or decide not to vote if their candidate is too far behind (or ahead). This is a negative influence that elections can do without.

Primaries will continue for months, candidates will be nominated, and the polling process will persist until and beyond Election Day, November 2008. Don't answer pollsters and campaigners except with the following, "Are you aware that we use a secret ballot in US elections assure that my and every voter's choice is *confidential*? How are my interests served by disclosing my vote to you?"

Archived at http://www.securityskeptic.com/arc20080101.htm#BlogID667 by Dave Piscitello  

My initial thought was to wrap up 2007 with a list of successes and failures in the areas of Internet security and stability. Too much has already been written on this topic, both fact and FUD. Perhaps this is out of character for a skeptic, but I'll close the year by asking Santa for changes I'd like to see in 2008.

A pragmatic approach to user self-administration. Many organizations lock down every client endpoint. This proves frustrating for three classes of users: those who know little but hate conceding control, those who incorrectly perceive themselves to be power users, and truly knowledgeable users who may know as much as many staff in IT departments. One policy won't fit all here, so let employees choose. Those who choose to have client endpoints locked down get priority support over those who do not. The truly knowledgeable users will solve the majority of problems themselves, from hardware diagnostics to data and OS recovery. The wannabe power users will either learn quickly that they know less than they imagine, or their productivity will plummet.

Take DNS out of the fast flux equation.. The efficacy of fast flux hosting is greatly improved when the attack can flux both web proxies and DNS name servers. Some registrars and registries have aggressive anti-abuse policies that prohibit short times to live on A resource records for name servers of domains they manage. Make this an industry wide practice, either through policy or best practices.

More fact, less FUD. Too many anti-virus products are marketed as providing effective relief from viruses and malware. The sharp folks at CERT Brasil have some sobering statistics on the performance of these products in the field. During a November 2007 APWG Summit, Cristine Hoepers of CERT BR presented a summary of antivirus detection rates for trojans, keyloggers and downloaders affecting the Brazilian financial system: only 5 vendors had detection rates above 70% while ~70% of vendors had detection rates of less than 40%. Assuming that endpoints in the Brazilian financial system are better managed than your average broadband user, how much worse can detection rates get? We need to invest in more and broader-based statistical analyses like this, obtain a clearer picture of client endpoints, and if the statistics prove what I suspect, focus research on complementary and alternative solutions to signature-based malware detection.

Take steps to reduce IP spoofing. I've written about this many times. So have SSAC, the IAB (BCP38), and other respected security authorities. Lots of folks in a position to reduce IP spoofing claim this is hard to do and there's no obvious and justifiable return on the investment in time, talent and technology. If you're waiting for an easy way to solve IP spoofing that will cost nothing and improve your revenue, don't hold your breath. If reducing the percentage of malicious traffic on the 'net, making DDoS attacks a tad harder to execute, and making it easier for white hats to identify bot-infected hosts aren't enough of a justification, then maybe your organization is just too content to remain part of the problem. Step up or step aside.

Police port 80 or shut it down. That's right... or shut it down. 80/http is overloaded to the point where we either need a standard discriminator for each of the random acts of application convenience that pass through 80 or a Draconian policy enforcement that dumps everything that's evading firewall egress policy (skype, et. al.) or really merits its own port and policy.

There are many more. I'll happily publish anyone's (serious) suggestion to complement my list.

Archived at http://www.securityskeptic.com/arc20071201.htm#BlogID663 by Dave Piscitello  

Dan Briody wrote an article in InfoWorld in May 2000 called The Ten Commandments of cell phone etiquette. It's an interesting list to re-visit for several reasons.

Etiquette hasn't improved. Dan's first commandment is "Thou shalt not subject defenseless others to cell phone conversations".This one's a lost cause, Dan. It's nearly impossible to *not* overhear cell phone conversations if you are within earshot of another individual. Corollaries to this commandment from Dan included "Thou shalt turn thy cell phone off during public performances" and "Thou shalt not speak louder on thy cell phone than thou would on any other phone" Both are lost causes as well. There is, however, a silver lining for Americans regarding "loud". For ages, Americans have been easily distinguished from other tourists by their propensity to yell English at a non-English speaking individual, as if volume would improve comprehension. Not any more, laddie. The Ugly American is dead, long live (unfortunately) the Ugly Cell phoner. Lastly in this category, Dan offers, "Thou shalt not attempt to impress with thy cell phone." One word, Dan: iPhone.

Safety is marginally improved. Commandment 5 was "Thou shalt not dial while driving." Despite laws in various jurisdictions and technology assists from speed-dial, hands-free, and voice-dialing features on nearly any phone, including most "free when you sign up" models, it's again nearly impossible to drive without observing fools aplenty swerving as they dial. Automobile manufacturers are saying "BlueTooth is the answer". The BlueTooth chip manufacturers are saying, "Hallelulia, brother, BlueTooth is finally the answer to a question!" Whatever gains we make in driver attentiveness will be overtaken by GPS gawking and idiots who will arrange mirrors in vehicles so they can watch the rear-seat DVD while they drive.

Technology has rendered some commandments obsolete or irrelevant. "Thou shalt not grow too attached to thy cell phone"? Nearly impossible these days. Carriers use different bands and protocols, phones are locked, and phone technology evolves at a fraction of Moore's law. Commandment 4, "Thou shalt not wear more than two wireless devices on thy belt" is mostly obsolete. I can't remember the last time I saw someone with a pager or PDA *and* a cell phone. I do see folks with two cell phones but such folks are power users yet unaware of dual SIM card adapters.

I'd like to replace at least one of Dan's commandments with "Thou shall not use thy cell phone in a public restroom". Seriously, what do you have to say on a phone that can't wait until you've finished your business and washed your hands?"

Maybe I'll start a new list: 10 reasons to *not* borrow someone else's cell phone.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID662 by Dave Piscitello  

Live Chat is all the rage. "Speak" with a customer care representative directly from your PC via a Web application. How cool is that?

Those who know me know I am an infrequent and mostly reluctant phone user, so the notion that I can instant message rather than speak with call center personnel is enormously appealing. Unfortunately, I'm encountering more and more situations where Live Chat is really "live hold". The chat threads proceed as follows:

Hello this is Dorkas. I'm your customer care representative, how can I help you today?

I'd like to add a service to my cellular telephone, please."

...

??????????

...

Are you still there?

(At this point I check to see if I still have network connectivity, if I am still connected to the web site, and if my Java console is complaining... )

H E L L O ?

...

TYVMFWMT

(Thank you very much for wasting my time)

I take comfort that I get to choose the "on hold" music from iTunes. After 20 minutes, I close the popup window and call customer care.

sigh...

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID654 by Dave Piscitello  

An editor of an online publication contacted me by email today, asking if I would talk about network usage policies. The editor asked, "How can companies handle employee's usage of IM, email, social networking sites, YouTube etc. Should the company block access to certain sites? How does the company deal with network overload? Should the company prohibit personal email and IM use? How should these rules be enforced?" My response, amplified a bit, follows...

You are covering a huge swath of territory by including applications like email that are 20 years mature and IM that is less mature than email but becoming essential in mobile technology alongside social networking and entertainment sites that have unclear, even questionable business value and possibly add risk as well as impact productivity.

The hard question for organizations to answer isn't how to control traffic but rather, what applications fall within the realm of appropriate use? What applications enhance productivity? What apps are justified because they are good for morale? What applications expose the organization to unnecessary risk? Should all apps have unlimited bandwidth? Can compromises be made so that critical applications receive preferential and ample bandwidth and less critical applications receive a sufficient "trickle" to accommodate those who benefit from them?

How a company defines an AUP is very dependent on the type of business it operates. A company with hourly employees who must meet production benchmarks might require a very restrictive policy whereas an advertising company might want a very liberal policy. All the applications you mention may not be very useful to employees who use networked computers to perform work in a manufacturing company. An ad company may find YouTube invaluable because it wants to keep pace with youthful expression, teen obsessions, etc. OTOH, YouTube could pose a risk to a company that projects a traditional "corporate white collar" image but runs afoul of an employee who records and posts "insider activities" from his office PC that reveal the Emperor's true clothing.

Finally, there's a tendency to view AUPs as monolithic. With today's firewalls, application proxies and UTM appliances, even a small business can create group based AUPs in a company, so that the "creative" people in the company have access to what they need, the "mobile" people are hyper-connected, and the "production" people have a distraction-free computing environment.

Network usage and acceptable use policies are not one size fits all. This is one of many areas of network and security design where each company has to invest time and be thoughtful before it invests in technology.

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID649 by Dave Piscitello  

An InfoWorld security columnist posted the following to the BugTraq list at securityfocus.com:

I'm tired of the 0-day argument. I say forget the confusing acronym and use something else, like: unpatched exploit or previously undisclosed vulnerability or something like that.

It's unusual and somewhat gratifying to find a member of the 4^th Estate who takes issue with creating clever labels to distinguish among the indistinguishable, with the net result adding to the F.U.D.

When 0-day first appeared in print, I struggled to understand exactly how the term helped to characterize the type of attacks so labeled. Specifically, exactly what aspect(s) of an attack did 0-day describe?

Did it take an attacker zero days to write the exploit?
Did the exploit take zero days to propagate?
Did the exploit take zero days to infect, infest, or compromise a target?
Did it take zero days for countermeasures to be identified?
Did it take zero days for the countermeasure to be made available to the community?
Did it take the community zero days to implement the countermeasure and mitigate the exploit?

Depending on the amount of time represented by zero days, I can answer YES or NO to some or all these questions save the last. Why not the last? I doubt very many attacks, 0-day or otherwise labeled, are entirely mitigated in zero years much less days.

The InfoWorld columnist is absolutely right. Terms like 0-day have place in the vernacular of Internet security. They belong in marketing collateral. Yes, let's exile 0-day to marketing collateral and read it there.

On second thought, let's not read the marketing collateral. It is a silly place.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID634 by Dave Piscitello  

A woman interviewed following a debate among 2008 Republican Party candidates expressed her unhappiness with the way many of the Presidential hopefuls lashed out at President Bush, saying, "He's the sitting President and as long as he is in office he deserves our respect".

I take exception to this statement in so many ways I couldn't avoid posting a political rant.

• My high school wrestling coach taught me that no one deserves respect, but everyone must earn it. My son's coach told him the same thing. I'm glad to see this belief has endured and hope it's not only wrestlers who are taught this creed.

• An individual who occupies an elected seat in a democracy serves the people. The current sitting US President was elected, and it is clear that he earned the respect of a good percentage of the populace on several occasions during the course of his political career.

• Earning respect is not a "once and done" task. As a wrestler, you had to earn it every time you stepped on a mat. Americans expect no less than from their President; in fact, they are more demanding.

• While he may not have Presidential moments as frequently as many of his predecessors, many Americans believe he acted in a Presidential manner following September 11^th. So at one time, the sitting President earned respect.

• Public approval ratings in May 2007 indicate that fewer than one in three Americans approve of how the Bush administration is governing the country and that number could easily plummet to one in four by July. Whether you believe polls are fact or whimsy, you have to consider the possibility that the sitting US President is not earning respect at home and abroad.

Most Americans and more broadly, citizens in most countries, respect the office of the US President immensely. My experience (and embarrassment) when traveling internationally is that I find citizens of other countries fret more over what the sitting US President does and how he has acted during his term-and-a-half than a good many Americans.

People who have the privilege of living in a democracy should respect the office of the President. We should also be demanding and critical of any President who does not try to exceed our expectations every day, who acts with less than Presidential demeanor even (especially!) when dealing with members of the press who are intent on pushing his buttons; in short, a President who does not earn our respect.

One last point. We continue to call former US Presidents "Mr. President" long after they hold office. This means that US Presidents have a daunting task.

They must continue to earn our respect for as long as they live.

Archived at http://www.securityskeptic.com/arc20070601.htm#BlogID622 by Dave Piscitello  

What for, beyond accepting LinkedIn invitations?

Someone please tell me if LinkedIn is anything other than a MySpace for professionals. Or do C*Os get the same adolescent rush that teens do when they have the largest number of friends? Tell me, please!

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID615 by Dave Piscitello  

Colleague David Strom discusses waning attention spans in his 4 May 2007 Web Informant. In the article, David explains how his attention span is getting shorter and shorter, and how he and other noteworthies including Rupert Murdock, rarely finish the long (WSJ) stories, web pages, long emails, and online articles. It's an interesting admission for an author and e-publisher, and you ought to take a look.

The subject of David's column - and in particular how online publications are responding to what they perceive as visitor/subscriber needs - is consistent with what I see and hear from tech media people all the time. Where I was once asked for articles ranging from 1200-1500 words, I'm now asked to keep an article under 800 words: 600 would be better, and 400 is ideal.

This trend is very disturbing. We appear to be devolving into a "just tell me what I need to know RIGHT NOW, how to do this RIGHT NOW, keep it brief I'm too busy to care WHY" society. Fewer and fewer IT professionals are learning architectural and other *big picture* networking and security principles, and rely instead on technology to solve the problem.

This attitude is not isolated to Internet technology; in fact it's a pandemic. Consider your automobile. Fewer of us know the basic principles of combustion engines, brake and electrical systems in our vehicles. We are increasingly dependent on technology to troubleshoot and to identify the parts list and labor when we need a repair or routine maintenance performed. We don't know more than the basics of driving and many drivers only learn the absolute basics needed to obtain a license. Think of the number of drivers who can't parallel park, or who don't know the correct way to orient the wheels of a vehicle when parked on a hill. I won't even speculate how many (US) drivers can parallel park on the left-hand (driver's) side of a one-way street. Too many licensed drivers invest time and brain cycles to become safer drivers, and it's painfully evident that PC and Internet users invest even less time learning how to be productive and safe while computing and networking.

If we only have patience and the willingness to deal with a symptomatic problem in the most mechanical, boilerplate and simplest manner, what differentiates us from robots? Asking why and taking the time to study an issue is not only becoming an endangered attitude, but it seems to be falling out of favor as well. When attendees approach me with questions after I've given a seminar, I get the distinct impression that taking the time to understand why X is a best security practices is unimportant - management barely acknowledges the need for the best practice and doesn't appear to encourage education and awareness as business productive activities.

I'm not entirely sure this is an accurate picture, but it is a really worrisome condition if it is.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID611 by Dave Piscitello  

Georgia Public Broadcasting reports that a bill has been passed by the Georgia House which allows gun owners to keep *loaded guns* anywhere in vehicles without concealed weapons permits; specifically, the bill allows the guns to be kept in plain view and in the glove compartment. One of the State House representatives of a rural county in Georgia claims that this bill "gives back a piece - a small piece - of the Second Amendment that has been deprived of so many law-abiding citizens over the past few years".

Reading further down the day's news, three Dawson County students have been charged with multiple counts of aggravated assault in more than 30 sniper-type shootings that targeted businesses, cars, houses and a school. The students are suspected of using a 22-caliber rifle, firing at targets across 6 counties last month. Call me crazy, but isn't is possible that an "in plain view" legislation will encourage more such sprees?

I shouldn't be such a skeptic. If the law passes the Senate, it will undoubtedly stimulate a new "conversion" industry in the Peach State. Instead of simply pimping one's ride, Georgians could legally add a turret mount on their F150s, doolies, and HumVs.

Is it any surprise that Georgia ranked 41^st in the Smartest State 2006-2007 poll?

Archived at http://www.securityskeptic.com/arc20070201.htm#BlogID591 by Dave Piscitello  

My wife and I receive on the order of 5-7 offers for credit cards per day. I've been told this is a positive indicator - we pay back what we borrow with interest blah blah blah so everyone wants to be our lender blah blah blah.

I don't feel special. I feel besieged. I have an oversized mailbox that practically explodes when I open it.

My 2007 New Year's resolution is, "Pay back time!" And I'm borrowing a page from Blue Security's antispam campaign to do so.

Today, I took the pre-paid return envelopes from seven credit card offers, filled them with shredded offer letters and applications, and returned them from whence they came. Yes, mine is a small gesture, but if you all join me, we can test the Blue Security model in the real rather than virtual world. I'd love to have life imitate art here. There's a scene in the 1947 movie classic Miracle on 34th Street where New York City postal workers fill a court room with letters addressed to Santa Claus. I'd be delighted to see the same scene repeated in mail rooms at "New Cardmember Services" processing centers.

Perhaps a small effort on all our parts can make a difference. If not, at least you've tried.

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

Imagine that several centuries hence, anthropologists uncover a hoard of archived tapes containing terabytes of firewall log files recording events from the last decade of the 20^th century and into our present day (2006). Now imagine that they discover how to read the media and open the log files.

Initially, excited anthropologists will might rush to conclude that "gee, these early Internet folks were really committed to understanding how the primitive networks they used worked. Look at all the copiously maintained information!"

Much later, after considerable analysis and perhaps after correlating logged events with unearthed copies of newspapers containing articles about DOS attacks, Internet worms, spam and more, a young turk of an anthropologist will refute earlier conclusions in his Masters' thesis by suggesting an alternate theory.

"It really doesn't appear that early Internet people were able to derive much of value from all this 'log' information. At the very least, if they derived anything, they did not appear to apply it."

Archived at http://www.securityskeptic.com/arc20061101.htm#BlogID569 by Dave Piscitello  

Anyone who's gone through TSA security at an airport recently knows that you are required to remove your footwear for X-Ray screening. We owe this inconvenience to a man who attempted to conceal two functional improvised explosive devices in his sneakers (why can't these folks just say "bomb"?)

While waiting on line to pass through security at San Diego airport, I began wondering, "At what point does searching for IEDs cross the lines of reason and propriety?" So I began considering what other apparel might be used to conceal IEDs of approximately the size one could conceal in the heel of a sneaker.

A padded bra! Apparently, certain bra manufacturers conveniently provide pockets so that women can add padding according to need. I'm not an IED expert, but it seems that it would be far simpler to pad a bra with explosives than a sneaker heel.

So the question that begs an answer is, "If Richard C. Reid had been Roberta C. Reid, and Roberta had concealed an IED in her bra, would TSA insist that all bras pass through X-Ray?" [For the record: I would not be comforted by a response claiming that the X-Ray machine I walk through is sensitive enough to detect an IED in a bra but not in a sneaker heel.]

Thanks to spam, I am now painfully aware that certain undergarments accommodate tush pads as well. Um... let's not go there.

Archived at http://www.securityskeptic.com/arc20061101.htm#BlogID567 by Dave Piscitello  

A colleague forwarded me an article entitled Laptops Content may be Subject to Inspection upon Entering the United States today. The 9^th Circuit Court of Appeals in California thinks it's OK for Customs Officials to seize and search travelers' laptops upon entering the U.S. without a search warrant or probable cause. The case on which the court based this decision - one involving the seizure of a laptop containing child pornography - could not have been more convenient. The defendant is engaged in activities the public considers repugnant. The recovery of the images reads like the script of the hugely popular TV series, CSI. Customs agents and the TSA already examine laptops as a one of many homeland security measures.

So, really, how much of a stretch is it to allow agents to boot and surf your laptop?

IMO, a huge one. There is little difference between the information you store on your laptop hard drive and that ugly metal file cabinet that occupies the corner of your home office. Our courts have a responsibility to understand rather than fear technology. Before a court concedes what has been recognized and defended as an inalienable right since the 18^th century, it ought to consider how decisions it applies to the virtual world will affect the physical world.

This and related articles (e.g., Border Insecurity) discuss the impact on corporate privacy, i.e., examination of sensitive documents and the forced disclosure of passwords. The impact is far more fundamental. Why are courts and the federal government so eager to abandon warrants and due process? Is a world free of terrorism better than a world where you and your property can be seized and searched without probable cause?

I'm skeptical we can ever achieve the former, and I'm very reluctant to concede the latter.

Archived at http://www.securityskeptic.com/arc20060901.htm#BlogID557 by Dave Piscitello  

During an email exchange, a colleague reminded me that "anything can be done in software".

Since the topic we were discussing involved abuse and possible misuse of protocol responses, and since I am tired to tears of this nonsense, I grumpily replied, "If we could just fix that *anything can be done in software* issue all our problems would be solved."

The good news is that education is deteriorating globally and soon only a handful of people will be creative enough to write anything novel. :-O

Archived at http://www.securityskeptic.com/arc20060901.htm#BlogID556 by Dave Piscitello  

My wife is a licensed nurse practitioner. She has an RN, a masters degree from University of Pennsylvania, and extensive experience in critical care and private practice. Despite her accomplishments, degrees, and multiple certifications, many patients are confused when she is introduced. As an APRN (Advanced Practice Registered Nurse) in South Carolina and previously a CRNP (Certified Registered Nurse Practitioner) in Pennsylvania, she is routinely asked, "Are you a physician's assistant?", "Are you practicing for your nursing degree?", and "I just saw the nurse, I want to see the doctor!"

I began thinking about my wife's experience with degrees and appellations in the context of my own career. There's no concrete taxonomy for labeling and distinguishing security folks; in fact, degrees, certifications and titles are far more ambiguous in Internet Security than medicine. Satisfy the sometimes questionable criteria, and you can be a certified security professional or practitioner. Learn Linux, download bootable security images, and claim you're a security consultant. Here are my recent musings and ramblings on the topic.

Only a handful of people in the world are qualified and have accomplished enough in the short span where Internet Security has proved meaningful to be labeled experts. Dan Brown mentions Phil Zimmerman and Bruce Schneier in the Da Vinci Code. Give Dan credit for choosing two of an elite group of folks I consider experts (Bellovin, Cheswick, Diffie, Ranum, et. al.). The community at large diminishes "expert" status when it dilutes the talent pool by including anyone who can blurt out a credible quote for a reporter. Please be more disciplined...

I'm uncomfortable when people call me a security expert. I prefer to have folks describe me as a security practitioner. I study Internet Security and try to practice at it daily to increase my experience and expertise. Many of my colleagues do the same. Many are more expert than I in many areas. Some practice in research areas, others in deployment and operations. Over time, the best earn a positive reputation among the security community. These are the folks you want to meet. You look forward to reading and presenting their works.

Some of my colleagues have worked hard to earn certifications. IMO, certifications should reflect understanding of theory and accomplishments in practice. I believe that any certification that doesn't set minimum requirements for "time in the field" and only requires that you pass a test is suspect. I don't hold any certifications. I haven't identified one that would put me in a select group that would justify me exerting the effort to pursue at this point in my career. Even if I identified a certification I'd invest time to earn, I still believe that certifications cannot ever substitute for reputation.

I struggle with the label "security professional". The word "professional" is popularly associated with competition. Security practitioners aren't marksman, bowlers, golfers, or race car drivers. We may compete for income, but hopefully not for a ranking. IMO, the term "professional" should be reserved to reflect the behavior and integrity of of a security expert or practitioner.

I've mused and rambled long enough on this topic. Comments welcomed!

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID543 by Dave Piscitello  

In a thread discussing Integrated IDS/IPS/Firewalls, Chris Blask made the following claim that I can't help but believe is more accurate than any made by security vendors today:

Good firewalls managed badly suck, "weak" firewalls managed diligently and used with the right collateral don't."

What more can one say about the impact "clue" has on implementing effective security?

For similar insights, visit Blask Works.

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID535 by Dave Piscitello  

In previous blogs, I've described numerous painful experiences with versions 4 through 6 of Acrobat. I've been using Acrobat 7.0 for only a short while, but so far, the application and browser plug-ins load faster and most importantly, I haven't had a frozen browser or hung machine incident. Your mileage may vary, but Acrobat 7.0 seems to be a worthwhile upgrade. For the record, my upgrade process for Adobe products involves completely uninstalling the currently installed version, rebooting my machine, installing the new version, and rebooting again.

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID531 by Dave Piscitello  

If you've ever wondered how independent top tech research firms are in their analysis of technology and trends, you'll find a February 6^th article by Information Week's Larry Greenemeier and Paul McDougall interesting and troubling. Larry and Paul get right to the heart of the issue and begin with this challenge:

"Forrester, Gartner, IDC, and others insist their output is squeaky clean, yet they also rake in millions providing services to the very same companies they monitor, heavyweights like Cisco, IBM, Microsoft, and Oracle. Which leads to a question that continues to dog the research firms: How much influence do technology vendors have over their work?"

Larry and Paul ask the major players tough questions including, " Are analyst reports expert advice based on scientific, independent research, or does money talk?" (One question I've secretly wanted to ask for years is, "If you really believe you can accurately predict markets, why are you unwilling to disclose your predictions five years later and let the industry judge your track record?")

Larry and Paul also investigated funding and ownership of the top firms and claim some top analyst firms are partly owned by investors that hold "significant stakes" in the companies they cover. As an example, they describe Gartner's relationship with SI Ventures. Gartner invests in hedge funds, including SI Venture Fund II. SI funded Authentor Systems. Gartner analysts provided supportive quotes on Authentor Systems in the company's press releases. "I buy your fund. You invest in a company. I say nice things about the companies you invest in." Did I get that right?

I've always found it disturbing that companies with products in hot sectors say they have no choice but to pay to be placed into mystical quadrilaterals. When I've asked why, they respond as ProofPoint's Sandra Vaughan did in the IW article: "This [magic quadrant] matters more than you want it to matter..." Is Sandra saying "To do otherwise is economic suicide"?

I always thought the whole practice sound vaguely similar to the insurance street gangs offer corner grocery store owners in NYC and LA. Larry and Paul lead me to conclude it's much more ORGANIZED than this.

Archived at http://www.securityskeptic.com/arc20060201.htm#BlogID506 by Dave Piscitello  

My daughter attends a private school about 18 miles "off island" in the neighboring town of Bluffton. Traffic returning to Hilton Head Island all funnels onto a single multi-lane highway which is riddled with intersections and traffic lights and constantly congested. Volume alone is only one of the factors causing this congestion.

Driving or idling in traffic can be frustrating. The driver of cars adjacent to mine look catatonic, panicked, or ready to shoot someone (given the ratio of gun racks to vehicles here, this is seriously disconcerting). I deal with the frustration and boredom by petting my dog, who accompanies me on my round trip, by observing people, and thinking about writing topics for my blog.

I spent many years involved in the development of routing protocols. Routing and traffic management are close relatives, so trying to isolate the causes of congestion when I'm stuck in traffic is almost second nature. Each morning, I watch the random acts of braking, noted the weather, observed merging from intersections which are often manually controlled from Beaufort County Sheriff Department cruisers (with little observable improvement). Observing the braking patterns this morning, I confirmed a growing suspicion that they were not random but fairly predictable. I'll give you some hints.

• It's a bright sunny morning.

• Eastbound traffic on the highway runs predominantly East.

• It's winter, and the sun is low on the horizon in the morning.

• The giveaway: when traffic turns directly into the sun, the majority of drivers touch their brakes. The back pressure effect persists for more than a mile. .

Yes, the majority of braking occurs when drivers are temporarily blinded when they face the sun. A casual sampling of the drivers I pass reveals that only one in four are wearing protective sun glasses. I'm wearing sun glasses. I'm not tapping brakes when I turn into the sun, and neither are the handful of drivers I spotted wearing sun glasses. Could we actually abate congestion on Highway 278 through Bluffton by requiring drivers to wear sun glasses? Perhaps an experiment is in order. Law enforcement agents could buy several gross of sun glasses and hand them out to drivers.

There's a hidden PR benefit for the local law enforcement as well: deputies handing something other than traffic violations to drivers on Highway 278 unquestionably breaks the stereotype:-)

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID491 by Dave Piscitello  

Evidence that targeted advertisers like DoubleClick are frustrated by my content filtering efforts is always heartwarming. This image from a Network World web page I recently visited made me smile:

The site *isn't* temporarily unavailable, dudes, it's permanently blocked, as in "you will never EVER connect to it from any host behind my firewall while I remain mentally able to configure an egress filtering policy".

Too busy? An interesting interpretation, and a equally telling measure of the conceit of Internet marketeers. Try again in a few moments? Can they seriously imagine that someone will actually refresh a web page for an advertisement?

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID487 by Dave Piscitello  

I ranted about my issues with Adobe Acrobat Standard in blog #453. Creating pdf isn't very satisfying, either. I coerced into creating pdf files by my Office-hating colleagues, many of whom are entirely naive to the poor social skills Acrobat Standard and Windows XP exhibit when they occupy the same sandbox I call my PC.

Today's chronology of events is typical of most of my Adobe punishment, I mean, publishing experience. I launch Acrobat Standard, select "Create PDF" and open a powerpoint file. I'm immediately greeted with

Unable to find Adobe PDF resource files. Do you want to run the installer in repair mode?

I'm not really interested in this, do I have a choice? Adobe Acrobat 6.0 installer begins, and of course, stops because (you bet),

Adobe Acrobat 6.0 must be closed before continuing the installation.

I close the application. Installer begins, but I immediately am confronted with a dialog box explaining that

The feature you are trying to use is on a CD-ROM or other removable disk that is not available.

This is undoubtedly true, since I've *downloaded* this software. Clinging onto a faint glimmer of hope offered from the dialog box, I browse and search for ACROSTAN.MSI. Sorry, XP informs me,

Search is complete. There are no results to display.

I cancel the operation. Not content to set me free, Acrobat 6.0 tosses one last grenade into my lap, the nefarious

Error 1706. No valid source could be found for product Adobe Acrobat 6.0 Standard.

I study this sentence for a while. I can't argue the logic. There certainly seems to be no valid source for Adobe Acrobat 6.0 Standard that consistently works on *my* Windows PCs.

I'll convert the presentation into html. Let them eat gifs.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID462 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  

"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  

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  

Finance Tech offers an interesting article that suggests that the concern and worry over Internet fraud is (can you imagine) overblown. In The Internet Is the Safest Channel, Ivan Schneider quotes Richard Parry, a Senior Vice President of Consumer Risk Management at JP Morgan as saying that fraud is more commonly perpetrated over the phone and even face-to-face than through Internet-based services. Parry also claims the financial impact from Internet fraud is "limited".

So why is all the negative press aimed at the Internet?

This is one more example of the roller-coaster relationships the tech and popular press have with *any* technology. Over the years, I've observed that pop press reporters fall in love with and "marry" new technologies at rates that eclipse (ahem) chapel weddings in Las Vegas. A honeymoon period follows, during which reporters lavish their spouses with compliments - "innovative", "disruptive", "lifestyle-altering". When reporters run out of compliments, they become disenchanted and fickle. Most such marriages end in divorce, preceded by lengthy proceedings so reporters can milk negative copy from the relationship. Some reporters stay unhappily married simply because there's endless copy in beating down a technology or company (think "Microsoft").

It's simply the Internet's turn to take the abuse. But expect the Internet to remain a target for a while; like Microsoft, it's a big target.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID438 by Dave Piscitello  

In a WatchGuard Wire post, Scott Pinzon labels my colleague and friend Marcus Ranum "a devoted disciple of incorruptible practicality" - damn! I wish I could have come up with as Jeffersonian a phrase as that one to describe MJR.

The label is spot on. Marcus views security issues through black-and-white lenses: you do what you know is the right thing to do, or you are wasting everyone's time and money, and putting your organization at risk. What distinguishes Marcus from so many other preachers is that his advice and insights are correct way more often than not.

Why? Well, he's pretty damned smart. But lots of folks involved directly or tangentially in security are smart. He's also intensely skeptical. Again, lots of other folks are intensely skeptical. He's principled. Lots of folks are principled - until someone higher in the organization points at the door and says, "my way or the highway..."

Marcus chooses the highway, or high way, if you prefer.

Too many practitioners in the security field concede to administrative bullyism. (This is less an indictment of security practitioners than it is of society at large.) The reason many of us admire Marcus is exactly because he chooses the lesser road traveled when issued an ultimatum. Most others will acquiesce and whine later on mailing lists or among colleagues over a beer. I've taken both paths in my career, and regret that I didn't always choose wisely.

I'm not advocating blind disciplism. The world according to Marcus is quite possibly too constricting. I'm suggesting that security would improve measurably if all who practiced it were more curmudgeonly. It's quite possible that we have a critical mass of security practitioners to say "ENOUGH" and pull us out of the security tailspin. The trick is getting those who form the critical mass to say it with Jeffersonian conviction and style.

"When in the Course of human events it becomes necessary for one people to dissolve the political band...more"

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

The IM world learned *nothing* from the multi-protocol networking wars of the 1980s. Every provider has to run its own messaging protocol. Everyone provides a distinctly clever client. Everyone is protectionist to keep multi-lingual IMs in constant state of flux.

I was perfectly happy with Trillian. It satisfied my very modest IM needs. One client for MSN, Yahoo! and AIM.

Jabber is very popular among the folks I collaborate with when I am doing ICANN-related work. Unfortunately, the Jabber plug-in for Trillian was less than cooperative. But one positive aspect about freeware is that you don't have to feel bad if you choose to discard it in favor of something else.

On a colleague's recommendation, I installed GAIM. I like it. Very uncomplicated configuration, clean look and feel (yes, I chose the "no skins" look), and I had my IMs reconfigured in less than a minute.

Of course, the day I choose to create a Jabber account, wouldn't you know that Jabber.org's server decided to act out? From the Jabber.org web page...

2005-03-04: Attempts to register new jabber.org accounts using recent versions of Gaim are failing because of a protocol misunderstanding between Gaim and the jabber.org server...

Did I mention that the IM world learned nothing from the multi-protocol networking wars of the 1980s?

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

Two recent surveys - you might even call them social engineering studies - reveal that office workers have no difficulty disclosing their passwords for a bribe. Infosecurity Europe 2004's organizers were able to obtain passwords from 71% of workers surveyed by offering them chocolate, and TechWeb reports a similar finding (67%) from workers offered three dollar Starbuck's coupon.

Token and certificate-based authentication can't solve this problem (both employ PINs or passwords). Biometrics might raise the stakes: a pound of Teuscher Champagne Truffles is pretty tempting. But the root cause - behavior - must be changed.

What we have here is a rowboat pressing upstream without an OAR: ownership, accountability, and responsibility. Workers who will concede authenticated access to their organization's information network and assets aren't engaged in the security process. These folks don't know, don't care, or trivialize the problems associated with granting access to unauthorized parties. It's not their data, not their network, and claims that the company could suffer serious financial harm are overblown. It's someone else's problem (no ownership).

Perhaps password protection is a reflection of a broader social condition. How often do we claim they are not responsible for a circumstance or problem? And even when proven they are, how often are we held accountable in some punitive way? How often are we contrite enough to change behavior?

Workers need to care about information security before we can consider any authentication *stronger*. Before you invest in technology, see if your workforce is willing to invest in your organization.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID399 by Dave Piscitello  

In the 1990s, everyone apologized for delays and inconveniences by saying, "sorry, the network's slow". Post 9/11, apologists blame delays and inconveniences on The Patriot Act.

Airlines, hotels, and other travel industries generally understand the concept of proof of identity.

"Checking in? Can I see your driver's license or passport, please? It's for The Patriot Act."

Certain banks, unfortunately, haven't quite explained the nuances that distinguish transaction processing from identity verification to all their employees. I visited a bank to get an Debit/ATM card for my son, who never carries cash and is always running out of gas. Before the service assistant could begin processing my request, she asked me, "Can I see your social (security card)? It's for The Patriot Act." I use this number so infrequently, and was so astonished that this information was to serve as credentials to verify my identity that I suffered a momentary brain freeze and transposed some of the numbers.

"Hmmm... that's not the right 'social'. Can I see your ATM or Check Card? Great, thanks. I can look up your account directly. Do you live at 3 Myrtle Bank Lane? Wonderful. So, how can I help you?"

I explain what I want. "I'm sorry, the person applying for an ATM card must apply in person. Sorry, it's The Patriot Act." Honestly, I am not making this up.

"The card is for my son, who never carries cash and is always running out of gas. He attends High School off the island and can't get here during bank hours, " I reply.

"Oh, that's terrible. Let's see what we can do."

Fast-forward to the last page in the episode. I succeed in getting an ATM card under *my* name, for my son's UGMA account. As the custodian of this account, I can have one, but my son can't because he's not yet 18 years old. Of course, issuing me the card gives me the opportunity if not license to let my son use it at ATM machines, which only care that you hold the card and know the PIN. For now, at least. How long before ATMs use facial recognition? After all, it would be "for the Patriot Act".

Has "It's for The Patriot Act." become an interjection? According to the always amusing definitions at http://www.cs.cf.ac.uk/fun/welsh/Glossary_main.html, an interjection is defined as an ejaculatory utterance usually lacking grammatical connection. So I suppose "It's for the Patriot Act" isn't really an interjection. It's an ejaculatory utterance, for sure, but most parties who utter it have no idea what it means or implies.

Sad and deplorable? More like "sad and dangerous".

Archived at http://www.securityskeptic.com/arc20050301.htm#BlogID374 by Dave Piscitello  

BBC reports that the World Bank takes exception to the UN's campaign to increase technology access and use in 3^rd world (a.k.a., poorer) nations.

The World Bank apparently feels that having achieved a 50% access to fixed-line telephone, and 77% to cellular service, the world community has closed the gap faster than anticipated. Apparently, the WSIS's conservative campaign goal was 50% by 2015.

I don't imagine the World Bank wishes to be perceived as suggesting we relax for a decade, but don't the deployment figures suggest momentum? Even the most skeptical might at least concede that near-term profits were lucrative, and there's more left to be had, no?

I'm not impressed with the figures, nor the conservative goals. And I'm not certain that counting landlines and cellular subscribers is the most accurate means of measuring the Digital Divide.

Perhaps we could give World Bank officials a taste of what it's like to be digitally divided? Let's have them share a single fixed line and telephone between two offices. Better: let's have four official share three cell phones.

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

The folks at Microsoft, DeepNet Explorer and Mozilla/Firefox have a countermeasure that compares a web server certificate against the domain name to help defeat attempted server identity fraud.

Nice idea in principle, but in practice, the measure causes many "false positives".

I and others minimize keystrokes by visiting sites without prepending the wuh-wuh-wuh to many domain names. Why bother? It's mostly gratuitous these days, and many sites resolve the name correctly without the prefix. For example, whether I submit a hyperlink "http://google.com/adsense" or "http://www.google.com/adsense", I am directed to the same SSL-secured page.

Unfortunately, the aforementioned browsers overzealously apply the countermeasure, and pop up a Security Alert such as "The name on the security certificate is invalid or does not match the name of the site, do you want to proceed?" when I forego wuh-wuh-wuh.

You can argue that the measure is correctly applied, and you are formally correct. But this is an example of a security measure that becomes intrusive, and begs users to seek out a method to circumvent it. It's also an example of a security measure implemented without a broad understanding of the consequences and complementary actions required for it to be effective and non-intrusive. Web site administrators go through all this effort to make certain web users can resolve "fuzzy" names, but overlook the mismatch between certificates and the names they bind to the identity to which the certificate is assigned.

I can't be certain that browser developers did an adequate job of investigating the impact of this security measure, nor can I be certain they provided sufficient documentation for web administrators, but it really doesn't matter. The measure, as implemented, falls short of my expectations.

Archived at http://www.securityskeptic.com/arc20050101.htm#BlogID344 by Dave Piscitello  

The 12/28/2003 23:15:10 headline on Watchguard Wire is Even XP SP2 doesn't make Internet Explorer safe. The post leads with the statement, "Service Pack 2 for Windows XP was supposed to make all your security problems disappear" and describes a flaw in IE that allows remote code execution. The reporting is accurate, but I found myself asking why (and when) Microsoft made such a claim.

I visited Microsoft's About Windows XP SP2 page, where they state, "Windows XP Service Pack 2 (SP2) provides better protection against viruses, hackers, and worms, and includes Windows Firewall, Pop-up Blocker for Internet Explorer, and the new Windows Security Center." Another rant from Dave the Defender of Redmond, right?

No. I don't ever expect Microsoft to produce an OS, or any other software, that will make my security problems disappear. Generally speaking, I don't expect *anyone* can do this.

What Microsoft does claim is that XP SP2 will provide better, not perfect, protection. Firefox, Opera, and DeepNet Explorer make the same claims: google "browser more secure than IE" versus "browser perfect security" and you'll see my point.

Even the Grayhats authors of the security advisory 'Wire describes introduce the flaw by saying, "Although hundreds of millions of dollars have been spent on securing SP2, perfection is impossible."

Perfection is impossible. Hundreds of thousands of lines of source code, developed, enhanced, and patched by hundreds of individuals with little or no secure coding expertise or training, over a hundred months, will not produce a perfectly secure OS, whether it be closed or open source.

We burn so many cycles arguing "which is better? which is more secure?", as if we had definitive metrics and quantifiable measures for "secure". Absolute and objective conclusions regarding OS security are unachievable for general purpose operating systems, because in the real and commercial world where they are employed, GPOSs must satisfy nearly irreconcilable requirements.

If you know how to write an operating system that is easy to use, trivial to network and perfectly secure, drop me a line.

Archived at http://www.securityskeptic.com/arc20041201.htm#BlogID342 by Dave Piscitello  

In Blog entry #311, I commented on what an unwise decision SecurePoint had made in hiring Sven Jaschan. ZDNet UK recently reported that SecurePoint's decision has cost them a partner. My exact words were "do you want Jaschan anywhere close to the source code for your firewall?

According to a news item by Dan Ilett, antivirus vendor H+BEDV Datentechnik shares my opinion. H+BEDV has decided to walk away from a partnership whereby SecurPoint firewalls would use H+BEDV's Antivirus software as their AV gateway offering.

Chief executive Tarj Auerbach sums up his company's reservations rather succinctly, and you gotta love his logic. If the antivirus engine in SecurePoint's firewall fails to detect a virus and that virus causes considerable damage, customers might be more than a little concerned over the fact that a former virus writer may have had his fingers in the code.

Tarj is quoted as suggesting that the whole incident might "smell a little bit stinky", which reminds me of a favorite saying of a former colleague, Marshall Rose:

If you wallow in the mud with pigs, ...

Archived at http://www.securityskeptic.com/arc20041101.htm#BlogID332 by Dave Piscitello  

My frustration level with bug-traq increases in direct proportion to the frequency at which wannabes report vulnerabilities on software that has limited consumption and little business on a business network. I finally contacted some of the wannabes. I probed each for more specifics than the original bug disclosure:

What version of Windows did you discover this on? When was the software last released? Does the software vendor claim compatibility with the Windows version? Is the software on any compatibility list? What are the specific elements of the attack vector, and what is the probability that these can be encountered in real world Internet connection scenarios? Why should we worry or care about this bug?

You can guess the reactions. One wannabe couldn't answer any question but flamed me for not appreciating the spirit of the hunt. The exchange I had with one wannabe who posted a report of a buffer overflow in a 2001 version of a PC game on Windows 98SE is indicative of the problem:

Dave: "What practical consequence does this bug have for someone operating a large business network?

Wannabe: "Nothing, this game is not so much diffused and in a "large business network" the people should do their job, not play with games (except if the company is a software house that develops games)."

Dave: "The game's 4 years old, and wasn't a very good one. What's the attack vector for this game? Think of all the conditions that have to fall into place to compromise one home computer. It's too improbable to bother reporting, and the vendor is not going to invest a penny to fix it. So who benefits from the report?"

It's time for a reality traq on bug-traq. Thousands of professionals read this list to try to keep ahead of exploits and problems that could lead to significant large network exposures. Bug-traq has deteriorated from a place where we could go to help keep networks and applications healthy to a community of people who want 30 seconds of fame from identifying an obscure bug of little importance that affects a very small population. Put yourself in the position of someone really trying to apply bug-traq to make networks work well for his users. Now think about having to flog through several hundred reported and suspected vulnerabilities of little importance to find the one that affects your organization."

I closed my email by asking the wannabe to consider applying his talents to investigating applications and communications protocols where he can make a positive impact. I think this is sound advice for everyone on bug-traq.

Archived at http://www.securityskeptic.com/arc20041001.htm#BlogID319 by Dave Piscitello  

Sasser and Netsky worm creator Sven Jaschan is now an employee of SecurePoint, a security appliance company in Germany.

Everyone in the security community should be disappointed and opposed to SecurePoint's decision. Jaschan should be in jail, making license plates or clothespins, and contemplating the error of his ways. Instead, Securepoint is providing him a comfortable living and a fast track to repay the nearly $160,000 he owes for acts of computer sabotage.

My opinion regarding hiring and glamorizing crackers is long-documented in Security Hats: Black and White, no Grayscale. In this column, I identify five reason why you should not hire crackers. I only wish Securepoint had read it.

It absolutely astonishes me that Securepoint would make such a moronic move when viruses and worms are sapping IT dollars faster than OPEC is producing oil.

Ask yourself: do you want Jaschan anywhere close to the source code for your firewall?

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

After two weeks of whining about how woeful XP SP2 is and how lamentable Windows security is, I can't help but be amused at the recent barrage of MacOS X vulnerabilities and the concomitant patching frenzy.

In case you've missed the advisories:

Apple fixes 15 flaws in Mac OS X. (see the entire list at List of 15 Flaws)

Mac OS X CoreFoundation Buffer Overflow and Library Loading Bugs Let Local Users Gain Elevated Privileges

Apple QuickTime Streaming Server State Error Lets Remote Users Deny Service

Apple Safari Frame Boundary Flaw Lets Remote Users Render HTML in an Arbitrary Site's Domain

I bring these to your attention for two reasons. The first is to silence the Linux lambs, or

at least pause the annoying bleating for an afternoon. According to the article, "Many of the problems are flaws in the [Mac OS X] operating system's underlying open-source software". Sorry, your open source code is as flawed and exploitable as Redmond's. Spend the afternoon checking your code for buffer overflows instead of ranting about the poor quality of someone else's code.

The second is to corroborate a claim I share with many of my colleagues: general-purpose, commercial operating systems all have their share of security flaws and exploitable code. The bickering and dirt-slinging is as bad as any you'll see from the Democrats and Republicans between now and November.

Sadder still, it serves the same purpose: distract the public's attention from the fact that your party's just as incapable of publicly confronting and solving the real problems as your antagonist.

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

"De-perimeterization" is popular among the VPN, application protection, and web services communities. It's another in the never-ending stream of labels that marketing wonks invent to distinguish what they are trying to sell from what everyone else is selling. It's a dumb and inaccurate term that only serves to confuse buyers, which ultimately causes them to buy badly, or not buy at all. De-perimeterization is a testimony to the shortcomings of a society that operates on ten-word sound bites.

De-perimeterization is "a worldwide push toward a more porous corporate shell yet more secure collaborations in our increasingly interconnected online world"¹. De-perimeterization is yet another forecast of the demise of the corporate perimeter, the traditional network firewall, in this case due to the increased employment of web services in collaborative networking: simply put, not only people but executable code (services) move across enterprises, mostly over web, and hence through ports that network firewalls allow inbound and outbound.

What the term tries to convey can't easily be done in one word. What the term and the hype woefully misrepresent spreads the F.U.D.

De perimeter exists. You've misappropriated the prefix de.

There are many perimeters in the present and future enterprise. The perimeter that that de-perimeterization tries to deprecate is maintained through network layer firewalls. It's not going away. It's now decentralized through the use of personal, teleworker, and small office firewalls as complements to enterprise Internet-facing and compartmental firewalls.

Further complementing the network layer perimeter is a perimeter of application protection. This additional layer of security will be responsible for assuring that application connections are authenticated and that the data conveyed over them is authentic and (where appropriate) confidential. And by this, I don't mean "VPN".

The column I cited earlier casts skepticism on de-perimeterization's ultimate goal: "worldwide use of system-, data- and connection-level authentication". While I hate the term, I love the objective. What is often misunderstood when we use the word data is that data includes identities, information web services process and and the executable code (services) organizations exchange, as well as the channels over which this data are communicated. This is not de-perimeterization at all, but the addition of federated identities to our existing layers of security.

We don't need a new term. We need people to RTFM and use the terms we have appropriately.

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

My colleague and friend, David Strom, has been discussing blogs and self-publishing in his recent Web Informants #382 and #383 .

In WI #383, David permits Deb Radcliff of the Freelance Business and Technology Writers' Association (www.fbtw.org) to comment on self-publishing. Deb presents a dim view of self-publishing, and I'd like to offer a rebuttal to the conclusion that "Self-publishers and blogs are unsafe, abusive, and lack credibility" expressed therein.

I don't dispute that many blogs are unsafe, lack credibility, exhibit poor judgement and dreadful taste. But these sad examples, in general, are hosted blogging sites. They are largely unsupervised playgrounds, and educating folks about the risks and credibility of such venues is A Good Thing.

I do find more and more serious professionals using blog software rather than web publishing tools to produce very credible and valuable content. These folks - and I include myself - run their own secure servers. They moderate and filter comments, and the responsible ones are as fastidious regarding privacy, error and libel as traditional media. Professional self-publishers invest time, talent, and research as seriously in their blog endeavors as they do when they freelance or write white papers for traditional publishers. Such blogs offer professionals to explore other topics than those they typically provide consultation and advice. Some are personal, and they give readers and potential clients valuable insight into the character of the individual they might hire. Some are off the mainstream topics, and perhaps reveal clients other dimensions of the practitioner/consultant.

Some are editorial. There are too few traditional publications to permit broad editorial opportunities for the number of people who are capable of providing credible OpEd, Others are simply pro bono activities. A security professional publishes a brief configuration note for IIS or Windows 2003 server. An HTML professional recommends a utility that generates reports from web log files. These are all valuable activities.

Many such blogs offer RSS feeds. I routinely visit at least a dozen such blogs. I find them to be a marvellous complement to traditional publications. And in a number of cases, I find the stories more accurate and technical than those a beat writer composes.

Self-publishing is easy. Like traditional publishing, GOOD self-publishing is demanding, and the good self-publishers hold themselves accountable. You can get the same protections from responsible self-publishers as you get from traditional media.

It's just as inappropriate to lump all blogs in the "iffy and unreliable" category as it is to claim all newspapers are scandal rags.Don't condemn a technology, castigate instead those who misuse it.

Archived at http://www.securityskeptic.com/arc20040801.htm#BlogID297 by Dave Piscitello  

Lurk on any mailing list long enough and you'll invariably eyeball a subject line that makes you question why you've bothered to lurk at all. A recent subject line, "Microsoft technologies. By default, non-HIPAA compliant?" from (who else?) but abm@anythingbutmicrosoft.org, made me blink, laugh, then laugh again. What is it with Linux people that every issue reduces to Klingons versus Earthlings? It's Linux, not Linix.

The notion that any operating system's default or "out of the box" configuration is HIPAA compliant is childishly amusing. But, if you overlook the twin implications in the subject line - by definition, Windows could never be, but someone could ship Linux in a way that it could be - you have to worry that most folks, including many who practice security, still don't know how to distinguish policy from product and implementation (deployment).

In a physician's office, handwritten patient histories, facsimiles, and printouts of test results are all examples of healthcare information protected under HIPAA. In the real world of small town physician's offices and rural clinics, these are "protected" and satisfy HIPAA regulations if they are stored in locked file cabinet made of what most of us would consider only modestly tamper- and fire-resistant. Locks on the doors to the rooms in which the cabinets are situated adds a layer of security. Locking any doors that deny access to unauthorized individuals during and outside office hours adds yet another layer of security, and thus you have defense in depth.

I'm thinking as I wait for new posts to this thread, "HIPAA identifies the criteria you have to satisfy to protect healthcare information. Wouldn't I satisfy HIPAA regs were I to store medical records in ASCII files on a pre-Pentium PC running CPM-86 or MS-DOS 3.1 if I didn't network the PC and locked it away as securely as physicians customarily lock file cabinets? Sure. No internet connection, locks in place... suppose I remove the power supply each night..."

Lingering on the list, I wait for someone to inject some sanity into the discussion. Sure enough, someone offers the following: "HIPAA has very few direct requirements. A lot of what needs to be done depends on the environment. For example, if I have a closed environment with no Internet connections (yes, this happens in some places) and sufficient controls to protect servers against insiders, then the latest ... problems are of no concern at all."

Sane minds prevail! HIPAA has few direct requirements because even much-maligned regulators appreciate that it's imprudent and illogical to mandate a particular authentication method, encryption algorithm, security (e.g., VPN) protocol or other security solution without considering the risk profile for each situation where HIPAA or any other regulation must be satisfied. Some solutions, such as the use of biometrics for physical access, might satisfy HIPAA in the overwhelming majority of situations, but such methods are prohibitively expensive for a rural clinic. Others, like the use of passwords, for example, may meet HIPAA guidelines if other measures are present to reduce the likelihood of theft and misuse.

Context, me lad, context!

And lose the Micro$oft attitude...

Archived at http://www.securityskeptic.com/arc20040701.htm#BlogID280 by Dave Piscitello  

The ACLJ and Bush administration are no doubt less encouraged by recent Supreme Court decisions than I am. Mind you, I'm no fan of child pornography and terrorism, but I am a great fan of the U.S. Constitution. As loathsome as I find child porn, I have to agree that the Child Porn Prevention Act of 1996 is overly broad and vaguely worded. The CPPA needs better language to be effective. In its current form, it's easily manipulated by law enforcement and equally easy for porn mongers to elude. Write an enforceable law, then enforce it.

I abhor violence and terrorism, but I also have to agree that terrorist suspects held by the military, both foreign nationals and American, have the right to challenge their detention in the U.S. court system. I'm not comfortable claiming the United States is a democratic society when we can arbitrarily call someone an enemy combatant, detain that individual, and deny the right to challenge that detention in a U.S court. Detention of this sort was wrong in the 1770s, the 1930s and 40s, and it remains wrong today. By including foreign nationals, the Supreme Court's clearly tells the international community something the current administration has failed again and again to convey. We aren't exclusionary in our definitions of democracy and equality. The life of an American citizen is not more valuable than the life of any other world citizen.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID276 by Dave Piscitello  

The theme for SearchSecurity.com: This Week May 17, 2004, is Defense-in-depth. The promo for this Joel Snyder webcast explains that, "Perimeter defense leads to a network that is crunchy on the outside but soft on the inside."

I'm pretty certain that the phrase, "defense in depth" originated in the DoD. I'm also certain that the D0D didn't intend defenses to ever be crunchy, but rather, hard. Crunchy conjures images of World War II G.I.'s being overrun by German Panzers in the Ardennes forest. Knowing Joel, I don't think he'd have chosen crunchy if given a choice.

Fried chicken, various breads and candies are crunchy on the outside. Defenses shouldn't be crunchy. This is a case of marketing copy gone awry. Googling, I find that others have used crunchy to describe security for SANS and WLANs. The phrase draws a bad analogy, please don't use it.

Defense in depth means strong perimeter *and* interior defenses. Phil Carden wrote a column in 1997 titled Stored File Encryption: Boiled Eggs and Scrambled Data, in which he explained that security architectures that store data in plain text are like soft-boiled eggs, whereas those that utilize stored data encryption are like hard-boiled eggs.

Dr. Bill Hancock coined and frequently used the Twinkie analogy. In TISC and SANS presentations during 1999, Bill claimed that, "Security is like a Twinkie: it's what's inside that counts".

Today, the Twinkie analogy is accurate for a different reason than Dr. Bill intended. Most perimeters are not hard. We alternatively describe security perimeters as extended, inverted, collapsed, and fluid. In a word, they're soft.

The latest buzzword among the endpoint and web services security wonks is de-perimeterized. I loathe when nouns are used as verbs, so I can't in good conscience bless the term without de-intelligencing or stupidating myself. Let me simply say that the term "perimeter" is no longer applicable when used in the singular for a given organization. If you use perimeter, use the plural, perimeters.

Every mobile client - perhaps every client - should have its own a perimeter defense (in the form of a personal firewall software or an OS hardened against network attacks). Every broadband connection - generally, every network segment where a security policy describes a trusted versus untrusted interface - should have a perimeter (firewall). Every application server farm should have a perimeter (application and network firewall).

Joel will almost certainly tell you to secure the interior of your network. I wholeheartedly agree. Remember, however, that defense in depth implies layers of security, and one of the layers consists of many, strong perimeters.

Archived at http://www.securityskeptic.com/arc20040501.htm#BlogID252 by Dave Piscitello  

The 2003 CSI/FBI Computer Crime survey has lots of folks worrying that it's difficult to detect insider initiated attacks. I actually worry more about insider error.

Insider errors are more prolific than attacks. They may be root causes of attacks. They include:

• The employee who creates unprotected shares;

• runs unauthorized services;

• has no use for personal firewall software;

• fails to patch and hot fix operating systems and applications;

• falls prey to spoof email or phishing;

• fails to maintain virus definitions;

• keeps accounts and passwords in text files created in NotePad, and caches passwords to save keystrokes;

• installs software of unverified origin, without approval.

Such employees fall victim to spyware, keyloggers, worms, trojans, and combinations thereof (also known as blended threats).

Blame the employee? Perhaps. Blame the policies and processes that make non-technical employees responsible for client security and administration?

Better.