Comprehensive logging is a cornerstone of application security, capturing user actions, system events, and critical security data. Log analysis tools and intrusion detection systems are essential for identifying and responding to security incidents. Log format examples and recommendations for logged information assist in maintaining robust security practices.
Logs should be able to be combined, sourced from separate entities that interact. This requires standardization of a minimum data set in the logs.
Committed changes must be logged with details such as date/time, operator identity, and other relevant information. The audit log should be append-only, read-only, and accessible only by the Security Officer. To ensure integrity, consider logging to a separate component or isolated system. must also be tracked in an append-only log.
Input data must not be logged “as is” without either validation or encoding; logs should have a reliable format.
When the system is operational in production, system status, load, request rates, errors etc must be logged and monitored. Alerts and notifications will be configured so that problems are detected quickly and can be resolved as soon as possible.
Logging and monitoring may be partially implemented in an additional gateway/proxy services and must be in place in production.
Logs should be exportable in a portable format (to be determined) for investigations of suspicious events, when sharing of logs between parties is necessary.
Escaping (or encoding) is not just relevant when logging data. In general any ‘sink’ could be, for example an SQL-context, an HTML-context or an URL-context.
The principle of escaping at the leaves means that escaping is applied at the last moment, when the context in which data is being used is known. Logging data is an example of such a ‘leave’.
Access to logs must be restricted to authorized roles (CISO).
Incident Response
Incident response involves a structured approach to handling security incidents, encompassing detection, containment, eradication, recovery, and post-incident analysis. A well-prepared incident response team and communication plan are paramount to address and mitigate security events effectively.
The security of a BDI implementation builds upon common security practices that every entity should put in place. Specific attention must be given to:
Software design of components
Emergent security (the security of the interacting components as an ensemble)
Provisions to detect anomalies and perform autopsies after incidents
Operational security
The system should mitigate denial of service scenarios:
Rate limiting to prevent overloading the service
Request/response buffering to ease handling of slow clients
Header size limits.
Prevent caching for endpoints (Cache-Control: no-store unless explicitly allowed for an endpoint)
Set charset on endpoints (including application/json endpoints)
Some of these mitigations may be implemented in an additional gateway/proxy service and should be in place in production.
Endpoints that are exposed to the Internet are a prime attack surface. One of the options to reduce the attack surface is to limit access to a specific port in the firewall only to authenticated systems, for a limited period of time (“port-knock” service). This has been investigated by the BDI https://bdinetwork.org/wp-content/uploads/2024/07/20240716-BDI-Port-Knocking-Security.pdf
Operational security is critical to ongoing protection. Access controls and permissions are vital for restricting employee access to sensitive resources. Regular access reviews and audit trails ensure accountability and security maintenance.
An Association Register is a core part of automated trust assessment. This requires both:
Rigorous design and testing for IT-security weaknesses (cryptographic libraries, protocols, pentesting, supply chain attacks etc.)
An operational security process that minimizes the risk of humans as attack vector (social engineering, pressure) to compromise the integrity of the register
The human attack vector is considered to be the most risky: onboarding should therefore be a one-way automated process in three separate steps (see also onboarding T&Cs Association articles):
Collecting information (automated and/or manual)
Verifying information and test trust chain (automated)
Committing to the register (manual action by functionary)
Modification of information should only be possible by deleting or deprecating information, followed by a new onboarding process.
Define roles for actors and restrict access to relevant actions or endpoints based on these roles. This ensures that users only have access to the functionalities necessary for their roles, reducing the risk of unauthorized access.
Security testing involves systematic (and automatic) assessments to uncover vulnerabilities. This includes penetration testing, vulnerability scanning, and code reviews. Integrating security testing into the development lifecycle is critical for identifying and rectifying security weaknesses.
For this process it is helpful to have an inventory of all software (and software dependencies), sometimes referred to as a software Bill of Materials. This could be integrated in the CI/CD pipeline.
During development and operations should have processes in place to keep the system’s dependencies up to date and to make sure dependencies are still supported by the vendor. CVEs should be monitored for issues and workarounds.
The development cycle should make it possible to release bugfixes and security-fixes on a fast schedule.
Backups to recover from crashes and/or data loss must be in place. Access to backups must be restricted to the CISO.
This page contains references to demo projects and their lessons learned where the Security has been used.
Selecting a secure development stack involves careful consideration of programming languages, frameworks, and tools with a strong track record in security. It's essential to keep libraries and dependencies up to date to address potential security vulnerabilities.
Especially when the functionality is needed for secure operation the implementation should use well-tested and maintained components and libraries in favor of implementing functionalities from scratch. This applies specifically to:
· JWT parsing & handling
· Certificate parsing & handling
· Input validation
· Authentication
· Authorization
· Database interactions (e.g. an ORM framework)
· Output escaping in user interfaces (e.g. templating frameworks)
· Cryptography, including password storage
The development stack should be chosen accordingly.
Secure Code Design
Secure code design encompasses foundational principles, including rigorous input validation, output encoding, and error handling. Implementing security design patterns, such as the Principle of Least Privilege or Fail-Safe Defaults, is crucial for minimizing potential vulnerabilities. Practical code examples demonstrate how to apply these principles effectively.
· Version Control: Use version control to manage code changes.
· Validate Inputs: Always validate API inputs, operator inputs, and data from peer services. Use standardized mechanisms like OpenAPI specifications for validation.
· Certificate and JWT Validation: Validate certificates and JWTs for format, validity period, and other parameters using standard components.
· Secret Management: Keep operational secrets secure and separate from source code repositories.
· Access Restrictions: Limit access to production machines, automate software deployment, and log all access and deployments. Restrict the number of users with production access.
· Code Review: Ensure all code changes are reviewed by a second developer before merging.
· Enforce access control service-wide: API and operator endpoints must have access control applied. This should be designed into the service architecture and “fail closed” so that endpoints must have explicit access restrictions – access control must not rely on ad-hoc checks per action/endpoint that may be omitted or have logic errors.
Strict checks that “fail closed”
When validating requests and comparing registrations, the implementation should be strict; incomplete data (including failure to request required information from third parties) is not acceptable and should prevent requests from completing.
The goal is to prevent leaking sensitive information and erroneous positive statements about parties (I.e., “Party X is an active member of an association”) due to misconfiguration, bugs, and deliberate attacks.
The core principle is that access is denied except for complete and valid requests.
The above principle must also be applied to the service’s implementation; any path + request method combination not explicitly allowed with specified access controls must be denied.
In addition to the above section on strict checks that “fail closed”, centralize the access control mechanisms so no endpoints can be accidentally exposed without correct controls.
Centralize input validation
Input validation on endpoints must be centralized so no endpoints can be accidentally exposed without correct input validation. Apply the “fail closed” principle.
Automated tests & CI/CD
The development process must use automated tests to check regressions and validate new functionality. The automated deployment mechanism should ensure that new releases pass all automated tests before deployment. Releases must be tracked in the audit log.
Besides unit tests and regressions tests the CI/CD pipeline can also be employed to perform:
· Dependency scanning
· Static Application Security Testing (SAST)
· Dynamic Application Security Testing (DAST)