[EMC] Source Code Protection

MERGE 2013 THE PERFORCE CONFERENCE SAN FRANCISCO • APRIL 24−26
White Paper
Security of source code is an evolving domain because
internal networks̶once considered to be safer̶are
no longer trusted environments. Since enterprise
perimeters are no longer sufficient defense boundaries,
the focus shifts to using defense-in-depth strategies to
secure internal systems that hold product code.
Source Code Protection:
Evaluating Source Code Security
Stephanie Woiciechowski, GSEC
EMC Product Security Office, EMC Corporation

2 SOURCE CODE PROTECTION

This is text for annotations in footer. Similar to footnotes treatment.
Introduction: Threats/Objective
Attackers have multiple motivations for focusing on source code such as crime, espionage,
hacktivism, and terrorism. Attacks may result in theft of source code that damages a
company’s reputation, allows attackers to search for vulnerabilities or other methods of attack
in your code, or undermines competitive advantages. From a different angle, the attacker may
attempt to alter your source code to undermine product integrity and create weaknesses in
your customer environments.
Traditionally, we have relied on basic system security hygiene along with the security of
corporate (or private) networks to protect source code. Today, attacks have evolved to obtain
and quietly maintain access on the network so there is greater pressure to understand the
level of defense in depth needed to protect product engineering systems, such as source code
repositories. In August 2011, the Security for Business Innovation Council told organizations:
“Consider that no organization is impenetrable. Assume that your organization might already
be compromised and go from there” (Security for Business Innovation Council Initiative, 2011).
Attackers are looking for long-term access to your network and data. They are willing to invest
the time and effort to go slowly, build multiple points of access, and learn your network better
than you do. In this environment of new threats, we need to expand security awareness
beyond security experts so software configuration management (SCM) administrators and
development teams can take a larger role in supporting security.
As a result of this changing landscape, we must update how we secure source code. This
white paper offers a security-focused overview for non-security professionals to create source
code environments with defense-in-depth solutions. It starts with an exploration of common
security criteria, describes how to analyze your source code environment, and provides
examples of managing change to implement security solutions to better protect your source
code.
Defining Security Criteria: Policies and Standards
Identify the stakeholders with an individual interest in protecting the company’s source code:
security practitioners, legal advisors, program managers, source code administrators, and
developers within your company. Reach out to them to explore different security perspectives
and use cases for your organization. The goal of these conversations is to identify weak points
in your environment (vulnerabilities) to define how someone might attack your environment
(threats) and the results of a successful attack (impacts) so you can develop a business case
for improving security in your environment. Consider questions such as these:
• What could happen if our source code was modified?
• What could happen if our source code was stolen?
• How would we recover and how much would this cost?
Use the business case to get buy-in from your executives, ensure that you are working toward
clear goals, and get the correct people involved in making decisions.
With an approved business case, begin constructing visible policies. Policies describe the
general goals without focusing on implementation details and frame the objective of the goals
to cover even unforeseen circumstances. Invite the stakeholders to form a task force or
advisory team to have meaningful conversations about what is necessary and practical and


how to address accountability.
Your task force will also develop the standards that define the rules supporting your policies.
Your policies establish what needs to be done to protect source code; standards describe how
to do it in a tool-agnostic way. Whether you are using Perforce Software Version Management
or ClearCase should be irrelevant to the standard because the standard could be equally
applied to both. It is essential to have cross-team collaboration to develop standards to ensure
both adequate coverage and feasibility. This approach provides relevant stakeholders with a
voice in the process so you obtain security-related improvements and compliance in a manner
that is achievable, measureable, and maintainable.
Common Defense-in-Depth Strategies
Defense in depth is “the concept of protecting a computer network with a series of defensive
mechanisms such that if one mechanism fails, another will already be in place to thwart an
attack” (McGuiness, 2001). The techniques our security and IT teams have been using to
protect the network are not dead. They still provide a layer of defense but need to be
supplemented. Defense-in-depth strategies will support your approach to developing a
standard.
Data Classification
You may be familiar with military data classifications: Classified, Secret, Top Secret. Data
classification reflects both the value of the data and the risk to the data so you can select the
appropriate security solutions. By defining and applying data classifications to your source
code, you can frame how to protect different types of source code. Source code intended to be
released under an open source license may deserve different security rules than the source
code that makes up your core design. Classification may take into account regulatory
requirements (e.g., cryptography) or customer requirements (e.g., FIPS compliance). For
inspiration, look at resources such as FIPS PUB 199 Standards for Security Categorization of
Federal Information and Information Systems (FIPS PUB 199, 2004) or the ISO 27000 series
of information security standards.
Identity/Authentication
Authentication means proving your identity in a way that no one can later say it wasn’t you
(non-repudiation). Authentication is usually achieved by combining a username (to provide an
identity) with a secret (such as a password or one-time token) to be validated. In the software
development context, you want to identify who broke the build, and authentication provides
that information; Bob Developer cannot dispute he broke the build when his commit was the
only one since the last successful build. In the security context, you want authentication to
supply non-repudiation that only authorized individuals are touching the code. Non-repudiation
can only be achieved through proper authentication.
By adopting centralized authentication mechanisms, you protect source code with your
organization’s password policies; accounts can be disabled quickly when someone leaves the
organization or changes roles. Solutions such as secure LDAP or Active Directory can support
access groups while two-factor authentication—which combines something you know with
something you have to re-create your secret—can provide enhanced security.


