Overview
At Kongo Group Pty Ltd, engineering documentation and technical references serve as the foundation for designing, developing, and maintaining secure and privacy-respecting information systems. This article provides a centralised resource for software developers, detailing the principles, processes, and standards that must be adhered to throughout the development lifecycle. These guidelines ensure that all system implementation efforts align with the company’s commitment to security, privacy, and quality.
Secure-by-Design and Privacy-by-Design Principles
Kongo Group mandates that all engineering efforts incorporate secure-by-design and privacy-by-design principles. These principles are non-negotiable and must be documented, maintained, and applied consistently across all projects. Below is an explanation of each principle, along with practical guidance for implementation.
Secure-by-Design Principles
-
Minimise Attack Surface Area
-
Reduce the opportunities for malicious exploitation by limiting exposed code, endpoints, and dependencies.
-
Implementation: Use only necessary libraries, disable unused features (e.g., default server ports), and restrict API access to required endpoints.
-
Documentation: Record all exposed interfaces and justify their necessity in the system design specification.
-
-
Establish Secure Defaults
-
Systems must ship with secure configurations out of the box, requiring deliberate action to reduce security.
-
Implementation: Enable encryption by default, enforce strong password policies, and disable debug modes in production.
-
Documentation: Include a checklist of default settings in deployment guides.
-
-
Principle of Least Privilege
-
Grant only the minimum permissions necessary for a user, process, or service to function.
-
Implementation: Use role-based access control (RBAC) in Bitbucket and application logic, restricting write access to production branches (e.g., main) to release managers.
-
Documentation: Map permissions to roles in the system architecture overview.
-
-
Principle of Defence in Depth
-
Layer multiple security controls to mitigate risks if one layer fails.
-
Implementation: Combine input validation, firewalls, and runtime monitoring to protect systems.
-
Documentation: Detail layered controls in the security architecture document.
-
-
Fail Securely
-
Ensure that failures do not compromise security or expose sensitive data.
-
Implementation: Design error handling to avoid stack traces in responses and revert to a safe state on failure.
-
Documentation: Specify failure modes and recovery steps in the technical design document.
-
-
Don’t Trust Services
-
Assume external services or dependencies may be compromised and validate their inputs/outputs.
-
Implementation: Sanitise data from third-party APIs and use secure communication protocols (e.g., TLS).
-
Documentation: List trusted services and validation methods in the dependency register.
-
-
Separation of Duties
-
Divide responsibilities to prevent any single individual from having unchecked control.
-
Implementation: Require multiple approvals for pull requests in Bitbucket and separate development from deployment roles.
-
Documentation: Define team roles and approval workflows in the change control process.
-
-
Avoid Security by Obscurity
-
Rely on strong, proven mechanisms rather than hiding vulnerabilities.
-
Implementation: Use industry-standard encryption (e.g., AES-256) instead of custom algorithms.
-
Documentation: Reference adopted standards in the security policy.
-
-
Keep Security Simple
-
Avoid overly complex solutions that increase the likelihood of errors.
-
Implementation: Favor straightforward authentication flows over intricate custom logic.
-
Documentation: Provide clear, concise explanations of security measures in the codebase comments.
-
-
Fix Security Issues Correctly
-
Address vulnerabilities thoroughly, avoiding temporary workarounds.
-
Implementation: Patch issues identified in code reviews or scans, then verify fixes via testing.
-
Documentation: Log resolved issues and verification steps in the issue tracker.
-
Privacy-by-Design Principles
-
Proactive not Reactive; Preventative not Remedial
-
Anticipate and prevent privacy risks before they occur.
-
Implementation: Conduct privacy impact assessments (PIAs) during design phases.
-
Documentation: Include PIA outcomes in the project initiation document.
-
-
Privacy as the Default Setting
-
Ensure privacy protections are enabled without user intervention.
-
Implementation: Disable data sharing by default and anonymize logs unless explicitly required.
-
Documentation: Specify default privacy settings in the configuration guide.
-
-
Privacy Embedded into Design
-
Integrate privacy into the system architecture, not as an afterthought.
-
Implementation: Use data minimisation techniques (e.g., collect only essential fields).
-
Documentation: Outline privacy features in the system design specification.
-
-
Full Functionality – Positive-Sum, not Zero-Sum
-
Balance privacy with functionality, avoiding trade-offs.
-
Implementation: Enable opt-in analytics that maintain utility without compromising user data.
-
Documentation: Describe privacy-preserving features in the user manual.
-
-
End-to-End Security – Full Lifecycle Protection
-
Protect data from creation to deletion across all stages.
-
Implementation: Encrypt data at rest and in transit, and securely delete it post-retention.
-
Documentation: Detail data lifecycle management in the security policy.
-
-
Visibility and Transparency – Keep it Open
-
Be clear about data practices with stakeholders.
-
Implementation: Publish a privacy notice detailing data usage.
-
Documentation: Link to the privacy notice in system documentation.
-
-
Respect for User Privacy – Keep it User-Centric
-
Prioritise user control and consent in design decisions.
-
Implementation: Provide granular privacy settings and consent prompts.
-
Documentation: Document user-facing privacy options in the requirements specification.
-
Development Process Integration
The above principles are enforced through Kongo’s Bitbucket-based change control process (see System Change Control Procedures). Key integration points include:
-
Pull Requests: Developers must document how changes align with these principles in PR descriptions.
-
Code Reviews: Reviewers verify adherence to security and privacy standards before approving merges.
-
Pipelines: Automated tests in Bitbucket Pipelines validate secure defaults, input sanitization, and least privilege configurations.
-
Production Merges: Release managers ensure documentation reflects compliance before merging into main.
Coding Standards
All software developers must follow Kongo Group Pty Ltd’s coding standards, which include:
-
Quality: Write maintainable, modular code with unit test coverage of at least 80%.
-
Commenting: Add inline comments for complex logic and maintain README files per repository.
-
Security: Avoid hard-coded secrets, use environment variables, and validate all inputs.
Standards are detailed in the company’s Coding Standards Guide [link to guide].
Technical References
-
Bitbucket Documentation: Guides on pull requests, pipelines, and branch permissions Bitbucket Docs.
-
Security Standards: OWASP Top Ten and NIST SP 800-53 for secure coding practices.
-
Privacy Frameworks: GDPR and ISO 27701 for privacy compliance.
Documentation Requirements
Engineers must maintain the following artefacts in Bitbucket repositories:
-
System Design Specification: Architecture, security, and privacy considerations.
-
Deployment Guide: Steps for staging and production deployment.
-
Changelog: Summary of changes per release.
-
Issue Tracker: Records of bugs, fixes, and verification.
Continuous Improvement
Feedback on this documentation and process is encouraged. Submit suggestions via Bitbucket issues or contact the engineering lead.