From NetAPT to NP-View A Case Study in Transferring - - PowerPoint PPT Presentation

▶
from netapt to np view a case study in transferring
SMART_READER_LITE
LIVE PREVIEW

From NetAPT to NP-View A Case Study in Transferring - - PowerPoint PPT Presentation

Jan 06, 2023 281 likes •751 views

COORDINATED SCIENCE LABORATORY ENGINEERING AT ILLINOIS From NetAPT to NP-View A Case Study in Transferring Technology from Academia to Industry ITI.ILLINOIS.EDU Robin

slide-1
SLIDE 1

ITI.ILLINOIS.EDU

COORDINATED SCIENCE LABORATORY ENGINEERING AT ILLINOIS

From ¡NetAPT ¡to ¡NP-­‑View ¡ A ¡Case ¡Study ¡in ¡Transferring ¡Technology ¡ ¡ from ¡Academia ¡to ¡Industry ¡

Robin ¡Berthier ¡

slide-2
SLIDE 2

Tech ¡Transfer ¡from ¡Academia ¡

Source: ¡the ¡Associa<on ¡of ¡University ¡Technology ¡Managers ¡(AUTM), ¡U.S. ¡licensing ¡ac<vity ¡survey ¡FY2012 ¡

5,130 ¡licenses ¡executed ¡

(40,007 ¡ac<ve ¡licenses) ¡

705 ¡new ¡startups ¡formed ¡

(4,002 ¡s<ll ¡opera<ng) ¡

23,741 ¡disclosures ¡received ¡ (+8.6%) ¡

14,224 ¡new ¡patent ¡applica<ons ¡filed ¡ (+7.2%) ¡ 5,145 ¡issued ¡U.S. ¡patents ¡ (+9.5%) ¡

$2.6 ¡billion ¡in ¡license ¡income ¡ (+6.8%) ¡

in ¡the ¡U.S. ¡ ¡ in ¡2012 ¡

slide-3
SLIDE 3

Background ¡

  • Intrusion ¡Detec<on ¡

– Specifica<on-­‑based ¡IDS ¡for ¡AMI ¡(Amilyzer) ¡ – Machine ¡learning-­‑based ¡IDS ¡for ¡account ¡compromise ¡ (UCAAS) ¡ – Hybrid ¡honeypot ¡management ¡framework ¡(Honeybrid) ¡

  • Network ¡Analysis ¡

– Ne]low-­‑based ¡situa<onal ¡awareness ¡tool ¡(Nfsight) ¡ – Network ¡Access ¡Policy ¡Tool ¡(NetAPT) ¡

  • Incident ¡Response ¡

– Response ¡and ¡Recovery ¡Engine ¡(RRE) ¡

  • Cri<cal ¡Infrastructure ¡Security ¡

– False ¡data ¡injec<on ¡mi<ga<on ¡ – Energy ¡thea ¡protec<on ¡

slide-4
SLIDE 4

Experiences ¡Transferring ¡Technologies ¡

Honeybrid ¡ ¡hbp://honeybrid.sourceforge.net ¡ ¡ Nfsight ¡ ¡hbp://nfsight.sourceforge.net ¡ ¡ Amilyzer ¡ ¡hbp://tcipg.org/research_IDS-­‑for-­‑AMI ¡ ¡ NetAPT ¡ ¡hbp://www.network-­‑percep<on.com/ ¡ ¡

slide-5
SLIDE 5

Experiences ¡Transferring ¡Technologies ¡

Honeybrid ¡ ¡hbp://honeybrid.sourceforge.net ¡ ¡ Nfsight ¡ ¡hbp://nfsight.sourceforge.net ¡ ¡ Amilyzer ¡ ¡hbp://tcipg.org/research_IDS-­‑for-­‑AMI ¡ ¡ NetAPT ¡ ¡hbp://www.network-­‑percep<on.com/ ¡ ¡

slide-6
SLIDE 6

Background ¡on ¡NetAPT ¡

  • PhD ¡thesis ¡project ¡by ¡Sankalp ¡Singh, ¡started ¡in ¡2006 ¡ ¡
  • Ini<ally ¡funded ¡by ¡I3P ¡from ¡2007 ¡to ¡2009 ¡
  • Then ¡funded ¡by ¡ICSEG ¡and ¡TCIPG ¡(DOE ¡& ¡DHS) ¡
  • Now ¡funded ¡through ¡DHS ¡for ¡commercializa<on ¡
  • Team ¡today: ¡