Some people argue that having local accounts separate from the centrally managed accounts
adds another “layer” of security, but local accounts risk complicating the deprovisioning
process and correlating user activity throughout the environment. “Business process flaws,
departmental silos, and a lack of automation all stand in the way of streamlining this so-called
deprovisioning process. And when organizations don’t get a handle on the orphan accounts
left behind by an ineffective deprovisioning process, they leave themselves open to fraudulent
account use and a lack of visibility” (Chickowski, 2013). Having inconsistent account IDs
across systems makes it hard to trace user activity across the environment. If I have bob.smith
and barbara.smith in the corporate directory, who is bsmith in my local account? This becomes
even more important when we talk about supporting enterprise logging and monitoring later.
Access Controls
Combining data classification with authentication provides the data necessary to establish
access controls to govern who has access to data. The principle of least privilege means you
only have access to the bare minimum you need to do your job.
With proper access controls in place, a malicious insider working on Project A is restricted from
Project B’s code, limiting the scope of exposure to attack. This is not just a matter of not
trusting employees. The developer on Project A may be an honest, dedicated employee but
her credentials were compromised; now, access controls limit the data available to the
attacker.
The principle of least privilege can be difficult to implement. The idea of limiting access
appears to go against many usual development practices: How do we share common code?
Can a project be agile if everyone can’t commit everywhere? However, even in the open
source world, we can find examples of access controls: The Apache Way describes how
Apache projects allow anyone to contribute, but only committers can actually write code
changes to the official repository (The Apache Software Foundation, 2012).
Isolation
Properly configured firewalls are still a vital component for isolating network access and
providing logical protection to the source code. Source code repositories typically have at least
one layer of isolation behind firewalls on the internal network. Hardware hosting repositories
used to build the product also should be physically isolated. The hardware should be behind
locked doors with limited access reducing the risk of physical tampering.
Recently, a trend toward distributed solutions, such as Git, or SaaS solutions, such as Perforce
OnDemand, requires extending how we apply isolation. Isolation still plays a role, but the
techniques are evolving. In a distributed solution, one repository should be identified as the
“gold” repository, which is the definitive source for all code contributing to a final build. Before
selecting a SaaS solution, you need to understand how the SaaS provider supplies isolation
for your environment. The hardware for your “gold” repository or at your SaaS provider’s facility
still must be protected from unauthorized physical access, and the firewalls should isolate your
source code environment from that of other customers.
For additional isolation protection of exceptionally sensitive source code, the entire
development and build environment can be physically and logically isolated. You can employ a
virtual desktop infrastructure (VDI) solution to provide limited access to source code in a highly


