Skip to content

Latest commit

 

History

History
50 lines (35 loc) · 3.05 KB

introduction-to-holistic-audits.md

File metadata and controls

50 lines (35 loc) · 3.05 KB
description
A reference for performing a wide-ranging, interconnecting technical, security, and privacy quality assessments for Information and Communications Technology for Development

Introduction to Holistic Audits

Throughout our work, we will be utilizing different strategies, techniques, and methodologies, and reflect upon how the CRVS Providers themselves used this methodologies. Here are four examples, specifically for the Stream 1 Technical Assessment:

  • Needs Assessment is a process of identifying and analyzing the needs of a specific group of users or stakeholders in order to determine the best course of action to meet those needs. In the context of software development, a needs assessment is an important part of the planning phase of the project. It involves gathering and analyzing data about the users or stakeholders who will be using the software, as well as their needs and requirements.
  • Threat modeling is a process of identifying, analyzing, and prioritizing the potential security threats and vulnerabilities in a software system. It is an important part of the software development process because it helps to ensure that the software is designed and implemented in a way that is secure and resistant to attacks.
  • Risk mitigation is the process of identifying, analyzing, and taking steps to reduce or eliminate risks in a software development project. It is an important part of the software development process because it helps to ensure that the project is delivered on time, within budget, and with a high level of quality.
  • Harm reduction is a public health approach that focuses on reducing the negative consequences associated with risky behaviors, rather than attempting to eliminate the behaviors themselves. In the context of software development, harm reduction may refer to the process of designing and implementing software in a way that minimizes the potential for harm to users or stakeholders.

Security Considerations

  • Audits: How, What, and When?
  • Penetration Testing vs Code Audits
  • Data Retention, Logging, and Deletion

The Role of Application Architecture

  • Planning for Authentication, Authorization, and Controls

DevSecOps: Three Magic Words

  • Utilizing CI/CD in your deployment of packaged solutions
  • Implementing Effective Attack and Intrusion Monitoring

Introduction/Executive Summary

  • Initial Takeaways
  • Threat Analysis
  • Information on the Solution/Product

Source Code Security Audit

  • Software Bill of Materials
  • Test Environment
  • Dug into known issues
  • read application source code,
  • deployed a development instance as described in the project’s documentation,
  • deeply probed known problem areas in web applications.
  • Our testing and audit methodology was guided by the OWASP Web Security Testing Guidelines. https://owasp.org/www-project-web-security-testing-guide/stable/
  • We also produced a Software Bill of Materials (SBOM)
  • performed a manual review of third-party dependencies.