IT  Architecture  Automa/c  Verifica/on:  A  Network  Evidence-­‐based  Approach  

António  Alegria  (Presen0ng)  Portugal  Telecom  

Ins/tuto  Superior  Técnico  –  Universidade  Técnica  de  Lisboa  

 André  Vasconcelos  

Center  for  Opera/onal  Design  and  Engineering  Ins/tuto  Superior  Técnico  –  Universidade  Técnica  de  Lisboa  

 

Roadmap  

•  Problem  Statement  

•  Proposed  Approach  •  Proof  of  Concept  Prototype  •  Case  Study  •  Results  •  Future  Work  

2  

Problem  Statement    

Is  the  expected  model  correct?  

Does  the  implementa5on  meet  expecta5ons?  

3  

Informa5on  Systems  Architecture  (ISA)  Planning  Process  

How  to  Check  the  Reality  of  IT  Architecture?  

•  Actual  architecture  emerges  from  Informa/on  Systems’  (IS)  func/on  

•  IS  manifest  themselves  through:  –  Input  and  Output  ar/facts  –  Interac/ons  with  other  agents  (humans  or  machines)  

•  Interac/ons  with  other  systems  are  predominantly  through  TCP/IP  networks  

•  At  the  technology  level  it’s  possible  to  capture  all  IS’  manifesta/ons  in  corporate  networks  –  Security  experts  have  been  doing  it  for  a  long  /me  although  with  a  different  purpose  and  at  a  lower  level  of  abstrac/on  

4  

How  to  Check  the  Reality  of  IT  Architecture?  

•  How  to  infer  evidence  of  the  actual  architecture  through  the  “bits”  captured  in  the  network?  –  Protocol  headers  and  applica/on-­‐layer  payload  contain  informa/on  that  serve  as  explicit  or  implicit  evidence  for  the  status  quo  of  the  IS  and  their  architecture  

•  If  we  capture  all  IS’  network  interac/ons  how  can  we  verify  an  IT  Architecture  (ITA)  model?  –  By  confron/ng  that  model  with  all  the  evidence  collected  from  the  network  

5  

Research  Ques/on  

How  to  automa5cally  verify  if  an  IT  Architecture  

model  is  actually  in  sync  with  current  IS,  resor5ng  

exclusively  to  the  passive  analysis  of  their  network  

traffic?  

6  

Approach  

Cap/on  

Common  ISA  Planning  Process  

Extensions:  Verifica5on  Process  

Extensions:  Verifica/on  Cycle  

Extensions:  Lifecycle  

7  

This  subprocess  is  our  main  focus  (at  the  technology  level)  

Verifica/on  Process  (Simplified)  

8  

Verifica/on  Process  (Simplified)  

Dis/lls  evidence  of  the  real  ITA  from  passively  captured  and  analyzed  network  traffic  

9  

Traffic  Monitoring  

•  Discover  evidence  of  the  actual  ITA  from  network  packets,  headers  and  payloads  

•  Passive  Network  Traffic  Analysis  Hierarchy  –  Sub-­‐Applica5on-­‐layer  Inspec5on  (TCP/IP  headers)  

§  System  interrela/onship  graph  §  Opera/ng  Systems  

–  Superficial  Applica5on-­‐layer  Inspec5on  (protocol  signatures)  §  Applica/on-­‐layer  Protocol  classifica/on  §  So\ware  Components  (limited)  

–  Deep  Applica5on-­‐layer  Parsing  §  Pre-­‐classified  traffic  is  dispatched  to  specialized  parsers  §  Technology  Services  and  Opera/ons  (including  used  Parameters)  §  So\ware  Components  §  Low-­‐level  Informa/on  En//es  (e.g.  database  schemas,  user  names)  

10  

Verifica/on  Process  (Simplified)  

11  

Real  ITA’s  evidence,  structured  in  accordance  with  a  proposed  conceptual  model  (NeVacts)  

Evidence  Descrip/on  Model  (Ne^acts)  

12  

Verifica/on  Process  (Simplified)  

13  

Described  in  an  ISA  modelling  language.    

We  used  and  extended  the  CEO  Framework’s  (CEOF)  UML  profile.  

Verifica/on  Process  (Simplified)  

14  

Knowledge  of  how  to  match/map  a  higher-­‐level  ITA  model  with  the  actual  reality  mirrored  

in  the  collected  network  traffic  

Verifica5on  realized  by  applying  these  rules  to  the  domain  of  the  

architecture  model  and  the  collected  real  ITA  evidence  

Mapping  and  Verifica/on  Rules  Representa5on  of  ITA  Expecta5ons  

Ne^acts  Model  (M1)  

Ne^acts  Model  Instan/a/on  (M0)  

ISA  Modeling  Language  (M2)  

ISA  Model  (M1)  