– Jenny ¡Applequist ¡ – Robin ¡Berthier ¡ – Mouna ¡Bamba ¡ – Faisal ¡Hasan ¡ – Rakesh ¡Kumar ¡ – Prof. ¡David ¡Nicol ¡ – Edmond ¡Rogers ¡ – Prof. ¡William ¡Sanders ¡

I3P: ¡Ins<tute ¡for ¡Informa<on ¡Infrastructure ¡Protec<on. ¡ICSEG: ¡Illinois ¡Center ¡for ¡a ¡Smarter ¡Electric ¡Grid ¡

slide-7
SLIDE 7

Mo<va<on: ¡Cri<cal ¡Infrastructure ¡Protec<on ¡

  • Process ¡control ¡networks ¡are ¡increasingly ¡connected ¡to ¡other ¡networks ¡in ¡

enterprise ¡systems. ¡ ¡

7 ¡

  • Access ¡controlled ¡by ¡configuring ¡poten<ally ¡many ¡firewalls ¡

⇒ ¡Subtle ¡errors ¡are ¡common ¡and ¡hard ¡to ¡detect ¡

slide-8
SLIDE 8

Mo<va<on: ¡Cri<cal ¡Infrastructure ¡Protec<on ¡

  • Process ¡control ¡networks ¡are ¡increasingly ¡connected ¡to ¡other ¡networks ¡in ¡

enterprise ¡systems. ¡ ¡

8 ¡

  • Access ¡controlled ¡by ¡configuring ¡poten<ally ¡many ¡firewalls ¡

⇒ ¡Subtle ¡errors ¡are ¡common ¡and ¡hard ¡to ¡detect ¡

Direct ¡traffic ¡between ¡ Corporate ¡and ¡Control ¡networks ¡ should ¡be ¡prevented. ¡ ¡ All ¡outbound ¡traffic ¡should ¡end ¡ in ¡DMZ ¡

  • Government ¡mandated ¡compliance ¡requirements ¡exist, ¡e.g., ¡NERC ¡CIPs ¡for ¡the ¡

power ¡sector ¡

  • Best ¡prac<ces ¡recommenda<ons ¡exist, ¡e.g. ¡NIST ¡SP ¡800-­‑82, ¡but ¡at ¡a ¡high-­‑level ¡
slide-9
SLIDE 9

Audit ¡Viola<on ¡

slide-10
SLIDE 10

Need ¡& ¡Approach ¡

  • Strong ¡need ¡for ¡an ¡automated ¡solu<on ¡to ¡help ¡

compliance ¡officers ¡and ¡auditors ¡beber ¡understand ¡ networks ¡and ¡the ¡effects ¡of ¡access ¡controls ¡

  • NetAPT ¡infers ¡the ¡network ¡ ¡

topology ¡from ¡firewall ¡ ¡ configura<on ¡and ¡ ¡ automa=cally ¡analyzes ¡ ¡ end-­‑to-­‑end ¡connec<vity ¡ ¡ ¡

– Visual ¡network ¡explora<on ¡ – Significantly ¡reduces ¡resources ¡needed ¡to ¡comply ¡with ¡ regula<ons ¡ – Improves ¡accuracy ¡of ¡security ¡analysis ¡

slide-11
SLIDE 11

DEMO ¡

slide-12
SLIDE 12

Technology ¡Transfer ¡of ¡NetAPT ¡

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡ Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

slide-13
SLIDE 13

Technology ¡Transfer ¡of ¡NetAPT ¡

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

slide-14
SLIDE 14

Inven<on ¡Disclosure ¡

  • First ¡step ¡in ¡commercializa<on ¡process ¡
slide-15
SLIDE 15

Inven<on ¡Disclosure ¡(cont.) ¡

  • Systema<c ¡process ¡to ¡follow ¡

Source: ¡hbp://otm.illinois.edu/uiuc_commprocess ¡

slide-16
SLIDE 16

Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

Technology ¡Transfer ¡of ¡NetAPT ¡

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

slide-17
SLIDE 17
slide-18
SLIDE 18

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

Technology ¡Transfer ¡of ¡NetAPT ¡

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡
slide-19
SLIDE 19

Funding ¡from ¡Department ¡of ¡Homeland ¡Security ¡

  • Science ¡and ¡Technology ¡Directorate, ¡ ¡

Cyber ¡Security ¡Division ¡

– Directed ¡by ¡Dr. ¡Douglas ¡Maughan ¡ – Part ¡of ¡the ¡Homeland ¡Security ¡Advanced ¡Research ¡Projects ¡ Agency ¡(HSARPA) ¡

  • Objec<ve: ¡

