Source Code Protection: Evaluating Source Code Security Stephanie Woiciechowski, GSEC Principal Software Engineer Product Security Office EMC Corporation 1
Goals Understand application of basic security concepts Collaborative security Iterative security improvements around source code If you have built castles in the air, your work need not be lost; that is where they should be. Now put the founda;ons under them. - - Thoreau 2
Why should we care? Threats to source code 3
Source Code Threats Consider that no organization is impenetrable. Assume that your organization might already be compromised and go from there. Security for Business Innovation Council (2011) Security takes a new role in working with source code. 4
Source Code Threats AMSC Ex- NASA Taking Sinovel contractor Infringement arrested Suit on plane to to China s China Supreme Court - - Bloomberg Claims - - Associated by Anonymous Press about Symantec - - Symantec Theft of product-related intellectual property to undermine the security of our customers. Or to seek competitive advantage Exposure of vulnerabilities Exposure of trade/government secrets Security takes a new role in working with source code. 5
Source Code Threats AMSC Taking Sinovel Infringement Suit to China s Supreme Court - - Bloomberg Ex- NASA contractor arrested on plane to China - - Associated Claims by Anonymous about Symantec - - Symantec Press Theft of product-related intellectual property to undermine the security of our customers. Or to seek competitive advantage Exposure of vulnerabilities Exposure of trade/government secrets Security takes a new role in working with source code. 6
Source Code Threats phpmyadmin Insertion of malicious code into products during development cycle that can undermine product integrity and operations in customer environments. Security takes a new role in working with source code. 7
What can we do? Define objective 8
What can we do? Improve security in the source code environment to defend against threats. Prerequisites & Assumptions IT is doing their part for corporate security Security is not #1 for SCM, Build, Release, QE, and Dev Security goals often support SCM goals of traceability, reproducibility, and auditability Approach: Collaboration Define security criteria Understand current environment Review tools in use against criteria Include input from SCM and security experts Manage change Provide recommendations for preferred solutions Provide a framework to assess implementations & evaluate new solutions 9
Establish Goals & Team Initial Goals: Call to action Who should be involved? Policies & Standards Procedures & Assessments Threat model: How might your Policy: What needs to be done to protect environment source code. RISK Strong passwords REDUCTION be attacked? to access source Business code case IT Transactions Achievable What could will happen be & logged if your and protected Standards: Security Maintainable: source code is modified? How to implement policy. Consistent What could happen approach if your to Source code systems are integrated with implementation source Task organization s code Force is stolen? identity management How would system you recover and use and network at password. what Measureable: cost? Evaluation Transactions are logged if a control to syslog and Actionable is exported every intelligence 20 minutes to Development a log aggregation in place system. and how it is Source Code Admin functioning RISK REDUCTION Legal 10
Establish Goals & Team Initial Goals: Call to action Threat model: How might your environment be attacked? Business case What could happen if your source code is modified? What could happen if your source code is stolen? How would you recover and at what cost? Actionable intelligence RISK REDUCTION 11
Establish Goals & Team Initial Goals: Call to action Who should be involved? Security Task Force IT Development Source Code Admin Legal 12
Establish Goals & Team Initial Goals: Call to action Who should be involved? Policies & Standards Policy: What needs to be done to protect source code. Strong passwords to access source code Transactions will be logged and protected Standards: How to implement policy. Source code systems are integrated with organization s identity management system and use network password. Transactions are logged to syslog and exported every 20 minutes to a log aggregation system. 13
Establish Goals & Team Initial Goals: Call to action Who should be involved? Policies & Standards Procedures & Assessments RISK REDUCTION Achievable & Maintainable: Consistent approach to implementation Measureable: Evaluation if a control is in place and how it is functioning 14
Defining Security Criteria Defense-in-depth Data Classification Identity/Authentication Access Controls Isolation Data Protection Hardening Avoiding Malicious Code Logging Value of Preven;ve Backups and risk to Authentication is a way to Code prove Changes your identity Environment such that no one can area later of say a server it wasn t you Reduce Principle vulnerable of Least Privilege surface Forensics Network IsolaMon the data informs Physical IsolaMon appropriate security solutions Restricted access Chain of Detec;ve Log protecmon Servers Storage monitors Services Security Log aggregamon Patches Identity Custody DLP + Secret = Authentication WorkstaMons Hardware Ports ConfiguraMon One of the most common Regular Source reviews Malware ways insiders detect egrc Compliance Code monitoring breaches Code reviews Reputable Centralized authentication Rootkits Correc;ve sourcing mechanisms Virtual AcMve monitoring Virtual Integrity Why IsolaMon local accounts Containment cause checks problems The Apache Way EncrypMon Storage Layers of Protection 15
Define Security Criteria We have a team We have basic Defense-in-Depth security solutions Now draft Source Code Security Policies and Standards to document expectations 16
What can we do? Understand the current environment 17
Where are we? Establish a baseline Scope your environment Environment diagrams 18
Where are we? Establish a baseline Scope your environment Environment diagrams Engineering practices 19
Where are we? Establish a baseline Scope your environment Environment diagrams Engineering practices Data classification: where is the important stuff? Threat Modeling 20
Where are we? Establish a baseline Are they working securely? Simple solutions? Turn on functionality Add-ons Cost/benefit Change tools Reinforce environment Don t throw the baby out with the bathwater! Scope your environment Environment diagrams Engineering practices Data classification: where is the important stuff? Threat Modeling Tools 21
Where are we? Scope your environment Environment diagrams Engineering practices Data classification: where is the important stuff? Threat Modeling Tools Usability!!! 22
What did EMC find? 23
2011 EMC Summary of 5 Common Brands 11 High level policy criteria and 31 controls (not weighted) Repository 1 Repository 2 Repository 3 Repository 4 Repository 5 Analysis of product features, not existing implementations Out of Box Add On Out of Box Add On Out of Box Add On Out of Box Add On Out of Box Add On Corporate authenmcamon ü ü ü ü ü Logs of transacmons against access controls can be exported to a monitoring tool. ü PARTIAL ü PARTIAL ü ü PARTIAL ü Granular access controls PARTIAL x PARTIAL x PARTIAL ü x ü Support for code review workflow PARTIAL ü x ü x ü ü x ü 24
2011 EMC Summary of 5 Common Brands 11 High level policy criteria and 31 controls (not weighted) Analysis of product features, not existing implementations 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Overall Risk Assessment Percentages Repository 1 Repository 2 Repository 3 Repository 4 Repository 5 Out- of- Out- of- Out- of- Out- of- Out- of- Box Add- On Box Add- On Box Add- On Box Add- On Box Add- On TOTAL (out of 220) 200 210 160 210 160 210 220 220 170 220 Percentage 91% 95% 73% 95% 73% 95% 100% 100% 77% 100% Difference: 5% 23% 23% 0% 23% Add- On Out of Box 25
EMC s Observations Most major Source Code Repository systems can be made acceptable All existing solutions can be made better Newer SCMs have more security built in or added as features Source code is highly visible to many people regardless of whether the SCM is distributed (like Git) or not A poorly configured underlying platform or poor practices can undermine strength of any application controls that may exist 26
Managing change to steady state 27
Action Like most organizational projects Team Policies & Standards Evaluate Plan Implement except this must be a continuous process. 28
Continuous Monitoring and Improvement Observe & Orient Minimize new options Until you get a handle on your environment Don t chase a moving target Assessments Security awareness training needs to emphasize secure source code 29
Continuous Monitoring and Improvement Decide Observe & Orient Minimize new options Until you get a handle on your environment Don t chase a moving target Assessments Security awareness training needs to emphasize secure source code How will you evaluate new solutions? Expand scope: other buildrelated tools and infrastructure 30
Continuous Monitoring and Improvement Threat Model Assessment Decide Observe & Orient egrc Triage 31
Continuous Monitoring and Improvement AcMon Test Deploy Implementation guidance Decide Observe & Orient 32
Summary 33
Summary Evolving threats change how we need to think about source code security Collaboration: Expanding security awareness involves more stakeholders Policies & Standards: define security goals based on common security strategies Measure: Baseline environment Implement & manage change Expand frameworks Improve security in the source code environment to defend against threats 34
Thank you Stephanie Woiciechowski, GSEC EMC Product Security Office stephanie.woiciechowski@emc.com 35