Conducting Security Metrics for Object-Oriented Class Design

Conducting Security Metrics for Object-Oriented
Class Design
Dujan B. Taha
Dept. of Software Engineering
College of Computer Sc. & Math, University of Mosul.
Mosul, Iraq.
Osamah S. Mohammed
Dept. of Software Engineering
College of Computer Sc. & Math, University of Mosul.
Mosul, Iraq.
Abstract—Security issues often neglected until coding step in
software development process, and changing in this step leads to
maximize time and cost consuming depending on the size of the
project. Applying security on design phase can fix vulnerabilities
of the software earlier in the project and minimize the time and
cost of the software by identifying security flaws earlier in the
software life cycle. This work concerns with discussing security
metrics for object oriented class design, and implementing these
metrics from Enterprise Architect class diagram using a
proposed CASE tool.
Keywords-Software Engineering; Security metrics; Class
design; SDLC; Design phase
I. INTRODUCTION
The increasing number of attacks has forced the
organizations to integrate the characteristic of security during
development process rather than considering during post
development phase. It is estimated that 90 percent of reported
security incidents result from exploits against defects in the
design or code of software [1]. Software engineering on the
other hand often take a long time to process and to complete,
and any change in the software may lead to changes on early
phases of the process which may take a lot of time and
increases the costs.
Assessing security earlier in the software life cycle will
minimize the time and cost of the software by identifying
security flaws at design phase of software life cycle.
Willoughby said “You must think about security, reliability,
availability, dependability at the beginning, in the design,
architecture, test and coding phases, all through the software
life cycle” [2]. Security must be designed and built into a
system from the ground up. According to the CERT
Coordination Center (CERT/CC) of the SEI, more than 90% of
reported security incidents are the result of exploits against
defects in the design or development flaws. Metrics can help to
detect and analyze the software functionality and correct them
during the software development process[3].
In this work, we discuss the security metrics for object-
oriented class that is applied on design phase of the software
life cycle. Identifying security flaws at this phase could help
reducing them before software coding begins. If security is
applied in design phase, it could minimize the vulnerabilities
that can appear in coding or after releasing the software.
A proposed CASE tool has been used to conduct the
security metrics from a class diagram designed using Enterprise
Architect.
II. BACKGROUND
Security metrics are being widely used to measure the
security level and try to fix any vulnerabilities, but most of
these metrics were used at source coding which is considered
late in the SDLC [4]. Chowdhury, Chan, Zulkernine[5],
proposed a set of code-level security metrics which can assess a
security level of a source code segment, and it can provide
guidelines to improve the security level of that source code.
Wang [1] proposed a new approach to define software security
metrics based on vulnerabilities included in the software
systems and their impacts on software quality. Kumar and
Alagarsamy[6] proposed a set of security metrics to identify the
most vulnerable parts of a Java source code at the level of
methods. Gandhi et. Al [7] proposed a CASE tool that help the
developer or the designer to calculate specific class security
metrics from a class diagram designed in Rational Rose, and
the tool was written in Java. Agrawal and Khan [8] proposed a
new security metrics development framework which can in
theory assess the security metrics of a software earlier in the
software development life cycle, its security metrics collection
consist of various type of metrics which may require number of
software build or versions for it to be calculated. Smriti Jain
and Maya Ingle[9] suggested a set of metrics based on security
issues of software development from requirement phase to
documentation phase. Saarela [10] measured software security
from design phase, he reviewed the security metrics for
assurance. His study reveals that these security metrics
proposed by Alshammari were succeeded in discovering the
current status of software security metrics and establishing the
level of current understanding of secure software.
Security metrics was defined based on the quality
properties specified by Bansiya[11]. The Metrics has a scale to
fit with the range 0 to 1, with lower value indicating that the
program’s design is more secure. To apply these metrics to a
given class, the class should be annotated with UMLsec and
SPARK’s annotations as shown in Error! Reference source
not found..
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 15, No. 8, August 2017
20 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

Figure 1, Class Design Structure.
Enterprise Architect (EA) is a UML CASE tool used for
analysis and design of software. It’s used to cover all aspects
of software including business, systems modeling and design,
[12]. Designing automated security metrics tool is relatively
easy, because EA can export a diagram as an (.XML) file
which can be easily interpreted for use of automated
processing on that diagram. The XML file contains all the
details needed to elicit and calculate security metrics using
XML file parser.
III. SECURIY METRICS
A metric is a value that used to study some aspect of a
project. Sometimes a metric is the same as an attribute. After
calculating the metrics, study them to see if any of them are
good indicators of the project’s future. Two thing can be done
with these indicators; first, it can be used to predict the future
of the current project; the second thing can be done with
indicators is making strategy improvements for future
projects[13].
Some terminologies associated with security metrics are
defined as follows [14][15] and shown in
Figure II:
 Classified Attribute: An attribute which is defined in
