[RISKS] Risks Digest 25.91

From: RISKS List Owner <risko_at_private>
Date: Tue, 19 Jan 2010 15:54:26 PST
RISKS-LIST: Risks-Forum Digest  Tuesday 19 January 2010  Volume 25 : Issue 91

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
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
  <http://catless.ncl.ac.uk/Risks/25.91.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
New Massachusetts unemployment insurance employer website crashes and burns
  upon launch (Jonathan Kamens)
Moscow grinds to a halt: spoofed traffic signs? (PGN)
Despite Risks, Internet Creeps Onto Car Dashboards (Matthew Kruk)
Software Firms Fear Hackers Who Leave No Trace (Markoff/Vance via PGN)
"--b" parsed as a double-negation (jidanni)
Network flaw connects Facebook users to wrong accounts (Steven J Klein)
Fraudulent Facebook group leads to malware scam (Matthew Kruk)
A5/3 attack (Alexander Klimov)
S&P loses 8.5% (Daniel P.B. Smith)
Dangerously wrong trailer weight in Web tool (Rex Sanders)
Australian man dies after being crushed by computers (Darryl Smith)
Update Your XYZZY Web Site Password (Dale E. Coy)
Offensive shutting down of botnets (Kelly Jackson Higgins via PGN)
Y2K+10 problem 1910 in BPCS 8.1 ERP (Al MacIntyre)
Y2K+10: Windows Mobile has 2010 problems too (Jeremy Epstein)
Y2K? Taiwan, N. Korea calendars facing Y1C in 2011! (jidanni)
Re: Couple Stuck in Oregon Snow for 3 Days After GPS Leads
 Them Astray (Al Stangenberger)
Other Traffic Risks (Gene Wirchenko)
REVIEW: "Into the Breach", Michael J. Santarcangelo (Rob Slade)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 14 Jan 2010 21:52:41 -0500
From: Jonathan Kamens <jik_at_private>
Subject: New Massachusetts unemployment insurance employer website
 crashes and burns upon launch

The Commonwealth of Massachusetts has a convoluted(*) unemployment insurance
system, under which employers are required to make various quarterly and
annual filings and quarterly payments involving at least two different state
agencies.

This system is administered by the Department of Unemployment Assistance
(DUA), who decided to replace their old, paper-based system with a Web-based
system called QUEST ("Quality Unemployment System Transformation").  The DUA
promised QUEST would bring countless improvements: one-stop shopping,
filings for all agencies in one place, faster filings, less wasted paper,
reduced printing and postage costs, reduced data entry costs, no more data
transcription errors, etc., etc.  You've no doubt heard it all before.

QUEST went live at the beginning of 2010.  As of the go-live date, the usage
of QUEST for all employer unemployment insurance transactions was mandatory;
paper filings were no longer permitted.  I.e., the DUA went straight from
paper filings only to on-line filings only, with no transition period or
overlap.(**)

It would be an understatement to say that QUEST is having some problems.  It
would probably be more accurate to say that it is a disaster.  Some examples
of the issues I've experienced trying to use the new system today to do my
filing for the last quarter of 2009:

 * I received an e-mail message informing me that there was correspondence
   in my QUEST inbox, and I should log into QUEST to read it.  When I log
   into QUEST and click on the link for the correspondence in question, I
   get a .NET error page.

 * When I attempted to enter my quarterly filing numbers, I was asked
   to fill in the fields "UI gross wages", "UI taxable wages", and
      "UHI taxable wages", with no explanation on the form or anywhere
      else on the site of what these terms mean or how to determine the
      correct amounts.  A DUA employee with whom I spoke today informed
      me that those words were supposed to be links that I could click
      on for definitions, but for some reason the links were missing
      from the page.

 * The two DUA employees with whom I spoke today both said that the
      new system is having innumerable problems across the board.

 * The first phone number I called today in an attempt to get help
      with QUEST was so swamped that I was not even given the option of
      waiting on hold -- a recording told me they were too busy to help
      me and I should call back later, and then I was disconnected.

 * A little while ago I tried to click on the QUEST login link on the
      DUA Web page and instead reached a DUA Web site error page
      indicating that the page I was trying to access had moved or was
      temporarily unavailable, or some such thing.

  * Some time after that, I tried again, and this time I actually got
    into the QUEST application, at which point I was greeted with a
      different error: "Error: You have reached the Commonwealth of
      Massachusetts Department of Unemployment Assistance. The Quest
      Unemployment System is temporarily unavailable due to scheduled
      maintenance in order to better serve you. Please try your request
      again later. We appreciate your understanding."  Given everything
      else that's going on, it seems highly unlikely to me that it is
      any way accurate to claim that this outage was "scheduled".

 * Earlier today, a new message showed up on the DUA Web site: *Additional
 Time for 4th Quarter Filing and Account Activation* Two-week grace period
 for filing 4th Quarter Employment and Wage Detail Report. New deadline:
 *February 16, 2010*. Penalties apply after deadline. ...  Although the
 January 8th deadline has passed, you can still activate your account
 without a late penalty. Please activate your account as soon as possible to
 avoid the expected high volume of calls and Web traffic near the filing
 deadline.

