Continue # Infosys Whitepaper 
  each of these parameters. On the next page, table 3.1 presents a sample parametric table. The snap- shot in table 3.1 only comprises of those parameters that are relevant for testing the application  requirement. The main security parameters, as listed in the table 3.1 are - Authentication, 
Authoriza- tion, Access control, Non-Repudiation and Audit control. This list is just a sample list and in actual  scenario there can be many more parameters in the template.     These parameters are further classified according to testing subtask.  For example the requirement of  authentication can be implemented using userid/password, smart card, biometric and digital certifi- cates. And each one of this implementation has different testing requirement. Based on the testing  complexity, appropriate weightages are assigned. The weightages can be determined based on past  experience and the series of interactions conducted with the customer during the requirement gather- © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.<|endoftext|>

---

  Page: 6 / 10  

---

   Presented at the 3rd International Software Testing Conference, India  ing stage. Going back to the example, since biometric requires substantial investment from the cli- ent’s side the digital certificates score higher than the other modes of implementing authentication.    The last column holds the priority level assigned to each sub-parameter. The business domain and the  experience of the test expert determine the priority level assigned to each sub-parameter. For exam- ple, consider a case of Internet banking application. Here the authentication is slightly of higher prior- ity than that of authorization or access control. Where as in case of a b2b application the authoriza- tion and the access control takes higher priority.    All the parametric values are recorded and this constitutes a requirement document outlining the ar- eas and the level of testing that has to be executed.    No.  Parameters  Dimension            (scale of 1 - 5)  Dimension      (scale 1 - 5)  Dimension      (scale 1 - 5)  Dimension       (scale 1 - 5)  Dimension      (scale 1 - 5)  Priority     (scale of  1 – 100)  1  Authentication  -corroboration  that an entity  is who it claims  to be.  No  authentica- tion  (0)  Password  Based  (3)  Smart card  and PIN  (3)  Biometric  (4)  Digital  certificates.  (5)  10  2  
Authorization  No  
Authoriza- tion  (0)  Role Based   (3)  User Based   (3)  Using Elec- tronic Signa- tures  (for  non- repudiation)  (3)  Role  and  User Based  (4)  10  3  Access Control  No ACL  (0)  Context  Based  (3)  User Based  (3)  Role Based  (3)  All 3  (4)  7  4  Non  repudia- tion  Nothing  (0)  Digital  signature  (3)  Encryption  and digital  signature  (4)      5  5  Audit control  Nothing  (0)  Use  Fire  wall/ VPN  logs  (1)  Custom  made logs  (3)  Employ  managed  security  services  (4)    5  Table 3.1  © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.<|endoftext|>

---

  Page: 7 / 10  

---

   Presented at the 3rd International Software Testing Conference, India  3.2 Parametric Approach to Security Test Analysis and Design   Once the weightages for each security parameter is finalized, the next task is to create test scenarios  for testing the security requirements. The weightages assigned to each sub-parameter goes on to sug- gest the number of scenarios that need to be tested for a particular requirement and the complexity  involved.     The parametric approach also helps in identification of the extent of data that would be needed for  test execution and also the distribution of data based on various scenarios. Also, this will help in  identifying the kind of tools that will be needed and determine the appropriateness of a tool for a  given type of test.    Now the data that is recorded with the parametric template can be tabulated in the below given form:  No.  Parameter  Weightages   (Scale of 1- 5)  Priority   (Scale: 1 – 100)  1  Authentication  3  10  2  
Authorization  2.75  10  3  Access Control  2.6  7  4  Non-Repudiation  2.3  5  5  Audit control  2.0  5  Table 3.2    The table 3.2 above is comprised of the security parameter with its corresponding values of Weight- ages and Priority levels. These weightages are the average of weightages assigned for the testing ac- tivity of each sub-parameter as illustrated in the table 3.1. With the availability of these values for  each sub-parameter the test expert is now able to plan the test scenarios to the desired level of priority  and depth.    3.3 Security Test bed Implementation  In case of application level testing the approach of testing the security vulnerabilities should be more  logical. Here logical security deals with the use of computer processing and/or communication capa- bilities to improperly access information. Second, access control can be divided by type of perpetra- © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.<|endoftext|>

---

  Page: 8 / 10  

---

   P   tor, such as employee, consultant, cleaning or service personnel, as well as categories of employees.  The type of test to be conducted will vary upon the condition being tested and can include:    Determination that the resources being protected are identified, and access is defined for each re- source. Access can be defined for a program or individual.    Evaluation as to whether the designed security procedures have been properly implemented and func- tion in accordance with the specifications.    Unauthorized access can be attempted in on-line systems to ensure that the system can identify and  prevent access by unauthorized sources.    Most of the security test scenarios are oriented to test the system in the abnormal conditions. This  throws up the challenge of simulating the real life conditions that the test scenarios require. There are  various tools that can be used to test various vulnerabilities that the system may have. The choice of  such a tool is determined by the extent of vulnerability, the tool is able to test, Customization of the  tool should be possible and testing of the system using both the external as well as the internal views.  The local users are the internal view and the external users constitute the external views. There are  various programming tools that can be programmed to simulate the various access control breaches  that can happen.     4 Interpreting Security Test Reports    Once tests have been executed and security gaps have been identified, the gaps need to be analyzed in  order to suggest improvements. The reports need to be validated as many a times as possible. The  reports may be misleading and the actual loopholes might be elsewhere or might not exist at all.  The  security test reports are like X-ray reports, where a security expert is essential to decipher the vulner- abilities reported and bring out the actual problem report. There are various security reporting tools.  © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.<|endoftext|>

---

  Page: 9 / 10  

---

   Presented at the 3rd International Software Testing Conference, India  While selecting a security-reporting tool, the following parameters have to be taken in to considera- tion:  1.  Extent if vulnerability, the tool is able to report.  2.  Customization of the tool should be possible.  3.  Testing of the system using both the external as well as the internal views.    Once the analysis of the report is completed a list of vulnerabilities and the set of security features  that are working is generated. The list of vulnerabilities is classified. The classification level of  vulnerability is determined by the amount risk involved in the security breach and the cost of fixing  the defect. Once the classification is done the vulnerability is fixed and retested.  5   Conclusions  A parametric approach to security testing not only, works very well for security requirement capture,  effort estimate and task planning but also for testing different levels of security requirements by dif- ferent components within same application. This approach for requirements gathering comes out to  be real handy in capturing those security requirements, which cannot