– Develop ¡and ¡transi<on ¡new ¡technologies, ¡tools, ¡and ¡ techniques ¡to ¡protect ¡and ¡secure ¡systems, ¡networks, ¡ infrastructure, ¡and ¡users ¡

slide-20
SLIDE 20

Key ¡Benefits ¡

  • Expand ¡evalua<on ¡program ¡to ¡get ¡the ¡tool ¡in ¡

the ¡hands ¡of ¡more ¡users ¡

  • Receive ¡feedback ¡and ¡bug ¡reports ¡
  • Grow ¡development ¡resources ¡to ¡beber ¡meet ¡

the ¡needs ¡of ¡users ¡

  • Develop ¡documenta<on ¡and ¡training ¡material ¡
slide-21
SLIDE 21

User ¡Interac<ons ¡

  • Evalua<on ¡license ¡signed ¡by ¡20 ¡new ¡organiza<ons ¡
  • ver ¡1 ¡year ¡

– U<li<es ¡ – Auditors ¡ – Consultants ¡

  • Par<cipated ¡in ¡audits ¡and ¡helped ¡u<li<es ¡

– Tool ¡enhanced ¡based ¡on ¡user ¡feedback ¡and ¡specific ¡ firewall ¡configura<ons ¡to ¡assist ¡through ¡audit ¡prepara<on ¡

  • Held ¡first ¡tutorial ¡in ¡Dallas ¡on ¡May ¡22, ¡following ¡

Southwest ¡Power ¡Pool ¡(SPP) ¡CIP ¡workshop ¡

– 17 ¡abendees ¡

slide-22
SLIDE 22

Lessons ¡Learned ¡

  • Progressive ¡transi<on ¡from ¡a ¡research-­‑centric ¡

to ¡a ¡user-­‑centric ¡development ¡roadmap ¡

  • 1. Challenges ¡to ¡install ¡the ¡tool ¡
  • 2. Difficul<es ¡to ¡grasp ¡the ¡concept ¡of ¡global ¡policy ¡
  • 3. Challenges ¡to ¡cover ¡firewall ¡vendors ¡
  • 4. Need ¡to ¡include ¡rou<ng ¡devices ¡
  • 5. Need ¡to ¡improve ¡workflow ¡and ¡repor<ng ¡

features ¡to ¡beber ¡prepare ¡for ¡audits ¡

slide-23
SLIDE 23
  • 1. ¡Challenges ¡to ¡Install ¡the ¡Tool ¡
  • Dependencies ¡on ¡mul<ple ¡development ¡

languages ¡and ¡libraries ¡increased ¡the ¡risk ¡of ¡ errors ¡during ¡installa<on ¡

  • Significant ¡refactoring ¡efforts ¡to: ¡

– Simplify ¡codebase ¡ – Simplify ¡debugging ¡and ¡error ¡repor<ng ¡ – Enable ¡rapid ¡prototyping ¡

slide-24
SLIDE 24

“Remote ¡access ¡to ¡cri<cal ¡assets ¡shall ¡be ¡denied” ¡ “All ¡flows ¡origina<ng ¡outside ¡of ¡control ¡network ¡towards ¡ IP ¡addresses ¡of ¡cri<cal ¡assets ¡should ¡be ¡denied” ¡

Regula<ons ¡& ¡Best ¡Prac<ces ¡ Access ¡Policy ¡ Implementa<on ¡

Cisco Firewall #1: access-list 101 deny tcp 192.168.0.0 0.0.0.255 host 10.1.2.3 eq www access-list 101 deny tcp 192.168.0.0 0.0.0.255 host 10.3.2.1 eq www …

  • 2. ¡Difficul<es ¡to ¡Understand ¡the ¡Concept ¡of ¡Global ¡Policy ¡
slide-25
SLIDE 25

Regula<ons ¡& ¡Best ¡Prac<ces ¡ Access ¡Policy ¡ Implementa<on ¡

“Remote ¡access ¡to ¡cri<cal ¡assets ¡shall ¡be ¡denied” ¡ “All ¡flows ¡origina<ng ¡outside ¡of ¡control ¡network ¡towards ¡ IP ¡addresses ¡of ¡cri<cal ¡assets ¡should ¡be ¡denied” ¡

Cisco Firewall #1: access-list 101 deny tcp 192.168.0.0 0.0.0.255 host 10.1.2.3 eq www access-list 101 deny tcp 192.168.0.0 0.0.0.255 host 10.3.2.1 eq www …