UMLsec as ‘secrecy’.
 Instance Attribute: An attribute whose value is stored
separately by each instance of a class.
 Class Attribute: An attribute whose value is shared by
all instances of that class.
 Classified Method: A method which reads or writes
at least one classified attribute.
 Mutator: A method that sets the value of an attribute.
 Accessor: A method that reads the value of an
attribute.
 Classified Mutator: A method that sets the value of at
least one classified attribute.
 Classified Accessor: A method that reads the value of
at least one classified attribute.
Figure II, Metric Terminology
Security metrics aim to measure the security metrics from
two perspective of information flow: least privilege, and
reducing attack surface.
The principle of least privilege states that an object should
be given only those privileges that it needs in order to
complete its task [11]. The main advantage of this principle is
to minimize the interaction between privileged programs. In
class design, this means the method do the least possible
actions is the most secure. In this case, the class whose
methods interact with the least possible classified attributes
would be a secure design with respect to this principle.
The principle of reduce attack surface aims to limit the
access to secret data. In class design, a class should have the
least possible accessible methods each with the least number
of parameters which can affect classified attributes needed for
necessary tasks.
Security metrics are divided into two groups: One
concerned with measuring accessibility level of attributes and
methods; and another concerned with measuring the
interaction level of methods attributes [14].
3.1 Security Accessibility Metrics
These metrics aim to measure the accessibility level of
attributes and methods in a class from an access modifier
perspective. These metrics are as follow:
A. Classified Instance Data Accessibility (CIDA)
These metric measures the direct accessibility of classified
instance attributes of a particular class. It is defined as “The
ratio of the number of classified instance public attributes to
the number of classified attributes in a class”. Higher values
indicate higher accessibility to these classified attributes and
hence a larger ‘attack surface’.
«secrecy»
Class1
«secrecy»
- id: int
# getName: string
+ getId(int): void
+ setId(): void
Classified Attributes
Instance Attribute
Class Attribute
Classified Methods
Mutator Method
Accessor Method Classified Mutator
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

Consider a set of classified attributes in a class C as CA =
{ca1, ..., can} and its classified instance public attributes CIPA
= {cipa1, ..., cipan} such that CIPA ⊆ CA.
B. Classified Class Data Accessibility (CCDA)
This metric measures the direct accessibility of classified
class attributes of a particular class. It is defined as follows:
“The ratio of the number of classified class public attributes to
the number of classified attributes in a class”. The result
shows the ratio of classified class attributes which are directly
accessible from outside its class. Higher values mean that
confidential data of that class has a higher chance of being
exposed to unauthorized parties. The lower the value of this
metric enforce the security principle of reducing the attack
surface.
Consider a set of classified attributes in a class C as CA =
{ca1, ..., can} and its classified class public attributes CCPA =
{ccpa1, ..., ccpan} such that CCPA ⊆ CA.
(2)
C. Classified Operation Accessibility (COA)
This metric measuresthe ratio of the accessibility of public
classified methods of a particular class. It is defined as: “The
ratio of the number of classified public methods to the number
of classified methods in a class”. It aims to protect the internal
operations of a class which interact with classified attributes
from direct access. Lower values of this metric would reduce
potential information flow of classified data which could be
caused by calling public methods. This metric measures the
potential attack surface size exposed by classified methods.
Consider a set of classified methods in a class C as CM =
{cm1, ..., cmn} and its classified class public methods CCPM =
{ccpm1, ..., ccpmn} such that CCPM ⊆ CM.
(3)
3.2 Security Interaction Metrics
These metrics measure the impact of class interaction
between methods and attributes in respect of security
principles. These metrics are as follow.
A. Classified Mutator Attribute Interactions (CMAI)
This metric measures the interactions of mutators with
classified attributes in a class. It is defined as: “The ratio of the
number of mutators which may interact with classified
attributes to the possible maximum number of mutators which
could interact with classified attributes”. Higher interaction
means stronger cohesion between mutators and classified
attributes within a given class. With regard to the security
principles, a lower value allows fewer privileges over
confidential data and therefore adheres to the least privilege
principle.
Consider a set of mutator methods in class C as MMi, i ∈{1,
..., mm} and the classified attributes CAj, j ∈ {1, ..., ca}. Let’s
α(CAj) be the number of mutator methods which may access
classified attribute CAj. Then, the CMAI for class C can be
calculated as follow:
(4)
B. Classified Accessor Attribute Interactions (CAAI)
This metric measures the interactions of accessors with
classified attributes in a class. It is defined as: “The ratio of the
number of accessors which may interact with classified
attributes to the possible maximum number of accessors which
could have access to classified attributes”. Higher interaction
means stronger cohesion between accessors and classified
attributes within a given class. Weak cohesion indicates fewer
privileges are given to accessors over classified attributes.
Consider a set of accessor methods in class C as AMi, i ∈
{1, ..., am} and the classified attributes CAj, j ∈ {1, ..., ca}.
Let’s β(CAj) be the number of accessor methods which may
access classified attribute CAj. Then, the CAAI for class C can
be calculated as follow:
(5)
C. Classified Attributes Interaction Weight (CAIW)
This metric is defined to measure the interactions with
classified attributes by all methods of a given class. We define
this metric as: “The ratio of the number of all methods which
may interact with classified attributes to the total number of all
methods which could have access to all attributes”. The higher
the value of this metric for a given class the more privileges
are given to this class’ methods over classified attributes, and
therefore the less that class adheres to the security principle of
least privilege.
Consider a set of attributes in class C as Ai, i ∈ {1, ..., a}
and a set of classified attributes CAj, j ∈ {1, ..., ca}. Let’s
γ(CAj) be the number of methods which access classified
attribute CAj. Let δ(Ai) be the number of methods which may
access attributes Aj. Then, CAIW can be computed as:
(6)
(1)
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