More.
http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf

As is typical in government bureaucracies facing epic disasters, there has
been no public disclosure of the fact that there is a problem, or of what is
being done to fix it, or of the ETA for when it will be fixed.  It remains
to be seen whether anything will be disclosed later, or whether any heads
will roll at the DUA in recognition of this monumental cock-up.

1. Perhaps the system does not seem so convoluted to businesses, but it does
to me, a "household employer" who is required to participate in it only
because I've made the seemingly naive decision of attempting to abide by the
law while employing a babysitter for six hours per week.

2. At least, requiring QUEST filing as of 1/1/2010 seems to have been their
original plan.  However, a letter sent to employers January 14 encourages
the use QUEST for filing 4Q2009 reports, which would seem to imply that not
using QUEST is in fact an option.  If so, it's a difficult option to
exercise, since all instructions and forms for filing on paper appear to
have been removed from website, or at least cunningly hidden.
<http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf>

------------------------------

Date: Tue, 19 Jan 2010 13:45:06 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: Moscow grinds to a halt: spoofed traffic signs?

The long URL tells the story nicely.  Two downtown billboard video screens
caused traffic to "jerk.. to a standstill" for 20 minutes, until Panno.ru
removed the content.  They claim it was the result of either "hooligan
hackers" or "advertising competitors".  [Thanks to Herb Lin and Steve
Bellovin for this one.  PGN]

http://www.switched.com/2010/01/16/russian-commuters-treated-to-free-roadside-pornography/

Steve Bellovin has noted various sign-hacking events.
  http://www.foxnews.com/story/0,2933,484326,00.html  (see RISKS-25.53)
  http://www.i-hacked.com/content/view/274/48/  (ADDCO)
  http://www.nytimes.com/2006/05/08/business/media/08sign.html
    ("Stephen Harper Eats Babies")
and a very amusing official posted sign ("Do not take any risks.")
  http://www.woostercollective.com/2009/06/culture_jamming_on_the_london_tube.html
RISKS has noted other cases of spoofed signs in the past, notably dating
back to the 1984 Rose Bowl scoreboard (Caltech vs MIT).  PGN]

------------------------------

Date: Sat, 9 Jan 2010 16:58:33 -0700
From: "Matthew Kruk" <mkrukg_at_private>
Subject: Despite Risks, Internet Creeps Onto Car Dashboards

As if we didn't have enough bad drivers out there ...

To the dismay of safety advocates already worried about driver distraction,
automakers and high-tech companies have found a new place to put
sophisticated Internet-connected computers: the front seat.  [Source: Ashlee
Vance and Matt Richtel, *The New York Times*, 7 Jan 2010.]
  http://www.nytimes.com/2010/01/07/technology/07distracted.html

------------------------------

Date: Tue, 19 Jan 2010 13:48:18 PST
From: "Peter G. Neumann" <neumann_at_private>
Subject: Software Firms Fear Hackers Who Leave No Trace

The title of this article gives you a strong clue as to its content.  The
Web page includes many readers' comments, so I won't try to capture the
entire discussion -- which should be very familiar to RISKS readers.

  John Markoff and Ashlee Vance, Fearing Hackers Who Leave No Trace,
  *The New York Times*, dated 19 Jan 2010
  http://www.nytimes.com/2010/01/20/technology/20code.html

------------------------------

Date: Tue, 12 Jan 2010 10:22:51 +0800
From: jidanni_at_private
Subject: "--b" parsed as a double-negation

POSIX says support for ++ and -- is "not required", but doesn't say how to
deal with ++b and --b when they aren't supported.

So we end up with
$ bash -c 'b=5; echo $((--b)); echo $((--b))'
4
3
$ dash -c 'b=5; echo $((--b)); echo $((--b))'
5
5
--b is being parsed here as a double-negation!
http://bugs.debian.org/508602