ISA  Model  Instan/a/on  (M0)  

Representa5on  of  Factual  Reality  

• Mapping  between  Ne^acts  evidence  and  ITA  concepts  and  rela/onships  

•  Specify  the  required  collected  evidence  to  declare  an  ITA  model  in  sync  with  reality  

•  Generic  and  Organiza5on-­‐independent  (defined  at  the  ISA  modeling  language  level  –  M2)  

•  Defined  by  statements  in  a  subset  of  First  Order  Logic  (Horn  clauses)  

•  The  actual  ITA  Verifica5on  is  realized  by  checking  if  these  rules  hold  for  a  given  domain  15  

Pucng  it  all  together  

16  

Sub-­‐Applica/on-­‐layer  Inspector  

     

IPAudit   p0f  

Deep  Applica/on-­‐layer  Parser  

                           

Streamer  Traffic  Classifier  and  Dispatcher  

HTTP/SOAP  Parser  

SQL  Parser  

Oracle-­‐TNS  Parser  

Network  Traffic  Analysis  Engine  

Superficial  Applica/on-­‐layer  Inspector  

     

PADS   Verifica/on  Report  TXT  

Raw  Traffic  PCAP  

ITA  Verifica5on  and  Inference  Engine  

                           

Domain-­‐independent  Knowledge  Base  

Fact  Base  (Network  Evidence)  

Inference  Engine  (LogTalk)  

User  Interface  

NeVacts  (Prolog)  

Generic  Mapping  Rules  

(Logtalk)  

Fact  Base  (ITA)  

Verified  ITA  Model  (Logtalk)  

?  

Case  Study  

•  Portugal  Telecom  

•  Sales  IS  ecossystem  

•  Applied  approach  to  accurate  and  inaccurate  (with  known  devia/ons)  models  

•  Traffic  passively  captured  in  several  points  of  the  corporate  network  –  ~1  Terabyte  of  data  –  1  workday  

•  Prototype  applied  to  raw  captured  traffic  

17  

Case  Study  Example:  Service  Architecture  

18  

Case  Study  Example:  Service  Architecture  

19  

Results:  Correct  Model  

•  Fully  Iden/fied  architecture  elements:  –  «IT  Infrastructure  Block»  –  «Opera/ng  System»  –  «IT  Applica/on  Block»  –  «IT  Services»  –  «IT  Services»  Usage  

•  Par/ally  Iden/fied  architecture  elements  (due  to  lack  of  “built-­‐in  knowledge”):  –  «IT  Pla^orm  Block»  –  Excep/ons:  

§  .Net  Framework  2.0  in  SFAP’s  frontends  §  SQL  Server  2005  in  SFAP’s  data  backends  

–  «IT  Services»  Realiza/on  –  Excep/ons:  §  One  data  service  supported  by  SQL  Server  2005  (SFAP’s  data  backend)  

20  

Results  (Con/nued…)  

•  Incorrect  Model:  –  All  devia/ons  were  detected  –  Most  of  them  explicitly  reported  as  errors  –  A  few  cases  were  undecidable  

§  Lack  of  evidence  to  support  or  refute  that  architecture  component  §  Prototype  raises  a  “red  flag”  §  Architect  is  lead  to  inves/gate  these  specific  cases  

•  Knowledge  Discovery  –  All  of  the  Ne^acts  evidence  –  Undocumented  Architecture  Elements:  

§  over  50  «IT  Services»  §  several  «IT  Opera/ons»  and  used  parameters  §  Database  Tables  and  Columns  

21  

Future  Work  

•  Automa/c  elicita/on  of  ITA  model  •  From  low-­‐level  evidence  infer  high-­‐level  model  Automa/c  Discovery  of  ITA  

• Middleware  •  Enterprise  Service  Bus  Complex  IS  Technical  Rela/onships  

•  Applica/on  Logs  •  Ac/ve  Probing  and  Agent-­‐based  solu/ons  Other  Data  Sources  

•  Informa/on  Architecture  •  Applica/on  Architecture  Other  IS  Architecture  Levels  

22  

Thank  You  

Ques/ons?  

23  

Thank  You  

Ques/ons?  

24  

Thank  You  

Ques/ons?  

25  

Extending  the  CEO  Framework  

New  En5ty  New  A^ribute:  «concreteName»  New  A^ribute:  «version»  

Cap/on  

26  

Main  Contribu/ons  

Automa/c  ITA  

Verifica/on  Process  

Passive  Network  Traffic  Analysis  

ITA  Network-­‐based  

Evidence  Model  

Mapping  CEOF2007+  and  Ne^acts  

CEO  Framework  Extensions  

Automa/c  ✔  

Organiza/on  independent  

✔  

Unobtrusive  to  the  Organiza/on  and  its  

IS  ✔  

27