REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

Security Considerations When Automating Software Development

Goutham Kacheru1, Sr. Software Engineer, Infostretch Corporation, United States- Email
id: [email protected]
Rohit Bajjuru2, Masters in Electrical Engineering, Southern Illinois University
Edwardsville Email id: [email protected]
Nagaraju Arthan3, Research Scholar, PhD in IT, University of Cumberlands,
Williamsburg, Kentucky. Email id: [email protected]
Abstract: The heterogeneous and partly outsourced nature of cloud service architectures gives
rise to inherent complex security challenges. Cloud applications are expected to leverage agile
software development methodologies and high-speed time to market while the traditional
security verification process is cumbersome and expensive. We therefore outline a security by
design approach that fully automates these processes to lower associated costs and reduce
reliance on specialized security expertise. We evaluate an existing software system and identify
threats to its technical assets, prioritize risks, and offer automated recommendations of
standardized countermeasures with limited human intervention. When used as part of the
development cycle, a dedicated tool implementing this technique can help you avoid expensive
security experts and minimize the time it takes to assess your security. Performance of the
proposed approach is evaluated against state of the art literature and tools.
1. Introduction
Cloud computing is easily the fastest growing technology sector in history, providing
unprecedented scalability, flexibility, and cost savings for software development. On the other
hand, it brings with it new security challenges that deserve attention. Cloud service architectures
are often heterogeneous and rely on third party components, which can often comprise a
complex attack surface, making them potentially difficult to defend. The conventional way these
checks for security verification are done is very tedious and manual, that cannot cope with high
end agility of development approaches and the speed to market demands by cloud based
applications. And these exercises are understandable expensive to run, with specialist security
intelligence not always readily available. Secondly, cloud environments are dynamic and
Page | 598
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

distributed in nature that makes it difficult to pinpoint and fix vulnerabilities. Adding to the
complexity, there's the shared responsibility model of cloud security where providers are
responsible for securing their entire infrastructure while users must ensure that their apps and
data remain secure too. The separation of responsibilities can also confuse and cause security
coverage gaps if not handled correctly. In addition, the rise of increasingly advanced
cyberattacks, combined with more data and sensitive information being held in the cloud, make a
reactive security strategy insufficient. To solve these challenges we propose a security by design
method automating threat modelling and risk assessment methods for cloud service architectures.
Our method focuses on optimizing the security verification process by being cost effective and
minimizing the necessity for domain expert level knowledge required in security. This approach,
which addresses security issues earlier in the software development lifecycle, helps to mitigate
risks before exploiting them. The approach is a user interaction light solution that analyses the
software system, performs a threat analysis based on technical assets, ranks the risks related to
those threats and proposes standard mitigations. This automation enables development teams to
remain laserfocussed on building secure applications, without having to spend considerable time
overcoming cumbersome and lengthy security assessments. We now have a dedicated tool which
facilitates scaling this technique into existing development processes. It allows developers to
conduct automated security assessments during the SDLC and promotes a culture of security
making sure that security isn't some afterthought. Our approach allows enterprises to balance
agility with security in their development efforts by minimizing dependency on expensive
security professionals and reducing the time needed for effective cloud assessment. The
proposed approach has been evaluated against existing literature and techniques by testing them
on Penetration Testing tools, and the results show its prospects in contributing to elevate the
overall security posture of cloud applications.
Automating Threat and Risk Assessment
Cloud security requires a proactive and holistic approach to threat modeling and risk assessment.
Conventional practices, which tend to be handson, tedious and based on specialized skills, are
lagging behind the ever changing world of cloud environments. The benefits of automating these

Page | 599
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

processes are substantial, allowing for an easy integration of security within the traditional
software development lifecycle.

Figure 1: The Steps of the proposed methodology

