RISKS Forum mailing list archives

Risks Digest 28.63


From: RISKS List Owner <risko () csl sri com>
Date: Mon, 11 May 2015 16:04:57 PDT

RISKS-LIST: Risks-Forum Digest  Monday 11 May 2015  Volume 28 : Issue 63

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/28.63.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
Ed Felten joining WH OSTP (Richard Forno)
Real-time emotion tracking by webcam (Nick Brown)
Flawed encryption leaves millions of smart grid devices at risk of
  cyberattacks (ZDNet via Bob Frankston)
Gustavo Duarte Blog Recommendation: "Brain Food for Hackers"
  (Lauren Weinstein)
HTTPS: the end of an era (Medium via Lauren Weinstein)
Another reason why any moves toward forced https: are so potentially
  dangerous (Google via NNSquad)
Re: Authentication vs Identification ... (David Brodbeck)
Re: Doctors don't like EHRs (Richard I Cook, Alister Wm Macintyre)
Re: All cars must have tracking devices ... (Wols, John Levine)
REVIEW: "Security for Service Oriented Architectures", Walter Williams
  (Rob Slade)
Abridged info on RISKS (comp.risks)

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

Date: May 11, 2015 5:22 PM
From: "Richard Forno" <rforno () infowarrior org>
Subject: Ed Felten joining WH OSTP (via Dave Farber)

Andrea Peterson, *The Washington Post*, 11 May 2015
http://www.washingtonpost.com/blogs/the-switch/wp/2015/05/11/the-white-house-just-snagged-one-of-the-most-valuable-players-in-the-tech-policy-world/?postshare=2921431378673360

The White House is adding one of the tech policy world's most valuable
players to it's roster: Princeton Professor Ed Felten. The White House
announced today that Felten will join the Office of Science and Technology
Policy as deputy U.S. chief technology officer.

In his decades-long career, Felten has carved out a role as one of the
world's top thinkers on computer security and privacy -- tackling
technically difficult topics and translating them for Washington insiders.
"There is no one more valuable to bridging tech and policy than Ed," said
Joseph Lorenzo Hall, the chief technologist at the Center for Democracy &
Technologist, who worked with Felten as a post-doctoral fellow at Princeton.

He's also slipped seamlessly between academia and civil service: Felten has
been a professor at Princeton for more than two decades, and currently
serves as the founding director of the school's Center for Information
Technology Policy. But from 2011 through 2012 he served as the first chief
technologist at the Federal Trade Commission -- the government's de facto
privacy watchdog.

Felten's also weighed in on government surveillance efforts: In the wake of
revelations about National Security Agency surveillance programs from former
government contractor Edward Snowden, Felten publicly argued that phone
record data being vacuumed up by the government could reveal extremely
sensitive personal information. In fact, he made that point in a brief
supporting the plaintiffs in a lawsuit that resulted in a federal appellate
court decision last week that found the phone records program is illegal.

"Ed joins a growing number of techies at the White House working to further
President Obama's vision to ensure policy decisions are informed by our best
understanding of state-of-the-art technology and innovation, to quickly and
efficiently deliver great services for the American people, and to broaden
and deepen the American people's engagement with their government,"
Alexander Macgillivray, deputy chief technology officer, and Megan Smith,
U.S. chief technology officer, said in a blog post today.

Both Macgillivray and Smith come from big tech companies -- Macgillivray is
a former general counsel at Twitter while Smith was a vice president at
Google. That makes Felten's academic background unique among the current
class of the nation's top tech civil servants.

  [See also
https://www.whitehouse.gov/blog/2015/05/11/white-house-names-dr-ed-felten-deputy-us-chief-technology-officer
  PGN]

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

Date: Sun, 10 May 2015 01:07:53 +0200 (CEST)
From: nick.brown () free fr
Subject: Real-time emotion tracking by webcam

The European Commission is giving financial backing to a company that claims
its technology can read your emotional state by just having you look into a
webcam.

Highlights:

"Realeyes is a London based start-up company that tracks people's facial
reactions through webcams and smartphones in order to analyse their
emotions. ...  Realeyes has just received a 3,6 million euro funding from
the European Commission to further develop emotion measurement
technology. ...  The technology is based on six basic emotional states that,
according to the research of Dr Paul Ekman, a research psychologist, are
universal across cultures, ages and geographic locations. ...

[T]his technological development could be a very powerful tool not only for
advertising agencies, but as well for improving classroom learning,
increasing drivers' safety, or to be used as a type of lie detector test by
the police."

More at https://edri.org/emotion-tracking-company-gets-funding-from-ec/

