3.1. Requirement specification and Design

3.1.1. Security requirements should be identified by the end users during system specification, be it for new information systems or enhancements to existing information systems. It may include but not limited to:

3.1.1.1. System access controls

3.1.1.2. Encryption of data in transit and at rest.

3.1.1.3. Compliance with any legal and regulatory requirements

3.1.1.4. Security of communications, includes private and public networks

3.1.1.5. Archiving or “housekeeping” functions for system performance or data retention purposes

3.1.1.6. Audit trail of login, activities, process executed

3.1.1.7. Reporting mechanisms to fulfill audit requirements.

3.1.1.8. SAML and Two factor capability

3.1.1.9. Hashed/salted passwords

3.1.1.10. Proper error handling

3.1.1.11. Access controls - role based access control RBAC

3.1.1.12. Logs (System/access/transaction)

3.1.1.13. Session management

3.1.1.14. Business logic checks

3.1.2. In the event that the end user is unable to identify security requirements, the developers and appropriate IT lead will recommend requirements 

3.2. Development and Secure coding

3.2.1. Use of a separate test environment should, if at all possible, be used to replicate the live system to allow assessments to be conducted without risk of adverse effect, with exceptions only allowed when it is not possible and when approved by the IT Director.

3.2.2. The use of personal or sensitive information for test purposes is not permitted.

3.2.3. Use of or cloning live data for systems development purposes are prohibited.

3.2.4. Access to development tools and system utilities will be restricted to authorized staff and will not be accessible from operational systems.

3.2.5. Access to program source code will be restricted and controlled by the lead developer/Software Architect

3.2.6. Backup of source codes through source control systems or other process is required

3.2.7. Change control to source codes should be applied

3.2.8. The lead developers/Software Architect should automatically be notified for any change of codes made by its team members

3.2.9. Changes should be reviewed and approved by the Lead developers prior to committing it to the source code.

3.2.10. Developers are to follow the current OWASP Secure Coding Principles (Please see latest OWASP secure coding guidelines) to help protect application service transaction from the following:

3.2.10.1. Incomplete transmission

3.2.10.2. Mis-routing

3.2.10.3. Unauthorized disclosure

3.2.10.4. Unauthorized message duplication or replay.

3.2.10.5. Internal Quality and Security Test

3.2.10.6. Testing based on the original design specification which includes security requirements must be done.

3.2.11. Positive and negative test must be done on all features which includes input validation, system time out, system log creation

3.2.12. System performance based on best practice guidelines (ie load testing, response time, latency, etc etc)

3.2.13. The test must ensure that the data returned from the service (API) is as expected as per the specification.

3.2.14. An application/software vulnerability test and code security scan must be conducted and any vulnerabilities found must be fixed based on priority and risk imposed.

3.3. Code Review Process

3.4. General Process

3.4.1. Initial Code Push: Once a developer believes their code is ready for review, they create a pull request (PR) against the target branch.

3.4.2. Automated Review: Before manual review, automated tools will scan the code to identify common issues.

3.4.3. Manual Review: At least one peer, but preferably two, reviews the PR in detail.

3.4.4. Feedback & Iteration: Comments, suggestions, or required changes are provided.

3.4.5. Approval & Merge: Once reviewers are satisfied, the PR is approved and merged.

3.4.6. Due to confidentiality requirements and being recognized as the position with the highest level of experience in terms of systems development and code review approval, code submitted by the Systems Architect will mostly be subject to Automated Review unless additional peer review is needed.

3.5. Automated Review

3.5.1. Static Code Analysis: Tools like SonarQube, ESLint, or similar should be set up to automatically scan the code for potential issues, including coding standard violations, potential bugs, or security vulnerabilities.

3.5.2. Code Coverage: Ensure that a sufficient percentage of the new code is covered by unit tests. A tool like Codecov or Coveralls can be utilized.

3.5.3. Build & Test Automation: The code must successfully build and pass all unit and integration tests in the CI/CD pipeline.

3.5.4. Security Scans: Use tools like Snyk or Dependabot to identify vulnerabilities in dependencies.

3.5.5. Automated Feedback: If any of the automated checks fail, feedback is provided directly on the PR. The developer must address these issues before a manual review begins

3.6. Manual Review

3.6.1. Reviewer Assignment: For small teams, everyone should be familiar with most parts of the codebase. However, try to select reviewers who have expertise in the modified area or feature.

3.6.2. Review Focus Areas:

3.6.2.1. Logic correctness.

3.6.2.2. Adherence to coding standards and best practices.

3.6.2.3. Potential performance bottlenecks.

3.6.2.4. Scalability and maintainability.

3.6.2.5. Security concerns.

3.6.2.6. Code clarity and documentation.

3.6.3. Feedback:

3.6.3.1. Comments should be constructive.

3.6.3.2. Highlight what you like, not just what you don’t.

3.6.3.3. Be clear about suggestions and required changes.

3.6.4. Exceptions

3.6.4.1.1. In rare cases, exceptions to this process may be required due to urgent fixes or other unforeseen circumstances. These exceptions should be discussed and approved by the team lead or manager. 

3.7. System Acceptance Test

3.7.1. UAT (User Acceptance Test) must be processed to ensure that the system works as intended and should include the relevant aspect of its security (ie access level control) and functionality requirements as required. This covers new information systems, upgrades/enhancements and new versions of the systems.

3.7.2. UAT will be satisfied with any of the following conditions:

3.7.2.1. Formal sign off process by the requestor.

3.7.2.2. No Major complaints after 1-week release/go live of add on/bug fixes. (Major complaints - defined as if the process/system is rendered unusable or will halt succeeding processes. Minor complaints - those that can be handled by work around/process change and can be treated as bugs)

3.7.2.3. Three successful live use cases with no errors within 1 week of release/go live.