Fragmation: Automated Threat Identification
• Using ML: Use machine learning models trained on known threats and vulnerabilities to assess
the risk of a cloud (or multicloud) deployment. Such as using a codebase or configurations, and
analyzing architectures of systems to discover existing areas for security vulnerabilities.
• Connecting with Vulnerability Databases: Keep threat models current by adding data from
vulnerability databases and security advisories. This guarantees that assessments reflect best
known threats at the time.
• Dynamic Analysis: Use dynamic analysis techniques to recreate attacks and detect
vulnerabilities that are inconspicuous by static analysis.
Automated Risk Assessment:
• Quantitative Risk Analysis: Quantify threats identified in qualitative risk analysis or such that
the organization is currently facing, considering factors including likelihood and negative
impact. It allows prioritizing the risks and allocating resources objectively.
• Contextual Risk Scoring: Risk should be evaluated within the context of the cloud
environment. Risk scores should depend on factors such as data sensitivity, regulatory
considerations and business impact.
• Automated Reporting and Visualization: Create detailed reports and visualizations that
communicate the risk levels and remediation information effectively to stakeholders.

Page | 600
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

Integration with SDLC:

• DevSecOps Integration: Integrate automated threat modeling and risk assessment tools in the
CI/CD pipeline, so that each phase of development has security awareness.
• Automate Security Testing: Add automated security testing tools to detect and discover
vulnerabilities as the development phase begins.
• Monitoring and Alerting in RealTime: Monitors cloud environments continuously to detect
security threats and create alerts for immediate response.
Benefits of Automation:
• Enhanced Automation: Automate recurrent tasks, allowing security staff focus on higher value
activity.
• Enhanced Precision: Eliminate human error and improved consistent practises of qualiy
controls needed in security over time.
• Improved Scalability: Scale security assessments to keep up with the growth and evolution of
cloud environments.
• Proactive Security Posture: Move away from reactive security and continue with a proactive
approach to anticipate the threat before it gets exploited.
Automating threat modeling and risk assessment can help organizations improve their cloud
security posture, thus significantly reducing the chances of a breach. This approach facilitates
speedier, more precise and scalable security assessments with the end result being safer, resilient
cloud ecosystems.
Threat Modeling and Risk Assessment Automation
This paper describes an automation process that can specifically facilitate six steps of threat
modeling and risk assessment, to reduce dependence on resorting to expert intervention over and
over again. This method identifies threats and their risks, then recommends countermeasures
based on security frameworks defined. Interaction with the user is only necessary in the first
phase of system modeling and in the final phase of risk rating.

Page | 601
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

The first phase consists of defining the architecture of the app including used assets and its
interactions. This phase does require a considerable amount of user input, as for accurate threat
modeling we need an exact knowledge about the parts and relationship between those parts in the
system. This process may involve:
• Data Flow Diagrams: Illustrated diagrams showing how data is provided, used, and transmitted
within the system.
• Asset Inventory: Prepare an all encompassing inventory of system assets, including hardware
assets, software assets, data and personnel.
• Asset Dependency Mapping: Establishing the interdependencies and relationships across
different assets to identify possible impact of compromise on one asset affecting other assets.
• Trust boundaries: Finding trust boundaries within the system, marking areas with distinct
security requirements.
Threat Agent Identification:
The focus of this step is listing possible threat actors, or persons/individuals who may attack the
system. Having a sense of the potential adversaries allows us to characterize their threats and
prioritize the relevant risks. This process can involve:
• Threat Actor Profiling: This involves building profiles of potential threat actors, including their
motives, skills and attack methods.
• Threat Intelligence: Using threat intelligence feeds and reports to find new threats, as well as
those lurking in the wild—specifically predictable target systems.
• Environmental Analysis — factoring in the environment where the system is deployed, which
includes regulatory requirements and specific threats from industry.
Threat Identification:
Step 2: Identifying Potential Threats In this step, we need to identify all possible threats based on
the type of assets, their relationship with each other etc. It utilizes a threat catalog uniquely
characterized by a triplet: Target, Attack and Behaviour.
• Target: The asset type that the threat is targeting
• Attack: The method a threat agent uses to leverage a vulnerability.

