Quick Security Reference:Exposure of Sensitive Information

November 15, 2010 For the latest information, please see http://www.microsoft.com/sdl.

For the latest information, please see http://www.microsoft.com/sdl.

This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious.  No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.© 2010 Microsoft Corporation. All rights reserved. 

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

Quick Security Reference: Exposure of Sensitive Information

Contents

Overview.................................................................................1

What Are Personas..................................................................3Business Decision Maker 3Architect 3Developer 3Tester/QA 3

Understanding Exposure of Sensitive Information Issues for the Business Decision Maker......................................................................................4Risk 4Business Impact 5Resources for Business Decision Makers 6

Understanding Exposure of Sensitive Information Issues for the Architect 6Identifying the Problem 6Common Attacks 6Implementing Defenses 6

Mitigations 8Resources for Architects 11

Understanding Exposure of Sensitive Information Issues for the Developer 12Insecure Scrubbing 13

Setting DACLs Programmatically 14Resources for Developers 14

Understanding Exposure of Sensitive Information Issues for the Tester/QA 15Resources for Testers 15

Exposure of Sensitive Information and the SDL.......................15Long-Term Solutions 16

Conclusion.............................................................................16

Acknowledgements................................................................16

Quick Security Reference: Exposure of Sensitive Information

OVERVIEWFailure to properly protect sensitive data can be difficult to recognize during application development, but it is a common weakness used by attackers to steal sensitive information. In this paper, sensitive information is defined as: Privileged or proprietary information which, if compromised through alteration, corruption, loss, misuse, or unauthorized disclosure, could cause serious harm to the organization or individual owning it.1

Two current vulnerability catalogs, the Open Web Application Security Project (OWASP) Top 10 and the Common Weakness Enumeration (CWE) Top 25, both list vulnerabilities resulting from exposure of sensitive information as common vulnerabilities:

OWASP Top 10 2007 and OWASP Top 10 2010—A9 Insecure Cryptographic Storage2 2010 CWE/SANS Top 25 Most Dangerous Software Errors—CWE-311 Missing

Encryption of Sensitive Data3 CWE-312 Cleartext Storage of Sensitive Information CWE-319 Cleartext Transmission of Sensitive Information CWE-284: Access Control (Authorization) Issues

The prevalence of exposure of sensitive information vulnerabilities is often increased by software developers attempting to protect sensitive data with inappropriate controls that offer little or no real protection. Sensitive, confidential, or personally identifiable information (PII) can be exposed through a variety of paths. This paper covers how to identify and help prevent vulnerabilities caused by exposure of sensitive information in software for sensitive data at rest (for example, in a database) or when it is transmitted across a network.

1 http://www.businessdictionary.com/definition/sensitive-information.html2 http://www.owasp.org/index.php/OWASP_Top_Ten_Project3 http://cwe.mitre.org/top25/

Quick Security Reference: Exposure of Sensitive Information 1

Figure 1. Multiple points where sensitive data can be exposed by an application

This Quick Security Reference (QSR) paper can be used by each member of an organization to gain a more thorough understanding of how to identify and address exposure of sensitive information vulnerabilities in software. By better understanding these vulnerabilities, one can more easily and efficiently deal with existing issues and implement ongoing solutions that help protect sensitive information and the users of that information.

Quick Security Reference: Exposure of Sensitive Information 2

WHAT ARE PERSONASEvery person from the business decision maker (BDM), to the architect, to the developer, to the tester/quality assurance (QA) must play a role in addressing this issue. However, each person must approach the problem from the appropriate perspective to ensure that they have a clear plan for addressing how to better protect data, successfully verifying the solution, and mitigating problems that may arise in the future. This paper uses four basic personas in an engineering organization—business decision maker, architect, developer, and tester/QA. The goal of this paper is to address the key questions that each persona might ask regarding protecting sensitive data and provide direction to each persona on how to address the issue. The personas are defined in the following paragraphs.

