Goal Of Security Testing Computer Science Essay

The end of security testing is to verify and formalize the potency of different exposures. For identified menaces guarantee that security mechanism deployed during design truly extenuate the menaces at vulnerable points. This requires look intoing that during functionality execution the menaces to the assets truly acquire mitigated. In this paper we propose a Model for Security Testing that involves placing different onslaughts that are possible by different stakeholders or interlopers for each functionality offered by the system. Next we validate that the design determination taken to implement the security demand associated with that functionality is appropriate to extenuate identified menaces and hazards on assets involved. Finally a trial study templet is designed which can be used to reexamine the deployed security mechanism.

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

Introduction

The common security steps ( security ends ) are to procure the assets of the organisation. Assetss are by and large defined as anything that has value to the administration and needs protection from interloper or inadvertent hurt by recognized histrions of the system. Traditionally it is known as information security and is expressed as confidentiality, unity and handiness of information in an administration which is called CIA three [ 1 ] .

To develop an efficient, cost effectual and unafraid system, security technology procedure dwelling of activities like I ) Security demands evocation, analysis & A ; prioritization, specification and direction ; ( two ) Appropriate design construction ; ( three ) Execution of all functionalities integrating design determination ; ( four ) Testing of security faculties must be present. Our old research [ 3, 4 ] nowadayss a model for secure package development where 1 should follow the security technology activities. Then in [ 5 ] a design templet is presented that guide the security applied scientist to take appropriate design determinations after arousing and prioritising demands. In continuance to our old research now our focal point is to show a model for security testing.

Arousing security demands utilizing point of view oriented attack [ 3 ] and prioritising this security demand utilizing techniques of CRAMM [ 10 ] are discussed in [ 4 ] . Once security demand technology is through, one needs to take proper design determination for security demand parallels to conventional design procedure for functional and nonfunctional demands. In [ 11 ] we have developed a methodological analysis, to analyse available cryptanalytic techniques for different menaces and proposed a design templet that identifies the environmental restraints and design restraints. Based on this, appropriate cryptanalytic techniques may be specified that optimally meets the security demands. After the design determination, the system needs security proving to avoid all possible loopholes and failings in the system which might ensue into loss of information in the custodies of the stakeholders or outsiders/ interlopers of the system.

Recently there are some proposals on theoretical account based security proving as in [ 6 ] they have combined system patterning linguistic communications with mold linguistic communications for security and formalise entree control demands. A brief study on theoretical accounts that can be used for theoretical account based security proving besides found in [ 7 ] . In [ 8 ] they are making menace hints to prove the security construct at the clip of proving by fiting the executing hint with menace hint created with the aid of sequence diagrams. Security proving every bit presented in [ 9 ] is a novel scenario based method that trades with security proving during the design stage. Continuing our earlier work to develop a cost effectual security technology model which is already proposed in [ 5 ] , now our purpose in this paper is to widen this model by developing a procedure for Security Testing.

Our attack involves placing vulnerable points and mapping identified menaces to these vulnerable points to extenuate the identified security menaces. In this paper we have proposed a model for security testing by which we check whether the design determination taken to implement the security demands is appropriate for the system or non.

The remainder of the paper is organized as follows:

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

Proposed Security Engineering Framework

To plan, construct and deploy secure systems, one must incorporate security into SDLC and adapt current package technology patterns and methodological analysiss to include specific security-related activities. Security-related activities [ 5 ] include placing security demands, prioritising & A ; direction of security demands, security design, implementing security mechanisms, security testing. Our proposed model for Security Engineering Process ( SEP ) is shown in Figure 1. Now the brief account of the different activities performed in different stages of Security Engineering

Procedure ( SEP ) are as follows:

Figure 1 Model for Security Engineering Procedure

Requirement Engineering – This procedure is based on good known procedure of View Point Oriented Requirement Definition [ 3 ] . It involves detecting functional demands. It so identifies the assets and associated menaces involved with the functional demands to eventually arouse security demand such as Privacy, Authentication, Integrity, Non- Repudiation, etc as defined by Firesmith [ 2 ] . Then elicited security demands are analyzed and prioritized.

Design Decisions – In this stage security design determinations are taken which include function of security demands with cryptanalytic services such as hallmark, confidentiality, etc. , and so mapping onslaughts to prioritise menaces. After that design determinations are taken which consider environmental restraints such as memory, encoding velocity, energy, etc and security design attributes such as throughput, mark platform, cost, etc. It so generates Security Design Template ( SDT ) that guides security applied scientist to finalise design determinations that specify which cryptanalytic technique is best suited for peculiar environment and design restraints.

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

Testing – It involves measuring the system security and finding the adequateness of cryptanalytic algorithms chosen during design.

Proposed Security Testing Framework

When the term proving comes, the two bomber subjects arise. These are confirmation and proof. Confirmation is the procedure of measuring a system or constituent to find whether the merchandises of a given development stage satisfy the conditions imposed in the beginning of that stage. Validation is the procedure of measuring a system or constituent during the development procedure or at the terminal of it to find whether it satisfies the specified demands. Verification is a inactive technique in which executing of codification is non needed hence procedure of confirmation is chosen here.

