Adding a firewall to your internetwork

Adding a firewall to your internetwork. To isolate internal data packets from exposure to the Internet, you can add a network firewall. This also helps protect random Internet traffic from entering your internetwork.
See also:
Authentication Services
Use SSL to Enhance Security of Network Communication
Cryptography
Certificates
Secure Your Wireless Network
Unlike wired networks, wireless networks can reach beyond the walls of buildings. In many deployments, wired network security depends on the physical security of the networks behind locked doors of the buildings. You need to pass through the building security to get access to the network. On the other hand, wireless networks can be monitored and attacked from outside the walls of buildings.
To mitigate security risks, many wireless networks provide ways to encrypt transmissions. You can use simple static encryption (WEP) network keys or more advanced techniques that generate and rotate the WEP keys to help provide privacy. For the most advanced protection, specifically for 802.11, you should use 802.1X industry standard as defined by the Institute of Electrical and Electronics Engineers, Inc. (IEEE). It provides for individual authentication and enhanced privacy by being able to generate and plug in WEP keys. Furthermore, these WEP keys can be generated per user and rotated often based on the policy. For detailed information, see the IEEE Web site.
Note: 802.1X is intended only for enterprise deployments. Windows CE does not support mutual authentication in wireless networks.
Windows CE uses a number of authentication methods that can be plugged in to 802.1x to customize the authentication methods. You can use simple user name and passwords, certificates, smart cards, or biometrics. The EAP-MD5 supports user name and passwords and the EAP-TLS supports certificate-based authentication. You can also develop your own authentication scheme. For more information, see 802.1x Authentication and the IEEE Web site.
You should be aware of another potential security risk that is not software related. Basic interference can cause a network to slow down or stop altogether, if the RF spectrum of the network is jammed with RF noise. Although this intrusion does not compromise privacy, it poses a denial of service risk. You should work with your wireless vendor to determine the best approach to mitigate this risk.
Use Authentication
You can control access to the device and services only to authorized users by implementing authentication protocols available in Windows CE. Some are built into the feature and others require you to add features to your operating system. For example, if your want to use NTLM SSP and/or Kerberos SSP, you need to add these features to your operating system. NTLM and Kerberos are implemented through the Security Support Provider Interface (SSPI).
SSPI is available through the Secur32.dll module, which is a well-defined, commonly used API for obtaining integrated security services for authentication, message integrity and enhanced message privacy. It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries (DLLs) containing different authentication and cryptographic data schemes. These DLLs are called Security Support Providers (SSPs).
The following illustration shows the relationship of the SSP DLLs to the SSPI Secur32.dll, Winsock and WinInet.
Figure 1. Windows CE SSP DLLs
The available SSPs in Windows CE are:
Microsoft Windows NT LAN Manager SSP (NTLM SSP). NTLM SSP is based on Microsoft Windows NT LAN Manager challenge/response and NTLM version 2 authentication protocols used on networks running versions of Windows NT operating system or Windows CE servers.
Kerberos SSP. The Kerberos protocol defines how clients interact with a network authentication service. The Kerberos authentication protocol provides a mechanism for mutual authentication between entities before a secure network connection is established.
Note that some schemes are more secure than others. You should keep in that Basic authentication is much weaker than Kerberos when you are determining which scheme best fits the needs of the application.
The following list summarizes the authentication best practices:
Use the StartUI component to password-protect a device. Without password protection, anyone can use the device and potentially gain access to resources on a network.
Enable device-locking capabilities to require a password to access a device while it is powered on.
If you need to keep user credentials on the device, save them in the registry. For best protection, do not store user credentials on the device. This prevents hackers from extracting the network credentials from the device if the device is stolen.
If you want to allow users to save authentication information on a device, use Credential Manager. However, you can increase the level of protection if you do not save user credentials on the device itself. If the application is using the Credential Manager, you can set the DisallowSavedNetworkPasswords registry value to 1. This prevents hackers from extracting the network credentials from the device in case the device is stolen.
Use smart cards to store user credentials. This prevents hackers from extracting the network credentials from the device in case the device is stolen.
Use NTLM SSP or Kerberos SSP in client-server applications. The client applications supply the user name, domain name and password and the server and client applications exchange tokens to complete the authentication.
Use Kerberos to provide mutual authentication between entities. This allows the server to authenticate the client and allows the client to authenticate the server. Note that NTLM does not provide mutual authentication.
Use a strong authentication protocol. When using NTLM SSP, you can specify the authentication protocols for the client and the server separately. To prevent NTLM SSP from using the weaker authentication protocol, set the LmCompatibilityLevelClient registry value to 3. This specifies that the client will only use NTLM v2 for authentication; however, authentication will fail if the server is not capable of NTLM v2 protocol. You can also set the LmCompatibilityLevelServer value to 2 or 3. This specifies that the server will only use NTLM v2; authentication will fail if the client is not capable of NTLM v2 protocol.
NTLM v2 authentication protocol is only available in Windows CE 4.1 and later. Servers running Microsoft Windows 2000 and later support NTLM v2.
Avoid authentication protocols that use clear text passwords. When using Lightweight Directory Access Protocol (LDAP), use NTLM or Negotiate instead of Basic authentication protocol. Basic uses clear text passwords.
Use ldap_bind_s function to use authentication services, such as NTLM or other Security Support Providers. The ldap_simple_bind function uses a clear text password for authentication. For more information, see LDAP Security Model.
See also:
Authentication Services
LDAP Client
Smart Card
Credential Manager
Use Credential Manager
You can use the Credential Manager to allow users the option to save authentication information on a device. When a Web site or another computer requests authentication through NTLM or Kerberos, an Update Default Credentials or Save Password check box appears in the Net UI dialog box. If the user selects the check box, the Credential Manager keeps track of the user's name, password and related information for the authentication service in use.
The next time that service is used, the Credential Manager automatically supplies the stored credential. If it is not accepted, the user is prompted for the correct access information. If access is granted, the Credential Manager overwrites the previous credential with the new one.
See also:
Credential Manager
CredRead
CredWrite
CredFree
Use SSL to Enhance Secure Network Communication
To enhance secure network communication, Windows CE also supports Secure Sockets Layer (SSL) 2.0, SSL 3.0 and SSL 3.1 security protocols, which are available through WinInet or directly from WinSock. SSL version 3.1 is also known as Transport Layer Security (TLS). These applications use secure sockets to send and receive encoded data over the communication lines.
Secure socket implementation relies on authentication to determine if a remote host can be trusted. Remote hosts establish their trustworthiness by obtaining a certificate from a certification authority (CA). The CA can, in turn, have certification from a higher authority and so on, creating a chain of trust. To determine whether a certificate is trustworthy, an application must determine the identity of the root CA and then determine if it is trustworthy.
Windows CE based SSL uses trusted CAs. When a secure connection is attempted by an application, SSL extracts the root certificate from the certification chain and checks it against the CA database. It delivers the server certificate to the application through a certificate validation callback function, along with the results of the comparison against the CA database. You can modify the default SSL behavior by modifying the registry keys. The base registry key is HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL.
Applications bear the ultimate responsibility for verifying that a certificate is acceptable. Applications can accept or reject any certificate. If a certificate is rejected, the connection is not completed. At a minimum, a certificate should meet the following requirements:
The certificate must be current
The identity in the certificate must match the destination identity.
A list of root certificate authorities is included in the Schannel CA database. These root certificates expire and may need to be updated periodically. Adding certificates to the cryptoAPI store can also update the database.
The following root certificate authorities are included in the Windows CE root certificate store:
VeriSign/RSA Secure Server
VeriSign Class 1 Public Primary CA
VeriSign Class 2 Public Primary CA
VeriSign Class 3 Public Primary CA
GTE Cybertrust ROOT
ThawtePremium Server CA
Thawte Server CA
Entrust.net Secure Server CA
Entrust.net Premium Secure Server CA, also known as Entrust.net CA (2048)
CryptGenRandom'>See also:
Encrypt Data Using CryptoAPI
CryptoAPI provides services that enable application developers to add data encryption/decryption schemes, to authenticate using digital certificates, and to encode/decode to and from ASN.1 to their Microsoft Win32-based applications. Application developers can use the functions in CryptoAPI without detailed knowledge of the underlying implementation. CryptoAPI works with a number of cryptographic service providers (CSPs) that perform the actual cryptographic functions, such as encryption, decryption and key storage and security.
The three elements of the Microsoft cryptographic system are the operating system, the application and the CSP. Applications communicate with the operating system through the CryptoAPI layer and the operating system communicates with the CSPs through the cryptographic service provider interface (CSPI). The following illustration shows the concept.
Figure 2. CryptoAPI data encryption
CSPs are independent modules, usually DLLs that contain algorithms and perform all cryptographic operations. Ideally, CSPs are written to be independent of a particular application, so that any application will run with a variety of CSPs. In reality, however, some applications have specific requirements that require a customized CSP. OEMs can write their own CSP package and add it to the registry.
The following table shows the predefined CSPs included in Windows CE.
CSP
|
Description
|
RSA Base Provider
|
Supports digital signature and data encryption. It is considered to be a general-purpose cryptographic tool.
|
RSA Enhanced Provider
|
Supports 128-bit key encryption. It provides stronger security through longer keys and additional algorithms.
|
Smart Card CSP
|
Supports smart cards for Windows. A sample smart card CSP in source code can be found in the %_WINCEROOT%\Public\Common\Sdk\Samples\ directory. This CSP illustrates how to properly integrate a smart card with the various functions and services provided by CryptoAPI.
|
Applications can use CryptoAPI functions to:
Generate and exchange keys
Encrypt and decrypt data
Encode and decode certificates
Manage and enhance security of certificates
Create and verify digital signatures and compute hash
The capabilities provided by CryptoAPI 1.0 in Windows CE are very similar to those in Windows 2000 and Windows NT; however, only a subset of CryptoAPI 2.0 is supported. The following capabilities available in CryptoAPI 2.0 are supported in Windows CE: encoding and decoding digital certificates based on the X.509 standard and certificate management. The following capabilities are not supported: tools to manage certificate revocation lists (CRLs) and certificate trust lists (CTLs), low-level messaging functions, and simplified messaging functions.
Coredll.lib exports CryptoAPI 1.0 functions and Crypto32.lib exports the CryptoAPI 2.0 functions; all these functions are defined in the Wincrypt.h header file.
The following table shows the algorithms the CSPs contain and their descriptions.
Algorithm
|
Description
|
CALG_3DES
|
Triple DES encryption algorithm.
|
CALG_3DES_112
|
Two-key triple DES encryption.
|
CALG_DES
|
DES encryption algorithm.
|
CALG_HMAC*
|
MAC keyed-hash algorithm.
|
CALG_MAC*
|
MAC keyed-hash algorithm.
|
CALG_MD2*
|
MD2 hashing algorithm.
|
CALG_MD4
|
MD4 hashing algorithm.
|
CALG_MD5*
|
MD5 hashing algorithm.
|
CALG_RC2*
|
RC2 block encryption algorithm.
|
CALG_RC4*
|
RC4 stream encryption algorithm.
|
CALG_RC5
|
RC5 block encryption algorithm.
|
CALG_RSA_KEYX*
|
RSA public-key exchange algorithm.
|
CALG_RSA_SIGN*
|
RSA public-key signature algorithm.
|
CALG_SHA*
|
SHA hashing algorithm.
|
CALG_SHA1*
|
Same as CALG_SHA.
|
CALG_SSL3_SHAMD5
|
SLL3 client authentication algorithm used by the schannel.dll operations system. This ALG_ID should not be used by applications.
|
* Algorithms supported by the Microsoft Base Cryptographic
Best practices
If possible, do not save sensitive data in RAM, the file system, or the registry. The following list shows best practices to use if you must save sensitive data:
Cache the data to process memory rather than to the registry or file system.
Allow the user to choose whether to save sensitive information, such as credentials. The registry setting HKEY_LOCAL_MACHINE\Comm\Security\DisallowSavedNetworkPasswords identifies whether the option to save credentials is displayed. When the value is 1, no option to save credentials is displayed. When the value is 0, the user interface (UI) allows the user to save credentials.
Encrypt and decrypt application data by using CryptProtectData_and_CryptUnprotectData_.__Note'>CryptProtectData and CryptUnprotectData.
Note: Although CryptProtectData and CryptUnprotectData use entropy, the encryption is only as strong as the data supplied for encryption. It is important to supply a strong password. A user who supplies a weak password can weaken the effectiveness of encryption.
Clear data from temporary storage after use.
When appropriate, the application should obtain an additional password or other secret data from the user, and then use pOptionalEntropy to supply the information to CryptProtectData and CryptUnprotectData.
See also:
Cryptography
Certificates
Use the Protected Store API
To help protect sensitive information and to prevent data tampering, the protected store API provides a convenient solution to cryptography, key management and user experience issues. The two CryptoAPI functions,
CryptProtectData and CryptUnprotectData, take the user's logon credentials to lock and unlock the private data.
Typically, only a user with logon credentials matching those of the encrypter can decrypt the data. In addition, decryption must be done on the computer where the data was encrypted.
The benefits of the protected store include the following:
An easy-to-use application that takes data and optional password or other entropy and receives shrouded data.
Enhanced data protection from other users who are able to log on to the same device.
Enhanced data protection from tampering while the device is offline.
The transparent use of logon credentials to supply the entropy for data protection.
OEM extensibility that allows the use of hardware tokens such as smart cards or biometric devices.
See also:
Generate Random Data Using CryptGenRandom
Use CryptGenRandom to generate random data. This function has two of the properties of a good random number generator: unpredictability and even value distribution.
On a Windows CE device, entropy is generated for CryptGenRandom by the following sources:
Thread and kernel switches (CeGetRandomSeed)
The current process identifier (GetCurrentProcessId)
The current thread identifier (GetCurrentThreadId)
Ticks since boot (GetTickCount)
Current time (GetLocalTime)
Memory information (GlobalMemoryStatus)
Object store statistics (GetStoreInformation)
All of this information is added to a buffer, which is hashed using MD4 and used as the key to modify a buffer, using RC4, provided by the user.
If Cryptography Services features are not included in your platform, you can also use CeGenRandom to generate random numbers.
Isolate Sensitive Data in a Smart Card
You can add an additional layer of security to a Windows CE device by using smart cards to store authentication information or a digital signing mechanism. You can write a custom CryptoAPI provider that exploits a smart card's ability to store information with enhanced security.
The Windows CE smart card subsystem supports CryptoAPI through smart card service providers (SCSPs), which are DLLs that enable access to specific services. The subsystem provides a link between the smart card reader hardware and the applications. Windows CE does not provide SCSPs; typically, the smart card vendor provides the appropriate SCSPs. However, Windows CE provides the interfaces described in the following table.
Subsystem component
|
File
|
Description
|
Resource manager
|
Scard.dll
|
Uses the Win32 APIs to manage access to multiple readers and smart cards.
|
Resource manager helper library
|
Winscard.dll
|
Exposes PC/SC services for using smart cards and smart card readers.
|
Smart card reader helper library
|
Smclib.lib
|
Provides common smart card driver support routines and additional T=0 and T=1 protocol support to specific drivers as needed.
|
Sample smart card reader drivers
|
Pscr.dllbulltlp3.dllstcusb.dll
|
SwapSmart PC reader driver. Serial reader driver. Universal serial bus (USB) reader driver.
|
A typical smart card system consists of applications, a subsystem that handles communication between smart card readers and the applications, readers and the smart card.
Implementing a fraction of the smart card CryptoAPI service provider functionality in a separate hardware keeps the cryptographic keys and operations safer because it:
Provides tamper-resistant storage for helping to protect private keys and other forms for personal information.
Isolates security-critical computations involving authentication, digital signatures and key exchange from other parts of the system.
Enables portability of credentials and other private information.
In an organization that uses smart cards, users do not have to remember any passwords at all, only a personal identification number, and they can use the same certificate for other security purposes, such as digitally signing email.
See also:
Practice Secure Coding Techniques
The book Writing Secure Code by Michael Howard and David LeBlanc, Microsoft Press, 2002, is an excellent source of secure programming best practices. The book discusses the vulnerabilities of applications to malicious attacks and shows examples of code defects.
One important issue discussed in the book and often overlooked by application developers is buffer overruns. You should avoid using the following C/C++ functions. These functions can cause buffer overruns and cause your application to fail or enable code to be injected into your process space:
strcpy
strcat
memcpy
gets
sprintf
scanf
Be especially careful if you call any of the listed functions to copy data into a stack-based buffer. Generally, it is much easier to execute malicious code when the buffer is allocated on the stack, rather than memory allocated on the heap. For more information about buffer overruns and other techniques for writing secure code, refer to Writing Secure Code, by Michael Howard and David LeBlanc, Microsoft Press Books, 2002.
As the OEM or application developer, you can use samples, such as VMini for sharing your ethernet network and debugging connections, to quickly build and test your application or operating system. To help protect against these types security vulnerabilities, before you ship your product, you must replace the samples with your own application code.
|