Se#ng  up  (Product)  Enterprise  Architecture  program  

Max  Poliashenko  Chief  Enterprise  Architect  Wolters  Kluwer,  Tax  and  AccounCng  May  22,  2015,  Stockholm,  Sweden  

ITARC 2015 1

Presenter  

Max  Poliashenko  Chief  Enterprise  Architect  Wolters  Kluwer,  Tax  &  AccounCng  

Max  leads  the  Enterprise  Architecture  pracCce  across  WK  T&A  and  defines  its  Technology  Strategy  as  well  as  oversees  the  architecture  of  its  soLware  product  lines.  He  chairs  the  Architecture  Review  Board,  which  performs  EA  governance.  Max  is  based  in  Atlanta,  USA  Prior  posiCons  included:  Chief  SoLware  Architect  at  Sage,  Enterprise  Architect  at  Bank  of  America      Max  is  acCve  in  the  IT  Architecture  community,  being  one  of  the  founders  of  IASA  Atlanta  chapter.  He  has  served  on  IASA  Architect  EducaCon  and  CerCficaCon  commiUees.  Max  is  IASA  Fellow,  holds  MicrosoL  CerCfied  Architect  and  CITA-­‐P  cerCficaCons,  and  served  on  mulCple  CITA-­‐P  and  MCA  boards  

