intelliHR's Software Development Life Cycle policy defines the high-level requirements for providing business programme managers, business project managers, technical project managers, and other project stakeholders guidance to support the approval, planning, and life-cycle development of intelliHR software systems aligned with the Information Security Program. intelliHR establishs and maintains processes for ensuring that its computer applications or systems follow an SDLC processes which are consistent and repeatable, and maintains information security at every stage.
Software Development Phases and Approach Standard
A Software Development Project consists of a defined set of phases:
Envision
In line with intelliHR’s vision to transform workplaces for the better, product management and company executives determine the needs of customers and the causes that they may have to implement intelliHR’s platform and products.
Strategize
To bring intelliHR’s vision into reality, the product team determine features, products and offerings to be delivered to address customer needs and streamline implementation.
Alternative solutions and conflicting priorities are welcome during this phase.
Select
The product team alongside engineering management determines the most valuable projects to bring into team roadmaps for investigation and broad analysis.
Success criteria and proposed investment of resources for the project are also determined during this phase.
Explore
The product team delivers a problem statement and determines success criteria for the project to an applicable domain team. This may be based on customer workshops, feedback, market research or in effort to lead industry expectations.
Visual representations and prototypes of the proposed solutions may be generated at this phase, in order to gain customer feedback.
Design Solution
The domain team and investigates alternative solutions or execution methods to achieve a solution. The team will endeavour to produce a solution that is:
- Incrementally deliverable, in order to receive customer feedback as regularly and early as possible
- Extensible and scalable, in order to accommodate customer requirements that may not yet be in scope
- Reliable and reproducible, in order to reduce dependency on vendors, platforms and technologies as much as possible
- Measurable, in order to monitor effectiveness for future work
Together with the Chief Technology Officer and any relevant principle engineers, the most valuable solution is determined with a broad estimate.
If visual prototypes of the solution are required and are not yet validated, they will be produced and validated during this phase by team members within the domain team.
The solution is broken down into increments that can be released in order, each having their own broad estimates (relevant to agile sprints).
Build
The domain team selects the first deliverable increment and breaks it down into component tasks, each given a numeric weighting. These tasks are assigned to work iterations (sprints) based on their priority and against maintained estimates for that team’s iteration velocity.
The domain team executes these tasks as part of their day-to-day duties. Commonly these tasks require the production of code assets that are persisted within version control platforms (Git).
The domain team, together with dedicated quality assurance team members will produce unit, regression and automated test assets to ensure reliability and maintenance of their work. These assets are also maintained in version control platforms.
Once a body of work is determined to be nearing releasable, demonstration and feedback sessions are conducted internally.
Once any issues from those sessions are resolved, external sessions and presentations are conducted by customer success or account management team members. Once any issues are resolved to the satisfaction of stakeholders, the body of work is deemed fit for limited release.
Adopt
As new bodies of work are deemed fit for limited release the following may occur:
- training material and release notes produced for intelliHR team members
- training material produced for the benefit of customers
- opt-in customers are nominated, and the new body of work is released behind a feature flag for their evaluation
- product team and executives may determine a new feature or offering to be fit for general access
After the above, a body of work may be determined fit for general access. If so, any feature flags are removed and the change is made available to all customers.
Evaluate
All interactions with the intelliHR platform and products are monitored using de-identified methods. This monitoring allows the *domain and product teams* to report on the engagement, uptake and overall success of any changes they produce.
After any major releases, the metrics capturing included in the body of work (from the Design Solution phase) are monitored and evaluated against the success criteria for the project (from the Select phase).
Customer feedback may also be taken during this phase.
The output of these metrics and customer feedback is recorded and used to inform future Select and Explore phases.
SDLC Security Control Guidelines
The SDLC process will adhere to the following information security controls:
- Adequate procedures should be established to provide separation of duties in the origination and approval of source documents. This shall include, but not be limited to, separation of duties between Personnel assigned to the development/test environment and those assigned to the production environment
- Modification of code or an emergency release will follow the change control standard Secure programming standards should be followed. Secure code training should be provided to intelliHR’s developers
- Secure development environments will be created, based on:
- sensitivity of data to be processed, stored, and transmitted by the system
- applicable external and internal requirements, for example, from regulations or policies
- security controls already implemented by the organization that support system development
- trustworthiness of personnel working in the environment
- the degree of outsourcing associated with system development
- the need for segregation between different development environments
- control of access to the development environment
- monitoring of change to the environment and code stored therein
- backups are stored at secure offsite locations
- control over movement of data from and to the environment
- All software deployed on Corporate or Hosted infrastructure must prevent security issues including but not limited to those covered by SAN and OWASP
- Code changes are reviewed by team members other than the originating code author and by team members who are knowledgeable in code review techniques and secure coding practices
- Overrides of edit checks, approvals, and changes to confirmed transactions should be appropriately authorized, documented, and reviewed
- Application development activity should be separated from the production and test environments. The extent of separation, logical or physical, is recommended to be appropriate to the risk of the business application or be in line with customer contractual requirements. The level of separation that is necessary between production, development, and test environments should be evaluated and controls established to secure that separation
- All changes to production environments should strictly follow change control procedures, including human approval of all changes, granted by an authorized owner of that environment. Automated updates should be disallowed without such approval
- Active production environments should not be re-used as test environments. Inactive and/or decommissioned production environments should not be used as test environments unless all private data has been removed. Test environments should not be re-used as production environments without going through a decommissioning and recommissioning process that cleans all remnants of test data, tools, etc.
- Team members who are responsible for supporting or writing code for an internet-facing application, or internal application that utilizes web technology and handles customer information, should complete annual security training specific to secure coding practices. For team members supporting or writing code for an internet-facing application, training should also include topics specific to internet threats. The team member should complete the training prior to writing or supporting the code. The training must include OWASP secure development principles as well as OWASP top 10 vulnerability awareness for the most recent year available
- Custom accounts and user IDs and/or passwords should be removed from applications before applications become active or are released to customers
- Production data should not be used in testing or development environments Security controls that are in place for the production copy in the test system should be production quality (for example, mirroring the production controls over the data)
- When conducting quality assurance (QA) testing prior to the release of a new feature requiring user input where constraints on user input may be reasonably understood, feature acceptance tests must include testing of edge and boundary cases
For situations demonstrating that testing needs to use production data, the requirements are the following:
- The Information Resource Owner will provide approval before production data can be used for testing purposes
- Wherever possible, the production data should be tokenized or anonymized instead of using production data directly
- Testing and parallel runs should use a separate copy of production data and the test location or destination should be acceptable (for example, loading confidential production data to a laptop for testing is not acceptable)
- The data should not be extracted, handled, or used by the test process in a manner that subjects the data to unauthorized disclosure
- The data should be accessed on a need-to-know basis
- Normal test activities should not use production data. In cases where test activity requires access to production data, access to production data should be restricted to only those team members who have a documented business need. Only the information with the documented business need should be accessible by those users
- Production data used for testing should be securely erased upon completion of testing
- Test data and accounts will be removed before being placed into production
- Restricted/Protected Information will be encrypted according to the Encryption Standard while at rest or in transit
- Error messages must be handled securely and they must not leak sensitive information
Change Management
Software Installation and Change on Operational Systems
- Operating system applications and software will only be implemented after extensive and successful testing. The tests will cover:
- Usability
- Security
- Effects on other systems
- User-friendliness
- Tests will be conducted on separate systems (test environment), and all corresponding program source libraries will also be updated, as appropriate
- The operational software, applications, and program libraries of intelliHR will only be updated by trained team members upon appropriate management authorization
- Company operational systems will only hold approved executable code, not development code or compilers
- A configuration control system will be used to keep control of all implemented software as well as the system documentation
- Previous versions of software will be retained as a contingency measure
- Old versions of software will be archived, together with all required information and parameters, procedures, configuration details and supporting software for as long as the data are retained in archive
- There will be a rollback strategy in place before changes are implemented
- An audit log will be maintained of all updates to operational program libraries
- All decisions to upgrade to a new version release must take into account:
- Business requirements for the change
- Security of the release, for example, the introduction of new information security functionality or the number and severity of information security problems affecting this version
Change Control Procedures
- A record of agreed authorization levels will be maintained
- Changes are only submitted by authorized users
- Controls and integrity procedures will be reviewed to ensure that they will not be compromised by the changes
- All software, information, database entities and hardware that require amendment will be identified
- Security critical code to minimise the likelihood of known security weaknesses will be identified and checked
- Formal approval must be obtained for detailed proposals before work begins
- Authorized users must accept changes prior to implementation
- Changes will be implemented at a time that is least intrusive to business processes involved
- Vendor-supplied software will be used without modification; in the event that a modification is necessary, the following will be evaluated:
- Risk of compromising built-in controls and integrity processes
- Vendor consent
- Getting the modifications from vendor as standard updates
- Impact of owning the responsibility for maintaining the program
- Compatibility with other software in use.
- A technical review of applications will be conducted after changes to operating platforms (operating systems, databases, and middleware platforms). The review will include:
- Application control and integrity procedures to ensure that they have not been compromised by the operating platform changes
- Timely notification of operating platform changes to allow appropriate tests and reviews to take place before implementation
- Appropriate changes are made to the business continuity plans