DOCSLIB.ORG

Draft NIST Special Publication 800-177, Trustworthy Email

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Draft NIST Special Publication 800-177, Trustworthy Email This (First) DRAFT of Special Publication 800-177 document has been superceded by the following draft publication: The first draft has been attached for HISTORICAL PURPOSE – PLEASE refer to the Second Draft (see details below): Publication Number: Second Draft Special Publication 800-177 Title: Trustworthy Email Publication Date: March 2016 Second Draft Publication: http://csrc.nist.gov/publications/PubsDrafts.html#800-177 Information on other publications: http://csrc.nist.gov/publications/ The following information was posted with the attached DRAFT document: NIST requests comments on the second draft of Special Publication (SP) 800-177, Trustworthy Email. This draft is a complimentary guide to NIST SP 800-45 Guidelines on Electronic Mail Security and covers protocol security technologies to secure email transactions. This draft guide includes recommendations for the deployment of domain-based authentication protocols for email as well as end-to-end cryptographic protection for email contents. Technologies recommended in support of core Simple Mail Transfer Protocol (SMTP) and the Domain Name System (DNS) include mechanisms for authenticating a sending domain (Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM) and Domain based Message Authentication, Reporting and Conformance (DMARC). Email content security is facilitated through encryption and authentication of message content using S/MIME and/or Transport Layer Security (TLS) with SMTP. This guide is written for the federal agency email administrator, information security specialists and network managers, but contains general recommendations for all enterprise email administrators. The public comment period April 29th, 2016. Email comments [email protected] 1 DRAFT NIST Special Publication 800-177 2 Trustworthy Email 3 4 5 Ramaswamy Chandramouli 6 Simson Garfinkel 7 Stephen Nightingale 8 Scott Rose 9 10 11 12 13 14 15 16 17 18 19 C O M P U T E R S E C U R I T Y 20 21 22 DRAFT NIST Special Publication 800-177 23 Trustworthy Email 24 25 Scott Rose, Stephen Nightingale 26 Information Technology Laboratory 27 Advanced Network Technology Division 28 29 Simson L. Garfinkel 30 Information Technology Laboratory 31 Information Access Division 32 33 Ramaswamy Chandramouli 34 Information Technology Laboratory 35 Computer Security Division 36 37 38 39 40 41 42 43 September 2015 44 45 46 47 48 49 U.S. Department of Commerce 50 Penny Pritzker, Secretary 51 52 National Institute of Standards and Technology 53 Willie May, Under Secretary of Commerce for Standards and Technology and Director 54 Authority 55 This publication has been developed by NIST in accordance with its statutory responsibilities under the 56 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law 57 (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, 58 including minimum requirements for federal information systems, but such standards and guidelines shall 59 not apply to national security systems without the express approval of appropriate federal officials 60 exercising policy authority over such systems. This guideline is consistent with the requirements of the 61 Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information 62 Systems, as analyzed in Circular A-130, Appendix IV: Analysis of Key Sections. Supplemental 63 information is provided in Circular A-130, Appendix III, Security of Federal Automated Information 64 Resources. 65 Nothing in this publication should be taken to contradict the standards and guidelines made mandatory 66 and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should 67 these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of 68 Commerce, Director of the OMB, or any other federal official. This publication may be used by 69 nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. 70 Attribution would, however, be appreciated by NIST. 71 National Institute of Standards and Technology Special Publication 800-177 72 Natl. Inst. Stand. Technol. Spec. Publ. 800-177, 87 pages (September 2015) 73 CODEN: NSPUE2 74 This publication is available free of charge 75 76 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 77 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 78 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best 79 available for the purpose. 80 There may be references in this publication to other publications currently under development by NIST in 81 accordance with its assigned statutory responsibilities. The information in this publication, including concepts and 82 methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, 83 until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain 84 operative. For planning and transition purposes, federal agencies may wish to closely follow the development of 85 these new publications by NIST. 86 Organizations are encouraged to review all draft publications during public comment periods and provide feedback 87 to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at 88 http://csrc.nist.gov/publications. 89 Comments on this publication may be submitted to [email protected] 90 Public comment period: through November 30, 2015 91 National Institute of Standards and Technology 92 Attn: Advanced network Technologies Division, Information Technology Laboratory 93 100 Bureau Drive (Mail Stop 8920) Gaithersburg, MD 20899-8920 94 Email: [email protected] 95 ii 96 Reports on Computer Systems Technology 97 The Information Technology Laboratory (ITL) at the National Institute of Standards and 98 Technology (NIST) promotes the U.S. economy and public welfare by providing technical 99 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 100 methods, reference data, proof of concept implementations, and technical analyses to advance 101 the development and productive use of information technology. ITL’s responsibilities include the 102 development of management, administrative, technical, and physical standards and guidelines for 103 the cost-effective security and privacy of other than national security-related information in 104 federal information systems. The Special Publication 800-series reports on ITL’s research, 105 guidelines, and outreach efforts in information system security, and its collaborative activities 106 with industry, government, and academic organizations. 107 Abstract 108 This document gives recommendations and guidelines for enhancing trust in email. The primary 109 audience includes enterprise email administrators, information security specialists and network 110 managers. This guideline applies to federal IT systems and will also be useful for any small or 111 medium sized organizations. Technologies recommended in support of core Simple Mail 112 Transfer Protocol (SMTP) and the Domain Name System (DNS) include mechanisms for 113 authenticating a sending domain (Sender Policy Framework (SPF), Domain Keys Identified Mail 114 (DKIM) and Domain based Message Authentication, Reporting and Conformance (DMARC). 115 Recommendations for email transmission security include Transport Layer Security (TLS) and 116 associated certificate authentication protocols. Email content security is facilitated through 117 encryption and authentication of message content using S/MIME and OpenPGP, and associated 118 certificate and key distribution protocols. 119 120 Keywords 121 Email; Simple Mail Transfer Protocol (SMTP); Transport Layer Security (TLS); Sender Policy 122 Framework (SPF); Domain Keys Identified Mail (DKIM); Domain based Message 123 Authentication, Reporting and Conformance (DMARC); Domain Name System (DNS) 124 Authentication of Named Entities (DANE); S/MIME; OpenPGP. iii 125 126 Acknowledgements 127 Audience 128 This document gives recommendations and guidelines for enhancing trust in email. The primary 129 audience for these recommendations is enterprise email administrators, information security 130 specialists and network managers. While some of the guidelines in this document pertain to 131 federal IT systems and network policy, most of the document will be more general in nature and 132 could apply to any small-mid sized organization. 133 For most of this document, it will be assumed that the organization has some or all responsibility 134 for email and can configure or manage its own email and Domain Name System (DNS) systems. 135 Even if this is not the case, the guidelines and recommendations in this document may help in 136 education about email security and can be used to produce a set of requirements for a contracted 137 service. 138 Note to Reviewers 139 This document is considered a DRAFT publication. Reviews and comments are welcome and 140 should be sent via email to [email protected]. The public comment period runs from 141 MM/DD/YYYY to MM/DD/YYYY. 142 Trademark Information 143 All registered trademarks belong to their respective organizations. iv NIST SP 800-177 Trustworthy Email 144 Executive Summary 145 This document gives recommendations and guidelines for enhancing
Load more

Recommended publications
  • Red Hat Enterprise Linux 3 Security Guide
    Red Hat Enterprise Linux 3 Security Guide Red Hat Enterprise Linux 3: Security Guide Copyright © 2003 by Red Hat, Inc. Red Hat, Inc. 1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA rhel-sg(EN)-3-Print-RHI (2003-07-25T17:12) Copyright © 2003 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarks and logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Motif and UNIX are registered trademarks of The Open Group. XFree86 is a trademark of The XFree86 Project, Inc, and is pending registration. Intel and Pentium are registered trademarks of Intel Corporation. Itanium and Celeron are trademarks of Intel Corporation. AMD, Opteron, Athlon, Duron, and K6 are registered trademarks of Advanced Micro Devices, Inc.
    [Show full text]
  • DMARC and Email Authentication
    DMARC and Email Authentication Steve Jones Executive Director DMARC.org Cloud & Messaging Day 2016 Tokyo, Japan November 28th, 2016 What is DMARC.org? • DMARC.org is an independent, non-profit advocate for the use of email authentication • Supported by global industry leaders: Sponsors: Supporters: Copyright © 2016 Trusted Domain Project 2 What Does DMARC Do, Briefly? • DMARC allows the domain owner to signal that fraudulent messages using that domain should be blocked • Mailbox providers use DMARC to detect and block fraudulent messages from reaching your customers • Organizations can use DMARC to perform this filtering on incoming messages – helps protect from some kinds of phishing and “wire transfer fraud” email, also known as Business Email Compromise (BEC) • Encourage your partners/vendors to deploy inbound DMARC filtering for protection when receiving messages • More information available at https://dmarc.org Copyright © 2016 Trusted Domain Project 3 Overview Of Presentation •DMARC Adoption •Case Study - Uber •Technical Challenges •Roadmap Copyright © 2016 Trusted Domain Project 4 DMARC Adoption This section will provide an overview of DMARC adoption since it was introduced, globally and within particular country-specific top-level domains. It will also show how the DMARC policies published by top websites has evolved over the past two years. Copyright © 2016 Trusted Domain Project 5 Deployment & Adoption Highlights 2013: • 60% of 3.3Bn global mailboxes, 80% consumers in US protected • Outlook.com users submitted 50% fewer phishing
    [Show full text]
  • DMARC — Defeating E-Mail Abuse
    CERT-EU Security Whitepaper 17-001 DMARC — Defeating E-Mail Abuse Christos Koutroumpas ver. 1.3 February 9, 2017 TLP: WHITE 1 Preface E-mail is one of the most valuable and broadly used means of communication and most orga- nizations strongly depend on it. The Simple Mail Transport Protocol (SMTP) – the Internet’s underlying email protocol – was adopted in the eighties and is still in use after 35 years. When it was designed, the need for security was not so obvious, and therefore security was not incor- porated in the design of this protocol. As a result, the protocol is susceptible to a wide range of attacks. Spear-phishing campaigns in particular can be more successful by spoofing (altering) the originator e-mail address to imper- sonate a trusted or trustworthy organization or person. This can lead to luring the recipient into giving away credentials or infecting his/her computer by executing malware delivered through the e-mail. While raising user awareness on how to avoid e-mail fraud is recommended, the Verizon Data Breach Investigations Report indicates that more needs to be done. The DBIR report reveals that 30% of all phishing e-mail messages were opened by the recipients and with 12% clicked on the content and executed malicious code. The median time for the first user of a phishing campaign to open the malicious email is 1 minute, 40 seconds. The median time to the first click on the attachment was 3 minutes, 45 seconds. These statistics highlight the risk for an organization on the receiving end of spear-phishing e-mails.
    [Show full text]
  • Electronic Mail Standard
    IT Shared Services Standard: Electronic Mail Standard For South Carolina State Agencies Version 1.0 Effective: August 8, 2018 Revision History: Date Authored by Title Ver. Notes Recommended by the Security and Architecture 08.08.2018 Standards 1.0 Executive Oversight Group. Review Board Standard finalized. Electronic Mail Standard | 2 Contents Revision History: ................................................................................................................................... 1 Electronic Mail ...................................................................................................................................... 4 Rationale ........................................................................................................................................... 4 Agency Exception Requests ............................................................................................................... 4 Current State..................................................................................................................................... 4 Purchasing......................................................................................................................................... 4 Maintenance ..................................................................................................................................... 5 Service Level Agreements ............................................................................................................. 5 Security ............................................................................................................................................
    [Show full text]
  • XEP-0347: Internet of Things - Discovery
    XEP-0347: Internet of Things - Discovery Peter Waher mailto:peterwaher@hotmail:com xmpp:peter:waher@jabber:org http://www:linkedin:com/in/peterwaher Ronny Klauck mailto:rklauck@informatik:tu-cottbus:de xmpp:TBD http://www-rnks:informatik:tu-cottbus:de/~rklauck 2018-11-03 Version 0.5.1 Status Type Short Name Deferred Standards Track iot-discovery This specification describes an architecture based on the XMPP protocol whereby Things can be in- stalled and safely discovered by their owners and connected into networks of Things. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • DHS Mandates DMARC for Email Security
    Agari U.S. Federal Government DMARC Adoption: DHS Mandates DMARC for Email Security Executive Summary On October 16, 2017, the U.S. Department of Homeland Security issued a Binding Operational Directive (BOD) 18-01 that mandates the implementation of specific security standards to strengthen email and 82% of all Federal domains have no web site security. As part of this directive, all federal agencies that operate DMARC policy .gov email domains must implement a DMARC monitoring policy (p=none) within 90 days. Furthermore, all federal agencies must move to a reject policy (p=reject) by 1 year. Based on Agari research of public DNS records, 82% percent of all US Federal Government domains do not have a DMARC policy, leaving their constituents unprotected from phishing and other forms of email attacks 86% of Federal that impersonate their agency email domains. Cybercriminals exploit this domains that use DMARC choose Agari 1 vulnerability by sending billions of phishing emails per year claiming to be from these government agencies. 1 Includes all domains that send aggregate data to a 3rd party DMARC vendor. 1 | www.agari.com Email Abuse on Federal Agency Domains Phishing continues to be a pervasive threat in the United States and around the world.The impact of these threats has been felt specifically by government agencies. Beyond the high-profile targeted attacks that have made headlines, criminals are executing phishing attacks leveraging the brand name of agencies. Indeed, over the last six months, Agari has seen an amplification of attacks against our Federal customers. As the following chart indicates, on the email-sending and defensive domains that we monitor, 25% of email volume was malicious or failing authentication.
    [Show full text]
  • A Survey of DNSSEC Deployment in the US R&E Community
    A survey of DNSSEC deployment in the U.S. R&E community Shumon Huque; University of Pennsylvania Bill Owens; NySERNET Joint Techs Conference, Stanford University, July 16th 2012 http://events.internet2.edu/2012/jt-stanford/ 1 Abstract: DNSSEC (DNS Security Extensions) is a system to verify the authenticity of DNS data using public key signatures. Although a small number of institutions in the R&E community have been at the forefront of DNSSEC deployment, the adoption rate in the larger community is still quite low. This talk will present some results of an ongoing project to survey the status of DNSSEC deployment in the US Research & Education and a few other communities. It also surveys the status of several other DNS capabilities, such as availability of the service over IPv6 transport, TCP transport, EDNS0 support, etc. [Joint Techs, Stanford University, Jul 2012] 2 Agenda • DNSSEC deployment monitoring project overview • Live demo of the website • New uses of DNSSEC by applications (DANE/TLSA etc) • (time permitting) [Joint Techs, Stanford University, Jul 2012] 3 DNSSEC at a glance • “DNS Security Extensions” • A system to verify the authenticity of DNS “data” using public key signatures • Specs: RFC 4033, 4034, 4035, 5155 (and more) • Helps detect DNS spoofing, misdirection, cache poisoning .. • Additional benefits: • Ability to store and use cryptographic keying material in the DNS, eg. SSHFP, IPSECKEY, CERT, DKIM, TLSA, etc .. [Joint Techs, Stanford University, Jul 2012] 4 Other surveys • SecSpider • http://secspider.cs.ucla.edu/
    [Show full text]
  • XEP-0156: Discovering Alternative XMPP Connection Methods
    XEP-0156: Discovering Alternative XMPP Connection Methods Joe Hildebrand Peter Saint-Andre Lance Stout mailto:jhildebr@cisco:com mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:hildjj@jabber:org xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2020-07-07 Version 1.3.1 Status Type Short Name Draft Standards Track alt-connections This document defines an XMPP Extension Protocol for discovering alternative methods of connecting to an XMPP server using two ways: (1) DNS TXT Resource Record format; and (2) Web Host Metadata Link format. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • DMARC Jesse Thompson, Technical Architect University of Wisconsin-Madison [email protected] Motivation → Authenticity
    Email Authenticity with DMARC Jesse Thompson, Technical Architect University of Wisconsin-Madison [email protected] Motivation → Authenticity ● Mail your institution sends isn’t accounted for ● Mail claiming to be your domain may be fraud ● Instead of filtering the bad...we start authenticating the good? Functional Motivators for Email Authenticity 1. Deliverability: Google/MS/etc starting to require 2. Policies: DHS Binding Operational Directive 18-01 3. Security: Stop abuse Build on SPF SPF = Sender Policy Framework Publish in DNS a list of servers authorized for MAIL FROM (SMTP envelope return path). Receivers consult list. https://tools.wordtothewise.com/spf/check/wisc.edu wisc.edu. 3600 IN TXT "v=spf1 ip4:144.92.197.128/25 ?all" Build on DKIM DKIM = Domain Keys Identified Mail Attach signatures to email. Public key in DNS. Receivers verify signature. https://tools.wordtothewise.com/dkim/check/wisc.edu/selector1 DKIM-Signature: v=1; a=rsa-sha256; d=wisc.edu; s=selector1; c=relaxed/relaxed; q=dns/txt; t=1126524832; x=1149015927; h=from:to:subject:date:keywords:keywords; bh=MHIzKDU2Nzf3MDEyNzR1Njc5OTAyMjM0MUY3ODlqBLP=; b=hyjCnOfAKDdLZdKIc9G1q7LoDWlEniSbzc+yuU2zGrtruF00ldcF VoG4WTHNiYwG Build on SPF and DKIM SPF Problems: ○ Users can’t see MAIL FROM / no alignment to Header From domain ○ Forwarding / mailing lists ○ DNS lookup limit of 10 ○ Inconsistent enforcement by receivers DKIM Problems: ○ Users can’t see key selector / no alignment to Header From domain ○ Message modification in transit / mailing lists ○ Key management / vendor support Protagonist → Header From domain Need to create a link between the domain and the message. dmarc.org What is DMARC? Domain-based Message Authentication Reporting and Conformance 1.
    [Show full text]
  • Presentations Made by Senders
    SES ���� ��� � �� � � � � � � � ������������� DomainKeys ��������� SPF ��������������������� ���������� ����������������� ������������������������������������������������ Contents Introduction 3 Deployment: For Email Receivers 6 Audience 3 Two Sides of the Coin 6 How to Read this White Paper 3 Recording Trusted Senders Who Passed Authentication 6 A Vision for Spam-Free Email 4 Whitelisting Incoming Forwarders 6 The Problem of Abuse 4 What To Do About Forgeries 6 The Underlying Concept 4 Deployment: For ISPs and Enterprises 7 Drivers; or, Who’s Buying It 4 Complementary considerations for ISPs 7 Vision Walkthrough 5 Deployment: For MTA vendors 8 About Sender Authentication 8 Which specification? 8 An Example 8 Conformance testing 8 History 8 Perform SRS and prepend headers when forwarding 8 How IP-based Authentication Works 9 Add ESMTP support for Submitter 8 The SPF record 9 Record authentication and policy results in the headers 8 How SPF Classic Works 9 Join the developers mailing list 8 How Sender ID works 9 Deployment: For MUA vendors 9 How Cryptographic Techniques Work 0 Displaying Authentication-Results 9 Using Multiple Approaches Automatic switching to port 587 9 Reputation Systems Deployment: For ESPs 20 Deployment: For Email Senders 2 Don’t look like a phisher! 20 First, prepare. 2 Delegation 20 Audit Your Outbound Mailstreams 2 Publish Appropriately 20 Construct the record 2 Deployment: For Spammers 2 Think briefly about PRA and Mail-From contexts. 3 Two Types of Spammers 2 Test the record, part 3 Publish SPF and sign with DomainKeys. 2 Put the record in DNS 3 Stop forging random domains. 2 Test the record, part 2 4 Buy your own domains. 2 Keep Track of Violations 4 Reuse an expired domain.
    [Show full text]
  • That Ain't You: Detecting Spearphishing Emails Before They
    That Ain't You: Blocking Spearphishing Emails Before They Are Sent Gianluca Stringhinix and Olivier Thonnardz xUniversity College London z Amadeus [email protected] [email protected] Abstract 1 Introduction Companies and organizations are constantly under One of the ways in which attackers try to steal sen- attack by cybercriminals trying to infiltrate corpo- sitive information from corporations is by sending rate networks with the ultimate goal of stealing sen- spearphishing emails. This type of emails typically sitive information from the company. Such an attack appear to be sent by one of the victim's cowork- is often started by sending a spearphishing email. At- ers, but have instead been crafted by an attacker. tackers can breach into a company's network in many A particularly insidious type of spearphishing emails ways, for example by leveraging advanced malware are the ones that do not only claim to come from schemes [21]. After entering the network, attackers a trusted party, but were actually sent from that will perform additional activities aimed at gaining party's legitimate email account that was compro- access to more computers in the network, until they mised in the first place. In this paper, we pro- are able to reach the sensitive information that they pose a radical change of focus in the techniques used are looking for. This process is called lateral move- for detecting such malicious emails: instead of look- ment. Attackers typically infiltrate a corporate net- ing for particular features that are indicative of at- work, gain access to internal machines within a com- tack emails, we look for possible indicators of im- pany and acquire sensitive information by sending personation of the legitimate owners.
    [Show full text]
  • Busting Blocks: Revisiting 47 U.S.C. §230 to Address the Lack of Effective Legal Recourse for Wrongful Inclusion in Spam Filters
    Digital Commons @ Touro Law Center Scholarly Works Faculty Scholarship 2011 Busting Blocks: Revisiting 47 U.S.C. §230 to Address the Lack of Effective Legal Recourse for Wrongful Inclusion in Spam Filters Jonathan I. Ezor Touro Law Center, [email protected] Follow this and additional works at: https://digitalcommons.tourolaw.edu/scholarlyworks Part of the Commercial Law Commons, Communications Law Commons, and the Science and Technology Law Commons Recommended Citation Jonathan I. Ezor, Busting Blocks: Revisiting 47 U.S.C. § 230 to Address the Lack of Effective Legal Recourse for Wrongful Inclusion in Spam Filters, XVII Rich. J.L. & Tech. 7 (2011), http://jolt.richmond.edu/ v17i2/article7.pdf. This Article is brought to you for free and open access by the Faculty Scholarship at Digital Commons @ Touro Law Center. It has been accepted for inclusion in Scholarly Works by an authorized administrator of Digital Commons @ Touro Law Center. For more information, please contact [email protected]. Richmond Journal of Law and Technology Vol. XVII, Issue 2 BUSTING BLOCKS: REVISITING 47 U.S.C. § 230 TO ADDRESS THE LACK OF EFFECTIVE LEGAL RECOURSE FOR WRONGFUL INCLUSION IN SPAM FILTERS By Jonathan I. Ezor∗ Cite as: Jonathan I. Ezor, Busting Blocks: Revisiting 47 U.S.C. § 230 to Address the Lack of Effective Legal Recourse for Wrongful Inclusion in Spam Filters, XVII Rich. J.L. & Tech. 7 (2011), http://jolt.richmond.edu/v17i2/article7.pdf. I. INTRODUCTION: E-MAIL, BLOCK LISTS, AND THE LAW [1] Consider a company that uses e-mail to conduct a majority of its business, including customer and vendor communication, marketing, and filing official documents.
    [Show full text]