International Journal of Advanced Science and Technology

Vol. 29, No.02, (2020), pp. 1564-1571

SQUARE Methodology based Security

Framework in Cloud computing
Pragnavi Erva
Dept. of CSE, UCE(A), O. U

Abstract: Security is a vital requirement for software systems. The security of the underlying cloud
software is crucial to the overall health of a cloud infrastructure since these are the foundations upon
which other applications within the cloud function. Misuse case models allow system designers to inject
security considerations within their designs in the development lifecycle rather than patching an end
system after it was developed. Conducting vulnerability assessments in cloud environments requires
approaches different from those found in traditional computing. Efforts towards improving security in
cloud infrastructures recommend regulatory compliance approaches. Vulnerability assessments are
imperatives for fulfilling the regulatory compliance requirements. SQUARE namely Risk assessment,
Elicitation techniques [3], Categorization and Prioritization are reviewed with major characteristics.
The above four steps are analyzed against application development.
Keywords:Cloud Computing, Elicitation, Vulnerability, Misuse case, attack trees, SQUARE
methodology.

I. INTRODUCTION

Almost all of the software systems installed today involve security in one way or another. Yet these
systems are breached. One of the most critical phases of Security architecture lifecycle is the security
requirements engineering phase, because any flaws occurring in these phases will cost a lot to fix in the
later stages. A possible solution lies in creating security architecture, ensures that security as a
subsystem and creates separation of concerns. Without requirements security architecture cannot be
built. SQUARE is one of the most popular Security requirements methodologies. It is a process aimed
specifically at security requirements engineering. SQUARE Methodology is able to accurately adapt to
the current state of the practice of software and requirements engineering. This paper mainly focuses
on performance of SQUARE methodology and the four major steps risk assessment, elicitation,
categorization and prioritization were analyzed against SaaS application development as a part of
mainstream engineering that includes formal techniques of functional and nonfunctional requirements
elicitation.
In Cloud Computing paradigm however, platform and infrastructure are virtual making this
boundary non-existent and insecure. Recent times many applications have moved out of the private
network and being deployed as Web Services and these services are easily accessible to authorized
users and also to unauthorized entities alike therefore; security must be part of the application to protect
itself from security threats. Application security will however be over and above the perimeter network
security. To achieve this, security now need to be treated as functional requirement and must be part of
development lifecycle.

2. Applying SQUARE methodology against SaaS Application

SQUARE can be decomposed into nine discrete steps. Each step identifies the necessary inputs, major
participants, suggested techniques, and final output. The following are the nine steps of SQUARE
methodology [19].

2.1 Agree on Definitions

In order to guarantee effective and clear communication throughout the requirements engineering
process, the requirements engineering team and stakeholders must first agree on a common set of
terminology and definitions.

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC
1564
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

2.2 Identify Security goals

The purpose of Step 2 in SQUARE is for the stakeholders to formally agree on a set of prioritized
security goals for the project. The security goals of the project must be in clear support of the project’s
overall business goal, which also must be identified and enumerated in this step.
Security goals for SaaS are same as one’s traditional deployments but addressing the security issues are
twice. In SaaS model the control over the data is delegated to SaaS vendor and the communications
happen through network. In some cases SaaS vendor may be using a public IaaS for deployment of
SaaS where the access and control is given to IaaS vendor.
Also, SaaS application have many security vulnerabilities [16] like Denial of servers, SQL injection,
Hidden form parameters, cookie values, cross site scripting etc. as they include multiple entry and exit
points.
2.3 Develop Artifacts
Before the requirements engineering team and stakeholders can generate a comprehensive set of
security requirements, the team must collect a complete set of artifacts of the system. Example: System
architecture diagrams, use case scenarios/diagrams, misuse case scenarios/diagrams, attack trees,
standardized templates and forms.
Analysis of Use case for Login application:
Brief Description:
This use case describes how a user logs into the registration system
Basic Flow
This use case starts when an actor wishes to log into the system
1. The system requests the actor to enter his/her login credentials.
2. The actor enter his/her credentials
3. The system validates the entered credentials and logs into the system
Alternative flow
Invalid credentials
The system displays an error message. The actor can choose to either return to the beginning of the
Basic Flow or cancel the login at which the use case ends.
Pre conditions: None
Post conditions: if the use case was successful, the actor is now logged into the system. If not the
system is unchanged.
Analysis of Misuse case
For example, taking a simple scenario of login application where in use case and actor can be analyzed
with possible conflicts. An actor can malfunction and the use case defined as misuse case Figure1:

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1565
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

