IT Architecture Automatic Verification (RCIS 2010)
0 likes754 views
The document discusses an approach to automatically verify if an IT architecture model is accurate based on analyzing network traffic. It involves capturing network traffic, extracting evidence of the real IT architecture from the traffic using various analysis techniques, structuring the evidence using an evidence description model called NeVacts, and then verifying the IT architecture model by comparing it to the collected evidence using defined mapping and verification rules. A prototype was developed to demonstrate the feasibility of the approach.
IT Architecture Automatic Verification (RCIS 2010)
- 1. 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
- 2. Roadmap • Problem Statement • Proposed Approach • Proof of Concept Prototype • Case Study • Results • Future Work 2
- 3. Problem Statement Informa5on Systems Architecture (ISA) Planning Process Is the expected model correct? Does the implementa5on meet expecta5ons? 3
- 4. 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
- 5. 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
- 6. 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
- 7. Approach This subprocess is our main focus (at the technology level) Cap/on Extensions: Verifica5on Process Extensions: Verifica/on Cycle Extensions: Lifecycle Common ISA Planning Process 7
- 9. Verifica/on Process (Simplified) Dis/lls evidence of the real ITA from passively captured and analyzed network traffic 9
- 10. 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 § Soware Components (limited) – Deep Applica5on-‐layer Parsing § Pre-‐classified traffic is dispatched to specialized parsers § Technology Services and Opera/ons (including used Parameters) § Soware Components § Low-‐level Informa/on En//es (e.g. database schemas, user names) 10
- 11. Verifica/on Process (Simplified) Real ITA’s evidence, structured in accordance with a proposed conceptual model (NeVacts) 11
- 12. Evidence Descrip/on Model (Ne^acts) 12
- 13. Verifica/on Process (Simplified) Described in an ISA modelling language. We used and extended the CEO Framework’s (CEOF) UML profile. 13
- 14. Verifica/on Process (Simplified) Knowledge of how to match/map a higher-‐ Verifica5on realized by applying level ITA model with the actual reality mirrored these rules to the domain of the in the collected network traffic architecture model and the collected real ITA evidence 14
- 15. Mapping and Verifica/on Rules Representa5on of Factual Reality Representa5on of ITA Expecta5ons Ne^acts Model ISA Modeling Language (M1) (M2) ISA Model (M1) ISA Model Instan/a/on Ne^acts Model Instan/a/on (M0) (M0) • 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
- 16. Pucng it all together Generic Mapping Verified ITA Model Rules ITA Verifica5on and (Logtalk) (Logtalk) Inference Engine Domain-‐independent Knowledge Base Network Traffic Analysis Engine Deep Applica/on-‐layer Fact Base Parser (ITA) ? Fact Base Streamer Sub-‐Applica/on-‐layer Traffic Classifier and Dispatcher (Network Evidence) Inspector NeVacts Inference Engine IPAudit p0f HTTP/SOAP Parser (Prolog) (LogTalk) Raw Traffic PCAP Superficial Applica/on-‐ SQL Parser User Interface layer Inspector PADS Oracle-‐TNS Parser Verifica/on Report TXT 16
- 17. 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
- 18. Case Study Example: Service Architecture 18
- 19. Case Study Example: Service Architecture 19
- 20. 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
- 21. 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
- 22. Future Work • Automa/c elicita/on of ITA model Automa/c Discovery of ITA • From low-‐level evidence infer high-‐level model • Middleware Complex IS Technical Rela/onships • Enterprise Service Bus • Applica/on Logs Other Data Sources • Ac/ve Probing and Agent-‐based solu/ons • Informa/on Architecture Other IS Architecture Levels • Applica/on Architecture 22
- 23. Thank You Ques/ons? 23
- 24. Thank You Ques/ons? 24
- 25. Thank You Ques/ons? 25
- 26. Extending the CEO Framework Cap/on New En5ty New A^ribute: «concreteName» New A^ribute: «version» 26
- 27. Main Contribu/ons Passive Network Traffic Automa/c Analysis ✔ Automa/c ITA Unobtrusive to the CEO ITA Network-‐ Framework based Organiza/on and its Extensions Verifica/on Evidence IS Process Model ✔ Organiza/on Mapping CEOF2007+ independent ✔ and Ne^acts 27