Perilocity

John Quarterman on Mapping Spam and Politics (audio)

At a meeting on a completely different subject, I was interviewed about SpamRankings.net. Here's the audio, and here's the blurb they supplied:

John S. Quarterman, long time Internet denizen, wrote one of the seminal books about networking prior to the commercialization of the Internet. He co-founded the first Internet consulting firm in Texas (TIC) in 1986, and co-founded one of the first ISPs in Austin (Zilker Internet Park, since sold to Jump Point). He was a founder of TISPA, the Texas ISP Association. Quarterman was born and raised in Lowndes County, where he married his wife Gretchen. They live on the same land where he grew up, and participate in local community and government.

Quarterman took some time during Georgia River Network's Weekend for Rivers to speak with the Nonprofit Snapshot about spam-mapping and small town politics.

More about Elinor Ostrom's Nobel-prize-winning work on organizing the commons, and how that applies to SpamRankings.net.

The water organization has since been incorporated as the Georgia non-profit WWALS Watershed Coalition:

WWALS is an advocacy organization working for watershed conservation of the Willacoochee, Withlacoochee, Alapaha, and Little River Systems watershed in south Georgia and north Florida through awareness, environmental monitoring, and citizen advocacy.

-jsq

eCrime Summit in Prague 25-27 April 2012

These ecrime meetings are always interesting and useful. -jsq

Press release of 29 March:

Containing the Global Cybercrime Threat is Focus of Counter eCrime Operations Summit (CeCOS VI) in Prague, April 25-27

CeCOS VI, in Prague, Czech Republic, to focus on harmonizing operational issues, cybercrime data exchange, and industrial policies to strengthen and unify the global counter-ecrime effort.

CAMBRIDGE, Mass.—(BUSINESS WIRE)—The 6th annual Counter eCrime Operations Summit (CeCOS VI) will convene in Prague, Czech Republic, April 25-27, 2012, as the APWG gathers global leaders from the financial services, technology, government, law enforcement, communications sectors, and research centers to define common goals and harmonize resources to strengthen the global counter-cybercrime effort.

CeCOS VI Prague will review the development of response systems and resources available to counter-cybercrime managers and forensic professionals from around the world.

Specific goals of this high-level, multi-national conference are to identify common forensic needs, in terms of the data, tools, and communications protocols required to harmonize cybercrime response across borders and between private sector financial and industrial sector responders and public sector policy professionals and law enforcement.

Key presentations will include:

Hermeneutic Distanciation

The text of one particular talk here at eCrime is experiencing autonomization, as it is being appropriated as part of a social construction which might actually be used in enactment. -jsq

Quis custodiet ipsos medici?

Internet security is in a position similar to that of safety in the medical industry. Many doctors have an opinion like this one, quoted by Kent Bottles:

"Only 33% of my patients with diabetes have glycated hemoglobin levels that are at goal. Only 44% have cholesterol levels at goal. A measly 26% have blood pressure at goal. All my grades are well below my institution’s targets." And she says, "I don’t even bother checking the results anymore. I just quietly push the reports under my pile of unread journals, phone messages, insurance forms, and prior authorizations."

Meanwhile, according to the CDC, 99,000 people die in the U.S. per year because of health-care associated infections. That is equivalent of an airliner crash every day. It's three times the rate of deaths by automobile accidents.

The basic medical error problems observed by Dennis Quaid when his twin babies almost died due to repeated massive medically-administered overdoses and due to software problems such as ably analysed by Nancy Leveson for the infamous 1980s Therac-25 cancer-radiation device are not in any way unique to computing in medicine. The solutions to those problems are analogous to some of the solutions IT security needs: measurements plus six or seven layers of aggregation, analysis, and distribution.

As Gardiner Harris reported in the New York Times, August 20, 2010, another problem is that intravenous and feeding tubes are not distinguished by shape or color:

What we can learn from the Therac-25

What does Nancy Leveson's classic analysis of the Therac-25 recommend? ("An Investigation of the Therac-25 Accidents," by Nancy Leveson, University of Washington and Clark S. Turner, University of California, Irvine, IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41.)

"Inadequate Investigation or Followup on Accident Reports. Every company building safety-critical systems should have audit trails and analysis procedures that are applied whenever any hint of a problem is found that might lead to an accident." p. 47

"Government Oversight and Standards. Once the FDA got involved in the Therac-25, their response was impressive, especially considering how little experience they had with similar problems in computer-controlled medical devices. Since the Therac-25 events, the FDA has moved to improve the reporting system and to augment their procedures and guidelines to include software. The input and pressure from the user group was also important in getting the machine fixed and provides an important lesson to users in other industries." pp. 48-49

The lesson being that you have to have built-in audit, reporting, transparency, and user visibility for reputation.

Which is exactly what Dennis Quaid is asking for.

Remember, most of those 99,000 deaths a year from medical errors aren't due to control of complicated therapy equipment:

Community Flow-spec Project

A lightning talk at NANOG 48, Austin, Texas, 22 Feb 2010, by John Kristoff, Team Cymru. See RFC 5575.

Update: PDF of presentation slides here.