GUI ¡ Engine ¡

  • 2. ¡Difficul<es ¡to ¡Understand ¡the ¡Concept ¡of ¡Global ¡Policy ¡(cont.) ¡
slide-26
SLIDE 26

Policy ¡Focusing ¡on ¡Repor<ng ¡Possible ¡Flows ¡

  • Report ¡flows ¡that ¡match ¡some ¡specifica<on ¡of ¡

what ¡is ¡interes<ng ¡ ¡

  • Specify ¡conforming ¡flows, ¡and ¡have ¡the ¡tool ¡to ¡

iden<fy ¡and ¡report ¡any ¡flows ¡that ¡are ¡ admibed ¡but ¡are ¡outside ¡of ¡the ¡specifica<ons ¡

  • Introduc<on ¡of ¡the ¡concept ¡of ¡domain ¡to ¡

restrict ¡analysis ¡to ¡specific ¡parts ¡of ¡the ¡ network ¡

slide-27
SLIDE 27

NetAPT Architecture

Host-­‑based, ¡router-­‑based ¡dedicated ¡ firewalls ¡or ¡OS-­‑based ¡access ¡control ¡

¡

Rule-­‑sets ¡in ¡na<ve ¡format ¡ Import ¡firewall ¡configura<ons ¡

Topology ¡

(XML) ¡

Rule-­‑sets ¡

(XML) ¡ Specify ¡Policies ¡ applying ¡templates ¡ to ¡topology ¡

Policies ¡

(XML) ¡

Conformance ¡ Analysis ¡

Viola8on ¡found: ¡add ¡policy ¡excep8on ¡ Viola8on ¡found: ¡adjust ¡rules ¡

Compliant ¡configura<on ¡

slide-28
SLIDE 28

Policy ¡Formalism ¡

  • Intui<vely ¡defined ¡

from ¡the ¡GUI ¡

