Re-Thinking BYOD Policy.pptx
 

Re-Thinking BYOD Policy.pptx

on

  • 239 views

This presentation provides an overview of the fundamental considerations, research-based recommendations and best practices across application, device and policy-based models.

This presentation provides an overview of the fundamental considerations, research-based recommendations and best practices across application, device and policy-based models.

Statistics

Views

Total Views
239
Views on SlideShare
239
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

Re-Thinking BYOD Policy.pptx Re-Thinking BYOD Policy.pptx Presentation Transcript

  • Forget About BYOD: Develop a Realistic Mobile Security Policy m  Bain   ector,  Product  Marke4ng  curity  Innova4on  
  • ector,  Product  Marke0ng,                                  curity  Innova0on   merly  with  Q1  Labs  (an  IBM  Company)  d  Applica0on  Security,  Inc.  0ve  blogger,  presenter   ,  Communica0ons,  RIC;  MS,  Interna0onal   a0ons/Public  Affairs,  UMASS   Thomas  Ba
  • YOD  Dilemma:     ts/Trends    vs  IT  Sec  Need  hy  it’s  a  security  risk  ifferences  Between  App  &  IT  Sec  olicy   remental  policy  construc0on  al-­‐world  policy  improvement  ecommenda0ons  eps  you  should  consider  
  • plication Security Experts +  Years  vulnerability  research    curity  Tes0ng  Methodology  adopted  by  SAP,                croso,  Symantec   thors  of  8+  books   ducts and Services andards  -­‐  Best  Prac0ces   uca0on  -­‐  CBT  &  Instructor-­‐Led  sessment  -­‐  Soware  and  SDLC  ducing Application Security Risk 0cal  Vulnerability  Discovery  cure  SDLC  Rollout  
  • BYOD: Security Challenges are Emerging
  • ile  devices  help  employees  increase   uc0vity  –  staying  connected  is  not   y  op0onal  anymore!  ge  has  experienced  a  massive  up0ck:    of  today’s  workforce  is  using  a  rtphone  specifically  for  business  use.   struggling  to  keep  up  with  device   agement.   ility  by  its  nature  opens  up  a  larger  ck  surface  with  more  points  of  entry.  cult  to  measure  business  need  ugh  IT  Security  lens.  eloping  a  policy  isn’t  as  easy  as  it  ht  seem.  
  • s  lose  autonomy  with   rity  policies  that  aren’t  well-­‐ ned.   ormance  +  capabili0es  oen  mp  security  =  IT  headache.     s  expect  an  always-­‐on,   re  connec0on  and   0onality   e  to  market  pressures  hurt   rity:  But  good  architecture   backend  systems  can  help.   Frameworks  like  PhoneGap   get  to  market  quickly:  But  can  
  • %  use  the  same  smartphone  for  rk  and  for  personal  usage.  %  of  employed  adults  use  at  st  one  personally  owned  ctronic  device  for  business   rris  Interac0ve  survey,   ruary  2012)  %  of  employees  surveyed  use  bile  devices  to  run  line-­‐of-­‐ iness  applica0ons  (Ibid)  %  of  companies  allow  BYOD   ge  in  some  manner  (Aberdeen   up,  February  2011)  
  • %  of  companies  have  experienced  ata  breach  due  to  inadequate   ice  security  (Ponemon  survey,   2)  %  don’t  have  a  password  on  their  bile  phone.  %  stated  their  companies  couldn’t   cute  a  remote  wipe  if  lost  or   en.  %  said  mobile  security  has  not   n  addressed  with  them  by  IT.  
  • Device Security consistent  security  policies   ptop  encryp0on  bypass  mode  nmanageable  devices   ared  media  leakage   inimal  device  management  eadable  data  on  disposed-­‐of  evices  ter-­‐applica0on  data  leakage  
  • On Pace for Increased Incidents
  • Why is BYOD a Security Problem evice  turn-­‐over:  What  happens  to  the  old  device?     ew  devices:  Default  or  customized  setngs?   ow  can  you  know  everything  about  every  device?   ware  updates  –  user  vs  IT.   pp  Stores:  Approved  apps?     pplica0ons:   What  data  is  on  your  device?   What  enterprise  applica0ons  can  you  connect  to?   Which  apps  are  connected  to  other  apps?  EX:  Your  blog  app  is connected  to  your  CMS,  which  feeds  to  Twiger,  etc.    
  • bile Traditionalnerabilities Vulnerabilities
  • BYOD: AppSec vs InfoSec Polic
  • Information Security Application Security Based Receptionist, IT Manager, • Architect, Developer, Tester etc • Application Roles and Privileges w to Rollout and Rollout of web application firewall and secure ement configuration of servers, development best practices databases, anti-virus, • Application Authentication checks communications, • Secure Design components certificates, etc. • Attack surface reduction • Code hardening • Data Encryption • Input validation ertise IT networking, database • How applications interact with environment ded to and computer/OS • How applications function and fail with respeement configuration skills security • Software development skills w/ security over
  • Policy Statement Comparison etwork  Security  Control  Enable  SSL  on  the  web  server.  Don’t  transmit  sensi0ve  data  via  IM  chats.  (Actually  a  policy  statement  in  PCI-­‐DSS)  atabase  Security  Control  Configure  DB  server  so  sensi0ve  data  stores  are  encrypted.  hysical  Control   Shred  documents  that  contain  sensi0ve  data.  pplica<on  Security  Control  Encrypt  sensi0ve  data  during  transmission.  Web  facing  applica0ons  must  be  resilient  to  SQL  injec0on  agacks.  
  • SQL Injection Policy ✔  MINIMUM   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks.  ✔✔  BETTER   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks  by  sani4zing  all  use put.    ✔✔✔  GOOD   uild  web  applica0ons  that  defend  against  SQL  injec0on  agacks  by  sani0zing  all  use put  using  this  approved  sani4za4on  rou4ne.  ✔✔✔✔  EXCELLENT  …..plus   •  Soware  Developers  do  X   •  Soware  Testers  do  Y    
  • Protect Sensitive Data  MINIMUM  otect  sensi0ve  data.     ✔  BETTER  otect  sensi0ve  data  by  using  this  approved  encryp4on.   ✔✔  GOOD  otect  sensi0ve  data  by  using  this  approved  encryp0on  in  databases  that  store  and  ring  transmission  of  sensi4ve  data.   ✔✔✔ EXCELLENT  plus  •  Architects  define  algorithms.  •  Developers  never  write  their  own  crypto.  •  Test/QA  verifies  XYZ.  
  • Cross-Site Forgery MINIMUM  ate  applica0ons  that  are  resilient  to  Cross-­‐Site  Request  Forgery.     BETTER  ate  soware  applica0ons  that  are  resilient  to  CSRF  agacks  by  using  the  OWASP  TopRF  Cheat  Sheet.”    ✔✔  GOOD  ate  soware  applica0ons  that  are  resilient  to  CSRF  agacks  by  using  the  OWASP  Top CSRF  Cheat  Sheet”  and  implement  a  language-­‐appropriate  framework.    ✔✔✔ EXCELLENT   us   Use  challenge-­‐response.   QA  check  reference  headers.  
  • App Pen Testing icy:  Conduct  annual  tests  of  internet  facing  applica0ons.”  w  to  improve  it  pecify  the  type  of  test,  e.g.,  web  vulnerability  can,  source  code  review,  paper  audit,  etc.   ow  deep  should  it  go  /  What  should  be  tested?  Ø OWASP  Top  10  vulnerabili0es   efine  the  key  assets  you  are  trying  to  protect.  pecify  which  agacks  should  be  conducted.  Ø Threat  modeling  in  advance  can  guide  you  here.  
  • cy  Ensure  applica0ons  processing  data  properly  authen0cate  sers  through  central  authen0ca0on  systems  where  ossible.”    f  addi0onal  func0onality  is  needed,  coordinate  evelopment  with  Informa0on  Technology  Services.”    w  to  improve  it  ere  is  our  approved  authen0ca0on  library  <URL>.  emove  ambiguity.    “coordinate  with  ITS”   •  Rather,  obtain  wrigen  excep0on  for  using  any   authen0ca0on  mechanism  not  explicitly  approved  by   InfoSec  Office    
  • cy   QL  Injec0on  vulnerabili0es  must  be  prevented.”   e  OWASP  QL_Injec0on_Preven0on_Cheat_Sheet    for   commenda0ons.    to  improve  it   e  Parameterized  SQL  statements  and  stored   ocedures.   e  white-­‐lis0ng  to  constrain  user  input.   e  company-­‐approved  sanita0on  library,     und  here  <URL>.  
  • olicy   “Ensure  applica0ons  validate  input  properly  and  restric0vely,   allowing  only  those  types  of  input  that  are  known  to  be  correc …”examples  include,  but  are  not  limited  to,  cross-­‐site  scrip0ng buffer  overflow  errors,  and  injec0on  flaws.”     “…see  hgp://www.owasp.org  for  more.”    ow  to  improve  it  Use  this  input  sanita0on  rou0ne  <URL>.  Validate  Input  from  all  sources  For  Type,  Length,  Format,  and  Range.  Iden0fy  all  source  of  input  and  verify  validators    have  been  used  to  check  input.  
  • III. BYOD: Policy Development to Fit Your Business
  • onsider  risk  scenarios.   dapt  from  proven  or  trustworthy  models.  Measure  percep0on.   nderstand  roles,  privileges  and  what’s  in  place  today.   et  granular  with  your  ques0ons  &   onsidera0ons.   gure  out  a  strategy  for  tes0ng  your   pplica0ons.     olicy  enforcement.   aise  awareness/required  training.  
  •  an  inventory  of  your  high-­‐risk   ica0ons/mobile  applica0ons.  ermine  business  cri0cality.     t’s  your  agack  probability?    do  you  define  the  agack  surface?  sider  overall  business  impact.   re  does  compliance  factor  in?   t  are  the  security  threats?  
  • Trustworthy Sources
  • tudes  of  general  popula0on  ward  security  (suppor0ve,   agonis0c,  indifferent?)   tudes  of  general  popula0on  ward  management  (suppor0ve,   agonis0c,  indifferent?)     tudes  of  management  toward   urity?   at’s  the  percep0on  of  the  current  OD  policy?   e  there  been  related  security   dents?    
  • h  departments/groups/individuals    been  most  ac0ve  in  developing   ies?     here  been  any  previous   bora0on  between  policies  and   ors?  you  iden0fy  a  poten0al  champion(s)   pport  the  new  policy?    s  of  agreement  in  commonly  emented  controls  re:  policies?   ort  documents,  materials  and  ed  policies  should  be  cited  in  mobile  ce  policy.  w  who  has  access  to  what  and  how  
  • w  will  mobile  devices  be  used?  vices  assigned  to  one  person  or  shared?    hich  mobile  applica0ons  would  be  used?  hat  informa0on  is  accessible  through  mobile  devices?    hat  informa0on  will  be  stored  on  the  mobile  devices?     w  will  data  be  shared  to/from  and  between  mobile  devices?    ho’s  ul0mately  responsible  for  mobile  devices?     l  personal  ac0vi0es  on  company  devices  be  permiged?    hat  levels  of  support  are  expected?    
  •  sensi0ve  is  your  data?   t  kind  of  data  is  it?  PII,  customer   ,  credit  card  data,  proprietary,  IP,  subject  to  regulatory  mandates?  ch  ones?  duct  a  threat  model:   termine  threats  en0fy  poten0al  agacks  nderstand  the  frequency  &  severity   th  which  they  are  executed.  
  • Application Criteria hreat Sensitive Compliance Custo Lifespan ating Data Stringency Faciier 1 Restricted Long High Yeier 2 Private Mid Medium Yeier 3 Public Short N/A No
  • Depth, Breadth, Frequency reat Static Dynamic Manual Pen Threting Analysis Analysis Test Mode Complete/ Complete/ Complete/ Compl Frequency Frequency Frequency Freque Required/Major Required/Major Required/Per Requireer 1 code changes code changes Milestone Relea Suggested/ Required/ Required/Per Suggesteer 2 Monthly Quarterly Release Relea Optional/ Required/ Optional/As Optioner 3 Quarterly Annually Needed Need
  • scribes  contextual,  technical  guidelines  on  how  security  shouldegrated  within  the  SDLC   y  phase,  role,  technology,  applica0on  type  everages  internal  secure  development  champion(s)  for  input   ps  to  compliance  mandates  nsiders  cri0cality  of  applica0on  and  data   equirements,  ac0vi0es  and  level  of  detail  needed  will  differ  s  clear  excep0on  policy  What  if  minimum  standards  can’t  be  met?  What  is  considered   cceptable?  Who  approves?   ludes  internally  built  and  third  party  applica0ons  flects  current  maturity  and  secure  development  skills  he  more  skilled,  the  less  explicit  you  need  to  be  with  policies  
  • u  need  management  buy-­‐in!  oad  strategy  vs  Targeted  strategy  roll-­‐out  n-­‐boarding:    Require  all  device  info  as  part  of  hiring  process  (especially  applica0ons)  Require  policy  training  up  front   quire  training  for  various  departments:  General  popula0on  receives  awareness  training  Technical  employees  receive  in-­‐depth  training  onitor  for  effec0veness  –  EX:  Deliver  training  or  reminder  hen  employee  is  out  of  compliance.    
  • Thank You!! tbain@securityinnova4on.com   TwiWer:  @tmbainjr1