Page | 602
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

• Behaviour —Description of the malicious event in natural language that allows security experts
to understand how to mitigate it.
This additional information is added to the threat catalog:
CIA Triad Impact: Determine what security requirement in the CIA triad each threat has an
effect on.
• STRIDE Classification: Assigning a classification for each threat based on the STRIDE model.
Risk Assessment:
In this phase, the risk associated with each identified threat is assessed. Risk is determined by the
combination of likelihood and consequence. Such process can take advantage from OWASP
methodology and use parameters coming from modeling the system and threat catalogs.
• Probability Estimation: Evaluating the probability of a threat being successful, based on
variables such as attack methodologies, exploitation potential and existing controls.
• Consequence Analysis: Analyzing the effect of a successful attack by evaluating details such as
data loss, financial damage, and harm to reputation.
• Risk Calculation: The process of taking the values calculated, (i.e. probability and
consequences) and combining them to calculate what is referred to as "risk" for each threat.
Risk Rating:
In this step, a rating of the risk must be assigned to each threat identified using the calculated
value of risk. The phase involves user intervention to confirm the automated risk assessment and
modify ratings according to specific business contexts and appetite for risk.
• Risk Matrix: Creating a risk matrix to visualize and prioritize the overall risk based on
probability of occurrence and impact.
• Risk Acceptance: Assessing risks that fall in the acceptable range according to the risk appetite
of the organization.
• Risk Mitigation planning: Prioritizing the risks for enhancement according to their rating and
probable impact.
Recommendation for Security Control

Page | 603
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

Last Step is to Create the List of Recommend Security Controls In The NIST security control
framework (SP 80053) These recommendations take into account the threats we identified and
their associated risk assessments.
Control Mapping: linking the threats you have identified to appropriate security controls that
could help lessen their impact.
• Prioritisation – The risk level of the threats paired with its associated security controls.
• Implementation Guidance: Information and guidance on how to properly implement the
recommended security controls.
The automated process simplifies threat modeling and risk assessment processes to help
organizations identify and mitigate security risks early on. It enables a holistic and efficient
approach to security throughout the software development lifecycle, using established security
frameworks in combination with input from users at critical points in the process.
2. The Technique
One of the best practices for having security critical applications is comprehensive Threat
Modeling during development. This automatic process implementation enables integration with
security by design approaches because our approach is to automate Threat Modeling and Risk
Analysis. With this automation, it comes up with some possible threats and also proposes related
countermeasures in terms of security controls that must be checked preproduction. It is very little
user interaction with the model creation phase. Section 5 discusses the comprehensiveness of the
threat list. According to NIST, a threat is an event or condition that has the potential for causing
asset loss and undesirable consequences. It is challenging to determine every possible threat that
could occur, as threats may arise from design choices, technologies used, or custom code. For
this purpose for automating threat identification in cloud applications, a threat is modeled as
containing three features threat Agent, Asset and Behavior.
According to a literature review, the term Threat Agent refers to an antagonistic actor causing the
threat event. According to NIST an Asset is any high value items used to meet the goals and
objectives of an organization. Our approach is same as for Technical assets, i.e. technical parts of
a system to perform this type classification, we have defined several classes of assets (Asset

Page | 604
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

Types). Behavior refers to the actions, or occurrences that can result in the compromise of assets
(e.g. unauthorized access, alteration, and destruction). Modeling threats as Threat .Behavior
triples provides a systematic way to identify and assess risk to the application being developed.
We employ a commonly used cloud hosted application, an ecommerce system using WordPress,
to validate our approach. It is an opensource content management system to create and manage
dynamic websites. Here, we will use a WP application because the WP would run on a cloud
virtual machine with an Apache web server and MySQL database in this case study. And when
scaled, these multiple WP instances can share the same vertically scalable database. A load
balancer distributes incoming requests from clients across these instances. WP instances are
customized by developers using plugins and other custom configurations.
These systems are, in fact, easy to develop, but because they work with financial and personal
data that require a high level of security. Due to poor planning and management of security, a
large amount of WordPress instances is vulnerable. Human Sort: Identify and mitigate
vulnerabilities before deployment, our approach helps you do that.