<?xml version='1.0' encoding='us-ascii'?> <!DOCTYPE FlowDifferenceSet[ <!ELEMENT FlowDifferenceSet(NetworkGroup*, ServiceGroup*, ICMPGroup*, ProtocolGroup*, FlowDifference*)> <!ELEMENT NetworkGroup (Description, AddressBlock+)> <!ATTLIST NetworkGroup name CDATA #REQUIRED> <!ELEMENT AddressBlock EMPTY> <!ATTLIST AddressBlock NetAddress CDATA #REQUIRED> <!ATTLIST AddressBlock NetMask CDATA #REQUIRED> <!ELEMENT ServiceGroup (Description, PortRange+)> <!ATTLIST ServiceGroup name CDATA #REQUIRED> <!ELEMENT PortRange EMPTY> <!ATTLIST PortRange protocol CDATA #REQUIRED> <!ATTLIST PortRange beginPort CDATA #REQUIRED> <!ATTLIST PortRange endPort CDATA #REQUIRED> <!ELEMENT ICMPGroup (Description, ICMPType+)> <!ATTLIST ICMPGroup name CDATA #REQUIRED> <!ELEMENT ICMPType EMPTY> <!ATTLIST ICMPType type CDATA #REQUIRED> <!ELEMENT ProtocolGroup (Description, ProtocolID+)> <!ATTLIST ProtocolGroup name CDATA #REQUIRED> <!ELEMENT ProtocolID EMPTY> <!ATTLIST ProtocolID protocol CDATA #REQUIRED> <!ELEMENT FlowDifference(Include*, Exclude*)> <!ATTLIST FlowDifference name CDATA #REQUIRED> <!ELEMENT Include (Flow+)> <!ELEMENT Exclude (Flow+)> <!ELEMENT Flow EMPTY> <!ATTLIST Flow name CDATA #REQUIRED> <!ATTLIST Flow nodeRef CDATA #REQUIRED> <!ATTLIST Flow direction CDATA #REQUIRED> <!ATTLIST Flow sourceIP CDATA #REQUIRED> <!ATTLIST Flow sourceMask CDATA #REQUIRED> <!ATTLIST Flow sourcePortRange CDATA #REQUIRED> <!ATTLIST Flow destinationIP CDATA #REQUIRED> <!ATTLIST Flow destinationMask CDATA #REQUIRED> <!ATTLIST Flow destinationPortRange CDATA #REQUIRED> <!ATTLIST Flow ipProtocol CDATA #REQUIRED> <!ATTLIST Flow description CDATA #REQUIRED> <!ELEMENT Description (#PCDATA)>

slide-29
SLIDE 29
  • 3. ¡Challenge ¡to ¡Cover ¡Firewall ¡Vendors ¡

In ¡theory: ¡

¡

  • Each ¡firewall ¡has ¡a ¡collec<on ¡of ¡

group ¡defini8ons ¡and ¡Access ¡ Control ¡Lists ¡(ACLs) ¡

  • Each ¡ACL ¡bound ¡to ¡a ¡par<cular ¡

interface ¡

  • ACLs ¡are ¡comprised ¡of ¡list ¡of ¡

rules, ¡processed ¡sequen<ally. ¡ ¡

  • Each ¡rule ¡is ¡of ¡the ¡form ¡<P, ¡

ac8on> ¡

– P: ¡predicate ¡characterizing ¡the ¡ abributes ¡of ¡the ¡traffic ¡ – ac8on: ¡is ¡one ¡of ¡{accept, ¡deny, ¡ drop} ¡

Rule # ¡

  • Prot. ¡

Source ¡ Des=na=on ¡ Ac=on ¡

  • 1. ¡

tcp ¡ 10.1.1.0/25 ¡ Any ¡ Deny ¡

  • 2. ¡

udp ¡ Any ¡ 192.168.1.0/24 ¡ Accept ¡

  • 3. ¡

tcp ¡ 10.1.1.128/25 ¡ Any ¡ Deny ¡

  • 4. ¡

udp ¡ 172.16.1.0/24 ¡ 192.168.1.0/24 ¡ Deny ¡

  • 5. ¡

tcp ¡ 10.1.1.0/24 ¡ Any ¡ Accept ¡

  • 6. ¡

udp ¡ 10.1.1.0/24 ¡ 192.168.0.0/16 ¡ Deny ¡

  • 7. ¡

udp ¡ 172.16.1.0/24 ¡ Any ¡ Accept ¡

slide-30
SLIDE 30

Variety ¡of ¡Configura<on ¡Formats ¡

access-list 100 deny ip 192.168.0.0 0.0.0.255 any access-list 100 permit ip any any

“Access ¡control ¡list” ¡in ¡Cisco ¡IOS: ¡

Firewall { filter sample-filter {

  • term block-bad-subnet {
  • from {
  • source-address {
  • 192.168.0.0/24;
  • }
  • }
  • then {
  • reject;
  • }
  • }
  • term accept-all {
  • then accept;
  • }

} }

“Firewall ¡filter” ¡equivalent ¡in ¡JUNOS: ¡

config firewall policy edit 1

  • set srcintf internal
  • set scraddr 192.168.0.0/24
  • set dstintf wan1
  • set dstaddr all
  • set action deny
  • set schedule always
  • set service “any”

next edit 2

  • set srcintf "internal"

set dstintf "wan1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service ”any” next end

“Policy” ¡equivalent ¡in ¡For=net: ¡

In ¡prac<ce: ¡

slide-31
SLIDE 31

Formalisms ¡for ¡Access ¡Control ¡Elements ¡

  • Developed ¡an ¡XML-­‑based ¡unified ¡schema ¡that ¡

provides ¡an ¡intermediate ¡representa<on ¡for ¡several ¡ types ¡and ¡vendors ¡of ¡firewalls ¡

– Cisco, ¡Juniper, ¡Checkpoint, ¡SonicWall, ¡For<net ¡

  • Challenge ¡in ¡modeling ¡extensive ¡list ¡of ¡features ¡and ¡

func<onality, ¡including ¡ ¡

– NAT ¡(sta<c/dynamic) ¡ – Rou<ng ¡ – Virtual ¡Private ¡Networks ¡(VPNs) ¡ – ACL ¡chains ¡ ¡ – Virtual ¡addresses ¡

31 ¡

slide-32
SLIDE 32

Formalisms ¡for ¡Access ¡Control ¡Elements ¡

  • Developed ¡an ¡XML-­‑based ¡unified ¡schema ¡that ¡

provides ¡an ¡intermediate ¡representa<on ¡for ¡several ¡ types ¡and ¡vendors ¡of ¡firewalls ¡

– Cisco, ¡Juniper, ¡Checkpoint, ¡SonicWall, ¡For<net ¡

  • Challenge ¡in ¡modeling ¡extensive ¡list ¡of ¡features ¡and ¡

func<onality, ¡including ¡ ¡

– NAT ¡(sta<c/dynamic) ¡ – Rou<ng ¡ – Virtual ¡Private ¡Networks ¡(VPNs) ¡ – ACL ¡chains ¡ ¡ – Virtual ¡addresses ¡

32 ¡

<?xml version='1.0' encoding='us-ascii'?> <!DOCTYPE RuleSetCollection [ <!ELEMENT RuleSetCollection (RuleSet*)> <!ELEMENT RuleSet (Description, IPInterface*, NetworkGroup*, ServiceGroup*, ICMPGroup*, ProtocolGroup*, AccessList*)> <!ATTLIST RuleSet name CDATA #REQUIRED> <!ATTLIST RuleSet fragsAllowed (true | false) #REQUIRED> <!ATTLIST RuleSet nonIPTrafficAllowed (true | false) #REQUIRED> <!ATTLIST RuleSet sniffingAllowed (true | false) #REQUIRED> <!ATTLIST RuleSet spoofingAllowed (true | false) #REQUIRED> <!ATTLIST RuleSet ipOptionAllowed (true | false) #REQUIRED> <!ATTLIST RuleSet testMode (true | false) #REQUIRED> <!ATTLIST RuleSet fallbackMode CDATA #REQUIRED> <!ELEMENT IPInterface EMPTY> <!ATTLIST IPInterface name CDATA #REQUIRED> <!ATTLIST IPInterface address CDATA #REQUIRED> <!ATTLIST IPInterface netmask CDATA #REQUIRED> <!ELEMENT NetworkGroup (Description, AddressBlock+)> <!ATTLIST NetworkGroup name CDATA #REQUIRED> <!ELEMENT AddressBlock EMPTY> <!ATTLIST AddressBlock NetAddress CDATA #REQUIRED> <!ATTLIST AddressBlock NetMask CDATA #REQUIRED> <!ELEMENT ServiceGroup (Description, PortRange+)> <!ATTLIST ServiceGroup name CDATA #REQUIRED> <!ELEMENT PortRange EMPTY> <!ATTLIST PortRange protocol CDATA #REQUIRED> <!ATTLIST PortRange beginPort CDATA #REQUIRED> <!ATTLIST PortRange endPort CDATA #REQUIRED> <!ELEMENT ICMPGroup (Description, ICMPType+)> <!ATTLIST ICMPGroup name CDATA #REQUIRED> <!ELEMENT ICMPType EMPTY> <!ATTLIST ICMPType type CDATA #REQUIRED> <!ELEMENT ProtocolGroup (Description, ProtocolID+)> <!ATTLIST ProtocolGroup name CDATA #REQUIRED> <!ELEMENT ProtocolID EMPTY> <!ATTLIST ProtocolID protocol CDATA #REQUIRED> <!ELEMENT AccessList (Description, AuthorizedUsers*, Rule*)> <!ATTLIST AccessList name CDATA #REQUIRED> <!ATTLIST AccessList incomingInterface CDATA #REQUIRED> <!ATTLIST AccessList authenticationACL (true | false) #REQUIRED> <!ELEMENT AuthorizedUsers (User*)> <!ATTLIST AuthorizedUsers aaaServerAddress CDATA #REQUIRED> <!ATTLIST AuthorizedUsers aaaServerProtocol CDATA #REQUIRED> <!ELEMENT User EMPTY> <!ATTLIST User name CDATA #REQUIRED> <!ELEMENT Rule (Description)> <!ATTLIST Rule name CDATA #REQUIRED> <!ATTLIST Rule sourceHostID CDATA #REQUIRED> <!ATTLIST Rule sourcePortRange CDATA #REQUIRED> <!ATTLIST Rule sourceMask CDATA #REQUIRED> <!ATTLIST Rule destinationHostID CDATA #REQUIRED> <!ATTLIST Rule destinationPortRange CDATA #REQUIRED> <!ATTLIST Rule destinationMask CDATA #REQUIRED> <!ATTLIST Rule direction CDATA #REQUIRED> <!ATTLIST Rule action CDATA #REQUIRED> <!ATTLIST Rule ipProtocol CDATA #REQUIRED> <!ATTLIST Rule enabled (true | false) #REQUIRED> <!ATTLIST Rule audit CDATA #REQUIRED> <!ATTLIST Rule testMode (true | false) #REQUIRED> <!ATTLIST Rule ruleNegated (true | false) #REQUIRED> <!ATTLIST Rule allowTcpConnectInit (true | false) #REQUIRED> <!ELEMENT Description (#PCDATA)> ]>

slide-33
SLIDE 33

Addi<onal ¡Challenges ¡to ¡Accurately ¡Model ¡ ¡ How ¡Packets ¡Traverse ¡Firewalls ¡

Juniper ¡ For=net ¡

slide-34
SLIDE 34
  • 4. ¡Need ¡to ¡Include ¡Rou<ng ¡Devices ¡

34 ¡

  • Firewall ¡configura<ons ¡contain ¡elements ¡of ¡connec<vity ¡info ¡
  • Descrip<ons ¡of ¡interfaces ¡and ¡networks ¡connected ¡to ¡interfaces ¡
  • Some ¡rou<ng ¡statements ¡
  • VPN ¡descrip<ons ¡
  • Topology ¡inference ¡algorithm ¡build ¡knowledge ¡of ¡topology ¡out ¡from ¡the ¡

elemental ¡connec<vity ¡data ¡

  • Core ¡task ¡to ¡merge ¡networks ¡described ¡(differently) ¡in ¡mul<ple ¡loca<ons ¡
  • Layer-­‑3 ¡devices ¡also ¡have ¡access ¡control ¡lists ¡and ¡important ¡rou<ng ¡

informa<on ¡that ¡affect ¡network ¡connec<vity ¡

192.168.1.80/25 ¡ 192.168.2.80/24 ¡ 192.168.0.80/24 ¡ 192.168.1.80/25 ¡ merge ¡ ¡

  • pera<on ¡
slide-35
SLIDE 35
  • 5. ¡Improving ¡Workflow ¡and ¡Repor<ng ¡Features ¡
  • Current ¡features: ¡

– Path ¡highlight ¡ – Export ¡results ¡to ¡ Excel ¡

slide-36
SLIDE 36
  • 5. ¡Improving ¡Workflow ¡and ¡Repor<ng ¡Features ¡(cont.) ¡
  • Feedback ¡from ¡users ¡

– Step-­‑by-­‑step ¡set ¡of ¡tasks ¡to ¡prepare ¡for ¡an ¡audit ¡ – Visualizing ¡electronic ¡security ¡perimeter ¡ – Highligh<ng ¡risk ¡associated ¡with ¡dangerous ¡paths ¡

  • Improving ¡GUI ¡and ¡filtering ¡features ¡
  • Introducing ¡defense-­‑in-­‑depth ¡metrics ¡

– Depth: ¡minimum ¡number ¡of ¡stepping ¡stones ¡required ¡ for ¡access ¡ – Width: ¡measure ¡of ¡number ¡of ¡abacking ¡hosts, ¡or ¡ unique ¡stepping ¡stone ¡aback ¡vectors ¡ – Long ¡depth, ¡low ¡width ¡reflects ¡<ght ¡configura<on ¡

slide-37
SLIDE 37

Defense ¡in ¡Depth ¡Metric ¡

slide-38
SLIDE 38

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

Technology ¡Transfer ¡of ¡NetAPT ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡

slide-39
SLIDE 39

Licensing ¡Technology ¡with ¡University ¡

  • Scope ¡of ¡license ¡rights ¡
  • Market ¡assessment ¡
  • Royalty ¡model ¡
  • Sublicensing ¡model ¡
  • Patent ¡reimbursement ¡
  • Performance ¡milestones ¡
slide-40
SLIDE 40

License ¡issued ¡in ¡August ¡2013 ¡ ¡ aaer ¡nego<a<on ¡with ¡OTM ¡

Funding ¡from ¡DHS ¡started ¡in ¡ ¡

  • Sep. ¡2012 ¡

Patent ¡filed ¡in ¡2008 ¡ Patent ¡issued ¡in ¡ ¡ June ¡2012 ¡

Disclosure ¡submibed ¡to ¡ OTM ¡in ¡2006 ¡

Technology ¡Transfer ¡of ¡NetAPT ¡

Network ¡Percep<on ¡startup ¡incorporated ¡this ¡summer ¡

slide-41
SLIDE 41

Startup ¡Incorpora<on ¡

  • Support ¡from ¡the ¡University ¡research ¡park ¡

– Grant ¡to ¡cover ¡ini<al ¡legal ¡and ¡accoun<ng ¡costs ¡ – Entrepreneur ¡mentor ¡ – Resources ¡for ¡logo ¡and ¡website ¡design ¡ – Assistance ¡to ¡find ¡funding ¡(e.g., ¡SBIRs) ¡

slide-42
SLIDE 42

Next ¡Steps ¡

  • Accepted ¡in ¡NSF ¡Innova<on ¡Corps ¡program ¡

– hbp://www.nsf.gov/news/special_reports/i-­‑corps/ ¡

  • Release ¡of ¡first ¡commercial ¡version ¡of ¡the ¡tool, ¡

called ¡NP-­‑View ¡

slide-43
SLIDE 43

Conclusions ¡

  • Technology ¡transfer ¡from ¡academia ¡is ¡a ¡well-­‑

defined ¡and ¡supported ¡process ¡

  • Key ¡to ¡design ¡a ¡viable ¡product ¡is ¡to ¡extensively ¡

interact ¡with ¡users ¡

– Commercial ¡product ¡will ¡be ¡different ¡from ¡ research ¡project ¡

  • Key ¡to ¡evaluate ¡solu<on ¡and ¡improve ¡

approach ¡is ¡to ¡enable ¡rapid ¡prototyping ¡

– Implemen<ng ¡agile ¡development ¡methods ¡ – Collabora<ng ¡with ¡industry ¡partners ¡early ¡

slide-44
SLIDE 44

Publica<ons ¡

Patent ¡

  • S. ¡Singh, ¡D. ¡M. ¡Nicol, ¡W. ¡H. ¡Sanders, ¡and ¡M. ¡Seri. ¡Analysis ¡of ¡Distributed ¡Policy ¡Rule-­‑

Sets ¡for ¡Compliance ¡with ¡Global ¡Policy. ¡Provisional ¡Patent ¡Applica8on ¡in ¡TF070703, ¡ BHGL ¡10322-­‑99, ¡Serial ¡Number ¡60/941, ¡132, ¡June ¡2007. ¡

Papers ¡

  • D. ¡M. ¡Nicol, ¡W. ¡H. ¡Sanders, ¡S. ¡Singh, ¡and ¡M. ¡Seri. ¡Usable ¡Global ¡Network ¡Access ¡

Policy ¡for ¡PCS. ¡IEEE ¡Security ¡and ¡Privacy, ¡6(6), ¡November-­‑December, ¡2008, ¡pp. ¡30-­‑36. ¡

  • D. ¡M. ¡Nicol, ¡W. ¡H. ¡Sanders, ¡S. ¡Singh, ¡and ¡M. ¡Seri. ¡Experiences ¡Valida<ng ¡the ¡Access ¡

Policy ¡Tool ¡in ¡Industrial ¡Seyngs. ¡In ¡Proceedings ¡of ¡the ¡43rd ¡Annual ¡Hawai’i ¡ Interna8onal ¡Conference ¡on ¡System ¡Sciences ¡(HICSS), ¡Koloa, ¡Kauai, ¡Hawaii, ¡January ¡ 5-­‑8, ¡2010, ¡pp. ¡1-­‑8. ¡

  • R. ¡K. ¡Cunningham, ¡S. ¡Cheung, ¡M. ¡Fong, ¡U. ¡Lindqvist, ¡D. ¡M. ¡Nicol, ¡R. ¡Pawlowski, ¡E. ¡

Robinson, ¡W. ¡H. ¡Sanders, ¡S. ¡Singh, ¡A. ¡Valdes, ¡B. ¡Woodworth, ¡and ¡M. ¡Zhivich. ¡ Securing ¡Process ¡Control ¡Systems ¡of ¡Today ¡and ¡Tomorrow. ¡In ¡Proceedings ¡of ¡the ¡IFIP ¡ WG ¡11.10 ¡Interna8onal ¡Conference ¡on ¡Cri8cal ¡Infrastructure ¡Protec8on, ¡Hanover, ¡ NH, ¡March ¡2007. ¡

  • S. ¡Singh, ¡D. ¡M. ¡Nicol, ¡W. ¡H. ¡Sanders, ¡and ¡M. ¡Seri. ¡Verifying ¡SCADA ¡Network ¡Access ¡

Control ¡Policy ¡Implementa<ons ¡Using ¡the ¡Access ¡Policy ¡Tool. ¡In ¡Proceedings ¡of ¡the ¡ IFIP ¡WG ¡11.10 ¡Interna8onal ¡Conference ¡on ¡Cri8cal ¡Infrastructure ¡Protec8on, ¡ Hanover, ¡NH, ¡March ¡2007. ¡

44 ¡

slide-45
SLIDE 45

Robin ¡Berthier ¡ rgb@network-­‑percep<on.com ¡ ¡ 240-­‑455-­‑4543 ¡