D. Classified Methods Weight (CMW)
This metric is defined to measure the weight of methods in
a class which potentially interact with any classified attributes
in a particular class. It is defined as: “The ratio of the number
of classified methods to the total number of methods in a
given class”. Higher values of this metric indicate more
classified operations are offered by the given class. This leads
to a higher chance of information flow of classified data by
calling the class’s methods and violations of the security
principle of reducing the attack surface.
Consider a set of methods in class C as M = {m1, …, mn}
and the classified methods as CM = {cm1, …, cmn} such that
CM ⊆ M. CMW can be calculated as:
(7)
IV. PROPOSED CASE TOOL
The proposed tool is a webapp CASE tool used to calculate
specific-class and multi-class security metrics, which can be
accessed with any device which contains an internet
connection and a web browser. Users can register and access
the functionalities of this tool, such as: uploading an XML file
exported from EA to process and save the results into the
database; and viewing the results of the diagrams. This tool
can process a class diagram exported from EA as an XML file,
and the class diagram has to be annotated with UMLsec and
SPARK’s annotations. The architecture of this tool is shown in
Error! Reference source not found.. New users can register
and login as a regular user, the user can view the last uploaded
diagrams metrics which consist of design security metrics and
specific class metrics. The tool will help the user to calculate,
view, and easily compare these classes to select the most
secure class. The use of this tool can reduce the total cost of a
project by reducing the number of vulnerabilities discovered in
the design phase, which reduces a large number of potential
security vulnerabilities and flaws that may be discovered late
in the project.[4].
Figure 3, Proposed tool Architecture.
V. CASE STUDY
The following case study illustrate security metrics for a
single class using the proposed webapp CASE tool to elicit the
design data from XMI file exported from Enterprise Architect
diagram. The diagram must include UMLsec and SPARK’s
annotations in each class to help the application calculate
security metrics.
This case study will consist of different designs of a single
class which has a confidential information. The class diagram
shows a different designs of a User class. This User class
holds information of a user in the system. Its attributes consist
of userFullName which holds the user full name, userEmail
holds the user personal email address, userPassword holds the
user own password that are used to enter the system, and
userTelephone holds the user personal telephone number. The
class’s methods are used to access or mutate its attributes.
User email, password, and telephone number are meant to be
secret. Each classified class are labeled “Critical” in its
stereotype field, all confidential attributes are labeled
“secrecy” in its stereotype field and all method’s behavioral
are written in its behavior field.
As shown below, a few designs of the class User have been
made to study the result of it in respect to security. Figure (a)
shows the class User_1 which has all of its attributes and their
methods set as public ‘+’.
Figure (b) shows the class User_2 has its attributes
accessibility changed to private ‘-’ unlike User_1 which is
public.
Figure (c) shows User_3 class simillar to User_2 but it’s
methods are declaired private and added two extra methods to
access and mutate the class attributes through its methods.
Figure (d) shows User_4 class, similar to User_3 but it has
only two methods to access and mutate the attributes in the
class and the rest of the methods was deleted to make the
access/mutate point to the class through one method only.
User_5 class is shown in Figure (e), it has only one
confidential attribute which has its own mutator and accessor
method. The rest of the attributes has their accessor and
mutator method.
VI. RESULTS AND CONCLUSION
Table 1 shows results after applying
security metrics. The lower value of each
metric are considered more secure.
Figure shows results on a radio chart to make it easier to
compare between different classes.
User_1 class is determined as most insecure class regarding
classified instance data accessibility metric (CIDA) since it’s
classified attributes are all declared as public, the other classes
has the same level of security because they have their
classified attributes declared as private. Regarding classified
class data attributes metric (CCDA), all classes have the same
results since they don’t have any classified class data
attributes.
Class User_3 is considered the most secure regarding to
classified operation accessibility (COA) since it has only two
out of ten classified methods declared as public, the rest are
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

