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)21431378673360 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]
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.
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!
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
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."
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...
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–471. doi:10.1136, available as PDF: http://jamia.oxfordjournals.org/content/jaminfo/22/2/465.full.pdf
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.
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.
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.
BKSECSOA.RVW 20150130 "Security for Service Oriented Architectures", Walter Williams, 2014, 978-1466584020, U$61.97 %A Walter Williams email@example.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 firstname.lastname@example.org email@example.com firstname.lastname@example.org
Please report problems with the web pages to the maintainer