Infosys and Salesforce accelerate enterprises in their journey to be a cloud-based customer centric organization. We deliver engaging customer experiences, drive smarter business decisions and co-create new business opportunities.

« Field Service Management - Have you explored the ocean? | Main

Enhancing Application Security around Requirement Engineering in CRM Projects...

Inspite of several best practices and proven techniques advocated by Agile application delivery methodologies, data breach is still a common concern across the globe. Data breach cases in the year 2018-19 reached all time high with a greater number of well-reputed organizations coming under threat, with their customer information being compromised.

Large IT enterprises too are hit by security vulnerability time-to-time inspite of having best in class security policies and technology advancements in place. Several IT giants have embraced several security shields such as Deception, Threat Intelligence, Security by design, Security ratings, AI cyber security, BOTS, Threat hunting, including outsourcing to managed security companies inspite of all these countermeasures; data breach incidents are on constant rise year after year.

Official sources such as Common Vulnerabilities & Exposures (CVE) - https://cve.mitre.org/ (lists vulnerabilities grouped by year, per type and per product across the industries). National Vulnerability database (NVD) maintains common weakness enumeration (CWE) coded weakness in a hierarchical structure. CRM space alone amounts to huge data leakage from both on-premise as well as cloud infrastructures leading to reputation damages.

As part of COE engagements and in-dept study of how an vulnerability becomes a threat at later phases, we devised three milestone approach to tackle application security concerns:

Milestone 1 - 

To study evolution of vulnerabilities and determining injection point in the SDLC life cycle below techniques can be utilized:

1. Inverted Tree approach or the Attack tree

Attack trees helps in defining and analyzing possible threats expressed in a node hierarchy, allows the decomposition of a nonrepresentational attack into several concrete attack steps.

2. Affinity 

An Affinity Diagram gathers large amounts of attributes (ideas, opinions, issues) and organizes them into groupings or clustering based on their natural relationships.

Based on the prior known attack paths either through rule-based engine or via machine learning based training set a specific attack tree will be modeled for a given security incident.

A detailed investigation of data breach along with the path traversed by the intruder is highlighted through log forensics. 

Other possible attack paths or vulnerabilities waiting to be exploited are called out and prioritized for the process or technical fix

A detailed root cause analysis is then taken up to zero down in SDLC life cycle which was the originating point for this vulnerability to get injected (specific case-wise). 

o Backward traversal from post-Go live phase  Deployment  User Acceptance testing  System Integration Testing  Implementation  Design  Requirement Elicitation phases. Each SDLC phase where there could be contribution towards injection of this vulnerability will be tagged with associated weightage. 

Leveraging Affinity principle and weighted average mechanism, the earliest and core phase where this vulnerability took birth is determined and highlighted. 

Cost of data breach and efforts to fix at each SDLC phase can be called out.


Milestone 2 - 

Our next milestone was to study and innovate a mechanism to adopt early prevention of Vulnerability injection in SDLC life cycle. As from our Milestone 1 experiences, it was evident that most vulnerabilities enter as early as requirement phase itself and some of non-technical logical requirements were the major suspects.

"Logical vulnerabilities are flaws injected due to improper business logic. Logical vulnerabilities are security gaps ascended due to improper business logic and not from coding".  These vulnerabilities are exploited by understanding how an application works and circumventing the typical business flow. These vulnerabilities manipulate the logic of the application to enforce functionality which application was never intended to do.

Below Techniques can be utilized to decide whether requirements are vulnerable free or not!?

3. Design Thinking - for security requirements vulnerability detection. Design thinking enables the identification of the presence or absence of security requirement attributes at atomic level.

4. Binarization - Concept of security requirement template has been innovated in our study that can be used in quantifiable model through binarization approach.

Stage 1: Security Requirement Analysis

Stage 2: SRA template

Stage 3: Design thinking to extract and identify SRA

Stage 4: Binarization and Vulnerability Detection

Stage 5: Determining Vulnerable and non-vulnerable SR


Based on INVEST principles try to break the requirements into Atomic level.

Identify the requirement attributes (as defined in our SRA template) presence or absence in each Use-case. 

Apply binarization (1s or 0s) to the respective attributed based on its presence or absence

A logical AND and OR operation based on the requirement attribute category (BASIC / PRECISE / PRIMARY). 

A requirement with SRA score 1 is categorized as Vulnerable and needing further refinement, whereas SRA score 0 represents well defined non-intrudable logical requirement which can proceed to Design and Development phase. 


Milestone 3 -

Our final milestone to innovate a mechanism to anticipate and prepare for a possible security attack and propose a framework towards eliciting resilient requirements as below:

Application security attack deterrence inherently depends on two factors: higher grade Quality of Application Security (QAS) and optimized risk. In turn these two aspects are dependent on good quality security requirements (SR). Currently, there exists no methodology to delineate the limitations of SR. we propose framework to elicit resilient requirements to deter attacks by identifying the attacker's objective. 

5-phase approach:

 Application classification

 Vulnerability Evaluation

 Countermeasure Evaluation

 Countermeasure Selection

 Countermeasure Decomposition.


The study focuses on attack preparedness or resiliency in SR. In general, the word 'resiliency' is the capacity of a system to withstand and recover quickly from both known and unknown threats.

Application resiliency depends on how well resilience concepts are embedded in security requirements. Though resilient applications are of essential need, its development is at conceptual level. Resilient security requirements are not yet explicit in the current practice of application development. 

Application classification provides a roadmap to know the relevance of each application in the organization. Get the necessary protection against vulnerabilities to maintain continuity of service and compliance. Provides insight into the importance of vulnerability relative to the context in which the application operates.

Vulnerability identification gives a view of vulnerabilities that affect an organization. This uncovers the deficiency in SDLC. Integration of the information such as vulnerability density in each application category, application criticality, and repeated vulnerability in applications can determine the type and trend of security attacks 

Resilient Security Requirement generation process provides awareness on the nature and strength of vulnerabilities present in applications. The security team can prepare organization specific vulnerability distribution chart that reveals redundant, frequent and dominant vulnerabilities with a common strong countermeasure.

Countermeasure's adherence ensures the efficiency of countermeasures to address vulnerabilities. Vulnerability verses countermeasure analysis gives the mapping of vulnerabilities against respective countermeasures. This analysis helps to frame the required set of countermeasures without redundancy.

Building Resilient Use Cases from countermeasures is a great way to test the application's defensive ability against the attacker's potential. Resilient Use Cases provide a distinct coverage of what must be implemented to address a given vulnerability.

This article is applicable beyond CRM space considering all digital application landscape of an Organization. The entire process of building resilience into their requirement engineering phase allows the organization to identify, remediation and transform only the vulnerable applications and not those that have acceptable level of protection. This action of directing the organization to focus only on needy systems than focusing on all applications of the organization results in many benefits such as cost saving, time saving, efficient management of applications and better achievement of security resiliency. 

As a conclusion, we saw 3 milestone approach which can be further tailored to each program to Identify the vulnerability injection point, measure the requirement elicitation maturity by testing for presence of vulnerabilities or not as early as requirement engineering phase, finally a framework to consistently define a resilient requirements to uplift the quality of requirement plus its resilience which in turn shall elevate project success rates in midst of severely hacked world today.


Note: Thanks to Shubhamangala B.R for guidance


Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.