Home page logo

risks logo RISKS Forum mailing list archives

Risks Digest 27.38
From: RISKS List Owner <risko () csl sri com>
Date: Fri, 26 Jul 2013 10:53:03 PDT

RISKS-LIST: Risks-Forum Digest  Friday 26 July 2013  Volume 27 : Issue 38

Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
The current issue can be found at

Star Wars Redux (Peter G. Neumann)
Hackers Reveal Nasty New Car Attacks--With Me Behind The Wheel
  (Andy Greenberg via Steve Goldstein via Dewayne Hendricks)
The risks of DNA "Certainty" (Bob Frankston)
Cybersecurity hacking estimates exaggerated for profit (Lauren Weinstein)
PIN-Punching Robot Cracks Phone's Security Code In 24 Hours (Andy Greenberg
  via Henry Baker)
"Researchers spot new breed of infected Android apps in the wild"
  (Ted Samson via Gene Wirchenko)
"SIM cards vulnerable to hacking, says researcher" (Jeremy Kirk via
  Gene Wirchenko)
Citi Bike Accidentally Exposes Customer Credit Card Information (Ted Mann
  via Jim Reisert)
Re: PayPal 'credits' US man $92 quadrillion in error (Mark Brader,
  Bill Stewart, Chris Drewe)
Fool proofs? (Re: UBS fined $30,000 for a typing error, Bertrand Meyer)
Re: Government Destroys $170k of Hardware ... (Rob Slade)
Hardware destruction in perspective (Steve Lamont)
Re: "How the Pentagon's payroll quagmire traps soldiers (Gene Wirchenko)
Re: "How to Build Versatile and Reusable Software" (Gene Wirchenko)
REVIEW: "Intelligent Internal Control and Risk Management", Leitch
  (Rob Slade)
Abridged info on RISKS (comp.risks)


Date: Thu, 25 Jul 2013 13:47:06 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Star Wars Redux

In the very first RISKS issue, RISKS-1.01 (1 Aug 1985), I posited the need
for open discussion of the risks involved in the Strategic Defense
Initiative, and suggested that past experiences with very large projects
requiring extensive new technology and system engineering were generally
less successful than anticipated:

  ... the problems of developing software for critical environments are very
  pervasive -- and not just limited to strategic defense.  But what we learn
  in discussing the feasibility of the strategic defense initiative could
  have great impact on the uses that computers find in other critical
  environments.  In general, we may find that the risks are far too high in
  many of the critical computing environments on which we depend.  We may
  also be led to techniques for developing better systems that can
  adequately satisfy all of their critical requirements -- and continue to
  do so.  But perhaps most important of all is the increased awareness that
  can come from intelligent discussion.  Thus, an open forum on this subject
  is very important.

An editorial in *The New York Times* today revisits this thorny subject,
and suggests that we are still far away from what might be needed:

  A Failure to Intercept:
  Will America ever have effective ground-based missile defense?

  After 30 years of research and an estimated $250 billion investment, the
  Pentagon's defense program against intercontinental ballistic missiles
  ... had another failed test this month... the third consecutive dud.  The
  military has tested the ground-based midcourse defense system 16 times;
  only eight were successful, the last in 2008.  One might expect the record
  to be near perfect since the tests are rigged ...  ``controlled scripted

  Two studies ... have expressed new doubts ...

  But it doesn't make sense to keep throwing money at a flawed system
  without correcting the problems first.

The entire editorial is worth reading carefully, although it may not be new
news to many long-time RISKS readers.


Date: July 25, 2013 10:51:07 AM EDT
From: Dewayne Hendricks <dewayne () warpspeed com>
Subject: Hackers Reveal Nasty New Car Attacks--With Me Behind The Wheel

  [Note: This item comes from friend Steve Goldstein.  DLH][via Dave Farber]

From: Steve Goldstein <steve.goldstein () cox net>
Subject: Hackers Reveal Nasty New Car Attacks--With Me Behind The Wheel
  (Video) - Forbes
