DOCSLIB.ORG

NIST SP 800-45 Version 2, Guidelines on Electronic Mail Security

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
NIST SP 800-45 Version 2, Guidelines on Electronic Mail Security Special Publication 800-45 Version 2 Guidelines on Electronic Mail Security Recommendations of the National Institute of Standards and Technology Miles Tracy Wayne Jansen Karen Scarfone Jason Butterfield NIST Special Publication 800-45 Guidelines on Electronic Mail Security Version 2 Recommendations of the National Institute of Standards and Technology Miles Tracy, Wayne Jansen, Karen Scarfone, and Jason Butterfield C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 February 2007 U .S. Department of Commerce Carlos M. Gutierrez, Secretary Technology Administration Robert C. Cresanti, Under Secretary of Commerce for Technology National Institute of Standards and Technology William Jeffrey, Director Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-45 Version 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-45 Version 2, 139 pages (Feb. 2007) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. iii Acknowledgements, Version 2 The authors, Wayne Jansen and Karen Scarfone of NIST, Miles Tracy of Federal Reserve Information Technology, and Jason Butterfield of Booz Allen Hamilton, wish to express their thanks to colleagues at both organizations who reviewed drafts of this document. In particular, their appreciation goes to Linda Antil, Rick Ayers, Bill Burr, Tim Grance, and Tim Polk from NIST for their research, technical support, and written contributions to this version of the document. The authors would also like to express their thanks to all those who contributed input during the public comment period and who assisted with our internal review process. Acknowledgements, Original Version The authors, Wayne Jansen of NIST and Scott Bisker and Miles Tracy of Booz Allen Hamilton (BAH), wish to express their thanks to colleagues at both organizations who reviewed drafts of this document. In particular, their appreciation goes to John Wack, Murugiah Souppaya, and Tim Grance from NIST, and Steve Allison, Alexis Feringa, Jonathan Holleran, Kevin Kuhlkin, and Mark McLarnon from BAH, for their research, technical support, and written contributions to this document. The authors would also like to express their thanks to all those who contributed input during the public comment period and who assisted with our internal review process. iv GUIDELINES ON ELECTRONIC MAIL SECURITY Table of Contents Executive Summary..............................................................................................................ES-1 1. Introduction ......................................................................................................................1-1 1.1 Authority...................................................................................................................1-1 1.2 Purpose and Scope .................................................................................................1-1 1.3 Audience and Assumptions .....................................................................................1-2 1.4 Document Organization ...........................................................................................1-2 2. Background and Standards ............................................................................................2-1 2.1 Background..............................................................................................................2-1 2.2 Multipurpose Internet Mail Extensions .....................................................................2-2 2.3 Mail Transport Standards.........................................................................................2-3 2.3.1 Simple Mail Transfer Protocol ......................................................................2-3 2.3.2 Simple Mail Transfer Protocol Extensions....................................................2-4 2.3.3 Proprietary Mail Transports ..........................................................................2-6 2.4 Client Access Standards..........................................................................................2-6 2.4.1 Post Office Protocol......................................................................................2-7 2.4.2 Internet Message Access Protocol ...............................................................2-8 2.4.3 Proprietary Mailbox Access Mechanisms.....................................................2-9 2.4.4 Web-Based Mail Access...............................................................................2-9 3. Signing and Encrypting Email Messages ......................................................................3-1 3.1 OpenPGP.................................................................................................................3-2 3.2 S/MIME ....................................................................................................................3-4 3.3 Key Management.....................................................................................................3-4 3.4 Issues with Email Encryption ...................................................................................3-5 4. Planning and Managing Mail Servers.............................................................................4-1 4.1 Installation and Deployment Planning......................................................................4-1 4.2 Security Management Staff......................................................................................4-3 4.2.1 Senior IT Management/Chief Information Officer (CIO) ...............................4-3 4.2.2 Information Systems Security Program Managers .......................................4-3 4.2.3 Information Systems Security Officers .........................................................4-4 4.2.4 Mail Server and Network Administrators ......................................................4-4 4.3 Management Practices ............................................................................................4-4 4.4 System Security Plan...............................................................................................4-5 4.5 Human Resources Requirements............................................................................4-7 4.6 General Information System Security Principles......................................................4-7 4.7 Checklist for Planning and Managing Mail Servers .................................................4-9 5. Securing the Mail Server Operating System .................................................................5-1 5.1 Updating and Configuring the Operating System ....................................................5-2 5.1.1 Patch and Upgrade Operating System.........................................................5-2 5.1.2 Remove or Disable Unnecessary Services and Applications.......................5-2 5.1.3 Configure Operating System User Authentication........................................5-4 5.1.4 Configure Resource Controls Appropriately .................................................5-6 5.1.5 Install and Configure Additional Security Controls .......................................5-6 5.2 Security Testing the Operating System ...................................................................5-7 v GUIDELINES ON ELECTRONIC MAIL SECURITY 5.3 Checklist for Securing the Mail Server Operating System .......................................5-7 6. Securing Mail Servers and Content................................................................................6-1 6.1 Hardening the Mail Server Application.....................................................................6-1 6.1.1 Securely Installing the Mail Server ...............................................................6-1 6.1.2 Configuring Operating System and Mail Server Access Controls ................6-1 6.2 Protecting Email from Malware ................................................................................6-3 6.2.1 Malware Scanning ........................................................................................6-5 6.2.2 Content Filtering ...........................................................................................6-9 6.2.3 User Awareness .........................................................................................6-12
Load more