declared as private. Other class designs are considered
insecure because all classified methods are declared as public.
In terms of classified mutator attribute interactions (CMAI),
class User_1 has the most secure design since it has less
connections between classified mutator methods and classified
attributes and the classified mutator methods interact with less
number of classified attributes. Sam results regarding
classified accessor attribute interactions (CAAI), User_1 is the
most secure design because it has the least interaction of
classified attributes with classified accessor methods.
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

(a) User 1 Class.
(c) User 3 Class.
(a) User 1 Class.
(b) User 2 Class.
«Critical»
User_4
- userFullName: string
«secrecy»
- userEmail: string
- userPassword: string
- userTelephone: string
+ setDetails(string, string, string, string): void
[ derives userFullName, userEmail, userTelephone, userPassword from
_fullName, _email, _tele, _pass ]
+ getDetails(): string[]
[ derives getDetails() from userFullName, userEmail, userTelephone,
userPassword ]
(d) User 4 Class.
«Critical»
User_5
- userEmail: string
«secrecy»
+ setDetails(string, string): void
[ derives userFullName, userEmail from _fullName,
_email ]
+ getDetails(): string []
[ derives getDetails() from userFullName, userEmail ]
+ setPassword(string): void
[ derives userPassword from _pass ]
+ getPassword(): string
[ derives getPassword() from userPassword ]
(e) User 5 Class.
«Critical»
User_2
«secrecy»
- userEmail: string
+ SetName(string): void
[ derives userFullName from _userName ]
+ getName(): string
[ derives getName() from userFullName ]
+ setContact(string, string): void
[ derives userEmail, userTelephone from _email, _tele ]
+ getContact(): string[]
[ derives getContact() from userEmail, userTelephone ]
+ setEmail(string): void
[ derives userEmail from _email ]
+ getEmail(): string
[ derives getEmail() from userEmail ]
+ setTele(string): void
[ derives userTelephone from _tele ]
+ getTele(): string
[ derives getTele() from userTelephone ]
«Critical»
User_3
«secrecy»
- userEmail: string
- SetName(string): void
- getName(): string
- setContact(string, string): void
[ derives userEmail, userTelephone from _email, _tele ]
- getContact(): string[]
[ derives getContact() from userEmail, userTelephone ]
- setEmail(string): void
- getEmail(): string
- setPassword(string): void
- getPassword(): string
- setTele(string): void
- getTele(): string
+ setDetails(string, string, string, string): void
[ derives userFullName, userEmail, userPassword, userTelephone from _userName,
_email, _pass, _tele ]
+ getDetails(): string[]
[ derives getDetails() from userFullName, userEmail, userPassword, userTelephone ]
«Critical»
User_1
+ userFullName: string
«secrecy»
+ userEmail: string
+ userPassword: string
+ userTelephone: string
+ SetName(string): void
+ getName(): string
+ setEmail(string): void
+ getEmail(): string
+ setTele(string): void
+ getTele(): string
Figure 4, User Classes Samples
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

(a) User 1 Metric Results. (b) User 2 Metric Results
(c) User 3 Metric Results. (d) User 4 Metric Results.
(e) User 5 Metric Results.
Figure 5, Class Security Metrics Radio Chart Results.
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