protected network environment where only the final product ever leaves the environment.
Classifying the data first will help you determine if additional protections such as this are
warranted; these additional controls incur extra costs and require changes in the development
process. Usability is key to successfully deploying an enhanced security environment because
end users still need an environment in which they can work efficiently and effectively. Be sure
to prototype the solution with actual users and get their buy-in.
Data Protection
While isolation addresses security of your source code where it lives on your servers, data
protection considers security of your source code in other places.
If we assume our network has been compromised or if we’re using a SaaS solution, we want to
make sure source code is protected in transit over the network; we don’t want source code
leaked or changes made mid-flight by an attacker. Many source code tools provide an SSL
solution to encrypt data between the client and server applications. Using these solutions—
along with the accompanying PKI solution to mitigate man-in-the-middle attacks—supports a
more secure coding environment.
Backup solutions aren’t just an issue for business continuity; they are also another area of
potential vulnerability. When we’ve locked up our source code repository hardware, the backup
tapes may become easier targets for a thief. Backups can also be a target for people looking to
tamper with your code, if they can modify the data on the backup and force you to restore that
data. When a backup is no longer needed, it should be securely disposed of through
techniques such as secure overwriting or physical shredding.
Similar to backups, hardware decommissioning presents another area of vulnerability. When
you replace a hard drive, the device must be securely disposed of to prevent access to your
source code. If the hard drive is functional, consider securely clearing or sanitizing the drive
using the National Institute of Standards and Technology’s Guidelines for Media Sanitization
(NIST SP800-88) (Kissel, Scholl, Skolochenko, & Li, 2006).
Even current hardware should be evaluated. In larger organizations, repository storage is often
mounted in SAN or NAS storage, which requires evaluating access to another physical device
and the processes used to securely dispose of them.
For additional protection, consider implementing a data loss prevention (DLP) tool. With a DLP
solution, you define where data can live on your network, and the DLP solution will block or
notify you if that protected data is leaving the defined location. This may be useful, particularly
with a distributed source code system such as Git, to restrict where repository copies can be
created.
Hardening
Hardening involves reducing the vulnerable surface of a server. Although these tasks are
typically OS changes, which fall under the domain of an OS or IT administrator, source code
administrators need to understand the requirements of their tools and processes to guide
effective hardening. The hardening process looks at services running on the host and known
vulnerabilities. Remediation consists of techniques such as disabling and removing services
not needed to avoid unknown vulnerabilities, meeting minimum password requirements, and


installing the latest security patches. By reducing the vulnerable surface of a server, we make
it more difficult for an attacker to compromise it. For example, if you do not need Apache web
services on a server, disabling and removing the Apache services removes all attack methods
that rely on Apache vulnerabilities. Work closely with the OS administrators because they may
not know which services the source code system requires.
There are many hardening resources available to help secure your servers.
Microsoft has had a variation of Windows Server Update Services since Windows 2000 SP3
that enables automatic updates of the Microsoft OS to keep systems current with the latest
patches. Microsoft also provides several tools to understand and manage the security state of
your servers:
• Security Configuration & Analysis can compare your system against a security template
that defines items such as Password Policy, Lockout Policy, User Rights, and Registry
Permissions (Microsoft, 2013). It comes with modifiable templates that were developed
in conjunction with NIST, DISA, and NSA. You can learn more about NIST’s role on the
NIST web site (NIST, 2008).
• The Security Configuration Wizard will poll you for information about your environment
and how you will use the server to create a custom security template to manage your
server in the context of the role it plays. The wizard can then apply the template
(Microsoft, 2013).
• The Microsoft Baseline Security Analyzer is an assessment tool that can analyze a
system for vulnerabilities such as missing security patches, common password issues,
logging configuration, and some permission issues. It generates a report along with
recommendations to improve system security (Microsoft, 2013).
The U.S. Defense Information Systems Agency, a part of the Department of Defense
(DoD), also produces a set of Security Technical Implementation Guides (STIGs) that define
the DoD standards for hardening a wide variety of systems. You can analyze your systems
against STIGs manually or using a tool compliant with the security content automation protocol
for automated analysis. Combining the results from these scanning tools with an enterprise
governance, risk, and compliance (EGRC) tool can help you track metrics to measure
compliance goals or furnish evidence for audits in the event of a security incident.
Avoiding Malicious Code
There are two situations to consider with malicious code:
• Protecting your environment (servers, workstations, laptops) from malicious code, such
as malware that may be installed, and
• Protecting against an attacker altering your source code in such a way that can harm a
customer environment through your product once it is installed.
The first step for protection should be maintaining a strict chain of custody for everything you
bring into your environment. Use only reputable sites to obtain components whether they are
internal development tools such as Eclipse or an open source component that you may use in
your product. Defining “reputable” can be challenging, but getting the latest JDK from Oracle or
CNET is generally better than getting it from an unknown site.


