As applications grow more complex, security of an application cannot be ensured by doing a set of random checks such as SQL injection, Cross site scripting or Session handling. In May, Roshen wrote on Threat Profiles . Just to recollect, a threat is the goal of an adversary, and a threat profile is the set of all threats the system should protect against. Threat profiling can be very effective in identifying various threats that can affect an application.
The usefulness of a threat profile is best illustrated with an example. In this post I am using a banking application to show a small set of threats. Any banking application could be vulnerable to the following threats:
Post a transaction with incorrect date or amount and cause inaccurate interest calculation.
Transact funds from an account even after it has been frozen or closed.
Close an account without running the interest calculation on it and cause a loss to the bank or the customer.
Post unauthorized transactions by authorizing one's own transactions, bypassing the maker-checker restrictions.
Close an account with non-zero balance or while there are unverified transactions and cause operational problems.
Open and close accounts secretly.
Post invalid transaction where the total amount entered is different from the sum of the amount entered in the part transactions.
Debit an account using a check number not issued to that account.
Modify the maturity amounts for deposits and cause losses to the bank.
The threats listed above could be missed in a checklist based approach or an automated tool testing. It is therefore important that a threat profile be created before doing a security test of the application. Sangita wrote an introduction to threat modeling in Palisade some months ago.