3. Modelling
System Modeling with the MACM Formalism MACM is a graphbased model where nodes
correspond to system components, and edges denote connections between them. Each node is
labeled either regarding its deployment role (e.g. Cloud Service Provider, Cloud Service
Customer) or service model (e.g. IaaS, PaaS, SaaS). This concept is known as labels, where
should restrict the edges a node can have. In addition nodes also have properties such as the
mandatory property for a service which is a type that defines what the Asset Type. That is the
IaaS node can be VM or container and SaaS can be Web Application, Database or IDM. Adding
new asset types is an easy task.
On these graphs, directed edges represent a relationship between the nodes, providing
information like who provides, hosts or uses something. These relationships, which describe how
components interact. As an example, a "uses" relation with two services means that the first

Page | 605
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

service uses the other to accomplish its functionality. Relationships can have properties, e.g a
"protocol" on the "uses" relationship to define communication protocol.
Our case study is illustrated on the MACM model (not shown due to space limitations in Figure
2). Node colors indicate labels, attributes not shown. The system includes a Cloud Service
provider with three virtual machines (virtual machines: IaaS, Asset Type: VM) One VM is
hosting Load Balancer service and other ones are hosting an instance of WordPress and MySQL
(database) respectively. Here we can see Load Balancer and WordPress are modeled as SaaS
nodes.

4. Threat Agent Selection

A threat actor may be any individual or anything that can cause, carry, transport, and/or facilitate
the occurrence of a threat. More Information on (and the Reason to Identify) Threat Agents
Security assessments are not done at random, and threat agents are also taken into consideration
when determining risk rating. In this study, we use the taxonomy from (Casey et al., n.d.) that
classifies threat agents as shown in Table 3 (not provided).
This taxonomy maps attribute values to each threat agent class. These attributes and their
potential values are summarized in Table 4 (not shown). To further subdivide these attributes we
delineate them into two categories, (i)attributes which inform relevant threat agent selection and
(ii)attributes for risk evaluation. For selection, we concentrate on the first of these categories:
Intent, Access, Outcome and Objective. To select the threat agent, we have defined four
corresponding questions that need to be answered by the system owner.
4.1 Partial Case Study Application
Since our case study has been intended for an ecommerce WordPress site, its cybersecurity
officer is concentrating on the hostile threat agents only as they target those that can result in
payoff. We assume that all personnel are to be trusted, and therefore are not considered. The
categorization of threat agents corresponding to these responses is provided in Table 5 (not
shown). Some categories are universal and apply to all systems, such as threat agents with no
particular intent. In the second situation, one user entered multiple values for Q3 and two

Page | 606
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

answers for Q4 with "Copy" being selected for Q3, and both "Tech Advantage" and "Business
Advantage" as answer options to Q4. If there are multiple responses for answer Q3 or Q4, then
threat agent categories are calculated per each response, and the final result is the union of these
sets. As a result, in summary the algorithm output takes technological vs business advantages
into account resulting in five different threat agent categories.
Category Description
Employee Reckless Employee who circumvents safeguards for expediency,bu intends no
harm
Employee Untrained Employee with harmless intent but unknowingly misuses system or
safeguards
Info Partner Someone with whom the company has voluntarily shared sensitive data
Anarchist Someone who rejects all forms of structure and acts with few constraints
Civil Activist Highly motivated but nonviolent supporter of cause
Competitor Business adversary who competes for revenues or resources
(acquisitions,etc.)
Corrupt Government Person who uses his position within the government to acquire resources
Data Miner Professional data gatherer external to the company (includes cyber
methods)
Employee Disgruntled Current or former employee with intent to harm the company
Government Statesponsored attacker with significant resources to affect major
Cyberwarrior disruption
Government Spy Statesponsored spy as a trusted insider, supporting idealistic goal
Internal Spy Professional data gatherer as a trusted insider
Irrational Individual Someone with illogical purpose and irrational behavior
Legal Adversary Adversary in legal proceedings against the company, warranted or not
Mobster Manager of organized crime organization with significant resources
Radical Activist Highly motivated, potentially destructive supporter of cause

