Introduction:
SDLC stands for Software Development LifeCycle.
WHY do we need to Secure it when it is already a global standard across any development cycle ? ? ?
Remember the quote?
A stitch in time, saves nine ! ! !
S-SDLC is a preventive process to avoid any security mishaps once a product is out there in the wild. The GOAL is to keep the application SAFE from breaches/attacks/hacks. Fixing a security vulnerability in a product which is already released is always a costly affair in terms of Brand, Revenue & Time!
Phase#1: SCOPING:
Gather as much information as possible in this phase regarding the feature in question. This helps us understand the business functionality much better so that no security measure in place shall affect the Business Requirements. Ultimately its our responsibility to deliver what Business wants. Do involve the key people in this phase like the Product Manager, Senior Management or even Application Developers
Phase#2: DESIGN:
In the Design phase, it is our responsibility to provide a flow which is secure by design. Think of the logical flow based attacks which purely attack the core logic of the feature. Ensure that sufficient checks can be placed at multiple places and the source of truth in core logics should not completely rely on the client side logic instead has some validation in place. For example, in a checkout flow for an e-commerce application, ensure that the client side cart value is not taken as the source of truth instead always keep that as a validation step but the source of truth should be from the merchant’s server for a payment gateway!
Phase#3: CODING:
Ensure that the best coding standards and practices are followed. As well perform static analysis of the code should be done at this phase and not at the next one so that the developers are not going through multiple cycles. For example, ensure that no passwords are being hardcoded in the code, instead define a strategy to pickup sensitive keys in runtime while building your application at the time of deployment and is always a part of the runtime memory. So even if a breach happens on the application server, the credentials/ keys are safe. Ensure that proper sanitizing wrappers are in place and there is always a service layer between your frontend application and critical infrastructure like Database which sanitizes/parametrizes the query inputs before executing them on the database server.
Please note that developer’s time is precious and this phase shall ensure that their time is not getting wasted in multiple redundant cycles!
Phase#4: TESTING:
The test cases for Security Testing should be pre-determined so that the RED Team once receives the build after QA Sanity, should start off with manual testing against the OWASP Top 10 vulnerabilities which ever relates to the feature. Ensure that there are proper regression tests also in place if it is an enhancement to an existing feature. Logical Flow testing is one of the most important tests in this phase and ensure that the flow developed is 100% complying to the flow proposed in Phase#2: Design. A proper VAPT should be done end-to-end and the results should be recorded in your bug/task tracking tools like JIRA for future regression testing references.
Always prioritize the Security Bugs w.r.t. the impact expected out of the issue identified the right way and ensure that the impact description is well understood by the stakeholders! Of course the bug bounty platforms have helped the bounty hunters and security researchers practice this step by providing a proper flow on their platforms. Try raising a Security Bug in BugCrowd!
If bugs are found, then get them fixed in a timely manner and DO ENSURE THAT YOU HAVE A SOLUTION for the bug raised beforehand because ultimately you are the who found the security bug and hence propose a secure solution regarding the same. For best practices and evasion techniques, please refer to the OWASP Top 10 Cheat Sheet and refer the same as a good standard while addressing vulnerabilities and requesting a fix.
Phase#5: DEPLOY:
This is the last phase in which we need to ensure that the environment in which the feature is getting deployed is secured. Ensure that the server has been hardened and the version being used is vulnerability free! As well do perform network assessment where and when required and try to avoid non-standard ports. Ensure that proper TLS Implementation is in place. A Security Architect with the right DevOps skills can help you in achieving the best results.
Once we are able to implement the above process, we can ensure that our applications that are getting deployed are well protected right from design itself. But remember:
Security is a Process, not a Product!
Ensure that you have sufficient monitoring and alerts in place. A proper Incident Response Team is well trained on the new feature and how to identify security incidents and attack attempts and how to identify them. Design a process on how to handle live attacks and ensure that there are sufficient tools and visibility provided to the monitoring teams like SOC
Keep Defending !
Hits: 120
