A Choreography-Driven Approach to APIs: The OpenDXL Case Study - - PowerPoint PPT Presentation

a choreography driven approach to apis the opendxl case
SMART_READER_LITE
LIVE PREVIEW

A Choreography-Driven Approach to APIs: The OpenDXL Case Study - - PowerPoint PPT Presentation

A Choreography-Driven Approach to APIs: The OpenDXL Case Study Leonardo Frittelli @ McAfee, Cordoba, AR Facundo Maldonado @ McAfee, Cordoba, AR Hern an Melgratti @ UBA, AR Emilio Tuosto @ GSSI, IT & UoL, UK Coordination 2020 15-20 July


slide-1
SLIDE 1

A Choreography-Driven Approach to APIs: The OpenDXL Case Study

Leonardo Frittelli @ McAfee, Cordoba, AR Facundo Maldonado @ McAfee, Cordoba, AR Hern´ an Melgratti @ UBA, AR Emilio Tuosto @ GSSI, IT & UoL, UK Coordination 2020 15-20 July 2020

Research partly supported by the EU H2020 RISE programme under the Marie Sk lodowska-Curie grant agreement No 778233.

slide-2
SLIDE 2

Prelude

slide-3
SLIDE 3

A fairy tale

(pictures from Matteo Garrone’s “Pinocchio”) Tell them...

slide-4
SLIDE 4

A fairy tale

(pictures from Matteo Garrone’s “Pinocchio”) and they’ll behave

slide-5
SLIDE 5

A fairy tale

(pictures from Matteo Garrone’s “Pinocchio”) unless they don’t

slide-6
SLIDE 6

A fairy tale

(pictures from Matteo Garrone’s “Pinocchio”) So, keep an eye on’em

slide-7
SLIDE 7

A fairy tale

(pictures from Matteo Garrone’s “Pinocchio”)

  • f course, it’s for their own good
slide-8
SLIDE 8

At a glance

API-based development

difficult in theory... ...and in practice

BehAPI

Behavioural specification of APIs can help

document monitor

Case study: OpenDXL

slide-9
SLIDE 9

Managing expectations

This work

reports on a collaboration with industry uses existing behavioural types proposes a methodology strives

to be easily usable by non-experts to attain practical benefits

slide-10
SLIDE 10

Managing expectations

No new technical contributions This work

reports on a collaboration with industry uses existing behavioural types proposes a methodology strives

to be easily usable by non-experts to attain practical benefits

slide-11
SLIDE 11

OpenDXL & Threat Intelligence Exchange

slide-12
SLIDE 12

Open Data Exchange Layer

slide-13
SLIDE 13

Architecture of OpenDXL

C Env C Env C Env B B S S S

Brokers abstracted away

slide-14
SLIDE 14

Architecture of OpenDXL

C Env C Env C Env S S S

Brokers abstracted away Event-based communication

slide-15
SLIDE 15

Architecture of OpenDXL

C Env C Env C Env S S S check

Brokers abstracted away Event-based communication

slide-16
SLIDE 16

Architecture of OpenDXL

C Env C Env C Env S S S res r e s res res

Brokers abstracted away Event-based communication

slide-17
SLIDE 17

An instance of OpenDXL services

TIE’s features

coordination of activities involving assessment of the security threats

  • f configuration files, certificates, unsigned or unknown files, etc.

prioritisation of analysis steps

focusing on malicious or unknown files

customisation of security queries

based on reputation-based data such as product or company names

reaction to suspicious indicators

slide-18
SLIDE 18

Documenting TIE

Semi-formal diagrams Verbal recommendations

a client “must have permission to send messages to the /mcafee/service/tie/reputation/set topic”

slide-19
SLIDE 19

Sounds good...in theory

In practice “Stuff” developed @McAfee works fine

McAfee provides the service and clients

but it’s a SOA: 3rd-party clients misbehave sometimes hence, defensive programming of TIE services

slide-20
SLIDE 20

Sounds good...in theory

