EFF Analyzes Secure Messaging
The Electronic Frontier Foundation has published an interesting look at secure messaging, as it exists today, including a super-handy scorecard. Yay!
Project West Ford →
Judah Levine, Time Lord
Mobile Telephony, First Cut Is The Deepest
Apparently, the United States Supreme Court has been asked (via Petition) to weigh-in on the Department of Homeland Security's Standard Operating Procedure 303, originally developed by the National Security Telecommunications Advisory Committee. My take on it - Not Going To Happen.
Use of Secret Communications is an "Ancient Liberty"
Presented for your consideration - a 1997 paper entitled The Use of Encrypted, Coded and Secret Communications is an "Ancient Liberty" Protected by the United States Constitution, published by the University of Virginia Journal of Law and Technology]*.
John Fraser III the author of this superlative screed (now an attorney in Washington, DC) presents his fascinating argument on encryption, and the 'ancient right' to utilize cryptographic artifacts in the course of communications, protected, of course, by our nations' Constitution. Today's Must Read.
*Va. J.L. & Tech. 2 Fall 1997 1522-1687 / © 1997 Virginia Journal of Law and Technology Association
Le Bots Émerger →
La Fin de Twitter est Proche, otherwise known as The End of Twitter, Inc. (NasdaqGS: TWTR) is Near... via The Harvard Business Review, and written by Alexandera Samuel, comes this tell-all on the rise of 'bots infecting Twitter, and not necessarily the 'bots you may think. Entitled "How Bots Took Over Twitter". Congratulations, you have discovered Today's Must Read.
IC3 Issues LEO Warning, Targeted 'Cyber' Attacks Against Public Officials
The Internet Crime Complaint Center (IC3) has published a warning focusing on Law Enforcement Officers (and other LEO personnel including family members). The warning explicitly states Law Enforcement Officers, personnel and public officials are at an increased risk of cyber related attacks, due to attacks committed by so-called Hactiviists; primarily focused at this time on the act of DOXING, see the etymology of Doxing here). The full text of IC3 Alert Number I-042115-PSA appears below:
Hacktivists Threaten to Target Law Enforcement Personnel and Public Officials
Summary
Law enforcement personnel and public officials may be at an increased risk of cyber attacks. These attacks can be precipitated by someone scanning networks or opening infected emails containing malicious attachments or links. Hacking collectives are effective at leveraging open source, publicly available information identifying officers, their employers, and their families. With this in mind, officers and public officials should be aware of their online presence and exposure. For example, posting images wearing uniforms displaying name tags or listing their police department on social media sites can increase an officer's risk of being targeted or attacked.
Many legitimate online posts are linked directly to personal social media accounts. Law enforcement personnel and public officials need to maintain an enhanced awareness of the content they post and how it may reflect on themselves, their family, their employer or how it could be used against them in court or during online attacks.
Threat
The act of compiling and posting an individual's personal information without permission is known as doxing. The personal information gathered from social media and other Web sites could include home addresses, phone numbers, email addresses, passwords and any other information used to target an individual during a cyber attack. The information is then posted on information sharing Web sites with details suggesting why the individual should be targeted.
Recent activity suggests family members of law enforcement personnel and public officials are also at risk for cyber attacks and doxing activity. Targeted information may include personally identifiable information and public information and pictures from social media Web sites.
Another dangerous attack often used by criminals is known as “swatting.” This involves calling law enforcement authorities to report a hostage situation or other critical incident at the victim's residence, when there is no emergency situation.
Defense
Defending Against Hacktivism
While eliminating your exposure in the current digital age is nearly impossible, law enforcement and public officials can take steps to minimize their risk in the event they are targeted.
Turn on all privacy settings on social media sites and refrain from posting pictures showing your affiliation to law enforcement.
Be aware of your security settings on your home computers and wireless networks.
Limit your personal postings on media sites and carefully consider comments.
Restrict your driver license and vehicle registration information with the Department of Motor Vehicles.
Request real estate and personal property records be restricted from online searches with your specific county.
Routinely update hardware and software applications, including antivirus.
Pay close attention to all work and personal emails, especially those containing attachments or links to other Web sites. These suspicious or phishing emails may contain infected attachments or links.
Routinely conduct online searches of your name to identify what public information is already available.
Enable additional email security measures to include two factor authentication on your personal email accounts. This is a security feature offered by many email providers. The feature will cause a text message to be sent to your mobile device prior to accessing your email account.
Closely monitor your credit and banking activity for fraudulent activity.
Passwords should be changed regularly. It is recommended to use a password phrase of 15 characters or more. Example of a password phrase: Thisisthemonthofseptember,2014.
Be aware of pretext or suspicious phone calls or emails from people phishing for information or pretending to know you. Social engineering is a skill often used to trick you into divulging confidential information and continues to be an extremely effective method for criminals.
Advise family members to turn on security settings on ALL social media accounts. Family member associations are public information and family members can become online targets of opportunity.
The RAM House by PROKOSS + Space Caviar
Faraday Home
The ulitmate whole-house signal-attenuation device.... Behold, the Faraday Home, perfect for the paranoid amongst us; or those that suffer from idiopathic environmental intolerance attributed to electromagnetic fields (IEI-EMF).
FCC Issues Net Neutrality Order Document →
The Federal Communications Commission has issued the codified order targeting Net Neutrality. Entitled FCC 15-24*, for GN Docket Number 14-28, In the Matter of Protecting and Promoting the Open Internet, Report and Order on Remand, Declaratory Ruling, and Order. At over *Four hundred pages long*, this document will (likely) become one of the most highly contentious Orders emerging this year (or the weapon of choice for conspiracy theorists due to it's weight*) from the Commission.
NIST Announces New Internal Report Targeting Smart Metering →
The National Institute of Standards and Technology (NIST) has announced a new internal report detailing a framework targeting Smart Meter Upgradability (NIST Internal Report NISTIR 7823), Advanced Metering Infrastructure Smart Meter Upgradeability Test Framework). Authored by Michaela Iorga (a member of the Computer Security Division, in the Information Technology Laboratory (ITL) at NIST) and Scott Shorter (of Electrosoft Services, Inc. in Reston, Virgina), the document is also available at the International DOI System under NIST.IR.7823.
I reckon the document's abstract sums it up quite nicely:
"As electric utilities turn to Advanced Metering Infrastructures (AMIs) to promote the development and deployment of the Smart Grid, one aspect that can benefit from standardization is the upgradeability of Smart Meters. The National Electrical Manufacturers Association (NEMA) standard SG-AMI 1-2009, “Requirements for Smart Meter Upgradeability,” describes functional and security requirements for the secure upgrade—both local and remote—of Smart Meters. This report describes conformance test requirements that may be used voluntarily by testers and/or test laboratories to determine whether Smart Meters and Upgrade Management Systems conform to the requirements of NEMA SG-AMI 1-2009. For each relevant requirement in NEMA SG-AMI 1-2009, the document identifies the information to be provided by the vendor to facilitate testing, and the high-level test procedures to be conducted by the tester/laboratory to determine conformance." - via NIST IR 7823
Meanwhile, you can also track, examine and attempt to contain your surprise at the latest, recognized industiral control systems & supervisory control and data acquisition systems vulnerabilities from our colleagues st US-CERT, here.
Mythos of IPv6, It's Too New to be Attacked... →
More IPV6 myths exposed by ISOC's Deploy360 Director Chris Grundemann. This time focusing on the myth that IPv6 is too new to be attacked. Today's MustRead!
Net Neutrality Doomed? →
via Jeff Hecht, writing at the IEEE's Spectrum Magazine, notes the fundamental issues with the interwebs may not be oversight, policy or warring leviathan corporate monstrosities. It, that is, Network Neutrality, may be doomed from a technical perspective... Read it and Weep.
Redefining 'Unlimited' Suddenly Becomes Quite Expensive →
IPv6 Security Myth: No NAT Means No Security
Astoundingly, myths still arise in this epoch of science, strangely so, when dealing with new technologies [Read: new means new in the final two years of the last century as IPv4 was originally codified by the IETF in 1981, with the acceptance of RFC 791] - in this case the vaunted move to IPv6. Now, arising from the ashes of IPv4 exhaustion hysteria, comes a current popular myth surrounds the utilization NATs in IPv4 and the lack of a counterpart construct in IPv6.
IETF RFC 7258, Pervasive Monitoring Is An Attack →
Quite likely, the most important document published this week on Infosecurity.US, now over a half-year old, [released during the month of May, 2014]. In accordance with the IETF Trust's Legal Provisions relating to IETF Documents in effect on the date of publication of this document, this RFC is published in it's entirety, without modification. Further information and Feedback opportunities can be found at the RFC Editor / RFC Database. The following information is the accurate content of RFC 7258. Enjoy!
###
BEST CURRENT PRACTICE
Internet Engineering Task Force (IETF) S. Farrell Request for Comments: 7258 Trinity College Dublin BCP: 188 H. Tschofenig Category: Best Current Practice ARM Ltd. ISSN: 2070-1721 May 2014
Pervasive Monitoring Is an Attack
Abstract Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7258. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Farrell & Tschofenig Best Current Practice [Page 1]
RFC 7258 Pervasive Monitoring Is an Attack May 2014
1. Pervasive Monitoring Is a Widespread Attack on Privacy
Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise. The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community's consensus and establishes the technical nature of PM. The term "attack" is used here in a technical sense that differs somewhat from common English usage. In common English usage, an attack is an aggressive action perpetrated by an opponent, intended to enforce the opponent's will on the attacked party. The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator. [RFC4949] contains a more complete definition for the term "attack". We also use the term in the singular here, even though PM in reality may consist of a multifaceted set of coordinated attacks. In particular, the term "attack", used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols. Farrell & Tschofenig Best Current Practice [Page 2] RFC 7258 Pervasive Monitoring Is an Attack May 2014
2. The IETF Will Work to Mitigate Pervasive Monitoring
"Mitigation" is a technical term that does not imply an ability to completely prevent or thwart an attack. Protocols that mitigate PM will not prevent the attack but can significantly change the threat. (See the diagram on page 24 of RFC 4949 for how the terms "attack" and "threat" are related.) This can significantly increase the cost of attacking, force what was covert to be overt, or make the attack more likely to be detected, possibly later. IETF standards already provide mechanisms to protect Internet communications and there are guidelines [RFC3552] for applying these in protocol design. But those standards generally do not address PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation. In all cases, there will remain some privacy-relevant information that is inevitably disclosed by protocols. As technology advances, techniques that were once only available to extremely well-funded actors become more widely accessible. Mitigating PM is therefore a protection against a wide range of similar attacks. It is therefore timely to revisit the security and privacy properties of our standards. The IETF will work to mitigate the technical aspects of PM, just as we do for protocol vulnerabilities in general. The ways in which IETF protocols mitigate PM will change over time as mitigation and attack techniques evolve and so are not described here. Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?" In particular, architectural decisions, including which existing technology is reused, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making architectural decisions. Getting adequate, early review of architectural decisions including whether appropriate mitigation of PM can be made is important. Revisiting these architectural decisions late in the process is very costly. While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam Farrell & Tschofenig Best Current Practice [Page 3]
RFC 7258 Pervasive Monitoring Is an Attack May 2014 mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered. Finally, the IETF, as a standards development organisation, does not control the implementation or deployment of our specifications (though IETF participants do develop many implementations), nor does the IETF standardise all layers of the protocol stack. Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF. The broader Internet community will need to step forward to tackle PM, if it is to be fully addressed. To summarise: current capabilities permit some actors to monitor content and metadata across the Internet at a scale never before seen. This pervasive monitoring is an attack on Internet privacy. The IETF will strive to produce specifications that mitigate pervasive monitoring attacks.
3. Process Note
In the past, architectural statements of this sort, e.g., [RFC1984] and [RFC2804], have been published as joint products of the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB). However, since those documents were published, the IETF and IAB have separated their publication "streams" as described in [RFC4844] and [RFC5741]. This document was initiated after discussions in both the IESG and IAB, but is published as an IETF- stream consensus document, in order to ensure that it properly reflects the consensus of the IETF community as a whole.
4. Security Considerations
This document is entirely about privacy. More information about the relationship between security and privacy threats can be found in [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses surveillance as a combined security-privacy threat. Farrell & Tschofenig Best Current Practice [Page 4]
RFC 7258 Pervasive Monitoring Is an Attack May 2014
5. Acknowledgements
We would like to thank the participants of the IETF 88 technical plenary for their feedback. Thanks in particular to the following for useful suggestions or comments: Jari Arkko, Fred Baker, Marc Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Phillip Hallam-Baker, Ted Hardie, Sam Hartmann, Paul Hoffman, Bjoern Hoehrmann, Russ Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan Winter, and Lloyd Wood. Additionally, we would like to thank all those who contributed suggestions on how to improve Internet security and privacy or who commented on this on various IETF mailing lists, such as the ietf@ietf.org and the perpass@ietf.org lists.
6. Informative References
[IETF88Plenary] IETF, "IETF 88 Plenary Meeting Materials", November 2013, <http://www.ietf.org/proceedings/88/>. [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013 Farrell & Tschofenig Best Current Practice [Page 5]
RFC 7258 Pervasive Monitoring Is an Attack May 2014 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. Authors' Addresses Stephen Farrell Trinity College Dublin Dublin 2 Ireland Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie Hannes Tschofenig ARM Ltd. 6060 Hall in Tirol Austria EMail: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at Farrell & Tschofenig Best Current Practice [Page 6] Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/
NTP Reflection DDoS at 400Gbps →
News, via John Dunn at Techworld, of what is being characterized as the most powerful (in terms of throughput) DDoS attack on record; this time, clocked at 400GBps, and identified as last year's NTP Reflection Vulnerability.
Securosis' Toddle
In an outstanding video piece, the Gentlemen of Securosis contemplate the apparent second childhood of Goggle, Inc. (NasdaqGS: GOOG) and Microsoft Corporation (NasdaqGS: MSFT).
Kim's Big Secret →
An End-to-End Encrypted Secret, that is...