With many open source components available on community sites such as SourceForge.net,
you need to evaluate the reputation of the project as well. These sites often have information
about the number of downloads for the component along with reviews and recommendations.
This type of information must be evaluated with a critical eye, however; the numbers can be
manipulated and reviews can be forged, but it can be useful in narrowing the scope of projects
to review in depth. Detailed review should, at a minimum, analyze the development forum of
the project, the number, quality, and frequency of patches, and the public bug repository
system as the tangibles that represent a “quality” of the project.
Once you’ve settled on a reputable site, be sure to validate the integrity of your download by
confirming file size and checksums. Use cryptographic checksums (also known as
cryptographic hash algorithms) such as SHA-2 or digital signatures in preference to other
options that might be available. Cryptographic checksums and digital signatures are
specifically designed to address challenges where common checksum algorithms, such as
CRC-32, are easily reproduced with modified binaries. When possible, get the hash
information from a different site or through a different medium; if the download site has been
compromised, the attacker can post checksum data that matches the corrupt package.
After taking the effort to validate that you trust the component, keep a record of all of the
information used to support your decision.
Your next level of protection should come from anti-malware tools that scan your environment
and your product at various stages of the build process. While the merits of anti-malware
software are being hotly debated, it does provide reassurance that known malware signatures
covered by the tool are being screened out.
Finally, strong development processes that require peer code reviews, tracking of functional
requirements for code branches, restricted commit access to the HEAD of the repository, and
use of code analysis tools reduce the likelihood of malicious code being inserted into your
code base where it might ship to customers. Combined, these techniques help ensure that
only intended changes are submitted to the mainline.
Logging
Logs are an important forensic tool and must be carefully protected to preserve their integrity.
Checking logs when there are no apparent problems with your environment can help you
better recognize good and bad behaviors. By actively monitoring logs, you can watch for
suspicious behavior patterns such as log-in failures over a set threshold, code commits from
someone on vacation, or automation accounts being used from unusual locations.
Start by confirming that your systems have logging enabled and make sure the logs are
protected. Restricting write access to the logs prevents alteration of the logs to hide attack
activity. Restricting read access can reduce leaking data, such as user IDs, that might be
useful in an attack scenario. You will also want to protect your logs from corruption due to
insufficient available storage through techniques such as log rolling and storage monitoring.
Move (or at least copy) your logs to another system as frequently as possible. Local logging
usually can be trivially defeated by the same attacker with elevated privileges you are trying to
track. Moving the logs to another system with different privileges preserves the integrity of
those logs.


Finally, consider a solution to analyze the content of your logs. The right tools can monitor logs
for predefined patterns, such as excessive log-in failures, and generate alerts to administrators
for further investigation. More advanced searches can correlate information from multiple logs
or other available security information. To correlate data across multiple sources, we need
consistent user IDs or a way to correlate the IDs.
Next Steps
Once you’ve established a standard that reflects your expectations about protecting source
code, consider both a method to assess compliance and to track your progress. Whether you
use simple spreadsheets or an EGRC solution, you will want to measure, monitor, and report
on progress. The ability to measure compliance creates the feedback loop and visibility for
continuous improvement.
Understanding the Environment
While security initiatives are often supportive of typical SCM best practices, security and SCM
do not always speak the same language and need to find common ground. One challenge in
developing a workable standard for your organization will be bridging this communication gap.
Begin by building an understanding of your environment with both SCM and security
stakeholders.
Both tools and processes contribute to the security of source code. Changing software
development tools and processes is not something to undertake lightly. If a solution is
cumbersome, developers will find ways to simplify their work, but that may unintentionally
undermine security controls. The goal is to understand how best to remediate security
vulnerabilities in your environment based on how your teams work and what risks you have.
1. Consider the entire environment and its lifecycle in this analysis: your repository
application, the host OS and hardware, storage, build environments, and backups. A
threat modeling exercise that covers the entire build environment will help you
determine where weaknesses lie. A weakness anywhere in the environment can
jeopardize your source code; consider these situations:
• The Perforce application uses authentication tied to a centralized LDAP server, but
the underlying OS has local accounts with weak or default passwords; an attacker
who gains access to the host can modify your Perforce configuration.
• Your source code repository is well secured, but your build hosts have a vulnerability
that allows an attacker to modify the build process to inject malicious code or change
compiler flags.
• An attacker gains access to your unencrypted backup or a disk from a
decommissioned source code environment. What could the attacker learn about
your products in the field or your next features?
2. Compare the tools currently in use with your security requirements to determine if there
are significant issues with the tools themselves (e.g., they may not be capable of
encrypted sessions or using Active Directory). Often, the existing implementation may
not meet your security objectives, but you can change the configuration to support the


