Secure SDLC at OPSWAT

Author: Vincent Lin, Director of Software Engineering at OPSWAT

This document describes the application security program used at OPSWAT and covers the following topics:

• What is Secure Software Development Life Cycle (SDLC) and why we use it
• Security frameworks we follow
• Comprehensive Application Security Program that covers strategy and governance, requirements, and design to implementation and operation.

What is Secure SDLC?

Software Development Life Cycle (SDLC) is a process consisting of a series of planned activities to develop software products. The Secure Software Development Life Cycle (S-SDLC) incorporates security into every phase of the Software Development Life Cycle - including requirement gathering, design, development, testing, and operation/maintenance.

Why Secure SDLC?

The threat landscape has changed drastically in recent years. There are actors out there whose only intention is to break into computer systems and networks to damage them, whether it is for fun or profit. There are many consequences, but eventually it costs organizations money and creates business risks.

According to a recent survey, the cost of fixing a security bug can be 30 times more expensive when it is discovered in production in comparison to when it is identified at the analysis and requirements stage.

Implementing Secure SDLC has become very important to organizations due to the following benefits:

• Reduces business risk for organizations by detecting security flaws in products early in development process
• Reduces costs by detecting and resolving flaws early in the lifecycle
• Makes security a continuous concern by all stakeholders

Secure SDLC at OPSWAT

OPSWAT follows the Agile Software Development Lifecycle. On top of the agile process, we have added OWASP SAMM as the framework for Secure Software Development Life Cycle and OWASP ASVS as the framework for Application Security and Verification. We adopted these two OWASP frameworks for the following reasons:

• Open source framework with broad contributions from a global community
• Provides guidance for security requirements and checklists that is detail enough to be actionable for engineering teams
• Framework that can quantify results and improvement of Secure SDLC

OWASP Software Assurance Maturity Model (SAMM): This is a framework to assess, formulate, and implement a strategy that software security organizations can integrate into their existing Software Development Lifecycle (SDLC).

OWASP Application Security Verification Standard (ASVS): This is the framework for testing web applications using technical security controls (e.g. authentication, authorization, session management, access management) and provides developers with a list of actionable requirements for secure development.

Secure SDLC at OPSWAT is mapped into several key business functions and security practices:

1. Application Security Governance
2. Security Requirements & Assessment
3. Secure Design and Implementation
4. Application Security Verification
5. Application Security Operation/Maintenance

Application Security Governance

OPSWAT is a global company with offices around the world and has development centers in the US, Vietnam, Romania and Hungary.

The center piece of application security at OPSWAT is the AppSec team, a virtual and multi-national team with designated engineers from each product team who will drive security improvements to their own product as well as Secure SDLC. This approach allows OPSWAT to scale application security across many teams from all development centers by providing appropriate security context/training and build secure products.

The AppSec team has created a set of policies that drive our application security program:

• Policy for each product team/organization to make assessments and implement security controls based on ASVS/SAMM framework
• Open Source & Third Party component usage and policy
• Application Security Testing and Verification Policy
• Secure Package Verification Policy
• Application Security Awareness Training

One important aspect of our security program is the Awareness Training for development teams on application security which covers various topics, including secure design, threat modeling, secure coding, secure testing, and secure deployments. The training consists of traditional video as well as a hands-on platform where developers learn to code best practices on securing applications. The training program ensures that all developers receive tailored training solutions whether they are beginners or advanced security champions. Developers learn how to code securely through monthly learning paths that incentivize long-term engagement with the help of gamification, social features, and communities.

Security Requirements and Assessment

As part of the Secure SDLC process, product managers and key stakeholders are involved in security requirement gathering during planning meetings. The type of security requirements captured as part of this collaboration are listed below:

• Secure Functional Requirements: These are security related requirements integrated into each functional requirement of a product. See examples below:
  • Example 1: When a system has a user ID and a PIN number, a secure functional requirement may define the number of PIN guesses before an account is locked out.
  • Example 2: For audit logs, a derived requirement may support the integrity of the logs, such as log injection prevention.
• Functional Security Requirements: These are security services that need to be achieved by the system based on principles of Confidentiality, Integrity, and Availability. Examples of functional security requirements include:
  • Confidentiality: Authentication, Authorization
  • Integrity: Input validation, Error handling
  • Availability: Backup, server-clustering
