We use a Modified Agile development methodology.

The Agile model allows us to quickly delivers a working product and is considered a very realistic development approach. The model produces ongoing releases, each with small, incremental changes from the previous release. At each iteration, the product is tested.

This model emphasizes interaction, as the customers, developers and testers work together throughout the project.

What is Agile?

In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features for a release.

The standard Agile model is:

  • Planning - Deciding what goes in a specific release
  • Requirements Analysis - Generating requirements for a specific feature
  • Design - Design based on requirements
  • Coding - Python (for the back end), JavaScript (for the front end)
  • Testing - Quality Assurance
  • Deployment - Deployment to test and production server (including acceptance testing)

What is Modified Agile?

Modified Agile includes additional steps to ensure additional objectives are met. In our case, information security related tasks are added the the standard development process.

Our Modified Agile Model is:

  • Planning - Deciding what goes in a specific release
  • Requirements Analysis - Generating requirements for a specific feature
  • Design - Design based on requirements
  • Coding - Python (for the back end), JavaScript (for the front end)
  • Security Review - Features are peer reviewed to determine if they introduce security concerns
  • Testing - Quality Assurance
  • Deployment - Deployment to test and production server (including acceptance testing and)

What happens during the 'Security Review' step?

  • Peer review - other developers review code to spot potential security issues
  • Static code analysis - automated tools are used to scan the code for potential issues
  • Penetration testing - automated tools are used to detect potential issues
  • OWASP testing - Review of the code with respect to http://www.OWASP.org guidelines

Examples of peer review:

  1. Check if passwords are one way hashed when at rest (where possible)
  2. Check if data entry is masked where appropriate in the user interface
  3. Check for use End-of-Life (EOL) or End-of-Support (EOS) tools and modules

Source Code Management (SCM)

Git is used for source code management. Git is a distributed version-control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows and easy tracking of source code changes over time.

Configuration Management

If a change to an existing feature or a new feature is requested, a release must be "replanned" using the following steps:

  • Requested change is logged as a ticket
  • Impact analysis of change is performed
  • Requirements are updated
  • Requirement are reviewed by management (and further updated as needed)
  • Decision is made to a) delay release to incorporate change b) defer change to future release
  • Communication of decision to stakeholders
  • Implementation is approved and begins

All code changes associated with request are tracked using the SCM (see previous section). All requirement changes are tracked in associated ticket.

Customer Data

In the event customer data is required for resolving an issue or testing a new software release, the data must be made anonymous (obfuscation) before moving to development or test systems.

ISO/IEC 27000 Guidelines

We adhere to the controls described in Annex A.14 (ISO 27002) to ensure that information security is an integral part of our development process.

14.1 Security requirements of information systems
Security control requirements should be analyzed and specified, including web applications and transactions.

14.2 Security in development and support processes
Rules governing secure software/systems development should be defined as policy. Changes to systems (both applications and operating systems) should be controlled. Software packages should ideally not be modified, and secure system engineering principles should be followed. The development environment should be secured, and outsourced development should be controlled. System security should be tested and acceptance criteria defined to include security aspects.

14.3 Test data
Test data should be carefully selected/generated and controlled.