Paper Title (use style: paper title)

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 4, April 2016

Conducting multi-class security metrics from Enterprise Architect class diagram Osamah S. Mohammed

Dujan B. Taha

Dept. of Software Engineering College of Computer Sc. & Math, University of Mosul. Mosul, Iraq.

Dept. of Software Engineering College of Computer Sc. & Math, University of Mosul. Mosul, Iraq.

A proposed CASE tool has been used to conduct the security metrics from a class diagram designed using Enterprise Architect.

Abstract— Developers often neglect security until the end of developing the software just after coding, and any change in the code with respect to security may lead to change in the software code, this consumes time and cost depending on the software size. Applying security on a software late in its SDLC may result in many security flaws, some of them can involve serious architectural issues. Applying security metrics on design phase can reveal the security level and fix vulnerabilities of a software earlier in the project. In this work, security metrics has been discussed, and conducting these metrics from Enterprise Architect class diagram using a proposed CASE tool.

II.

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. Ram and Alagarsamy proposed a set of security metrics which can measure the method level secuitty through the source code [4]. I. Chowdhury, B. Chan, and M. Zulkernine proposed a code-level security metrics which can be used to suggest the level of security of a code segment [5]. Alshammari proposed a set of security metrics which can assess the security level and reveal security vulnerabilities from a class diagram in design phase of the software development life cycle [6]. Assessing security metrics and fixing security vulnerabilities at design phase will decrease a large amount of security flaws which may appear while coding or after deployment of the software. It measures any potential information flow between objects instantiated the design’s classes [6]. To measure the security metrics for a class diagram, some additional annotations are required to help express information flow between methods and attributes in a given class or to express information flow between the classes through class diagram relations. For this metric, UMLsec and SPRAK’s annotation are used to express this information flow. UMLsec annotations consist of using ‘secrecy’ label as a stereotype for each confidential attribute in a class, and ‘critical’ label as a stereotype for each class containing at least one confidential attribute in a class diagram [7]. SPARK is programming language, which can be defined as “a programming language designed for security-critical code in which the programmer may annotate subroutines with the intended data flow between variables and parameters” [8]. ‘derives from’ block is used as one of the SPARK’s annotations which explains how the flow of values are going from methods and attributes, and show which variable are being accessed or mutated in each method [8]. Using this block will help these metrics to detect information flow between different classes and between methods and attributes.

Keywords-Software Engineering; Security metrics; Enterprise architect; Class diagram; SDLC; Design phase

I.

BACKGROUND

INTRODUCTION

Software that does not exhibit a high quality is easier to hack, and as a consequence, low-quality software can indirectly increase the security risk with all of its attendant costs and problems. To build a secure system, we must focus on quality, and that focus must begin during design [1]. As 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]. Applying security in the design phase of SDLC can reduce a large number of defects and security vulnerabilities before coding. Most security vulnerabilities result from flaws that are introduced in the software during design and development. Therefore, to significantly reduce software vulnerabilities, the overall defect content of software must be reduced. 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 [3]. Metrics help the developers to manage the software as well as the software development process. Metrics can help to detect and analyze the software functionality and correct them during the software development process. In this work, we discuss the security metrics that is applied on design phase of the software life cycle which will help in identifying potential security flaws and how it could help reducing them before start coding the software. This will help reducing the total amount of time and cost spent on managing and applying security later on the project.

56

https://sites.google.com/site/ijcsis/ ISSN 1947-5500


Enterprise Architect (EA) is a UML CASE tool used for analysis and design of a software. It’s used to cover all aspects of software including business, systems modeling and design, [9]. 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. A sample XML file is shown in Figure 1, Class Diagram XML Structure., exported from a class diagram from EA.

C. Critical Classes Extensibility (CCE) This metric is defined as “The ratio of the number of the non-finalized critical classes in a design to the total number of the critical classes in that design” [6]. It can be expressed as: 



Where ECC is the number of critical extensible classes and CC is the total number of critical classes in the design. D. Classified Method Extensibility (CME) This metric is defined as “The ratio of the number of the non-finalized classified methods in a design to the total number of classified methods in that design” [6]. It’s expressed as: 











Where β(CSCk) is the number of classes which may inherit from the critical superclass CSCk, C is the number of classes, and CC is the number of critical classes in a hierarchy located in the design.

B. Critical Classes Coupling (CCC) This metric is defined as “The ratio of the number of all classes’ links with classified attributes to the total number of possible links with classified attributes in a given design” [6]. This metric is expressed as: 