The risks are left as an exercise for the reader. I suspect that most people
will have little difficulty in coming up with a few dozen, perhaps split
into two categories: if the technology works, and if it doesn't work, the
boundary between the two being some more-or-less arbitrary false-positive
rate. The impossibility of falsifying the machine's verdict is top of my
list.

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

Date: Mon, 11 May 2015 02:27:45 -0400
From: "Bob Frankston" <bob19-0501 () bobf frankston com>
Subject: Flawed encryption leaves millions of smart grid devices at risk of
  cyberattacks (ZDNet)

http://www.zdnet.com/article/smart-grid-group-rolls-out-its-own-flawed-crypto-risking-device-security/

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

Date: Sat, 9 May 2015 13:38:39 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Gustavo Duarte Blog Recommendation: "Brain Food for Hackers"

Earlier today I literally stumbled into a site unfamiliar to me, the blog of
Gustavo Duarte called "Brain Food for Hackers."

Contrary to what you might expect from the name, it is not a guide to
hacking, but (among other things) a series of extremely clear, lucid, and
accessible articles -- most with great graphics -- explaining how modern PCs
and OSes work in various respects -- CPU, system calls, page caches,
recursion, and so on. While most of his examples are for UNIX/Linux, he also
takes care to explain the relationship of these principles to Windows and
other systems.

His blog is only relatively infrequently updated -- the last update is from
late last year. But if you've ever wondered how this stuff works -- and you
really should! -- you might want to check out his blog archive at:

http://duartes.org/gustavo/blog/archives/

Great work, Gustavo!

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

Date: Sun, 10 May 2015 12:26:08 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: HTTPS: the end of an era

Medium via NNSquad
https://medium.com/@b_k/https-the-end-of-an-era-c106acded474

  Mozilla, the foundation that maintains Firefox, has announced that it will
  effectively deprecate the insecure HTTP protocol, eventually forcing all
  sites to use HTTPS if they hope to use modern features.  This essay
  explains why this was such depressing news to me, why this shift marks the
  death of a way of life ... An HTTPS site can not be built on a desert
  island network, because you need a signature from a certificate
  authority. A dissident is screwed, because the dissident must give
  identifying information to the certificate authority.  -- Ben Klemens

More on this theme: "When Mozilla's Fanatics Make Us All Look Bad":
http://lauren.vortex.com/archive/001099.html

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

Date: Sun, 10 May 2015 19:27:32 -0700
From: Lauren Weinstein <lauren () vortex com>
Subject: Another reason why any moves toward forced https: are so
  potentially dangerous

Google via NNSquad
https://plus.google.com/+LaurenWeinstein/posts/N5c2RiTSBPf (Google+)

The Internet is already far too dependent on centralized authorities.  We've
seen the DNS abused by LEOs (Law Enforcement Organizations) and courts, not
to mention being turned into an extortion racket by many gTLD domainers and
the domain-industrial complex. Any moves that would make Net communications
even more dependent on centralized entities should be non-starters.  I don't
care who the central entities are -- even with the best of intentions they
could be manipulated by LEOs, courts, crooks, black hat hackers, intel
agencies, or whomever to the detriment of potentially vast numbers of sites
coerced into dependency on issued certs and the associated "chains of
trust."

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

Date: Fri, 8 May 2015 23:49:03 -0700
From: David Brodbeck <david.m.brodbeck () gmail com>
Subject: Re: Authentication vs Identification ... (Ashworth, RISKS-28.62)

Jay Ashworth makes a number of excellent points about the problems of using
Social Security Numbers as both identifiers and authenticators, and suggests
organizations should stop asking for them at all unless there's a legal
need.

A big sticking point here is the use of SSNs as identifiers for credit
reports.

Everyone from utility companies to landlords to prospective employers run
credit checks, these days, which means they all need to ask for my SSN.
Often, refusing to give it would either mean being denied, or providing a
prohibitively large deposit.  Landlords are especially risky, since I can
never be sure if they're actually going to follow through with a lease, or
if they're just going to abscond with my personal details and my application
fee.  A typical rental application has enough info for a very effective
identity theft -- SSN, previous addresses, employment information...

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

Date: Sat, 9 May 2015 14:52:00 -0400
From: Richard I Cook MD <ricookmd () gmail com>
Subject: Re: Doctors don't like EHRs (Geissman, RISKS 28.62)

This is a sore spot for the medical world but not, perhaps, as important as
it at first appears. Exchange of data between systems is not as frequent as
it might have been in the past. The reason is that insurance schemes [sic]
severely limit the choice of provider so cross-system data access is the
exception rather than the rule.

