The application security life cycle or "application development life cycle" (AEL)
After providing an overview of application security in the first part of the blog, in the second part we will look at the special features of an application's life cycle. The advantage of this approach is that it is generic and independent of the development method. In this case, generic means a closed cycle of procedures and processes as opposed to the classic input/output process model. The holistic approach means that modern development methods such as agile project management or Kanban can also be supported.
This means that modern methods such as agile development or hybrid technologies can also be taken into account. What is the content of the individual phases in an "Application Security LifeCycle"?
What is the "Application Security Lifecycle"?
The "Application Security Lifecycle" consists of five phases, with individual processes (activities) and ten milestones. The milestones represent the WBS "Work Breakdown Structure" of the project process in application development. The benefits of proper planning and architecture can be seen right from the start, as errors in the initial phases will mean many times more work in later quality assurance.
- Design & Concept
- Software Development
- Quality Assurance
- Operation and Maintenance
- End of Life
ISO/IEC 27034 applies a risk-based approach here.
The guideline and the optional supporting tools supplement the determination of risk levels and the determination of suitable controls (audit-based) during the life cycle.
The aim here is to ensure application safety.
The individual tools for the phases are as follows:
| Phase | Designation of the tools |
| Design and concept | Application Risk Assessment (semi-auto) Application Security Controls (semi-auto) |
| Software development | Application Security Architecture (semi-auto) Source code analysis (automated) |
| Quality assurance | Application Security Controls (semi-auto) |
| Operation and maintenance | Application Security Controls (semi-auto) |
| Dismantling | Application Security Controls (semi-auto) |
A total of around 140 controls are available throughout the entire life cycle. The controls are equally applicable for project management, architects, developers, testers and auditors. The individual processes and activities are as follows:
It should be noted that some information security activities should be carried out on a regular basis or again in the event of significant changes to the application.
These include:
- Carrying out the risk assessment;
- Guidelines for the secure creation of source code
- Carrying out the vulnerability assessment
Which tools are usually used?
The "Application Risk Assessment" is used to determine the risk level for the application in order to determine the relevant safety controls.
The "Application Architecture Security Controls", i.e. the security controls of the application architecture. This defines the minimum number of security controls that must be fulfilled during the design and development of the application.
The ASL security controls are given as a summary of the defined minimum number of security controls depending on the risk level of the application.
Source code analysis, also knownas an external service in the form of penetration tests or vulnerability analysis. This "tool" evaluates the source code provided with regard to general security vulnerabilities and the associated vulnerability of the application.
The guidelines "Application Security Lifecycle" and "Secure Coding Requirements" contain information on the use, requirements and avoidance of general security problems in the development of applications.
What predefined principles of secure software development exist?
- Minimize the attack surfaces
- Set secure default values or settings
- Principle of least user rights or privileges
- Principle of defense in depth (several controls on top of each other)
- Safe failure of the application (safe failure)
- No blind trust in IT components
- Separating tasks and authorizations
- Avoiding ambiguity or confusion
- Application security should be kept simple
- Correctly resolve security problems
The list does not claim to be exhaustive and only serves as an initial guide to understanding the principles.
As referenced in Part 1, these should be coordinated between those responsible from the various units (project, application, developer, business unit) in the "Design & Concept " phase.
What is the purpose of the risk assessment of the application?
Determining the application risk level (e.g. low - medium - high) is mandatory for all applications. The determined risk level defines the required minimum number of security controls for the application. The application development project manager is responsible for carrying out the risk assessment. The person responsible for the application (or the person later responsible for operations) should carry out the risk assessment again during the operational phase if significant changes have occurred.
The risk assessment must take into account at least the following safety aspects:
- Accessibility of the application at network level;
- Intended user group;
- Procedure for user authentication;
- Critical information;
- Complexity of the application;
- Business criticality;
The supporting tool "Application Risk Assessment" should be used to determine the risk level. The risk assessment should be signed off by the client.
In the event of a "high" or "very high" risk level, the relevant officers (data protection, information security, compliance) should review and sign off the risk assessment.
What other safety requirements exist?
For all risk levels, the project manager should ensure that the security requirements are appropriate to the complexity of the application and the identified risk level. To this end, he should work together with the "security architects" to define and document the requirements.
The security requirements must cover at least the following security areas in order to avoid the main risks ofapplication security:
- Security architecture;
- Authentication;
- Session management;
- Access control;
- Input validation;
- Output coding;
- Cryptography;
- Error handling and logging;
- Data security;
- Communication security;
- HTTP security;
- Security configuration;
- Avoid malicious code;
- Internal security.
The project manager should use the specifications of the "Application Architecture Security" tool to derive the security controls of the application architecture according to the risk level. Further security requirements can be defined by the stakeholder groups (business/specialist area, customer, client, legislator). The derived security requirements should be approved by those responsible.
What happens next?
In the next blog, we will focus on phase 2 software development. The analysis of the source code, the guidelines for secure application development and outsourced development will play a role here.
Dr. Gerd Grimberger, 15 March 2023
Legal IT specialist