• Non-Functional Security Requirements: These are non-functional Security requirements such as minimal performance requirements, scalability requirements, auditability, and up-time.
• Secure Development Requirements: These are required activities during software development which assure application software does not contain vulnerabilities. Examples are: “secure coding guideline”, “secure code review”, “secure design”, and “secure test methodology”.

Secure Design & Implementation

Security is incorporated into design and implementation as part sprints. The AppSec team members collaborate on defining and refining various security design and implementation best practices:

Threat Modeling - Threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle. Product teams conduct threat modeling which requires the following activities:

• Identify security objectives
• Identify assets and dependencies
• Model the attack possibilities
• Threat model interpretation
• Traceability matrix for reporting the attacks

Secure Design Best Practices - Application security principles (e.g. Fail Securely, Least Privilege, Establish Secure Defaults) are collections of desirable application properties, behaviors, designs and implementation practices. Product teams use these design principles to reduce the likelihood of a threat.

Secure Coding Best Practices - Product teams follow coding best practices which can be language independent as well as have language specific guidelines:

• Language independent secure coding best practices: Input data validation; Sanitize data sent to other systems; Eliminate compiler warnings.
• Language specific secure coding best practices
  • Example in Java: Ensure that keys used in comparison operations are immutable
  • Example in C++: Detect and handle memory allocation errors

Security Test Plan - QA engineers include security related artifacts as part of the overall software test plan:

• Security test cases for functional and non-functional security requirements
• Test data, including attack patterns (e.g. DOM based cross site scripting, Stored Cross Site scripting)
• Testing tools (e.g. port scanning, network sniffing)

Secure Code Review and Code review Checklist

• Secure Code review checklist based on OWASP Cheatsheet series
• Secure Code review policy (see below as part of security verification and testing)

Application Security Verification & Testing

As part of the Application Security Verification policy, product teams perform security verification and testing activities:

Security Architecture and Reviews: Any design change is reviewed by the engineering lead and senior engineers before implementation. The following security topics are often included in design/architecture review:

• Application Architecture
  • Encryption best practices
  • Authentication & Authorization
  • Auditing
• System and Network Architecture
  • Deployment standards
  • Hardening best practices
  • Access control
  • Auditing
  • Security controls verification

Security and Peer Code Review: Following secure coding guidelines (see above), code changes are reviewed by senior engineers and peers before the code is passed for further testing. The following common security flaws are checked as a priority:

• Authentication/authorization
• Injection flaws
• Improper error handling/exception flaws
• Encryption (Cryptography)
• Session related flaws
• Insecure configuration
• Auditing and logging

Static/Dynamic Application Security Testing result review: AppSec team regularly audits findings from Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools to make sure product does not contain severe vulnerabilities.

• SAST tools (white-box testing) are used early in the development process to analyze the source code for vulnerabilities. SAST tools are ideal for vulnerabilities that can be found automatically with high confidence, such as SQL Injection or XML configuration flaws. See an example below from SAST tool:



• DAST tools (black-box testing) are used to find vulnerabilities toward the end of SDLC. These tools can find run-time (e.g. memory flaws) and environment (insecure network configuration) related issues.

Security Testing: QA engineers perform application security testing as part of the overall test plan described above. Both automated and manual application security testing methodologies are used:

• Automated Dynamic Application Securities testing (DAST) tools are used to detect infrastructure and environment configuration vulnerabilities.
• For securities controls (e.g. information leakage in logging) that cannot be verified with automated tools, manual application security testing is performed.

Periodic and On-demand penetration testing: OPSWAT engages with external vendors to perform penetration and vulnerability assessments of Web applications as well as critical components. AppSec team members triage vulnerabilities found by external vendors to determine whether issues require code or configuration changes. For vulnerabilities that require code changes, application backlogs are created and resolve as quickly as possible.

Application Security Operation/Maintenance

Operation of cloud environment is the responsibility of the Cloud Ops team and is not part of SDLC. However, AppSec team members have other responsibilities after a product is released:

• Triaging application security Incidents raised by customers
• Reviewing and mitigating vulnerabilities found as part of external Pen-test
• Provide system and environment hardening guidelines (for on-premises product)

How does Secure SDLC help our customers?

As a leader in Critical Infrastructure Cyber Security, OPSWAT is committed to achieving the highest level of maturity in Secure SDLC and application security in order to provide our customers with the following benefits:

• More secure software, which will minimize exploitation and vulnerabilities for our customers
• Reduction of the risk associated with security breaches and loss of reputation
• Help address compliance of customer’s corporate security policies

For more information, contact us to schedule a meeting with one of our cyber security experts