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  3rd 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.

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 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

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

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

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
• Mainly applied to C/C++ systems
• Phased approach
• Phase 1 covers Windows: DEP and ASLR
• 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

ETS: Engineering T

• ols and Services

DEP: Data Execution Prevention ASLR: Address Space Layout Randomization PIE: Position Independent Executable

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
• Preparation: rule selection
• Phase 1: scan only
• Require build script changes
• Phase 2: review issues only
• Phase 3: fix all issues

Source: https://vulncat.fortify.com/en/weakness

Rule Examples:

• SQL Injection: Constructing a

dynamic SQL statement with input that comes from an untrusted source

• Command Injection: Executing

commands that include un- validated user input

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

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

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

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

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

Thank You