Recommended publications
  • Trendmicro™ Hosted Email Security
    TrendMicro™ Hosted Email Security Best Practice Guide Trend Micro Incorporated reserves the right to make changes to this document and to the products described herein without notice. The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted. Complying with all applicable copyright laws is the responsibility of the user. Copyright © 2016 Trend Micro Incorporated. All rights reserved. Trend Micro, the Trend Micro t-ball logo, and TrendLabs are trademarks or registered trademarks of Trend Micro, Incorporated. All other brand and product names may be trademarks or registered trademarks of their respective companies or organizations. No part of this publication may be reproduced, photocopied, stored in a retrieval system, or transmitted without the express prior written consent of Trend Micro Incorporated. Authors : Michael Mortiz, Jefferson Gonzaga Editorial : Jason Zhang Released : June 2016 Table of Contents 1 Best Practice Configurations ................................................................................................................................. 8 1.1 Activating a domain ....................................................................................................................................... 8 1.2 Adding Approved/Blocked Sender ................................................................................................................ 8 1.3 HES order
    [Show full text]
  • SMTP (Simple Mail Transfer Protocol)
    P1: JsY JWBS001A-60.tex WL041/Bidgoli WL041-Bidgoli.cls May 12, 2005 3:27 Char Count= 0 SMTP (Simple Mail Transfer Protocol) Vladimir V. Riabov, Rivier College Introduction 1 SMTP Security Issues 12 SMTP Fundamentals 1 SMTP Vulnerabilities 12 SMTP Model and Protocol 2 SMTP Server Buffer Overflow Vulnerability 15 User Agent 4 Mail Relaying SMTP Vulnerability 15 Sending e-Mail 4 Mail Relaying SMTP Vulnerability in Microsoft Mail Header Format 4 Windows 2000 15 Receiving e-Mail 4 Encapsulated SMTP Address Vulnerability 15 The SMTP Destination Address 4 Malformed Request Denial of Service 16 Delayed Delivery 4 Extended Verb Request Handling Flaw 16 Aliases 5 Reverse DNS Response Buffer Overflow 16 Mail Transfer Agent 5 Firewall SMTP Filtering Vulnerability 16 SMTP Mail Transaction Flow 5 Spoofing 16 SMTP Commands 6 Bounce Attack 16 Mail Service Types 6 Restricting Access to an Outgoing Mail SMTP Service Extensions 8 Server 17 SMTP Responses 8 Mail Encryption 17 SMTP Server 8 Bastille Hardening System 17 On-Demand Mail Relay 8 POP and IMAP Vulnerabilities 17 Multipurpose Internet Mail Extensions Standards, Organizations, and (MIME) 8 Associations 18 MIME-Version 10 Internet Assigned Numbers Authority 18 Content-Type 10 Internet Engineering Task Force Working Content-Transfer-Encoding 10 Groups 18 Content-Id 11 Internet Mail Consortium 18 Content-Description 11 Mitre Corporation 18 Security Scheme for MIME 11 Conclusion 18 Mail Transmission Types 11 Glossary 18 Mail Access Modes 11 Cross References 19 Mail Access Protocols 11 References 19 POP3 11 Further Reading 22 IMAP4 12 INTRODUCTION and IMAP4), SMTP software, vulnerability and security issues, standards, associations, and organizations.
    [Show full text]
  • SMTP Protocol
    CS 280 Lecture 4: Application Layer, Email, DNS, P2P John Magee 21 September 2016 Most slides adapted from Kurose and Ross, Computer Networking 7/e Source material copyright 1996-2016 1 J.F Kurose and K.W. Ross Chapter 2: outline Last Class: 2.1 principles of network Next Class: applications 2.6 video streaming and 2.2 Web and HTTP content distribution networks Today: 2.7 socket programming with UDP and TCP 2.3 electronic mail • SMTP, POP3, IMAP 2.4 DNS 2.5 P2P applications Application Layer 2-2 outgoing Electronic mail message queue user mailbox Three major components: user agent . user agents . mail servers mail user server . simple mail transfer agent protocol: SMTP SMTP mail user server agent User Agent SMTP . a.k.a. “mail reader” SMTP user agent . composing, editing, reading mail server mail messages user . e.g., Outlook, Thunderbird, agent iPhone mail client user . outgoing, incoming agent messages stored on server Application Layer 2-3 Electronic mail: mail servers mail servers: user agent . mailbox contains incoming messages for user mail user server . message queue of outgoing agent (to be sent) mail messages SMTP mail user . SMTP protocol between server agent mail servers to send email SMTP messages SMTP user agent • client: sending mail mail server server • “server”: receiving mail user server agent user agent Application Layer 2-4 Electronic Mail: SMTP [RFC 2821] . uses TCP to reliably transfer email message from client to server, port 25 . direct transfer: sending server to receiving server . three phases of transfer • handshaking (greeting) • transfer of messages • closure . command/response interaction (like HTTP) • commands: ASCII text • response: status code and phrase .
    [Show full text]
  • Statement from Directtrust Regarding the EFAIL Vulnerability
    Statement from DirectTrust regarding the EFAIL Vulnerability Summary EFAIL is a set of attacks used to exploit vulnerabilities in email clients that decrypt and display PGP and S/MIME encrypted messages by coercing them into sending the decrypted text of the emails to an attacker. Properly implemented, Direct is NOT vulnerable. However, we recommend that if you are exchanging with anyone outside of the DirectTrust Network, you will want to understand at a reasonable depth how their implementation protects against EFAIL. How does EFAIL work? EFAIL consists of two different attack scenarios that create “backchannels” to send the decrypted text to an attacker. Both require an attacker to first obtain the encrypted message. 1. The attacker “wraps” the encrypted body with carefully crafted markup that can result in an email client decrypting the message and sending the decrypted body to the attacker. 2. The attacker manipulates the encrypted body of the message using well known S/MIME weaknesses that produce a message that can send the decrypted body to the attacker once rendered in the email client. Although the attacks are different, the end result is the same: a vulnerable email client sends the decrypted text to the attacker. How is this relevant to Direct? Direct uses S/MIME to encrypt messages, so in theory every Direct message could be vulnerable to this attack. However, Direct, when implemented correctly, is NOT vulnerable. The vulnerability is only applicable if decryption and rendering of the message are done in certain email clients like Thunderbird, iOS, Apple Mail, and some versions of Outlook.
    [Show full text]
  • Electronic Evidence Examiner
    2 Table of Contents About Electronic Evidence Examiner How To .......................................................................12 How to Work with Cases .........................................................................................................13 How to Create New Case .......................................................................................................13 How to Enable Automatic Case Naming .................................................................................14 How to Define Case Name During Automatic Case Creation .................................................14 How to Open Existing Case....................................................................................................15 How to Save Case to Archive .................................................................................................16 How to Change Default Case Location ...................................................................................16 How to Add Data to Case ........................................................................................................17 How to Add Evidence .............................................................................................................18 How to Acquire Devices .........................................................................................................20 How to Import Mobile Data .....................................................................................................21 How to Import Cloud Data ......................................................................................................22
    [Show full text]
  • MTA STS Improving Email Security.Pdf
    Improving Email Security with the MTA-STS Standard By Brian Godiksen An Email Best Practices Whitepaper CONTENTS Executive Overview 03 Why Does Email Need Encryption in Transit? 04 The Problem with “Opportunistic Encryption” 07 The Anatomy of a Man-in-the-Middle Attack 08 The Next Major Step with Email Encryption: MTA-STS 10 What Steps Should Senders Take to Adopt MTA-STS? 11 About SocketLabs 12 Brian Godiksen Brian has been helping organizations optimize email deliverability since joining SocketLabs in 2011. He currently manages a team of deliverability analysts that consult with customers on best infrastructure practices, including email authentication implementation, bounce processing, IP address warm-up, and email marketing list management. Brian leads the fight against spam and email abuse at SocketLabs by managing compliance across the platform. He is an active participant in key industry groups such as M3AAWG and the Email Experience Council. You can read more of Brian’s content here on the SocketLabs website. ©2019 SocketLabs 2 Executive The Edward Snowden leaks of 2013 opened many peoples’ eyes to the fact that mass surveillance was possible by Overview intercepting and spying on email transmissions. Today, compromised systems, database thefts, and technology breaches remain common fixtures in news feeds around the world. As a natural response, the technology industry is rabidly focused on improving the security and encryption of communications across all platforms. Since those early days of enlightenment, industry experts have discussed and attempted a variety of new strategies to combat “pervasive monitoring” of email channels. While pervasive monitoring assaults can take many forms, the most prominent forms of interference were man-in-the-middle (MitM) attacks.
    [Show full text]
  • Groupwise Mobility Quick Start for Microsoft Outlook Users
    GroupWise Mobility Quick Start for Microsoft Outlook Users August 2016 GroupWise Mobility Service 2014 R2 allows the Microsoft Outlook client for Windows to run against a GroupWise backend via Microsoft ActiveSync 14.1 protocol. This document helps you set up your Outlook client to access your GroupWise account and provides known limitations you should be aware of while using Outlook against GroupWise. Supported Microsoft Outlook Clients CREATING THE GROUPWISE PROFILE MANUALLY Microsoft Outlook 2013 or 21016 for Windows 1 On the machine, open Control Panel > User Accounts and Family Safety. Microsoft Outlook Mobile App Adding a GroupWise Account to the Microsoft Outlook Client You must configure the Microsoft Outlook client in order to access your GroupWise account. The following instructions assume that the Outlook client is already installed on your machine. You can use the GroupWise Profile Setup utility to set the profile up automatically or you can manually create the GroupWise profile for Outlook. Using the GroupWise Profile Setup Utility Creating the GroupWise Profile Manually 2 Click Mail. 3 (Conditional) If a Mail Setup dialog box is displayed, USING THE GROUPWISE PROFILE SETUP UTILITY click Show Profiles to display the Mail dialog box. You must first obtain a copy of the GWProfileSetup.zip from If GroupWise is installed on the machine, the Profiles your system administrator before following the steps below list includes a GroupWise profile, as shown in the to create the profile on your workstation. following screenshot. You need to keep this profile and create a new profile. 1 Extract the GWProfileSetup.zip to a temporary location on your workstation.
    [Show full text]
  • Securing Your Email in 13 Steps: the Email Security Checklist Handbook Securing Your Email in 13 Steps
    HANDBOOK Securing Your Email in 13 Steps: The Email Security Checklist handbook Securing Your Email in 13 Steps overview You’ve hardened your servers, locked down your website and are ready to take on the internet. But all your hard work was in vain, because someone fell for a phishing email and wired money to a scammer, while another user inadvertently downloaded and installed malware from an email link that opened a backdoor into the network. Email is as important as the website when it comes to security. As a channel for social engineering, malware delivery and resource exploitation, a combination of best practices and user education should be enacted to reduce the risk of an email-related compromise. By following this 13 step checklist, you can make your email configuration resilient to the most common attacks and make sure it stays that way. 2 @UpGuard | UpGuard.com handbook Securing Your Email in 13 Steps 1. Enable SPF How do you know if an email is really from who it says it’s from? There are a couple of ways to answer this question, and Sender Policy Framework (SPF) is one. SPF works by publishing a DNS record of which servers are allowed to send email from a specific domain. 1. An SPF enabled email server receives an email from [email protected] 2. The email server looks up example.com and reads the SPF TXT record in DNS. 3. If the originating server of the email matches one of the allowed servers in the SPF record, the message is accepted.
    [Show full text]
  • Ipv6 DMZ Web Service Technology Design Guide
    IPv6 DMZ Web Service Technology Design Guide August 2014 Series Table of Contents Preface ........................................................................................................................................1 CVD Navigator .............................................................................................................................2 Use Cases .................................................................................................................................. 2 Scope ......................................................................................................................................... 2 Proficiency .................................................................................................................................. 2 Introduction .................................................................................................................................3 Technology Use Cases ............................................................................................................... 3 Use Case: Enable Native IPv6 Access for Network Traffic Between the Internet and a Web Server DMZ Network.............................................................................................................. 3 Use Case: Enable IPv6 Access for Network Traffic Between the Internet and an IPv4-only Web Server DMZ Network ..................................................................................................... 3 Design Overview ........................................................................................................................
    [Show full text]
  • Iptables with Shorewall!
    Iptables with shorewall! Table of Contents 1. Install swarmlab-sec (Home PC) . 1 2. shorewall . 1 2.1. Installation . 2 3. Basic Two-Interface Firewall. 2 4. Shorewall Concepts . 3 4.1. zones — Shorewall zone declaration file . 3 4.2. interfaces — Shorewall interfaces file. 4 4.3. policy — Shorewall policy file . 4 4.4. rules — Shorewall rules file . 4 4.5. Compile then Execute . 4 5. Three-Interface Firewall. 5 5.1. zones . 6 5.2. interfaces . 6 5.3. policy . 7 5.4. rules . 7 5.5. masq - Shorewall Masquerade/SNAT definition file . 7 5.6. snat — Shorewall SNAT/Masquerade definition file . 8 5.7. Compile and Execute . 8 1. Install swarmlab-sec (Home PC) HowTo: See http://docs.swarmlab.io/lab/sec/sec.adoc.html NOTE Assuming you’re already logged in 2. shorewall Shorewall is an open source firewall tool for Linux that builds upon the Netfilter (iptables/ipchains) system built into the Linux kernel, making it easier to manage more complex configuration schemes by providing a higher level of abstraction for describing rules using text files. More: wikipedia 1 NOTE Our docker instances have only one nic to add more nic’s: create netowrk frist docker network create --driver=bridge --subnet=192.168.0.0/16 net1 docker network create --driver=bridge --subnet=192.168.0.0/16 net2 docker network create --driver=bridge --subnet=192.168.0.0/16 net3 then connect network to container connect network created to container docker network connect net1 master docker network connect net1 worker1 docker network connect net2 master docker network connect net2 worker2 now let’s look at the following image 2.1.
    [Show full text]
  • Zix Wins 5-Vendor Email Encryption Shootout Email Encryption Has Come a Long Way Since Our Last Review
    Reprint THE CONNECTED ENTERPRISE MARCH 13, 2017 Zix wins 5-vendor email encryption shootout Email encryption has come a long way since our last review BY DAVID STROM, NETWORK WORLD terms of the flexibility of various encryption While these personal encryption products protocols used, along with DLP features that are improvements, there are also steps mail encryption products have are built-in along with a simple and single forward for the enterprise encryption email made major strides since we last pricing structure -- all things that Zix excels. user. Some products, such as Zix, hide the looked at them nearly two years All of these encryption products will cost encryption key process entirely from the ago. They have gotten easier you a few dollars a month per user. While user, so well that you might not even know to use and deploy, thanks to a that doesn’t sound like much, if you have that an encrypted message has passed from Ecombination of user interface and encryption an installation of several thousand users, sender to recipient. key management improvements, and are at the price tag could add up. However, the Others, such as Virtru and HPE/Voltage, the point where encryption can almost be alternative is having your email stream use identity-based encryption management called effortless on the part of the end user. available to anyone with a simple collection to verify a new recipient in their systems. Our biggest criticism in 2015 was that the of tools that even teens can master. Once a user new to these products products couldn’t cover multiple use cases, clicks on a confirmation email, they are such as when a user switches from reading Trends and bright spots forever allowed access, their emails are emails on their smartphone to moving to a In 2015, we said that gateways may have automatically decrypted, and there is no webmailer to composing messages on their fallen out of favor, but that trend has been need for any further effort to keep track of or Outlook desktop client.
    [Show full text]
  • End-To-End Measurements of Email Spoofing Attacks
    End-to-End Measurements of Email Spoofing Attacks Hang Hu, Gang Wang [email protected] Computer Science, Virginia Tech Spear Phishing is a Big Threat • Spear phishing: targeted phishing attack, often involves impersonation • 91% of targeted attacks involve spear phishing1 • 95% of state-affiliated espionage attacks are traced to phishing2 1. Enterprise Phishing Susceptibility and Resiliency Report, PhishMe, 2016 2. 2013 Data Beach Investigation Report, Verizon, 2013 2 Real-life Spear Phishing Examples Yahoo DataJohn Breach Podesta’s in 2014 Gmail Account From Google [accounts.googlemail.comAffected] 500HillaryMillion ClintonYahoo! 2016User CampaignAccount Chairman Why can phishers still impersonate others so easily? 3 I Performed a Spear Phishing Test • I impersonated USENIX Security co-chairs to send spoofing emails to my account ([email protected]) Auto-loaded Profile Picture From Adrienne Porter Felt From William Enck Adrienne Porter Felt [email protected] Enck [email protected] [email protected]@ncsu.edu 4 Background: SMTP & Spoofing • Simple Mail Transfer Protocol (SMTP) defined in 1982 • SMTP has no built-in authentication mechanism • Spoof anyone by modifying MAIL FROM field of SMTP HTTP HTTP POP SMTP SMTP IMAP William ncsu.edu vt.edu Hang Mail Server Mail Server SMTP MAIL FROM: [email protected] Attacker Mail Server 5 Existing Anti-spoofing Protocols MAIL FROM: [email protected] Process SMTP, 1982 IP: 1.2.3.4 ncsu.edu Sender Policy Framework (SPF), 2002 • IP based authentication Publish authorized? the IP Is vt.edu Yes IP authorized?
    [Show full text]