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...................................................................................................... 3
Business Decision Maker
3
Architect
3
Developer
3
Tester/QA
3
Understanding Exposure of Sensitive Information Issues for the Business Decision Maker 4
Risk
4
Business Impact
5
Resources for Business Decision Makers
6
Understanding Exposure of Sensitive Information Issues for the Architect .... 6
Identifying the Problem
6
Common Attacks
6
Implementing Defenses
6
8
Mitigations
11
Resources for Architects
Understanding Exposure of Sensitive Information Issues for the Developer 12
Insecure Scrubbing
13
14
Setting DACLs Programmatically
14
Resources for Developers
Understanding Exposure of Sensitive Information Issues for the Tester/QA 15
Resources for Testers
15
Exposure of Sensitive Information and the SDL .................................................. 15
Long-Term Solutions
16
Conclusion .................................................................................................................. 16
Acknowledgements ................................................................................................... 16
Quick Security Reference: Exposure of Sensitive Information
OVERVIEW
Failure 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.html
2
http://www.owasp.org/index.php/OWASP_Top_Ten_Project
3
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 PERSONAS
Every 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.
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.”
Quick Security Reference: Exposure of Sensitive Information
3
UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE
BUSINESS DECISION MAKER
Risk
The 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.
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]
Quick Security Reference: Exposure of Sensitive Information
4
Business Impact
The 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:


Requirement 3: Protect stored cardholder data.
Requirement 4: Encrypt transmission of cardholder data across open, public networks.
4
http://www.reuters.com/article/idUSTRE65960S20100611
5
http://www.crn.com/security/198701183;jsessionid=J5Q3CQJDQ2HXRQE1GHPCKH4ATMY32JVN
6
http://www.privacydigest.com/topic/rfid/2006/10/24.html
7
http://www.resonant.org/text/security/nt-activesync-security-artsusageP.htm
8
http://www.scmagazineus.com/the-real-cost-of-a-security-breach/article/113717/
Quick Security Reference: Exposure of Sensitive Information
5
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 Problem
An 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 Attacks
The 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
Example:
An attacker could access a network through a weak Wi-Fi
information to disclose paths to sensitive data. The
access point or take advantage of a SQL injection
first scenario is when an attacker actively attempts
vulnerability to access the sensitive information.
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 Defenses
Implementing 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:
1.
2.
3.
Build or analyze an up-to-date threat model.
Itemize all data stores and data flows in the threat model.
Determine which of these data flows and data stores could potentially expose sensitive data.
Quick Security Reference: Exposure of Sensitive Information
6
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
9.0 Web server configuration
10.0 Web pages
12.0 Database server configuration
13.0 Customer data
17.0 Audit logs
Quick Security Reference: Exposure of Sensitive Information
7
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
Important:
established, the architect must determine which of
Any data flow that crosses a trust boundary should be
these could potentially hold sensitive, confidential,
scrutinized for potential data leakage issues.
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.
Mitigations
Information 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:




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)
If you must encrypt a large amount of data, encrypt the
Encryption and decryption must occur in a
data using custom code, and encrypt the encryption key
using DPAPI.
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.
Quick Security Reference: Exposure of Sensitive Information
8
Use Encryption
For 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
Email
But 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 Code
Taking 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 ACLs
Data at rest should also be protected using ACLs, also known as Discretionary ACLs (DACLs).
Quick Security Reference: Exposure of Sensitive Information
9
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:


Some operating systems, such as Linux, do not support
DACLs by default and use a less fine-grained system called
permissions .
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 Control
An 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 Messages
An 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:


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
10
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
11
UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE
DEVELOPER
Some 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 string
NULL, // Optional entropy not used.
NULL, // Reserved.
NULL, // Pass NULL so there’s no prompt data
CRYPTPROTECT_AUDIT, // audit encrypt/decrypt events
&DataOut)) {
// all worked
} else {
// Error
exit(1);
}
Quick Security Reference: Exposure of Sensitive Information
12
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 Scrubbing
All 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 memory
memset(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
Quick Security Reference: Exposure of Sensitive Information
13
maintained. If code scrubs secrets in memory, the developer should call functions that are not removed by
the compiler optimizer, such as SecureZeroMemory rather than ZeroMemory() or memset().
Setting DACLs Programmatically
DACLs 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
14
UNDERSTANDING EXPOSURE OF SENSITIVE INFORMATION ISSUES FOR THE
TESTER/QA
The 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, sectorby-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 SDL
The 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.
Figure 4. The Microsoft SDL Process
Quick Security Reference: Exposure of Sensitive Information
15
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 Solutions
The 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
CONCLUSION
Vulnerabilities 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, implement,
verify, and release code that proactively helps protect customers from these attacks.
ACKNOWLEDGEMENTS
Thanks to the following individuals for their contributions to this article:
Author: Michael Howard
Contributors: Jeremy Dallman, David Ladd, Steve Lipner, and Bryan Sullivan
9
http://www.nist.gov/itl/csd/index.cfm
Quick Security Reference: Exposure of Sensitive Information
16