Secure Software Development

Navigation Menu
    Add a header to begin generating the table of contents
    Scroll to Top

    Overview

    The aim of the Profectus Secure Software Development policy is to establish effective guidelines defining the minimum practices to ensure secure code is developed, implemented and tested prior to client acceptance and production software releases.

    As intrusions and exploits have begun to target gaps within public facing or accessible software applications rather than the network perimeter itself, the overall scope and role of information security has changed to include and even focus on effective and secure development practices to mitigate risk associated with malicious code moving through networks.

    All software development practices and software testing must include security as a part of any delivery ensuring the confidentiality, integrity and availability of information is maintained to support and enable effective business operations.

    Scope of this policy

    This policy covers the development practice for all technical staff across all Profectus developed products and services. This includes all client-facing applications as well as any software services built for Profectus internal use only.

    This policy also covers any development performed by contractors or any other third-party support services.

    Much of this policy is derived from and supports the principles developed as a part of The Open Web Application Security Project (OWASP). Refer to the published security documentation by OWASP for additional materials and other resource

    Roles and Responsibilities

    It is the responsibility of all software development and engineering staff to ensure the policies and guidelines contained and referenced herein are adhered to.

    The relevant project and development team leads are responsible for ensuring all members of their team adhere to the principles contained within this document.

    It is the responsibility of the CTO to ensure communication of this policy to all team members. This includes any updates or changes to the guidelines.

    This document shall be reviewed at least annually as part of the overall policies review.

    Common Vulnerabilities

    A description of the most common vulnerabilities arising as a direct result of inadequate security practices are listed on the OWASP top 10 Web site (https://owasp.org/www-project-top-ten/). All members of Profectus Software development teams, including external contractors, must periodically review this list to maintain familiarity. Specific training sessions will be run to refresh this knowledge, and ensure team members are maintaining their own professional knowledge of these issues.

    Policies and Procedures

    All software developers and associated technical staff shall ensure that all development is validated with the most recent version of this document and associated OWASP principles.

    The following high-level policy check-list items form the basis for secure software development and delivery.

    • Data Validation
    • Authentication and Password Management
    • Authorisation and Access Management
    • Session Management
    • Sensitive Information Storage or Transmission
    • System Configuration Management
    • General Coding Practices
    • Database Security
    • File Management
    • Memory Management

    Sample specific guidelines

    Profectus software Development teams will use the OWASP Top ten proactive Controls and Secure Coding Practices Quick reference guide as their main references for developing secure software.

    Development Methodology

    Profectus software development employs Agile Principles and Practices as a guide to all delivered technology products and services. Agile software development supports the overall goal of secure code and spans the entire life-cycle into delivery and support.

    Software development source code repositories

    Profectus application source code is managed within Subversion and git repositories. Access to these repositories is restricted to relevant software development team members only and is granted and controlled by the CTO via DevOps Engineers.

    Access to these repositories by any other staff members outside the development teams is strictly not permitted.

    Agile security practices

    When capturing software requirements the information security component as it relates to that feature shall be discussed and scoped in as a testable deliverable. This means that for each agile story or task added to an iteration for development, a separate section shall be included outlining any specific information security requirement or side-affect.

    Security must be incorporated throughout the agile process using the following guidelines:

    • Verify security early and often

    • Validate the current state

    • Identify what needs to be protected

    • Determine what will be built

    • Understand the current security landscape

    • What happens if things go wrong?

    Where appropriate software development teams will include a security component to the project feature’s “definition of done”. Use of peer code reviews within and across teams is mandated to ensure that relevant feature implementations are socialised amongst the team as well as allowing for a broader assessment of the implementation as it relates to security.

    The figure below illustrates the typical agile development process.

    Incorporating secure practices in the above model occurs at every stage – formalised as a part of the user story itself as outlined or incorporated into the overall review and testing process. The above figure including secure practice checkpoints changes as shown below.

    The above ensures that security assessments and validation is performed throughout the process and continues into production. Adding security acceptance criteria into relevant stories clarifies the requirement and validates the criteria as a part of QA and testing.

    Continuous improvement and delivery

    Within the development environment at Profectus where Continuous Delivery is practised aggressively, incorporating security elements within the process is critical. Effective adoption of secure development practices is achieved as the process becomes a key part of the overall development culture.

    Continuous delivery build pipelines should incorporate security testing as automated processes. Automated checks for library and associated component updates should be performed here too, as well as update schedules for any external dependencies.

    It is expected that teams learn and improve iteratively in line with deliverables. Threat models need to be maintained and current. Records of key architectural design decisions should be maintained for reference and may include evidence and actions after an attack or breach has been detected.

    Incidence response planning

    In the event of any suspected or actual software or data security breach the Profectus Information Security Breach Response Plan will be followed.

    Secure Code Guidelines

    Adhering to the secure development policies outlined here is a requirement for all software development for all client-facing and internal-only systems and interfaces. All development code shall be validated and tested against the standards defined – this will ideally form part of the automated build pipeline and associated processes.

    Where any tests across any guideline fails, that build will be marked as failed and marked for action. The review and validation ensures that code exhibits fundamental security properties to include correctness, predictability, and attack tolerance.

    A high-level policy check-list for secure code development is listed below.

    • Ensure code meets the level of confidence that software is free from exploitable code vulnerabilities, regardless of whether they are already designed into the software or inserted later in its life cycle.
    • Ensure code provides predictable execution or justifiable confidence and that the software, when executed, will provide security functionality as intended
    • Never trust incoming data to the system, apply checks to this data
    • Disable or redact error messages that return any sensitive information to the user
    • Use object inheritance, encapsulation, and polymorphism wherever applicable
    • Use environment variables prudently and always check boundaries and buffers
    • Applications must validate input to ensure it is well-formed and meaningful

    The above is a non-exhaustive guide only and should be added to or modified as required per project.

    Any specific omissions from the guide above, must first be communicated to the team and technology leads before being implemented as a part of any build.

    Development Tools

    Depending upon the development environment and technologies employed, development tools at Profectus will typically be derived from the following list.

     

    Software Description
    Eclipse Java Platform IDE (supports multi-language)
    IntelliJ IDEA Java Platform IDE (supports multi-language)
    Visual Studio Code General Purpose IDE (supports multi-language)
    MS Visual Studio .net platform IDE
    DBeaver Database management and SQL tool

    The above is not exhaustive and will depend on the underlying development platform, specific need and infrastructure. Any departure from the above will be approved by the relevant team leads.

    Databases, applications servers, containers and other specific technologies will be assessed on a need and deployment profile basis for security and fitness for purpose.

    PROFECTUS GROUP

    Australia

    +61 (3) 9009 8500
    Level 12, 492 St Kilda Road
    Melbourne
    Victoria 3004

    New Zealand

    +64 (9) 215 3479 Profectus, Rewired, Level 2/96 Saint Georges Bay Road, Parnell, Auckland 1052

    Vietnam

    +84 (28) 7107 8108 Support Office
    Level 2, Dinh Le Building
    1 Dinh Le street, Ward 12, District 4, HCMC, Vietnam

    © Copyright Profectus Group 2020 – Privacy PolicyTerms & Conditions