It is true that EHR vendors benefit from non-standard databases. They get to
program things as they like and the difficulty in moving existing data to
another vendor's platform is an obstacle to switching vendors. But the
significance of this is decreasing as the medical industry becomes an EHR
monoculture. The EHR world is quite likely to end up with a single vendor by
2020. Making data accessible for exchange doesn't do much if there is no one
to exchange with.

See Koppel & Lehmann (2015). Implications of an emerging EHR monoculture for
hospitals and healthcare systems. JAMIA 22:465=96471. doi:10.1136, available
as PDF: http://jamia.oxfordjournals.org/content/jaminfo/22/2/465.full.pdf

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

Date: Fri, 8 May 2015 22:46:45 -0500
From: "Alister Wm Macintyre \(Wow\)" <macwheel99 () wowway com>
Subject: Re: Doctors don't like EHRs (Geissman, RISKS-28.62)

I think whoever is in charge of enforcing a standard has a lot to do with
whether it is competent.

Consider PCI-DSS, which most security professionals consider to be a minimum
standard, but security professionals are not in charge of PCI-DSS, the
credit card companies are.  There is a slight variation for each card
company.  If a financial institution wishes to issue a particular credit
card, or a retailer wishes to accept payment via some card, they must agree
to the terms of the standard for that card, unless they are exempted by law
such as using credit card to pay for government services.  If they
sub-contract card processing to some other firm, they are supposed to
cascade the standard into whatever contract, but is this ever audited by the
credit card companies?  One of the reasons why there are so many breaches,
is that agreeing to a standard is not the same as obeying it.  The standard
is supposedly adhered to, during an eye blink of an occasional audit, on
systems which are forever in a state of flux with various hardware and
software upgrades and patches.  Standards Compliance Testing really needs to
be continuous, or rerun after every update.  Then the folks, who agreed to
the standard, claim to have met it because of the eye blink test, when in
fact many of them are ignorant of what all is in the standard.  When I was
full time IT, I occasionally saw on IT forums some peer who had been ordered
to implement the PCI-DSS standard, with zero training, who was reaching out
to fellow computing professionals for guidance on what the heck is that,
because his or her boss had no idea?

I believe EHR is a sub-set of Obama Care, which the Republicans have been
trying to sabotage since day one.  Then implementation was handed to a
government agency which lacked experience in the scale of the project, and
called on hundreds of contractors to each produce pieces of the giant jigsaw
puzzle. We should be amazed the result is working as well as it is.

Whether there is a single mortgage standard may be in the eyes of the
beholder.  In many US states there are court battles over whether the
banking industry is permitted to supplant the old courthouse system of
keeping track of who is a legal owner of real estate.  Under the new
standard, there have been cases of banks foreclosing on homes owned free and
clear, because the records had failed to have been cleared of info on former
owners of the property.  I don't know if that ever happened under the
courthouse system.  But the court house system seems to be suffering a
higher rate of breaches, thanks to government budgets and laws not keeping
up with privacy risks.

I am now retired, but when I was full time in manufacturing ERP, one
standard we had was EDI (electronic data interchange), where companies in a
supply chain send each other business forms associated with the ordering and
delivery of widgets, and getting paid for them.  I worked with EDI I and EDI
II.  I would not be surprised if there's an EDI III by now.  These were
packages of standards, where there was a standard for each type of form,
each type of data, each type of company, each type of communication, and
other ingredients.  I knew of no company which adhered to relevant
standards, except a few industries had a too-big-to-fail conglomerate, or
super-store chain, creating their own independent standards, for any doing
business with them.  The normal rule was each company claimed to have
exceptions, which required their customers and vendors to make modifications
to the standards for the business to work. One of my employer's customers
was mandating new modifications more frequently than Microsoft delivers
critical patches.  Upper management mandated we do anything a customer
wants, claiming this customer's management had promised to pay all expenses
because of implementation urgency.  That lasted until they were willing to
discuss the bill for tens of thousands of hours implementing the never
ending modifications.

The best enforced standard may be income tax forms like W-2, because there
is a single organization in charge, with serious fines for outfits who
violate the standard.  Before I retired, the IRS would wait until a few
months before filing deadline, to change form design, and our ERP company
could not implement the changes until 6 months after the deadline, so we had
to modify to meet IRS standards, then address it again when vendor patches
arrived.

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

Date: Sat, 09 May 2015 00:31:30 +0100
From: Wols Lists <antlists () youngman org uk>
Subject: Re: All cars must have tracking devices ... (AlMac, RISKS-28.62)

Mmmm ... that's problematic. All level crossings *should* have automatic
barriers, and sensors that leave the train signals on yellow until the
barriers have properly deployed with a clear path left for the train.

