2.1 Product life cycle

As highlighted in the ENISA report Baseline security recommendations for IoT in the context of critical information infrastructures (9), security must be considered throughout the entire product life cycle. Regardless of the production model used (V-model or agile), the following life-cycle processes require explicit security consideration to support product security.

• Requirements. As part of this process, user, business, functional and security requirements are determined. These requirements reflect the intended use of the product and will be translated into specifications that will guide design, development and maintenance/deployment decisions at later stages.
• Design. As part of the design process, the architecture and the design of the product are created. This process involves the creation of a set of documents that describe how the product requirements, including security requirements, will be translated into system specifications and essentially how the product will work.
• Implementation. As part of the implementation process, specifications and software design artefacts are implemented in the product.
• Verification : This process involves all necessary steps to verify that the developed product actually meets the identified requirements and design principles of the previous processes.
• Deployment. This process follows the acceptance of the product subject to successful testing as part of the previous processes – that is, it takes place after it has been approved for release. It involves integrating all necessary elements of the solution into the production environment and its deployment.
• Maintenance and disposal. Solutions deployed in production need to be constantly maintained to ensure the availability and integrity of the functionality provided. When the solution becomes obsolete, it is important to provide data erasure mechanisms that ensure secure disposal and preserve privacy management.

These processes are presented as groupings, not a mandatory sequential model. They may overlap, occur iteratively and be revisited throughout a product’s life cycle. For example, in agile environments, security requirements may be captured and progressively refined through backlog items, user stories, acceptance criteria and the definition of done.

Figure 1: Secure by design and default across a product’s life cycle

Figure 1 shows the relationships between the product life cycle, secure by design and default principles and risk management activities.

Risk management activities establish the security context by clarifying important considerations, including what needs to be protected, the threats of concern and the acceptable level of residual risk given the product’s intended purpose and security impact. Secure by design and default principles translate this context into practical security decisions that are applied throughout the processes of the product life cycle, from requirements through to end of life.

Risk management activities should be revisited in response to changes or events arising during the product life cycle. Similarly, while the product life-cycle processes are presented sequentially, both the life cycle and the application of secure by design and default principles across the processes are inherently iterative. Events or findings in later processes, such as testing results, deployment in new environments, incidents, discovered vulnerabilities or the implementation of new features, often require re-entry into earlier life-cycle processes.

Frameworks such as the OWASP software assurance maturity model (SAMM) (10) may be used to organise and mature security activities across the software life cycle. Its threat assessment and security requirements practices provide one example of how identified threats can inform testable security requirements. For SMEs, especially those operating with rapid iterations, the key is to keep life-cycle processes lightweight, risk driven and automation first:

• use small, reusable artefacts (one-page context, simple diagrams, checklists);
• prefer automated controls in continuous integration and continuous delivery (CI/CD) over manual reviews, reserving deep reviews for high-risk changes;
• introduce fast security gates aligned with existing agile ceremonies (definition of ready/done, pull request (PR) checks, release checklist).

Table 1: Cybersecurity activities during the product life cycle for SMEs

process

context and

assumptions, short

security requirements

checklist (including

secure defaults)

secrets, logging).

dependency hygiene; protect secrets; require review

for security-sensitive changes; configure automated

static application security testing (SAST) /

dependency scanning as part of CI environments

(agile /DevOps/DevSecOps).

scanning, basic dynamic application security testing

(DAST) where relevant); ensure default configuration

is validated; run targeted penetration testing when

potential risk triggers are hit (e.g. in the case of a

substantial modification). Run automated tests with

high coverage that include security-relevant negative

tests (verifying that what shouldn’t happen doesn’t

happen). Note that security verification should be

integrated into developer workflows and CI pipelines

as early as possible (following the ‘shift left’ principle).

updates

( a ) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README .

1. Apžvalga

1.1 Nuorodos

1.2 Nustatyti reikalavimai

1.3 Susiję teisės aktai

2. Nustatyti reikalavimai

3. Susiję teisės aktai

• ENISA -