Business Decision Maker In charge of delivering the development project from start to finish, on time, and

within budget. Aware of the fact that security is a customer-satisfaction and cost-management

issue. Needs to understand security issues at a high level to make overall project planning

decisions, including budget and justification of time and resource investments toward secure development.

Architect In charge of the technical design of the development project. Cares about security from a standpoint of overall project integrity. Understands security concepts in enough detail to avoid creating a blueprint that

would result in security issues. Responsible for establishing the core principles that developers use to meet the

functional goals of the project, managing awareness of security issues as they relate to the specific solution, and tracking and verifying fixes to potentially costly security mistakes in code before release.

Developer In charge of taking the architectural blueprints for the development project and

implementing them in code. Fixes security vulnerabilities that result from coding errors. Understands secure coding best practices in detail and gathers supporting technical

content, such as approved libraries, to write secure code correctly and consistently.

Tester/QA In charge of acting as the quality gatekeeper and managing the last step before a

development project is completed. Ensures that any security issues that may have slipped through previous steps are

caught before the application is released.

Quick Security Reference: Exposure of Sensitive Information 3

Executes security testing (different from functional testing) to attempt to make the application do things that it was not designed to do. If successful, these tests may represent potential vulnerabilities.

Maintains a detailed understanding of attack techniques and a bit of the creative “attacker’s mindset.”

UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE BUSINESS DECISION MAKER

RiskThe business risks associated with accidental or malicious exposure of sensitive information can result in high-impact financial loss—and potentially more damaging—a negative impact on customer perception and business integrity. In recent years, regulatory requirements around protecting such data have increased as digital record keeping and financial transactions have become prevalent in society. Regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the Payment Card Industry Data Security Standard (PCI/DSS) have made strides in closing the risk gap in these industries, but such regulations often lack tangible security guidance to enable developers to mitigate common vulnerabilities in software. It is imperative that a company that passes sensitive information over a network or allows remote access to a database containing sensitive information takes precautions to avoid potential attacks that take advantage of the exposure of sensitive

information.

Quick Security Reference: Exposure of Sensitive Information 4

Figure 2. Distribution and evolution of the six most prevalent impact classes since 2005. The plots include a linear extrapolation for 2010 based on the data of the first half of 2010. [Source: Secunia Half Year Report 2010]

Business ImpactThe financial impact of security breaches that result from loss of customers’ sensitive information has become a reality in today’s business world. Financial loss is only one of the significant ways exposure of sensitive information can negatively impact a business. Legal impact and loss of customer trust quite often accompany the financial risks. This is not a legal document and does not provide legal guidance, but legal issues are real, and business decision makers should consult with their legal counsel to evaluate the legal risks to the organization if sensitive information is leaked. The “loss of customer trust” impact is largely intangible. There is no simple formula to determine what “loss of customer trust” means nor what the financial impact might be as customers move their business to a company that is perceived to be more trustworthy. There have been a number of high profile computer-system security breaches that have led to exposure of sensitive information in recent years. Some examples of incidents relating to information leakage include the following:

In 2010, a coding error in an AT&T website led to the disclosure of thousands of email addresses belonging to Apple iPad users.4

In 2007, TJX—the owner of T.J. Maxx, Marshalls, HomeGoods and A.J. Wright stores in the United States and Puerto Rico and Winners and HomeSense stores in Canada—acknowledged that online attackers had stolen credit and debit card data from its processing systems due to weaknesses in the encryption system used in their Wi-Fi networks.5

In 2006, Visa, MasterCard, and American Express gave out radio-frequency identification (RFID) credit cards that promised 128-bit encryption, but didn’t actually turn it on.6

In 1999, Microsoft “encrypted” the user password in Windows CE by encoding it with the word “PEGASUS” spelled backwards.7

It’s very hard to put a cost on security breaches that lead to exposure of sensitive information, but an article written by David Hobson points out some costs from real events.8 Finally, there are potential regulatory implications. For example, if a company processes credit cards, they must comply with PCI/DSS, including:

