Develop software security standards and guidelines

[godfreykutumela]

Goal:

Establish standards and guidelines for secure coding to help find and remove vulnerabilities that could be exploited by cyber attackers!

Acceptance Criteria:

• [ ] TBD

Complexity: Medium

Uncertainty: Low

---

Tasks:

• [ ] TBD [ @? ]

Done

• [ ] Acceptance Criteria pass
• [ ] Designs are up-to date
• [ ] Unit Tests pass
• [ ] Integration Tests pass
• [ ] Code Style & Coverage meets standards
• [ ] Changes made to config (default.json) are broadcast to team and follow-up tasks added to update helm charts and other deployment config.
• [ ] TBD

Pull Requests:

• [ ] TBD

Follow-up:

• N/A

Dependencies:

• N/A

Accountability:

• Owner: @godfreykutumela
• QA/Review: @godfreykutumela

[godfreykutumela]

I have developed a framework for the code security standard for everyone to review and add to it - https://docs.google.com/document/d/1oluhsqzXj5epCripU7xFhhvVUvwMWghq/edit?usp=sharing&ouid=111271012303486374335&rtpof=true&sd=true

[godfreykutumela]

Mojaloop Software Security Standard This is divided into five distinct focus areas to broaden and widen the detection capability for all types of application security flaws. What is required is to create code security rules for each of the areas below:

1. Application design security flaws To avoid software design flaws from being introduced in the applications, rules should be created to enforce the following principles.

• Earn or give, but never assume trust
• Implementation of a zero-trust access model
• Use an authentication mechanism that cannot be bypassed or tampered with
• Authorize after you authenticate
• Ensure all events and transactions are immutably logged
• Establish an audibility framework with role-based access restrictions

Ensure that all services and components do not trust each other and must self-identify and authenticate in all interactions. Strictly separate data and control instructions, and never process control instructions received from untrusted sources Understand how integrating external components changes your attack surface Be flexible when considering future changes to objects and actors.

The reference architecture security model will also be leveraged to create rules for this section.

2. Business logic security flaws

Business logic vulnerabilities are flaws in the design and implementation of an application that allows an attacker to elicit unintended behavior. This potentially enables attackers to manipulate legitimate functionality to achieve a malicious goal.

A logic flaw happens when an application does not behave as expected. It occurs when some logic steps or a workflow can be avoided, circumvented, or manipulated by an attacker. The attacker diverts a workflow in its own interest, it isn't a technical mistake, but an opportunity granted to the attacker based on how the application flow logic is designed and implemented. Threat modeling could be used as one way of identifying rules for these flaws.

3. Data leakage flaws

An application data leakage occurs when a developer inadvertently places sensitive information or data in a location that is easily accessible by other users or services without authentication or authorization.
Ensure data is sufficiently protected when stored or transmitted between systems by treating all data input and output as suspect. Define an approach that ensures all data are explicitly validated Ensure cryptography is used correctly – It is no longer about whether you encrypt the data or not, it is about how you do it! Identify sensitive data and how they should be handled Always consider the users Data leakage prevention rules will ensure that all access to data is authenticated, authorized, and verified before access is allowed and the access must be tracked per user, service, and application profile.

4. Insider threats (Malicious actors)

This involves the abuse of privileges by the developers to create backdoors or logic bombs that allows them to bypass authentication, authorization and any business logic flows and execute sensitive transactions without being traced.

Threat modeling should drive the identification of insider threat detection rules and create a framework separation of duties at an application call level – enforce that even processes should not violate these rules!

5. Insecure coding practices

The focus of this area is to enforce rules that prevent disclosed vulnerabilities (CVEs) and avoid known and well-researched insecure coding practices leveraging OWASP, PCI DSS, and SANS Top 25 Programming errors.

The MITRE Common Vulnerability Enumeration (CVE) standardized will be used to enumerate and discriminates between all known vulnerabilities and all critical vulnerabilities should be solved before accepting the code into the main Github branches. Most static application security testing standard policies could be leveraged for the rules in this area.

[godfreykutumela]

Updated Code Security Standard - https://docs.google.com/document/d/1oluhsqzXj5epCripU7xFhhvVUvwMWghq/edit?usp=sharing&ouid=111271012303486374335&rtpof=true&sd=true