Successfully reported this slideshow.
Your SlideShare is downloading. ×

[EMC] Source Code Protection

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

[EMC] Source Code Protection

  1. 1.   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. 2. 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
  3. 3. 3 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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.
  4. 4. 4 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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
  5. 5. 5 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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
  6. 6. 6 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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.
  7. 7. 7 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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.
  8. 8. 8 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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
  9. 9. 9 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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.
  10. 10. 1 0 SOURCE CODE PROTECTION   This is text for annotations in footer. Similar to footnotes treatment. 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  

×