2.4 Perform Risk Assessment:

The purpose of this step in the SQUARE process is to identify the vulnerabilities and threats that face
the system, the likelihood that the threats will materialize as real attacks, and any potential consequences
of an attack. Without a risk assessment, organizations can be tempted to implement security
requirements or countermeasures without a logical rationale. The risk assessment also serves to
prioritize the security requirements at a later stage in the process.
Using attack trees to model threats is one of the oldest and most widely applied techniques on cyber-
only systems, cyber-physical systems, and purely physical systems. Attack trees were initially applied
as a stand-alone method and has since been combined with other methods and frameworks.

Attack trees are diagrams that depict attacks on a system in tree form. The tree root is the goal
for the attack, and the leaves are ways to achieve that goal. Each goal is represented as a separate tree.
Thus, the system threat analysis produces a set of attack trees. See examples in Figure 2.

In the case of a complex system, attack trees can be built for each component instead of for the whole
system. Administrators can build attack trees and use them to inform security decisions, to determine
whether the systems are vulnerable to an attack, and to evaluate a specific type of attack. Using the
attack pattern find risk of any given path using DREAD [.

DREAD measures the risk of attack on the application. it is used to calculate the impact of an attack

RISK= (Damage + Affected Users) * (Reproducability+Exploitability+Discoverability)

• Damage - how bad would an attack be?

• Reproducibility - how easy it is to reproduce the attack?
• Exploitability - how much work is it to launch the attack?
• Affected users - how many people will be impacted?
• Discoverability - how easy it is to discover the threat

2.5 Elicitation Technique

This step becomes important when there are diverse stakeholders. At this step we proceed with the
collection of the information for further analysis by the various stakeholders involved Thus, issues
of online surveys and semi-structured interviews are numbered, grouped and organized
according to the descriptive framework, to allow the analysis of the cases. The transcript of each
interview is sent to the participants to confirm the information provided during the interview, to

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1566
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

eliminate any misunderstanding. Quantitative data are analyzed using statistical tools that enable
its analysis. The analysis of qualitative data, though it begins during the execution of the
interviews starts in fact at the encoding of the collected information phase. The best way to assess
results is to identify the different patterns in the collected data. For the analysis of qualitative
data we

can use software for qualitative data analysis.

2.6 Elicit Security Requirements

The elicitation activity is supported by detailed study of security for each service. This activity uses a
set of security artifacts as seen in figure 2.
Following a brief explanation of the security artifacts used during elicitation’s activity progress is
specified
1. Identify the fragment of functional software whose security will be analyzed.
2. Identify the possible threats at application level
3. Identify and evaluate the threats
4. Identify the type of attackers and their possible type of attack
5. Assess the impact of the attack
Consider for example, hackers corrupt the database by injecting malicious SQL statements in
input fields of a SaaS application
Relevant countermeasures:
a. database login accounts should be given the minimal rights that are necessary for
functionality
b. Implement validation of input fields in SaaS application
c. Enforce data access via stored procedures with formal parameters content validation.

2.7 Categorize Requirements

After the identification of impacts it is necessary to classify them. According to the PMBOK, each
risk is evaluated according to the probability and the impact of the risk. The organization shall
determine the combinations of probability and impact in order to classify high risk, moderate risk,
and low risk, but the classification rules differ and are specific to each organization or project.
Based on this concept, we propose the development of a matrix according to the probability and
magnitude.

Vulnerabilities based on critical, medium , low : Attack Complexity: The attack complexity
(AC) metric describes how easy or difficult it is to exploit the discovered vulnerability

Value Description Score

Specialized conditions exist,

such as a race condition with a
narrow window, or a
High
requirement for social 0.35
(H)
engineering methods that
would be readily noticed by
knowledgeable people.

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1567
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

There are some additional

requirements for the attack,
such as a limit on the origin of
Medium
the attack, or a requirement for 0.61
(M)
the vulnerable system to be
running with an uncommon,
non-default configuration.

There are no special conditions

for exploiting the vulnerability,
such as when the system is
Low (L) 0.71
available to large numbers of
users, or the vulnerable
configuration is ubiquitous.

2.8 Prioritize Requirements

In most cases, the client organization will be unable to implement all of the security requirements due
to lack of time, resources, or developing changes in the goals of the project. Thus, the purpose of this
step in the SQUARE process is to prioritize the security requirements so that the stakeholders can
choose which requirements to implement and in what order, software level, or as architectural
constraints.

2.9 Requirements Inspection

The case study teams experimented with different inspection techniques and had different levels of
success with each. None of the inspection techniques that were used were sufficiently effective in
identifying defects in the security requirements, and the teams do not recommend their use in the future.
Instead, the teams recommend that future iterations of SQUARE experiment with the Fagan inspection
technique, which is a highly structured and proven technique for requirements inspection. For reference
purposes, the inspection techniques and their results can be made as follows.
NUMBER OF THE MIS- MIS USE CASE NUM-001 REGISTERED
USECASE
Name of the Mis-use Case Un authorized log on to the server Noticed
Scope of the Mis-use Case User authorization concerns Identified
Priority of the Mis-use Case Selected
a) Low Priority
b) Medium Priority
c) High Priority
Deployment of the Mis-use Case Selected
(a) Internet
(b) Intranet
Mis actors of the Mis-use Case Un authorized user access Noticed
Access Right Levels Low level user systems users Selected
Medium level user system users
High level user system users
System Admin
Other Network Users

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1568
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