+--------+--------------------+--------------------------+
| type   | extended community | encoding                 |
+--------+--------------------+--------------------------+
| 0x8006 | traffic-rate       | 2-byte as#, 4-byte float |
| 0x8007 | traffic-action     | bitmask                  |
| 0x8008 | redirect           | 6-byte Route Target      |
| 0x8009 | traffic-marking    | DSCP value               |
+--------+--------------------+--------------------------+

A few selected points:

• Dissemination of Flow Specification Rules
• Think of filters(ACLs) distributed via BGP
• BGP possibly not the right mechanism
• Multi-hop real-time black hole on steroids
• Abuse Handler + Peering Coordinator
  = Abeering Coordinator?
• Traditional bogon feed as source prefix flow routes
• A la carte feeds (troublesome IP multicast groups, etc.)
• AS path prepend++
• Feed-specific community + no-export

He showed some examples of specs for flows (I can't type fast enough to transcribe those).

Trust issues for routes defined by victim networks.

Research prototype is set up. For questions, comments, setup, contact: http://www.cymru.com/jtk/

I like it as an example of collective action against the bad guys. How to deal with the trust issues seems the biggest item to me.

Hm, at least to the participating community, this is a reputation system.

Checks on Checks, or Shipping and Shipping Software

Paul Graham points out that big company checks on purchasing usually have costs, such as purchasing checks increase the costs of purchased items because the vendors have to factor in their costs of passing the checks.

Such things happen constantly to the biggest organizations of all, governments. But checks instituted by governments can cause much worse problems than merely overpaying. Checks instituted by governments can cripple a country's whole economy. Up till about 1400, China was richer and more technologically advanced than Europe. One reason Europe pulled ahead was that the Chinese government restricted long trading voyages. So it was left to the Europeans to explore and eventually to dominate the rest of the world, including China.

— The Other Half of "Artists Ship", by Paul Graham, November 2008

I would say western governments (especially the U.S.) subsidizing petroleum production and not renewable energy is one of the biggest source of current world economic, political, and military problems. Of course, lack of checks can also have adverse effects as we've just seen with the fancy derivatives the shadow banking system sold in a pyramid scheme throughout the world. It's like there should be a balance on checks. Which I suppose is Graham's point: without taking into account the costs of checks (and I would argue also the risks of not having checks), how can you strike such a balance?

He doesn't neglect to apply his hypothesis to SOX:

Better Products Bootstrap

Gunnnar notes the formation of a software vendor security best practices consortium and asks:

Why not bootstrap a Fortune 500 Secure Coding Initiative to drive better products, services and share best practices in the software security space?

— Secure Coding Advocacy Group, Gunnar Peterson, 1 Raindrop, 23 October 2007

Yes, if the customers demanded it, that might make some difference, and the vendors do pay the most attention to the biggest customers. Of course the biggest customer is the U.S. government, and they seem more interested in CYA than in actual security. And I'm a bit jaded on "best practices" due to reading Black Swans. But regardless of the specific form of better such a group demanded, demanding better security might make some difference.

Maybe they could also demand risk management, which would including having watchers watching ipsos custodes. Not just in the circular never-ending hamster wheel of death style, but for actual improvemment.

-jsq

What It Will Take to Win

IT and Internet security people and companies act mostly as an aftermarket. Meanwhile, the black hats are a well-integrated economy of coders, bot herders, and entrepeneurs. This is what it will take for the white hats to win:

It can seem overwhelming for security people who are typically housed in a separate organization, to begin to engage with software developers and architects to implement secure coding practices in an enterprise. While the security team may know that there are security vulnerabilities in the systems, they have to be able to articulate the specific issues and communicate some ideas on resolutions. This can be a daunting task especially if the security team does not have a prior workign relationship with the development staff, and understand their environment.

...

The task seems daunting also because there are so many developers compared to security people. I am here to tell you though that you don't have to win over every last developer to make some major improvements. In my experience a small percentage of developers write the majority of code that actually goes live. The lead developers (who may be buried deep in the org charts) are the ones you need to engage, in many cases they really don't want to write insecure code, they just lack the knowledge of how to build better. Once you have a relationship (i.e. that you are not just there to audit and report on them, but are there to help *build* more secure code) it is surprisingly easy to get security improvements into a system, especially if the design is well thought and clearly articulated. You don't have get the proverbial stardotstar, each and every developer on board to make positive improvements, it can be incremental. See some more specific ideas on phasing security in the SD! LC here. In meantime, with security budgets increasing 20% a year, use some of that money to take your top developers out to lunch.

— Secure Coding - Getting Buy In, Gunnar Peterson, 1Raindrop, 17 Sep 2007

The start of what it will take.

-jsq

Quantitative >= Qualitative

See Pete Lindstrom's Spire Security Viewpoint for empirical evidence that mechanical quantitative diagnosis is almost always at least as good as clinical qualitative diagnosis.

There is still plenty of room for qualitative decision-making in arenas where there aren't enough facts or the facts haven't been quantified or there's no baseline or there's no mechanical method yet. But where those things are available, it's better to use them. You'll still need qualitative judgement for cases where the algorithm is right but it didn't take into effect unfortunate side effects, for instance. Even then, you've got a better chance of knowing what you're doing.

-jsq