Secure Software Development

At the requirements gathering stage, our security specialists prepare an application risk profile. The document describes possible entry points for attackers and categorizes security risks by the severity level, including their impact and likelihood.

Relying on the risk profile as well as organizational security and privacy policies and standards, regulatory requirements (e.g, of HIPAA, PCI DSS, etc.), business analysts elicit and document security and resilience requirements for future software, including:

• Identification requirements
• Authentication requirements
• Authorization requirements
• Integrity requirements
• Non-repudiation requirements
• Privacy requirements
• Survivability requirements

After ScienceSoft’s team designed a high-level software architecture and established the major data flows and data entry points in the future application, they proceed with threat modeling. Our team performs the following activities:

• Decomposing the planned application architecture into functional components, determining threats to each of the components.
• Threats categorization and prioritization.
• Planning and prioritizing controls and countermeasures for possible attacks.

Based on the described security and resilience requirements and threat modeling activities, our team plans:

• Secure software architecture (e.g., employing application partitioning, container-based approach).
• Security features (cryptography (DES, 3DES, AES, RSA, blowfish), audit/log, user identification, verification and authorization (password-based, multi-factor, certificate-based, token-based, biometrics).
• Test cases to be executed at the testing and maintenance stages.

Threat modeling at ScienceSoft is typically iterative and spans the entire SDLC cycle, from a high-level architecture (interaction between software modules) to a detailed architecture design and implementation (specific code functions and methods).

At this stage, ScienceSoft’s developers:

• Employ secure coding practices to mitigate or minimize high-risk implementation-level vulnerabilities.
• Use only secure development tools (libraries, frameworks, etc.).
• Perform regular unit tests.
• Perform automated static code analysis.
• Conduct language-specific, checklist-based code peer reviews to detect types of vulnerabilities that can’t be identified by automated security review tools.

At this stage, ScienceSoft’s team proceeds with:

• Conducting penetration testing of software and its infrastructure (black box, gray box, and white box pentesting); fixing identified security issues and conducting regression testing. Note: When we develop software iteratively, these activities are performed in every build.
• Final Security Review (FSR) by subject-matter security experts to verify that security risks identified in the course of the previous security activities have been properly addressed (fixed or have a mitigation plan in place).
• Creating an incident response procedure.
• Setting application security monitoring, performing manual and automated security regression testing.
• (if applicable) Submitting your application for external validation to officially attest compliance with industry regulations.
• Establishing a feedback process and tools for users, white hat hackers, etc. to report on revealed vulnerabilities.