4 http://www.reuters.com/article/idUSTRE65960S20100611 5 http://www.crn.com/security/198701183;jsessionid=J5Q3CQJDQ2HXRQE1GHPCKH4ATMY32JVN6 http://www.privacydigest.com/topic/rfid/2006/10/24.html7 http://www.resonant.org/text/security/nt-activesync-security-artsusageP.htm8 http://www.scmagazineus.com/the-real-cost-of-a-security-breach/article/113717/

Quick Security Reference: Exposure of Sensitive Information 5

Requirement 3: Protect stored cardholder data. Requirement 4: Encrypt transmission of cardholder data across open, public

networks.

Quick Security Reference: Exposure of Sensitive Information 6

Resources for Business Decision Makers Top ten tips for protecting consumers' sensitive data from malicious employees PCI/DSS resource material

Even if a company does not handle payment cards, the concepts are still valid when applied to other forms of potentially sensitive information.

UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE ARCHITECT

Identifying the ProblemAn architect must start by identifying and understanding the nature of all information maintained by the system, and how that information is stored and transmitted. Similarly, it is also important to understand the potentially sensitive nature of text used in error messages and other status information that is delivered to an end user. In some cases, the information presented in the text of error/status alerts might provide an attacker with useful system or end user information that enables an attack.Sensitive information requires better and more complete protection than non-sensitive information. Although non-sensitive information should be given appropriate protections, it will require more time and resources to ensure that security measures for sensitive information are properly implemented.

Common AttacksThe two most common attack scenarios that take advantage of exposed sensitive information are direct attacks to gain unauthorized access to data and opportunistic use of error messages or status information to disclose paths to sensitive data. The first scenario is when an attacker actively attempts to compromise the information source. In either case, the attacker’s goal from the outset is unauthorized access. The second scenario is more opportunistic. Information that leaks through error messages and other status information can often be discovered by an attacker and used as a path for enabling further attacks. The information leaked in messages is usually not confidential, but including internal IP addresses or file system path data might be useful to an attacker to aid further attack.. For example, if an error message had the following text, “File abc.txt not found in c:\apps\web\files,” then the attacker knows part of the server’s directory structure and can use the folder name information to read other parts of the server’s hard drive.

Implementing DefensesImplementing correct defenses to mitigate exposure of sensitive information vulnerabilities involves first identifying how the data has been exposed, and then coming up with appropriate mitigations to close the holes. The process steps are:

Quick Security Reference: Exposure of Sensitive Information 7

Example: An attacker could access a network through a weak Wi-Fi access point or take advantage of a SQL injection vulnerability to access the sensitive information.

1. Build or analyze an up-to-date threat model.2. Itemize all data stores and data flows in the threat model.3. Determine which of these data flows and data stores could potentially expose

sensitive data.The first step is to consult or create an accurate and up-to-date threat model for the application in question. Because all data stores and data flows in the threat model are subject to information disclosure (the “I” in STRIDE) threats, the architect must determine which of the data stores holds sensitive information, and those that do must be called out as requiring special attention to make sure the data is not leaked. Figure 3 shows the threat model in some detail.

Figure 3. A sample database-driven web application threat model

The threat model shows how a request flows from the user (1.0) all the way through a browser, to the web server and database server and how the response flows back. All requests are logged (16.0 and 17.0) and the system is managed by admins (15.0) using an administration and configuration tool (14.0).A close look at this diagram shows the following data stores:

7.0 Browser configuration

Quick Security Reference: Exposure of Sensitive Information 8

9.0 Web server configuration 10.0 Web pages 12.0 Database server configuration 13.0 Customer data 17.0 Audit logs

And the following data flows: 2.0 -> 8.0 (Browser to web server) 8.0 -> 2.0 (Web server to browser) 8.0 -> 11.0 (Web server to database server) 11.0 -> 8.0 (Database server to web browser)