Page | 607
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

Sensationalist Attentiongrabber who may employ any method for notoriety

Terrorist Person who relies on the use of violence for sociopolitical purposes
Thief Opportunistic individual with simple profit motive
Cyber Vandal Derives thrills from intrusion or destruction of property, without strong
agenda
Vendor Business partner who seeks inside information for financial advantage

4.2 Implementation
We created a python script to automate this process that includes the threat agent selection
algorithm. Threat Agent Selection Process — This is implemented as a wizard that collects
information by asking the questions mentioned above from the user. A specific data model is
being used throughout this process as shown below where one can logically divide it into two
halves: a static predefined first half and a dynamic second half representing results from the
wizard for the application.
The ER model of this data model is shown in Figure 3 (not available). The static part (the blue
tables) consists of six tables: one group that stores categories, attributes and their mapping for the
Threat agent (based on (Casey et al., n.d.)), and a second group which stores Questions, Replies
as well as a linking table connecting answers to satisfied Categories. Future work with further
validation will easily be able to build upon this model.
In each step of the wizard, user answers questions, and the intermediate results get saved in the
dynamic tables.
Attribute Description Attribute Values
Access Privileged position of the Internal, External
target infrastructure
Intent Whether the agent intends Hostile, Not Hostile
harm
Limits Legal and ethical limits of Code of Conduct, Legal, Extralegal Minor, Extralegal

Page | 608
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

threat agent Major

Outcome Primary goal of threat agent Acquisition, Business Advantage, Damage,
Embarrassment, Technical Advantage
Objective Method agent uses for Copy, Deny, Destroy, Damage, Take, All
achieving goals
Resources Available time, money and Individual, Club, Contest, Team, Organiza tion,
technological means Government
Skills Special training and expertise None, Minimal, Operational, Adept
Visibility How hidden are identity and Overt, Covert, Clandestine, Don't Care
actions
Table 5
Category Description Common Actions
Competitor Business adversary who competes for re Theft of IP or business data
sources
Cyber Derives thrills from intrusion or destruction Network/Computing disruption, web
Vandal of property, without strong agenda hijacking, malware
Irrational Someone with illogical purpose and irra Personal violence resulting in
Individual tional behavior physical business disruption
Data Miner Professional data gatherer external to the Theft of Personally Identifiable
company Information, IP or business data
Sensationalist Attentiongrabber who may employ any Public announcements for PR crises,
method for notoriety of fame theft of business data

5. Threats Selection Phase

The Threat selection phase is at the heart of this Framework, and it is an extension of the original
MUSA framework described by means of a Threat Catalogue designed in the scope of the H2020
project MUSA. This catalogue classifies threats based on the type of asset — it is built from

Page | 609
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

existing sources (OWASP and some scientific papers) and links to source pages are preserved.
You can access the Threat Catalogue for free.
This method has been improved to also take into account asset types and their relationships with
one another. In Section 3, we refer to MACM relationships identified by the value of the
"protocol" attribute specifying protocol(s) over which communication happens between nodes .
In more detail, if a Customer uses a web application over HTTP, the MACM model appends
"HTTP" as an attribute of the "uses" relationship and then associates the role of "client" with that
CSC, and assigns the role of "server" to that application.
This method only currently supports client server peers. We hope to apply it to other paradigms
in the future. Relevant protocol related threats have been added to the threat catalogue as
appropriate.
5.1 Design + Data Architecture
The improvements to the approach required better design of the data model for Threat Catalogue,
which is shown as Figure 4 (not shown). This new model contains a dynamic "components" table
connected via an N:M relation to the threat catalogue table. Using a "threat protocol" table,
threats pertaining to protocol based issues are mapped to a "Protocols" table.
Relationships are kept in a "Relation" table, and protocol information is gathered from the
MACM. Table 1 Mapping components to their used protocols, and defining whether the
component (arc direction) is acting as client or server
The threats are retrieved from by means of a query, to select only those related to certain
protocol, but also a filter is applied based on the attribute role. This is different from threats
relative to components of the same type that speak with the same protocol but play different
roles.
5.2 Threat Selection Example
This method produces a list of threats in our case study (models listed in Tables 1 and 2 at the
Modeling section). We omit some tables for conciseness, Table 7 (not provided) lists few
HTTPS related threats and Table 6 (not provided) demonstrates within asset pair threats. The
entire threat list is long and maintained in our tools, with a web interface for browsing.

