Securing Data at the Application Layer Planning Authenticity and Integrity of Transmitted Data...
-
Upload
marjory-fox -
Category
Documents
-
view
228 -
download
0
Transcript of Securing Data at the Application Layer Planning Authenticity and Integrity of Transmitted Data...
Securing Data at the Application Layer
Planning Authenticity and Integrity of Transmitted Data
Planning Encryption of Transmitted Data
Planning Authenticity and Integrity of Transmitted Data
Providing authenticity and integrity of transmitted data
Planning Server Message Block (SMB) signing Planning digital signing
Two Methods That Provide Authenticity and Integrity of Transmitted Data at the Application Layer SMB signing Secure/Multipurpose Internet Mail Extensions
(S/MIME) and Pretty Good Privacy (PGP)
Planning SMB Signing SMB signing is also known as Common Internet File
System (CIFS). SMB signing ensures the authenticity and integrity of
packets transmitted between a client and a server. Each packet is signed as it is transmitted and then
verified at the recipient computer. SMB signing is implemented in high-security
networks to prevent impersonation of clients and servers.
SMB signing authenticates the user and the server hosting the data.
If authentication fails on either side, data transmission will not take place.
SMB Signing Process
Message Digest v5 (MD5) Algorithm
MD5 is used to create the key that is used to create the digest.
The MD5 algorithm breaks the data into 512-bit blocks and produces a 128-bit message digest for each 512-bit block of the data.
The key is computed from the session key established between the client and the server and the initial response sent by the client to the server's challenge.
When to Use SMB Signing
Use SMB signing in networks that implement both Microsoft Windows 2000–based clients and down-level Windows clients.
IPSec Authentication Headers (AH) are supported only in a pure Windows 2000 network.
SMB signing is supported by Windows 2000, Microsoft Windows NT 4.0 (Service Pack 3), and Microsoft Windows 98–based clients.
Windows 95–based clients do not support SMB signing.
Deployment of SMB Signing
SMB Signing: Windows 2000–Based Clients
Workgroup environment Deploy the security template file by using the
Secedit command. Copy the completed security template locally to each
computer. Create a batch file that calls the Secedit command,
using the /configure option to apply the security template
SMB Signing: Windows 2000–Based Clients (Cont.)
Domain environment
SMB Signing: Windows 2000–Based Clients (Cont.)
Choosing domain or workgroup settings depends on
The role of the Windows 2000–based computer The security requirements for SMB signing defined
for the network
SMB Signing: Windows NT 4.0–Based Clients Windows NT 4.0 introduced support for SMB signing in
Service Pack 3 (SP3). Requires editing of the registry. Create a custom template file and apply the settings with
the System Policy Editor. If Windows NT 4.0 is operating in a domain environment,
apply the settings to a Ntconfig.pol configuration file. Registry key for clients functioning as a server
HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\LanManServer\Parameters
Registry key for clients functioning as a client HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\Rdr\Parameters
SMB Signing: Windows 98–Based Clients
Windows 98 includes an updated version of the SMB protocol.
Requires editing of the registry. Deploy these settings by e-mailing a .reg file
containing the desired settings. Registry key for clients
HKEY_LOCAL_MACHINE \System\CurrentControlSet\
Services\VxD\Vnetsup
Making the Decision: Planning SMB Signing Security
Require that all communications to a server use SMB signing.
Allow SMB signing to fall back to unsigned communications.
Deploy SMB signing configuration for Windows 2000–based clients.
Deploy SMB signing configuration for Windows NT 4.0–based clients.
Deploy SMB signing configuration for Windows 98–based clients.
Applying the Decision: Planning SMB Signing Security for Fabrikam Inc.
Implement SMB signing for the Radar System project, using different methods depending on the computer's OS.
The HELIOS server Windows 2000 clients Windows NT 4.0 clients Windows 98 clients
SMB signing is not required for the Sonar System project.
Applying the Decision: Proposed OU Structure for Windows 2000–Based Clients for Fabrikam Inc.
Planning Digital Signing
Digital signatures ensure the authenticity and integrity of e-mail messages between clients.
Public Key Infrastructure (PKI) is required to deploy the necessary public/private key pairs to participating clients.
Digital signatures function by applying a digest function to the contents of the message to create a message digest.
If the contents of the message are modified, the message digest output will also change.
Digital Signature Process
Determining Protocol Choices for Digital Signing
Two protocols provide digital signatures for e-mail applications:
S/MIME PGP
Determine which protocol to use based on the e-mail application deployed.
Deploying Public Keys
Ensure the availability of public keys when implementing digital signatures.
Without a public key, the digest encrypted with the sender's private key cannot be decrypted to verify message integrity.
The digital certificate must be issued by a Certificate Authority (CA) that the recipient trusts.
The Certificate Revocation List (CRL) must be accessible to any recipients so the revocation status of the digital certificate can be verified.
If the CRL cannot be accessed, the certificate is assumed to be revoked.
Ensuring the Availability of Public Keys
Configure e-mail clients to include their certificate with all signed messages.
Implement the Key Management Service (KMS) in Microsoft Exchange Server 5.5 or Microsoft Exchange 2000 Server.
Making the Decision: Digital Signature Design
Choose which protocol to use for digitally signing e-mail messages within the organization.
Ensure that important messages are digitally signed.
Ensure that digital signatures are validated. Limit which users can use digital signatures.
Applying the Decision: Digital Signature Design for Fabrikam Inc.
Provide the ability to digitally sign messages. Defense Department price quotes The Radar System project The Sonar System project
Determine which users need to acquire certificates for digitally signed e-mail.
Determine whether the partners of the Defense Department and A. Datum Corporation use PGP or S/MIME for their e-mail packages.
Planning Encryption of Transmitted Data
Planning secure e-mail encryption Planning application-level encryption with
Secure Sockets Layer/Transport Layer Security (SSL/TLS)
Planning Secure E-Mail Encryption
Contents of e-mail messages are vulnerable to inspection.
Digital signing does not prevent someone from inspecting e-mail messages during transmission across the network.
Simple Mail Transfer Protocol (SMTP) is the default protocol used for sending e-mail messages.
SMTP does not include any extensions for the encryption of e-mail.
E-Mail Encryption Process
Encryption Levels for E-Mail
Algorithms supported in Microsoft Outlook 2000 Rivest's Cipher v2 (RC2) Data Encryption Standard (DES) Triple DES (3DES)
Encryption import and export laws RC2 (128 bit) and 3DES require the Windows 2000
High Encryption Pack to be installed. The Windows 2000 High Encryption Pack is subject to
import and export laws. The United States allows the export of the high
encryption to nonembargoed nations.
Protocol Choices for E-Mail Encryption
Choose between S/MIME and PGP for the encryption protocol.
Encryption protocols for e-mail cannot be mixed.
Making the Decision: Deploying E-Mail Encryption
Determine all approved e-mail applications that are in use.
Determine who can use secure e-mail. Determine where the private/public keys will be
acquired. Establish guidelines for the distribution of public
keys to recipients outside the organization. Establish an external public point for CRLs if
using an internal CA. Train users on when to encrypt messages.
Applying the Decision: Deploying E-Mail Encryption for Fabrikam Inc. Require encryption of e-mail sent to the Defense
Department and between project members on the Sonar System project.
The same infrastructure that is required for digitally signing e-mail messages works for encrypting e-mail messages.
It is recommended that Mail certificates be acquired from a public CA, or ensure that the CAs have their CRLs available on the Internet.
The users in the two projects should be trained on how to encrypt messages when the messages are sent to recipients in other companies.
The process may require that a digitally signed message is first sent between the two users who require encrypted mail.
The public key of the recipient is used to encrypt messages sent to that recipient.
Application-Level Encryption with SSL/TLS
Secure Sockets Layer (SSL)
SSL provides encryption services by using public and private keys to encrypt data transmitted between a server and a client.
SSL is commonly associated with Web browsers. The application must be programmed to support
SSL. SSL is implemented between the TCP and
application layer. SSL-enabled applications listen for client
connections on a different port than the usual port.
SSL Provides Encryption Services to Other Protocols
Lightweight Directory Access Protocol (LDAP) Network News Transfer Protocol (NNTP) Post Office Protocol v3 (POP3) Internet Message Access Protocol v4 (IMAP4)
Transport Layer Security (TLS)
Similar to SSL in that TLS provides communications privacy, authentication, and message integrity by using a combination of public key and symmetric encryption
Uses different encryption algorithms than SSL Is an IETF draft standard Used by Windows 2000 to encrypt smart card
authentication information transmitted when using Extended Authentication Protocol (EAP)
Supports the option of reverting to SSL support if needed
May replace SSL in the future
Deploying SSL and TLS
The server hosting the application that uses SSL or TLS must acquire a private/public key pair for encrypting the data.
The benefit of using application-level security is that the encryption requires no additional work by the user.
The only noticeable change is https: in the URL rather than http:.
Encryption Process for Web-Based Applications
Making the Decision: Designing Application-Level Encryption Using SSL and TLS Enable secure Web communications. Enable secure Web communications for a public Web
site. Enable secure communications for a private Web site. Secure authentication to a Web site and support any
browser. Define the level of encryption to use for a Web site. Enable strong encryption at a Windows 2000 Web
server. Enable strong encryption at a Windows client. Minimize reduction in performance due to encryption
of transmitted data.
Applying the Decision: Designing Application-Level Encryption for Fabrikam Inc. Ensure that information entered into or
downloaded from Web pages stored on the three separate Web sites is not compromised during transmission.
Defense Department bidding Web site Sonar project time sheet Web site The Sonar System project server
Chapter Summary
Providing authenticity and integrity of transmitted data
Planning SMB signing Planning digital signing Planning secure e-mail encryption Planning application-level encryption with
SSL/TLS