------------------------------

Date: Sun, 17 Jan 2010 13:30:02 -0500
From: Steven J Klein <steven_at_private>
Subject: Network flaw connects Facebook users to wrong accounts

Source: http://www.washingtontimes.com/news/2010/jan/16/network-flaw-causes-scary-web-error/
2010 Network flaw causes scary Web error

A woman in Georgia using a Nokia phone connected to facebook.com, and found
herself logged in to a stranger's account, without ever having been prompted
to log in.  She asked her mother & sister, both with the same model phone to
try it, and both also ended up in the accounts of other unknown parties.
They sent an e-mail from Facebook as evidence that what they described
really happened.

I want to emphasize that the error isn't specifically a Facebook problem,
but an AT&T network issue. Facebook could fix the problem by using a secure
connection.

Excerpt:

  The glitch -- the result of a routing problem at the family's wireless
  carrier, AT&T -- revealed a little known security flaw...  In each case,
  the Internet lost track of who was who, putting the women into the wrong
  accounts...  It's not clear whether such episodes are rare or simply not
  reported...  The women, who live together in East Point, Ga., outside
  Atlanta, had recently upgraded to the same model of phone and all used the
  same carrier, AT&T...  AT&T spokesman Michael Coe said its wireless
  customers have landed in the wrong Facebook pages in "a limited number of
  instances" and that a network problem behind those episodes is being
  fixed.

This is, of course, a serious problem.  But it's not clear to me that
there's any way for bad guys to intentionally exploit it.

Steven J Klein, A+ and Apple Certified, Your Mac & PC Expert (248) YOUR-MAC

------------------------------

Date: Sat, 9 Jan 2010 23:42:15 -0700
From: "Matthew Kruk" <mkrukg_at_private>
Subject: Fraudulent Facebook group leads to malware scam

If you happen to be on Facebook today and spot a group that is called,
"WE'RE AGAINST THE 4.99 A MONTH CHARGE FOR FACEBOOK FROM JUNE 30TH 2010,? be
sure to keep away from it. If you don't - instead of finding a friendly
group of people that are there to discuss ideas or similar interests, a user
could potentially end up with loads of malware garbage on their computer.

http://www.geek.com/articles/news/fraudulent-facebook-group-leads-to-malware-scam-20091229/

------------------------------

Date: Tue, 12 Jan 2010 12:46:25 +0200
From: Alexander Klimov <alserkli_at_private>
Subject: A5/3 attack

As you may already know, GSM phone conversations are encrypted with the 20+
years old A5/1 and A5/2 stream ciphers. The ciphers were repeatedly shown to
be weak, but in absence of a publicly available decryption tools the GSM
Association was able to claim that the attacks are not practical. Last
December the completion of tables needed for breaking A5/1 was announced and
now the GSM Association intends to speed up the transition to A5/3.

This A5/3 block cipher is KASUMI, which is a modified version of the MISTY
cryptosystem. Recently (2010-01-10) it was publicly shown that it is
possible to derive the complete 128-bit key of the full KASUMI by using only
4 related keys, 2^26 data, 2^30 bytes of memory, and 2^32 time (two hours on
a single PC).  <http://eprint.iacr.org/2010/013.pdf>

Authors of the attack note:
  neither our technique nor any other published attack can break MISTY in
  less than the 2^128 complexity of exhaustive search, which indicates that
  the changes made by the GSM Association in moving from MISTY to KASUMI
  resulted in a much weaker cryptosystem.

Never attribute to malice that which can be adequately explained by stupidity.

------------------------------

Date: Tue, 12 Jan 2010 09:13:04 -0500
From: "Daniel P.B. Smith" <usenet2006_at_private>
Subject: S&P loses 8.5%

As noted in the Bogleheads investing forum, the S&P 500 index plummeted 97.7
points or 8.53% in the last instant of trading on Monday, January 11th,
2010... as shown by Google Finance and other online charts.

An actual 8.53% drop would of course have generated screaming headlines, but
perfunctory Googling suggests that this glitch has escaped the notice of the
financial press.

The obvious RISK is that an investor might take action on erroneously
reported information, especially when that information could be "confirmed"
by more than one source. This particular glitch is obvious enough to make
such a thing unlikely, but it does place into question the reliability of
our financial reporting channels.

Why does such a thing ever happen? How difficult is it to calculate the
average of 500 numbers... and to omit reporting the result if any of them
are missing?