There are many data flows in the example threat model, but we have only itemized the four highest risk flows. The data flows are high risk because they cross trust boundaries and should be analyzed first. In a typical threat modeling exercise, all data flows should be analyzed for risk to determine if sensitive data could leak to an untrusted user. Now that a list of data stores and data flows is established, the architect must determine which of these could potentially hold sensitive, confidential, or personal information. For this example, it is assumed that the customer data held in 13.0 is confidential and the audit log data in 17.0 is sensitive. Both must be protected. But the process is not complete yet because there is a path from 13.0 to 1.0, and all data flows on that path must also be protected. In the interests of brevity, this example focuses on the data flow from 13.0 to 1.0. If it is not necessary to protect a data flow, then the threat model must explicitly explain why the data flow need not be protected from disclosure. In this instance, the potentially sensitive customer data from 13.0 finds its way on to the data flow from 8.0 (web server) to 2.0 (web browser), and the data flow crosses a trust boundary—in this case, the data traverses the Internet. Clearly, this data must be protected from disclosure.

MitigationsInformation disclosure threats are mitigated with confidentiality technologies—such as encryption—and access control mechanisms—such as permissions and access control lists (ACLs.) For highly sensitive data at rest, a combination of permissions and encryption is generally the preferred solution. If possible, the system should use the infrastructure within the operating system. For example, the preferred solution on Windows® is to use the Data Protection API (DPAPI) for encryption and discretionary access control lists (DACLs) for access control. When data is held in a database, DPAPI can still be used to encrypt the data as long as there is no requirement for the database engine to search or analyze the data because the DPAPI blob is opaque to the database engine. If the data must be queried or analyzed by the database engine, then the architect should use the encryption services available within the database engine.There are some scenarios where DPAPI is not the appropriate solution. Examples include:

Quick Security Reference: Exposure of Sensitive Information 9

Important: Any data flow that crosses a trust boundary should be scrutinized for potential data leakage issues.

DPAPI is not available on the target platform (for example, Windows Azure, Linux or Mac OS X)

DPAPI is not available in the application (for example, IBM DB2)

Encryption and decryption must occur in a server cluster.

Large amounts, no more than a few MB, of data must be encrypted.

If one or more of these scenarios applies to the application then lower-level encryption mechanisms must be employed as described in the next section.

Use EncryptionFor symmetric encryption, the Advanced Encryption Standard (AES) should be used rather than the Data Encryption Standard (DES), 3DES, or RC4 unless backward-compatibility with an older application that does not support AES is required.It is always necessary to make sure that any encryption mechanism uses good key management practices. A detailed look at encryption and key management is beyond the scope of this paper, but at a high level, good key management practices include:

Appropriate key generation (large keys with high entropy). Secure key storage and protection. Secure key exchange. Key updating.

Additional information about correct key management is available in Recommendation for Key Management – Part 1: General, published by the National Institute of Standard and Technology (NIST). Protecting data over a network requires the use of encryption. Access control mechanisms cannot be used because there is no process enforcing the access control policy. Like encryption for data at rest, use existing libraries and infrastructure where possible. For data on the network, this recommendation comes down to using Secure Sockets Layer (SSL)/Transport Layer Security (TLS) or Internet Protocol security (IPsec). Any other potential solution must be heavily analyzed and scrutinized by security professionals to make sure it’s secure enough.Continuing with the earlier threat model, this example assumes database column-level encryption rather than DPAPI (because the column must be queried) to protect the data at rest in 13.0, and uses SSL/TLS to mitigate the disclosure threat to the data as it travels from 2.0 -> 8.0 and 8.0 -> 2.0.Column-level encryption protects one or more columns in a database table. For example, a table named Customer might have the following columns:

ID Surname GivenName MiddleInitial

Quick Security Reference: Exposure of Sensitive Information 10

If you must encrypt a large amount of data, encrypt the data using custom code, and encrypt the encryption key using DPAPI.