After the security demands are prioritized, appropriate design determinations are taken and farther activities arise. Procedure for doing design determinations is already explained in [ 5 ] . After security design execution security proving comes into image. Early sensing of security related concerns will be cost effectual, as it costs more to take any mistake during ulterior stages. Security testing is done to prove whether security demands are implemented decently and are protecting the system against all the attacks/ vulnerable points. Our proposed model for Security testing is shown in Figure 2.

Degree centigrades: Documents and SettingsShrutiDesktop
ewframe1.bmp

Figure 2 Security Testing Framework

Measure 1: Identify the Attacker and Possible Attacks.

Designation of aggressor and the onslaughts that he can put to death is really helpful in measuring the system security.

The procedure consists of following sub procedures:

Identify the Attacker. Identify whether the aggressor is an insider or an foreigner. Insider means anybody who is an histrion related to system straight or indirectly and outsider means an interloper who wants to deliberately assail the system. Identify the aggressor for each functionality offered by the system.

Identify the Attacks. Once the aggressors are identified, place the possible onslaughts executed by aggressors to transgress the security. This is required to prove whether the security mechanism is protecting against the onslaughts.

Step2: Find Vulnerable Points.

Vulnerable point shows the failing of the system, from where the aggressors can perforate the system and derive entree to the valuables for their usage. They may besides do injury to the organisational assets, so place all these vulnerable points.

The procedure consists of following sub procedures:

Trace the Sequence of Events. To place the vulnerable points that exist in the system, make the sequence of events that occurs to put to death functionality.

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

Map the Attacks to Vulnerable Points. Map the onslaughts identified in measure 1 to all the identified vulnerable points, so that it can be checked easy whether the system is able to protect these points from identified onslaughts or non.

Measure 3: Security Mechanism Verification & A ; Validation.

Now test whether the cryptanalytic algorithms identified during the design stage are able to protect the system against assorted onslaughts and menaces possible due to the presence of vulnerable points for peculiar functionality

The procedure consists of following sub procedures:

Identifying Attacks for Selected Algorithm. First take the cryptanalytic algorithm identified during the security design determinations activity of security design technology and so place the onslaughts which are resisted by the algorithm.

Check the Vulnerability Nullification. Map the onslaughts to the vulnerable points identified with the set of onslaughts that the given algorithm is able to protect against. Then will mensurate the degree to which the exposure points are protected against the onslaught. If out of N entire onslaughts M are mitigated so will state that the exposure point is protected by value M/N. Following this, cipher the Security Vulnerability Index ( SVI ) utilizing the expression given below:

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

Check Threat Mitigation & A ; Effect on Risk. Map the onslaughts to the corresponding menaces and look into how many menaces are mitigated by selected cryptanalytic algorithm. If algorithm is able to support against onslaught, decision can be extracted that menaces matching to onslaughts are besides mitigated. If the menace is mitigated it means the value of menace evaluation becomes zero and therefore the hazard will besides go nothing as the hazard is dependent on menace evaluation in our hazard value calculation [ 4 ] . Then cipher the Security Risk Index ( SRI ) utilizing the expression given below:

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

Measure 4: Generate Test Report Template

Make a trial study templet that contains all the of import information related to the activities. The templet will assist the developer in make up one’s minding farther activities as it contains all the security related information of this stage. Template has the Fieldss like Test Case ID, Test Case Name, Attacker and Modeled Attacks, Vulnerable Points, Security Mechanism, Result, Recommendation/ Remark. The sample trial templet is shown below in Figure 3.

Test Case ID

Unique ID for each Template so that it can be distinguished

Test Case Name

Alone Name must be same as functionality under trial

Attacker Type

Type of aggressor ( insider or foreigner )

Modelled Attacks

List of onslaughts that attacker can put to death

Vulnerability Points

List of all points on which onslaught can happen during the executing of functionality

Security Algorithm Applied

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

Consequence

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 subdivision, use the model to a Web Based Banking system for verifying the security mechanisms as per demands and restraints. In web based banking system, the histrions involved can be Customer, Bank Employee, Bank Database, System Administrator, Maintenance Manager, etc. But the actors/stakeholder that comes under our consideration is merely the direct histrions such as Customer, Bank Employee and Bank Database. Their functional demand, non functional demands, security demands, onslaughts, security mechanism and all other inside informations of evocation and design can be found in [ 5 ] .

The end product of the activities of first stage of security technology, that is, security demands technology is shown in Table 1.

Table 1 Security Requirement Prioritization for Web Based Banking System

Before using the proposed model of security proving we have taken the security determination templet as shown in Table 2. For elaborate procedure refer [ 5 ] .

Table 2 Security Design Engineering Web Based Banking System

Now use our proposed model on Web Based Banking system. As our model has four chief stairss, we progress through all of them one by one.

Step1: Identify the Attacker and Possible onslaughts.

Identify the Attacker. To place the aggressor, start with the functionality balance question. This functionality can be attacked by an insider or by an foreigner or by both. Here we take the aggressor as an foreigner for explicating the remainder of the procedure.

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