Here is a screenshot of the glitch as shown by Google Finance. The glitch
was not limited to Google, however.

http://img31.imageshack.us/img31/6914/sp8.png

The arrow points to the plummet. The chart displays a dynamic readout when
you point to places on the curve, and the circled number is the readout for
the right end of the curve. Fortunately, all of the summary numbers are
displayed correctly, showing that it was a gratifyingly dull day.

Bogleheads discussion:

Bogleheads link: http://www.bogleheads.org/forum/viewtopic.php?t=48592&mrr=1263297139

------------------------------

Date: Tue, 12 Jan 2010 17:22:21 -0800
From: Rex Sanders <rsanders_at_private>
Subject: Dangerously wrong trailer weight in Web tool

A good friend wanted to rent a trailer to haul heavy stuff about 1,000
miles.  The website of a reputable company had a tool for matching vehicle
towing capacity, trailer weights, and trailer cargo capacity.  He found a
trailer that just met all his requirements, and reserved the trailer online.

Except it seemed a little too good to be true.  A couple days before
leaving, he dug deeper on that company's website.  Under the specifications
for that trailer, he found the trailer weight listed at 1,000 pounds higher!

He called customer service.  The first agent tried to convince him through
some dubious logic that the extra weight would not be a problem.

He called again to get a second agent, who confirmed an error in the Web
tool, and promised to get it fixed.  My friend rented a truck instead.

If he had trusted the Web tool, or the first agent, he could have suffered a
serious crash through overloading.

Lessons: A trailer rental database error could have killed people.  And some
customer service agents are more trustworthy than others.

------------------------------

Date: Tue, 12 Jan 2010 22:15:20 +1100
From: "Darryl Smith" <Darryl_at_radio-active.net.au>
Subject: Australian man dies after being crushed by computers

An Australian man has died after computer equipment fell on him as it was
being unloaded from a truck according to a local paper...  "It appears the
man was helping others unload a large computer server from the back of a
truck,'' ambulance clinical support officer Mark Lamb said.
http://www.news.com.au/breaking-news/man-dies-after-being-crushed-by-compute
rs-in-melbourne/story-e6frfku0-1225818578320

Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
www.radio-active.net.au/blog/ - www.radio-active.net.au/web/tracking/

------------------------------

Date: Sat, 16 Jan 2010 11:53:11 -0600
From: "Dale E. Coy" <dale_at_private>
Subject: Update Your XYZZY Web Site Password

