around the time we were doing some work on the original payment gateway (for what has since became to be called e-commerce)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

I frequently commented that to take a standard, well-tested application and turn it into an industrial strength dataprocessing "service", typically required 4-10 times the original effort. as mentioned in the above references ... two of the people that we had worked with when we were doing our high-availability (ha/cmp) product ... were now responsible for the commerce server. old posting about an old ha/cmp meeting
http://www.garlic.com/~lynn/95.html#13

misc. past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

we have also made the statement that that payment gateway could be considered the original SOA ... part of that is from coming up with 3-tier architecture in the 80s
http://www.garlic.com/~lynn/subnetwork.html#3tier

when we started ha/cmp we did a detailed failure mode analysis on tcp/ip protocol and code. some of the items we turned up ... showed up in attacks nearly 10 years later .... i.e. from the standpoint of doing industrial strength dataprocessing ... a failure mode analysis is a superset of some types of security treat analysis .... or you upgrade the term threat analysis to any type of problem ... not solely limited to stuff related to human attackers.

of course part of the history was having done a lot of work in the 60s & 70s on operating systems that were used for commercial time-sharing services
http://www.garlic.com/~lynn/subtopic.html#timeshare

where the implicit assumption was that the full community of users could have hostile intent with regard to each other ... compared to today where very few people take seriously that the default assumption is the standard operating environment is extremely hostile.

there used to be the old joke that computer science institutional memory is no more than five years. this somewhat goes along with the current idea that free software is something new ... as opposed to be the default in the 50s, 60s, and 70s. some amount of the change was gov. litigation and the resulting 23jun69 unbundling announcement that started trend charging for software ... some number of past posts about transition from free software to charge-for/licensed software
http://www.garlic.com/~lynn/subtopic.html#unbundle

some past posts mentioning identifying failure modes ... some of which didn't actually materialize (in attacks) to nearly ten years later:
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor

some number of past posts mentioning it taking 4-10 times the effort to turn a well-tested application into an industrial strength service
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003g.html#62 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003j.html#15 A Dark Day
http://www.garlic.com/~lynn/2003p.html#37 The BASIC Variations
http://www.garlic.com/~lynn/2004b.html#8 Mars Rover Not Responding
http://www.garlic.com/~lynn/2004b.html#48 Automating secure transactions
http://www.garlic.com/~lynn/2004k.html#20 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004l.html#49 "Perfect" or "Provable" security both crypto and non-crypto?
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#63 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2006n.html#20 The System/360 Model 20 Wasn't As Bad As All That

there is something of an analogy with driving ... long ago you could have an environment that didn't have bumpers, safety glass, collapsible steering column, padded dashboard, safetybelts, door locks, ant-theft devices, alarms, air bags, guard rails, impact barriers, crush zones, stop signs, and a ton of other countermeasures for all the possible bad things that might happen.

part of the current programming state of the art ... is that it appears that nearly all of the countermeasures have to be re-invented from scratch for every new effort (if there is any attempt to address the issues at all).

note that in some of the scenarios ... a particular piece of software is more like a single component ... like the engine ... so a lot of the necessary countermeasures aren't part of the engine operation ... it would be part of other components.

a basic issue is designing and implementing an overall infrastructure that has all the necessary countermeasures designed in as part of the fundamental operation .... aftermarket piecemeal is significantly less effective than having it alld designed in from the start.

re:
http://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science

another scenario ... is the x9.59 paradigm change.

if you take the security acronym PAIN

P -- privacy (or sometimes cain and confidentiality)
A -- authentication
I -- integrity
N -- non-repudiation

much of the current retail payment environment is dependent on privacy (information hiding and encryption). the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments (as part of the x9.59 standard work)
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

x9.59 changed the paradigm and requires integrity and authentication ... but no longer requires data hiding encryption (privacy) as part of the transaction in order to preserve the integrity of the financial infrastructure for all retail payments.

this is somewhat the past comments about moving away from naked payment/transaction paradigm:
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues

i guess i have to admit to being on a roll.

one of the big issues is inadequate design and/or assumptions ... in part, failing to assume that the operating environment is an extremely hostile environment with an enormous number of bad things that can happen.

i would even assert that the enormous amounts of money spent attempting to patch an inadequate implementation can be orders of magnitude larger than the cost of doing it right in the first place.

some of this is security proportional to risk ... where it is also fundamdental that what may be at risk is correctly identified.

this is my old standby security proportional to risk posting
http://www.garlic.com/~lynn/2001h.html#61

these are postings in a pki/ca security proportional risk thread from today
http://www.garlic.com/~lynn/2006s.html#4
http://www.garlic.com/~lynn/2006s.html#5

and as i've observed before that possibly part of the "yes card" exploits has been assumptions that there would be attacks on the chipcard ... where, in fact, the "yes card" attacks are on the terminal and infrastructure (and the chipcard attack countermeasures pretty much failed to address terminal/infrastructure attacks at all)
http://www.garlic.com/~lynn/subintegrity.html#yescard

But the real solution is to make the right folks responsible for the task. We had a big problem with stolen credit cards until the credit card providers were financially responsible for (almost) all the losses incurred. Suddenly, security measures were taken which reduced the problem to whatever the losers were willing to bear. That works. But when they can make the problem an "externality" (as happens with identity theft these days) the problem will not be contained. The people who can contain it lack the motivation. End of story.

Bruce Schneier writes clearly about these topics at Schneier.com so you can read it for free.

Funny... yes, incentives is part of the story, but not the whole part. It's the Internet, remember, and the attackers don't like your funny incentives. Also, your defenders need to get their training somewhere. And if you don't do that, then the company goes out and hires some company like Counterpane or Symantec or ..., and we're back with muddled incentives again.

Here's something you should read: someone reaching out and communicating with the blackhats. Coz he needs their help, and they might even do it ... not because he got his ethics out of a cornflakes packet.

http://www.wired.com/wired/archive/15.01/cybercop_pr.html

** *** ***** ******* *********** *************

Teaching Viruses

Over two years ago, George Ledin wrote an essay in "Communications of the ACM," where he advocated teaching worms and viruses to computer science majors: "Computer science students should learn to recognize, analyze, disable, and remove malware. To do so, they must study currently circulating viruses and worms, and program their own. Programming is to computer science what field training is to police work and clinical experience is to surgery. Reading a book is not enough. Why does industry hire convicted hackers as security consultants? Because we have failed to educate our majors."

This spring semester, he taught the course at Sonoma State University. It got a lot of press coverage. No one wrote a virus for a class project. No new malware got into the wild. No new breed of supervillain graduated.

Teaching this stuff is just plain smart.

Essay:
http://www.csl.sri.com/neumann/insiderisks05.html#175

http://www.sonoma.edu/pubs/newsrelease/archives/001090.html
http://www1.pressdemocrat.com/apps/pbcs.dll/article?AID=/20070522/NEWS/705220312/1033/NEWS01 or http://tinyurl.com/ytrbzs
http://blogs.pcworld.com/staffblog/archives/004452.html
http://www1.pressdemocrat.com/apps/pbcs.dll/article?AID=/20070526/NEWS/705260309/1043/OPINION01 or http://tinyurl.com/2e2anv
http://www.hardocp.com/news.html?news=MjU5NzgsLCxoZW50aHVzaWFzdCwsLDE
http://technews.acm.org/archives.cfm?fo=2007-05-may/may-25-2007.html#313412 or http://tinyurl.com/yuur5l
http://www.calstate.edu/pa/clips2007/may/22may/virus.shtml