requirements such as when an integration to your corporate Active Directory database
is available but you’re not currently using it.
3. Next, capture software development practices. Understanding how developers work will
help you define the most transparent security solutions for the environment or allow you
to defend practices that disrupt developers. A team that is used to having copies of
source code on their laptops to work with at the airport is not going to like a solution that
requires them to be connected to the company network in order to work; but if they’re
working on the crown jewels of the company, proper protection may require
inconveniencing developers.
4. Finally, understand how security best practices are implemented in your tools.
Generally, the security solutions natively implemented by the tool are less expensive to
implement and maintain than solutions that require additional plug-ins, integrations, or
custom-written code. One example would be integration with Active Directory for
Authentication and Access Controls using the vendor’s supplied integration. With add-
ons such as plug-ins and scripts, almost any tool can be brought into compliance with
most security policies, but the trade-offs of initial cost, maintenance costs, available
support, and ease of use should be compared with migration costs to a solution that
addresses more of your primary concerns out of the box.
Managing Change
Based on the analysis of your environment, we now look to manage the implementation of
security improvements.
• Begin by minimizing new options: don’t chase a moving target. You’ve done the
analysis of what is and isn’t working in your environment, so narrow the scope of
acceptable solutions by recommending preferred solutions—at least until you can
manage what you have.
• Provide strong guidance to encourage adoption of improved security techniques.
Guidance should specify how to securely configure each solution to meet security
requirements. Include security training focused on source code in addition to any
other organizational security training. The more developers buy in to the culture of
security, the easier it will be to implement changes.
• Develop an assessment framework to measure security compliance of
environments. If possible, use a compliance management tool to support the
assessment and provide reporting. Use this framework to tie security compliance to
prerelease metrics and create an environment of continuous improvement.
• Create a framework to evaluate new solutions. When there is a new tool that
developers want to use, this framework should help you quickly understand the
security considerations of the tool and provide guidance for compliance. Eventually,
you should be able to use this framework to proactively supply security “reviews” of
new tools.
• Continue to learn about security and evolving threats.

1
0
SOURCE CODE PROTECTION

Conclusion
The evolving threat landscape changes how we need to think about source code security.
Evolving and advancing threats require more defense in depth to protect ourselves and our
customers. Expanding security awareness to SCM administrators and development teams
encourages better conversations about how to best protect source code.
We need stakeholders to define policies and standards based on common security strategies
to set security goals. These documents provide reference points for establishing security and
communicating improvements. Defense-in-depth techniques such as data classification,
identity and authentication management, access controls, hardening, avoiding malicious code,
and logging furnish a solid base from which to build environments with the right level of
security for your organization.
Through continuous analysis of our source code environments, we can assess risk and build
frameworks to support continuous improvements. These assessments and frameworks
support prioritization of changes in a secure manner as well as provide assurance of the last
known good state and strong forensic information when we face a potential security breach.
Works Referenced
Chickowski, E. (2013, January 24). Avoiding IAM's Biggest Blunder. Dark Reading.
Department of Defense. (1995, January). DoD 5220.22-M National Industrial Security Program
Operating Manual (NISPOM) January 1995. Retrieved February 2013, from USAID: DoD
5220.22-M National Industrial Security Program Operating Manual (NISPOM) January 1995.
FIPS PUB 199. (2004, February). Standards for Security Categorization of Federal Information
and Information Systems. Retrieved February 6, 2013, from NIST:
http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
Kissel, R., Scholl, M., Skolochenko, S., & Li, X. (2006, September). NIST Special Publication
800-88: Guidelines for Media Sanitation. National Institute of Standards and Technology.
McGuiness, T. (2001). Defense In Depth. SANS Institute.
Microsoft. (2013). Microsoft Baseline Security Analyzer. Retrieved 2013, from Microsoft:
http://www.microsoft.com/en-us/download/details.aspx?id=7558#overview
Microsoft. (2013). Security Configuration Wizard. Retrieved 2013, from Microsoft Technet:
http://technet.microsoft.com/en-us/library/cc771492(v=WS.10).aspx
Microsoft. (2013). Step-by-Step Guide to Using the Security Configuration Tool Set. Retrieved
2013 from Microsoft TechNet: http://technet.microsoft.com/en-us/library/bb742512.aspx
NIST. (2008, October 10). CSRC - System Administration. Retrieved 2013, from NIST:
http://csrc.nist.gov/itsec/
Security for Business Innovation Council Initiative. (2011). When Advanced Persistent Threats
Go Mainstream.
The Apache Software Foundation. (2012). How the ASF Works. Retrieved February 2013,
from The Apache Software Foundation: http://apache.org/foundation/how-it-works.html

[EMC] Source Code Protection

Mais conteúdo relacionado

Destaque

Semelhante a [EMC] Source Code Protection

Mais de Perforce

Último

[EMC] Source Code Protection