For many years I've been a member of an organization that has a website that
has negligible risk, but requires a login for some purposes.  The
organization (let's call it XYZZY) has always used the members' surname as a
password.  On January 16th, I received the following e-mail (slightly altered
to obscure the organization [and the sender!  PGN]).

  Dear Mr. Coy,

  Due to website maintenance, the "member/guest only" sections of the XYZZY
  website will not be available until after Jan. 26. As part of this
  maintenance, we are increasing security measures. Passwords now must be at
  least five characters in length. Your current password does not meet this
  security requirement and you will be unable to log in. Please call XYZZY's
  Member Service Center at (800) 555-1212 from 8 a.m. to 6 p.m. EST or
  e-mail webmaster_at_private to update your password. We apologize for this
  inconvenience.

  I. Mostly Clueless, Deputy Director/Web Manager

Of course, I've sent e-mail requesting that they change my password.  I'm
anticipating that they will send my new password by email.

  [PGN says, not so Coyly, you should request a password of "Coyote" as in
  "Don Coyote", Or you could change your name.  That would certainly
  increase your security!  But they will probably change your NAME and
  PASSWORD for you.  I remember the 1108 operating system password, which
  was also the same as your user name.  If you attempted to change your
  password, as I recall it would tell you that your desired password change
  was already in use if it belonged to another user.  Now that's what we
  mean by REAL security!]

------------------------------

Date: Tue, 12 Jan 2010 9:37:02 -0800
From: Peter G Neumann <neumann_at_private>
Subject: Offensive shutting down of botnets

http://www.darkreading.com/insiderthreat/security/vulnerabilities/showArticle.jhtml?articleID=222300408

Kelly Jackson Higgins, DarkReading, 11 Jan 2010

Yet another botnet has been shut down as of today as researchers joined
forces with ISPs to cut communications to the prolific Lethic spamming
botnet -- a development that illustrates how botnet hunters increasingly are
going on the offensive to stop cybercriminals, mainly by disrupting their
valuable bot infrastructures.

For the most part researchers monitor and study botnets with honeypots and
other more passive methods. Then security vendors come up with malware
signatures to help their customers scan for these threats. But some
researchers are turning up the heat on the bad guys' botnet infrastructures
by taking the lead in killing some botnets: Aside from last weekend's
takedown by Neustar of Lethic, which is responsible for about 10 percent of
all spam, FireEye last November helped shut down the MegaD botnet. And
researchers at the University of California at Santa Barbara in May revealed
they had taken the offensive strategy one step further by infiltrating the
Torpig botnet, a bold and controversial move that stirred debate about just
how far researchers should go to disrupt a botnet.

Back in 2008 after two major ISPs halted traffic to malicious hosting
provider McColo, spam worldwide dropped around 70 percent because McColo had
been the main home to most botnet command and control (C&C) servers.

But deploying more offensive tactics to stop botnets and bad guys is not so
straightforward: Researchers walk a fine line as to how far they can go
legally and ethically, and sometimes taking down a botnet actually
backfires, either with the bad guys returning the favor with a
denial-of-service (DoS) attack, or learning how to better evade
investigators next time. There's the danger that getting inside a botnet
will just give its operators more tools and insight into how to strengthen
their operations; botnet operators are notorious for reinventing themselves
with stealthier botnets and new forms of malware.  [...]

------------------------------

Date: Fri, 8 Jan 2010 20:51:20 -0600
From: Al MacIntyre <macwheel99_at_private>
Subject: Y2K+10 problem 1910 in BPCS 8.1 ERP

http://archive.midrange.com/bpcs-l/201001/msg00012.html

BPCS-L discussion group has found out about a Y2K+10 problem in Business
Planning and Control System (BPCS) version 8.1.00 where Trusted Link
Enterprise (TLE) version 3.2.01 substitutes 1910 for 2010 in Electronic Data
Interchange (EDI). The vendor (Infor) knows about it, and is working on a
fix.

------------------------------

Date: Thu, 14 Jan 2010 13:49:34 -0500
From: Jeremy Epstein <jeremy.j.epstein_at_private>
Subject: Y2K+10: Windows Mobile has 2010 problems too

Should be no surprise, given RISKS 25.89 and 25.90, but.... according
to Cnet, there's reports of a glitch on Windows Mobile that some
devices are putting the wrong date on incoming SMS messages - using
2016 rather than 2010.  Microsoft has acknowledged the problem, but I
haven't seen any reports of fixes.

Source: http://news.cnet.com/8301-13860_3-10425455-56.html

------------------------------

Date: Sun, 10 Jan 2010 05:47:49 +0800
From: jidanni_at_private
Subject: Y2K? Taiwan, N. Korea calendars facing Y1C in 2011!

"This [everything-begins-again-with-us] dating system -- which reflects the
habits of the imperial dynasties, isn't just a quaint local custom, its
continued use is heading Taiwan toward its very own type of Y2K problem on
2011/1/1, when Taiwan's calendar reaches the age of 100 and has to jump to
three-digit years, Taiwan will likely experience what I like to call the Y1C
problem. (Yes, I know: I'm mixing systems in that C represents hundred in a
system that uses M, not K, for 'thousand.' But that's the best I could come
up with. I'm open to suggestions for catchy but correct names.)" North Korea
too, the very same day.

http://pcofftherails101.blogspot.com/2010/01/is-there-y1c-computer-glitch-in-taiwans.html
http://pinyin.info/news/2006/taiwans-y1c-problem
http://en.wikipedia.org/wiki/Y1C_Problem
http://en.wikipedia.org/wiki/Minguo_calendar
http://en.wikipedia.org/wiki/Juche#Calendar

------------------------------

Date: Fri, 08 Jan 2010 11:48:39 -0800
From: Al Stangenberger <forags_at_private>
Subject: Re: Couple Stuck in Oregon Snow for 3 Days After GPS Leads
 Them Astray (Grady: Risks 25:89)

Part of this problem can be caused by poor-quality data in the underlying
map database used by the GPS.

I found a similar error while reviewing a web page which has a link to
Google Maps to give directions from Berkeley to the University of
California's forestry camp in Plumas County.  The printed map directed users
to take a Forest Service road as the shortest route; the road is dirt and
not suitable for passenger cars.  I contacted Tele Atlas (the firm which
supplies the basic road data used by Google Maps), and found that they did
not know that the road was dirt.  They have updated the database, which
fixed the problem.

But all of these incidents (remember the Stolpa family in 1993?) just point
out that all the technology and maps in the world are no substitute for
common sense...

------------------------------

Date: Fri, 08 Jan 2010 21:23:34 -0800
From: Gene Wirchenko <genew_at_private>
Subject: Other Traffic Risks

While these traffic risks are not computer-related, they do help point out
how hard it can be to get it right.  So how difficult is it to construct a
good road sign?

1) Snow can stick to signs.  I recall driving near Penticton, British
Columbia, Canada one night and being very thankful that I knew the road.
The highway has some switchbacks as it descends into the Okanagan Valley
from Keremeos.  The turns are signed.  They are very visible three seasons
of the year.  In snow, the signs can be barely visible and not readable at
all.  *I* knew to slow down.  What about someone else?

Heated signs anyone?

2) In the same area and in others, it can be very windy.  I have seen signs
mounted so that they turn in the wind.  I would not have thought that
necessary.