Replay onslaught

Man – in – the – Middle Attack

Dictionary Attack

Impersonation Attack

Insertion onslaught

Step2: Find Vulnerable Points.

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

Provide login inside informations at client terminal ( Request )

Confirmation of login inside informations at server side ( Response )

Request for balance question ( Request )

Retrieve information from database ( Response )

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

Table 3 Vulnerable points with Assetss

S. No

Vulnerable Point Extracted

Assetss Involved

1

At the clip of Login

User Login Information

2

Confirmation of Login inside informations

Account Information,

Customer Information

3

Request for Balance

Account Information

4

Recovering Datas

Account Information,

Customer Information

5

During Data Transfer

User Login Information

Account Information,

Customer Information

Map the Attacks to Vulnerable Points. Now map the onslaughts identified in measure 1 to the identified vulnerable points and besides map the corresponding menaces. As shown in Table 4.

Table 4 Mapping of Threats Involved

S. No.

Vulnerable Point

Attack

Menaces Involved

1

At the clip of login

Replay Attack, Impersonation Attack

T. Impersonate,

T.Data_Theft

2

Confirmation of Login Details

Denial of Service Attack

T.Change_Data

3

Request for Balance

Impersonation Attack

T.Impersonate

4

Recovering Datas

Denial of Service Attack

T.Change_Data

5

During Data Transfer

Man – in – the – in-between Attack, Dictionary Attack, Insertion Attack

T. Impersonate,

T.Data_Theft

T.Disclose_Data

Measure 3: Security Mechanism Verification & A ; Validation.

Identifying Attacks for Selected Algorithm. Take the cryptanalytic algorithm selected in design stage and place the onslaughts 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

Caricature

2

Stolen Verifier

3

Smart Card Loss

4

Denial of Service

5

Interpolation

Check Vulnerability Nullification. Next cheque whether the identified onslaughts are resisted and matching vulnerable points are protected by the selected algorithm. Table 6 shows the exposure point nullification.

Functionality under Test: Balance Question

Table 6 Nullification of Vulnerable Points

S. No.

Vulnerable Point

Attacks

Nullified or Not

1

At the clip of login

Replay Attack, Impersonation Attack

1/2

2

Confirmation of Login Details

Denial of Service Attack

1/1 = 1

3

Request for Balance

Impersonation Attack

1/1 = 1

4

Recovering Datas

Denial of Service Attack

1/1 = 1

5

During Data Transfer

Man – in – the – in-between Attack, Dictionary Attack, Insertion Attack

1/3

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

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

Check Threat Mitigation & A ; Effect on Risk. Now check the consequence of onslaught remotion on menace and hazard shown in Table 7.

Table 7 Threat Mitigation and Risk Value

S. No.

Vulnerable Point

Attack

Menaces

Involved

Menaces

Mitigated

Hazard Value

1

At the clip of login

Impersonation Attack, Replay Attack

T. Impersonate,

T.Data_Theft

T.Impersonate

Y ( 1 )

N ( 0 )

2

Confirmation 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

Recovering Datas

Denial of Service Attack

T.Change_Data

T.Change_Data

Y ( 1 )

5

During Datas

Transportation

Man – in – the – in-between 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 menace represents it is being mitigated by mapped onslaught and value N ( 0 ) means corresponding menace is non mitigated by onslaught.

In the above tabular array, most of the menaces are mitigated as the corresponding onslaughts are resisted. Therefore, it is validated that most of the hazard values become zero, as the menaces are mitigated which in bend make menace evaluation as nothing. And in CRAMM [ 10 ] if the menace evaluation is 0 the corresponding hazard will be 0.

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

Measure 4: Generate Test Report Template.

Test study templet is generated to supply a brief overview of the overall procedure of security testing. Test Template for Balance Enquiry is shown in Figure 4. It contains all the of import information related to the activity. The templet will assist the developer in make up one’s minding farther activities as it contains all the security related information of this stage.

Test Case Id

TC_01

Test Case Name

Balance Enquiry

Attacker Type

Foreigner

Modelled Attacks

Replay onslaught, Man – in – the – Middle Attack, Dictionary Attack, Impersonation Attack, Insertion onslaught

Vulnerability Points

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

Security Mechanism Applied

ECDSA

Consequence

SVI = 76.67 %

SRI = 62.5 %

Remarks

None

Figure 4 Test Template for Balance Enquiry

Decision

In this paper model for security testing is presented that attempts to verify all the security mechanism identified during design stage are appropriate for system under survey. In bing research proposed, security testing is carried out after system execution. In [ 9 ] research workers are executing security proving during design stage but this is based merely on security demands. In our proposal we foremost elicit security demands, and so take effectual design determination by taking the most optimum mechanism to implement security and so execute proving. Security proving stage will be the portion of Security Engineering Process. The model is really helpful in information system development procedure as here it tries to cover with all security related concerns in early phases. It will assist cut down the overall budget of system development as early sensing and rectification of security concern incur less cost and clip. Security proving will go an built-in portion of security technology model and in turn portion of the conventional package technology procedure.