‘Decoding ‘Application Sec’ or ‘Secure Software/System Engineering’: Going beyond SAST and DAST

“App Sec” is often synonymous with SAST and DAST. SAST, or Static Application Security Testing, is a white-box methodology for examining an application’s source code for vulnerabilities. DAST, or Dynamic Application Security Testing, is a black-box methodology for testing an application from the outside.

Start-up software development organizations may use cost-effective SAST and DAST tools, like open source/freeware and service-based models. As companies grow, software development should align with established engineering disciplines. Limiting security measures to SAST and DAST can be counter-productive in the long run.

Implementing a secure Software Development Life Cycle (SDLC) is very critical. Common SDLC phases include planning, architectural design, coding, testing, deployment, and ongoing maintenance. Traditionally, security activities have been constrained to the testing phase, often resulting in late discoveries of vulnerabilities. Integrating security activities throughout the SDLC ensures early detection and resolution of issues.

A secure SDLC process incorporates security assurance activities such as security requirement identification, threat modeling, architectural analysis, and secure code reviews. Penetration testing is an integral part of this process. The primary advantages of a secure SDLC approach include reduced business risks, continuous security implementation, stakeholder awareness about security considerations, early detection of bugs, and cost reduction.

Security Software Engineering: R3D Approach

Security Requirements Engineering: Security requirements should be captured as part of the requirements phase to create a strong base for architecting the solution. Due diligence for maintaining the confidentiality, integrity, and availability of Personally Identifiable Information (PII) is mandatory. Requirements should address undesired behavior, access control, database security, and identify stakeholders and data that needs protection. A checklist with security parameters is created, and the risk score of the application is computed.

Security during Design: Threat modeling is conducted to identify and mitigate vulnerabilities based on the application’s risk score. Various methodologies, like STRIDE and PASTA, Troke, VAST, can be employed.

Security during Development: Secure coding practices and static security code reviews using SAST tools are essential. Organizations with integrated code review functions produce more secure code. Human reviewers are necessary to complement automated tools and understand the business context.

Security during Deployment: Change Management, Change Evaluation, and Release and Deployment practices from ITIL should be used to prevent instability in operations. The Change Advisory Board (CAB) ensures all prerequisites are met before software is released into production.

Secure SDLC Models

Organizations can explore various secure SDLC models to develop or benchmark their practices:

• Microsoft Security Development Lifecycle (MS SDL): Consists of practices that support security assurance and compliance, reducing number and severity of vulnerabilities.
• NIST SP 800-160: Emphasizes an integrated, holistic security perspective across all life cycle stages by defining the problem context, the solution context, and the trustworthiness context.
• OWASP SAMM Project: An open framework for formulating a software security strategy tailored to specific organizational risks.
• BSIMM: A study of existing software security initiatives, reflecting the practices of successful organizations, consisting of 12 practices organized into four domains Governance, Intelligence, Secure software development lifecycle (SSDL), Touchpoints and Deployment.

Umesh Kumar
Head – Cyber Security
Godfrey Phillips India

- Advertisement -