3.8. Production change management

3.8.1. Implementation plans should include Risk assessment for its potential effects on the confidentiality, integrity and availability, both directly and indirectly in conjunction with other systems and assets

3.8.2. A system owner must be identified that will handle the maintenance and disposal of the system.

3.8.3. The criticality of the system in terms of maximum tolerable times to restore for emergency and full processing need to be established and agreed with the system owner. (SLA)

3.8.4. The backing up strategy and business continuity plan need to be drawn into the project plan and approved by the system owner.

3.9. Maintenance Phase

3.9.1. Appropriate backup and recovery setup should be utilized during maintenance with a remote backup copy if risk analysis suggests that is necessary

3.9.2. If bugs are discovered in a software application or system then in some form or another they may have an impact on confidentiality, availability or integrity. Any solution to the bug should be tested and installed at the earliest opportunity.

3.9.3. In the event that there are planned or unplanned changes with the Operating systems of the application, a review of the security and functional capability of the system must be done prior to any changes

3.9.4. Application vulnerability test must be conducted regularly wherein any weakness found must be fixed accordingly

3.10. Disposal Phase

3.10.1. Prior planning and actual decommissioning of systems needs to be undertaken and must include removal of access rights and removal of software from PCs and servers.

3.10.2. When a system is disposed of, security measures need to be in place to enable safe removal of equipment and software including data to ensure that the confidentiality of data is not compromised. This includes low level wiping of all hard disk drives where the system or its data has resided and removal of any system related access.

3.10.3. During disposal of any system, if required, software code, data and information may need to be archived in line with statutory requirements and internal/external audit requirements. The archiving of data will need to be overseen and signed off by system owners to ensure requirements have been fulfilled.

3.11. Outsourced Development

3.11.1. The company shall supervise and monitor the activity of all outsourced system development, using all relevant and applicable information on this document.

3.11.2. NDA’s should be signed and agreed by both parties prior to discussion of any critical design/information.

3.11.3. This policy should be forwarded agreed by and signed off by the outsourced developers.

4.1. Project / Feature request Approval

4.1.1. The following process is provided to ensure that all team members are guided in terms of how we approve, prioritize and decide allocation of resources/investments transparently. Our end goal is to enable the company to scale and innovate through digitization and use of technology which allows us to increase productivity and efficiency while lowering our support cost. All this must be done with a scarce set of resources and hence a transparent decision making process for which projects to understand with which priority and what resources are critical to provide the maximum return on investment.

4.1.2. New requirements will need to be presented with their respective VP for initial approval. The following items must be discussed and identified if applicable

4.1.2.1. Objectives and features

4.1.2.2. Process description – current and proposed

4.1.2.3. Workflow diagram – current and new

4.1.2.4. Benefit Analysis (indicate items like man hour saved/value to business)

4.1.2.5. If approved forward request to Transformation team for prioritization

4.1.3. IT Requirement Specification and estimation

4.1.3.1. Transformation team will meet up with the requesting party to provide estimates in terms of development time and will help identify and recommend security requirements and other features for cost benefit analysis.

4.1.3.2. Identify and validate requirements with requesting party for the following main items

4.1.3.3. In the event that the end user is unable to identify security requirements, the developers and appropriate IT lead will recommend requirements

4.1.3.3.1. Input

4.1.3.3.2. Outputs

4.1.3.3.3. Process or Work Flow

4.1.3.3.4. Logic and computation formula

4.1.3.3.5. Security Control 4.1.3.3.6. Reports

4.1.3.4. Transformation team will propose the following:

4.1.3.4.1. Recommendations/logic changes as necessary

4.1.3.4.2. Alternative off the shelf solutions (if applicable)

4.1.3.4.3. Estimation of project cost in terms of Development Man hour

4.1.3.4.4. Estimate support cost (dev man hour per week)

4.1.3.4.5. Requesting party will forward and document agreed requirements to the Transformation team.

4.1.4. Digital Transformation team approval

4.1.4.1. Team will comprise key decision makers - IT Director, Vice-President, People Operations and Transformation ,System Architect,Transformation Director . 4.1.4.2. Group will help validate Cost Benefit Analysis based on

4.1.4.3. Project impact/Value (man hours saved) 4.1.4.4. Estimation of dev man hours

4.1.4.5. Support cost

4.1.4.6. Recommendation if Buy or build or hard stop

4.1.4.7. Update Management Committee and Executive Committee on projects and status

4.2. UAT

4.2.1. Once software development is done, a User Acceptance Test will be conducted based on the specification. Features of the system will be tested if working as intended. 4.2.2. If there are bugs or UAT fails, the system developer will fix the issue based on agreed timeline until UAT satisfies the requirement

4.3. Deployment

4.3.1. Once UAT passes and is accepted, system developers will deploy the system/application based on agreed items.

4.3.1.1. Newly developed systems and additional feature will include Implementations plans

4.3.1.2. Bug fixes will be rolled out as per agreed time frame.

4.3.1.3. Trainings and manuals are to be provided if applicable

5.1. Senior Leadership Team are responsible for ensuring that staff and managers are aware of Infinit-O IT security policies and that they are complied with. Managers need to be aware that they have a responsibility to ensure staff have the relevant knowledge concerning security of information and systems which they develop or maintain. Staff involved within the systems development lifecycle need to be aware of their responsibilities toward security of both systems and information. Designated owners of systems who have responsibility for the management of systems and inherent information, need to ensure that staff have been made aware of their responsibilities toward security.

6.1. Specification– as the need arise

6.2. Non-Disclosure Agreement (NDA) – as the need arise 6.3. User Acceptance Test (UAT) – as per agreement

7.1. IT Team

7.2. Software Development team

7.3. Managers/Directors

7.4. VPs