ComiFin a_dingsor


Published on

Overview of the EU Framework Programme ComiFin project, researching mechanisms to protect critical financial infrastructures

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ComiFin a_dingsor

  1. 1. CoMiFin Essential contract contract contract Agre infor ed matioOrganization 1 n warn ings Collaborative .... Processing SystemOrganization M Internet
  2. 2. Comifin Essentials: Business Vision•  CoMiFin platform can be potentially useful for addressing the following business use cases –  Monitoring and reaction to cyber threats (Man-in-the-Browser, Man-in-the- Middle, Botnet detection, stealthy inter-domain port scan) –  Location intelligence for fraud correlation –  ID-theft –  Anti money laundering monitoring –  Black/white lists distribution (for credit reputation, trust level,.) –  Anti-terrorism lists•  These use cases imply value added services that can be offered by SPs to FIs over CoMiFin•  CoMiFin project had been submitted to four FAB meeting evaluation sessions that have highlighted its possible business value in real financial use cases
  3. 3. CoMiFin Essentials: The notion of semantic room■  Contract ■  set of processing and data sharing services provided by the SR along with the data protection, privacy, isolation, trust, security, dependability, performance requirements. ■  The contract also contains the hardware and software requirements a member has to provision in order to be admitted into the SR.■  Objective ■  each SR has one strategic objective to meet (e.g, large-scale stealthy scans detection, detecting Man-In-The-Middle attacks)■  Deployment ■  highly flexible to accommodate the use of different technologies for the implementation of the processing and sharing within the SR (i.e., the implementation of the SR logic or functionality).
  4. 4. CoMiFin Essentials: The notion of semantic room■  Contract ■  set of processing and data sharing services provided by the SR along with the data protection, privacy, isolation, trust, security, dependability, performance requirements. ■  The contract also contains the hardware and software requirements a member has to provision in order to be admitted into the SR.■  Objective ■  each SR has one strategic objective to meet (e.g, large-scale stealthy scans detection, detecting Man-In-The-Middle attacks)■  Deployment ■  highly flexible to accommodate the use of different technologies for the implementation of the processing and sharing within the SR (i.e., the implementation of the SR logic or functionality).
  5. 5. Architectural Design•  Design and implementation of each component
  6. 6. CoMiFin Essentials: Deploying a Semantic Room■  Private cloud ■  Deployment of the semantic room through the federation of computing and storage capabilities at each member ■  Each member brings a private cloud to federate■  Public Cloud ■  Deployment of the semantic room on a third party cloud provider ■  The third party owns all computing and storage capabilities■  Hybrid approach
  7. 7. CoMiFin Testbed for live Demos
  8. 8. Interconnections of SRs•  Horizontal/Vertical composition –  Communicating SRs have different goals –  Complex/combined attacks can be detected by information fusion –  E.g. , alerts generated in Portscan SR contributes to the Blacklist managed in MitM SR
  9. 9. Today’s CoMiFin Achievements: user perspectives•  Timely identification of Identity Theft•  Community-based advanced information sharing•  Identification of Command and Control of Trojans for MiTB
  10. 10. Giorgia Lodi (CINI)Gregory Chockler (IBM)
  11. 11. Outline•  Three Semantic Rooms –  Esper-based and Agilis-based SRs for inter-domain stealthy port scan detection –  Agilis-based botnet driven HTTP session hijacking (not covered in this presentation)•  High level description of the port scanning detection algorithms –  R-SYN port scan detection –  Line Fitting•  High Level description of botnet driven HTTP session hijacking (not covered in this presentation)•  Performance evaluation –  R-SYN vs Line Fitting using the Esper-based SR –  Agilis vs Esper-based SR for inter-domain stealthy port scan detection (R-SYN only) –  Agilis for botnet driven HTTP session hijacking (not covered in this presentation)
  12. 12. Do you remember some important concepts?•  SR creation phase –  A so-called SR schema is created where the three characterizing SR elements are specified •  The objective •  The contract filled in with general SR contractual clauses •  The variety of software deployments that can be used for that SR•  SR instantiation phase –  The same SR schema can be instantiated in different ways according to different aspects, e.g., •  geographical position of the members •  processing and sharing software (SR IDPS instance uses Agilis for the processing, SR IDPS instance uses Esper for the processing) •  types of SR deployments: third party based, SR owned, hybrid
  13. 13. Giorgia Lodi (CINI)
  14. 14. Inter-domain stealthy port scan•  TCP SYN (half-open) port scan –  Each scanner is targeting multiple sites –  Hosts at each site receive a series of probes to multiple ports –  Each probe is a TCP connection initiation (3-way handshake), which never completes •  A scanner S sends a SYN packet to a target T on a specific port P and waits for a response –  If a SYN-ACK packet is received, S can conclude that P is open and optionally reply with a RST packet to reset the connection (incomplete connections) –  if a RST-ACK packet is received, S can consider P as closed –  If no packet is received at all and S has some knowledge that T is reachable, then S can conclude that P is filtered –  If S does not have any clue on the reachability status of T, it cannot assume anything about the state of P•  We have implemented two algorithms for inter-domain stealthy port scan detection –  Rank-based SYN (R-SYN) port scan detection –  Line Fitting port scan detection
  15. 15. •  R-SYN algorithm* It recognizes half open connections (HOC) –  Sequence of SYN, ACK, RST packets in the 3-way TCP handshake •  Normal: (i) SYN, (ii) SYN-ACK, (iii) ACK •  SYN port scan: (i) SYN, (ii) SYN-ACK, (iii) RST (or nothing)•  It recognizes failed connections (FC) –  Unreachable hosts and closed ports •  Unreachable hosts: a sender, after a timeout the sending of a SYN packet, does not receive neither SYN-ACK nor RST-ACK packets •  Closed ports: it looks for RST-ACK reply packets•  source IP address x, it maintains the pairs (IP address, TCP port) probed by x (V(x))•  Using a proper ranking mechanism, it assigns a mark r to each source IP address x –  r(x) = f (HOC(x), FC(x), V(x)) –  If r(x) >= predefined threshold, x is a scanner * L. Aniello, G. Lodi, R. Baldoni, “Inter-Domain Stealthy Port Scan Detection through Complex Event Processing”, to appear in the Proceedings of 13th European Workshop on Dependable Computing (EWDC 2011), May 11-12, Pisa, Italy
  16. 16. Line Fitting algorithm*•  Underlying principle –  a scanner does not repeatedly perform the same operation towards specific hosts or ports •  if the attempt fails on a T:P a scanner likely carries out a malicious port scan towards different targets•  Line Fitting takes into account the set F{h} which is a multiset of failures generated by the source host h –  A normal failure: the set contains few elements with high multiplicity –  A port scan: the set includes many elements with low multiplicity * L. Aniello, G. A. Di Luna, G. Lodi, R. Baldoni, “A Collaborative Event Processing System for Protection of Critical Infrastructures From Cyber Attacks”, submitted for publication to International Conference, 2011.
  17. 17. Implementation in Esper•  Esper uses the so-called Event Processing Language (EPL) for defining continuous queries –  EPL is an SQL extension language•  Example: EPL query for detecting incomplete connections –  We exploit the “pattern” construct of EPL •  a is the stream of SYN packets, b is the stream of SYN+ACK packets, <c > is a filter for RST packets and <d > is the filter of ACK packets that would correctly complete 3-way handshaking •  Pattern matches if involved packets are within a time window of 61 sec
  18. 18. Results: detection accuracy
  19. 19. Results: detection latency
  20. 20. Concluding Remarks•  Collaboration can be beneficial –  In both algorithms, augmenting the number of SR Members (i.e., augmenting the volume of data to be correlated) leads to an increase of the detection rate –  Line Fitting converges more quickly to the highest detection rate compared to R-SYN•  Esper employed a centralized approach –  It can can be useful in case of small SRs with members which are not geographically dispersed –  It can become a bottleneck in case of high number of distributed SR members•  A distributed version can be necessary in order to improve scalability
  21. 21. Gregory Chockler (IBM)
  22. 22. Design Goals•  Enable processing for detecting cyber attacks•  Ensure privacy/confidentiality for locally generated data –  Sensitive information must not be exposed for global correlation•  Support for diverse types of input data –  E.g., real-time and long-lived historical data•  Easy-to-use, built using off-the-shelf components•  Scalable performance
  23. 23. Scaling Challenges•  Large numbers participating sites•  Possibly wide distribution•  Massive volumes of events•  High rates of incoming event traffic
  24. 24. Agilis Architecture Re-define InputFormat, OutputFormat Map-Reduce (Hadoop) Job Task Task Task Jaql Tracker Tracker Tracker Tracker Front-EndJaqlQuery Query WXS HDFS Scheduler Adapter Adapter Distributed In-Memory Store (WXS) Storage Storage Storage Cat 1 container container container Cat 2 Distributed File System (HDFS) Data Data Data Anonymizing Anonymizing Anonymizing Gateway Gateway Gateway … Pre-Processing Pre-Processing Pre-Processing . Raw Raw Raw Data Data Data Aglis Site 1 Agilis Site 2 Agilis Site N
  25. 25. Locality-Aware Collaboration•  Map tasks are mutually independent and can run in parallel at each site –  Can be run in parallel at each site•  Input data is partitioned among the sites –  Each partition is mapped into an input split –  Map tasks are collocated with their input splits•  Simple queries are delegated to the SQL engine embedded in data containers –  Select, project, and aggregate  Improves scalability by reducing the amount of data requiring global correlation
  26. 26. Processing Flow Parallelized Map/Reduce Jobs Summarized Data: Normalized [SourceIP, Prepr XS rNum,TCPDump Data: oces Part [LogEvent]* pNum]* sing 1 Summ Blacklis Black arizati ting List on Prepr XSTCPDump oces Part Summarized sing 2 Data Ranking Calibr ation Prepr XSTCPDump oces Part sing N [SourceIP,rank]* Historical Safety Ranking
  27. 27. Detection Algorithm (R-SYN)•  Recognizes two probe patterns –  Incomplete connection –  Failed connection•  Log unique tuples –  (sourceIP, destIP, destPort)•  Ranking: –  Rank(sourceIP) = F(#incomplete, #failed)
  28. 28. R-SYN Implementation in Agilis•  Gateway identifies incomplete and failed connections, and maintains tuples (IP, #incomplete, #failed)•  Jaql query for global correlation:
  29. 29. Latency Evaluation*•  287MB intrusion trace from dataset/index.html   Varied WAN link bandwidth   Partitioned across 6 Agilis sites   WANem simulator   Each site simulated by a Linux VM   Comparison against centralized event processing (Esper) * L. Aniello, R. Baldoni, G. Chockler, G. Laventman, G. Lodi, Y. Vigfusson, “Agilis: An Internet-Scale Distributed Event Processing System for Collaborative Detection of Cyber Attacks”, submitted for publication to International conference, 2011
  30. 30. Conclusions•  Agilis: Distributed platform for collaborative detection of cyber attacks•  Performance studies show scalability and highlight benefits of collaboration –  Port scan detection and botnet identification•  Ongoing work: improvements to the infrastructure –  Replacing WXS with open source RAM-based store, persistent & data-driven queries•  Evaluation on realistic data
  31. 31. UML modeling•  UML –  standardized, general-purpose modeling language•  Modeling the overall CoMiFin middleware –  Common understanding –  Coherent models•  Create –  high level –  technology independent models –  following MDA approach•  Main packages of the model –  Actors –  Components –  Common Data Types –  Diagrams
  32. 32. Diagrams•  Use Case diagrams•  High-level Component diagram•  Detailed component diagrams•  Class diagrams•  Data models•  Sequence diagrams•  Deployment diagrams•  Covering all parts of CoMiFin prototype –  123 diagrams, 1518 modeling element, 223 classes, 49 components, 89 sequence diagrams,…•  Example diagrams: SR Gateway component
  33. 33. Use Case diagram - Gateway
  34. 34. High-level Component diagram
  35. 35. Component diagram - Gateway
  36. 36. Class diagram - Gateway
  37. 37. Data model - Gateway•  Description of elements, components and concepts
  38. 38. Nov. 2010 attack – selected actionsEvent # Day # Time Event1 1 14:48 Bank1 is notified about infections3 1 16:05 Logon attempt from UK IP4 1 16:35 Bank2 sends Bank1 link to drop site5 2 09:00 Bank 1 analyzes the information received from Bank 26 2 09:10 Bank 1 comes across login information of customers of Bank 3, and duly warns Bank 3.16 3 13:04 Bank 1 analyzes config file of the infection that Bank 1 has received from Bank 2.17 3 18:45 Customer records are collected from drop site20 3 20:56 Analysis of config file reveals how the customer may recognize if the PC is infected.26 4 09:10 The certificates of compromised customers are revoked.29 4 09:16 The recent transaction history of compromised customers is analyzed.37 4 12:38 The Financial Supervisory Authority of Norway is notified of the attack.45 4 13:04 All certificates of compromised customers are revoked.47 4 13:10 There is a successful logon from a PC in UK.48 4 13:43 The infected PCs of compromised customers are collected.53 4 14:10 There are telephone calls with the cyber police.78 7 10:55 Bank1 receives samples of the Zeus virus from the cyber police.81 7 12:02 Discussions with the cyber police about how the Zeus virus works.104 8 09:21 New “stolen” login credentials are posted to drop site.… … … …
  39. 39. Lessons learnt  Banks today exchange information about incidents in an informal and accidental way  The way banks today exchange information about incidents does not scale  The cooperation between the banks and between the banks and the cyber police seems informal and based more or less on good will. One cannot help thinking that a more formal cooperation and exchange of information made possible by CoMiFin might further benefit the parties involved. Countermeasures might then be made at an earlier stage, reducing detrimental consequences of attacks and protect society as a whole against attacks.
  40. 40. Which are the events to look for?During log-in, the Trojan presents a false login-page. Whenthis happens, one bank had certain log-entries posted to thebank’s web-server log. The bank identified the signature ofthe log entry and developed an automated process thatrecognizes the signature, stops the login and alsoautomatically and instantly revokes the login-credentials ofthe customer. Sharing this information allowed other banksto implement similar countermeasures.
  41. 41. Which are the events to look for?Analysis revealed that at the time of writing this, the Trojanis very context sensitive, i.e. a small change to the web ofthe internet bank would fool the Trojan. This suggests thatusing random names for JavaScript functions and CSSclass names would make the Trojan not recognize where toinject the malicious code and probably render the Trojanuseless or less effective.
  42. 42. Which are the events to look for?One important quality of a Trojan, is its ability to hide itself.Encryption, hashing and other techniques are being usedfor this. If the obfuscation techniques are elaborate it takesresources and expertise to break them. Together the bankswere able to “undress” the Trojan effectively. Once“undressed”, the banks were able to device effectivecountermeasures.
  43. 43. Which are the events to look for?The national CERT (NSM) did a comprehensive technicalanalysis of SpyEye to be shared by all FIs. During this theydiscovered the IP of the Command and Control Center(CC). By contacting the Norwegian ISPs, they were able tomonitor the amount of traffic going from Norwegiancustomers to the CC. This way they got a picture of theseverity of the attack. Also steps could be taken to closedown the attack sites.
  44. 44. Supporting documentationThe CIFAS - the UKs Fraud Prevention Service, has releasedFraudscape, a report detailing the frauds recorded by the 265CIFAS Members during 2009. According to CIFAS,"the findings presented in Fraudscape, however, clearlydemonstrates the benefits that mutual collaboration brings. Bysharing knowledge and pooling resources, CIFAS Members haveprevented millions of pounds of fraud year after year and alsoincreased the knowledge of the methods used to defraudbusinesses, consumers and society equally. This approach canonly bring futher benefits if further cooperation and responsibledata-sharing takes place across all sections of society".