Page | 610
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

This is to analyze then you have potential threats like Injection for WordPress. Data Breaches
Jailbreaking: such as Bruteforce, Sniffing, and Admin Interface Unlocked SQL data can be
sniffed within the communication channel between SQL and WordPress or even directly parsed.
5.3 Selfvalidation with Microsoft Tool
To provide some validation for our threat selection approach we compared its results to the
output of Microsoft's Threat Modeling Tool. For instance, the efforts needed by a component
(e.g., WordPress in our case) is shown in 8 (for space motivation we report only the table for this
asset). We were able to uniquely identify 27 threats across both groups using Microsoft tool,
while our approach proposes only 18. The key difference between the approaches is that MS tool
suggest more low level threats, in a way assists a technician for technology oriented problem
solution, Our tool suggested high level threats which are more likely to assist policy definition
and audit verification procedures. Additionally, in table 8 we describe the relationship between a
partial set of threats proposed by an MS tool and the specific cases against the threats raised
using our approach, for example we may consider the threat of security misconfigurations
(whose mitigation may be accomplished by adopting an audit procedure and/or some
SCAPbased automatic tools (D. Waltermire, 2018)), while the MS tools proposes a specific list
of security misconfiguration cases. As regards the threats detected on the MYSQLDatabase we
have suggested 22 threats, compared to 7 proposed in the tool of Microsoft. Microsoft only
shows 2 threats for VM asset but instead we considered 17 different threats. In both cases the
threats proposed by MS are subcases of those that we identified. I believe the main difference in
the last two asset types is simply due to the fact that we take an asset oriented approach while
Microsoft suggests a communication oriented one. These findings show that the proposed threat
modeling approach is reliable because of the fact that the threat catalogue was built based on
cybersecurity best practices.
6. Risk Evaluation
Risk Assessment Process: The MACM model is used to determine the most significant threats,
and then these high impact threats are evaluated for severity by both likelihood and impact. The
threat modeling helps to identify what are the potential threats of a system but it is not feasible

Page | 611
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

nor economical to address all these threats. . For this, we used OWASP Risk Rating
methodology to evaluate risk from Likelihood and Impact.
Likelihood refers to the probability of a threat agent creating an exploit for a threat. OWASP
expresses this via Threat Agent Factors and Vulnerability Factors.
Impact takes into account technical and business factors. Technical impact relates to how threats
affect security requirements. Business impact, and other factors related to the company.
OWASP partially describes what each factor should be rated (110). The average factor values are
then grouped into categories of Low (13), Medium (46), or High (710) for both Likelihood and
Impact. The risk matrix then calculates the overall threat risk level by combining Likelihood and
Impact levels. With our approach, we set predetermined Threat Agents and threat behaviors so
that 12 out of the 16 factors can be calculated automatically. The only context dependent part we
need user input on is business impact factors.
6.1 Threat Agent Rating
Calculating Threat Agent Factors for a given threat model is done through some core steps and
with information found in different portions of the document. All identified threats are treated
similarly in the model; these factors have been calculated at a systemwide level and remain
invariant across threats. It is primarily based on the OWASP framework and its parameters
grouped into categories from a questionnaire.
Here is a step by step guide on how the process works:
System Level Threat Agent Characteristics:
The Threat Thanks Agent Factors are only calculated once for the entire system and uniform
against all threats. It helps to standardize the risk assessment by providing a common
understanding of who we may be facing in terms of threat actor & capabilities.
OWASP parameters and agents of threat:
The calculation uses OWASP threat agent parameters. These parameters are evaluated per
categories defined in a questionnaire (Section 5). This questionnaire likely collects information
regarding possible threat actors, their motivation, capability and access level.
TAL Attributes and Scoring:

