Goal Of Security Testing Computer Science Essay

Published:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The goal of security testing is to verify and validate the potentiality of different vulnerabilities. For identified threats ensure that security mechanism deployed during design really mitigate the threats at vulnerable points. This requires checking that during functionality execution the threats to the assets really get mitigated. In this paper we propose a Framework for Security Testing that involves identifying different attacks that are possible by different stakeholders or intruders for each functionality offered by the system. Next we validate that the design decision taken to implement the security requirement associated with that functionality is appropriate to mitigate identified threats and risks on assets involved. Finally a test report template is designed which can be used to review the deployed security mechanism.

Keywords: Security Testing, Vulnerability Point, Vulnerability Nullification, Threat Mitigation

Introduction

The common security measures (security goals) are to secure the assets of the organization. Assets are generally defined as anything that has value to the organisation and needs protection from intruder or accidental detriment by recognised actors of the system. Traditionally it is known as information security and is expressed as confidentiality, integrity and availability of information in an organisation which is called CIA triad [1].

To develop an efficient, cost effective and secure system, security engineering process consisting of activities like i) Security requirements elicitation, analysis & prioritization, specification and management; (ii) Appropriate design structure; (iii) Implementation of all functionalities incorporating design decision; (iv) Testing of security modules must be present. Our previous research [3, 4] presents a framework for secure software development where one should follow the security engineering activities. Then in [5] a design template is presented that guide the security engineer to take appropriate design decisions after eliciting and prioritizing requirements. In continuation to our previous research now our focus is to present a framework for security testing.

Eliciting security requirements using viewpoint oriented approach [3] and prioritizing this security requirement using techniques of CRAMM [10] are discussed in [4]. Once security requirement engineering is through, one needs to take proper design decision for security requirement analogues to conventional design process for functional and nonfunctional requirements. In [11] we have developed a methodology, to analyze available cryptographic techniques for different threats and proposed a design template that identifies the environmental constraints and design constraints. Based on this, appropriate cryptographic techniques may be specified that optimally meets the security requirements. After the design decision, the system needs security testing to avoid all possible loopholes and weaknesses in the system which might result into loss of information in the hands of the stakeholders or outsiders/ intruders of the system.

Recently there are some proposals on model based security testing as in [6] they have combined system modeling languages with modeling languages for security and formalize access control requirements. A brief survey on models that can be used for model based security testing also found in [7]. In [8] they are creating threat traces to test the security concept at the time of testing by matching the execution trace with threat trace created with the help of sequence diagrams. Security testing as presented in [9] is a novel scenario based method that deals with security testing during the design phase. Continuing our earlier work to develop a cost effective security engineering framework which is already proposed in [5], now our aim in this paper is to extend this framework by developing a process for Security Testing.

Our approach involves identifying vulnerable points and mapping identified threats to these vulnerable points to mitigate the identified security threats. In this paper we have proposed a framework for security testing by which we check whether the design decision taken to implement the security requirements is appropriate for the system or not.

The rest of the paper is organized as follows:

In Section 2, Proposed Security Engineering framework is discussed; Section 3 provides Proposed Framework for Security testing; Section 4 provides Implementation Example; finally Section 5 concludes the paper.

Proposed Security Engineering Framework

To design, build and deploy secure systems, one must integrate security into SDLC and adapt current software engineering practices and methodologies to include specific security-related activities. Security-related activities [5] include identifying security requirements, prioritizing & management of security requirements, security design, implementing security mechanisms, security testing. Our proposed framework for Security Engineering Process (SEP) is shown in Figure 1. Now the brief explanation of the different activities performed in different phases of Security Engineering

Process (SEP) are as follows:

Figure 1 Framework for Security Engineering Process

Requirement Engineering - This process is based on well known process of View Point Oriented Requirement Definition [3]. It involves discovering functional requirements. It then identifies the assets and associated threats involved with the functional requirements to finally elicit security requirement such as Privacy, Authentication, Integrity, Non- Repudiation, etc as defined by Firesmith [2]. Then elicited security requirements are analyzed and prioritized.

