Vice has a great interview with Peter Singer. Singer makes some excellent points, especially when it comes to applying the word terrorism to the Sony pictures hack.
The FBI's definition of terrorism is as follows:
18 U.S.C. § 2331 defines "international terrorism" and "domestic terrorism" for purposes of Chapter 113B of the Code, entitled "Terrorism":
- Involve violent acts or acts dangerous to human life that violate federal or state law;
- Appear to be intended (i) to intimidate or coerce a civilian population; (ii) to influence the policy of a government by intimidation or coercion; or (iii) to affect the conduct of a government by mass destruction, assassination, or kidnapping; and
- Occur primarily outside the territorial jurisdiction of the U.S., or transcend national boundaries in terms of the means by which they are accomplished, the persons they appear intended to intimidate or coerce, or the locale in which their perpetrators operate or seek asylum.*
Calling what happened to Sony terrorism cheapens the idea of terrorism for those who have suffered violence. The 132 children who were recently killed by the Taliban in Pakistan were victims of terrorism. Their families were victims of terrorism. What Sony is suffering from is embarrassment.
NB: Above, I am speaking solely of The Hack. Ensuing threats of violence from the Guardians of Peace certainly fall into the definition. But again, as Singer points out: is there capability to follow through with said threat?
Sony's label of "cyber terrorism" is being echoed by organizations like the MPAA who sent out this gem of a Press Release:
"The FBI's announcement that North Korea is responsible for the attack on Sony Pictures is confirmation of what we suspected to be the case: that cyber terrorists, bent on wreaking havoc, have violated a major company to steal personal information, company secrets and threaten the American public. It is a despicable, criminal act.Disappointingly, that fact has been lost in a lot of the media coverage of this over the past few weeks. This situation is larger than a movie's release or the contents of someone's private emails. This is about the fact that criminals were able to hack in and steal what has now been identified as many times the volume of all of the printed material in the Library of Congress and threaten the livelihoods of thousands of Americans who work in the film and television industry, as well as the millions who simply choose to go to the movies. The Internet is a powerful force for good and it is deplorable that it is being used as a weapon not just by common criminals, but also, sophisticated cyber terrorists. We cannot allow that front to be opened again on American corporations or the American people" [emphasis added].
Which is it? Terrorists or criminals? These are dangerous waters being waded into in describing the hack.
Was Sony at fault for this?
An acquaintance recently summed up some philosophical nuances: "...there is an important moral difference between 'creating a situation with a predictable effect they should have foreseen' and 'asking for it' or 'inviting it.' The latter phrases mitigate the immorality of the attackers, as if it makes it less wrong to do something predictably wrong. If you 'invite' or 'ask for' something you are condoning it. If you just stupidly leave yourself open to it, you are responsible for being stupid, but not for the wrong act that results."
DPRK (official according to FBI) is 100% at fault for the morality of their actions, i.e. that they were wrong. Sony is the victim.
Now, let's talk about the responsibility Sony had.
Sony had a responsibility to their employees and shareholders to protect their personal and intellectual property. They had a responsibility to identify, understand, and operate within their threat environment. Sony failed to uphold that responsibility in an epic and very public fashion. Sony has not acknowledged this failure. "Being a victim is more palatable than having to recognize the intrinsic contradictions of one's own governing philosophy." ? Tom Clancy, The Hunt for Red October
Sony has chosen a response I certainly would not have advised had I been standing in their incident response room. Singer calls this the 'lose our shit' mentality, "[t]he reality is we can either choose a 'lose our shit' mentality, or we can choose a mentality that is far more successful, which is focusing on resilience."
Perhaps Sony can stop losing their shit and focus on resilience.
Dan Greer delivered the following speech at this year's (2014) BlackHat. The video and text are presented below. I have republished the text below but edited from original text format to be a bit more readable and printable.
[ nominal delivery draft, 6 August 2014 ]
Cybersecurity as Realpolitik
Good morning and thank you for the invitation to speak with you today. The plaintext of this talk has been made available to the organizers. While I will not be taking questions today, you are welcome to contact me later and I will do what I can to reply. For simple clarity, let me repeat the abstract for this talk:
Power exists to be used. Some wish for cyber safety, which they will not get. Others wish for cyber order, which they will not get. Some have the eye to discern cyber policies that are "the least worst thing;" may they fill the vacuum of wishful thinking.
Privacy and security folks rely on encryption as a means to ensure the confidentiality and integrity of information, protecting it at rest and in transit. But what happens when a fundamental control is thoroughly compromised? When a protective control becomes an attack vector? How should we react?
It is critical to note that proof of concept exploit code is already in the wild. This is not a theoretical emergency.
Today, we should be activating Incident Response Plans (or screaming, loudly, with hair on fire) within our organizations to do the following:
- Identify all external and internal sites using SSL/TLS
- This could be a website, API interface, e-mail connection, VPN concentrator, etc.
- Check if they are vulnerable
- There are a few sites offering to "check if you're vulnerable" ; however, don't rely on them. They could be actively exploiting you and you wouldn't know it. Keep it in house.
- GitHub has a pre-tested list of the top 10,000 websites here:
- Note for above: your client must support 'heartbeat' otherwise you will get false positives.
- Find one of your system admins and have them conduct a check:
- The following command (or something similar) can provide quick feedback (replace google.com with the target server)
openssl s_client -connect google.com:443 -tlsextdebug 2>1 | grep 'server extension "heartbeat" (id=15)' || echo safe
- If the site is not vulnerable, celebrate. You've avoided the heartbleed problem but...
- Don't celebrate too hard, it likely means you're running a very old OpenSSL version and are vulnerable to many other issues.
- If the site is vulnerable, do the following:
- Patching affected systems to OpenSSL 1.0.1g
- Update any other dependent software/hardware
- Procure new certificates
- Revocation of the old keypairs that were just supersceded
- Changing all passwords
- nvalidating all session keys and cookies
- Evaluating the actual content handled by the vulnerable servers that could have been leaked, and reacting accordingly
- Evaluating any other information that could have been revealed, like memory addresses and security measures
- Ensure all end-user browsers all check Certificate Revocation Lists, this functionality is generally off by default
Updating certificates will cost you money. However, the risk is that your site has already been compromised before you remediated the risk. If someone has your private key, you're forever compromised until you replace the certificates. Since, as of writing this, you cannot tell if you've been compromised or not, it is much better to err on the side of caution and spend the money replacing your certificates.
In some cases, hardware based platforms will not have a quick fix for this vulnerability. You should have conversations with your IT, Business, and Security Operations people. Investigate the possibility of unplugging that piece of hardware, depending on how critical it is, until it can be fixed. This is a big decision and trade offs will need to be understood thoroughly. However, the gravity and seriousness of the heartbleed situation should be clearly communicated. This is the fire drill we never really wanted to have.
-------------------------- Background on OpenSSL and vulnerability --------------------------
OpenSSL (wikipedia) is an open-source implementation of the SSL and TLS protocols. The library is supported on multiple OS platforms (Unix, Windows, etc) , multiple connection types (web, email, VPN, XMMP chat, APIs, etc.), and is extensively used. Trust me when I say, it's in your environment. Likely in many places. Specific OpenSSL versions have a vulnerability that can completely compromise all information transmitted over the connection, rendering the protection moot. The vulnerability allows for compromise of the private keys on the server side. The attack, so far, is not detectable. This is very, very, bad.
Questions? Concerns? Comments are welcome below and on twitter @PrivacyWonk.
Security Advisory from OpenSSL - https://www.openssl.org/news/secadv_20140407.txt
OpenSSL Security Advisory [07 Apr 2014] ======================================== TLS heartbeat read overrun (CVE-2014-0160) ========================================== A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <firstname.lastname@example.org> and Bodo Moeller <email@example.com> for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2.Additional Sources:
Adam Shostack (@adamshostack) discusses Threat Modeling on Mozilla Air. Excellent presentation (so far)
Reading up on location based privacy...below are a few articles spanning 7 years that tackle the issues from a few different angles. Brush, Krumm, and Scott's paper is especially interesting as they look specifically at end-user values of location data privacy, what and how they chose to protect that data, and how they share that data.
- Ardagna, C. A., Cremonini, M., Damiani, E., Di Vimercati, S. D. C., & Samarati, P. (2007). Location Privacy Protection Through Obfuscation-based Techniques." (PDF) In Data and Applications Security XXI (pp. 47-60). Springer Berlin Heidelberg.
- Brush, A. J., John Krumm, and James Scott. "Exploring end user preferences for location obfuscation, location-based services, and the value of location."Proceedings of the 12th ACM international conference on Ubiquitous computing. ACM, 2010.
- Henne, Benjamin, et al. "Selective cloaking: Need-to-know for location-based apps." Privacy, Security and Trust (PST), 2013 Eleventh Annual International Conference on. IEEE, 2013.
- Bordenabe, Nicolás E., Konstantinos Chatzikokolakis, and Catuscia Palamidessi. "Optimal Geo-Indistinguishable Mechanisms for Location Privacy."arXiv preprint arXiv:1402.5029 (2014).
"It is hardly possible to overrate the value...of placing human beings in contact with persons dissimilar to themselves, and with modes of thought and action unlike those with which they are familiar....Such communication has always been, and is [particularly] in the present age, one of the primary sources of progress."
John Stuart Mill,
Principles of Political Economy, 1848
John Stuart Mill,
Principles of Political Economy, 1848
Generating keys and CSR requests for your Public Key Infrastructure (PKI) needs is tedious and annoying without proper tools. Remembering openssl commands and syntax requires a constant visit to the man page or the googles. So what does any good geek do when faced with a repetitive problem? They write a script or download a tool. I wrote a script because I love reinventing the wheel.
The script below (after the jump) creates a customized openssl config file and generates private keys and CSRs. The input to the script is a flat file with either FQDNs, email addresses, or whatever your want that is plugged into the Common Name field of the key/CSR. The script is nothing more than a glorified for loop that helps reduce errors and ensures consistency across a large key base.
This can be really useful when setting up EAP-TLS for your WiFi or other device authentication.
Please leave any feedback you may have in the comments.