F. Critical Superclasses Inheritance (CSI) This metric is defined as “The ratio of the sum of classes which inherit from each critical superclasses to the number of possible inheritances from all critical classes in a class hierarchy” [6]. This metric is expressed as:

Where CP is the number of composite-part critical classes in design D and CC is the total number of critical classes in the same design.





Where CSC is the number of critical superclasses in design D and CC is the number of critical classes in a hierarchy located in the same design.

A. Composite-Part Critical Classes (CPCC): This metric is defined as “The ratio of the number of critical composite-part classes to the total number of critical classes in a design” [6]. This metric is expressed as: 



E. Critical Superclasses Proportion (CSP) This metric can be defined as “The ratio of the number of critical Superclasses to the total number of critical classes in an inheritance hierarchy” [6]. Its equation is as follow:

SECURIY METRICS

Security metrics for multi-class design aim to assess the information-flow security of an object-oriented design. It uses five properties of the design of an object-oriented program which is: composition, coupling, extensibility, inheritance, and design size. These metrics measure potential information flow between objects derived from its class diagram according to security design principles of reducing attack surface and the least privilege [6].





Where ECM is the number of extensible classified methods in design D and CM is the number of classified methods in the same design.

Figure 1, Class Diagram XML Structure. III.



G. Classified Methods Inheritance (CMI) This metric is defined as “The ratio of the number of classified methods which can be inherited in a hierarchy to the total number of classified methods in that hierarchy” [6]. It’s expressed as:



Where α(CAj) is the number of classes which may interact with classified attribute CAj in design D, C is the number of classes, and CA is the total number of classified attributes in the same design.



57







Where MI is the number of classified methods which could be inherited in the hierarchy, and CM is the number of classified methods in the same hierarchy.

sault of the password and the database connection. The session class is concerned about managing each user’s session which has confidential data in it such as sessionId, sessionHash and mysql.

H. Classified Attributes Inheritance (CAI) This metric is defined as “The ratio of the number of classified attributes which can be inherited in a hierarchy to the total number of classified attributes in that hierarchy” [6]. It’s expressed as: 



Store Data



Where AI is the number of classified attributes which could be inherited in the hierarchy, and CA is the number of classified attributes in the same hierarchy. I.

Critical Design Proportion (CDP) This metric measures the impact of the size of a certain design size. Its defined as “The ratio of the number of critical classes to the total number of classes on a design” [6]. It’s expressed as: 



User Login

View Stored Information

Calculate Security Metrics

Register

Upload .XML file

.XML File Parser

Figure 2, Proposed tool Architecture.



Where C is the number of classes and CC is the number of classes in the same design. 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 Figure 2. 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 as shown in Figure 3 and Figure 4. A user can design a class diagram with different variation of a class, 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. V.

Figure 3, Proposed tool Main Page.

Figure 4, Specific Design Results.

CASE STUDY

In this case study, different variation of a class diagram has been designed for a webapp user information system. As shown in Figure 6, this system is responsible for managing the access and storing information of a user to the system. A user can log-in the system as a regular user or as an admin. Each user has a confidential data in its class such as the password, Figure 5, Upload Form. 58



class Diagram OO D 1

class Diagram OO D 4 Name

«Critical» User +

+ +

+

+

userName: string name: Name email: string session: Session

-

firstName: int lastName: int

+

setName(string, string) [ derive firstName, lastName from _firstName, _lastName ] getName(): string [ derives getName() from firstName, lastName ]

+

«secrecy» passwordHash: string sault: string mysql: MySQL

User

+ +

+

User(string, string, string, string): void [ derives userName, firstname, lastname, email, from _userName, _firstname, _lastname, _email, mysql ] getUsername(): string [ derives getUsernam() from userName ] checkPasswordEqualTo(string): bool [ derives checkPasswordEqualTo from _inputPass, mysql ] getName(): string [ derives getName() from firstname, lastname ] getEmail(): string [ derives getName() from email ] query(string): void [ derives query() from mysqli, _query]

Admin +

title: string privilege: string = FULL

+

setTitle(string) [ derives title from _title ] getTitle(): string [ derives getTitle() from title ]

+

+ + + +

«Critical» Person

Admin

«Critical» Session

+

userName: string firstname: string email: string lastname: string mysql: mysqli

+