Page | 612
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

There is a Threat Agent Level associated with each category for every questionnaire. An
OWASP values calculation uses a score this attribute has been given. Enhanced security services
TAL score is probably the damage a particular threat agent of that type could inflict on the
system.
Taking Attributes as Classes:
As explained in Section 5 it takes into account both classes of attribute Though the attribute
classes themselves are not elaborated on here, they may include elements of a threat agent's
characteristics e.g., technical capabilities, access control powers, motives.
For example, you can calculate OWASP Motive:
The OWASP Motive parameter estimates the probability of a threat agent selecting an attack
vector based on three factors:
• Target of the threat agent or goal of what the threat agent wants to achieve (e.g., target)
• Result: A successful outcome from the threat agent's perspective, which means a successful
attack.
• Limits: Constraints that would or could force the threat agent to act in a certain way.
The scores for Intent, Outcome, and Limits are then combined to result in a final OWASP
Motive value. It adds to the calculation of the overall Threat Agent Factor.
To summarize: You gather information about possible threat actors using a questionnaire, in
which you scale the attributes based on the responses to the questionnaire and then use those
scores to find out OWASP parameters. Then these parameters are merged to obtain the global
Threat Agent Factors that can be used consistently on all identified threats across model. By
reframing elements of threat agent characteristics, this structured approach can serve to ensure
that a consistent and thorough assessment can be made on the potential impact that each possible
threat agent poses to system integrity.
6.2 Vulnerability Rating
Properties of vulnerable component are evaluated per threat, termed as the set of vulnerability
factors.

Page | 613
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

• Ease of Discovery – This rates the difficulty in discovering the vulnerability and how simple it
is to find. More discovery means more likelihood.
• Exploitability This comes from the expertise required to exploit the threat.
• Last updated the greater the Knowledge a villain has concerning a weakness, the more probable
it is actually for this to become mistreated.
• Intrusion Detection – Countermeasures that can do the check on decrease threat possibility.
These four factors are defined from properties of a component (for one) as well the definitions at
OWASP.
6.3 Impact Rating
Impact assessment involves both technical and business considerations:
TTC: By affected security requirement – confidentiality, integrity, availability, accountability It
assumes the worst case scenario,

7. Security Control Selection

Close this process step, proposing target system countermeasures against the identified threats to
improve overall security. This step, detailed use of the threat catalog enriched. The development
of countermeasures is referenced from NIST security control framework that recognizes controls
must belong to families, controls, and control enhancements.
For every identified threat, we check the threat catalog to find NIST security controls mapped.
NIST framework. We have already discussed NIST framework as a baseline that defines
mandatory controls based on various levels of security. Select all controls on identified threats
needed for risks beyond those assessed in prior sections. Examples of Recommended NIST
Controls for Our Case Study (not shown) are presented in Table 10 For Ex: To mitigate Injection
threats for web applications, input/output validation is recommended etc. Control selection
details are well established (and in some cases will have been reported previously), and therefore
we will not elaborate further on this.
8. Conclusions

Page | 614
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