In practice “Stuff” developed @McAfee works fine

McAfee provides the service and clients

but it’s a SOA: 3rd-party clients misbehave sometimes hence, defensive programming of TIE services

Caveat

3rd-party code may not be available for analysis Hence, post-mortem analysis of execution logs to identify misbehaviour and communicate it to 3rd-parties

slide-21
SLIDE 21

A methodology

slide-22
SLIDE 22

Idea

Adding more precision:

1 draw the protocol (global choreography) 2 turn the “drawing” into a behavioural type 3 project to component specs (local types) 4 turn local specs into state machines

Advantages

global choreographies: formal & precise (Pomset or Event Structure semanticsa), yet intuitive algorithmically generate monitors enhance “program comprehension”

aSee Ugo de’Liguoro’s talk @ ICE 2020

slide-23
SLIDE 23

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

slide-24
SLIDE 24

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

  • C sends meta-data
slide-25
SLIDE 25

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

  • C requests an assessment
slide-26
SLIDE 26

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

  • nested choice
slide-27
SLIDE 27

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

  • S publishes a new report
slide-28
SLIDE 28

Let’s tie our TIE

After a couple of meetings...

C− →S: MD(x) S− →C: Restt(x) C− →S: MD(x) C− →S: File(x) S− →C: Resft(x) C− →S: File(x) S− →C: Restf(x) C− →S: MD(x) S− →C: Resff(x) + + C− →S: Req(x) + + KNR

  • DISCLAIMER

No greek letters were used in the making of this global view

slide-29
SLIDE 29

If you’re versed in behavioural types

Behavioural types

Suitable devices for specification and analysis focus on control (mostly) assume point-to-point channels

slide-30
SLIDE 30

If you’re versed in behavioural types

Behavioural types

Suitable devices for specification and analysis focus on control (mostly) assume point-to-point channels

vs

Klaimographies

Behavioural types with focus on data (mostly) interactions based on generative communication unit & multi-roles

slide-31
SLIDE 31

Monitors from projections

UML-like

@startuml left to right direction [*] --> S0 S0 --> S0: ’MD’ @l @Dgt S0 --> S1: ’Req’@l S1 --> S2: (’Res’, ’1’, ’1’)@l -> @Dgt S1 --> S3: (’Res’, ’0’, ’1’)@l -> @Dgt S1 --> S4: (’Res’, ’1’, ’0’)@l -> @Dgt S1 --> S0: (’Res’, ’0’, ’0’)@l S2 --> S3: ’MD’@l -> @Dgt S3 --> S0: ’File’@f S4 --> S0: ’MD’@l @enduml

Transformation Manual (for now) but algorithmic ’@...’ for data-flow analysis huge logs (can’t fit memory) Monitor checks expected data correspondences (e.g., ’file’ corresponds to a ’file req’)

slide-32
SLIDE 32

Lessons learned

slide-33
SLIDE 33

Effectiveness & Reproducibility (of (meta-)communication)

non-deterministic & visual abstractions

help communication among stakeholders provide insights & “inspirations”

but semantics is necessary

to attain precision to change mind

a reviewer was “missing the difficulties in this formalisation”

slide-34
SLIDE 34

Generality

how tight to TIE are we? klaimographies were not designed for OpenDXL a reviewer noted: “event-based middleware are becoming the norm” choreography can go bottom-up (as noted by another reviewer)

slide-35
SLIDE 35

Other FM?

Sure / but ... Model checking but it is not easy for lay-users to express properties in some temporal logic Other behavioural types usually too many greek letters Other FM (Petri nets, event structures,...) too low level (and (sadly) not much studied anymore)

slide-36
SLIDE 36

What’s next?

Tool support (extend ChorGram)

validated global views ensure properties automatise projections code generation (eg TIE vs many versions/variants)

Extend the application to other services of TIE / OpenDXL Klaimographies-inspired abstractions for CAS

slide-37
SLIDE 37

Thank you and to the anonymous reviewers!