User(string, string, Name, string, string): void [ derives userName, passwordHash, name, email, sault from _userName, _passhash, _name, _email, _sault, mysql.connection ] getUsername(): string [ derives getUsernam() from userName ] checkPasswordEqualTo(string): bool [ derives checkPasswordEqualTo from sault, passwordHash, _inputPass ] getName(): string [ derives getName() from name.firstName, name.lastName ] getEmail(): string [ derives getName() from email ]

«Critical» MySQL

-

-

+

title: string privilege: string = full

«secrecy» - connection: mysqli

+

+

+


query(string): string [ derives query() from connection ]

{leaf} + -

«secrecy» sessionId: string sessionHash: string mysql: MySQL

-

newSession(time): void [ derives sessionId, sessionHash from time ] getSessionHash(): string [ derives getSessionHash() from sessionHash ] retriveSession(): void [ derive sessionHash, sessionId from mysql.connection ]

+ +

privilege: string = stricted «secrecy» address: string telephone: string setAddress(string): void [ derives address from _address ] getAddress(): string [ derives getAddress() from address ] getTele(): string [ derives getTele() from telephone ] setTele(string): void [ derives telephone from _tele ] getDetails(): string[] [ derives getDetails() from address, telephone ] setDetails(string, string): void [ derives address, telephone from _address, _tele ]

Figure 8, Webapp User Information System Design 4.

Figure 6, Webapp User Information System Design 1. class Diagram OO D 2 «Critical» Session

Name -

firstName: int lastName: int

+

setName(string, string) [ derive firstName, lastName from _firstName, _lastName ] getName(): string [ derives getName() from firstName, lastName ]

+

+

+

+ +

+

+

+

userName: string name: Name email: string session: Session «secrecy» passwordHash: string sault: string mysql: MySQL User(string, string, Name, string, string): void [ derives userName, passwordHash, name, email, sault from _userName, _passhash, _name, _email, _sault, mysql.connection ] getUsername(): string [ derives getUsernam() from userName ] checkPasswordEqualTo(string): bool [ derives checkPasswordEqualTo from sault, passwordHash, _inputPass ] getName(): string [ derives getName() from name.firstName, name.lastName ] getEmail(): string [ derives getName() from email ]

-

+

userName: string firstname: string email: string lastname: string «secrecy» passwordHash: string sault: string mysql: MySQL

+

User(string, string, string, string, string, string): void [ derives userName, passwordHash, firstname, lastname, email, sault from _userName, _passhash, _firstname, _lastname, _email, _sault, mysql.connection ] getUsername(): string [ derives getUsernam() from userName ] checkPasswordEqualTo(string): bool [ derives checkPasswordEqualTo from sault, passwordHash, _inputPass ] getName(): string [ derives getName() from firstname, lastname ] getEmail(): string [ derives getName() from email ]

+

«secrecy» - connection: mysqli

+

query(string): string [ derives query() from connection ]

+ +

«Critical» Person + -

-

+


+

+


+

+

-

«Critical» MySQL

-

Admin

«Critical» User

newSession(time): void [ derives sessionId, sessionHash from time ] getSessionHash(): string [ derives getSessionHash() from sessionHash ] retriveSession(): void [ derive sessionHash, sessionId from mysql.connection ]

+ «Critical» User

class Diagram OO D 3

«secrecy» - sessionId: string - sessionHash: string - mysql: MySQL

«Critical» MySQL

+

«secrecy» connection: mysqli query(string): string [ derives query() from connection ]

privilege: string = stricted «secrecy» address: string telephone: string

«Critical» Person

Admin

setAddress(string): void [ derives address from _address ] getAddress(): string [ derives getAddress() from address ] getTele(): string [ derives getTele() from telephone ] setTele(string): void [ derives telephone from _tele ] getDetails(): string[] [ derives getDetails() from address, telephone ] setDetails(string, string): void [ derives address, telephone from _address, _tele ]

+


+


+

+ + +

Figure 7, Webapp User Information System Design 2

privilege: string = stricted «secrecy» address: string telephone: string setAddress(string): void [ derives address from _address ] getAddress(): string [ derives getAddress() from address ] getTele(): string [ derives getTele() from telephone ] setTele(string): void [ derives telephone from _tele ] getDetails(): string[] [ derives getDetails() from address, telephone ] setDetails(string, string): void [ derives address, telephone from _address, _tele ]

Figure 9, Webapp User Information System Design 3.

59



Table 1, Design Security Metrics Results. Metric Name CPCC CCC CCE CME CSP CSI CMI CAI CDP

Design 1

Design 2

Design 3

Design 4