n World’s  largest  provider  of  tax,  accounCng  and  audit  informaCon  n Content  from  more  jurisdicCons  than  any  other  provider  n Leveraging  global  pla[orms,  delivering  customized  soluCons  

Please,  introduce  yourself  

•  Name  •  Company  and  its  Business  domain  •  Your  Architectural  SpecializaCon,  if  any  •  Are  you  part  of  SoLware  Development  organizaCon?  

•  Do  you  have  Enterprise  Architecture  team?            If  not,  have  your  done  Enterprise  Architecture  or  Security  Architecture?  

•  Your  ExpectaCons  from  this  workshop  

ITARC 2015 4

Topics  that  we  will  cover  •  Enterprise  Product  Architecture  and  Business  case  for  it  – Exercise:  Formulate  Business  and  Technology  strategy  

•  EPA  Governance  – Exercise:  Enterprise  collaboraCon  game  

•  Example  of  Enterprise  Program:  SoLware  Security  Assurance  

MODULE  1:  Enterprise  Product  Architecture  (EPA)  

Problem  Statement:  

•  Company  X  has  many  soLware  applicaCons  that    it  built  or  acquired  over  Cme  •  They  include  various  technologies  and  uncoordinated  so1ware  

architectures    •  Architectural  frameworks  are  disparate  &  redundant  •  SoLware  products  have  had  varying  investment  cycles:  some  products  are  

re-­‐architected  while  some  have  had  not  been  modified  since  being  acquired  

•  There  is  very  li7le  reuse  of  soLware  frameworks,  components  and  other  assets  

•  Ownership  &  knowledge  is  maintained  at  a  product  level  and  not  shared  

EvoluCon  leads  to  more  Complexity    

•  New  products  developed  and  acquired  •  Need  to  renovate  exisCng  products  •  Dependencies  on  3rd  party  components  •  Complex  integraCons  between  products  and  3rd  parCes  •  IntegraCon  with  other  products  sold  by  their  own  company  •  Dependencies  on  frameworks,  pla[orms  and  reusable  components  built  by  other  development  

teams  •  Necessity  to  coordinate  3rd  party  technologies  and  component  dependencies,  also  leveraged  by  

other  products  in  their  enterprise  •  Constant  upgrade  cycles  of  3rd  party  technologies  they  are  dependent  upon  •  MulC-­‐generaConal,  mulC-­‐year  development  programs  •  Enterprise-­‐wide  infrastructure  iniCaCves,  oLen  driven  by  internal  IT  and  tradiConal  EA  •  Enterprise-­‐wide  agreements  with  soLware  vendors  affecCng  choices  and  costs  of  the  available  

technologies  •  MulCple  similar  technologies  and  capabiliCes  developed  over  and  over  again  by  different  product  

teams    

Business  impact  

•  DuplicaCon  of  the  effort  •  Inconsistent  customer  experience  •  Poor  integraCon  between  company’s  products  •  Difficulty  to  create  suites  of  products  and    assemble  new  soluCons  –  impacts  Cme  to  market  

•  Slow-­‐down  in  innovaCon  •  Increased  costs  of  OperaCons  and  Customer  Support  

Answer:  Enterprise  Product  Architecture  

•  The  tradiConal  Enterprise  Architecture  is  well  established  •  Its  pracCces  are  constrained  by  the  limits  of  the  Enterprise  •  New  IT  Architecture  pracCce  is  emerging  from  the  pracCcal  need  

of  SoLware  Product  companies  -­‐    Enterprise  Product  Architecture.    •  Its  scope  is  defined  by  por[olios  of  soLware  products  that  ISVs  are  

offering  to  their  customers,  and  it  virtually  extends  into  customers’  enterprises,  including  other  IT  products  that  are  used  by  customers,  and  various  processes  that  exist  in  their  organizaCons  

•  This  changes  many  assumpCons  and  standard  pracCces  of  tradiConal  EA,  while  confirming  and  validaCng  others  

OpportuniCes  and  Goals  of      Enterprise  Product  Architecture  

•  Establishing  Enterprise  Product  Architecture  pracCces  responsible  for  Product  Technology  strategies,  governing  its  strategic  technology  investments  across  Enterprise  

•  Increased  reuse  and  leverage  of  technology  assets,  including  pla[orms,  frameworks,  soLware  components,  paUerns,  code,  etc.  

•  Sharing  of  Knowledge,  Best  PracCces,  Guidelines,  Standards,  POC  results    •  Decreased  Product  Development  Cycle,  Time  To  Market  and  Development  

Cost  •  Flexibility  in  creaCng  new  products  by  assembling  components  and  features  •  Improved  integraCon  between  various  products  •  Improved  posiCve  Customer  experience  •  Reduced  cost  of  Customer  Support  

EPA  vs.  tradiConal  EA  

•  Specifics  of  Enterprise  Product  Architecture  –  Building  is  prevalent  to  buying  –  SoluCons  oLen  require  creaCve  approach  and  comprise  IP    –  OLen  start  with  building  product  pla[orm  first  –  Is  Cme  constrained  by  product  release  dates/  customer  calendar  –  Customers  span  a  range  of  segments,  are  mostly  anonymous,  represented  by  Product  

Management  and  Customer  Support  –  Must  support  a  variety  of  deployment  environments  with  liUle  control.  End-­‐integraCons  are  

less  predictable  –  Must  support  some  sort  of  API/SDK  

•  SimilariCes  with  Internal  IT  Enterprise  Architecture:  –  Inter-­‐product  integraCons,  SSO  –  RaConalize  services,  capabiliCes,  technologies  –  MGP,  technology  roadmaps,  target  and  reference  architectures      

 

Architect  roles  in  enterprise  

•  All  architect  specializaCons  are  included  

•  Specialists  cover  appropriate  areas  

•  Value  “rolls  up”  •  Value  is  clear  to  

business  •  Career  growth  

supported  

Product  Por)olio  or  Pla)orm  

Business  Unit  1   Business  Unit  2   Opera7ons  

Data  Centers  

Solu7ons  Architects  

So=ware  Architect  

So=ware  Architect  

Mobility  Architects  

Informa7on  Architects  

Infrastructure  Architects  

Enterprise  Architects  

Business  Analy7cs  Architects  

Security  Architects  

So=ware  Architect  

What  Does  EPA  Mean  to  Development?  

•  Technology  pla[orms  and  frameworks  are  consistent  across  product  lines  •  BeUer  portability  of  development  skills,  leveraging  experience  of  other  teams  •  Easier  integraCon  between  products  •  Faster  new  product  development  take-­‐off  •  Uniform  development  tools  and  processes  •  Common  development  standards  and  guidelines  •  Lower  risks  and  unknowns  in  adopCng  new  technologies  •  Common  and  familiar  architectural  paUerns  •  Faster  and  more  direct  access  to  technology  vendor  resources  (e.g.,  MS  TAP)  •  ConcentraCng  of  building  applicaCon  funcConality  instead  of  plumbing  •  Can  afford  to  have  architect  specialists  such  as  security,  mobile  technologies,  

BI/BA,  data  warehousing,  DBA,  QA  automaCon,  etc.    •  More  efficient  leveraging  deployment  and  operaCon  resources    

What  Does  EPA  Mean  to  Other  Stakeholders?  

•  Product  Management  –  “Go  to”  Technology  person  that  is  aligned  with  your  Market  &  Customers  –  BeUer  technology  ve#ng  

•  AcquisiCon  due  diligence  •  Partnering  opportuniCes  

–  ComponenCzed,  modular  Products  lines  -­‐  not  monolithic  apps  in  a  silo  –  MGTPs  in  relaCon  to  MGPPs  

•  Customer  Support  –  BeUer  supportability,  resiliency  and  integraCon  of  products  –  Decreased  complexity  &  disparity  in  product  architectures  

•  Sales  –  Products  that  are  architected  to  meet  customer  demands  first  Cme  out  –  Products  that  integrate  well  together  –  Key  technology  resources  to  beUer  educate  and  answer  technology  quesCons  –  Single  point  of  contact  for  pre-­‐sale  technical  quesCons  about  mulCple  products  

 

EPA  CAPABILITY  Maturity  Model  

http://iea.wikidot.com/ea-maturity-model

First  Steps:  DEFINE  Strategy  

•  One  of  the  main  goals  of  EPA  is  in  establishing  Product(s)  Technology  Strategy,  which  would  translate  into  mulC-­‐year  technology  roadmaps  for  products  and  product  lines.  Their  purpose  is  to  strategically  guide  technology  investments  across  the  Enterprise  

•  Product  Technology  Strategy  should  support  Product  Business  Strategy  

•  Do  you  know  your  Business  Strategy?    

Describing  your  business  model  The business model canvas

OFFER

CHANNELS

RELATIONSHIPS CLIENTS

REVENUE STREAMS COST CENTRES

KEY PARTNER

KEY RESOURCES

KEY

ACTIVITIES

Source:  Canvas  by  businessmodelgenera7on.com

Who‘s your customer?

Which

customer segments do you serve?

What‘s your offer?

Which „jobs to be done“ do you satisfy?

What‘s your relationship to the customer? What‘s your

image?

How do you reach your customers?

How do you make money?

What is driving cost?

What are your core activities

and processes? You are your

main suppliers,

partners and alliances?

What are your main assets and competencies?

Four  AcCons  Framework  •  Reduce  

–  Which  factors  should  be  reduced  well  below  the  industry’s  standards?  

•  Eliminate  –  Which  of  factors  that  the  

industry  takes  for  granted  should  be  eliminated?  

•  Raise  –  Which  factors  should  be  

raised  well  above  the  industry’s  standards?  

•  Create  –  Which  factors  should  be  

created  that  the  industry  has  not  offered?  

New  Value  Curve  

Reduce  

Create  

Raise  

Eliminate  

Norton  &  Kaplan  Strategy  Map  

Norton & Kaplan Strategy Map Discussion

•  Who does this map speak to?

•  Is any one perspective or objective more important than the others?

•  How does this tool communicate the breadth spectrum of involvement?

•  What is the common goal to be realized by everyone’s efforts?

Print  and  distribute  the  Strategy  Map  to  everyone  involved!  

[yellow  tail]  Blue  Ocean  Strategy  

Exercise  (10  minutes):    Formulate  your  Enterprise’s  business  

and  IT  strategy  

ITARC 2015 24

Enterprise  Product  and  Assets  Inventory  

•  InformaCon  about  various  products,  product  lines,  pla[orms  and  frameworks,  as  well  as  of  the  supporCng  teams  is  maintained.    

•  More  formal  methods  and  tools  of  ApplicaCon  Por[olio  Management  used  by  tradiConal  Enterprise  Architecture  can  be  applied  here  to  raConalize  these  soLware  and  technological  assets  

•  Example  of  product  informaCon  collected:  –  BU;  Name;  Product  Line/Pla[orm  name;  DescripCon,  Product  Categories,  Customers  and  Users,  Annual  Revenues,  Deployment  model,  Product  Life  Status,  Server  Side  technologies,  Client  side  technologies,  Dev  Tools  and  languages,  Product,  Development,  Architecture  owners,  DocumentaCon  site,  HA,  DR,  Monitoring  capabiliCes,  etc.,  etc.  

Enterprise  Technologies  Inventory  

•  InformaCon  about  technology  dependencies  such  as  OS,  pla[orms,  development  tools  and  frameworks,  3rd  party  components,  etc.  

•  Also,  to  locate  products  and  teams  using  parCcular  technology  for  impact  analysis  or  experience  sharing  

•  The  goal  is  to  understand  and  start  raConalizing  the  technology  stacks  and  3rd  party  components  

•  Eventually,  used  for  Technology  Lifecycle  Management  

Module  2:  EPA  Governance  

Define  Governance  

What  goes  into  governance?  •  EA  Goals  (IT  Strategy)  •  EA  Principles  •  Policies  •  Standards  •  Guidelines  •  Governance  Roles    •  Processes  and  RACI  matrixes  

•  Metrics  and  ReporCng  

 

Governance  Body:  Architecture  Review  Board  (ARB)  

Architecture  Review  Board  ResponsibiliCes  

•  Set  Enterprise  Product  Architecture  Principles,  Goals,  Policies,  Standards  and  Guidelines  

•  Perform  ApplicaCon  Por[olio  Management  (MGP):  –  Review  and  approve  Strategic  Projects  Architectures  and  their  readiness  –  Review  and  approve  Strategic  Product  Technology  Roadmaps  –  Review  and  approve  Pla[orms  and  Por[olios  Technology  Roadmaps  –  Review  and  approve  TAA  Product  Enterprise  Technology  Roadmap  

•  Discuss  and  act  on  any  Technology  and  Architecture  Issues  with  cross-­‐Enterprise  Concerns  

•  Issue  guidelines  on  vendor  technologies  usage  and  manage  vendor  technology  lifecycle  

•  Charter  EPA  iniCaCves    

What  Things  are  Reviewed  by  ARB  

•  Enterprise  Architecture  Principles,  Goals,  Policies,  Standards,  and  Guidelines  

•  Requests  for  EPA  governance  excepCon  waivers  •  Strategic  Product’s  architectures,  their  target  states  and  roadmaps  •  Strategic  Project’s  architecture  designs,  their  interim  reviews,  and  

product  readiness  reviews  •  Reviews  of  emerging  technology  POC  plans  and  their  results    What  doesn’t  require  ARB  review:  •  RouCne  project’s  SoLware  Architecture  Documents  with  no  excepCons  

or  excepCons  that  are  agreed  to  be  remedied  •  Other  work  by  Product  Architects  which  have  no  Enterprise  impact  or  

can  be  reviewed  by  Enterprise  Architects    

Other  EPA  Work-­‐streams  

•  Formalize  Product  and  Enterprise  Architect  roles.  Help  in  hiring  key  architecture  resources      

•  Providing  Architect  training    •  Facilitate  Technology  innovaCons,  conducCng  and  coordinaCng  POCs  •  Managing  technology  partner  relaConships  (MSFT,  IBM,  Dell,  Cloud  

Providers,  Citrix,  Adobe,  etc.)    •  ParCcipaCon  in  Merger  &  AcquisiCon,  and  Partnership  due  diligence  •  SupporCng  focused  iniCaCves  related  to:  re-­‐architectures,  

performance,  scalability,  supportability  or  security  improvements  •  CollaboraCon  with  other  IT  organizaCons  (back-­‐office  and  Internal  IS  

systems)      

Challenges  for  EPA  

•  Successfully  navigaCng  Corporate  poliCcs:  –  Get  CooperaCon  and  CollaboraCon  from  various  BUs  and  dev  teams  

•  Ensuring  technology  Ces  into  Business  need  and  direcCon  –  Technology  with  a  purpose  –  Minimize  skunk  work  without  business  cases  

•  Enterprise  Architecture  cannot  be  a  boUleneck  to  execuCon  and  agility  –  Managing  dependencies  

•  Manage  technology  change  with  investment  cycle  –  Manage  MGTP  –  Bunch  technology/architecture  upgrade  with  feature  work  

•  Formalize  Architect  career  path  –  ParCal  resources  performing  architecture  roles  –  Deliver  Architect  training,  mentorship  and  learning  resources  

 

Steps  to  Set  up  EPA  

•  Create  Architecture  Review  Board  •  Define  Enterprise  Architecture  Principles  and  Goals    •  Start  Defining  Policies,  Standards  and  Guidelines    •  Create  Product  Por[olio  Inventory  (see  Appendix)  •  RaConalize  Products  and  Technologies.  Decide  where  to  invest  

strategically  and  what  to  sunset  •  IdenCfy  Reuse  OpportuniCes  across  Product  Por[olios  and  

Geographies.  Concentrate  on  few.  Make  them  successful  •  IdenCfy  products  that  can  be  sold  globally.  Drive  their  GlobalizaCon  •  Create  Strategic  Product  Architecture  and  Technology  Roadmaps  •  Create  Por[olios  Architecture  and  Technology  Roadmaps  •  Create  Enterprise  Technology  Roadmap    

BREAK  and  TEAM  Game  Rules:  

n  You  are  given  2  cards,  red  and  green  

n  If  ALL  players  play  GREEN  card,  each  receives  +1  point  

n  If  ONE  player  shows  RED  card  and  others  show  GREEN,  the  RED  card  gets  3  points,  and  others  get  –  1  

n  If  TWO  or  THREE  players  show  RED,  each  gets  1  points,  GREEN  cards  get  -­‐1  each  

n  If  ALL  players  show  RED,  each  gets  -­‐1  point  

n  You  will  play  10  rounds.    

n  You  cannot  communicate  with  each  unless  the  moderator  allows  

n  You  will  be  given  1  minute  for  deliberaCon  on  each  round  

n  Please,  keep  tally  of  your  points  

MODULE  3:    SOFTWARE  SECURITY  ASSURANCE  PROGRAM    

Wolters Kluwer Confidential 37

DramaCc  Changes  in  IT  Security  Environments  

•  Security  landscape  has  substanCally  changed  in  the  recent  years:  the  number  of  breaches  and  their  financial  and  reputaConal  impact.  

•  Automated  penetraCon  tools  are  becoming  more  main  stream  and  aUacker’s  barrier  of  entry  is  lower  and  lower  

•  The  corporate  IT  perimeter  is  rapidly  eroding  with  data  in  the  Cloud,  hybrid  deployments,  BYOD  devices,  etc.    

•  The  aUackers  no  longer  doing  it  just  for  fun  and  bragging  but  to  exploit  the  compromised  assets  for  financial  or  poliCcal  gains    

•  The  government  agencies  are  also  rapidly  expanding  security  regulaCon  and  levels  of  responsibility  of  applicaCon  providers  

•  Average  cost  of  dealing  with  a  compromised  record  -­‐  $1.2K    •  Many  companies  are  spending  millions  and  billions  to  raise  their  security  defenses  

38

HolisCc  Security  Ecosystem  –  Defense  in  Depth  

•  Infrastructure  and  Perimeter  –  Firewalls,  anC-­‐malware,  Intrusion  DetecCon  and    PrevenCon  systems  –  Secure  se#ngs  on  Routers,  Switches  

•  IT  Controls    –  User  account  management,  password  expiraCon  policies  –  LimitaCon  on  privileges  and  access,  on-­‐boarding  and  off-­‐boarding  

•  Human  Behavior  –  Clicking  on  links  with  unknown  origins  –  Bringing  in  personal  device  into  workplace  and  plugging  into  company  network  –  Rogue  employee  

•  Physical  Access  and  Devices    

–  Physical  security  of  Data  Centers  –  Securing  company  user  devices,  including  mobile,  which  may  have  customer  data  

•  ApplicaNon  Code  –  the  focus  of  SSA  –  Security-­‐conscious  SDLC,  roles  and  acCviCes    –  Cross  Site  ScripCng,  SQL  InjecCon,  Path  traversal  ,  misconfiguraCons  –  Many  others…  

 

   

39

Gartner  ShiLs  Security  Focus  to  ApplicaCons    

Top  10  Strategic  Technology  Trends  for  2015  report:  “…Security-­‐aware  applicaCon  design,  dynamic  and  staCc  applicaCon  security  tesCng,  and  runCme  applicaCon  self-­‐protecCon  combined  with  acCve  context-­‐aware  and  adapCve  access  controls  are  all  needed  in  today's  dangerous  digital  world.  This  will  lead  to  new  models  of  building  security  directly  into  applicaCons.  Perimeters  and  firewalls  are  no  longer  enough;  every  app  needs  to  be  self-­‐aware  and  self-­‐protecNng.”  

•  hUp://www.gartner.com/newsroom/id/2867917  Gartner  Symposium  

40

Typical  ApplicaCon  VulnerabiliCes  

Broke  AuthenCcaCon  and  Session  Management  Ø  Included  in  2013  -­‐  OWASP  Top  10  Ø  AUacker  uses  leaks  or  flaws  in  the  authenCcaCon  or  session  management  funcCons  (e.g.,  exposed  

accounts,  passwords,  session  IDs)  to  impersonate  users.    

Ø  Scenario:    “Insider  or  external  aUacker  gains  access  to  the  passwords  stored  locally.  User  passwords  are  not  properly  encrypted,  exposing  them  to  the  aUacker.  ”    

Ø  Scenario:  “ApplicaCon’s  Cmeouts  aren’t  set  properly.  User  uses  a  public  computer  to  access  site.  Instead  of  selecCng  “logout”  the  user  simply  closes  the  browser  tab  and  walks  away.  AUacker  uses  the  same  browser  an  hour  later,  and  accesses  user’s  session  and  data.”  

41

Typical  ApplicaCon  VulnerabiliCes  

Insecure  Direct  Object  Reference  Ø  Included  in  2013  -­‐  OWASP  Top  10  Ø  An  authorized  aUacker  simply  changes  a  parameter  value  in  the  request  (filename,  key,  guid,  ID,  etc.)  that  

directly  refers  to  a  system  object  which  the  user  isn’t  authorized  to  access.  The  system  doesn’t  properly  validate  the  request  parameters  and  doesn’t  validate  authorizaCons  to  access  the  data  before  sending  it  back  to  the  user  

Ø  Scenario:    “An  aUacker  is  able  to  manipulate  the  file  name  or  path  of  a  file  to  a  file  they  do  not  have  permission  to  access.    The  file  is  owned  by  a  different  customer  of  the  applicaCon.    The  vulnerability  enables  the  aUacker  to  access  data  in  the  file  of  a  different  customer.”    

42

Typical  ApplicaCon  VulnerabiliCes  

SQL  InjecCon  Ø  A  top  industry  applicaCon  vulnerability  for  over  10  years  Ø  AUack  is  able  to  access  data  in  the  database  by  sending  SQL  commands  into  the  database  through  

applicaCon  interface.    These  command  can  access,  modify  or  delete  the  data  in  the  database.  

Ø  Scenario:    “AUacker  exploits  this  vulnerability  in  an  applicaCons  that  stores  PII  informaCon.    The  aUacker  sends  in  the  SQL  commands  which  cause  the  applicaCon  to  expose  customer  or  their  clients  PII  data  or  alter/delete  other  data  in  the  database”  

43

Most  Frequent  ApplicaCon  VulnerabiliCes  

44

Source – WhiteHat security report 2014

MicrosoL  Security  Development  Lifecycle  Framework  

•  The  Security  Development  Lifecycle  (SDL)  is  a  security  assurance  process  that  is  focused  on  soLware  product  development.    

 

•  As  a  company-­‐wide  iniCaCve  and  a  mandatory  policy  since  2004,  the  SDL  has  played  a  criCcal  role  in  embedding  security  and  privacy  in  soLware  and  culture  at  MicrosoL.  

•  Combining  a  holisCc  and  pracCcal  approach,  the  SDL  aims  to  reduce  the  number  and  severity  of  vulnerabiliCes  in  soLware.    

 

•  The  SDL  introduces  security  and  privacy  throughout  all  phases  of  the  development  process.    

 

•  The  MicrosoL  SDL  is  based  on  three  core  concepts—educa7on,  con7nuous  process  improvement,  and  accountability.  

 

•  MicrosoL  publish  SDL  best  pracCces  at  hUp://www.microsoL.com/security/sdl  

45

Best  industry  pracCces  -­‐  MicrosoL  SDL  

46

n  Team  has  reviewed  best  industry  pracCces,  consulted  with  internal  and  external  experts  

n  MicrosoL  SDL  program  was  selected  as  baUle-­‐tested  industry  best  pracCce  model  for  TAA  SoLware  Security  Assurance  

SoLware  Security  Assurance  (SSA)  Program  

• Code  Review  • Security  TesCng  • Architectural  Analysis  

• Vulnerability  Management  • Environment  Hardening  • PenetraCon  TesCng  

• Secure  Architecture  • Security  Standards  and  Requirements  

• Training  • Policies  and  Compliance  • Strategy  and  Metrics  

Governance   ConstrucCon  

VerificaCon  Deployment  

47

Enterprise  Architecture  team  can  perform  stewardship  and  governance  of  SSA  program,  providing  it  with  organizaConal  context:    

§  Maintain  Security  Policies,  Standards,  Guidelines  adopCng  Industry  standards  and  best  pracCces  such  as  MicrosoL  SDL,  OWASP,  etc.  

§  Maintain  Security  Training  Curriculum  (both  online  and  in-­‐person)  specific  to  SDLC  roles:  Developers,  DBAs,  Architects  and  Security  Champions,  QA,  Product  Managers  and  Scrum  Masters  

§  Work  with  Development  and  PMO  to  incorporate  SSA  into  Agile  Development  Process  

§  Perform  Security  reviews  of  applicaCons  §  Provide  reviewer,  advisor,  and  auditor  

resources  

 

§  Dedicated  ApplicaCon  Security  Architects  responsible  for  SSA  tools  and  governance  

§  Keep  and  report  on  SSA  KPIs  §  Maintain  security  assessment  repository  

Risk-­‐based  Approach  to  ApplicaCon  Security  Management  

Utilize resources effectively to identify and mitigate risk

Application Security Risk Management

Business Impact

Assessment Asset

Inventory Status and Progress

Measurement Enrollment into SSA Vulnerability Prioritization

•  Create an application profile template

•  Build an inventory of applications

•  Describe each application

•  Classify applications

•  Determine business impact

•  Prioritize assets

•  Perform Threat Analysis

• Perform Static and Dynamic Code scanning

• Perform Security Reviews of highest risk applications

• Perform external pen and prod tests

• Prioritize vulnerabilities and create remediation plans

• Enroll high risk applications into SSA program:

• Identify Security Champions

• Train in Security the entire team

• Incorporating Security into SDLC

• Budget for Training, Tools and periodic tests

• Track progress against remediation plan

• Perform periodic Security Reviews, Code Scanning and Vulnerability Prioritization

Context  

• Industry  and  Strategic  Context  • OrganizaConal  Context  • Develop  risk  management  structure  and  risk  criteria  

IdenCfy  Risks  

• What  can  happen?  • How  can  it  happen?  

Analyze  Risks  

• Determine  exisCng  controls  • Determine  likelihood  • Determine  impact  • Establish  Business  risk  profile  

Evaluate  Risk  

• Compare  against  criteria  • Set  risk  prioriCes  and  tolerances  

Accept  Risks  

• Are  we  accepCng  the  risk?  If  yes,  then  treat/miCgate  risk  

Treat  Risks  

• IdenCfy  miCgaCon  opCons  • Evaluate  miCgaCng  opCons  • Prepare/define  treatment  plans  • Implement/execute  treatment  plans  

ApplicaCon  &  Data  Context  

• Current  ApplicaCon  Por[olio  context  • (Customer)  Data  context  • Determine  applicaCon  and  data  risk  evaluaCon  criteria  (Threat  models  and  AUack  paUerns)  

IdenCfy  Risks  

• What  can  happen?    • How  can  it  happen?  

Analyze  Risks  

• Determine  exisCng  applicaCon  controls  and  underlying  IT  general  controls  • Determine  likelihood  • Determine  impact  • Establish  ApplicaCon  risk  profile  for  each  applicaCon  

Evaluate  Risk  

• Compare  against  criteria  (threat  models  and  aUack  paUerns)  • Set  data  and  soLware  risk  prioriCes  and  tolerances  

Accept  Risks  • Are  we  accepCng  the  risk?  If  yes,  then  treat/miCgate  risk  

Treat  Risks  

• IdenCfy  miCgaCon  opCons  • Evaluate  miCgaCng  opCons  • Prepare/define  treatment  plans  • Implement/execute  treatment  plans  

Business  Risk  Management   So=ware  &  Data  Risk  Assessment  

Mon

itorin

g  an

d  Re

view

s  throu

gh  Assessm

ents  

Por[olio  Risk  Assessment  Framework  (Business  &  Security)  

49

50

Example  of  Risk  Assessment  Analysis  Business Risk Analysis:

1.  Product Name 2.  Business Importance Ranking 3.  Is Internet Accessible 4.  Revenue or # of customers 5.  Assets to be protected 6.  Business Goals 7.  Data Center 8.  High Availability solution 9.  Backup solution 10.  Disaster Recovery solution 11.  Do Dev/Test environment

contain PII data? 12.  PII data encrypted? 13.  Has Intellectual Property? 14.  Business Risk Ranking

Product Threat Analysis:

1.  Security Attack Vector/Method 2.  Threat Actor 3.  Event type (CIA) 4.  Asset at risk 5.  What is Impacted 6.  Likelihood of event 7.  Severity of Impact 8.   Threat Severity 9.  Monitoring Process 10.  Mitigations 11.  Gaps 12.  Remediation Plan

ApplicaCon  Security  TesCng  Strategy  

51

•  Applica7ons  are  evaluated  to  determine  their  risk  

•  Based  on  the  risk,  different    security  work  flows  could  apply.  

•  Including  a  combina7on  of  Dynamic  and  Sta7c  Analysis  techniques.  

Catalogue Application Assets

Evaluate Application Risk RISK = F (Probability X Expected Loss )

Rank Applications

LOW MEDIUM HIGH CRITICAL

§  Dev Code Scanning §  Code Scan on Builds §  QA Dynamic Scan §  Pre Prod Scan §  Manual Pen test §  External Security Test §  Quarterly Prod Test

§  Dev Code Scanning §  Code Scan on Builds §  QA Dynamic Scan §  Pre Prod Scan §  Manual Pen test §  Bi-Annual Prod Test

§  Code Scan on Builds §  Pre Prod Scan §  Manual Pen test §  Annual Prod Test

§  Pre Prod Scan §  Annual Prod Test

ApplicaCon  Security  TesCng  –  Code  Scanning  

•  StaCc  code  analysis  –  StaCc  ApplicaCon  Security  TesCng  (SAST)  –  White  Box  TesCng,  “Inside  Out”  

•  Dynamic  ApplicaCon  Security  TesCng  (DAST)  –  Black  Box,  “Outside  In”  

•  InteracCve  ApplicaCon  Security  TesCng  (IAST)  –  Gray  Box,  combines  staCc  and  dynamic  tesCng  

Requirements

Design

Code & Unit Test

Integration

System Test

The  “Waterfall”  Approach  

STATIC ANALYSIS (Dev) AppScan Source

DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise

PENETRATION TEST (Security) AppScan Standard Manual Testing

Product Backlog Sprint Backlog Iteration Product Shipping

SPRINT 2 - 3 weeks

Daily Review

The  “Agile”  Approach  

PENETRATION TEST (Security) AppScan Standard Manual Testing

AppScan Source (Filtering on High Confidence)

AppScan Source AppScan Enterprise/ Standard

Requirements

Design

The  “Agile-­‐Fall”  Approach  

Integration

System Test

DYNAMIC ANALYSIS (QA) AppScan Standard AppScan Enterprise

PENETRATION TEST (Security) AppScan Standard Manual Testing

AppScan Source AppScan Enterprise/ Standard

Manual  StaCc  Code  Analysis  

•  Manual  code  tesCng  –  Proven  –  Expensive,  difficult,  hard  to  cover  all  flows,  no  guarantee  –  Coverage  is  criCcal  for  security  –  single  failure  fails  system  –  To  scale  -­‐  Automated  to  automated  unit  tests  

•  Code  review  – Humans  can  generalize  beyond  rules  – Human  Cme  is  expensive  – Not  consistent  between  iteraCons/releases  –  To  scale  -­‐  Automated  to  staNc  code  analysis  

Role  of  StaCc  Code  Analysis  

•  Strong  points  of  staCc  code  analysis:  –  Scales  beUer  –  Can  detect  vulnerabiliCes  proacCvely  –  Can  focus  on  a  few  key  properCes  with  big  payoffs  –  Can  reuse  security  specificaCons  across  programs  –  Eliminate  categories  of  error  vs  single  error  –  Encourage  beUer  development  pracCces  

•  Domains:  –  Inference                    (program  understanding,  bug-­‐finding)  

•  Appropriate  for  legacy  code  –  Enforcement            (proving  absence  of  bugs)  

•  Most  useful  when  building  new  systems  

CheckMarx  •  Checkmarx  offers  one  of  the  strongest  SAST  technologies,  which  tests  a  broad  variety  of  

programming  languages  (C#,  PHP,  Java,  JavaScript,  PL/SQL,  C++,  etc.)  and  is  well-­‐integrated  into  the  SLC.  

•  Checkmarx  offers  a  universal  applicaCon  model  that  can  be  queried  to  discover  vulnerabiliCes,  and  to  check  for  code  adherence  to  secure  programming  best  pracCces.  The  model  also    enables  incremental  scans  and  analysis  across  components  of  composite  applicaCons  that  are  wriUen  in  different  programming  languages  and  with  the  use  of  different  frameworks.  

•  Checkmarx  offers  SAST  as  a  tool  and  a  cloud  service.  The  vendor  is  a  SAST  tesCng  provider  that  is  capable  of  tesCng  Apex,  and  is  also  a  major  provider  of  SAST  for  salesforce.com,  its    partners  and  users.  In  addiCon,  Checkmarx  offers  support  for  many  cloud  pla[orms  and  frameworks,  such  as  CloudSpokes,  MediaMind  and  topcoder.  

•  Checkmarx  offers  SAST  for  naCve  Android  and  iOS  mobile  apps,  and  also  tests  mobile  apps  with  a  mobile  browser  that  uses  HTML5.  

•  Checkmarx  does  not  offer  its  own  DAST  and  IAST  –  (all  above  source  Gartner)  

•  NegaCves  -­‐  Completed  scans  show  large  number  of  false  posiCves  and  slow  review  viewer  

Checkmarx  

•  CxScan  Engine  –  Scan  the  actual  source  code  •  CxSuite  ApplicaCon  –  used  to  manage  teams,  users,  

projects  and  scans  •  CxSuite  Viewer  –  Review  the  scan  results  and  

perform  triage  

CheckMarx’  components  

CHECKMARX  

Checkmarx  

Self-­‐Service  scanning  •  PrioriCze  products  to  scan  (BU  level)  

–  5-­‐6  products  per  month  –  1-­‐2  reviewers  login  per  product  

•  Prepare  code  base  for  scan  –  Create  a  script  to  delete  all  files  not  subject  to  scan.  Simple  rule  –  

leave  only  those  which  open  in  Notepad  (code,  configuraCon,  XAML,  HTML,  etc),  delete  all  binaries  and  images.    

–  Delete  dead  code,  careful.  Discuss  what  to  delete.  –  Repeatable,  check-­‐in  into  the  Source  Control  –  Zip  and  share    –  Login  and  review  warning,  mark  as  “Not  exploitable”  or  “Confirmed”  

•  Connect  with  SSA,  clarify  those  which  you  have  doubt  in  •  Print  report,  noCfy  EA  •  Use  findings  for  security  backlog,  create  defects  and  stories  •  Your  reviewer  login  will  be  taken  away  2  weeks  aLer  to  be  reused  

Security  Roles  and  Tools  in  Dev  Teams  

62

Security  Champions  

•  Part  Cme  role,  filled  by  Architects  or  Sr.  Developers  from  the  product  team    

•  Receive  more  in-­‐depth  security  training  to  become  local  Security  expert  

•  Responsible  for  reviewing  product  requirements  from  Security  view  point  and  idenCfying  Security  requirements  

•  Responsible  for  coordinaCng  and  tracking  security  issues  for  the  product  and  communicaCon  with  EA  SSA  team  

•  May  perform  Threat  analysis,  Security  code  scanning  and  triaging  scanned  issues  

63

Security  champions  tasks  priority  

•  All  years  •  Self-­‐training  and  team’s  training  planning  –  20%  •  Maintain  inventory  of  3rd  party  components  and  watch  for  vendor’s  vulnerabiliCes  –  

10%  •  Security  architecture  review  of  new  features  –  10%  •  Assist  in  security  review  –  10%  

•  Year  1  (before  security  review)  –  Self-­‐service  vulnerability  discovery  –  50%  

•  Year  1-­‐2  (aLer  security  review)  –  Create,  manage  and  decrease  security  backlog  –  40%  –  Self-­‐service  vulnerability  discovery  –  10%  

•  Year  2+  (no-­‐high  vulnerabiliCes  state)  –  Self-­‐service  vulnerability  discovery  –  20%  –  Adopt  new  tasks  (threat  modeling,  etc)  –  20%  –  Control  security  backlog  –  10%  

Task  –  self  service  vulnerability  discovery  

•  Apply  training  to  analysis  of  team  code  base  and  idenCficaCon  of  security  defects  

•  ParCcipate  in  architecture  and  code  reviews  •  Submit  code  base  to  staCc  code  scan  to  TAA  SSA,  triage  false  posiCves,  populate  security  defects  backlog  

•  Allocate  on  this  task  50%  of  bucket  before  SSA  review  and  20%  of  bucket  aLer  SSA  review  

Task  –  security  backlog  •  AcCvely  manage  security  defects  and  stories  backlog  

–  Backlog  is  populated  from  external  reviews  and  internal  self-­‐service  vulnerability  discovery  

•  Provide  design  for  quick  miCgaCon  and  complete  remediaCon    

•  Validate  implemented  soluCons  to  actually  remediate  vulnerabiliCes  

•  Map  security  defects  to  stories  •  Report  security  defects  backlog  detailed  status  and  staCsCcs  •  Allocate  annually  on  this  task  50%  of  bucket  aLer  SSA  review  and  20%  before  SSA  review  

Security  champions  reporCng  •  Provide  reporCng  of  tasks  and  hours  to  product  team  management  and  SSA  program  

•  Bucket  Cme  allocaCon  •  To  product’s  team  management  

– Manage  and  report  allocated  Cme  bucket  –  8-­‐16  hours  per  month  

– Manage  and  report  task  details  –  Drive  team-­‐wide  training  and  security  defect  backlog    

•  To  SSA  program  –  Report  KPI  for  cross-­‐BU  aggregaCon  –  Report  all  vulnerabiliCes  –  new  and  remediaCon  status  changes  –  Assist  in  training  planning  

Security  Champion  monthly  KPI  

•  Security  defects’  counts  – Rows:  high/medium/low    – Columns:  New/MiCgated/Remediated/Remaining  

•  Security  defects’  details  •  Security  training  by  champion  and  team  including  hours  

•  List  of  other  security  related  tasks  completed  

SSA  AcCviCes  for  Each  Enrolled  Product/Dev  Team  

•  All  steps  require  acCve  involvement  of  product  leadership  •  Assign  Team  Security  Champions  

–  Security  champion  roles  should  be  filled  by  SMEs  from  the  project  team.    –  Responsible  for  the  negoCaCon,  acceptance,  and  tracking  of  security  and  privacy  requirements  and  

maintaining  clear  lines  of  communicaCon  with  SSA  governance  –  Establish  communicaCon  and  training  plan  

•  Conduct  Security  Training  for  team  and  addiConal  training  for  Champion  •  Perform  Product  Business  Risk  Assessment  •  Catalog  soLware  dependencies,  especially  Open  Source    •  Run  staCc  code  analysis  scan,  triage  found  issues  •  Run  dynamic  code  analysis  scan,  triage  found  issues  •  Perform  Security  Risk  Assessment  &Threat  Modeling  (incl.  IT  Ops).  IdenCfy  risks  w/miCgaCons.  As  a  

result,  create  backlog  of  Security  stories,  Security  bugs  &  IT  Ops  gaps  •  Document  results  in  Security  Assessment  document  •  Budget  for  annual  penetraCon  test,  training,  tools  and  other  SSA  acCviCes  •  Create  Incident  Response  Plan  (review  it  with  Legal)  

69

Security  AcCviCes  for  Each  Product  Release  

At  Release  planning:    •  Perform  Security  Threat  Surface  analysis  and  plan  its  reducCon:  

–  Review  and  prioriCze  security  backlog,  create  new  stories  if  needed  –  Review  other  requirements  for  security  impact  –  Review  and  prioriCze  security  bugs  

•  QA  creates  test  plans  and  updates  automaCon  scripts  to  test  Security  stories  &  bugs    

For  each  Sprint:    •  Incorporate  security  standards  and  guidelines  into  code  reviews  •  Review  security  threat  vectors  •  Perform  staCc  code  analysis  •  IdenCfy  and  prioriCze  security  bugs    At  the  end  of  Release  (during  Hardening  Sprint):  •  Perform  Dynamic  security  analysis  and  Fuzz  TesCng  by  QA  •  Conduct  and  submit  security  Assessment  Survey  by  security  champion  •  Perform  Final  Release  Security  Review  (including  IT  OperaCons)  and  cerCfy  the  Release  •  Update  Security  Assessment  document  and  SSA  governance  repository  •  Perform  external  penetraCon  test  (at  least  annually)       70

Security  Training  •  Training  is  foundaCon  of  SSA  and  aligns  with  agile  goal  of  

contribuCon  from  every  team  member  –  All  members  of  a  soLware  development  team  must  receive  appropriate  training  to  stay  informed  about  security  basics  and  recent  trends  in  security  and  privacy.  This  includes  Developers,  DBAs,  Architects  and  Security  Champions,  QA,  Product  Managers  and  Scrum  Masters  

•  Annual  training  goals:  –  SoLware  development  team  members  in  technical  roles  must  aUend  at  least  one  unique  security  training  class  each  year  or  4  hours  of  online/seminar  training  

–  Development  is  required  to  complete  online  Pluralsight  security  training  –  EA  team  will  maintain  Recommended  Security  Training  Curriculum  –  Online  and  in-­‐person  security  classes  for  Security  Champions  

•  Some  training  sites:  –  hUp://www.microsoL.com/security/sdl/process/training.aspx    –  hUp://www.pluralsight.com/training/Products/Individual  

71

Example  of  Security  Training  Curriculum  Course/Module  Name   Hours   Target  audience  in  order  of  

relevance  Level   EvaluaNon  notes  

OWASP  Top  10  Web  ApplicaNon  Security  Risks  for  ASP.NET  

8   Development,  QA,  Design,  PM  

Medium   Recommended  as  base  course  for  Development.  With  web  concentraCon  of  this  course  we  recommend  addiConal  modules  

Hack  Yourself  First:  How  to  go  on  the  Cyber-­‐Offense  

9   QA,  Design,  Development,  PM  

Medium   Basic  course  from  the  posiCon  of  penetraCon  test.  Highly  recommended  

Microso^  MTA:  Security  Fundamentals   5   PM,  Design,  QA   Basic   Describes  basic  security  concepts  with  mostly  network,  than  app  security.  Prepare  for  MicrosoL  Security  fundamentals  MCP  exam  

Web  Security  and  the  OWASP  Top  10:  The  Big  Picture  

2   Design,  PM,  QA,  Development  

Basic   FoundaCon  course  on  base  concepts  of  applicaCon  security.  

What's  New  in  the  OWASP  Top  10  for  2013   1   Development,  Design,  QA   Basic   Short  very  recent  (2014)  course  with  informaCon  on  latest  changes  in  app  security  

IntroducNon  to  Cryptography  in  .NET       2   Development,  Design   Advanced      

Developing  and  Deploying  SQL  Server  ISV  ApplicaNons.  Modules  –  Security,  TesNng  

1   Development,  Design,  QA   Medium   Recommended  course  for  Axcess  developers  

Enterprise  Library  Security  and  Cryptography  ApplicaNon  Blocks    

1   Development   Medium   While  this  module  is  not  acCvely  used  in  Axcess  there  are  many  relevant  points  

CompTIA  Security+.  Modules  -­‐  Incident  Response,  User  EducaNon,  Social  Engineering,  PKI,  Cryptography  

2   PMO,  PM   Medium   Describes  security  processes  

WCF  Design  concepts.  Module  Security   1.5   Development,  Design   Advanced   Required  course  for  Axcess  developers  

SQL  Server  Fundamentals.  Modules  –  Security  1,  2  

2   Development,  Design,  DBA   Medium   SQL  Security    

72

Sample  Security  Review  Process  •  1.            Kick-­‐off  meeCng.  The  dates  for  the  in-­‐person  Security  Review  are  agreed  upon.  

–  The  Dev  team  sends  to  the  Review  Team  architecture  documentaCon  about  the  product  –  ZIP’d  source  code  or  read-­‐only  access  to  the  source  repository  

•  2.            Step  2:  (approx.  Week  2)  Review  Team  sends  Product  team  a  customized  Security  quesConnaire  –  Product  team  sends  answers  to  Review  Team  –  Call  between  Review  team  and  Product  team  in  order  to  review  answers  and  plan  visit                  

•  3.            Step  3:    (approx.  Week  2-­‐3)  StaCc  and  Dynamic  code  scanning  –  Review  team  performs  StaCc  code  vulnerability  scan  of  the  source  code.  –  Product  team  gives  external  authenCcated  access  to  their  applicaCon  Test  or  Staging  environment  to  the  

Review  team.  –  Review  team  performs  Dynamic  code  vulnerability  scan  on  the  environment  above.  

•  4                Step  4:    (approx.  Week  4)  In  person  review  of  the  product  –  Demo  of  the  latest  product  release  –  Review  of  the  architecture  and  important  quality  aUributes    –  IdenCficaCon  of  threats  and  aUack  vectors  –  Deep  dive  into  potenCal  vulnerabiliCes  found  during  code  scanning  and  inspecCons  –  Recap  of  confirmed  vulnerabiliCes  and  remediaCon  recommendaCon  with  the  team    –  Review  of  SoLware  Security  Assurance  process  that  they  may  want  to  adopt  

•  5.            Step  5:  (approx.  Week  5)  Report  –  The  Review  team  writes  a  report  idenCfying  the  main  threats  idenCfied  and  the  remediaCon  strategy  –  Product  team  reviews  the  report  and  creates  remediaCon  plan  for  each  high  and  medium  risk  vulnerability  

•  6.            Step  6:  Review  RemediaCon  Plan  

73

Vulnerability  RemediaCon  and  Tracking  Process  

•  Create  internal  tracking  record  describing  vulnerability  with  some  required  detail  informaCon.  This  document  is  sensiCve  and  distribuCon  should  be  limited  and  controlled.    

•  MiCgaCon  and  remediaCon  process  is  triggered  by  mulCple  points  in  incident  response  plan  and  executed  separately  for  each  vulnerability  idenCfied  internally  or  externally.    

•  Dev  team  provides  remediaCon  approach,  dates  for  vulnerabiliCes  or  deferral  dates  in  format  specified  by  EA  and  infrastructure  security.    

•  Dev  team  report  compleCon  of  remediaCon  and  provide  verifiable  prove.  

•  EA  tracks  status  of  the  remediaCon  and  updates  execuCve  Security  dashboard  

74

Coordinated  Vulnerability  Disclosure  Policy  

•  Describes  the  structured  Vulnerability  Management  process  that  the  Company  uses  for  handling  and  disclosing  soLware  vulnerabiliCes.  As  a  template  MicrosoL  Security  Vulnerability  Disclosure  guidance  can  be  used  

•  Vulnerability  documentaCon  •  CommunicaCon  to  the  product  team  •  InvesCgaCon  and  RemediaCon  •  Coordinated  Disclosure  •  CommunicaCon  to  third  party  vendor  •  Externally  discovered  vulnerabiliCes  

75

SSA  Safe  Harbor  Principles  

SSA  will  adhere  to  Safe  Harbor  principles  in  conducCng  SoLware  Assurance  Program  to  reduce  size  of  legal  exposure  due  to  Security  incidents.      Those  principles  are:  •  Establish  Security  Policies,  Standards  and  Guidelines  •  Establish  CommunicaCon  plan  •  Establish  Training  plan  for  all  involved  personnel  •  Audit  and  Monitor  compliance    

76

Capability  Maturity  Model  

77

CAPABILITY  Maturity  Model  

78

Source: https://www.veracode.com/blog/2013/10/the-appsec-program-maturity-curve-1-of-4