Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Dan Geer, who has a wonderful bent for things quantitative, has an article in ACM Queue, 2 April 2013, that we somehow missed in RISKS. Dan Geer, Resolved: The Internet is no place for critical infrastructure http://queue.acm.org/detail.cfm?id=2479677 Buried in the middle of the article is this wonderfully pithy paragraph: Risk is a consequence of dependence. Because of shared dependence, aggregate societal dependence on the Internet is not estimable. If dependencies are not estimable, then they will be underestimated. If they are underestimated, then they will not be made secure over the long run, only over the short. As the risks become increasingly unlikely to appear, the interval between events will grow longer. As the latency between events grows, the assumption that safety has been achieved will also grow, thus fueling increased dependence in what is now a positive feedback loop. Accommodating rejectionists preserves alternative, less complex, more durable means and therefore bounds dependence. Bounding dependence is the core of rational risk management.
Marc Santora, William K. Rashbaum and Nicole Perlroth, *The New York Times*, 28 May 2013 The operators of a global currency exchange ran a $6 billion money-laundering operation online, a central hub for criminals trafficking in everything from stolen identities to child pornography, federal prosecutors in New York said on Tuesday. The currency exchange, Liberty Reserve, operated beyond the traditional confines of United States and international banking regulations in what prosecutors called a shadowy netherworld of cyberfinance. It traded in virtual currency and provided the kind of anonymous and easily accessible banking infrastructure increasingly sought by criminal networks, law enforcement officials said. The charges announced at a news conference by Preet Bharara, the United States attorney in Manhattan, and other law enforcement officials, mark what officials said was believed to be the largest online money-laundering case in history. Over seven years, Liberty Reserve was responsible for laundering billions of dollars, conducting 55 million transactions that involved millions of customers around the world, including about 200,000 in the United States, according to prosecutors. ... http://www.nytimes.com/2013/05/29/nyregion/liberty-reserve-operators-accused-of-money-laundering.html
At a time when we are still in deep economic trouble, with huge numbers of people unemployed, or under-employed, and with no serious effort to get corporations and the super-rich to pay more taxes, many states and municipalities are turning to gambling as a "painless" revenue source. We are seeing more state lotteries, licensing of casinos, etc., and the use of the internet to make it easier for people to gamble. Is this a good thing, or is there a serious down side? Place your bets as to what my position is on this. My analysis is accessible at: http://www1.cs.columbia.edu/~unger/articles/gambling.html Stephen H. Unger, Professor Emeritus, Computer Science and Electrical Engineering, Columbia University
Half of employees never consider security when they upload or download data to their office PC or company smartphone, according to a survey. And 40 per cent of employees said they did not know about their company's security policy when using their phone. Many never consider the threat of cyber crime and are unfamiliar with company policies to protect their data, the poll of 1,200 officer workers found. http://www.modis.co.uk/resources/news/ http://www.standard.co.uk/business/business-news/half-of-workers-arent-aware-of-cyber-security-policies-8610358.html Staffing provider Modis said its research showed that even business owners did not think about the security of their organization's data when downloading or uploading information. http://metro.co.uk/2013/05/10/employees-clueless-on-cyber-security-3748202/ Roy Dungworth, of IT staffing provider Modis, which carried out the survey, said: “The rise of flexible working and cloud computing has created a multitude of points at which cyber criminals can access a company's data.'' Half of workers do not know if their company has a policy on cyber crime and do not worry about security when they download data to their phone, according to a new study. http://uk.news.yahoo.com/employees-unaware-cyber-risks-231749012.html
Lucian Constantin, InfoWorld, 23 May 2013 The malware is connected to Indian cyberespioange operation and has been active since at least December 2012, researchers say http://podcasts.infoworld.com/d/security/researchers-find-more-versions-of-digitally-signed-mac-os-x-spyware-219245 selected text: The newly discovered KitM variants are all signed with the same Rajinder Kumar certificate. Apple revoked this Developer ID last week, after the first samples were discovered, but this won't immediately help existing victims, according to Bogdan Botezatu, a senior e-threat analyst at antivirus vendor Bitdefender. "Gatekeeper uses the File Quarantine system, which holds the file in quarantine until it is first executed," Botezatu said Thursday via email. "If it passes Gatekeeper on first run, it will continue to run and never be queried by Gatekeeper again. So, malware samples that have been ran once while the developer ID used for signing them was valid will continue to run on the machines."
Jeremy Kirk, InfoWorld, 22 May 2013 Legislation that would give the federal government power to oversee the protection of utilities has stalled http://www.infoworld.com/d/security/us-power-companies-under-frequent-cyber-attack-219118
Nick Bilton, *The New York Times, 26 May 2013 Perhaps the best way to predict how society will react to so-called wearable computing devices is to read the Dr. Seuss children's story "The Butter Battle Book." The book, which was published in 1984, is about two cultures at odds. On one side are the Zooks, who eat their bread with the buttered side down. In opposition are the Yooks, who eat their bread with the buttered side up. As the story progresses, their different views lead to an arms race and potentially an all-out war. Well, the Zooks and the Yooks may have nothing on wearable computing fans, who are starting to sport devices that can record everything going on around them with a wink or subtle click, and the people who promise to confront violently anyone wearing one of these devices. I've experienced both sides of this debate with Google's Internet-connected glasses, Google Glass. Last year, after Google unveiled its wearable computer, I had a brief opportunity to test it and was awe-struck by the potential of this technology. A few months later, at a work-related party, I saw several people wearing Glass, their cameras hovering above their eyes as we talked. I was startled by how much Glass invades people's privacy, leaving them two choices: stare at a camera that is constantly staring back at them, or leave the room. ... http://bits.blogs.nytimes.com/2013/05/26/disruptions-at-odds-over-privacy-challenges-of-wearable-computing/
Today's software is layered. Your computer has a bios. Your operating system
uses that bios. Your apps use the operating system. Any website's you
connect to is a machine that uses a web server—an app or "application
program"—to provide pages to you (the web server is usually Apache or
IIS). The web server you connect to uses pages written using probably PHP,
Perl or ASP to dynamically create pages. Those pages depend on PHP, Perl, or
Visual Basic in Microsoft IIS to provide the underlying interpreter to
render them. And then some websites (like Wikipedia) are scriptable, so the
web pages running on PHP, which are running on Apache, which are running on
Linux (or Windows), all provide interesting places to potentially have bugs.
"Pick a card, any card." Now, when something is wrong, where is it? I'm
doing a calendar test on Wikipedia, and I wrote a small piece of Wikimedia
code (the macro syntax used by the software that runs Wikipedia). And it
comes up wrong. You can see it in a sample template I did at
http://en.wikipedia.org/w/index.php?title=Template:X8&oldid=557212409
It discovered that the dates rendered before January 1, 1600 are wrong. So
if you place in a Wikipedia page the following macro to display the day of
the week: {#time:l|1600-01-01}} It is correct, Saturday. Also, this macro
call for today: Today: 2013-05-28 is {{#time:l|2013-05-28}} Which says
Today: 2013-05-28 is Tuesday. But this: Year 1599 is {{#time:l|1599-01-01}}
Says: Year 1599 is Saturday. What's the problem? 1599 started on a Friday.
I reported it to the Wikipedia Foundation on their bug tracker, but it
occurred to me it might be an error in PHP, the underlying software that
Wikimedia is written in. So I wrote a small program, which, since I have
hosting—I run my own blog—I can question is why this bug exists in the
first place? I think the algorithm, Zeller's Congruence, for getting the day
of the week works for all Gregorian dates, and the Gregorian calendar
started in 1583, 17 years earlier.
[1] https://bugs.php.net/bug.php?id=61599=0A
"In a decision that's almost certainly going to result in this issue heading up to the Supreme Court, the Federal 1st Circuit Court of Appeals [Friday] ruled that police can't search your phone when they arrest you without a warrant. That's contrary to most courts' previous findings in these kinds of cases where judges have allowed warrantless searches through cell phones." http://j.mp/YQOoQl (Slashdot via NNSquad)
On May 23rd, an overloaded truck struck support trusses for a bridge over the Skagit River on Interstate 5 between Burlington and Mount Vernon, WA. This is an important route, and since I will be going that way in August, I was concerned about making alternative plans. Washington State Department of Transportation has this data on it: http://www.wsdot.wa.gov/Projects/I5/SkagitRiverBridgeReplacement/default.htm Google Maps does not show the bridge now in map mode (though it is still shown in satellite mode). Getting directions between Vancouver, BC and Seattle, WA shows a detour off I-5 by the ex-bridge. It is nice to see that the Google Maps people are on the ball.
However, Vcare and the two telecom companies assert that the reporters
"hacked" their way into the data using "automated" methods to access the
data. And what was this malicious hacking tool that penetrated the
security of Vcare's servers? In a letter sent to Scripps News by Jonathan
D. Lee, counsel for both of the cell carriers, Lee said that Vcare's
research had shown that the reporters were "using the 'Wget' program to
search for and download the Companies' confidential data." GNU Wget is a
free and open source tool used for batch downloads over HTTP and FTP. Lee
claimed Vcare's investigation found the files were bulk-downloaded via two
Scripps IP addresses.
http://j.mp/10onoVP (ars technica via NNSquad)
- - -
Ah yes—wget—more dangerous to mankind than General Zod!
http://www.google.com/transparencyreport/traffic/ etc. etc.
http://j.mp/10IAcXg (Google+ via NNSquad) "The Association for Computing Machinery (ACM) recently announced a new option for publication rights management, wherein researchers can choose to pay for the public to have perpetual open access to the publication ( http://goo.gl/OXlYp ). Google applauds this new option, and today we are announcing that we will pay the open access fees for all articles by Google researchers that are published in ACM journals. IEEE ( http://goo.gl/qqeka ) also has an open access option for some of its publications, and we also pay the open access fee for them and for publications in like organizations."
I'm skipping over the usual observations about the need to get the legal framework right first before you offer crypto products (flogging a dead horse etc) - I have a simple answer why I personally would not be that interested in security products from Seecrypt (abridged version): bushido:~ peter$ dig seecrypt.com mx ;; QUESTION SECTION: ;seecrypt.com. IN MX ;; ANSWER SECTION: seecrypt.com. 7200 IN MX 5 ALT1.ASPMX.L.GOOGLE.com. seecrypt.com. 7200 IN MX 10 ASPMX2.GOOGLEMAIL.com. seecrypt.com. 7200 IN MX 1 ASPMX.L.GOOGLE.com. seecrypt.com. 7200 IN MX 5 ALT2.ASPMX.L.GOOGLE.com. seecrypt.com. 7200 IN MX 10 ASPMX3.GOOGLEMAIL.com. I would not be terribly inclined to do business with Seecrypt: they use Google as e-mail provider, which is IMHO not exactly a great approach to protecting client confidentiality. Case closed.
For anyone interested in quantifying the risks of spreadsheet errors, the European Spreadsheet Risks Interest Group, "eusprig" http://www.eusprig.org/ They not only have a set of horror stories, but cite a lovely 2002 paper, Spreadsheet Engineering: A Research Framework, by Thomas A. Grossman. http://arxiv.org/ftp/arxiv/papers/0711/0711.0538.pdf The author makes the point that spreadsheets are a declarative programming tool, programmed by people who have understanding of the problem domain, but of what software engineers would consider a process for writing correct spreadsheets. This appears to be due as much to the different psychological outlook of "software developers" from "spreadsheet developers"—something noted by Bonnie Nardi and Jim Miller in 1990 [Nardi90]—as to the weak tooling in spreadsheets for delivering high quality applications. There is also the lack of significant work in the software engineering community, where we are more concerned with the correctness of our IDE-written, SCM managed code, than in spreadsheets. "This class of programming—high stakes, high speed coding with strategic implications—appears to be absent from the software engineering literature. There are many interesting issues regarding this sort of programming, particularly how to design a spreadsheet to ensure flexibility and reduce the likelihood of errors." To add insult to injury, the fact that artifact delivery is often by multihop email attachments without adequate provenance or updating means that even knowing where your application has got to is unknown -making maintenance that much harder. Collaborative server-based spreadsheets—MS sharepoint, google applications, etc,, may handle distribution, but don't appear to addresss the other risks described in [Grossman02]. In fact, even for those of us who do understand software development and naming, spreadsheet development as a workflow of copy-existing-file-and-change is dangerously close to the "copy and edit" process that software engineering has long recognized as creating maintenance grief downstream. Of course, this lack of focus on quality development techniques in what could well be largest programming tools used round the world does present some interesting opportunities for anyone wanting to fix this. The open source developers of Apache Open Office would no doubt welcome anyone willing to address this in their software. [Grossman02]: Grossman, Spreadsheet Engineering: A Research Framework. http://arxiv.org/ftp/arxiv/papers/0711/0711.0538.pdf [Nardi90] : B.A. Nardi, J.R. Miller: An ethnographic study of distributed problem solving in spreadsheet development http://www.hpl.hp.com/techreports/90/HPL-90-08.html http://www.darrouzet-nardi.net/bonnie/pdf/Nardi_spreadsheet.pdf
As a middle-aged ex-smoker I remember very well the brouhaha around passive smoking, with all the studies that found correlations below the margin of accuracy and all those calls for retractions (e.g. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC188394/) and lawsuits and great fun's been had by all. I'm sure other RISKS readers have other examples of studies whose conclusions were tailored to support the author's initial premise (though perhaps few with as much media coverage). The only difference is this time we're blaming Excel. Come on, you lost me at "global economic crisis modeled in Excel program". Dimitri Maziuk, Programmer/sysadmin BioMagResBank, UW-Madison—http://www.bmrb.wisc.edu PS. here's another example, this is getting little PR in the USA for some reason: http://en.wikipedia.org/wiki/Gun_politics_in_Australia#Research "It is always unpleasant to acknowledge facts that are inconsistent with your own point of view."
>> I would be surprised if this feature does not exist in the >> still-popular Excel 2003.' It exists in Excel 97. I have never used it since I do not make complex spreadsheets. I tried it, and it worked, but it is of limited use, because I can not find out what a name means. At least, I could not find it which is about the same. It is easier, then, for me to verify a co-ordinate range because I can check those cells, but what does "TTT" mean? If I do not know what it means, then I can not check that it is correct. 'It seems that, in this case, Kohne's observations about folks lacking a combination of subject-matter expertise and fluency with chosen digital tools is more compelling than dwelling on the absence of features that are actually present.' There is the problem of a tool not having all of the pieces necessary for it to be truly useful. Or that the features are not obvious.
Book Review By Richard Austin, May 23, 2013
[Extracted From IEEE TCSP CIPHER, Issue 114, May 28, 2013.
A very valuable resource, Cipher is published 6 times per year. The
entire newsletter is at http://www.ieee-security.org/cipher.html. PGN]
Dawn Cappelli, Andrew Moore and Randall Trzeciak
The CERT Guide to Insider Threats
Addison-Wesley 2012.
ISBN 978-0-321-81257-5 amazon.com USD 35.88,
Table of Contents:
http://www.pearsonhighered.com/educator/product/CERT-Guide-Insider-Threats-How-Prevent-Detect-and-Respond-Information-Technology-Crimes-Theft-Sabotage-Fraud/9780321812575.page#table-of-contents
This was a hard book to review - it is intended to be introductory and
targeted at a non-technical reader, a decision which led to a glacial pace
of presentation and frustratingly shallow detail in many areas. However, it
also has the huge plus of being based on analysis of 700+ cases of insider
abuse collected by CERT over a ten-year period. For that reason alone, I
respectfully recommend it to your attention.
The term "insider threat" can have many meanings so the authors clearly set
their scope as "a current or former employee, contractor or business partner
who has or has had authorized access to an organization's network, system or
data and intentionally exceeded or misused that access in a manner that
negatively affected the confidentiality, integrity or availability of
information or information systems" (p. xx). That definition earns the
authors bonus credit for including both contractors and business partners.
Based on their analysis, the authors identify three profiles for
insider threats: IT sabotage, Theft of intellectual property, Fraud.
As security professionals, our goals for insider threats are to identify the
factors that make the threat likely to occur (the authors call these
"predispositions"), to recognize that the threat has been instantiated, and
to mitigate the threat or its effects. The authors address those goals by
abstracting the results of their analysis of insider threat into the MERIT
model ("Management and Education of the Risk of Insider Threat"). MERIT is
a system dynamics model and some readers may benefit from a more substantial
introduction to the topic (e.g., Meadows, D. H. [2008]. "Thinking in
Systems: A Primer". Chelsea Green Publishing).
Each threat profile is described in its own chapter where the model for that
threat is presented. For example, the authors found that cases involving
theft of intellectual property (IP) fit two general patterns: "entitled
independent" and "ambitious leader". The "entitled independent" is, for
example, the engineer who feels a proprietary ownership in the new product
she developed and feels "entitled" to take the design with her when her
position is eliminated during an economic downturn. The "ambitious leader"
recruits a group of insiders to pilfer intellectual property for a share in
the financial reward. The MERIT model for these patterns portrays the
factors and relationships that give rise to the threat and shows where
organizational responses can be most effectively applied. For example, the
desire to steal for an "entitled independent" arises from the interplay
between their contribution to the IP and feelings of ownership and
precipitating events such as dissatisfaction or a job offer from a
competitor. There's obviously a tension here where even though the feeling
of entitlement predisposes the engineer to potentially steal the product,
the organization benefits from the engineer's substantial contributions to
the product and feelings of ownership. The models recognize this tension by
suggesting that organizations include recognition of precipitating events as
triggers for defensive measures such as increased behavioral monitoring.
After working through the threat models, the authors turn their attention to
detection and prevention. Chapter 6 reviews 16 best practices (ranging from
consistently enforcing policies to effective monitoring). The best
practices are each presented in a "how to" followed by a "what happens if
you don't" case study. The list of best practices contains no surprises but
a reexamination of "the usual suspects" from an insider-threat perspective
is useful.
Chapter 7, "Technical Insider Threat Controls", provides
managerially-focused readers with a brief introduction to how intrusion
detection systems (IDS), network flow data, security information and event
management (SIEM), etc., can be effectively used in detecting instantiation
of insider threats.
For technical professionals, the takeaways from this book revolve around the
MERIT model and its way of looking at insider threats. The authors provide
footnote references to the papers that back up the book chapters, and much
of the lamented missing details are found in those papers. For managerial
professionals, this is an excellent introductory book for understanding the
scope of the insider threat and what organizations can do to predict,
recognize and mitigate the threat.
[It has been said "Be careful, for writing books is endless, and much
study wears you out" so Richard Austin (http://cse.spsu.edu/raustin2)
fearlessly samples the wares of the publishing houses and opines as to
which might most profitably occupy your scarce reading time. He welcomes
your thoughts and comments via raustin at ieee dot org .]
Please report problems with the web pages to the maintainer