We live in a data-driven world filled with multiple software and products that demand confidentiality, integrity, and availability at every cost. Those products also encompass critical functionalities and require a high degree of protection so no threat actor can tamper with the features or exploit them for their desired purpose. Most of the security flaws in the application (software interchangeably) and systems often occur due to software development methodology gaps.
Businesses can easily remove the gap in software development through the secure software development lifecycle (SSDLC) when they plan to develop their desired product. Secure SDLC is essential because if security is addressed at the initial development stage and followed by the best practices for the protection, it automatically reduces the chances of a breach or security implication to a greater extent.
Previously we had talked about application security and how SSDLC helps achieve it. This blog post elaborates on the SSDLC’s first phase, i.e., the security requirement that provides a foundation for a Secure Software Development Lifecycle.
In the traditional SDLC requirement phase, the focus is to develop feature-rich software with great user experiences to meet the customers’ needs, grab market attention, bring a Return on Investment (RoI), and increase revenue. In the simple SDLC, this phase includes deciding the application architecture blueprints, appearance, front-end, interfaces within the system for user and application communication, data storage and transmission methodologies, software development goal, financial budget, the timeframe to develop, and market product, its features, etc.
The secure SDLC security requirement gathering phase is not very much different from the traditional SDLC phase. Additionally, mandates include security considerations with other planning. However, it is the most crucial activity and must be performed to minimize the possible errors that could be fed forward and impact the subsequent development phases.
During this phase of SSDLC, security professionals evaluate the product/software requirements to protect it from potential threats and determine the probability of attack surface. Furthermore, they assist the development team by presenting product evaluation risk profiles, which is basically understanding the cost of the breach in case the product gets compromised.
Moreover, they focus on determining the regulatory obligation according to the data type that the product would use or the regional law needed to comply with. This activity brings development, security, privacy, and business teams together in the same environment and helps map the details to develop software according to users’ needs and stakeholders’ requirements.
The most common mistake that businesses make while developing any software or product is that they treat security requirements as non-functional, which often leads them to build software that is neither secure nor tested appropriately. Therefore, to cover the security aspects, it is crucial to bring the development, business, and security team on the front line to discuss the business risk associated with the security risk.
The security requirement is primarily about understanding the resources, tools, components, frameworks, languages, etc., that are used to develop the software and its security implications. Furthermore, it expands toward data classification, compliance essentials, and access control requirements, such as data types and processing and storage? For example, is it PII (Personal Identifiable Information) or PHI (Personal Health Information)? If the organization has never stored or processed that type of data before, the requirement stage would also consider drafting or updating the organization’s data handling standards.
Similarly, at the same stage, it is equally vital to analyze what sort of compliances and security controls would be required for application security, e.g., AuthN, AuthZ, MFA, data at rest and in transit encryption, key management, SSL/TLS handshake at the load balancer. For instance, whether the SSL/TLS should be terminated at the load balancer or do mutual TLS from the load balancer to AppServer, or is it necessary to terminate TLS at the AppServer, etc. other similar aspects of basic security controls.
Documenting and establishing the risk profile is also critical in the security requirement phase as it helps to make essential security considerations, methodologies, and protocols transparent to stakeholders, business, and development teams. In addition, by interpreting all the prerequisites mentioned earlier, businesses can quickly classify the security components needed later on to develop the software.
Requirement gathering includes the risk profiling of software or product-sensitive areas that present attack surfaces and could be susceptible to specific attacks. However, all these requirements collection are needed to be done under the following consideration, which includes,
- The mandatory regulation and compliance are required to prove due diligence to ensure security.
- Security gaps that might impact other development stages if neglected or not considered while gathering software requirements
- Analysis of security impact on each component, such as third-party libraries, SDKs, etc., that might influence under different conditions or could be exploited by threat actors.
Most of the time, third-party components contain various vulnerabilities and often are already end-of-life and thus have no product support from the vendor if any vulnerability emerges. Therefore, if such things are documented at the security requirement stage and taught to the development team to have certain criteria for choosing the third-party software or libraries, it enhances the SDLC security and reduces the risks and threats that are frequently transferred to later stages through such negligence.
The requirements can be comprehensively classified according to their functionalities, such as:
Functional Security Requirement
Functional security requirements (FSR) describe functionaries that the application/software should have and must be able to fulfill the Confidentiality, Integrity, and Availability (CIA) triad. It can be collected by driving security needs from the overall business requirements. Generally, FSRs include access control, authentication, authorization, data security and integrity via encryption, backup, data recovery, log management, etc.
For example, how the user would be verified and granted access to the relevant information, how the logs would be anonymized if stored, how would logs be shared with any third-party with crash dump services, and other similar considerations.
All the FSRs can be collected by interviewing stakeholders and managers and taking input from customers.
Non-Functional Security Requirements
Non-functional security requirements describe the quality of the product, i.e., the software to be built. These requirements do not directly involve security considerations but are equally crucial for software and provide a good user experience, improve performance, error-handling, reliability, maintenance, auditing, usability, scalability, and capacity. It also involves determining the product’s resiliency and immunity against incidents (both security and non-security) and is essentially all about how efficiently the software would perform and construct.
For example, how the application would be able to handle the traffic in case the primary server gets down or crash, how should the application be designed to have minimum downtime, how would the real-time application stack will be monitored, including bandwidth, performance, etc. where will the application logs be stored, how would the application stack be integrated with SIEM solution, what will be the criteria of event alerts, how the backup should be kept to foster the recovery process in case the data gets corrupted, etc.
Secure Development Requirements
Secure development requirements are the needed activities for the rest of the development processes to ensure that any stage’s output, which eventually will be the input of the subsequent stage, does not contain any vulnerabilities. Because to develop and deploy the software, specific prerequisites must be considered to ensure the software is securely built and bug-free. Therefore, secure coding guidelines, secure frameworks, trained developers, product testing methodologies, abuse cases identification, etc., are some of the most crucial things to decide during the security requirement phase of SDLC.
Correspondingly, to identify the risk, businesses must know their requirements to build the product, i.e.,
Product Details
What does the product/software or system do, and what is its scope?
Regulatory Requirements
What geographic and industrial regulations apply to the product, e.g., GDPR, CCPA, HIPAA, ISO 27001, PCI DSS, etc.
Operating Environment
It includes the following considerations.
- APIs communicate with each other, whether it is a monolith application or microservices architecture.
- Data encryption mechanism, data flow, the pattern of data encryption at rest and in transit
- Authentication and authorization mechanism, the necessity of enforced MFA or 2-FA, application design to prevent unauthorized access or attack, e.g., brute-forcing, credential stuffing, account lockout policy, etc.?
- Client or server-side encryption, access of the data, third-party access management, amount of stored data, data classification
- Client and server-side validation
Basic Security Function
This includes having an appropriate security control to justify the secure operating environment, e.g., strong password, user lockout policy, strong cryptograms, firewalls, IDS/IPS, etc. After analyzing the areas mentioned above, the security professional categorizes the risks according to their impact. As a result, the risk can be classified into the following:
Data or Privacy Breach
It includes disclosing customers’ sensitive information by any cyber-attack or incident that eventually leads to regulatory penalty, affecting revenues or brand reputation.
Denial of service
This includes identifying key areas that might disrupt the service in case of breach, attack, or software compromise.
Data Theft
It involves any incident of attack vector that could leverage sensitive data-stealing theft and impact revenues, legal penalty, or brand reputation.
Fraud
Any activity that could lead to defrauding business, customers, or legal authorities and impact brand reputation, regulatory penalty, or revenues. Apart from identifying and categorizing the risk and requirements, it is essential to review the gathered documented conditions and further examine whether any of the listed conditions conflict with others or not. Similarly, it is vital to determine the risk acceptance criteria (if any requirements are considered despite the risk).
Once all security requirements are clearly understood by the entire business, development, and security teams, it is appropriate to move to the next phase, i.e., architecture design review. In the second phase of secure SDLC, a secure architecture is built and reviewed for the software to get more transparency of threats and risks that could have been overlooked or deemed before as not so secure.
ioSENTRIX offers a full suite of application security that includes but is not limited to security requirements review, design review, threat modeling, code review, and penetration testing. Call us today for security consultation or assessments.
Never miss a story from us, subscribe to our newsletter