EmailBut the architect considers the customer email address to be sensitive, so only the Email column is encrypted by the database engine.

Use Existing Tools Instead of Writing New CodeTaking advantage of reusable policy or infrastructure rather than writing new code is another mitigation. For example, if it makes sense to do so, use the Encrypting File System (EFS) in Windows to encrypt files rather than encrypting the data with application software. EFS offers many advantages, including strong cryptographic algorithms, sound key management, transparency to the application, and the ability to enforce an EFS policy company-wide.

Using ACLsData at rest should also be protected using ACLs, also known as Discretionary ACLs (DACLs). A DACL is a container that includes a list of access control entries (ACEs). Each ACE has a subject (for example, Users, Administrators, or FinanceDept) and defines what that subject can do to the object being protected. For example, a configuration file might have the following DACL:

Administrators: Full Control Users: Read.

This DACL, composed of two ACEs, means administrators on this computer can perform any operation on the configuration file—they can create a new one, delete it, read from it, or write to it. Users, on the other hand, can only read the file contents. If the configuration file contains sensitive information, such as a user account password, then perhaps Users: Read is a vulnerability and this ACE should be removed, leaving this simple DACL:

Administrators: Full ControlAn architect should be able to explain why every ACE is in a DACL. In other words, there should be a valid business rationale for each ACE. If an ACE cannot be vouched for, then it should be removed from the DACL.

Preventing Sensitive Leaks in Error MessagesAn effective way to mitigate the risk of leaking sensitive data through error messages is to funnel all errors and warnings through a single checkpoint in the application. This single checkpoint determines who sees what data. For example, a remote, unauthenticated user should see very little warning information. In contrast, a local administrator should see all information. Regardless of the user type, full error details should be written to an administrator-readable log file. An administrator can read the full error information to help determine why an operation failed. Creating an administrator-readable log file requires applying a DACL to the log file with the following ACEs:

Quick Security Reference: Exposure of Sensitive Information 11

Some operating systems, such as Linux, do not support DACLs by default and use a less fine-grained system called permissions .

Everyone (Write) Administrators (Full Control)

A file with this DACL is often called a “drop-box” because anyone can write to the file, but only trusted users can read the file.

Quick Security Reference: Exposure of Sensitive Information 12

The following C# code snippet takes a low-level .NET exception and a user identity, then logs the full error and returns an appropriate error string to display to the user:

string GetErrorFromException(Exception ex, WindowsPrincipal pr) { WriteToErrorLog(DateTime.Now, ex);

if (pr.IsInRole(WindowsBuiltInRole.Administrator)) { return ex.Message; } return "An error occurred. Please try again. " "If the error persists, please contact the administrator.";}

Resources for Architects How To: Use DPAPI (User Store) from ASP.NET 1.1 with Enterprise Services Windows Data Protection API (DPAPI) white paper by NAI Labs Uncovering Security Design Flaws Using the STRIDE Approach

Quick Security Reference: Exposure of Sensitive Information 13

UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE DEVELOPERSome key points about solutions were touched on in the Architect section, but the developer must make sure that the defenses designed to protect sensitive information are appropriately implemented and do not suffer from oversights that could open the system to attack, such as insecure key management and insecure key lengths or home-grown cryptographic algorithms. Examples of “what not to do” during implementation include:

Using non-random encryption keys. Hard-coding encryption keys in application code. Using small encryption keys. Using out-dated, home-grown, or insecure crypto algorithms.

In short, encryption keys must be protected like any other sensitive information and generated using appropriately secure mechanisms. Developers and architects must work very closely with BDMs to make sure that information is identified as sensitive and appropriate defenses put in place.If an application stores information in a file system or a web server or in the registry, then the developer should consider encrypting that information. Basic principles from the Microsoft Security Development Lifecycle (SDL)—see Exposure of Sensitive Information and the SDL later in this document—require that the developer use the Data Protection API (DPAPI) to do so.The following C/C++ code shows how to use DPAPI:

DATA_BLOB DataIn;DATA_BLOB DataOut;BYTE *pbDataInput = GetDataToEncrypt();DWORD cbDataInput = strlen((char *)pbDataInput)+1;DataIn.pbData = pbDataInput;DataIn.cbData = cbDataInput;if(CryptProtectData(

&DataIn,L"My stuff.", // A description stringNULL, // Optional entropy not used.NULL, // Reserved.NULL, // Pass NULL so there’s no prompt dataCRYPTPROTECT_AUDIT, // audit encrypt/decrypt events&DataOut)) {// all worked

} else {// Errorexit(1);

}

Quick Security Reference: Exposure of Sensitive Information 14

The same solution, but using the .NET Framework and C#:

try{

byte[] text = Encoding.ASCII.GetBytes(GetDataToEncrypt());byte[] buffer =

ProtectedData.Protect(text,null,DataProtectionScope.CurrentUser);

return Convert.ToBase64String(buffer);}catch (CryptographicException e){

// Error

}

Notice that there is no key generation or key management in this code—Windows takes care of handling the keys.Windows also offers another way to store sensitive data, called Local Security Authority (LSA) Secrets. In older versions of Windows, LSA Secrets was used mainly to store sensitive system service information, but it is completely superseded by DPAPI.

Insecure ScrubbingAll sensitive data must be removed from memory when it is no longer needed by the application. However, there are scenarios where some data scrubbing functions don’t work as expected. The following code looks benign, but it is in fact insecure.

void PerformDBOperations() {char szUid[MAX_UID];char szPwd[MAX_PWD];if (GetUidAndPassword(szUid, szPwd)) {

// Use the uid and pwd...// scrub secret data from memorymemset(szUid,0,MAX_UID);memset(szPwd,0,MAX_PWD);

}}

The problem is that the calls to memset() are removed by the compiler optimizer. The two values, szUid and szPwd, are written but not read by the function, so the compiler determines that the write operations can safely be removed. Clearly this is not correct for this code, and the scrubbing functions must be maintained. If code scrubs secrets in

Quick Security Reference: Exposure of Sensitive Information 15

memory, the developer should call functions that are not removed by the compiler optimizer, such as SecureZeroMemory rather than ZeroMemory() or memset().

Setting DACLs ProgrammaticallyDACLs can be configured in native C or C++ code using the low-level Windows APIs, such as SetSecurityDescriptorDacl(), or using higher-level constructs, such as the ATL CSecurityDesc::SetDacl() method. In general, developers should not use the low-level functions as they require a great deal of code that can lead to subtle errors. If a developer must call low-level APIs, consider SetNamedSecurityInfo() as it is a little easier to use. It is easy to set DACLs using .NET because the .NET Framework includes rich and easy-to-use class library support for setting DACLs on an object, such as a file, as shown in the following code snippet.

using System;using System.IO;using System.Security.AccessControl; // Adds an ACE to the specified file for the specified account. public static void AddFileSecurity(string fileName, string account, FileSystemRights rights, AccessControlType controlType) {

// Get a FileSecurity object that represents the // current security settings. FileSecurity fSecurity = File.GetAccessControl(fileName);

// Add the FileSystemAccessRule to the security settings. fSecurity.AddAccessRule(new FileSystemAccessRule(account, rights, controlType));

// Set the new access settings. File.SetAccessControl(fileName, fSecurity);

}

Resources for Developers SecureZeroMemory How To: Use DPAPI (User Store) from ASP.NET 1.1 with Enterprise Services Windows Data Protection API (DPAPI) white paper by NAI Labs How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI FileSecurity Class (.NET) CSecurityDesc Class (ATL) SetNamedSecurityInfo Function Chapter 12 “Information Leakage” from 24 Deadly Sins of Software Security by

Michael Howard, David LeBlanc, and John Viega

Quick Security Reference: Exposure of Sensitive Information 16

UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE TESTER/QAThe challenge for a tester is to find sensitive information that should be protected but is not. The tester should consult the threat model and note the sensitive information that must be defended from disclosure. If a threat model does not yet exist, then the tester should consult the application architect to have him or her create one to get a list of information that needs protection. One of the most effective testing techniques is to add known sentinel values to the sensitive information (for example, a social security number or credit card number like 123-45-678) then see if that number occurs in plaintext either on the network or in storage. If it does appear in plaintext, then the information is not correctly secured.In a data-driven, web-based application, a tester should add sentinel values to the test data, and then set up a protocol analyzer to examine every packet that enters and leaves the web server looking for the sentinel data. This system should be in place for the duration of the product life cycle and totally automated. If the sentinel is disclosed and detected by the protocol analyzer, then there is an information leakage vulnerability that must be fixed.Another test is to run the application through an exhaustive usability test and then scan the disk, sector-by-sector, for the sentinel values. It is possible that the sensitive information was written to a log file or a temporary file. By doing a sector-by-sector search, a tester can find the information if it is not erased correctly.To move testing techniques beyond this simple method, a tester can implement penetration testing. Penetration testing, which is recommended if the information must be protected because of legal requirements, is beyond the scope of this paper.

Resources for Testers How To: Use DPAPI (User Store) from ASP.NET 1.1 with Enterprise Services – Step 2 How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI OWASP Testing Guide for SSL-TLS Chapter 12 “Information Leakage” from 24 Deadly Sins of Software Security by

Michael Howard, David LeBlanc, and John Viega

EXPOSURE OF SENSITIVE INFORMATION AND THE SDLThe Microsoft SDL, highlighted in Figure 4, requires that applications document the privacy implications of the information used or processed by the application. This process requires architects to document the use of data and who should have access to the information.

Quick Security Reference: Exposure of Sensitive Information 17

Figure 4. The Microsoft SDL Process

The SDL does allow a development group to use other methods of protecting sensitive information. When this occurs at Microsoft, any such design must be reviewed and approved by a designated group of experts. In the absence of a similar body of experts, one may need to use other resources to find methods of securing sensitive information. Any new design should be evaluated by security personnel who understand cryptography well and understand how simple mistakes can lead to exposure of sensitive information.

Long-Term SolutionsThe Microsoft SDL involves modifying an organization’s software development process by integrating measures that lead to improved software security and privacy. The intention of these modifications is not to totally overhaul the process, but rather to add well-defined security checkpoints and security deliverables to help minimize the quantity and severity of security vulnerabilities in software. By introducing security early in the software development life cycle, problems like inadequate data protection can be addressed in underlying security requirements and mitigated in design. From a financial and business perspective, it is very beneficial to eliminate security problems as early as possible in the software development process. The National Institute of Standards and Technology (NIST) estimates that code fixes performed after software has been released are 30 times more costly to complete than fixes during the design phase. Clearly it makes sense to put as much discipline and rigor up front to reduce the cost of finding and fixing disclosure vulnerabilities, especially those relating to protected sensitive data.9

CONCLUSIONVulnerabilities resulting from exposure of sensitive information are often difficult to detect, but can have widespread impact if exploited. The increased value of PII and increased attacks against software to gain access to this information are clear evidence that extending the extra effort to close potential security vulnerabilities that result from inadequate protection is critical. As exposure of sensitive information vulnerabilities continue to grow in number, it is imperative that development organizations prepare themselves with the solutions needed to rapidly address problems as they occur. It is equally important that long-term solutions, including security policies and requirements, are in place to design,

9 http://www.nist.gov/itl/csd/index.cfm

Quick Security Reference: Exposure of Sensitive Information 18

implement, verify, and release code that proactively helps protect customers from these attacks.

ACKNOWLEDGEMENTSThanks to the following individuals for their contributions to this article:

Author: Michael HowardContributors: Jeremy Dallman, David Ladd, Steve Lipner, and Bryan Sullivan

Quick Security Reference: Exposure of Sensitive Information 19