0.67 0.071 1 1 0 0 0 0 0.6

0.75 0.044 1 1 0.5 0.5 0.25 0.6 0.67

1 0.056 1 1 0.5 0.5 0.25 0.6 0.75

1 0 0 0 0 0 0 0 0.33

metric (CMI) and classified attributes inheritance metric (CAI) since those metrics depend on critical superclasses to measure the security of an inheritance and both design 1 and design 2 has no critical superclasses on them. Critical design proportion metric (CDP) measures the size of a design with respect to security and design 4 is the most secure design according to this metric since it has less critical classes than the total number of classes in that design. After calculating the metrics result, design 4 can be considered as the most secure design since most of the results have the lowest value compared to other designs results except CPCC metric, which is considered as the most insecure class for composition because it doesn’t use composite part class to store its classified attributes.

A different variation of the same diagram has been designed for calculating security metrics and determine which design has the most security. Figure 7 shows the User class that has two subclasses which is Admin and Person. Person class is critical since it has confidential attributes (address, telephone). Figure 8 shows the diagram which is similar to Figure 7, but it doesn’t have Session class, and Figure 9 shows the diagram with only User class along with its subclasses (Admin, Person). Security metrics will help choosing the best diagram with regards to security. VI.

RESULTS AND CONCLUSION

Results shown in Table 1 are conducted using the proposed CASE tool. The result shows the security metrics from designs shown in Figures 6-9 where the lower value of the metric result is considered more secure design. Regarding composite part critical class metric (CPCC), Design 1 is the most secure one since it uses the composite part class to store classified data rather than storing them in the main class which can be exposed to the public. Critical classes coupling metric (CCC) used to minimize the use of classified attributes through coupling. Design 4 is the most secure design because it doesn’t use any coupling between their classes. With respect to critical class extensibility metric (CCE), design 4 is the most secure design because the critical class Person is labeled as a leaf, which means no class can extend from this critical class. In consequence, it’s the most secure class according to this metric. In critical methods extensibility metric (CME), design 4 is the most secure design because its classified methods are considered ‘final’ and it can’t be extensible because the class is labeled as a leaf which affect the class and its attributes and methods. Critical superclasses proportion metric (CSP) measures superclasses ratio in a hierarchy, design 1 and design 4 are considered secure designs because they don’t have a superclass labeled as a critical class. The lower number of the critical superclasses classes in a design would minimize the value of this metric which result a more secure design. According to critical superclasses inheritance metric (CSI) result, design 1 and design 4 are the most secure designs since they both doesn’t have a critical superclass. Same result obtained when conducting classified methods inheritance

Figure 10, Results Comparison. Security flaws can be expensive especially for large software products, and fixing these flaws is hard may take long time, and it may increase the total cost of project. The use of these security metrics in earlier phase of the software development life cycle can decrease a large amount of security flaws and vulnerabilities which may be discovered later in coding or after deployment. One way of using this metrics is designing software by several developers, compare and promote the best design according to the metrics results. One developer can use these metrics to avoid some design flaws and make the design more secure according to the results of these metrics. VII. REFERENCES [1] [2]

[3]

[4]

[5]

60

Roger S. Pressman, Software Engineering A practitioner’s approach 7th Edition. 2010. 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-securesoftware.html. N. R. Mead and G. Mcgraw, “A portal for software security,” IEEE Secur. Priv., vol. 3, no. 4, pp. 75–79, 2005. S. R. K. T, “A Method Level Security Metrics Suite for Java Programs,” vol. 3, no. 6, pp. 1991–1996, 2012. I. Chowdhury, B. Chan, and M. Zulkernine, “Security metrics for source code structures,” Proc. fourth Int.



[6]

[7]

[8]

[9]

Meagher, “Enterprise Architect User Guide,” p. 2888, 2012.

Work. Softw. Eng. Secur. Syst., no. October, pp. 57– 64, 2008. B. Alshammari, C. Fidge, and D. Corney, “Security metrics for object-oriented designs,” Proc. Aust. Softw. Eng. Conf. ASWEC, pp. 55–64, 2010. J. Jürjens, “UMLsec: Extending UML for secure systems development,” Proc. 5th Int. Conf. Unified Model. Lang., pp. 412–425, 2002. J. Barnes, High Integrity Software: The SPARK Approach to Safety and Security. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003. G. Spark, D. O ’bryan, S. Mcneilly, N. Capey, J. Redfern, B. Maxwell, V. Kumar, H. Britten, and S.

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.

61