The problem here, in Europe at least, is that many times by the time the
barrier is deployed and a problem detected, the train may be too close
to stop.

But EU auto manufacturers, which export to other nations, may need to
disable this feature ...

This is nothing new. Most new cars here have LED running lights.  I believe
they are (or were) not permitted in the US. Different standards for
different markets is par for the course.

* The USA has places where cell reception is no good, such as some rural
areas, and valleys.  Is this also true in Europe?

Of course. Britain is the most densely populated country in Europe, yet
we have vast swathes of hilly country with few people, and hence few
mobile masts. Lots of hills and not many masts means plenty of areas
where reception is poor or non-existent (and that includes a lot of
large villages / small towns !!!)

We don't, as far as I know, have many accidents caused by false deployment
of airbags. If the airbag deployment also triggers the alarm, then the
false-positive and false-negative rate is going to be low (false negative as
in an accident causing critical injuries fails to trigger an alarm).

Admittedly, given our dense population, the cost of responding to false
alarms is likely to be low, and a precautionary over-response is likely to
be fairly cost-effective.

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

Date: 9 May 2015 02:23:43 -0000
From: "John Levine" <johnl () iecc com>
Subject: Re: All cars must have tracking devices ... (AlMac, RISKS-28.62)

Trains have drivers (engineers in US English) who can see vehicles blocking
crossings.  The problem isn't seeing them, the problem is that for reasons
of physics and engineering by the time the driver or the radar can see the
vehicle, it's too late to stop the train.

The technical rules for cars in the EU are different from those for
North America and other countries, even cars with the same model name.
Having driven both the US Ford Focus and the European Ford Focus, I
wish I could buy the European one here, since it's a much better car.
Installing or removing a cell phone would be the least of the issues in
converting one from somewhere else to meet EU rules.

* Will this system be as easy to hack as prior systems installed in
vehicles?

Of course.

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

Date: Sun, 10 May 2015 16:01:03 -0800
From: Rob Slade <rmslade () shaw ca>
Subject: REVIEW: "Security for Service Oriented Architectures", Walter Williams

BKSECSOA.RVW   20150130

"Security for Service Oriented Architectures", Walter Williams, 2014,
978-1466584020, U$61.97
%A   Walter Williams walt.williams () gmail com
%C   #300 - 6000 Broken Sound Parkway NW, Boca Raton, FL   33487-2742
%D   2014
%G   978-1466584020 1466584025
%I   CRC Press
%O   U$61.97 800-272-7737 http://www.bh.com/bh/
%O  http://www.amazon.com/exec/obidos/ASIN/1466584025/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1466584025/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1466584025/robsladesin03-20
%O   Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P   329 p.
%T   "Security for Service Oriented Architectures"

Walt Williams is one of the sporadic, but thoughtful, posting members of the
international CISSP Forum.  He has come up with a significant text on an
important topic.

After some preface and introduction, the book starts in chapter two,
defining the four kinds of architecture in computer systems: infrastructure,
software, data, and security.  This chapter covers foundational concepts, as
well as service oriented architecture (SOA), and is, alone, worth the price
of the book.

Chapter three, on implementation, comprises the bulk of the space in the
work, and is primarily of interest to those dealing with development,
although it does have a number of points and observations of use to the
manager or security practitioner.  "Web 2.0" (chapter four) has some brief
points on those advanced usages.  A variety of additional SOA platforms are
examined in chapter five.  Chapter six, on the auditing of SOA applications,
covers not only the how, but also notes specific types of attacks, and the
most appropriate auditing tools for each case.  Much the same is done, in
terms of more general protection, in chapter seven.  Chapter eight, simply
entitled "Architecture," finishes off with sample cases.

It is an unfortunate truism that most security professionals do not know
enough about programming, and most programmers don't care anything about
security.  This is nowhere truer than in service oriented architecture and
"the cloud," where speed of release and bolt-on functionality trumps every
other consideration.  Williams' work is almost alone in a badly under-served
field.  Despite a lack of competition, it is a worthy introduction.  I can
recommend this book to anyone involved in either security or development,
particularly those working in that nebulous concept known as "the cloud."

copyright, Robert M. Slade   2015   BKSECSOA.RVW   20150130
rslade () vcn bc ca     slade () victoria tc ca     rslade () computercrime org

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

Date: Mon, 17 Nov 2014 11:11:11 -0800
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:
   http://mls.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 () 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.
   <http://www.CSL.sri.com/risksinfo.html>
 *** 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:
    <http://www.acm.org/joinacm1>

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

End of RISKS-FORUM Digest 28.63
************************


Current thread: