Information Security & Occasional Forays Into Adjacent Realms
via Sara Sorcher, writing at the Christian Science Monitor, for the Monitor's new Passcode department, comes the story of Plan X, the Defense Advanced Research Projects Agency's (DARPA) push into proper management of the cyberwar battlespace.
"They exposed weaknesses in the armor, illustrating that "we as scientists and engineers think we have a great solution and ha-ha moments, thinking Soldiers will love this" new piece of gear. Then the Red Team would show up and show all the weaknesses, she said, so "we started solving those problems." From that point on, anything deployed to small forward operating outposts of 300 people or less gets a Red Team going over from "the construct of the operational perspective, technology perspective, and how we could integrate it in such a way not to create inherent vulnerabilities. It's been very effective." - via David Vergun writing at the United States Army
News, via The Washington Post's Ashley Halsey III of significant information security issues at the Federal Aviation Agency. In this case, the Government Accountability Office has published a new report entitled "FAA Needs to Address Weaknesses in Air Traffic Control Systems", detailing significant shortcomings in the agency's capability to fend off electronic attacks.
The GAO report facts speak volumes: The FAA has failed to fully implement the planned, 'agency-wide' information security program. The failure to implement and deploy is a tell-tale of questionable competency within the Agency's information security management, whose duty and primary task is protecting the National Airspace System (aka NAS), of which, should be the core competency of the FAA.
Time for a change at the FAA? Probably, however, the issue of foot-dragging is deeply systemic at the Agency, witness the multi-year effort to implement the FAA's Next Generation Air Transportation System (aka NextGen). Any change will most likely be accomplished over decades, rather than single digit years... After all, thirteen years post-FISMA and the Agency has not yet implemented and deployed the mandated FISMA requirements, is, in a word - astonishing.
Now, focusing on the issues, we turn to the GAO discovered chllanges the FAA faces (of which, a statement from the GAO appears below, and is a direct excerpt from the published report. Read it, my fellow citizens, and weep.
"While the Federal Aviation Administration (FAA) has taken steps to protect its air traffic control systems from cyber-based and other threats, significant security control weaknesses remain, threatening the agency's ability to ensure the safe and uninterrupted operation of the national airspace system (NAS). These include weaknesses in controls intended to prevent, limit, and detect unauthorized access to computer resources, such as controls for protecting system boundaries, identifying and authenticating users, authorizing users to access systems, encrypting sensitive data, and auditing and monitoring activity on FAA's systems. Additionally, shortcomings in boundary protection controls between less-secure systems and the operational NAS environment increase the risk from these weaknesses.
FAA also did not fully implement its agency-wide information security program. As required by the Federal Information Security Management Act of 2002, federal agencies should implement a security program that provides a framework for implementing controls at the agency. However, FAA's implementation of its security program was incomplete. For example, it did not always sufficiently test security controls to determine that they were operating as intended; resolve identified security weaknesses in a timely fashion; or complete or adequately test plans for restoring system operations in the event of a disruption or disaster. Additionally, the group responsible for incident detection and response for NAS systems did not have sufficient access to security logs or network sensors on the operational network, limiting FAA's ability to detect and respond to security incidents affecting its mission-critical systems.
The weaknesses in FAA's security controls and implementation of its security program existed, in part, because FAA had not fully established an integrated, organization-wide approach to managing information security risk that is aligned with its mission. National Institute of Standards and Technology guidance calls for agencies to establish and implement a security governance structure, an executive-level risk management function, and a risk management strategy in order to manage risk to their systems and information. FAA has established a Cyber Security Steering Committee to provide an agency-wide risk management function. However, it has not fully established the governance structure and practices to ensure that its information security decisions are aligned with its mission. For example, it has not (1) clearly established roles and responsibilities for information security for the NAS or (2) updated its information security strategic plan to reflect significant changes in the NAS environment, such as increased reliance on computer networks.
Until FAA effectively implements security controls, establishes stronger agency-wide information security risk management processes, fully implements its NAS information security program, and ensures that remedial actions are addressed in a timely manner, the weaknesses GAO identified are likely to continue, placing the safe and uninterrupted operation of the nation's air traffic control system at increased and unnecessary risk." via the United States Government Accountablity Office Report "FAA Needs to Address Weaknesses in Air Traffic Control Systems"
NIST, the National Institute of Standards and Technology, has released a new internal report targeting replication device risk management (Replication devices reproduce images, objects or documents from an electronic or physical source, et cetera).
Entitled NIST Internal Report 8023 Risk Management for Replication Devices, the report provides clear and correct guidance to establish in-house methods, policies and procedures in the effort to provision the data stored within replication systems using the well-used infosecurity triad (Confidentiality, Integrity and Availability) as a baseline.
Replication devices are the perfect example of the so-called 'soft-underbelly' in many (if not all) organizations. These systems are quite often utilized for intelligence gathering activities due to on-board storage and other facilities that enable footprinting of historical data, thereby establishing timelines, and of course, all important raw data to accompany those timelines.
In what may prove to be the most controversial presidential executive order this year, President Obama has signed 'Executive Order -- Promoting Private Sector Cybersecurity Information Sharing'; in which, the President authorizes the creation of another, so-called ISAO [Information Sharing and Analysis Organizations (ISAOs) {similar to the NCCIC and others}]. The Order appears below:
Executive Order -- Promoting Private Sector Cybersecurity Information Sharing
EXECUTIVE ORDER
PROMOTING PRIVATE SECTOR CYBERSECURITY INFORMATION SHARING
By the authority vested in me as President by the Constitution and the laws of the United States of America, it is hereby ordered as follows:
Section 1. Policy. In order to address cyber threats to public health and safety, national security, and economic security of the United States, private companies, nonprofit organizations, executive departments and agencies (agencies), and other entities must be able to share information related to cybersecurity risks and incidents and collaborate to respond in as close to real time as possible.
Organizations engaged in the sharing of information related to cybersecurity risks and incidents play an invaluable role in the collective cybersecurity of the United States. The purpose of this order is to encourage the voluntary formation of such organizations, to establish mechanisms to continually improve the capabilities and functions of these organizations, and to better allow these organizations to partner with the Federal Government on a voluntary basis.
Such information sharing must be conducted in a manner that protects the privacy and civil liberties of individuals, that preserves business confidentiality, that safeguards the information being shared, and that protects the ability of the Government to detect, investigate, prevent, and respond to cyber threats to the public health and safety, national security, and economic security of the United States.
This order builds upon the foundation established by Executive Order 13636 of February 12, 2013 (Improving Critical Infrastructure Cybersecurity), and Presidential Policy Directive-21 (PPD-21) of February 12, 2013 (Critical Infrastructure Security and Resilience).
Policy coordination, guidance, dispute resolution, and periodic in-progress reviews for the functions and programs described and assigned herein shall be provided through the interagency process established in Presidential Policy Directive-l (PPD-l) of February 13, 2009 (Organization of the National Security Council System), or any successor.
Sec. 2. Information Sharing and Analysis Organizations. (a) The Secretary of Homeland Security (Secretary) shall strongly encourage the development and formation of Information Sharing and Analysis Organizations (ISAOs).
(b) ISAOs may be organized on the basis of sector, sub-sector, region, or any other affinity, including in response to particular emerging threats or vulnerabilities. ISAO membership may be drawn from the public or private sectors, or consist of a combination of public and private sector organizations. ISAOs may be formed as for-profit or nonprofit entities.
(c) The National Cybersecurity and Communications Integration Center (NCCIC), established under section 226(b) of the Homeland Security Act of 2002 (the "Act"), shall engage in continuous, collaborative, and inclusive coordination with ISAOs on the sharing of information related to cybersecurity risks and incidents, addressing such risks and incidents, and strengthening information security systems consistent with sections 212 and 226 of the Act.
(d) In promoting the formation of ISAOs, the Secretary shall consult with other Federal entities responsible for conducting cybersecurity activities, including Sector-Specific Agencies, independent regulatory agencies at their discretion, and national security and law enforcement agencies.
Sec. 3. ISAO Standards Organization. (a) The Secretary, in consultation with other Federal entities responsible for conducting cybersecurity and related activities, shall, through an open and competitive process, enter into an agreement with a nongovernmental organization to serve as the ISAO Standards Organization (SO), which shall identify a common set of voluntary standards or guidelines for the creation and functioning of ISAOs under this order. The standards shall further the goal of creating robust information sharing related to cybersecurity risks and incidents with ISAOs and among ISAOs to create deeper and broader networks of information sharing nationally, and to foster the development and adoption of automated mechanisms for the sharing of information. The standards will address the baseline capabilities that ISAOs under this order should possess and be able to demonstrate. These standards shall address, but not be limited to, contractual agreements, business processes, operating procedures, technical means, and privacy protections, such as minimization, for ISAO operation and ISAO member participation.
(b) To be selected, the SO must demonstrate the ability to engage and work across the broad community of organizations engaged in sharing information related to cybersecurity risks and incidents, including ISAOs, and associations and private companies engaged in information sharing in support of their customers.
(c) The agreement referenced in section 3(a) shall require that the SO engage in an open public review and comment process for the development of the standards referenced above, soliciting the viewpoints of existing entities engaged in sharing information related to cybersecurity risks and incidents, owners and operators of critical infrastructure, relevant agencies, and other public and private sector stakeholders.
(d) The Secretary shall support the development of these standards and, in carrying out the requirements set forth in this section, shall consult with the Office of Management and Budget, the National Institute of Standards and Technology in the Department of Commerce, Department of Justice, the Information Security Oversight Office in the National Archives and Records Administration, the Office of the Director of National Intelligence, Sector-Specific Agencies, and other interested Federal entities. All standards shall be consistent with voluntary international standards when such international standards will advance the objectives of this order, and shall meet the requirements of the National Technology Transfer and Advancement Act of 1995 (Public Law 104-113), and OMB Circular A-119, as revised.
Sec. 4. Critical Infrastructure Protection Program. (a) Pursuant to sections 213 and 214(h) of the Critical Infrastructure Information Act of 2002, I hereby designate the NCCIC as a critical infrastructure protection program and delegate to it authority to enter into voluntary agreements with ISAOs in order to promote critical infrastructure security with respect to cybersecurity.
(b) Other Federal entities responsible for conducting cybersecurity and related activities to address threats to the public health and safety, national security, and economic security, consistent with the objectives of this order, may participate in activities under these agreements.
(c) The Secretary will determine the eligibility of ISAOs and their members for any necessary facility or personnel security clearances associated with voluntary agreements in accordance with Executive Order 13549 of August 18, 2010 (Classified National Security Information Programs for State, Local, Tribal, and Private Sector Entities), and Executive Order 12829 of January 6, 1993 (National Industrial Security Program), as amended, including as amended by this order.
Sec. 5. Privacy and Civil Liberties Protections. (a) Agencies shall coordinate their activities under this order with their senior agency officials for privacy and civil liberties and ensure that appropriate protections for privacy and civil liberties are incorporated into such activities. Such protections shall be based upon the Fair Information Practice Principles and other privacy and civil liberties policies, principles, and frameworks as they apply to each agency's activities.
(b) Senior privacy and civil liberties officials for agencies engaged in activities under this order shall conduct assessments of their agency's activities and provide those assessments to the Department of Homeland Security (DHS) Chief Privacy Officer and the DHS Office for Civil Rights and Civil Liberties for consideration and inclusion in the Privacy and Civil Liberties Assessment report required under Executive Order 13636.
Sec. 6. National Industrial Security Program. Executive Order 12829, as amended, is hereby further amended as follows:
(a) the second paragraph is amended by inserting "the Intelligence Reform and Terrorism Prevention Act of 2004," after "the National Security Act of 1947, as amended,";
(b) Sec. 101(b) is amended to read as follows: "The National Industrial Security Program shall provide for the protection of information classified pursuant to Executive Order 13526 of December 29, 2009, or any predecessor or successor order, and the Atomic Energy Act of 1954, as amended (42 U.S.C. 2011 et seq.).";
(c) Sec. 102(b) is amended by replacing the first paragraph with: "In consultation with the National Security Advisor, the Director of the Information Security Oversight Office, in accordance with Executive Order 13526 of December 29, 2009, shall be responsible for implementing and monitoring the National Industrial Security Program and shall:";
(d) Sec. 102(c) is amended to read as follows: "Nothing in this order shall be construed to supersede the authority of the Secretary of Energy or the Nuclear Regulatory Commission under the Atomic Energy Act of 1954, as amended (42 U.S.C. 2011 et seq.), or the authority of the Director of National Intelligence (or any Intelligence Community element) under the Intelligence Reform and Terrorism Prevention Act of 2004, the National Security Act of 1947, as amended, or Executive Order 12333 of December 8, 1981, as amended, or the authority of the Secretary of Homeland Security, as the Executive Agent for the Classified National Security Information Program established under Executive Order 13549 of August 18, 2010 (Classified National Security Information Program for State, Local, Tribal, and Private Sector Entities).";
(e) Sec. 201(a) is amended to read as follows: "The Secretary of Defense, in consultation with all affected agencies and with the concurrence of the Secretary of Energy, the Nuclear Regulatory Commission, the Director of National Intelligence, and the Secretary of Homeland Security, shall issue and maintain a National Industrial Security Program Operating Manual (Manual). The Secretary of Energy and the Nuclear Regulatory Commission shall prescribe and issue that portion of the Manual that pertains to information classified under the Atomic Energy Act of 1954, as amended (42 U.S.C. 2011 et seq.). The Director of National Intelligence shall prescribe and issue that portion of the Manual that pertains to intelligence sources and methods, including Sensitive Compartmented Information. The Secretary of Homeland Security shall prescribe and issue that portion of the Manual that pertains to classified information shared under a designated critical infrastructure protection program.";
(f) Sec. 201(f) is deleted in its entirety;
(g) Sec. 201(e) is redesignated Sec. 201(f) and revised by substituting "Executive Order 13526 of December 29, 2009, or any successor order," for "Executive Order No. 12356 of April 2, 1982.";
(h) Sec. 201(d) is redesignated Sec. 201(e) and revised by substituting "the Director of National Intelligence, and the Secretary of Homeland Security" for "and the Director of Central Intelligence.";
(i) a new Sec. 201(d) is inserted after Sec. 201(c) to read as follows: "The Manual shall also prescribe arrangements necessary to permit and enable secure sharing of classified information under a designated critical infrastructure protection program to such authorized individuals and organizations as determined by the Secretary of Homeland Security.";
(j) Sec. 202(b) is amended to read as follows: "The Director of National Intelligence retains authority over access to intelligence sources and methods, including Sensitive Compartmented Information. The Director of National Intelligence may inspect and monitor contractor, licensee, and grantee programs and facilities that involve access to such information or may enter into written agreements with the Secretary of Defense, as Executive Agent, or with the Director of the Central Intelligence Agency to inspect and monitor these programs or facilities, in whole or in part, on the Director's behalf.";
(k) Sec. 202(d) is redesignated as Sec. 202(e); and
(l) in Sec. 202 a new subsection (d) is inserted after subsection (c) to read as follows: "The Secretary of Homeland Security may determine the eligibility for access to Classified National Security Information of contractors, licensees, and grantees and their respective employees under a designated critical infrastructure protection program, including parties to agreements with such program; the Secretary of Homeland Security may inspect and monitor contractor, licensee, and grantee programs and facilities or may enter into written agreements with the Secretary of Defense, as Executive Agent, or with the Director of the Central Intelligence Agency, to inspect and monitor these programs or facilities in whole or in part, on behalf of the Secretary of Homeland Security."
Sec. 7. Definitions. (a) "Critical infrastructure information" has the meaning given the term in section 212(3) of the Critical Infrastructure Information Act of 2002.
(b) "Critical infrastructure protection program" has the meaning given the term in section 212(4) of the Critical Infrastructure Information Act of 2002.
(c) "Cybersecurity risk" has the meaning given the term in section 226(a)(1) of the Homeland Security Act of 2002 (as amended by the National Cybersecurity Protection Act of 2014).
(d) "Fair Information Practice Principles" means the eight principles set forth in Appendix A of the National Strategy for Trusted Identities in Cyberspace.
(e) "Incident" has the meaning given the term in section 226(a)(2) of the Homeland Security Act of 2002 (as amended by the National Cybersecurity Protection Act of 2014).
(f) "Information Sharing and Analysis Organization" has the meaning given the term in section 212(5) of the Critical Infrastrucure Information Act of 2002.
(g) "Sector-Specific Agency" has the meaning given the term in PPD-21, or any successor.
Sec. 8. General Provisions. (a) Nothing in this order shall be construed to impair or otherwise affect:
(i) the authority granted by law or Executive Order to an agency, or the head thereof; or
(ii) the functions of the Director of the Office of Management and Budget relating to budgetary, administrative, or legislative proposals.
(b) This order shall be implemented consistent with applicable law and subject to the availability of appropriations. Nothing in this order shall be construed to alter or limit any authority or responsibility of an agency under existing law including those activities conducted with the private sector relating to criminal and national security threats. Nothing in this order shall be construed to provide an agency with authority for regulating the security of critical infrastructure in addition to or to a greater extent than the authority the agency has under existing law.
(c) All actions taken pursuant to this order shall be consistent with requirements and authorities to protect intelligence and law enforcement sources and methods.
(d) This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.
BARACK OBAMA
Meanwhile, news of the creation of a new United States Agency is brightening some security professionals view of information sharing capabilities inter- and intra- government. Created in the likeness of the National Counterterrorism Center [itself created post 9/11 in the wake of information sharing failures within [and obviously without] the federal civilian government & the military]. Monikered the Cyber Threat Intelligence Integration Center, it will ostensibly function as the defacto repository for existing 'cyber' operations/intelligence facilities government-wide, and will facilitate information sharing and decision making capabilities [more, below].
"The CTIIC will focus on four priorities:
- via the Federal Times
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
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
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
"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.
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.
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
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.
[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/
ENISA, the European Union Agency for Network and Information Security has published the agency's yearly Threat Landscape Report 2014 [PDF, 3,335 KB) analysis. Today's' Must Read.
via Rapid7's HD Moore, comes news of the latest flaw in the Internet of Things realm, this time, focusing on the fueling infrastructure worldwide. Specifically, the gauges that meter and permit the dispensing of liquid and gaseous matériel... Evidently, these automated tank gauges (monikered ATGs) not only possess IP connectivity, but they also have tremendously flawed software componentry to boot. What Could Possibly Go Wrong.
If you read anything today about cryptography today, read the work of Stanford University's Center for Internet and Society's Jeffrey Vagle, JD [Mr. Vagle is also a Lecturer in Law and the Executive Director of the Center for Technology, Innovation and Competition [CTIC] at the University of Pennsylvania Law School]; in which, Mr. Vagle examines the criminalization of cryptography [snippet of his work appears below].
'We've heard this story from governments before, of course, from the "crypto wars" of the early 1990s to recent claims by the FBI that encryption allows networks to "go dark," and prevent legitimate law enforcement efforts. But as the leaked security memo asserts, without strong crypto and secure networks, we're all put at greater risk. It is crucial that we keep this in perspective as the world's legislative bodies rush to do something--anything--in the face of these crises.' - via Jeffrey Vagle writing at the Center for Internet and Society, at Stanford University
News via The Independents' Whitehall editor Oliver Wright, of an innovative plan to engage recent graduates in the United Kingdom, by the United Kingdoms' Government Communications Headquarters. Something of a mashup is being mulled over, between serving in the ranks of GCHQ with an eye for opportunities further on down the line, when it's time to muster out. A similar model is in place for many Israeli military and intelligence personnel, post-service.
Or, what comes after the nations-state construct? In this case, if one is to take a gander at the future, through the discerning eye of futurist Thomas Frey, something akin to a fractal geometry, applied to the notion of governance...
Ah, news outlets are reporting evidence release by the United States Department of Justice's Federal Bureau of Investigation; in this case detailing DPRK complicit activity in the now infamous SONY hack...
Today's MustRead: Well crafted thought piece via LightCyber's Uriel Maimon on the multitude of failures in the network protection racket, and why - evidently - security and network professionals are unable to protect their at-risk network infrastructures.
Illustrating exactly why, Cyber Ranges are vitally important for training. After all, you will fight like you train.
Once again, Kim Zetters' superlative prose details the astounding story of Stuxnet; this time, in a new book titled 'Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon' [published by Crown Publishing Group a division of Random House]. Apparently, like many other 'infections' the vector [in this case] is the order-of-the-day... This month's MustRead.