Point of Entry Network Selected

Host
Application
Security Attributes Affected Confidentiality Selected
Integrity
Availability
Description If any un-authorized user attempts Noticed
to log on to the server and
succeeds
Sophistication Low Selected
Medium
High
Pre-condition Access control lists are Identified
configured properly in a domain-
based network. The un authorized
user has unintended log on rights
to the server. The server resides
on an intranet network
Assumption The user does not have expressed Identified
permission to log on to the server
Post-condition Worst case threat Notified
The un authorized user logs on to
the server machine.

Potential Mis Actor Profiles Potential Mis-actor Profiles Notified

Stake holders and Threats
Related Threats
Policy Recommendations
Medium to highly skilled,
potentially host administrators
with medium criminal intent
Stack holders and Threats Notified
Stakeholder's clients: loss of data
integrity and/ or confidentiality
Stack holders: Loss of reputation,
loss of current and potential
clients
Architectural Recommendations- Identified
Elevation of privilege, disclosure
of confidential data, unauthorized
access to administration interface,
unauthorized access to
configuration stores, retrieval of
print text configuration secrets
PRec-01: Audit information must Identified
be reviewed routinely
PRec--02: Enforce strong
password policies
PRec--03: Set clear and defined
user access controls for all users
such as low, medium, high,
system admins
reviewed
PRec--04: Users should not have
rights or access levels beyond
those of which prescribed by his
or her job responsibilities

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1569
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

3 Performance Evaluation:
In the process of requirement gathering the time and cost are high in the traditional application
development only for the functional requirements where as in proposed work the time and cost factors
are high as it not only gathers functional requirement but also identify misuse cases, attack patterns and
converting the misuse case to functional requirements. Hence when compared with traditional system
development the proposed work has less security risk. If security implications are increase modification
or upgrading the system is required from that maintain cost and time increase rapidly. If we draw graph
among traditional system development and proposed as below figure
.
20
Performance of traditional with
proposed
10

0
1 2 3 4 5
Traditional Proposed

4. Conclusion: Cloud computing is becoming popular and represents the future of computing. Before
it can be embraced by individuals and enterprises, however, the issue of security must be addressed.
Early consideration of security in cloud computing systems places it on a par with other functional
requirements of the system and significantly improves the security of the system. There is a need to
develop process to determine security requirements and develop policies for a cloud computing system
level-by-level in a structured manner. This methodology would analyze security requirements by
identifying threats posed by misusers both external and internal to a system. Requirements elicitation
helps in identifying the customers and stakeholders’ requirements in constructing software or a system.
There is no relevant Elicitation Topic Map for specific system and application domains. No
standardized elicitation methods for cloud providers. Large scale distributed software projects suffer
information overload, inadequate stakeholder input prioritization of requirements. This framework used
a simple login SaaS application for the vulnerabilities. Cloud computing is becoming popular and
represents the future of computing. Before it can be embraced by individuals and enterprises, however,

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1570
 International Journal of Advanced Science and Technology
