Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Security System Development Life Cycle
The Security System Development Life Cycle (SecSDLC) is a series of activities that are carried out in a certain order throughout the software development process (SDLC). It is created in such a manner that it can assist developers in creating software and apps in such a way that security risks are reduced greatly from the start.
The Security System Development Life Cycle (SecSDLC) is similar to the Software Development Life Cycle (SDLC), but the activities carried out in each step of the cycle are different. SecSDLC is a process that includes identifying specific threats and the risks that such threats pose to a system, as well as the necessary deployment of security controls to prevent, remove, and manage the risks involved. The SDLC process, on the other hand, is primarily concerned with the designs and implementations of an information system.
The system development life cycle (SDLC) is a method of ensuring that a new system or application has acceptable security controls and requirements. Integrating technologies and practices into the creation of the new system and application deployments allow security to be built into the solution from the start, rather than being retrofitted after the solution has been deployed.
To accomplish this, the SDLC process for system and application deployments should be clearly defined, with specified and enforced checkpoints that include security checks before going on to the next project phase. It is far more difficult to successfully oversee the development process and guarantee that securityrelated concerns are correctly handled without explicitly applying the SDLC and delivering the required deliverables.
The System Development Life Cycle and Its Phases
What is the difference between the system development and software development life cycles? End-to-end people, processes, and technology deployments, including software, infrastructure, and change management, are all part of the system development life cycle. The software development life cycle is only concerned with software components such as development planning, technical architecture, software quality testing, and software deployment. Simply said, the life cycle of system development is more holistic and thorough.
The phased actions outlined below are often reflected in the SDLC.
Start-up of the project
To begin all system development and integration tasks, create a formal project request. The project goals, users of the system or application, criticality in terms of confidentiality, integrity, and availability, and important completion time periods should all be included in the request.
Analysis
Determine if the project proposal should be allowed for development by conducting a feasibility assessment. The feasibility study should include the following −
Evaluation of the influence on the current environment;
Requirements for staff development and resources;
Cost analysis for project development;
Costs of program upkeep;
Alternative project implementation methodologies, such as build vs. purchase and outsourcing, are assessed.
Describe the recommended solution strategy;
the dangers of the suggested remedy; and
Cost savings, mistake reduction, additional customers, and enhanced customer service are all part of the benefit analysis.
During this phase, information security teams should begin their engagement with the project to verify that suitable security issues have been addressed in the feasibility study.
Specifications for Business and Operational Requirements
Develop business and operational needs specifications to guarantee that the project requirements required to achieve business goals are understood. This approach is usually led by users and development teams. The following issues should be addressed by business requirements
Data needed to support the system or application, as well as how it ties to other data
The frequency with which the system or application is used;
For online processing, a response time is required.
Relationships between functions and their reliance on other components;
Identifying any legal or regulatory requirements or limits that apply; and
The system's or application's expected lifespan.
The following items should be addressed in operational requirements
Requirements for security;
Provisions for contingencies;
Processing needs that are both distributed and centralized;
Assumed responsibility and data entry approach
Retention requirements for data
Demands for output distribution;
Transaction volumes to be expected, including project transaction increases; and
System performance criteria are critical.
The sort of development activity that the project represents should also be described in this document. Maintenance, enhancement, new system, and emergency change are all common project kinds. When a development activity is allocated to one of these categories, criteria should be established.
To ensure that security issues are adequately addressed and represented in the requirements document, information security teams should be included throughout the business and operational needs phase. During this phase, the risk assessment approach is mainly implemented, giving the project team early security insights.
Functional Requirements
Transform the business and operational requirements into functional requirements to represent the system or application's expected user experience. The user's viewpoint has been transferred into the early design via functional requirements. The goal of maintenance and improvement efforts is to use a before/after description to record what is changing.
The following should be included in the functional specifications −
Data flow diagrams show how data flows across all of its processing stages.
Data definitions include data definitions, linkages, and naming standards.
Screen definitions – Input field definitions, range checks, and so on;
Source of data, kind of data, and description of data are all inputs.
Report definitions - a description of each report, the data it contains, how data values are calculated, and the people who use it;
Control and security requirements include input edit requirements, audit log trails for critical data from point of origin to point of disposal, audit log trails for privilege usage, and identification of important processing areas.
Interaction points between this system and other systems, expected inputs and outputs, reaction time expectations, and other intersystem dependencies are all part of the system interface requirements.
Restart, backup, and recovery — backup frequency, backup reasoning, backup retention requirements, restart requirements that indicate how the program should be restarted, and recovery requirements;
Analysis of how long the application may be down before it affects the company, as well as identification of data sets, software, and other elements that must be restored at an off-site processing center;
Communication needs, storage space, processing equipment, and other hardware requirements;
Uptime requirements, needed response times, crucial periods, input deadlines, report dissemination deadlines, and other service-level requirements;
Transaction volumes, projected growth, and other capacity needs; and
Technique for producing data on the new system, method for reconciling data during conversion, cut-over requirements, and procedure for checking converted data is all conversion needs.
Information security teams should normally play a supportive role throughout the functional specifications phase, assisting the project team in capturing the early design and functional description of the system or application. Security-related information, such as technical features (e.g., access restrictions) and operational standards, should be included in functional specifications (e.g., awareness and training). Prior to the detailed design phase, information security teams should examine and give input on this document.
Design Specifications in Depth
Create thorough design specifications that convert functional requirements into a logical and physical layout. Detailed design specifications are created during the SDLC's design phase and detail how the system or application is built to meet the functional specifications' needs.
The following should be included in detailed design specifications −
Relationships between data elements; database requirements
Description of each file, file access methods, list of fields inside a record, data properties, and expected number of records are all required.
System flow diagram - shows the order in which programs are performed, as well as their links to inputs and outputs and security measures.
Program requirements - programs employed and their purposes, formulae and computations descriptions, and program interrelationships;
Job streams, comprising the purpose of processing, job names utilized, and restart/recovery methods; System operations needs
Requirements for managing errors;
Procedures for backup and recovery;
Procedures for starting and shutting down the system;
logical flow of screens specifying screens that pull other screens, input checks performed, and description of error messages; screen designs - fields in each screen, the purpose of each field, description of how each screen is triggered, description of how each screen is triggered, logical flow of screens specifying screens that pull other screens, input checks performed, and description of error messages;
data contained in each field of each report, as well as an explanation of how each data result is obtained; and report designs
Access control techniques, audit log provisions, user authentication, and encryption requirements are all described in the security design.
Information security teams should once again assist the project team's efforts to build the system to reach the desired solution during the detailed design phase. At the request of the project team, security specialists should attend project meetings for significant design reviews, including a security design review. Information security teams should review if security needs have been appropriately handled and whether suitable testing procedures are in place as part of the detailed design phase. Prior to moving on to the next step, they should evaluate the comprehensive design requirements.
Development
The security aspects of the system or application are designed, configured, and activated throughout the development process. To specify the program logic and processing needs, use the program specifications. Prior to the start of programming, program requirements are created as part of the development process. These requirements outline the mental process that must be followed in order to establish the procedures that must be taken in order to code the programs.
Source code evaluations for essential components of the system or application, such as user authentication, authorization, and financial transactions, should be retained by information security teams. Third-party code, such as that supplied by offshore development businesses, should be given more attention during source code reviews.
Phases of the SecSDLC
Investigation of the System − The officials/directives working at the highest level of management in the organization initiate this procedure. In order to carry out this procedure, the project's objectives and aims must be determined first. An Information Security Policy is created, which includes descriptions of security apps and programs deployed, as well as their implementations in the system of the organization.
Analysis of the System − This phase does a comprehensive document analysis of the documents obtained during the System Investigation phase. Existing security policies, programs, and software are examined to see whether there are any weaknesses or vulnerabilities in the system. Threats that may arise in the future are also considered. This method is solely responsible for risk management.
Logical Planning − The Logical Design phase is concerned with the creation of tools and blueprints that are used in the implementation of different information security rules, as well as their applications and software. In order to avoid future losses, backup and recovery plans are also created. The procedures to take in the event of a calamity are also prepared. During this phase, the choice to outsource the firm project is made. It is determined if the project can be finished inside the organization or whether it must be outsourced to another company for completion.
Physical Layout − The technical teams get the tools and blueprints required for the software implementation and system security application. Various solutions are researched during this step for any unanticipated concerns that may arise in the future, and they are analyzed and written down to address the majority of the vulnerabilities that were overlooked during the analysis phase.
Implementation − Whether the project is in-house or outsourced, sufficient documentation of the product is produced in order to fulfill the standards established for the project to be met. The project's implementation and integration are carried out with the assistance of numerous teams that rigorously verify whether the product fits the system requirements given in the system documentation.
Maintenance − After the security program has been implemented, it must be ensured that it is working effectively and that it is being monitored appropriately. In order to fight emerging risks that may go unnoticed at the time of creation, the security software must be maintained up to date.
5K+ Views