Design Decisions - In this phase security design decisions are taken which include mapping of security requirements with cryptographic services such as authentication, confidentiality, etc., and then mapping attacks to prioritized threats. After that design decisions are taken which consider environmental constraints such as memory, encryption speed, energy, etc and security design attributes such as throughput, target platform, cost, etc. It then generates Security Design Template (SDT) that guides security engineer to finalize design decisions that specify which cryptographic technique is best suited for particular environment and design constraints.

Implementation - This includes implementing specific techniques that are suggested in the design phase of the Security Engineering Process.

Testing - It involves evaluating the system security and determining the adequacy of cryptographic algorithms chosen during design.

Proposed Security Testing Framework

When the term testing comes, the two sub topics arise. These are verification and validation. Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed in the beginning of that phase. Validation is the process of evaluating a system or component during the development process or at the end of it to determine whether it satisfies the specified requirements. Verification is a static technique in which execution of code is not required hence process of verification is chosen here.

After the security requirements are prioritized, appropriate design decisions are taken and further activities arise. Process for making design decisions is already explained in [5]. After security design implementation security testing comes into picture. Early detection of security related concerns will be cost effective, as it costs more to remove any error during later phases. Security testing is done to test whether security requirements are implemented properly and are protecting the system against all the attacks/ vulnerable points. Our proposed framework for Security testing is shown in Figure 2.

C:\Documents and Settings\Shruti\Desktop\new\frame1.bmp

Figure 2 Security Testing Framework

Step 1: Identify the Attacker and Possible Attacks.

Identification of attacker and the attacks that he can execute is very helpful in assessing the system security.

The process consists of following sub processes:

Identify the Attacker. Identify whether the attacker is an insider or an outsider. Insider means anybody who is an actor related to system directly or indirectly and outsider means an intruder who wants to intentionally attack the system. Identify the attacker for each functionality offered by the system.

Identify the Attacks. Once the attackers are identified, identify the possible attacks executed by attackers to breach the security. This is required to test whether the security mechanism is protecting against the attacks.

Step2: Find Vulnerable Points.

Vulnerable point shows the weakness of the system, from where the attackers can penetrate the system and gain access to the valuables for their use. They may also cause harm to the organizational assets, so identify all these vulnerable points.

The process consists of following sub processes:

Trace the Sequence of Events. To identify the vulnerable points that exist in the system, create the sequence of events that occurs to execute functionality.

Identify the Vulnerable Points with Affected Asset. From the above sequence trace out the vulnerable points of system and the assets that can be affected if an attack occurs at the identified vulnerable point. Asset can be anything that has value to the organization.

Map the Attacks to Vulnerable Points. Map the attacks identified in step 1 to all the identified vulnerable points, so that it can be checked easily whether the system is able to protect these points from identified attacks or not.

Step 3: Security Mechanism Verification & Validation.

Now test whether the cryptographic algorithms identified during the design phase are able to protect the system against various attacks and threats possible due to the presence of vulnerable points for particular functionality

The process consists of following sub processes:

Identifying Attacks for Selected Algorithm. First take the cryptographic algorithm identified during the security design decisions activity of security design engineering and then identify the attacks which are resisted by the algorithm.

Check the Vulnerability Nullification. Map the attacks to the vulnerable points identified with the set of attacks that the given algorithm is able to protect against. Then will measure the level to which the vulnerability points are protected against the attack. If out of N total attacks M are mitigated then will say that the vulnerability point is protected by value M/N. Following this, calculate the Security Vulnerability Index (SVI) using the formula given below:

Security Vulnerability Index (SVI) = (Extent of Vulnerable Points Protected/ Total Vulnerable Points Considered) * 100

Check Threat Mitigation & Effect on Risk. Map the attacks to the corresponding threats and check how many threats are mitigated by selected cryptographic algorithm. If algorithm is able to defend against attack, conclusion can be extracted that threats corresponding to attacks are also mitigated. If the threat is mitigated it means the value of threat rating becomes zero and hence the risk will also become zero as the risk is dependent on threat rating in our risk value computation [4]. Then calculate the Security Risk Index (SRI) using the formula given below:

Security Risk Index (SRI) = (Total Risk Evaluated as Zero / Initially Considered Threats) * 100

Step 4: Generate Test Report Template

Create a test report template that contains all the important information related to the activities. The template will help the developer in deciding further activities as it contains all the security related information of this phase. Template has the fields like Test Case ID, Test Case Name, Attacker and Modeled Attacks, Vulnerable Points, Security Mechanism, Result, Recommendation/ Remark. The sample test template is shown below in Figure 3.

Test Case ID

Unique ID for each Template so that it can be distinguished

Test Case Name

Unique Name must be same as functionality under test

Attacker Type

Type of attacker (insider or outsider)

Modelled Attacks

List of attacks that attacker can execute

Vulnerability Points

List of all points on which attack can occur during the execution of functionality

Security Algorithm Applied

Algorithm that is identified and chosen during design for protection of the system.

Result

The value of Security Vulnerability Index and

Security Risk Index.

Remarks

Any suggestion or recommendation if required

Figure 3 Reference Test Report Template

Case Study of Web Based Banking

In this section, apply the framework to a Web Based Banking system for verifying the security mechanisms as per requirements and constraints. In web based banking system, the actors involved can be Customer, Bank Employee, Bank Database, System Administrator, Maintenance Manager, etc. But the actors/stakeholder that comes under our consideration is only the direct actors such as Customer, Bank Employee and Bank Database. Their functional requirement, non functional requirements, security requirements, attacks, security mechanism and all other details of elicitation and design can be found in [5].

The output of the activities of first phase of security engineering, that is, security requirements engineering is shown in Table 1.

Table 1 Security Requirement Prioritization for Web Based Banking System

Before applying the proposed framework of security testing we have taken the security decision template as shown in Table 2. For detailed process refer [5].

Table 2 Security Design Engineering Web Based Banking System

Now apply our proposed framework on Web Based Banking system. As our framework has four main steps, we progress through all of them one by one.

Step1: Identify the Attacker and Possible attacks.

Identify the Attacker. To identify the attacker, start with the functionality balance enquiry. This functionality can be attacked by an insider or by an outsider or by both. Here we take the attacker as an outsider for explaining the rest of the process.

Identify the Attacks. Now identify the possible attacks. Various possible attacks are:

Replay attack

Man - in - the - Middle Attack

Dictionary Attack

Impersonation Attack

Insertion attack

Step2: Find Vulnerable Points.

Trace the Sequence of Events. The sequence of event for the selected functionality is as follows

Provide login details at customer end (Request)

Verification of login details at server side (Response)

Request for balance enquiry (Request)

Retrieve data from database (Response)

Identify the Vulnerable Points with Affected Assets. From the above sequence trace extract out the vulnerable points of attack and assets that get affected. Result shown in Table 3.

Table 3 Vulnerable points with Assets

S. No

Vulnerable Point Extracted

Assets Involved

1

At the time of Login

User Login Information

2

Verification of Login details

Account Information,

Customer Information

3

Request for Balance

Account Information

4

Retrieving Data

Account Information,

Customer Information

5

During Data Transfer

User Login Information

Account Information,

Customer Information

Map the Attacks to Vulnerable Points. Now map the attacks identified in step 1 to the identified vulnerable points and also map the corresponding threats. As shown in Table 4.

Table 4 Mapping of Threats Involved

S. No.

Vulnerable Point

Attack

Threats Involved

1

At the time of login

Replay Attack, Impersonation Attack

T. Impersonate,

T.Data_Theft

2

Verification of Login Details

Denial of Service Attack

T.Change_Data

3

Request for Balance

Impersonation Attack

T.Impersonate

4

Retrieving Data

Denial of Service Attack

T.Change_Data

5

During Data Transfer

Man - in - the - middle Attack, Dictionary Attack, Insertion Attack

T. Impersonate,

T.Data_Theft

T.Disclose_Data

Step 3: Security Mechanism Verification & Validation.

Identifying Attacks for Selected Algorithm. Take the cryptographic algorithm selected in design phase and identify the attacks protected by the algorithm

Security Mechanism selected: ECDSA

