Preparing the threat profile – Security Testing Handbook for Banking Applications

1: Approach to Security Testing
19
test case will specify the page and the variable where the
test will be tried out. This detailed test plan serves an
important purpose: it ensures a thorough test is carried out
and that no attack vector for any threat is left unexplored.
In Chapter 4 we discuss the threat profiles and test plans of
several banking applications.
With a complete test plan in hand, the task of actual testing
becomes easy. The penetration tester now only has to
concentrate on carrying out each test case from the test
plan. But this is not just a no-brain activity. As each test
case is executed, there may be a need for more tests to
confirm the results.
A detailed report is then prepared, based on which the
application can be secured. Along with the security
weaknesses observed, the report also has details of the
impact it would have on the business, the ease of exploiting
it and the risk rating. It also describes how the exploit was
carried out with screenshots wherever required. There is a
recommendation section for each finding which explains
how the vulnerability can be fixed.
Preparing the threat profile
The threat profile is the basis of the entire test. Let’s see
how to create an effective threat profile. The exhaustiveness
of the threat profile is the big challenge. How can we create
a near-complete threat profile? Here’s a four-step approach
we follow and have always found very useful:
Ask
o Who are the users?
o What does the application do?
1: Approach to Security Testing
20
Spot
o Sensitive data
o Sensitive actions
Write
o View/modify/delete/add sensitive data
o Perform sensitive actions
Refine
o Use more expressive words.
Let’s build a sample threat profile for an Internet banking
application with limited features using the above steps.
First, ask ‘Who are the users?’
That would be the Internet banking customers.
Next, ask ‘What does the application do?’
An Internet banking application offers a wide range of
features. For this example let’s take two. The application
lets users:
check their account statements
transfer funds.
Next, spot the sensitive data and actions
The sensitive data would be:
transaction details
balance funds in the account.
The sensitive actions would be:
1: Approach to Security Testing
21
check account summary
transfer funds.
Next, generate the threats
We generate possible threats by prefixing
view/modify/add/delete for the sensitive data. Some of the
statements might not make sense, in which case you can
exclude them.
Let’s take the first item of sensitive data in the application
‘transaction details’ and generate potential threats.
view transaction details of other users
modify transaction details of other users
delete transaction details of other users
add transaction details of other users.
Next, let’s take the second sensitive data, ‘balance funds’:
view balance funds in another user’s account statement
modify balance funds in another user’s account
statement
delete balance funds in another user’s account statement
add balance funds in another user’s account statement.
The last three statements do not make sense, because the
balance is calculated from transactions and cannot be
directly changed; hence we can drop them. We now have
five threats to the application.
After cranking out threats using this formula, we can
generate a few more threats by trying to violate sensitive
actions. For example in this case, that would be:
check account statement of other users