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…
It's not demonstrating a risk here, but how secure is that Carrier protocol? Has a third-party evaluated it? Can it do anything besides telling thermostats to cycle every half hour? Can it be misused? Con-Ed Nerve Center Fights to Keep Lights On "In times of unusually high demand for electricity, Con Ed tells Carrier, the maker of heating and cooling systems, to send a radio signal that causes those thermostats to cycle on and off every 30 minutes. Doing so shaved about 25 megawatts off the peak demand this week, Con Ed officials said." https://www.nytimes.com/2010/07/08/nyregion/08heat.html or http://tinyurl.com/2e8s69p
http://news.yahoo.com/s/ap/us_california_budget_minimum_wage Absolutely pathetic. One reason America is in decline: major computer systems such as California's payroll were designed for computers like the one I first worked on in 1971: it had 8000 "bytes" of RAM. The information California needs to change is probably scattered through "sequential" files such that to find any record, you have to read all the records before it. And because there was no such thing as data base technology in the 1950s, the "knowledge" of how to find pieces of data (such as employee salaries) and interpret their contents (which could be a binary number, a "binary coded decimal number" or some wack's Own Idea encapsulated in said wack's code) much less change them, is lost and inside incomprehensible computer code. Probably, up to now, you submitted a "change" request to change an employee's salary, possibly still as a punched card. These change requests are probably combined or "batched" and then run together once a day or week. This means you'd have to create a change request for every single employee to implement Arnold's plan and match every record in a single whopper run. My guess is that the "change" software, assuming there aren't different versions for different classes of state employees (a distinct possibility) is "NP complete", meaning that it is "fast" on modern computers for the expected number of changes (a couple of orders of magnitude less than the total file size) but ramps up exponentially for the unexpected case of "change all employees". Whereas in developing countries the payroll was automated recently using best of breed database technology. Matching two sets of data was rocket science in the 1950s. Today, most ordinary computer programmers don't know how to do it, but databases programmed by good programmers do so as fast as possible. And I really don't want a job cutting state employee pay in sunny California by reviving my mainframe skills. I will pass this job lead on to some of my geezer friends. Remember when you were a hotshot if you could program, and could fund your California lifestyle with a part time coding job for the state? Welcome to the future, hotshot.
The soldier accused of downloading a huge trove of secret data from military computers in Iraq appears to have exploited a loophole in Defense Department security to copy thousands of files onto compact discs over a six-month period. In at least one instance, according to those familiar with the inquiry, the soldier smuggled highly classified data out of his intelligence unit on a disc disguised as a music CD by Lady Gaga. https://www.nytimes.com/2010/07/09/world/09breach.html?hp
We take a look at all the various sources of data Microsoft collects from customers, how it stores and uses that data, and how its use of it stacks up against Google and other competitors. Lee Pender, *Redmond Magazine*, 1 Jul 2010 Just about every software vendor or Web service collects information about its users. Some do it with more subtlety than others, but the fact is that there's hardly an application or Web site that doesn't gather some sort of intelligence about you every time you use it. Microsoft, of course, is no exception. From Windows Activation Technologies (WAT) to Bing, Microsoft stockpiles information on you even when you don't sign up for services such as Hotmail. But what does Microsoft know about you? Actually, a more appropriate question might be: What kind of information about you can Microsoft see? It could see a lot, but there are some things that the company chooses not to view or store. For example, the unpopular WAT, formerly known as Windows Genuine Advantage, is perhaps the least intrusive of the Microsoft information-gathering tools. Bing and Hotmail get a little more personal, but experts and IT professionals say that they're less worried about Microsoft regarding privacy than they are about some other high-profile vendors. What Microsoft Knows Microsoft starts collecting information on you and your system within minutes of you starting up a brand-new system. We asked Brendon Lynch, senior director of privacy strategy at Microsoft, to help us compile a step-by-step explanation of what Microsoft knows and when it knows it. The flow begins when you first start your system, log on to Windows and go through the WAT validation process. ... http://redmondmag.com/Articles/2010/07/01/What-Does-Microsoft-Know-About-You.aspx
Robert McMillan, *Business Week*, 2 Jul 2010 A former IT staffer with the Bank of New York Mellon pleaded guilty Thursday to stealing sensitive information belonging to 2,000 bank employees and then using that data to steal more than US$1 million from charities. ... http://www.businessweek.com/idg/2010-07-02/ny-bank-it-tech-pleads-guilty-to-data-theft-fraud.html
Trip Gabriel, *The New York Times*, 5 Jul 2010 https://www.nytimes.com/2010/07/06/education/06cheat.html The frontier in the battle to defeat student cheating may be here at the testing center of the University of Central Florida. * No gum is allowed during an exam: chewing could disguise a student's speaking into a hands-free cellphone to an accomplice outside. * The 228 computers that students use are recessed into desk tops so that anyone trying to photograph the screen - using, say, a pen with a hidden camera, in order to help a friend who will take the test later - is easy to spot. * Scratch paper is allowed - but it is stamped with the date and must be turned in later. * When a proctor sees something suspicious, he records the student's real-time work at the computer and directs an overhead camera to zoom in, and both sets of images are burned onto a CD for evidence. ...
[Thanks to Deborah Peel, Founder and Chair, Patient Privacy Rights (http://www.patientprivacyrights.org) for these items; starkly PGN-ed] 1. Steve Green, *Lawsuit filed over UMC patient records' leak, *Las Vegas Sun*, 3 Jul 2010 http://www.lasvegassun.com/news/2010/jul/03/lawsuit-filed-over-umc-patient-records-leak/ University Medical Center in Clark County NV is being sued for leaking confidential patient information. But the hook in the story seems to be the way in which patients were informed of the leak: they were offered a one-year free subscription to a credit-monitoring system knowledge of whose expiration became public, The *Sun* was also investigating a UMC employee who was tipping lawyers off on traffic accident victims. 2. ACLU sues over R.I. Health Information Exchange Claiming that not enough has been done to protect the privacy rights of patients, the Rhode Island chapter of the American Civil Liberties Union (ACLU) filed suit against the R.I. Department of Health (DOH), challenging the rules the agency has adopted to implement a centralized database of patient healthcare records in the state for its statewide health information exchange (HIE). http://www.cmio.net/index.php?option=com_articles&view=article&id=22971
Earlier today I called my bank's helpdesk to obtain an electronic certificate that was needed to transfer money to another account. After they verified my credentials the customer representative asked me: * Did you respond to that email we sent you asking for your username and password? Up to that point I was mechanically answering all their questions, but this one made me pause. In this forum we often criticize incompetent banks and silly security procedures, so my first thought was about the cluelessness of sending out such emails. However, a second later I realized that *they* were fishing, trying to find out if *I* had been the victim of a phishing attack and replied negatively. I was surprised by the question's originality and cleverness, so I asked if they were indeed looking for victims of phishing attacks and they acknowledged that this was their intention. Bravo! Diomidis Spinellis - http://www.spinellis.gr
Miguel Helft, 2 Jul 2010 Apple customers love to complain about the reception on their iPhones. And the problem may be worse than it looks. Apple said on Friday that for years its phones had been exaggerating signal strength by displaying too many bars - indicating stronger reception than there ever was. The problem, Apple said, is a bug in the software, which it promised to fix soon. Once it does, it seems, customers will be able to see just how bad reception really is. The company said it discovered the problem while trying to explain the mystery of the disappearing bars on its new iPhone 4, a week after some users began complaining that when they held the phone a certain way, the bars indicating signal strength dropped off sharply. But Apple said the flaw, which it promised to fix shortly, existed with older versions of the iPhone, too. For a company that obsesses over every detail of its products, the failure to detect this longstanding problem earlier is astonishing. Some customers say they are skeptical of Apple's explanation of the vanishing bars. "I don't buy it that it is just a simple matter of the meter not showing the right amount of signal strength," said Bryan Hurst, of Hackettstown, N.J., who upgraded last week to an iPhone 4 from an iPhone 3GS. Mr. Hurst said he had had more problems with dropped calls with the new handset than the old one. "It doesn't make any sense," he said. But Apple disagrees and says there is plenty to like about the iPhone 4. The much-vaunted antenna - designed specially for the new phone - works just fine, the company said. In fact, Apple said, the iPhone 4 is the best ever on several fronts, including wireless reception. ... http://www.nytimes.com/2010/07/03/technology/03apple.html
It seems to me that this is just a high-tech twist on a risk that is typically already present. Unless one has taken the precaution of establishing a separate mailing address for car registration information, the automobile registration in the glove box of the car will typically already have your home address on it. Add in the attached garage and automatic garage door opener, and the bad guys won't even need to jimmy the lock. [Besides, putting in a bogus address does not help if the historical record shows your actual coordinates! PGN]
> I'd like to see a campaign to change the nature of auto-updaters (such as MS > Word or Adobe). [...] Me too! I see several other problems here: * The frequency of updates. With only a few common applications (and one OS) installed, I sometimes feel there is not ever a time when I'm not being nagged for an update. * The need for reboots. I'm sure that many updates requesting a reboot don't (or shouldn't) really need it. * An interaction between the last two points: many updaters don't check for updates until a reboot, which I generally only do if an updater has requested it. So one update can lead to another... It seems to me that at least some of this ought to be in the hands of the OS. It already needs a secure method of providing updates, which we must trust. This uses, or could use, sensible protocols to ensure authentic provenance as well as providing decent UI for update management, including managing the risks inherent in such updates. If the back end were open to third parties to add their updates to the stream, this could be all managed far more effectively. This would still be open to abuse but less so, and such abuse would be more easily controlled. While it smacks of the single basket, it is a basket we already must trust.
However, when a bug in the application (or operating system) causes your = program to crash on launch (or crash during updating), you are left with = an unusable application. This happened with World of Warcraft for Mac OS X a few years ago.
BKSSLTTP.RVW 20091129 "SSL and TLS: Theory and Practice", Rolf Oppliger, 2009, 978-1-59693-447-4 %A Rolf Oppliger rolf.oppliger@esecurity.ch %C 685 Canton St., Norwood, MA 02062 %D 2009 %G 978-1-59693-447-4 1-59693-447-6 %I Artech House/Horizon %O 617-769-9750 800-225-9977 artech@artech-house.com %O http://books.esecurity.ch/ssltls.html %O http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20 %O Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation) %P 257 p. %T "SSL and TLS: Theory and Practice" The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols. (Oppliger does not address issues of implementation or specific products.) The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, although some fundamental cryptographic principles are given. Chapter one is a basic introduction to security and some related concepts. The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy. The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned. In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols. (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.) The author's commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic. Chapter three, although entitled "Transport Layer Security," is basically a history of both SSL and TLS. SSL is examined in terms of the protocols, structures, and messages, in chapter four. There is also a quick analysis of the structural strength of the specification. Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2. DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges. Chapter seven notes the use of SSL for VPN (virtual private network) tunneling. Chapter eight reviews some aspects of public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure). As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man- in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI). In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter. The material is clear, well structured, and easily accessible. He has definitely enhanced the literature. not only of TLS, but also of security in general. copyright Robert M. Slade, 2009 BKSSLTTP.RVW 20091129 rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html http://blogs.securiteam.com/index.php/archives/author/p1/
This subject examined in detail by Lee Clarke in his book "Mission Improbable: Using Fantasy Documents to Tame Disaster"—which details Exxon's disaster "plan" for spills around Valdez, Alaska. (University Of Chicago Press, 2001, ISBN-10: 0226109429). It is no surprise that companies develop fantasy documents for disaster management. What is surprising is that regulators and agencies continue to accept these documents as written.
Please report problems with the web pages to the maintainer