List of Attacks that are resisted by ECDSA are given in Table 5

Table 5 Attacks Resisted by ECDSA

S. No.

Attacks

1

Impersonation

2

Stolen Verifier

3

Smart Card Loss

4

Denial of Service

5

Insertion

Check Vulnerability Nullification. Next check whether the identified attacks are resisted and corresponding vulnerable points are protected by the selected algorithm. Table 6 shows the vulnerability point nullification.

Functionality under Test: Balance Enquiry

Table 6 Nullification of Vulnerable Points

S. No.

Vulnerable Point

Attacks

Nullified or Not

1

At the time of login

Replay Attack, Impersonation Attack

1/2

2

Verification of Login Details

Denial of Service Attack

1/1 = 1

3

Request for Balance

Impersonation Attack

1/1 = 1

4

Retrieving Data

Denial of Service Attack

1/1 = 1

5

During Data Transfer

Man - in - the - middle Attack, Dictionary Attack, Insertion Attack

1/3

So out of five vulnerable points identified, selected algorithm is able to protect three vulnerable points completely, one as half and one as one third.

Security Vulnerability Index = ((1/2 + 1+ 1 +1+1/3)/5) * 100 = 76.67 %

Check Threat Mitigation & Effect on Risk. Now check the effect of attack removal on threat and risk shown in Table 7.

Table 7 Threat Mitigation and Risk Value

S. No.

Vulnerable Point

Attack

Threats

Involved

Threats

Mitigated

Risk Value

1

At the time of login

Impersonation Attack, Replay Attack

T. Impersonate,

T.Data_Theft

T.Impersonate

Y (1)

N (0)

2

Verification of Login Details

Denial of Service Attack

T.Change_Data

T.Change_Data

Y (1)

3

Request for Balance

Impersonation Attack

T.Impersonate

T.Impersonate

Y (1)

4

Retrieving Data

Denial of Service Attack

T.Change_Data

T.Change_Data

Y (1)

5

During Data

Transfer

Man - in - the - middle Attack, Dictionary Attack, Insertion Attack

T. Impersonate,

T.Data_Theft

T.Disclose_Data

T.Data_Theft

N (0)

Y (1)

N (0)

In Table 7 Risk value Y (1) corresponding to a threat represents it is being mitigated by mapped attack and value N (0) means corresponding threat is not mitigated by attack .

In the above table, most of the threats are mitigated as the corresponding attacks are resisted. Therefore, it is validated that most of the risk values become zero, as the threats are mitigated which in turn make threat rating as zero. And in CRAMM [10] if the threat rating is 0 the corresponding risk will be 0.

Security Risk Index = (5/ 8) *100 = 62.5 %

Step 4: Generate Test Report Template.

Test report template is generated to provide a brief overview of the overall process of security testing. Test Template for Balance Enquiry is shown in Figure 4. It contains all the important information related to the activity. The template will help the developer in deciding further activities as it contains all the security related information of this phase.

Test Case Id

TC_01

Test Case Name

Balance Enquiry

Attacker Type

Outsider

Modelled Attacks

Replay attack, Man - in - the - Middle Attack, Dictionary Attack, Impersonation Attack, Insertion attack

Vulnerability Points

At the time of login, Verification of Login Details, Request for Balance, Retrieving Data, During Data Transfer

Security Mechanism Applied

ECDSA

Result

SVI = 76.67 %

SRI = 62.5 %

Remarks

None

Figure 4 Test Template for Balance Enquiry

Conclusion

In this paper framework for security testing is presented that tries to verify all the security mechanism identified during design phase are appropriate for system under study. In existing research proposed, security testing is carried out after system implementation. In [9] researchers are performing security testing during design phase but this is based only on security requirements. In our proposal we first elicit security requirements, and then take effective design decision by choosing the most optimal mechanism to implement security and then perform testing. Security testing phase will be the part of Security Engineering Process. The framework is very helpful in information system development process as here it tries to deal with all security related concerns in early stages. It will help cut down the overall budget of system development as early detection and correction of security concern incur less cost and time. Security testing will become an integral part of security engineering framework and in turn part of the conventional software engineering process.

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.