Data­base se­cu­rity

Banking Frontiers - - Housing Hihglights - - V Babu, ex-DGM - IT, Bank of In­dia (bab­

It is nec­es­sary to have a well-pre­pared plan:

Data­base se­cu­rity is noth­ing but a broad range of in­for­ma­tion se­cu­rity con­trols to pro­tect the data and re­lated data­base ap­pli­ca­tions, sys­tems, servers and the as­so­ci­ated net­work links against com­pro­mises of their con­fi­den­tial­ity, in­tegrity and avail­abil­ity. In­ter­nal con­trols are es­sen­tial to pro­tect the in­for­ma­tion / data, from unau­tho­rized ac­cess, dis­clo­sure, dis­rup­tion, mod­i­fi­ca­tions, in­spec­tion, record­ing or de­struc­tion etc. Threats and data­base se­cu­rity go to­gether.


There are many threats like soft­ware at­tack, theft of in­tel­lec­tual prop­erty, iden­tity theft, theft of equip­ment which con­tains data etc. In­for­ma­tion se­cu­rity poli­cies are pre­pared by banks, which en­sure pro­tec­tion of the in­for­ma­tion as­sets against risks of loss, mis­use, dis­clo­sure, dam­age etc and give nec­es­sary guide­lines to fol­low. In­for­ma­tion se­cu­rity poli­cies are one of the reg­u­la­tory re­quire­ments and have to be ap­proved by the board of direc­tors. It is also im­por­tant to see whether the poli­cies pre­pared are im­ple­mented in true spirit and not just in paper to sat­isfy reg­u­la­tory author­i­ties. It is of­ten no­ticed that even though banks do have them, they do not get per­co­lated to mi­cro level and the staff is not aware of the re­quire­ment or what should be done in case of an even­tu­al­ity.

Fur­ther, it is nec­es­sary to up­date the IS poli­cies reg­u­larly to be in tune with the lat­est tech­nol­ogy /prod­ucts in­tro­duced at the bank.


The most im­por­tant as­pect in any risk sce­nario is the aware­ness about the pit­falls and how to over­come these. In this sit­u­a­tion, there is no sub­sti­tute for train­ing to be of­fered to the staff mem­bers on var­i­ous as­pects of the risks and the po­lices of the bank on a reg­u­lar ba­sis. The bank may take help from ex­ter­nal ex­perts in this ex­er­cise in case in­ter­nal re­sources are not avail­able. An as­sess­ment may be made af­ter the train­ing pro­gram to find out whether staff mem­bers could un­der­stand the in­tri­ca­cies and whether any fine-tun­ing is nec­es­sary in the train­ing sched­ule. The train­ing should be an on­go­ing ex­er­cise when­ever new de­vel­op­ments take place or new tech­nolo­gies are in­tro­duced. The train­ing should cover not just the staff mem­bers but mid­dle and toplevel ex­ec­u­tives too. Most of the fail­ures of a new tech­nol­ogy driven prod­uct hap­pens due to lack of train­ing to the oper­a­tional staff.


Vi­o­la­tion of data­base se­cu­rity may be through unau­tho­rised ac­cess, un­in­tended ac­tiv­ity or mis­use of data, in­ap­pro­pri­ate changes to pro­grams, con­fig­u­ra­tions etc. There can also be leak­age or dis­clo­sure of per­sonal and pro­pri­etary data, dele­tion or dam­age to the data pro­grams. It is nec­es­sary that data­base se­cu­rity cen­ters at the data cen­tre are cre­ated and nec­es­sary safe­guards are cre­ated by fram­ing nec­es­sary poli­cies and guide­lines. The poli­cies, in­clud­ing ac­cess con­trol poli­cies and backup pro­ce­dures should be doc­u­mented, both for in­source as well out­sourced ac­tiv­i­ties. To start with, nec­es­sary poli­cies should be pre­pared for phys­i­cal se­cu­rity, en­vi­ron­men­tal con­trols, backup pro­ce­dures, net­work con­trols etc. In­for­ma­tion Se­cu­rity Man­age­ment Sys­tems (ISMS) is a set of poli­cies con­cerned with in­for­ma­tion se­cu­rity man­age­ment or tech­nol­ogy re­lated issues.

The three Ds of in­for­ma­tion’s se­cu­rity are (i) Se­cure by De­sign (elim­i­nate vul­ner­a­bil­i­ties) (iii) Se­cure by De­fault (avoid auto per­mis­sion etc) and (iii) Se­cure in De­ploy­ment. The con­trols may in­clude pre­ven­tion con­trols, de­tec­tion con­trols and cor­rec­tive con­trols.


It is sug­gested that once a cri­sis sit­u­a­tion de­vel­ops, one should not go for witch-hunt­ing; in­stead it will be bet­ter to find out how se­ri­ous the impact is, which are the oper­a­tional ar­eas af­fected and how fast the cor­rec­tion can be made. Un­to­ward in­ci­dents can­not be avoided in any tech­nol­ogy sce­nario. The risk oc­curred to the as­sets can be cal­cu­lated by Busi­ness Impact Anal­y­sis (BIA), which is gen­er­ally the mag­ni­tude of the po­ten­tial loss and once this is iden­ti­fied, nec­es­sary ac­tion should be taken to set right the is­sue and to min­i­mize the risk.


The fun­da­men­tal task in BIA is un­der­stand­ing which of pro­cesses are vi­tal for the on­go­ing op­er­a­tions and to un­der­stand the impact, the dis­rup­tion of these pro­cesses would have on busi­ness and cus­tomer ser­vice. BIA is the process of fig­ur­ing out which pro­cesses are crit­i­cal and which will impact cus­tomer ser­vice, and un­der­stand­ing the impact of a dis­rup­tion to those pro­cesses. Var­i­ous cri­te­ria are used, in­clud­ing cus­tomer ser­vice, in­ter­nal op­er­a­tions, le­gal or reg­u­la­tory and fi­nan­cial for this pur­pose. From an IT per­spec­tive, the goal is to un­der­stand the crit­i­cal busi­ness func­tions and link those to var­i­ous IT sys­tems. As a part of this as­sess­ment, un­der­stand­ing the in­ter­de­pen­den­cies of var­i­ous crit­i­cal pro­cesses to both dis­as­ter re­cov­ery and busi­ness con­ti­nu­ity, es­pe­cially from an IT per­spec­tive is most cru­cial.

The most im­por­tant thing is to take im­me­di­ate ac­tion to pre­vent the in­ci­dent from im­pact­ing other oper­a­tional ar­eas and to pre­vent a rep­e­ti­tion. Banks should have in place de­tailed Busi­ness Con­ti­nu­ity Plan (BCP), ap­proved by the board. There is a mis­con­cep­tion that the backup pol­icy /dis­as­ter re­cov­ery pol­icy is enough to take care of these things. These poli­cies cover the tech­nol­ogy ar­eas only and not for all the bank­ing op­er­a­tions. BCP is an ex­haus­tive plan to in­clude all the oper­a­tional ar­eas in­clud­ing tech­nol­ogy to en­sure a smooth cus­tomer ser­vice in case of any dis­as­ter. It is not just enough to have a plan or po­lices. It is nec­es­sary these are un­der­stood by the staff mem­bers so that they can fol­low the guide­lines in emer­gen­cies.

Fi­nally, too much de­pen­dency on any­thing leads to lethargy and sub­se­quent risk. This is true of ev­ery­thing in­clud­ing staff and tech­nol­ogy so­lu­tion providers. Some banks de­pend on their tech­nol­ogy solutions providers for all ac­tiv­i­ties without any su­per­vi­sory con­trol on them. There lies the risk. All said and done, fi­nally the bank is re­spon­si­ble for what­ever hap­pens and should take safe­guards to save its as­sets and to give con­tin­ued cus­tomer ser­vice.

V Babu

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.