Vol. 29, No.02, (2020), pp. 1564-1571

the issue of security must be addressed. Early consideration of security in cloud computing systems
places it on a par with other functional requirements of the system and significantly improves the
security of the system. It is observed that combination of web security testing platform with cloud
architecture can help to achieve on-demand resource for web application testing.

REFERENCES

[1]. Liu Kaihua, Li Xiong.” Cloud computing security model and strategyanalysis” [J]. Computer
Knowledge and Technology, 2011,7 (08): 1750-1751.
[2] X. F. Liu, H. Lin, and L. Dong, “High-Order Object-Oriented Modeling Technique for Structured
Object-Oriented Analysis,” International Journal of Computer and Information Science (IJCIS), 3rd ed.,
vol. 2. Oxford: Clarendon, 2001, pp.68–73.
[3] S. Markose, X. F. Liu, and B. McMillin, “A Systematic Framework for Structured Object-Oriented
Security Requirements Analysis in Embedded Systems,” in Magnetism, vol. III, G. T. Rado and H.
Suhl, Eds. New York: Academic, 2008, pp. 271–350.
[4] National Institute of Standards and Technology. “Cloud computing,”
http://csrc.nist.gov/groups/SNS/cloud-computing/index.html, October 2009.
[5] R. Fredriksen, M. Kristiansen, et al, "The CORAS Framework for a Model-Based Risk Management
Process," in Computer Safety, Reliability and Security. vol. 2434, Springer, 2002, pp. 39-53.
[6] C. Basile, A. Lioy, et al, "POSITIF: A Policy-Based Security Management System," in 8th IEEE
International Workshop Policies for Distributed Systems and Networks, 2007, pp. 280-280, Italy.
[7] H. Xu, X. Xia, et al "Towards Automation for Pervasive Network Security Management Using an
Integration of Ontology-Based and Policy-Based Approach," 3rd International Conference Innovative
Computing Information and Control, 2008, pp. 87-87, Dalian.
[8] J. Albuquerque, H. Krumm and P. de Geus, "Model-based management of security services in
complex network
environments," in IEEE Network Operations and Management Symposium, 2008, pp. 1031-1036,
Salvador.
[9] S. de Chaves, C. Westphall and F. Lamin, "SLA Perspective in Security Management for Cloud
Computing," in Sixth International Conference Networking and Services, 2010, pp. 212-217, Mexico.
[10] S. Pearson and A. Benameur, “Privacy, security and trust issues arising from cloud computing,”
CloudCom 2010, pp. 693-702.
[11] H. Takabi, J. B. D. Joshi, and G.-J. Ahn, “Security and privacy challenges in cloud computing
environments,” IEEE Security & Privacy, 8(6), 2010, pp. 24-31.
[12] K. M. Khan, “Security dynamics of cloud computing,” Cutter IT Journal, 22(6-7), 2009, pp. 38-
43.
[13] N. Oza, K. Karppinen, and R. Savola, “User experience and security in the cloud - An empirical
study in the Finnish Cloud Consortium,” CloudCom 2010, pp. 621-628.
[14] X. Jing, J. Tang, D. He, and Y. Zhang, “Security scheme for sensitive data in management-type
SaaS,” Int Conf on Information Management, Innovation Management and Industrial Engineering,
ICIII 2009 (4), pp. 47-50
[15] S. Ramgovind, M. M. Eloff, and E. Smith, “The management of security in cloud computing,”
ISSA 2010, pp. 1-7.
[16] Jayanti Vemulapati, Neha Mehrotra and Nitin Dangwal “ SaaS security Testing: Guidelines and
Evaluation Framework”- 11th Annual International software testing conference 2011
[17] Shubhamangala B.R, Snehanshu Saha “Application Security Risk Assessment and Modelling”
ISACA 2016
[18] Chun Wei (Johnny), Sia, “Misuse cases and abuse cases in Eliciting security requirements” 2005
[19] R.S.Sindhu Theja, G.Kalyani, E.Pragnavi, “A modified & extended security quality for
requirements engineering (SQUARE) methodology into standard lifecycle models, IJCDS, 2012.
[20] www.ptatechnologies.com
[21]www.owasp.org

ISSN: 2005-4238 IJAST

Copyright ⓒ 2020 SERSC 1571