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

Recommend


More recommend