Security SOW review
Security SOW review

Security SOW review

As technology continues to advance, the need for secure software development has become increasingly important.

But there is not so much information on how to work with security projects from a technical manager's point of view.

I would like to share specific focus points needed to prepare a good security project Statement Of Work (SOW) and how to include security questions in your project lifecycle.


Secure Development Lifecycle

A key component of the software development lifecycle is security.

Secure development seeks to ensure that a product is not just protected from "common threats," but also that its level of security is predictable and meets its specific needs. Every product is handled uniquely, and throughout the development process, specific efforts are made to detect and mitigate vulnerabilities unique to that product. Threats to confidentiality, integrity, and availability, as well as their corresponding mitigations, are gathered based on industry standards, best practices, and any unique requirements of the product being developed.

Best practices from OWASP and PCI DSS compliance requirements should be taken into account right away and have an impact on subsequent security-related actions.

How to achieve it? The answer is simple: the development team should be trained for it. Prior to beginning development, mitigations should be considered, and the security impact should be monitored. Security testing activities should also be included.

A good strategy is to utilise OWASP Code Review Guide to effectively find vulnerabilities.

No alt text provided for this image
OWASP

Security code reviews examine modifications that may have an impact on data privacy, compliance with security regulations, or the use of security features like encryption, authentication, and authorization. The individuals in charge of the project's security (security advisers, security champions) conduct security code reviews.

High-priority factors to check:

  • Code structure
  • Input/output processing
  • Data persistence, data footprint
  • Security context
  • Transport
  • Resources consumption
  • Multithreading and race conditions
  • Exception throwing/handling
  • Logging


If possible, it should also do:

  • Impact analysis for introduced functionality
  • Threat models are reviewed for existing features.
  • Attack surface review
  • Review of 3rd party dependencies
  • Review of mitigation plans
  • Deployment model assessment
  • Documentation review


DevSecOps

No alt text provided for this image
DevSecOps

At the heart of secure development is the idea of DevSecOps, which promotes a balance between human intelligence and automation.

DevSecOps is a combination of development, security, and operations. By integrating automation, agility, feedback loops, and cross-functional cooperation into the SDLC, it aims to accelerate the delivery of secure, high-quality software. To enable secure software development, DevSecOps uses the same DevOps concepts and prioritizes the following:

  • Security should be the responsibility of everyone involved in the development process.
  • Use automation whenever possible.
  • ???Shift Left - philosophy highlights the value of testing and evaluating code quality at the start of the Software Development Life Cycle (SDLC) instead of being performed only at the end of the process.
  • Check dependencies for vulnerabilities.

DevSecOps approach makes the process of eliminating security issues context-specific and effective. Appropriate tooling is:

  • SAST - Static Application Security Testing
  • DAST - Dynamic Application Security Testing

and more complex:

  • RASP – Analyze & Self-defense at Runtime
  • IAST - Interactive Application Security Testing
  • SCA - Software Composition Analysis
  • By understanding and utilizing appropriate tooling, teams can continuously leverage their existing SDLCs to create a secure product.

No alt text provided for this image

Following this article, you already understand what important processes should be added for a secure development project. Let’s go back to an RFP/RFI/SOW review.


Secure SOW checklist

When responding to RFP/RFI/SOW questionnaires related to security, there are several criteria to consider. Threats and respective mitigations in confidentiality, integrity, and availability should be gathered based on industry standards, best practices, and the particular requirements of the product under development.

You can check out my article, where I gave an overview of what SOW is and how it should be cooked prior to sign-off.

Checklist for security RFP/RFI/SOW documents:

  • Integrating security requirements into the system is not omitted as long as functional and non-functional requirements are met in the design and verification phases.
  • Information security reviews of business requirements are carried out as part of the security development process (security/privacy assessments) by the development team or a separate application security team.
  • Privacy requirements are clearly defined.
  • Unauthorised disclosure of application configuration information - connection strings, encryption keys, and other sensitive data are thought to be found in the application configuration. Thus, both the hazards of information disclosure and tampering must be prevented from affecting the configuration files.
  • Software vendors must guarantee code integrity. The code is shielded against unauthorized changes while it is being developed. Testing and code reviews maintain the integrity of the code.
  • Analysis of software security risks. An impact analysis is done, and every change is evaluated and reviewed before being implemented. With the application owner's approval, all changes are made.
  • Required security features must be included in the application design.
  • Security verification tests. Security features must be built, validated, and tested in accordance with this requirement. The security testing team can be involved in this process.
  • Approval and use of production data for testing purposes are clearly defined.
  • Developer access during testing is restricted to certain groups only.
  • Only the tools and components that are necessary are configured in the production environment. It cannot be used for debugging or development.
  • Acceptance testing is defined.


Implementing a secure development practice along with DevSecOps principles is crucial for creating secure software products. By considering industry standards and best practices when responding to RFP/RFI/SOW questionnaires related to security, teams can ensure that their products meet necessary security requirements.

要查看或添加评论,请登录

Oleksii Popov的更多文章

  • The AI Shift in Software Development: What's Next for Our Jobs?

    The AI Shift in Software Development: What's Next for Our Jobs?

    As a Manager in engineering and Solution architect, I follow market and technology trends to understand changes. The…

    3 条评论
  • RESTful API key concepts

    RESTful API key concepts

    Lots of people misunderstand the concept of REST API. They often call it a framework or a tool.

    3 条评论
  • 1-to-1 guide

    1-to-1 guide

    1-2-1 Meetings: A Regular Check-In for Growth and Development One-to-one (or 1-2-1, or 1-on-1) meetings are regular…

    1 条评论
  • How AI impact engineers’ careers

    How AI impact engineers’ careers

    As the world becomes increasingly digitized, the role of software development has become more important than ever…

    4 条评论
  • SOW review

    SOW review

    A well-written Statement of Work (SOW) is the key to a successful project, and a thorough review of the document is…

  • Avoiding 6 common pitfalls in Software Project Pre-Sales

    Avoiding 6 common pitfalls in Software Project Pre-Sales

    Underestimating project complexity. Without a deep understanding of requirements and technical details, timelines and…

  • Pre-Sales Solution presentation

    Pre-Sales Solution presentation

    As pre-sales engineering teams strive to understand their customer's needs, the ability to effectively present…

  • Pre-Sales Solution Architecture Workshop

    Pre-Sales Solution Architecture Workshop

    Once you had your initial workshop and pinpointed the essential needs for the project, you were ready to create an…

    2 条评论
  • Pre-Sales Client Workshop

    Pre-Sales Client Workshop

    Over the years of work in the field of #engineeringmanagement, I have been involved in the sales and onboarding…

社区洞察

其他会员也浏览了