• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Information Risk Security model and metrics

Information Risk Security model and metrics






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Information Risk Security model and metrics Information Risk Security model and metrics Document Transcript

    • INFORMATION  RISK  SECURITY  MANAGEMENT:    A  Model  and  Metrics    By  Vladimir  Jirasek, Information  Risk  Management  Evangelist    Contents                   Page      Section  1:  Introduction               2  1.1  The  Security  Governance,  Risk  and  Compliance  (GRC)  model     2   1.1.2 Security  Drivers             2   (i) Laws  and  regulations           2   (ii) Business  objectives           2   (iii) Security  threats             3   1.1.3 Security  Management             3   (i) Policy  framework             3   a. Policies               3   b. Standards             3   c. Artefacts             3   (ii) Processes  framework           3   (iii) Security  metrics  framework         3   1.1.4 Stakeholders               4    Section  2:  Security  Drivers               4  2.1  Business  objectives               4  2.2  Legal  and  regulatory  requirements           4  2.3  Security  threats                 4    Section  3:  Security  Management             5  3.1  The  Policy  framework               5   3.1.1  Information  security  policy             5   3.1.2  Data  classification  policy             5   (i)  Public  data               5   (ii)  Company-­‐wide  data           6   (iii)  Restricted  access  data           6   3.1.3  Employee  acceptable  policy           6   3.1.4  Information  technology  security  policy         6  3.2.  Security  standards               7   3.2.1  International  standards  for  security  policy  and  controls     7   3.2.2  Information  technology  standards           7  3.3  Security  architecture  repository             8  3.4  Process  frameworks  and  metrics             8   3.4.1  Security  processes               8   3.4.2  Security  metrics                 8   (i)  Value  at  Risk             9  Conclusion                   10    About  the  Author                 10      
    • Section  1:  Introduction  Information  risk  security  management  is  an  area  that  is  constantly  moving  to  respond  to  new  threats,  standards   and   technologies.   Security   is   now   a   part   of   information   risk   management,   which   in   turn  has  a  place  in  the  overall  business  risk  management  strategy.    This   document   explains   a   security   model   that   supports   business   needs,   and   explores   how   security  professionals  could  change  their  mindsets  to  help  ensure  future  job  security.    1.1  The  Security  Governance,  Risk  and  Compliance  (GRC)  model    Figure  1  below  describes  a  security  model  that  introduces  the  topic  of  security  to  business  managers  and  CIOs.     Figure  1:  Security  GRC  model Feedback:  update  business  requirements SECURITY  MANAGEMENT DRIVERS STAKEHOLDERS Correction  of  security  processes CEO  &  Board International   Policy  framework Process framework Metrics  framework Governance security   standards Information   Information   Information   Line   Security   Security   Security   management policies processes metrics   Laws  &   objectives regulations Information   Product   Drivers Security   Rules Measure Inform management Technology standards Security   People Define metrics  portal Program   Information   management Compliance security   requirements architecture Risk  &   DEFINE  security   EXECUTE  security   MEASURE  security   compliance Business   controls controls controls  maturity objectives Auditors Security   Security   threats intelligence Security   External professionals security metricsThe   model   describes   three   main   areas:   (1)   Security   drivers;   (2)   Security   management;   (3)   and  Stakeholders.    1.1.5 Security  Drivers    The  three  major  drivers  for  security  are:    (i)     Laws   and   regulations:   A   company   must   comply   with   these   or   face   legal   action   or   a   fine.   For   example,   the   Data   Protection   Act   and   the   Company   Act  are   examples   of   the   legal   drivers;   PCI   DSS  is  an  example  of  a  regulation  driver.      (ii) Business   objectives:  Companies  typically   want   to   generate   profit   and   define  a  set  of  business   objectives.   Security   supports   these   business   objectives   by   protecting   systems   and   information   used   in   the   business   processes.   Think   of   protecting   Microsoft   Windows   source   code:   if   the   source   code   was   not   protected   anyone   could   compile   their   own   operating   system   without   paying   Microsoft   any   license   fee.   Hence,   Microsoft’s   business   objective   to   ‘Sell   software’   is   supported   by   the   security   objective   ‘Protect   source   code’.   Similarly,   Amazon’s   business  
    • objective   is   to   sell   products   in   their   online   shop;   their   business   objective   is   to   have   an   online   shop   up   24/7;   the   security   objective   is   to   keep   systems   free   of   malware   that   could   disrupt   or   slow  down  IT  systems.    (iii) Security   threats:   Security   threats   work   against   laws   and   regulations   and   business   objectives.   However,   they   also   drive   information   security,   and   companies   need   to   respond   to   threats   in   order  to  satisfy  first  two  drivers.    1.1.6 Security  Management  Within   this   area   there   are   three   frameworks   that   enable   a   company   to   achieve   the   objectives  defined  in  the  ‘drivers’  section:      (i) Policy  framework  This   is   a   set   of   policies,   standards   and   guidelines   that   describe   how   a   company   addresses  information   security   drivers,   and  define   the   security   controls   available   for   a   company   to   implement.  There  are  also  international  standards  that  can  be  source  of  information  and  control  for  the  Policy  framework.    a.   Policies   –   also   known   as   Security   Control   Objectives,   these   typically   use   words   such   as   ‘should’  and   ‘must’.   The   key   objective   of   the   security   policy   document   is   alignment   with   the   business  objectives  and  drivers.      b.   Standards   –   detailed   Security   controls   that   should   be   implemented   to   support   individual   policy  statements;  one  policy  statement  can  be  supported  by  multiple  security  controls.  These  should  be  linked  to  a  policy,  otherwise  the  security  professional  will  be  unable  to  justify  why  a  password  needs  to   be   12   characters   and   change   every   45   days,   for   instance.   The   controls   should   be   selected   from   an  internationally  accepted  catalogue  of  controls  (see  section  below  on  ‘International  Standards’).      c.   Artefacts  –  Architecture  standardisation  is  the  key  to  the  success  of  any  company,  and  the  same  applies  to  security.  If  a  solution  to  implement  a  security  control  is  found  in  the  ‘Standard’,  it  should  be   put   it   into   a   ‘Security   Architecture   Repository’.   That   way,   others   can   benefit   and,   more  importantly,  consistent  security  is  achieved.  Many  security  professionals  do  not  document  artefacts  into  a  shared  library,  which  can  often  result  in  problems  when  they  leave  the  company.      (ii) Processes  framework  This   section   in   Security   Management   implements   what   is   stated   in   the   Policy   framework.   Any  security   control   in   a   policy   or   standard   is   a   process,   no   exceptions.   Each   process   is   supported   by  people   and   most   are   supported   by   technology.   However,   there   needs   to   be   a   link   between   any  technology  the  company  has,  its  process,   and  the  corresponding  control  in  the  Policy  framework  up  to   the   business   objective.   This   enables   traceability   of   the   security   investment   and   allows   security  professionals  to  justify  security  budgets.      (iii) Security  metrics  framework  This  is  a  developing  area  of  information  security  management.  The  common  adage  –  ‘what  cannot  be  measured,  cannot  be  managed’  –  can  be  applied  equally  well  to  security.  Security  professionals  should   be   able   to   measure   the   status   of   security   controls,   the   compliance   with   their   own   policies,  and  the  effectiveness  of  security  processes.  The  key  metric  is  to  take  a  security  policy  statement  and  measure   each   team   against   it;   this   will   provide   a   balanced   scorecard   for   security.   The   metrics  framework  provides  feedback  to  the  Process  framework,  to  assist  with  security  processes  design.    1.1.7 Stakeholders  Stakeholders  are  the  recipients  of  the  security  metrics  framework  results.  The  stakeholders  need  to  know  that  what  has  been  promised  is  being  delivered.  More  importantly,  the  security  professionals  need  to  show  the  value  of  security  to  the  business.  This  is  an  area  where  security  professionals  need  to   enhance   their   skills;   they   need   to   talk   to   stakeholders,   uncover   their   concerns,   and   show   them  
    • that   they   are   being   addressed.   This   should   be   followed   by   a   report   that   relates   to   their   specific  area  and  concerns;  they  need  to  see  that  security  personnel  are  on  their  side!    Section  2:  Security  Drivers    2.1  Business  objectives    Security   professionals   exist   to   support   the   business.   Companies   are   driven   by   their   vision   and  mission  statements,  translated   into  business  strategies  that  describe  how  to  achieve  that  vision.  The  business  objectives  define  how  the  organisation  wants  to  achieve  its  targets.  If  a  business  objective  is  to  ‘Supply  customers  with  the  goods’,  the  security  objectives  should  be  to  protect  the  process  of  supplying  the  customer.  This  clear  link  between  business  and  security  objectives  can  sometimes  be  missing.      2.2  Legal  and  regulatory  requirements    Businesses  need  to  comply  with  legal,  regulatory  and  contractual  requirements  (listed  in  order  of  impact).  Legal  requirements  are  typically  related   A  practical  example    to   the   way   the   company   is   governed,   how   it   A  telecommunication  company  sells  mobile  phones  prepares   its   accounts   and   how   it   protects   the   and  call  plans  to  its  customers.  One  of  its  objectives  is  personal  data.  In  the  UK,  the  Company  Act  2006,   to  ‘Deliver  outstanding  customer  service,  measured  by  ‘part   15   Accounts   and   reports’,   states   clearly   the   customer  satisfaction’.  This  objective  is  supported  by  a  requirements   relating   to   how   accounts   are   business  process  ‘Customer  service’,  whereby  customer  created   and   reported.   It   also   includes   penalties   service  representatives  in  shops,  call  centres  and  online   talk  to  customers  to  solve  their  problems  and  answer  for  untrue  and  misleading  accounts.  In  the  USA,   questions.    the   Sox   legislation   was   created   after   major    financial  scandals.  The  Data  Protection  Directive,   Customer  satisfaction  is  dependent  on  a)  speed  to  Principle   7,   states   that   access   to   data   must   be   initial  contact,  and  b)  completeness  of  response.  The  limited  to  the  authorised  persons.  And  although   information  security  risks  identified  are:  1)  information  the   Data   Protection   Directive   does   not   state   systems  unavailable  or  slow  so  the  initial  response   time  is  affected;  2)  information  in  the  knowledge  base  which  security  controls  should  be  implemented,   system  is  inaccurate;  and  3)  the  customer  data  in  the  the   guidance   states   that   there   are   CRM  system  becomes  compromised,  resulting  in  a  fine  internationally   accepted   standards   relating   to   and  bad  PR.  building   information   security   systems   in   a    company.   From  this  quick  risk  analysis,  it  is  easy  to  understand     where  the  information  security  policy  needs  to  focus  and   what  the  security  objectives  should  be.As   a   result   of   this   legislation,   any   information  security   system   implementation   must   protect  data  and  information  systems  so  that  they  are:   a)  accurate  (in  security  terminology  the  word  ‘Integrity’  is  used)   b)  available,  and   c)  access  to  the  content  is  assured  (‘Confidentiality’  in  security  terminology).    2.3  Security  threats    Security   threats   affect   the   level   of   protection   (i.e.   control)   that   is   needed.   Threats   come   from  attackers   who   want   to   either   acquire   information   or   limit   business   opportunities   by   affecting  business   processes.   Microsoft   has   created  a   very  good  methodology  (STRIDE)  for  assessing  threats  and  designing  security  controls  to  prevent  threats  from  harming  business  processes.  The  role  of  the  security  model  is  to  capture  security  threats  and  design  security  objectives  and  controls  to  protect  the   business.   Security   intelligence   is   the   capability   to   analyse   security   threats   and   advise   what  controls  should  be  included  in  the  policy  framework.  
    • Section  3:  Security  Management    3.1  The  Policy  framework    This   is   the   first   element   of   the   ‘Security   Management’   part   of   the   model.   The   Security   Policy   is  usually   not   a   single   document,   and   rightly   so.   The   documents   in   the   Security   Policy   library   have  different  audiences  and  levels  of  detail;  see  Figure  2  below.   Figure  2:  Information  Security  Policy  framework CISO Business  and   Information  security  policy security   objectives Data  classification   Employee  acceptable   policy use  policy CIO Information  technology  security  policy Security   objectives IT  Security IT  security   standards [reuse   Architecture internationally   accepted  controls] Controls   Technology and   Security   Technical  teams processes architecture repository Processes Security  guidelines    3.1.1  Information  security  policy  The  primary  objective  of  the  Information  security  policy  is  to  state  business  objectives  and  high  level  security  objectives.  The  document  also  sets  accountabilities  for  ensuring  the  security  objectives  are  met.   The   document   should   be   owned   by   CISO   or   CSO   but   approved   by   the   Board;   as   the   Board   is  responsible  for  approval  of  business  strategy  and  objectives,  the  protection  of  these  are  obviously  in  the  Board’s  interest.    3.1.2  Data  classification  policy  The  top  level  policy  should  also  make  provision  for  a  data  classification  scheme,  which  can  then  be  detailed  in  the  Data  classification  policy.  Data  classes  depend  on  the  nature  of  the  business  but  at  the  minimum  should  include:    (i)  Public  data  that  are  in  the  public  domain.  It  is  a  mistake  to  assume  that  public  data  do  not  need  any  protection.  For  example,  take  a  company  homepage;  typically  this  is  information  that  a  company  wants  to  share  with  the  world,  i.e.  it  is  ‘Public’.  But  what  happens  if  the  information  on  the  website  changes  without  authorisation?  Examples  can  range  from  defacing  of  the  website,  to  unintentional  mistakes  by  employees,  mixing  the  product  description,  changes  in  prices  of  the  products  etc.  The  public   information   usually   needs   to   be   ‘accurate’   and   ‘available’,   but   obviously   there   is   no  requirement  to  keep  the  information  ‘confidential’.      (ii)   Company-­‐wide   data:  this  type  of  information  can  be  shared  between  employees  and  people  who  have  signed  an  NDA.  This  is  by  far  the  largest  category  of  information  in  most  organisations.  It  is  also  
    • referred   to   as   ‘semi-­‐public’,   and   the   bigger   the   organisation   the   greater   the   probability   of   leakage  from  employees  or  partners.      (iii)  Restricted  access  data:  some  information  will  be  accessible  on  a  need-­‐to-­‐know  basis,  depending  on   the   type   of   business.   Business   plans,   strategy,   research   data,   and   new   product   details   are   just  some  examples  of  the  information  that  should  be  well  protected.      3.1.3  Employee  acceptable  policy  This  policy  document  should  spell  out  the  most  important  policies  for  employees.  Good  security  and  HR   professionals   do   not   expect   users   to   remember   all   policy   documents.   The   objective   of   this  document  is  to  show  employees  what  is  critical  and  where  to  find  more  information.      3.1.4  Information  technology  security  policy  Most  companies  rely  on  information  technology  to  run  the  business  processes.  The  role  of  CIOs  has  become  to  support  business,  understand  where  the  company  wants  to  expand,  and  suggest  how  to  become   more   agile   and   cost   effective.   IT   can   be   a   saviour   or   a   nightmare,   depending   on   the   abilities  of  the  CIO.  The  security  policy  for  the  CIO  team  needs  to  translate  business  objectives  into  security  objectives  and  controls,  as  shown  in  Figure  3  below.     Figure  3:  Relationship  between  business  objectives  and  security  processes Provides  response   to  ‘Do  we  have  all  business  risks  covered?’ International  standards Control  C1 Control  C2 Security   Security objective   SO1 Control  C3 process  P1 Business   Control  C4 objective   BO1 Security   objective   SO2 Control  C5 Security   Business  process  B3 Business  process  B1 Business  process  B2 Business   process  P2 Control  C6 objective   BO2 Security   objective   SO3 Control  C7 Business   Security   Control  C8 objective   BO3 objective   SO4 Security   Control  C9 process  P3 Control  C10 Security   Security   objective   SO5 Control  C11 process  P4 Provides  response   to  ‘Why  are  we  doing  this?’      The   figure   shows   how   business   objectives   on   the   left   influence   security   objectives.   Each   security  objective   then   has   several   security   controls   (C1   to   C11)   and   these   are   implemented   by   security  processes.   Lastly,   the   business   processes   are   protected   by   the   security   processes.   Such   a   model  answers  two  critical  questions:    a)  Do  we  have  all  business  risks  covered?    b)  Why  are  we  spending  money  on  the  security  controls?      
    • Examples  of  security  objectives  are:   § Establish  security  governance   § Provide  security  training   § Manage  access  to  information   § Keep  systems  resistant  to  malware   § Establish  secure  systems/applications  processes   § Monitor  systems  for  security  events   § Manage  security  incidents   § Monitor  security  compliance    Each  security  objective  then  contains  a  number  of  security  controls.  These  are  typically  included  in  more  detailed  documents,  such  as  IT  Security  standards  and  security  artefacts.    Examples  of  security  controls  are:     § Create  the  training  material;  monitor  attendance  of  security  trainings           § Review  feedback  from  security  trainings   § Manage   accounts   in   the   IT   systems   –   create   accounts   for   new   users,   modify   when   role   changes  and  delete/disable  when  account  is  not  longer  needed   § Install   anti-­‐malware   software;   establish   and   implement   secure   configuration   for   each   operating   system   in   use;   update   configurations   on   systems   as   per   changing   threat   landscape;  patch  systems  with  vendor  patches  within  X  days    Each  control  needs  to  be  linked  to  one  or  more  security  objectives.  A  number  of  security  controls  is  part  of  a  security  process,  and  each  process  must  have  its  owner  and  must  be  measured.      Finally,   each   security   process   contributes   to   the   security   of   a   number   of   business   processes.   For  example,  the  security  process  ‘Security  configuration  &  patch  management’  ensures  that  IT  systems  used  in  the  business  process  ‘Take  order  from  customers’  runs  smoothly  and  as  expected.    3.2.  Security  standards    3.2.1  International  standards  for  security  policy  and  controls  Figure   3   shows   business   objectives,   which   will   be   specific   to   each   company.   However,   security  objectives,   whilst   supporting   the   Business   objectives,   should   be   selected   from   a   catalogue   of  internationally   recognised   ones,   and   international   standards   can   play   an   important   role.   It   is  important   to   understand   which   objectives,   controls   and   processes   to   take   ‘as   is’   and   where   a  customisation  is  needed.  Moreover,  there  might  be  business  objectives  and  business  processes  that  need   controls   that   are   not   included   in   the   international   standards.   Standardisation   is   needed   but  should  not  be  applied  blindly.  Standards  such  as  ISO27001  &  27005,  COBIT  4,  ISF  Standard  of  Good  Practice  (both  2007  and  2011  editions)  are  generally  extremely  useful.    3.2.2  Information  technology  standards  This   document,   or   set   of   documents,   contains   a   list   of   security   controls   related   to   the   technology  used  in  a  company.  As  mentioned  above,  these  controls  are  of  sufficient  detail  to  describe  what  is  required.   Further   implementation   information   is   usually   included   in   ‘Guidelines’   or   ‘Security  Artefacts’.      The  level  of  detail  included  in  technology  standards  will  range  from  high  level,  such  as  ‘Implement  account   creation   process   to   create   account   within   two   days   of   request’,   to   more   detailed,   such   as  ‘Use  Windows  2008  R2  server  with  configuration  W2k_DMZ  for  servers  located  in  the  DMZ’.        
    • 3.3  Security  architecture  repository    Consistency   is   key   in   information   security.   TOGAF   9   has   a   good   approach   to   standardisation   and  reusability,   as   does   the   SABSA   security   framework.   Standardisation   and   reusability   ensure   higher  maturity   in   information   security.   For   this   reason,   having   a   library   of   reusable   security   architecture  components  (artefacts)  is  extremely  important.        TOGAF  9  defines  artefact  as:     “A   product   that   describes   architecture   from   a   specific   viewpoint.   Examples   include   a   network   diagram,   a   server   specification,   a   use-­‐case   specification,   a   list   of   architectural   requirements,   and   a   business   interaction   matrix.   Artefacts   are   generally   classified   as   catalogues   (lists   of   things),   matrices   (showing   relationships   between   things),   and   diagrams  (pictures  of  things)  …  ”    In   the   context   of   an   information   security   model,   artefacts   are   re-­‐usable   for   the   creation   of  information  security  architecture,  either  a  technology  (such  as  ‘We  use  Cisco  firewall  and  this  is  how  it   is   configured’)   or   a   process   (such   as   ‘We   have   standardised   our   incident   response   process   and   this  is  how  it  is  done’).      The  technology  section  of  the  repository  should  contain,  for  example:   § Standard  set  of  technologies  used  in  the  company  (related  to  security)     § Configuration   standards   for   the   technologies   above   (e.g.   Windows   7   laptop   local   security   policy  object)   § Hardening  configuration  of  Web  servers,  DB  servers  and  other  servers.    The   process   section   of   the   repository   should   contain   standard   descriptions   for   security   processes,   in  a   detail   needed   to   replicate   the   process   in   another   part   of   the   organisation,   subsidiary   or   when  acquiring   another   company.   From   experience,   the   documenting   of   processes   is   not   a   strong   skill  base  of  many  IT  and  information  security  professionals.      3.4  Process  frameworks  and  metrics      3.4.1  Security  processes  As  stated  earlier  in  this  document,  and  shown  in  Figures  1  and  3,  security  processes  are  an  integral  part   of   the   security   model.   For   example,   ISACA,   the   organisation   behind   COBIT,   ensures   that   the  default   view   in   COBIT   is   based   on   processes,   where   each   process   is   defined   by   the   objective,  stakeholders,  maturity  levels  and  controls.      Another   international   standard,   ISM3   –   now   adopted   by   the   Open   Group   –   also   sees   security  processes  as  key  to  having  mature  security  systems.  Processes  in  general  often  have  a  bad  name  due  to  their  rigidity  and  over-­‐complex  set-­‐ups;  however,  it  is  important  to  understand  that  a  process  can  easily  be  made  complex  –  it  takes  skill  to  create  processes  that  are  lean  and  adaptive.      3.4.2  Security  metrics    Measuring  of  processes  in  any  company  is  one  of  the  key  techniques  to  ensure  that  inefficiencies  are  recognised   and   corrected.   Measurement   is   a   product   of   the   industrial   revolution;   Frederick   Taylor  published   Scientific   Management   in   1911,   a   revered   work   on   the   capacity   of   observation   and  measurement   to   improve   productivity.   By   the   same   token,   security   processes   must   be   observed,  monitored  and  measured  to  improve  them.      Security  and  metrics  is  a  largely  neglected  area  in  information  security.  There  are  some  exceptions,  such  as  COBIT,  which  brings  maturity  levels  for  CIOs  and  CISOs.  Another  promising  candidate  is  the  Common  Assurance  Maturity  Model  (CAMM),  which  brings  information  security  maturity  levels  into  the  supply  chain.    
    •  Gartner  has  researched  IT  and  security  metrics,  and  the  relationship  between  KPI  and  KRI  (Key  Risk  Indicators).   Furthermore,   what   the   business   leaders   are   interested   in   is:   ‘What   impact   do   security  controls   (or   lack   of)   have   on   the   business   processes   and   the   bottom   line?’   Security   professionals  have,  for  long  time,  used  the  FUD  (fear,  uncertainty  and  doubt)  approach  and  are  now  finding  this  does  not  resound  with  their  audiences.    It   is   also   accepted   that   maturity   of   security   controls   and   processes   inversely   affects   risks   to   the  organisation.  The  problem  many  security  professionals  face  is  in  having  to  justify  additional  costs  to  move  from  maturity  level  2  (repeatable)  to  3  (defined)  and  beyond.        With  this  in  mind,  it  would  be  prudent  for  organisations  to  measure:   § Basic  operational  metrics  to  keep  an  eye  on  processes  (i.e.  do  they  operate  as  expected?)   § Each  security  process  for  its  maturity   § Value  at  risk,  expressed  in  £s;  a  business  process  is  exposed  due  to  low  maturity  of  security   controls  (or  lack  of  them,  as  defined  by  COBIT  level  0)    The  first  two  metrics  are  fairly  straightforward  and  well  defined.  The  last  one  is  somewhat  new  to  information   security,   though   used   in   the   financial   arena   and   general   risk   management1.   For   the  purpose  of  this  paper,  it  is  worth  having  a  look  at  it  in  more  detail.    (i)  Value  at  Risk  The   main   problem   that   Value   at   Risk   is   trying   to   solve   is   how   to   quantify   the   exposure   that   an  organisation  is  subject  to.  Further  research  into  VaR  use  in  information  security  is  needed  to  make  the  concept  practical  and  reusable.      However,  the  input  elements  into  the  calculations  should  be:   § Business   asset   value   –   information   assets   alone   or   the   value   of   a   business   process.   A   company’s   PR   image   is   a   business   asset   and   in   this   case   should   be   assigned   a   value   by   consensus  rather  than  measurement     § Security   process   maturity   –   measure   the   maturity   of   process   (and   included   controls)   that   protect  the  business  asset   § Threat   landscape   –   threats   change   over   time;   for   example,   Sony   changed   the   threat   landscape   greatly   by   prosecuting   George   Hotz   for   breaching   the   PlayStation   T&Cs.   In   combination  with  the  vulnerabilities  in  their  systems,  it  cost  them  dearly.      The  high  level  calculation  of  the  VaR  is:   1.   Measure  the  maturity  of  the  controls.  Assume  that  maturity  level  5  provides  99%  (or  lower)   protection;  lower  maturity  levels  provide  less  protection.   2.   Analyse   the   control   to   find   compensating   controls;   two   low   maturity   controls   may   work   together  to  provide  higher  protection.     3.   Analyse  the  threat  landscape  and  derive  the  likelihood  that  the  threat  agents  will  attempt  to   attack.     4.   Use   the   above   and   the   asset   value   to   come   up   with   a   probability   distribution   of   monetary   exposure    The   pound   value   for   each   asset   can   be   collected   and   summarised   in   order   to   calculate   the   total  exposure  probability  distribution.  This  will  give  CIOs  and  CISOs  a  very  useful  tool  to  demonstrate  the  risks  to  the  executive  management  and  thus  justify  the  spending.      Detailed  calculations  of  Value  at  Risk  for  information  security  have  not  yet  been  developed  and  need  further  research.  Value  at  Risk  could  also  be  used  to  justify  security  investments,  i.e.  the  reduction  in  VaR  should  be  higher  than  the  cost  spent.        
    • Conclusion    Information  Security  Risk  Management  must  support  the  business  objectives.  Security  professionals  should   have   open   dialogue   with   business   leaders   and   managers,   listen   to   their   concerns,   and  frequently  educate  them  about  risks.    The  security  model  can  help  with  explaining  why  security  is  important,  and  can  support  justifications  for  that  ‘rather  expensive’  piece  of  technology,  depending  on  the  point  of  view,  security  policy  and  business  appetite  for  risk.        1   McNeil,  Alexander;  Frey,  Rüdiger;  Embrechts,  Paul  (2005).  Quantitative  Risk  Management:  Concepts  Techniques  and  Tools.  Princeton  University  Press.  ISBN  978-­‐0691122557.        About  the  author    Vladimir  Jirasek  is  a  passionate  information  risk  professional  with  more  than  16  years  of  IT  industry  practise  and  over  11  years  in  Information  Security  and  IT  Security,  Risk  and  Compliance  disciplines.  He  has  both  led  and  managed  global  teams  in  Security,  Risk  and  Compliance  for  multinational  corporations  such  as  Nokia,  Tesco,  and  DTAG.      In  his  own  time  he  tries  to  give  something  back  to  the  security  community  by  participating  in  a  variety  of  key  industry  initiatives,  such  as  the  Common  Assurance  Maturity  Model  (common-­‐assurance.com),  Cloud  Security  Alliance  (cloud-­‐security.org.uk);  and  the  Open  Group’s  Jericho  forum,  working  together  with  industry  experts.    He  can  be  contacted  at  vladimir@jirasek.eu  or  on  +44  (0)  7538  790302