User_5 class design is considered the most secure design
regarding classified attribute interaction weight (CAIW) since
its classified attributes has less interaction with its methods.
User_5 class design is considered a secure design regarding
classified methods weight (CMW) since the number of
classified methods is less than the total number of methods in
this class.
After calculating the results of these metrics, we can see
that User_5 class is the most secure class compared to other
classes since it has the most overall low value results. User_2
and User_4 can be considered as insecure designs since they
have high value results compared to other classes.
VII. REFERENCES
[1] J. A. Wang, H. Wang, M. Guo, and M. Xia, “Security
metrics for software systems,” ACM Southeast Reg.
Conf., p. 1, 2009.
[2] M. Willoughby, “Q&A: Quality software means more
secure software,” 2005. [Online]. Available:
http://www.computerworld.com/article/2563708/secur
ity0/q-a--quality-software-means-more-secure-
software.html.
[3] N. R. Mead and G. Mcgraw, “A portal for software
security,” IEEE Secur. Priv., vol. 3, no. 4, pp. 75–79,
2005.
[4] O. S. Mohammed and D. B. Taha, “Conducting multi-
class security metrics from Enterprise Architect class
diagram,” Int. J. Comput. Sci. Inf. Secur., vol. 14, no.
4, pp. 56–61, 2016.
[5] I. Chowdhury, B. Chan, and M. Zulkernine, “Security
metrics for source code structures,” Proc. fourth Int.
Work. Softw. Eng. Secur. Syst., no. October, pp. 57–
64, 2008.
[6] S. R. K. T, “A Method Level Security Metrics Suite
for Java Programs,” Int. J. Comput. Technol. Appl.,
vol. 3, no. 6, pp. 1991–1996, 2012.
[7] S. H. Gandhi, D. R. Anekar, M. A. Shaikh, and A. A.
Salunkhe, “Security Metric for Object Oriented Class
Design- Result Analysis,” Int. J. Innov.
Technol. Explor. Eng., vol. 2, no. 6, pp. 139–144,2013.
[8] a. Agrawal, “Software Security Metric Development
Framework (An Early Stage Approach),” Am. J. Softw.
Eng. Appl., vol. 2, no. 6, p. 150, 2013.
[9] S. Jain and M. Ingle, “Security Metrics and Software
Development Progression,” J. Eng. Res. Appl., vol. 4,
no. 5, pp. 161–167, 2014.
[10] M. Saarela, “Measuring software security from the
design of software Department of IT,” 2016.
[11] J. Bansiya and C. G. Davis, “A Hierarchical Model for
Object-Oriented Design Quality Assessment,” IEEE
Trans. Softw. Eng., vol. 28, no. 1, pp. 4–17, 2002.
[12] G. Spark, D. O ’bryan, S. Mcneilly, N. Capey, J.
Redfern, B. Maxwell, V. Kumar, H. Britten, and S.
Meagher, “Enterprise Architect User Guide,” p. 2888,
2012.
[13] R. Stephens, Beginning Software Engineering, vol. 1.
Wrox Press Ltd., 2015.
[14] B. Alshammari, C. Fidgeand, and D. Corney, “Security
metrics for object-oriented class designs,” Proc. - Int.
Conf. Qual. Softw., pp. 11–20, 2009.
[15] B. Alshammari, C. Fidge, and D. Corney, “Security
metrics for object-oriented designs,” Proc. Aust.
Softw. Eng. Conf. ASWEC, pp. 55–64, 2010.
AUTHORS PROFILE
Dr. Dujan B. Taha (Assistant Prof.) is currently a lecturer at Mosul University,
College of Computer Science and Mathematics / Software Engineering
Department. She received B.Sc. degree in Computer Science /
University of Mosul in 1991, M.Sc. degree / University of Mosul in
1996 and Ph.D. degree / University of Mosul in 2005. Her research
interests are in information and network security, Software Engineering,
Image processing and pattern recognition.
Osama S. Mohammed is currently an M.Sc. student in Software Engineering
Department / Collage of Computer Science and Mathematics /
University of Mosul.
Table 1, Class Security Metrics Results
Class Name CIDA CCDA COA CMAI CAAI CAIW CMW
User_1 1 0 1 0.25 0.25 0.75 0.75
User_2 0 0 1 0.33 0.33 0.83 0.8
User_3 0 0 0.2 0.44 0.44 0.8 0.83
User_4 0 0 1 1 1 0.75 1
User_5 0 0 1 0.5 0.5 0.33 0.5
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

Conducting Security Metrics for Object-Oriented Class Design

More Related Content

What's hot (19)

Similar to Conducting Security Metrics for Object-Oriented Class Design (20)

Recently uploaded (20)

Conducting Security Metrics for Object-Oriented Class Design