Date: July 25, 2013 7:21:34 AM PDT

Andy Greenberg, *Forbes*, 24 Jul 2013

Stomping on the brakes of a 3,500-pound Ford Escape that refuses to stop --
or even slow down -- produces a unique feeling of anxiety. In this case it
also produces a deep groaning sound, like an angry water buffalo bellowing
somewhere under the SUV's chassis. The more I pound the pedal, the louder
the groan gets --along with the delighted cackling of the two hackers
sitting behind me in the backseat.

Luckily, all of this is happening at less than 5mph. So the Escape merely
plows into a stand of 6-foot-high weeds growing in the abandoned parking lot
of a South Bend, Ind. strip mall that Charlie Miller and Chris Valasek have
chosen as the testing grounds for the day's experiments, a few of which are
shown in the video below. (When Miller discovered the brake-disabling trick,
he wasn't so lucky: The soccer-mom mobile barreled through his garage,
crushing his lawn mower and inflicting $150 worth of damage to the rear

``Okay, now your brakes work again,'' Miller says, tapping on a beat-up
MacBook connected by a cable to an inconspicuous data port near the parking
brake. I reverse out of the weeds and warily bring the car to a stop. ``When
you lose faith that a car will do what you tell it to do,'' he adds after we
jump out of the SUV, ``it really changes your whole view of how the thing

This fact, that a car is not a simple machine of glass and steel but a
hackable network of computers, is what Miller and Valasek have spent the
last year trying to demonstrate. Miller, a 40-year-old security engineer at
Twitter, and Valasek, the 31-year-old director of security intelligence at
the Seattle consultancy IOActive, received an $80,000-plus grant last fall
from the mad-scientist research arm of the Pentagon known as the Defense
Advanced Research Projects Agency to root out security vulnerabilities in

The duo plans to release their findings and the attack software they
developed at the hacker conference Defcon in Las Vegas next month -- the
better, they say, to help other researchers find and fix the auto industry's
security problems before malicious hackers get under the hoods of
unsuspecting drivers. The need for scrutiny is growing as cars are
increasingly automated and connected to the Internet, and the problem goes
well beyond Toyota and Ford. Practically every American car maker now offers
a cellular service or Wi-Fi network like General Motors' OnStar, Toyota's
Safety Connect and Ford's SYNC. Mobile-industry trade group the GSMA
estimates revenue from wireless devices in cars at $2.5 billion today and
projects that number will grow tenfold by 2025. Without better security it's
all potentially vulnerable, and automakers are remaining mum or downplaying
the issue.

As I drove their vehicles for more than an hour, Miller and Valasek showed
that they've reverse-engineered enough of the software of the Escape and the
Toyota Prius (both the 2010 model) to demonstrate a range of nasty
surprises: everything from annoyances like uncontrollably blasting the horn
to serious hazards like slamming on the Prius' brakes at high speeds. They
sent commands from their laptops that killed power steering, spoofed the GPS
and made pathological liars out of speedometers and odometers. Finally they
directed me out to a country road, where Valasek showed that he could
violently jerk the Prius' steering at any speed, threatening to send us into
a cornfield or a head-on collision. ``Imagine you're driving down a highway
at 80 ,'' Valasek says. ``You're going into the car next to you or into
oncoming traffic. That's going to be bad times.''

A Ford spokesman says the company takes hackers ``very seriously,'' but
Toyota, for its part, says it isn't impressed by Miller and Valasek's
stunts: Real car hacking, the company's safety manager John Hanson argues,
wouldn't require physically jacking into the target car. ``Our focus, and
that of the entire auto industry, is to prevent hacking from a remote
wireless device outside of the vehicle,'' he writes in an e-mail, adding
that Toyota engineers test its vehicles against wireless attacks. ``We
believe our systems are robust and secure. ...

Dewayne-Net RSS Feed: <http://www.warpspeed.com/wordpress>


Date: Thu, 25 Jul 2013 10:23:36 -0400
From: "Bob Frankston" <Bob19-0501 () bobf frankston com>
Subject: The risks of DNA "Certainty"

The seeming certainty of DNA evidence leads to false confidence in the
results and insufficient scrutiny. And, once again, we are at the risk of
bad math. A million in one match seems leave no doubt but if you have a
database with 10 million people you'll get ten matches. But when a jury is
just told that there is a one in a million chance of a mismatch then they
will have to convict.


Date: July 24, 2013 1:50:55 AM EDT
From: Lauren Weinstein <lauren () vortex com>
Subject: Cybersecurity hacking estimates exaggerated for profit

  "A $1 trillion estimate of the global cost of hacking cited by President
  Barack Obama and other top officials is a gross exaggeration, according to
  a new study commissioned by the company responsible for the earlier
  approximation.  A preliminary report being released Monday by the Center
  for Strategic and International Studies and underwritten by Intel Corp's
  (INTC.O) security software arm McAfee implicitly acknowledges that
  McAfee's previous figure could be triple the real number."
  http://j.mp/167eQG4  (Reuters via NNSquad)

As we've been saying all along. Follow the money!


Date: Thu, 25 Jul 2013 10:30:09 -0700
From: Gene Wirchenko <genew () telus net>
Subject: "Researchers spot new breed of infected Android apps in the wild"
  (Ted Samson)

Ted Samson, InfoWorld, 24 Jul 2013
Cyber criminals have successfully exploited a recently discovered
vulnerability to infect legit apps without invalidating their digital


Date: Tue, 23 Jul 2013 12:08:22 -0700
From: Gene Wirchenko <genew () telus net>
Subject: "SIM cards vulnerable to hacking, says researcher" (Jeremy Kirk)

Jeremy Kirk, InfoWorld, 22 Jul 2013
Millions of phones could be at risk due to the use of a 1970s-era
encryption standard


Date: Mon, 22 Jul 2013 07:56:21 -0700
From: Henry Baker <hbaker1 () pipeline com>
Subject: PIN-Punching Robot Cracks Phone's Security Code In 24 Hours

Andy Greenberg, *Forbes*, 22 Jul 2013
Covering the worlds of data security, privacy and hacker culture.

There's nothing particularly difficult about cracking a smartphone's
four-digit PIN code.  All it takes is a pair of thumbs and enough
persistence to try all 10,000 combinations. But hackers hoping to save time
and avoid arthritis now have a more efficient option: Let a cheap,
3D-printable robot take care of the manual labor.

At the Defcon hacker conference in Las Vegas early next month, security
researchers Justin Engler and Paul Vines plan to show off the R2B2, or
Robotic Reconfigurable Button Basher, a piece of hardware they built for
around $200 that can automatically punch PIN numbers at a rate of about one
four-digit guess per second, fast enough to crack a typical Android phone's
lock screen in 20 hours or less.

``There's nothing to stop someone from guessing all the possible PINs,''
says Engler, a security engineer at San Francisco-based security consultancy
iSec Partners. ``We often hear `no one would ever do that.' We wanted to
eliminate that argument. This was already easy, it had just never been done

Engler and Vines built their bot, shown briefly in the video above, from
three $10 servomotors, a plastic stylus, an open-source Arduino
microcontroller, a collection of plastic parts 3D-printed on their local
hackerspace's Makerbot 3D printer, and a five dollar webcam that watches the
phone's screen to detect if it's successfully guessed the password. The
device can be controlled via USB, connecting to a Mac or Windows PC that
runs a simple code-cracking program. The researchers plan to release both
the free software and the blueprints for their 3D-printable parts at the
time of their Defcon talk.

In addition to their finger-like R2B2, Engler and Vines are also working on
another version of their invention that will instead use electrodes attached
to a phone's touchscreen, simulating capacitative screen taps with faster
electrical signals. That bot, which they're calling the Capacitative
Cartesian Coordinate Brute-force Overlay, remains a work in progress, Engler
says, though he plans to have it ready for Defcon.

Not all PIN-protected devices are susceptible to the R2B2's brute force
attack, Engler admits. Apple's iOS, for instance, makes the user wait
increasing lengths of time after each incorrect PIN guess. After just a
handful of wrong answers, the phone can lock out a would-be hacker for hours
before granting access to the PIN pad again.

But every Android phone that Engler and Vines tested was set by default to
use a much less stringent safeguard, delaying the user just 30 seconds after
every five guesses. At that rate, the robot can still guess five PINs every
35 seconds, or all 10,000 possibilities in 19 hours and 24 minutes.

Given that the robot's software can be programmed to guess PINs in any order
the user chooses, it may be able to crack phones far faster than that 20
hour benchmark. One analysis of common PINs showed that more than 26% of
users choose one of twenty common PINs. If R2B2 is set to try easily-guessed
PINs first, it could crack one in four Android users' phones in less than
five minutes, and half of those phones in less than an hour.

Physically typing thousands of PIN codes, even with a clever robot's help,
isn't necessarily the easiest way to gain access to a phone's
data. Forensics software firm Micro Systemation released a video last year
-- since removed from YouTube -- showing that it can digitally brute-force
an iPhone's PIN by using the same ``jailbreak'' hacks that many iPhone
owners use to remove installation restrictions on their devices. Google has
been known to cooperate with law enforcement to bypass the lockscreens of
criminal suspects' phones, and Apple will in some cases crack a phone's
security and give the user's data to police if officers mail the phone to
the company.

But Engler argues that the R2B2 helps to raise attention to the insecurity
of crackable four-digit PINs in ways that software tools don't. Even a
six-digit PIN, an option on many phones, would take R2B2 as much as 80 days
longer to crack than the default four-digit passcode. ``When you see a robot
working like this, you think, `maybe I should have a longer PIN','' says
Engler. '' If I'm a CEO, a four digit PIN is a problem, because it's worth
20 hours to break in and get my confidential emails.''

Engler and Vines aren't the first to create an automated, physical
PIN-cracking tool. Another hacker who calls himself JJ showed off a similar
robot earlier in the year that could crack the four-digit PIN of a Garmin
Nuvi GPS device, shown in the video below.

But Engler's and Vine's invention is meant to be far more versatile.  In
addition to cracking phones' lockscreens, Engler says he and Vines plan to
keep improving the robot so that it can be adapted to crack the PIN codes
used in specific smartphone apps, or even to press the mechanical buttons on
non-touchscreen devices like ATMs, hotel safes and combination locks. And in
his daily work of auditing clients' security, breaking into a corporate
smartphone represents a far more serious threat than accessing the data of
any GPS device.

``We used to joke that we'd have to hire an intern to press all these
buttons,'' says Engler. ``It turns out it's much better to get the
intern to help make the robot. Then he also has time to get coffee.''

Andy Greenberg, Forbes Staff

I'm a technology, privacy, and information security reporter and most
recently the author of the book This Machine Kills Secrets, a chronicle of
the history and future of information leaks, from the Pentagon Papers to
WikiLeaks and beyond. I've covered the hacker beat for Forbes since 2007,
with frequent detours into digital miscellania like switches, servers,
supercomputers, search, e-books, online censorship, robots, and China. My
favorite stories are the ones where non-fiction resembles science
fiction. My favorite sources usually have the word "research" in their
titles. Since I joined Forbes, this job has taken me from an autonomous car
race in the California desert all the way to Beijing, where I wrote the
first English-language cover story on the Chinese search billionaire Robin
Li for Forbes Asia. Black hats, white hats, cyborgs, cyberspies, idiot
savants and even CEOs are welcome to email me at agreenberg (at) forbes.com.
My PGP public key can be found here.


Date: Wed, 24 Jul 2013 11:40:23 -0600
From: Jim Reisert AD1C <jjreisert () alum mit edu>
Subject: Citi Bike Accidentally Exposes Customer Credit Card Information
  (Ted Mann)

Ted Mann, *Wall Street Journal*, 23 Jul 2013

A Citi Bike software glitch accidentally exposed sensitive personal and
financial information -- including credit card numbers -- of more than 1,000
of its account holders, the bike sharing program's operators wrote in a
letter last week to the affected customers.

The data breach occurred on April 15, according to a letter sent to a Citi
Bike member reviewed by The Wall Street Journal. The letter was dated July

The security breach was discovered and corrected at the end of May.  It
affected 1,174 customers who signed up for $95 annual memberships to the
program, said Seth Solomonow, a spokesman for the city Department of
Transportation, which launched Citi Bike and controls all of the system's
communications to the public.

He did not explain the delay between the identification of the security flaw
and notification of affected users.


Tune into another Risks Digest issue to discover the next risk resulting
from the Citi Bikes in NYC!


Date: Mon, 22 Jul 2013 16:43:52 -0400 (EDT)
From: msb () vex net (Mark Brader)
Subject: Re: PayPal 'credits' US man $92 quadrillion in error (RISKS-27.37)

Bob Gezelter giveth and taketh away $91,908 trillion!

From: Amos Shapir <amos083 () gmail com>
The article claims the erroneous sum was $92,233,720,368,547,800...
(Being a computer nerd I had to check -- this number is almost exactly
2^63 * 0.01, so the credit was probably meant to be 1 cent).

In fact $2^63 * 0.01 is $92,233,720,368,547,758.08, so if the indicated
amount was not rounded, it is larger than that by $41.92.  It does seem
likely that PayPal is storing its monetary amounts in 64-bit words using
integers in cents, but I don't think the deduction that the intended
amount was 1 cent holds up.


Date: Tue, 23 Jul 2013 14:33:46 -0700
From: Bill Stewart <bill.stewart () pobox com>
Subject: Re: PayPal 'credits' US man $92 quadrillion in error (RISKS-27.37)

That's an advantage of 64-bit arithmetic; errors like this used to be ~$21M
or $2.1B.  Nobody's bank or financial institution would be able to handle a
US$92 trillion transfer, even if they didn't have good sanity checking, but
some might let $2B slip by accidentally, and almost any of them could afford
$21M and might not notice the error for a while.  And while most of them
probably couldn't handle the interest payments on a day's float of $92T, the
interest on $21M would probably have gotten paid.


Date: Wed, 24 Jul 2013 22:19:10 +0100
From: Chris Drewe <e767pmk () yahoo co uk>
Subject: Re: PayPal 'credits' US man $92 quadrillion in error (RISKS-27.37)

My question: we all had a good laugh, but could it have worked out like
this?  Suppose your bank erroneously deposits a large sum into your current
account.  The mistake is quickly spotted and corrected, so no harm done.
However, this unusual activity sets off the bank's automated
anti-money-laundering alerts.  Therefore, you suddenly have a bunch of
Government heavies on your doorstep, who want to know where that money came
from, and, more importantly, just where is it now?  A mistake by your bank,
you say..?  Better find yourself a good lawyer, quickly.


Date: Tue, 23 Jul 2013 23:57:36 +0200
From: Bertrand Meyer <Bertrand.Meyer () inf ethz ch>
Subject: Fool proofs? (Re: UBS fined $30,000 for a typing error, Kimmeringer)

In RISKS-27.37: "The system will now be changed to be fool-proved (again)."

Are you sure this phrasing is what is intended? To me a "fool-proved" system
is one in which the Coq/Isabelle/Spark verification was assigned to the team
member who perhaps wasn't the brightest in the lot. This might happen for
example to NAS if Martyn Thomas's suggestion in the same issue is followed.

There may be something very subtle here that eludes me, but if not I think
you mean fool-proof, or possibly fool-proofed. (Two occurrences in the

  [lothar agrees.  PGN]
    [A fool and his proofs are soon parted...  Lindsay Marshall]


Date: Tue, 23 Jul 2013 00:39:10 -0700
From: Rob Slade <rmslade () shaw ca>
Subject: Re: Government Destroys $170k of Hardware ... (RISKS-27.37)

Once upon a time, many years ago, a school refused to take my advice
(mediated through my brother) as to what to do about a very simple computer
virus infection.  The infection in question was Stoned, which was a boot
sector infector.  BSIs generally do not affect data, and (and this is the
important point) are not eliminated by deleting files on the computer, and
often not even by reformatting the hard disk.  (At the time there were at
least a dozen simple utilities for removing Stoned, most of them free.)

The school decided to cleanse it's entire computer network by boxing it up,
shipping it back to the store, and having the store reformat everything.
Which the store did.  The school lost it's entire database of student
records, and all databases for the library.  Everything had to be
re-entered.  By hand.

I've always thought this was the height of computer virus stupidity, and
that the days when anyone would be so foolish were long gone.

I was wrong.  On both counts.

Malware is my field, and so I often sound like a bit of a nut, pointing out
issues that most people consider minor.  However, malware, while now
recognized as a threat, is a field that extremely few people, even in the
information security field, study in any depth.  Most general security texts
(and, believe me, I know almost all of them) touch on it only tangentially,
and often provide advice that is long out of date.

With that sort of background, I can, unfortunately, see this sort of thing
happening again.

victoria.tc.ca/techrev/rms.htm http://www.infosecbc.org/links


Date: Wed, 24 Jul 2013 08:15:12 -0700
From: spl () ncmir ucsd edu (Steve Lamont)
Subject: Hardware destruction in perspective (Re: RISKS-27.37)

This is a story about government incompetence on the grossest, most
unforgivable scale. Here's how the Economic Development Administration
unnecessarily spent $2.75 million to fight a common case of malware.

While this is indeed a waste of time and money, a bit of perspective:

At current funding levels, $170,000 is approximately what the government
spends in 54 seconds in Afghanistan and Iraq.


The entire enterprise ($2.75 million) comes down to a bit under 15 minutes
of war.

According to my calculations, we're spending $3,125 a *second* for our two
wars and I'd be hard put to show how much economic development we've gotten
from either.   spl


Date: Mon, 22 Jul 2013 20:07:09 -0700
From: Gene Wirchenko <genew () telus net>
Subject: Re: "How the Pentagon's payroll quagmire traps soldiers (RISKS-27.37)

is a great article, but I suppose that it is ironic that Reuters has screwed
up in the implementation.  I got a message that I needed to have JavaScript
enabled to read the article.  The whole article was sent to my browser
though.  I went through the source, removed the <noscript></noscript> block,
saved the file locally, and then was able to read it.


Date: Mon, 22 Jul 2013 20:27:49 -0700
From: Gene Wirchenko <genew () telus net>
Subject: Re: "How to Build Versatile and Reusable Software" (RISKS-27.37)

Another amusing link:


I called it up, read the first page, then clicked for the second, and only
then noted the message on the page of "A browser or device that allows
javascript is required to view this content."  The second page loaded just


Date: Mon, 22 Jul 2013 12:27:57 -0700
From: Rob Slade <rmslade () shaw ca>
Subject: REVIEW: "Intelligent Internal Control and Risk Management", Leitch

BKIICARM.RVW   20121210

"Intelligent Internal Control and Risk Management", Matthew Leitch,
2008, 978-0-566-08799-8, U$144.95
%A   Matthew Leitch
%C   Gower House, Croft Rd, Aldershot, Hampshire, GU11 3HR, England
%D   2008
%G   978-0-566-08799-8 0-566-08799-5
%I   Gower Publishing Limited
%O   U$114.95 www.gowerpub.com
%O  http://www.amazon.com/exec/obidos/ASIN/0566087995/robsladesinterne
%O   http://www.amazon.ca/exec/obidos/ASIN/0566087995/robsladesin03-20
%O   Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   253 p.
%T   "Intelligent Internal Control and Risk Management"

The introduction indicates that this book is written from the risk
management perspective of the financial services industry, with a
concentration on Sarbanes-Oxley, COSO, and related frameworks.  There
is an implication that the emphasis is on designing new controls.

Part one, "The Bigger Picture," provides a history of risk management
and internal controls.  Chapter one asks how much improvement is
possible through additional controls.  The author's statement that
"[w]hen an auditor, especially an external auditor, recommends an
improvement control it is usually with little concern for the cost of
implementing or operating that control [or improved value].  The
auditor wants to feel `covered' by having recommended something in the
face of a risk that exists, at least in theory" is one that is
familiar to anyone in the security field.  Leitch goes on to note that
there is a disparity between providing real value and revenue
assurance, and the intent of this work is increasing the value of
business risk controls.  The benefits of trying quality management
techniques, as well as those of quantitative risk management, are
promoted in chapter two.  Chapter three appears to be a collection of
somewhat random thoughts on risk.  Psychological factors in assessing
risk, and the fact that controls have to be stark enough to make
people aware of upcoming dangers, are discussed in chapter four.

Part two turns to a large set of controls, and examines when to use, and not
to use, them.  Chapter five introduces the list, arrangement, and structure.
Controls that generate other controls (frequently management processes) are
reviewed in chapter six.  For each control there is a title, example,
statement of need, opening thesis, discussion, closing recommendation, and
summary relating to other controls.  Most are one to three pages in length.
Audit and monitoring controls are dealt with in chapter seven.  Adaptation
is the topic of chapter eight.  (There is a longer lead-in discussion to
these controls, since, inherently, they deal with change, to which people,
business, and control processes are highly resistant.)  Chapter nine notes
issues of protection and reliability.  The corrective controls in chapter
ten are conceptually related to those in chapter seven.

Part three looks at change for improvement, rather than just for the
sake of change.  Chapter eleven suggests means of promoting good
behaviours.  A Risk and Uncertainty Management Assessment (RUMA) tool
is presented in chapter twelve, but, frankly, I can't see that it goes
beyond thinking out alternative courses of action.  Barriers to
improvement are noted in chapter thirteen.  Roles in the organization,
and their relation to risk management, are outlined in chapter
fourteen.  Chapter fifteen examines the special needs for innovative
projects.  Ways to address restrictive ideology are mentioned in
chapter sixteen.  Seven areas that Leitch advises should be explored
conclude the book in chapter seventeen.

A number of interesting ideas are presented for consideration in
regard to the choice and design of controls.  However, the text is not
a guidebook for producing actual control systems.

copyright, Robert M. Slade   2013   BKIICARM.RVW   20121210
rslade () vcn bc ca     slade () victoria tc ca     rslade () computercrime org
victoria.tc.ca/techrev/rms.htm http://www.infosecbc.org/links


Date: Sun, 7 Oct 2012 20:20:16 -0900
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
 comp.risks, the feed for which is donated by panix.com as of June 2011.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.  The mailman Web interface can
 be used directly to subscribe and unsubscribe:
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
   risks-request () csl sri com
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe () csl sri com or risks-unsubscribe () csl sri com
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users may contact <Lindsay.Marshall () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line.
 *** NOTE: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 http://www.risks.org takes you to Lindsay Marshall's searchable archive at
 newcastle: http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 <http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    <http://www.csl.sri.com/illustrative.html> for browsing,
    <http://www.csl.sri.com/illustrative.pdf> or .ps for printing
  is no longer maintained up-to-date except for recent election problems.
 *** NOTE: If a cited URL fails, we do not try to update them.  Try
  browsing on the keywords in the subject line or cited article leads.
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:


End of RISKS-FORUM Digest 27.38

  By Date           By Thread  

Current thread:
  • Risks Digest 27.38 RISKS List Owner (Jul 26)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]