Ensure that binaries are obfuscated if they contain sensitive information
Title
Details
Component
Machine Trust Boundary
SDL Phase
Deployment
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Ensure that binaries are obfuscated if they contain sensitive information such as trade secrets, sensitive business logic that should not reversed. This is to stop reverse engineering of assemblies. Tools like CryptoObfuscator may be used for this purpose.
Consider using Encrypted File System (EFS) is used to protect confidential user-specific data
Title
Details
Component
Machine Trust Boundary
SDL Phase
Build
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Consider using Encrypted File System (EFS) is used to protect confidential user-specific data from adversaries with physical access to the computer.
Ensure that sensitive data stored by the application on the file system is encrypted
Title
Details
Component
Machine Trust Boundary
SDL Phase
Deployment
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Ensure that sensitive data stored by the application on the file system is encrypted (e.g., using DPAPI), if EFS cannot be enforced
Ensure that sensitive content is not cached on the browser
Title
Details
Component
Web Application
SDL Phase
Build
Applicable Technologies
Generic, Web Forms, MVC5, MVC6
Attributes
N/A
References
N/A
Steps
Browsers can store information for purposes of caching and history. These cached files are stored in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When these pages are referred again, the browser displays them from its cache. If sensitive information is displayed to the user (such as their address, credit card details, Social Security Number, or username), then this information could be stored in browser's cache, and therefore retrievable through examining the browser's cache or by simply pressing the browser's "Back" button. Set cache-control response header value to "no-store" for all pages.
This may be implemented through a filter. Following example may be used:
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (filterContext == null || (filterContext.HttpContext != null && filterContext.HttpContext.Response != null && filterContext.HttpContext.Response.IsRequestBeingRedirected))
{
//// Since this is MVC pipeline, this should never be null.
return;
}
var attributes = filterContext.ActionDescriptor.GetCustomAttributes(typeof(System.Web.Mvc.OutputCacheAttribute), false);
if (attributes == null || **Attributes**.Count() == 0)
{
filterContext.HttpContext.Response.Cache.SetNoStore();
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddHours(-1));
if (!filterContext.IsChildAction)
{
filterContext.HttpContext.Response.AppendHeader("Pragma", "no-cache");
}
}
base.OnActionExecuting(filterContext);
}
Encrypt sections of Web App's configuration files that contain sensitive data
Configuration files such as the Web.config, appsettings.json are often used to hold sensitive information, including user names, passwords, database connection strings, and encryption keys. If you do not protect this information, your application is vulnerable to attackers or malicious users obtaining sensitive information such as account user names and passwords, database names and server names. Based on the deployment type (azure/on-prem), encrypt the sensitive sections of config files using DPAPI or services like Azure Key Vault.
Explicitly disable the autocomplete HTML attribute in sensitive forms and inputs
The autocomplete attribute specifies whether a form should have autocomplete on or off. When autocomplete is on, the browser automatically complete values based on values that the user has entered before. For example, when a new name and password is entered in a form and the form is submitted, the browser asks if the password should be saved.Thereafter when the form is displayed, the name and password are filled in automatically or are completed as the name is entered. An attacker with local access could obtain the clear text password from the browser cache. By default autocomplete is enabled, and it must explicitly be disabled.
Ensure that sensitive data displayed on the user screen is masked
Title
Details
Component
Web Application
SDL Phase
Build
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Sensitive data such as passwords, credit card numbers, SSN etc. should be masked when displayed on the screen. This is to prevent unauthorized personnel from accessing the data (e.g., shoulder-surfing passwords, support personnel viewing SSN numbers of users) . Ensure that these data elements are not visible in plain text and are appropriately masked. This has to be taken care while accepting them as input (e.g,. input type="password") as well as displaying back on the screen (e.g., display only the last 4 digits of the credit card number).
Implement dynamic data masking to limit sensitive data exposure non privileged users
The purpose of dynamic data masking is to limit exposure of sensitive data, preventing users who should not have access to the data from viewing it. Dynamic data masking does not aim to prevent database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complementary to other SQL Server security features (auditing, encryption, row level security…) and it is highly recommended to use this feature in conjunction with them in addition in order to better protect the sensitive data in the database. Please note that this feature is supported only by SQL Server starting with 2016 and Azure SQL Database.
Ensure that passwords are stored in salted hash format
Passwords should not be stored in custom user store databases. Password hashes should be stored with salt values instead. Make sure the salt for the user is always unique and you apply b-crypt, s-crypt or PBKDF2 before storing the password, with a minimum work factor iteration count of 150,000 loops to eliminate the possibility of brute forcing.
Ensure that sensitive data in database columns is encrypted
Sensitive data such as credit card numbers has to be encrypted in the database. Data can be encrypted using column-level encryption or by an application function using the encryption functions.
Ensure that database-level encryption (TDE) is enabled
Transparent Data Encryption (TDE) feature in SQL server helps in encrypting sensitive data in a database and protect the keys that are used to encrypt the data with a certificate. This prevents anyone without the keys from using the data. TDE protects data "at rest", meaning the data and log files. It provides the ability to comply with many laws, regulations, and guidelines established in various industries.
SQL Server has the ability to encrypt the data while creating a backup. By specifying the encryption algorithm and the encryptor (a Certificate or Asymmetric Key) when creating a backup, one can create an encrypted backup file.
Ensure that sensitive data relevant to Web API is not stored in browser's storage
Title
Details
Component
Web API
SDL Phase
Build
Applicable Technologies
MVC 5, MVC 6
Attributes
Identity Provider - ADFS, Identity Provider - Microsoft Entra ID
References
N/A
Steps
In certain implementations, sensitive artifacts relevant to Web API's authentication are stored in browser's local storage. E.g., Microsoft Entra authentication artifacts like adal.idtoken, adal.nonce.idtoken, adal.access.token.key, adal.token.keys, adal.state.login, adal.session.state, adal.expiration.key etc.
All these artifacts are available even after sign out or browser is closed. If an adversary gets access to these artifacts, he/she can reuse them to access the protected resources (APIs). Ensure that all sensitive artifacts related to Web API is not stored in browser's storage. In cases where client-side storage is unavoidable (e.g., Single Page Applications (SPA) that leverage Implicit OpenIdConnect/OAuth flows need to store access tokens locally), use storage choices with do not have persistence. e.g., prefer SessionStorage to LocalStorage.
Example
The below JavaScript snippet is from a custom authentication library which stores authentication artifacts in local storage. Such implementations should be avoided.
ns.AuthHelper.Authenticate = function () {
window.config = {
instance: 'https://login.microsoftonline.com/',
tenant: ns.Configurations.Tenant,
clientId: ns.Configurations.AADApplicationClientID,
postLogoutRedirectUri: window.location.origin,
cacheLocation: 'localStorage', // enable this for Internet Explorer, as sessionStorage does not work for localhost.
};
Encrypt sensitive data stored in Azure Cosmos DB
Title
Details
Component
Azure Document DB
SDL Phase
Build
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Encrypt sensitive data at application level before storing in document DB or store any sensitive data in other storage solutions like Azure Storage or Azure SQL
Use Azure Disk Encryption to encrypt disks used by Virtual Machines
Azure Disk Encryption is a new feature that is currently in preview. This feature allows you to encrypt the OS disks and Data disks used by an IaaS Virtual Machine. For Windows, the drives are encrypted using industry-standard BitLocker encryption technology. For Linux, the disks are encrypted using the DM-Crypt technology. This is integrated with Azure Key Vault to allow you to control and manage the disk encryption keys. The Azure Disk Encryption solution supports the following three customer encryption scenarios:
Enable encryption on new IaaS VMs created from customer-encrypted VHD files and customer-provided encryption keys, which are stored in Azure Key Vault.
Enable encryption on new IaaS VMs created from the Azure Marketplace.
Enable encryption on existing IaaS VMs already running in Azure.
Secrets can be any sensitive information, such as storage connection strings, passwords, or other values that should not be handled in plain text. Use Azure Key Vault to manage keys and secrets in service fabric applications.
Perform security modeling and use Business Units/Teams where required
Title
Details
Component
Dynamics CRM
SDL Phase
Build
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Perform security modeling and use Business Units/Teams where required
Minimize access to share feature on critical entities
Title
Details
Component
Dynamics CRM
SDL Phase
Deployment
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Minimize access to share feature on critical entities
Train users on the risks associated with the Dynamics CRM Share feature and good security practices
Title
Details
Component
Dynamics CRM
SDL Phase
Deployment
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Train users on the risks associated with the Dynamics CRM Share feature and good security practices
Include a development standards rule proscribing showing config details in exception management
Title
Details
Component
Dynamics CRM
SDL Phase
Deployment
Applicable Technologies
Generic
Attributes
N/A
References
N/A
Steps
Include a development standards rule proscribing showing config details in exception management outside development. Test for this as part of code reviews or periodic inspection.
Use Azure Storage Service Encryption (SSE) for Data at Rest (Preview)
Azure Storage Service Encryption (SSE) for Data at Rest helps you protect and safeguard your data to meet your organizational security and compliance commitments. With this feature, Azure Storage automatically encrypts your data prior to persisting to storage and decrypts prior to retrieval. The encryption, decryption and key management is totally transparent to users. SSE applies only to block blobs, page blobs, and append blobs. The other types of data, including tables, queues, and files, will not be encrypted.
Encryption and Decryption Workflow:
The customer enables encryption on the storage account
When the customer writes new data (PUT Blob, PUT Block, PUT Page, etc.) to Blob storage; every write is encrypted using 256-bit AES encryption, one of the strongest block ciphers available
When the customer needs to access data (GET Blob, etc.), data is automatically decrypted before returning to the user
If encryption is disabled, new writes are no longer encrypted and existing encrypted data remains encrypted until rewritten by the user. While encryption is enabled, writes to Blob storage will be encrypted. The state of data does not change with the user toggling between enabling/disabling encryption for the storage account
All encryption keys are stored, encrypted, and managed by Microsoft
Please note that at this time, the keys used for the encryption are managed by Microsoft. Microsoft generates the keys originally, and manage the secure storage of the keys as well as the regular rotation as defined by internal Microsoft policy. In the future, customers will get the ability to manage their own encryption keys, and provide a migration path from Microsoft-managed keys to customer-managed keys.
Use Client-Side Encryption to store sensitive data in Azure Storage
The Azure Storage Client Library for .NET Nuget package supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The library also supports integration with Azure Key Vault for storage account key management. Here is a brief description of how client side encryption works:
The Azure Storage client SDK generates a content encryption key (CEK), which is a one-time-use symmetric key
Customer data is encrypted using this CEK
The CEK is then wrapped (encrypted) using the key encryption key (KEK). The KEK is identified by a key identifier and can be an asymmetric key pair or a symmetric key and can be managed locally or stored in Azure Key Vault. The Storage client itself never has access to the KEK. It just invokes the key wrapping algorithm that is provided by Key Vault. Customers can choose to use custom providers for key wrapping/unwrapping if they want
The encrypted data is then uploaded to the Azure Storage service. Check the links in the references section for low-level implementation details.
Encrypt sensitive or PII data written to phones local storage
If the application writes sensitive information like user's PII (email, phone number, first name, last name, preferences etc.)- on mobile's file system, then it should be encrypted before writing to the local file system. If the application is an enterprise application, then explore the possibility of publishing application using Windows Intune.
Example
Intune can be configured with following security policies to safeguard sensitive data:
Require encryption on mobile device
Require encryption on storage cards
Allow screen capture
Example
If the application is not an enterprise application, then use platform provided keystore, keychains to store encryption keys, using which cryptographic operation may be performed on the file system. Following code snippet shows how to access key from keychain using xamarin:
protected static string EncryptionKey
{
get
{
if (String.IsNullOrEmpty(_Key))
{
var query = new SecRecord(SecKind.GenericPassword);
query.Service = NSBundle.MainBundle.BundleIdentifier;
query.Account = "UniqueID";
NSData uniqueId = SecKeyChain.QueryAsData(query);
if (uniqueId == null)
{
query.ValueData = NSData.FromString(System.Guid.NewGuid().ToString());
var err = SecKeyChain.Add(query);
_Key = query.ValueData.ToString();
}
else
{
_Key = uniqueId.ToString();
}
}
return _Key;
}
}
Obfuscate generated binaries before distributing to end users
Generated binaries (assemblies within apk) should be obfuscated to stop reverse engineering of assemblies.Tools like CryptoObfuscator may be used for this purpose.
Set clientCredentialType to Certificate or Windows
Using a UsernameToken with a plaintext password over an unencrypted channel exposes the password to attackers who can sniff the SOAP messages. Service Providers that use the UsernameToken might accept passwords sent in plaintext. Sending plaintext passwords over an unencrypted channel can expose the credential to attackers who can sniff the SOAP message.
Example
The following WCF service provider configuration uses the UsernameToken:
No transport or message security has been defined. Applications that transmit messages without transport or message security cannot guarantee the integrity or confidentiality of the messages. When a WCF security binding is set to None, both transport and message security are disabled.
Example
The following configuration sets the security mode to None.
Security Mode Across all service bindings there are five possible security modes:
None. Turns security off.
Transport. Uses transport security for mutual authentication and message protection.
Message. Uses message security for mutual authentication and message protection.
Both. Allows you to supply settings for transport and message-level security (only MSMQ supports this).
TransportWithMessageCredential. Credentials are passed with the message and message protection and server authentication are provided by the transport layer.
TransportCredentialOnly. Client credentials are passed with the transport layer and no message protection is applied. Use transport and message security to protect the integrity and confidentiality of messages. The configuration below tells the service to use transport security with message credentials.