I wonder if anyone has been injured by a sign that broke loose in the wind.

------------------------------

Date: Mon, 11 Jan 2010 11:45:04 -0800
From: Rob Slade <rmslade_at_private>
Subject: REVIEW: "Into the Breach", Michael J. Santarcangelo

BKINTBRE.RVW   20091012

"Into the Breach", Michael J. Santarcangelo, 2008, 978-0-9816363-0-6
%A   Michael J. Santarcangelo michael_at_private
%C   New York, USA
%D   2008
%G   978-0-9816363-0-6 0-9816363-0-6
%I   Catalyst Media
%O   www.intothebreach.com
%O  http://www.amazon.com/exec/obidos/ASIN/0981636306/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0981636306/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0981636306/robsladesin03-20
%O   Audience i+ Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   110 p.
%T   "Into the Breach"

The introduction states that security (which seems to be limited to
disclosure or breaches) is a "people" problem, and therefore requires social
solutions.  This addresses a common problem: security professionals, and
even non-technical managers, concentrate on breaches in systems and thus
miss the real heart of the matter: people.

Although not overtly stated, part one seems to be related to the first stage
in the Strategy to Protect Information, understanding information.  Chapter
one repeats the position that breaches are a human problem.  Security
awareness is promoted in chapter two.  In chapter three an analogy is drawn
between faddish security and crash dieting, noting that neither works.
Chapter four addresses risk management.

Part two suggests managing people.  Chapter five outlines the aforementioned
Strategy to Protect Information: understand your information assets, manage
and communicate with your people, and optimize your processes and systems.
Implementing this strategy is seen, in chapter six, as a five step process:
learn the jobs, gather information, prioritize, plan, and communicate.
Steps seem to be missing, such as dividing your data or systems into
elements for the process.  Guidance for planning is limited.  Chapter seven
suggests making a trial run with a pilot project, which is a good idea.
Measurement of the success of the project is discussed in chapter eight.

Part three deals with improvement.  Chapter nine notes that the strategy
benefits overall management, which is unsurprising, since it is basically a
general management process.  Costs of compliance with regulations or
standards are also partially covered, as is mentioned in chapter ten, since
a significant portion of the initial cost of compliance relies on the type
of research and analysis demanded by the strategy.  (However, a great deal
of the content simply emphasizes the importance of compliance.)  The advice
about outsourcing, in chapter eleven, seems to be to audit the vendor.
Chapter twelve closes off the book with an exhortation to act.

Although generic, the strategy proposed is sound and likely useful.  This
slim volume would help a significant number of managers and security
practitioners who are caught up in the latest security fad or device, to the
detriment of actual business (and personnel) needs.

copyright Robert M. Slade, 2009    BKINTBRE.RVW   20091012
rslade_at_private     slade_at_private     rslade_at_private
victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html
http://blogs.securiteam.com/index.php/archives/author/p1/
http://twitter.com/NoticeBored http://twitter.com/rslade

------------------------------

Date: Thu, 29 May 2008 07:53:46 -0900
From: RISKS-request_at_private
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> 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:
   http://lists.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman
 your FROM: address, send a message to
   risks-request_at_private
 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_at_private or risks-unsubscribe_at_private
 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.
   <http://www.CSL.sri.com/risksinfo.html>
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall_at_private>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks_at_private 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> redirects you to Lindsay Marshall's Newcastle archive
 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
==> Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

------------------------------

End of RISKS-FORUM Digest 25.91
************************
Received on Tue Jan 19 2010 - 15:54:26 PST

This archive was generated by hypermail 2.2.0 : Tue Jan 19 2010 - 16:49:55 PST