ITIL V3 Concept – Repression

One of the key processes in ITIL V3 is IT Information Security. This process is a part of Service Design phase. A technique used in countering basic hacks is the repressive/repression technique.

When a certain action is performed incorrectly multiple times, the system supporting the action represses it, thereby preventing potential hack.

I know whatever I stated above went right over your head. When I state it with an example, the aaah moment will follow.

Everybody I know who has an email account, has a gmail one. On the login page, when you enter wrong passwords multiple times, first a captcha phrase pops in – to test if the user keying the password is not a bot. Next, the account gets locked out, and the unlock process identifies the right owner through the registered cell phone number.

I am interested in the locking process rather than unlocking.

When wrong passwords are keyed in a number of times, to protect against a possible hack, the account getting locked is a repressive action. It ensures that the potential damage is minimized by repressing the threat.

In the gmail example, repression technique is two-fold. First is to check whether a script is trying to gain access by trying a number of permutations and combinations. Second control – locking the account is the second tier control which can protect against a person trying to gain access by manually trying out different passwords.

Generally financial institutions use the repression technique to protect against fraud. I have seen that a number of banks give three or five tries before locking the account.

If you have further questions on the repression concept in ITIL V3, comment below. Other techniques include detection, prevention and correction. I will pick the remaining in the near future.