There are massive benefits in terms of efficiency, consistency, and speed to be gained by
automating software development processes. Out of the box available in a security by design
approach, this allows anyone to automate work typically done by a security specialist. We do not
want to replace experts but instead we want to provide them with the quickest way of
involvement while also validating, enriching policy development and verification. It relies on a
simplified application model, as is done in tools such as Microsofts Threat Modeling Tool, and a
couple of easy questions to assess risk. Validation was by comparison with an existing tools
(e.g., Microsoft's) and using standard methodologies for the subjective phases. Competition with
Microsoft's Tool We found that our approach was able to identify all threats proposed by the
Microsoft tool and in some cases, more generalized threats. To the best of our knowledge, there
exists no comparable support for threat agent identification, and threat modeling and risk
analysis followed by countermeasure identification in a tool or technique with minimal
outofthebox user interactions involved other than answering some direct followup questions and
preparing the initial model. Several other future works also remain, including validation of risk
analysis with threat intelligence datasets to make our results more robust and enhance the
accuracy of risk levels. Our goals also include the evolution of threat catalog enrichment
automation via open datasets and improved risk factor evaluation via analysis and testing.
References
1. Abela, R. (2020). Statistics show why wordpress is a popular hacker target.
2. Casey, T. (2007). Threat agent library helps identify information security risks. page
12.
3. Casola, V. (2019). Toward the automation of threat modeling and risk assessment in
IoT systems. Internet of Things, page 13.
4. Casola, V., De Benedictis, A., Rak, M., and Rios, E. (2016). Security-by-design in
clouds: A security-sla driven methodology to build secure cloud applications.
Procedia Computer Science, 97:53 – 62. 2nd International Conference on Cloud
Forward: From Distributed to Complete Computing.

Page | 615
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

5. Casola, V., De Benedictis, A., Rak, M., and Salzillo, G. (2020a). A cloud secdevops
methodology: From design to testing. In International Conference on the Quality of
Information and Communications Technology, pages 317–331. Springer, Cham.
6. Casola, V., De Benedictis, A., Rak, M., and Villano, U. (2020b). A novel Security-
by-Design methodology: Modeling and assessing security by SLAs with a
quantitative approach. Journal of Systems and Software, 163:110537.
7. D. Waltermire, J.-M. (2018). Transitioning to the Security Content Automation
Protocol (SCAP) Version 2. White Paper, NIST.
8. Dobrovoljc, A., Trcek, D., and Likar, B. (2017). Predicting ˇ Exploitations of
Information Systems Vulnerabilities Through Attackers’ Characteristics. 5:13.
9. Fraunholz, D., Anton, S. D., and Schotten, H. D. Introducing GAMfIS: A Generic
Attacker Model for Information Security. page 6.
10. Group, J. T. F. I. W. (2020). Security and Privacy Controls for Information Systems
and Organizations. NIST.
11. Kohnfelder, L. and Garg, P. (1999). The threats to our products. Microsoft Interface,
Microsoft Corporation, 33.
12. Marback, A., Do, H., He, K., Kondamarri, S., and Xu, D. (2013). A threat model-
based approach to security testing. Software: Practice and Experience, 43.
13. Qualys (2013). SSL Threat Model. https://www.ssllabs. com/projects/ssl-threat-mode.
14. Rak, M. (2017). Security assurance of (multi-)cloud application with security sla
composition. In Au, M. H. A., Castiglione, A., Choo, K.-K. R., Palmieri, F., and Li,
K.-C., editors, Green, Pervasive, and Cloud Computing, pages 786–799, Cham.
Springer International Publishing.
15. Ross, R., McEvilley, M., and Oren, J. C. (2016). Systems security engineering
considerations for a multidisciplinary approach in the engineering of trustworthy
secure systems.
16. T. Lodderstedt, M. McGloin, P. H. (2012). OAuth 2.0 Threat Model and Security
Considerations draft-ietfoauth-v2-threatmodel-08. RFC 6819, RFC Editor.

Page | 616
 REVISTA DE INTELIGENCIA ARTIFICIAL EN MEDICINA

Volume: 12 Issue: 01 (2021)

Available Online: https://redcrevistas.com/index.php/Revista

17. Williams, J. (2020). OWASP Risk Rating Methodology. https://owasp.org/www-

community/OWASP Risk Rating Methodology.

Page | 617