trend micro security development lifecycle
play

Trend Micro Security Development Lifecycle (ChiChang Kung) 2019-03 - PowerPoint PPT Presentation

Trend Micro Security Development Lifecycle (ChiChang Kung) 2019-03 Agenda Introduction Security Development Lifecycle Threat Modeling and Security Design Static Source Code Analysis Software Build Security 3 rd


  1. Trend Micro Security Development Lifecycle 龔紀昶 (ChiChang Kung) 2019-03

  2. Agenda  Introduction  Security Development Lifecycle  Threat Modeling and Security Design  Static Source Code Analysis  Software Build Security 3 rd Party Vulnerability Scanning   Dynamic Security Analysis  Penetration Testing  Lesson Learned

  3. Introduction • Trend Micro has deployed a few product security practices for many years • Static Source Code Analysis, Dynamic Security Scanning, 3rd Party Vulnerability Scanning • In 2015, the Executives decided to invest more in this area • Objectives: improve product security, provide legal evidence • The main architecture is defined by Trend Micro CSO Jonah Feng • The planning initiative is organized by our SQA team, from a compliance perspective • An RDSec Committee , consists of a team of senior RD architects, is formed. Each product group has one or more representatives . 3

  4. Security Development Lifecycle • Each project is registered via PRS • Compliance results of all practices are sent back to DDCI dashboard • Alerts will be sent to stakeholders • GM criteria • PRS and DDCI are both managed by the SQA team DDCI: Data Driven Continuous Integration System PRS: Project Registration System 4 SQA: Software Quality Assurance T eam

  5. The Security Design Process • Certain security threats cannot be eliminated by patching the software, e.g. lack of authentication • Security considerations must be considered at the design time • The Security Design Process covers threat modeling, security design and security testing • Threat Modeling, or architectural risk analysis, should be conducted to identify security threats • Threat modeling, security design and security testing deliverables need to be uploaded to DDCI • Legacy codes must be addressed incrementally • There is a manual approval step in the process. This step will be removed in the future 5

  6. The Security Design Process • Threat modeling approach • Data Flow Diagram (DFD) + security design check list • STRIDE can also be adopted • Security check list from the Secure Coding Dojo, based on CWE: https://github.com/trendmicro/SecureCodingDojo • Security design • Preferably be part of the ordinary design • Security IS part of the design • Security testing • Validate the security design • Does NOT cover pen testing • Note that this process is very different from others in the SDL, because every developer/QA is affected 6

  7. Adoption of Threat Modeling • We hired a consulting company to provide company-wide training for threat modeling • Learned DFD + STRIDE and privacy by design principles • We conducted design/code level training with the Secure Coding Dojo system • Developed by Trend Micro security architect Paul Ionescu in Canada 7 Source: https://github.com/trendmicro/SecureCodingDojo

  8. Software Build Security • At build time, Trend ETS build server checks whether certain compiler flags are turned on • Mainly by checking the binary file • Mainly for mitigating the risks of buffer overflow ETS: Engineering T ools and Services • Mainly applied to C/C++ systems DEP: Data Execution Prevention ASLR: Address Space Layout • Phased approach Randomization • Phase 1 covers Windows: DEP and ASLR PIE: Position Independent Executable • Phase 2 covers Linux: PIE and Stack protection • Phase 3 covers Mac • Performance impact and process overhead is carefully monitored • The process is not enforced until most of the teams are already compliant • ETS generate visibility report first 8

  9. Static Source Code Analysis • Scan source codes for potential vulnerabilities • Switched from Klocwork to Fortify • For language covering • By far the process with the greatest overhead • Lots of false positive issues. Some teams had 10K+ issues initially • Phased approach • Rule Examples: Preparation: rule selection • SQL Injection : Constructing a • Phase 1: scan only dynamic SQL statement with • Require build script changes input that comes from an • Phase 2: review issues only untrusted source • Phase 3: fix all issues • Command Injection : Executing commands that include un- validated user input 9 Source: https://vulncat.fortify.com/en/weakness

  10. 3rd Party Product Vulnerability Scanning • Trend has an in-house system to scan 3pp vulnerability • Process • The system downloads CVE DB regularly • Project teams submit a scan request, uploading a list of 3pp • The system scans the CVE DB with the list of 3pp • RD determines if the product is impacted. RDSec review it. • All review comments are recorded in the system • After approval, the system still conduct daily scans afterwards • We have recently purchased Black Duck • Auto identification of 3pp • RD teams are not aware of 3pp embedded in 3pp. The manual list may be outdated • Auto identification is not 100% accurate, however • Daily scanning is the objective 10

  11. Dynamic Security Scanning • Limited to web security scanning and network scanning • Use several commercial and free tools • Process • Project teams submit scan requests • Ops team conduct scanning • Project teams fix issues based on the scanning results 11

  12. Penetration Testing • External pen testing services are expensive • Trend has an internal pen testing team • But the team does not have enough bandwidth for all projects • Pilot indicate that pen testing by project teams themselves are effective • Pen testing requires very different skills. Proper training is necessary • The objective is to enable project teams to conduct regular, internal pen testing 12

  13. Security Practices for Agile Process • A key to adopt security process in an agile development process is automation • Example: 3pp vulnerability scan • Manual and formal approval step is a bottleneck • By automating case creation upon detection, the process is more streamlined • Threat modeling needs to be lightweight • Since simple design is a key principle of agile development • A good check list is a good starting point • Adding product specific check items is likely necessary 13

  14. Lessons Learned • Existence of a champion( 擁護者 ) in the RD team is critical • A phased approach smoothens the transition • Create a decent process first, improve it later • Compliance alone isn’t enough, and the name of the game is Culture 14

  15. Thank You

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend