Understanding the Role of Automated Response AcOons to Improve AMI - - PowerPoint PPT Presentation

Understanding the Role of Automated Response AcOons to Improve AMI ¡Resiliency

Ahmed Fawaz1, Robin Berthier1, Bill Sanders1, Partha Pal2 April 24, 2012

1University of Illinois at Urbana ¡Champaign 2BBN Technologies ¡

| 1

TCIPG Mission

• IdenOfy and address criOcal
• Research Excellence

security and resiliency needs at – Balance long-­‑range basic the cyber-­‑physical juncOon in research with the need to the evolving power grid develop pracOcal soluOons in – Meet ¡the challenge of rapid the near term evoluOon and mixed legacy – PublicaOons and conference environment ¡ presentaOons – Address the proliferaOon of – TCIPG is the “go to” devices, demand response, academic center DG integraOon, HAN…

• EducaOon

– Emphasis on trust ¡and – Develop university students resiliency ¡ who will be experts in the

• Engage Industry (uOlity, control

field ¡ system vendors, technology – Outreach to K-­‑12 students providers) ¡ and the public – Ensure relevance of research – Foster technology transfer

| 2

TCIPG StaOsOcs

• Builds upon $7.5M ¡NSF TCIP CyberTrust Center 2005-­‑2010
• $18.8M ¡over 5 years, starOng Oct ¡1, 2009
• Funded by Department ¡of Energy, Office of Electricity and

Department ¡of Homeland Security

• 5 UniversiOes ¡

– University of Illinois at Urbana-­‑Champaign – Washington State University – University of California ¡at Davis – Dartmouth College – Cornell University

• 20 Faculty, 20 Senior Technical Staff, 37 Graduate Students, 5

Undergraduate Students, and 1 Admin

| 3

Industry InteracOon: Vendors and UOliOes that ¡have parOcipated in TCIPG Events

| 4

Industry InteracOon: Other organizaOons that ¡have parOcipated in TCIPG Events

| 5

TCIPG Impacts all aspects of the 2011 Roadmap to Achieve Energy Delivery Systems Cybersecurity

TCIPG Eff

• rts

Build a Culture of Security ¡

Conduct summer ¡ schools ¡for industry ¡ Develop K-­‑12 power/cyber curriculum ¡ Develop public ¡ energy literacy Directly interact with industry Educate next-­‑ generaNon cyber-­‑ power aware workforce

Assess and Monitor Risk ¡

Analyze security of protocols ¡(e.g. DNP3, Zigbee, ¡ ICCP, ¡C12.22) ¡ Create ¡tools ¡for ¡ assessing ¡security ¡of devices, ¡systems, ¡& use cases ¡ Create ¡integrated scalable cyber/ physical ¡modeling infrastructure Distribute ¡NetAPT for ¡use ¡by uNliNes and auditors ¡ Create ¡fuzzing ¡ tools for SCADA ¡ protocols ¡

ProtecNve ¡ Measures/Risk ¡ ReducNon

Build secure, ¡real-­‑ Nme, & flexible ¡ communicaNon mechanisms for ¡ WAMS Design secure ¡ informaNon ¡layer for ¡V2G ¡ Provide ¡malicious ¡ power system data detecNon ¡and protecNon ¡ ParNcipate ¡in industry-­‑led ¡CEDS ¡ projects ¡

Manage Incidents ¡

Build game-­‑ theoreNc Response and recovery ¡ engine ¡ Develop forensic ¡ data analysis to support ¡response Create ¡effecNve ¡ Intrusion ¡detecNon ¡ approach for AMI

Sustain Security ¡ Improvements ¡

Offer ¡Testbed and ExperNse as a Service to Industry ¡ AnNcipate/address issues ¡of scale: ¡PKI, ¡ data avalanche, ¡ PMU data compression Act as repository for ¡cyber-­‑security-­‑ related power ¡ system data

| 6

| 7

Agenda ¡

• Background ¡on ¡AMI ¡

– System ¡overview ¡ – Security ¡aspects ¡

• Towards ¡Automated ¡Response ¡

– Taxonomy ¡ – Cost ¡model ¡ – PracOcal ¡deployment ¡

• Future ¡DirecOons ¡

| 8

Acknowledgements ¡

• Core ¡funding ¡as ¡part ¡of ¡TCIPG ¡Center, ¡Office ¡of ¡

Electricity, ¡Department ¡of ¡Energy ¡

• AddiOonal ¡support ¡for ¡Development/Analysis/ ¡

Technology ¡Transfer ¡

– BBN ¡Technology ¡ – ITRON ¡– ¡Testbed ¡provisioning ¡

| 9

Advanced ¡Metering ¡Infrastructure ¡

hhp://www.nuritelecom.com/soluOons/advanced-­‑metering-­‑infrastructure.html ¡

¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Services: ¡

• ­‑

Real-­‑Nme ¡price ¡informaNon ¡

• ­‑

Remote ¡diagnosis ¡and ¡commands ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡Demand-­‑Response ¡

¡ ¡ ¡ ¡ Usage ¡readings ¡

| 10

Demand ¡Response ¡in ¡MISO ¡Markets ¡

~ 3,000 MW Relief from Demand Side Management

90,000 95,000 100,000 105,000 110,000 115,000 120,000 125,000 130,000 135,000 140,000 00:00:00 01:00:00 02:00:00 03:00:00 04:00:00 05:00:00 06:00:00 07:00:00 08:00:00 09:00:00 10:00:00 11:00:00 12:00:00 13:00:00 14:00:00 15:00:00 16:00:00 17:00:00 18:00:00 19:00:00 20:00:00 21:00:00 22:00:00 23:00:00

TIME (EST) Load (MW)

24:00:00

Forecast Footprint Load Actual Footprint Load hhp://www.narucmeeOngs.org/PresentaOons/Doying%20Midwest%20ISO%20Demand%20Response.ppt ¡

| 11

AMI ¡Architecture ¡

WAN ¡

(WiMax, ¡PLC, ¡ ¡ Satellite ¡or ¡GSM) ¡

NAN ¡

(Wireless ¡mesh ¡network ¡or ¡PLC) ¡

UOlity ¡Network ¡ Database ¡

• Collect. ¡Engine ¡

Relay ¡ Relay ¡

Third ¡Party ¡ ¡ Customer ¡

Field ¡Crew ¡ ¡WAN: ¡Wide ¡Area ¡Net., ¡NAN: ¡Neighborhood ¡Area ¡Net. ¡ ¡PLC: ¡Power ¡Line ¡Comm. ¡ Smart ¡Meter ¡

Relay ¡

| 12

Requirements ¡

• Large-­‑scale ¡

– Managing ¡few ¡millions ¡nodes ¡

• Resilient ¡

– Energy ¡delivery ¡mission ¡is ¡criOcal ¡

• Privacy-­‑preserving ¡

– Protect ¡sensiOve ¡customer ¡informaOon ¡

| 13

Constraints ¡

• Long ¡term ¡deployment ¡

– Life ¡cycle ¡of ¡5 ¡to ¡15 ¡years ¡(vs. ¡2-­‑3 ¡years ¡in ¡IT) ¡

• Meters ¡have ¡low-­‑computaOonal ¡power ¡
• Limited ¡network ¡bandwidth ¡
• Limited ¡informaOon ¡about ¡ahacks ¡
• Security ¡soluOons ¡should ¡be: ¡

– Non-­‑intrusive ¡ – Low ¡maintenance ¡

| 14

Cyber ¡Security ¡Threats ¡

• MoOvaOons: ¡

– Energy ¡fraud ¡ – Denial ¡of ¡service ¡

• ExtorOon ¡

– Power ¡DisrupOon ¡

• Targeted ¡remote ¡disconnect ¡
• Large-­‑scale ¡outages ¡and ¡instability ¡

– Stealing ¡personal ¡informaOon ¡ – Abuse ¡of ¡communicaOon ¡infrastructure ¡ – Loss ¡of ¡customer ¡trust ¡and ¡adopOon ¡

| 15

AMI ¡Ahack ¡Surfaces ¡

Corporate ¡Network ¡ Home ¡area ¡ network ¡ Physical ¡tampering ¡with ¡meter ¡ Wireless ¡Mesh ¡Network ¡

| 16

Smart ¡Meter ¡VulnerabiliOes ¡

• CommunicaOon ¡protocol ¡vulnerabiliOes ¡

– RouOng ¡ – ConfiguraOon ¡ – Name ¡service ¡

• Solware ¡and ¡firmware ¡vulnerabiliOes ¡
• Hardware ¡vulnerabiliOes ¡
• Read ¡and ¡write ¡access ¡to ¡data ¡storage ¡
• Access ¡to ¡encrypOon ¡keys ¡
• Weak ¡random ¡generator ¡
• Lack ¡of ¡replay ¡protecOon ¡

Replaced ¡anO-­‑tampering ¡seal ¡ Password ¡stored ¡in ¡clear ¡in ¡EEPROM ¡ ¡

Mul?-­‑vendor ¡Penetra?on ¡Tes?ng ¡in ¡the ¡Advanced ¡Metering ¡Infrastructure ¡(2010), ¡and ¡Energy ¡ TheE ¡in ¡the ¡Advanced ¡Metering ¡Infrastructure ¡(2009) ¡by ¡S. ¡McLaughlin ¡et ¡al. ¡ ¡

Password ¡sent ¡clear ¡over ¡opOcal ¡port ¡ Usage ¡data ¡not ¡integrity ¡protected ¡ Replayed ¡authenOcaOon ¡and ¡spoofed ¡meter ¡ EncrypOon ¡key ¡derived ¡from ¡password ¡

| 17

Smart ¡Meter ¡VulnerabiliOes ¡(cont.) ¡

Local ¡variables ¡promoted ¡to ¡global ¡ Vulnerable ¡to ¡buffer ¡overflow ¡ Very ¡small ¡stack ¡space, ¡no ¡memory ¡protecOon ¡ Vulnerable ¡to ¡Oming ¡ahacks ¡ “r/w” ¡flag ¡olen ¡disabled ¡

Smart ¡meter ¡worm ¡developed ¡and ¡tested ¡by ¡IOAc?ve ¡(BlackHat ¡2009) ¡ ¡ Self-­‑replica?ng ¡and ¡self-­‑propaga?ng ¡code ¡

• CommunicaOon ¡protocol ¡vulnerabiliOes ¡

– RouOng ¡ – ConfiguraOon ¡ – Name ¡service ¡

• Solware ¡and ¡firmware ¡vulnerabiliOes ¡
• Hardware ¡vulnerabiliOes ¡
• Read ¡and ¡write ¡access ¡to ¡data ¡storage ¡
• Access ¡to ¡encrypOon ¡keys ¡
• Weak ¡random ¡generator ¡
• Lack ¡of ¡replay ¡protecOon ¡

| 18

Cyber ¡Security ¡Threats ¡to ¡AMI ¡

WAN ¡

¡

NAN ¡

UOlity ¡Network ¡ Relay ¡ Database ¡

• Collect. ¡Engine ¡

Compromised ¡Meter ¡ (key ¡stolen ¡and ¡ malware ¡injected) ¡

Relay ¡ Relay ¡

Third ¡Party ¡ ¡ Customer ¡

Field ¡Crew ¡

Self-­‑propagaOon ¡ (remote ¡exploit ¡ remote ¡disconnect) ¡ AuthenOcaOon ¡ (meter ¡spoofing) ¡ Massive ¡requests ¡ (denial ¡of ¡service) ¡

¡WAN: ¡Wide ¡Area ¡Net., ¡NAN: ¡Neighborhood ¡Area ¡Net. ¡ ¡PLC: ¡Power ¡Line ¡Comm. ¡ Smart ¡Meter ¡

| 19

MulO-­‑layered ¡Security ¡Approach ¡

• PrevenOon ¡

– AuthenOcaOon ¡ – EncrypOon ¡

• DetecOon ¡

– Meter ¡alarms/logs ¡ – Intrusion ¡detecOon ¡

• Response ¡

– Access ¡control ¡lists ¡ – CredenOals/keys ¡update ¡ – Firmware ¡update ¡ Building ¡a ¡resilient ¡architecture ¡ requires ¡to ¡implement ¡all ¡three ¡

| 20

MulO-­‑layered ¡Security ¡Approach ¡

• PrevenOon ¡

– AuthenOcaOon ¡ – EncrypOon ¡

• DetecOon ¡

– Meter ¡alarms/logs ¡ – Intrusion ¡detecOon ¡

• Response ¡

– Access ¡control ¡lists ¡ – CredenOals/keys ¡update ¡ – Firmware ¡update ¡

| 21

MulO-­‑layered ¡Security ¡Approach ¡

• PrevenOon ¡

– AuthenOcaOon ¡ – EncrypOon ¡

• DetecOon ¡

– Meter ¡alarms/logs ¡ – Intrusion ¡detecOon ¡

• Response ¡

– Access ¡control ¡lists ¡ – CredenOals/keys ¡update ¡ – Firmware ¡update ¡ Cri?cal ¡need ¡for ¡smart ¡ automated ¡response ¡

• Complexity ¡of ¡large-­‑scale ¡

distributed ¡systems ¡

• Efficiency ¡of ¡automated ¡

aQacks ¡

• Reduc?on ¡of ¡response ¡cost ¡

and ¡?me ¡

| 22

Work ¡Plan ¡

• 1. Understand ¡possible ¡response ¡acOons ¡

à ¡IdenOfy ¡a ¡taxonomy ¡of ¡AMI-­‑specific ¡acOons ¡

• 2. Understand ¡safety/cost/benefit ¡tradeoffs ¡of ¡acOons ¡

à ¡Define ¡a ¡cost ¡model ¡

• 3. Test ¡and ¡study ¡pracOcal ¡deployment ¡

à ¡Implement ¡automated ¡responses ¡in ¡TCIPG ¡testbed ¡

| 23

RESPONSE ¡ACTION ¡TAXONOMY ¡

| 24

Response ¡AcOon ¡Taxonomy ¡

• Comprehensive ¡response ¡classificaOon ¡

– Ensures ¡coverage ¡and ¡completeness ¡

• Customized ¡for ¡AMI ¡

– CooperaOve ¡acOons ¡among ¡meters ¡ – Tunable ¡response ¡intensity ¡ – Special ¡AMI ¡recovery ¡acOons ¡

• Understand ¡characterisOcs ¡of ¡acOons ¡

– Important ¡for ¡cost ¡computaOon ¡

| 25

Response ¡AcOons ¡Taxonomy ¡

AcOons ¡ Learning ¡ Passive ¡ AcOve ¡ Modifying ¡ Blocking ¡ Recovery ¡

Generate ¡event ¡logs ¡ ¡ Study ¡adversary ¡ Block ¡intrusion ¡ Restore ¡system ¡ AcOons ¡aim ¡to ¡collect ¡ informaOon ¡about ¡intruders ¡ and ¡idenOfy ¡compromised ¡ meters ¡ AcOons ¡aim ¡to ¡limit ¡or ¡stop ¡ ahackers, ¡and ¡then ¡to ¡ recover ¡by ¡returning ¡to ¡a ¡ safe ¡state. ¡

| 26

Response ¡AcOon ¡Tags ¡

• Response ¡rollback ¡

– Reversible ¡ ¡ – Irreversible ¡with ¡removable ¡effects ¡ ¡ – Irreversible ¡

• OperaOon ¡Layer ¡

– System-­‑wide ¡ – Network ¡Layer ¡ – MAC ¡Layer ¡

| 27

Response ¡AcOon ¡Tags ¡

• Resources ¡Involvement ¡

– MulOple ¡meters ¡ – Single ¡meter ¡ – CooperaOve ¡

• Admin ¡Involvement ¡

– Fully ¡automated ¡ – Requires ¡admin ¡input ¡

• Response ¡flexibility ¡

| 28

(Subset ¡of ¡the) ¡Taxonomy ¡

AcNon ¡ Rollback ¡ Layer ¡ Resources ¡ Admin ¡Involvement ¡

Learning ¡

Passive ¡

Generate ¡reports ¡ ¡ N/A ¡ System ¡ MulOple ¡ Automated ¡ Alarm ¡ N/A ¡ System ¡ Automated ¡ Profile ¡customers’ ¡power ¡usage ¡to ¡detect ¡anomalies ¡ N/A ¡ System ¡ MulOple ¡ Automated ¡

AcOve ¡

Start ¡analysis ¡tools ¡ N/A ¡ Network ¡ MulOple ¡ Automated ¡ Verify ¡ARP ¡table ¡entries ¡(MAC-­‑device ¡mappings) ¡ N/A ¡ Network ¡ MulOple ¡ Automated ¡ Detect ¡duplicates ¡by ¡probing ¡the ¡network ¡ N/A ¡ Network ¡ CooperaOve ¡ Automated ¡ Send ¡probe ¡packets ¡to ¡test ¡routes ¡ N/A ¡ Network ¡ CooperaOve ¡ Automated ¡ Add ¡decoy ¡nodes ¡ R ¡ System ¡ Automated ¡

Modifying ¡

LimiOng ¡

Isolate ¡neighborhood ¡ R ¡ System ¡ MulOple ¡ Semi-­‑automated ¡ Firewall ¡rule ¡at ¡collector ¡ R ¡ Network ¡ Single ¡ Automated ¡ Blocking ¡connecOons ¡ IR ¡ Network ¡ Single ¡ Automated ¡ LimiOng ¡network ¡access ¡ R ¡ Network ¡ Single ¡ Automated ¡ Rate ¡limiOng ¡network ¡traffic ¡ R ¡ Network ¡ Single ¡ Automated ¡ Enabling ¡quaranOne ¡/ ¡jail ¡environment ¡ R ¡ System ¡ MulOple ¡ Automated ¡

Recovery ¡

Merge ¡neighborhood ¡network ¡temporarily ¡ R ¡ System ¡ MulOple ¡ Semi-­‑automated ¡ Distribute ¡ahack ¡signature ¡ IR ¡ System ¡ CooperaOve ¡ Automated ¡ Verify ¡C12.22 ¡rouOng ¡tables ¡ N/A ¡ Network ¡ CooperaOve ¡ Automated ¡ Apply ¡patch ¡ IR ¡ System ¡ MulOple ¡ Semi-­‑automated ¡ Replace ¡meter ¡(physically) ¡ IR ¡ N/A ¡ Single ¡ Semi-­‑automated ¡ Recover ¡meter ¡readings ¡ N/A ¡ N/A ¡ MulOple ¡ Automated ¡ Turn ¡on/off ¡service ¡(recover ¡ahack) ¡ R ¡ N/A ¡ MulOple ¡ Automated ¡

| 29

COST ¡MODELING ¡OF ¡RESPONSE ¡ ACTIONS ¡

| 30

Why ¡does ¡it ¡maher? ¡

Collection ¡Engine Relay

AcOon ¡alternaOves: ¡

• a. Block ¡traffic ¡from ¡relay ¡
• b. Block ¡traffic ¡from ¡meter ¡

The ¡number ¡of ¡affected ¡meters ¡impact ¡ the ¡cost ¡

| 31

Effect ¡of ¡an ¡AcOon ¡

• Three ¡enOOes ¡involved ¡

Affected ¡by ¡service ¡changes ¡

Customer ¡ System ¡ Administrator ¡ Ahacker ¡

Goal ¡is ¡to ¡compute ¡the ¡cost ¡of ¡a ¡response ¡acOon ¡using ¡ system ¡model, ¡taxonomy, ¡acOon ¡tags ¡and ¡ahack ¡tree ¡

| 32

Cost ¡for ¡LegiOmate ¡EnOOes ¡

Cost ¡Parameters ¡ – OperaOon ¡Cost ¡ – Impact ¡on ¡Services ¡(CIA) ¡ – EffecOveness ¡

• Cost ¡of ¡Ahack ¡
• Benefits ¡

– Recovery ¡Ome ¡ – Response ¡deployment ¡period ¡(TTL) ¡ – AcOon ¡parameters ¡(flexible ¡acOons) ¡ – ComputaOon ¡Ome/cost ¡(real-­‑Ome ¡deadlines) ¡

| 33

Current ¡Approaches ¡

Current ¡approaches ¡capture ¡a ¡parOal ¡image ¡

• StaOc ¡costs ¡mapped ¡to ¡acOons ¡

– Systems ¡dynamics ¡alter ¡the ¡effect ¡of ¡an ¡acOon ¡

¡

• Parameterized ¡cost ¡ ¡

– OperaOon ¡cost, ¡damage ¡cost, ¡response ¡goodness ¡and ¡ impact ¡(staOc ¡parameters) ¡ – Ensures ¡beher ¡coverage ¡but ¡does ¡not ¡capture ¡system ¡ dynamics ¡

• Resource ¡dependency ¡model ¡

– Capture ¡dynamics ¡but ¡leads ¡to ¡an ¡incomplete ¡cost ¡value ¡ ¡

| 34

CompuOng ¡Effect ¡on ¡CIA ¡

• System ¡modeled ¡using ¡ ¡

Dependency ¡graph ¡G=(V,E) ¡ – V ¡set ¡of ¡resources ¡ – E ¡set ¡of ¡edges ¡(r, ¡s) ¡ represenOng ¡relaOon ¡

• Resources ¡labeled ¡with ¡ ¡

dysfuncOon ¡rate ¡vector ¡ Vr[C,I,A] ¡ ¡

• Each ¡edge ¡labeled ¡with ¡a ¡

degree ¡matrix ¡

​𝒳↓​𝑠↓𝑗 ​𝑠↓𝑘 =(█□​𝓍↓​𝑠↓𝑗 ​𝑠↓𝑘 (1,1) &​𝓍↓​𝑠↓𝑗 ​𝑠↓𝑘 (1,2) &​𝓍↓​𝑠↓𝑗 ​𝑠↓𝑘 (1,3

| 35

Comprehensive ¡Cost ¡Approach ¡

Dependency ¡Model ¡ Current ¡ State ¡ Impact ¡

• n ¡CIA ¡

$ ¡

Cost ¡on ¡ Impact ¡ OperaOon ¡ Cost ¡ Labor ¡ Cost ¡ Recovery ¡ Cost ¡ Response ¡ Cost ¡

| 36

Cost ¡EffecOveness ¡

Taxonomy ¡characterizes ¡two ¡high ¡level ¡type ¡ – Learning: ¡leaves ¡ahack ¡running ¡ – Modifying: ¡acOvity ¡tackles ¡ahack ¡ ¡ Impact ¡of ¡ahack ¡on ¡system ¡ – Model ¡ahacker ¡(Möbius ¡ADVISE ¡model) ¡

• ObjecOvely ¡simulates ¡mulOple ¡adversary ¡models ¡

– ProbabilisOc ¡ahack ¡costs ¡

• Tag ¡ahack ¡trees ¡with ¡costs ¡

– Historic ¡data ¡

• Not ¡enough ¡for ¡complete ¡cost ¡model ¡

| 37

ConverOng ¡Impact ¡for ¡AMI ¡Services ¡

UOlity ¡ Meter ¡ R e a l ¡ O m e ¡ p r i c i n g ¡ S e r v i c e ¡ C

• m

m a n d s ¡ U s a g e ¡ R e a d i n g s ¡

Block ¡meter ¡

• Stops ¡all ¡services ¡between ¡user ¡and ¡uOlity ¡
• Temporarily ¡interrupOon ¡as ¡routes ¡are ¡generated ¡

Verify ¡route ¡integrity ¡

• Delays ¡“service ¡packets” ¡due ¡to ¡extra ¡traffic ¡

| 38

Ahack/Response ¡AcOon ¡Cost ¡Breakdown ¡

ConfidenNality ¡ Integrity ¡ Availability ¡ Real-­‑Nme ¡pricing ¡ Service ¡ Commands ¡ Usage ¡Readings ¡ Electricity ¡Market ¡ SLA ¡ SLA ¡ Electricity ¡Market ¡ SLA/SaOsfacOon ¡ No ¡cost ¡

For ¡each ¡element ¡in ¡the ¡grid ¡the ¡cost ¡is ¡computed ¡ for ¡both ¡the ¡administrator ¡and ¡customer ¡

| 39

Availability ¡for ¡Pricing ¡InformaOon ¡

• Customer ¡uses ¡flat ¡rate ¡in ¡

case ¡of ¡unavailable ¡ pricing ¡informaOon ¡

• 𝐺𝑚𝑏𝑢 ¡𝑠𝑏𝑢𝑓<𝑁𝑏𝑠𝑙𝑓𝑢 ¡𝑠𝑏𝑢𝑓 ¡

– UOlity ¡loses ¡revenue ¡ ¡

• 𝐺𝑚𝑏𝑢 ¡𝑠𝑏𝑢𝑓>𝑁𝑏𝑠𝑙𝑓𝑢 ¡𝑠𝑏𝑢𝑓 ¡

– Customer ¡overcharged ¡

𝐷𝑝𝑡𝑢=∆(𝑞𝑠𝑗𝑑𝑓)×𝑉𝑡𝑏𝑕𝑓 ¡

0 ¡ 0.5 ¡ 1 ¡ 1.5 ¡ 2 ¡ 2.5 ¡ 3 ¡ 3.5 ¡ 4 ¡ 4.5 ¡ 5 ¡ 12:00 ¡AM ¡ 2:00 ¡AM ¡ 4:00 ¡AM ¡ 6:00 ¡AM ¡ 8:00 ¡AM ¡ 10:00 ¡AM ¡ 12:00 ¡PM ¡ 2:00 ¡PM ¡ 4:00 ¡PM ¡ 6:00 ¡PM ¡ 8:00 ¡PM ¡ 10:00 ¡PM ¡ Cents/KWh ¡ Flat ¡rate ¡

| 40

Integrity ¡of ¡Pricing ¡InformaOon ¡

• AcOon ¡increases ¡rate ¡

– Customer ¡dissaOsfacOon ¡

• AcOon ¡lowers ¡rate ¡

– Customer ¡over ¡billed ¡(legal ¡acOon) ¡ – Increase ¡demand ¡for ¡power ¡

• Rate ¡increase ¡
• GeneraOon ¡perturbaOons ¡

| 41

Impact ¡on ¡Meter ¡Readings ¡

• Availability ¡

– SLA ¡penalty ¡ – Delay ¡in ¡EMS ¡usage ¡profiles ¡

• Integrity ¡

– Energy ¡thel ¡or ¡overbilling ¡customer ¡ – Misleading ¡usage ¡profiles ¡

| 42

Impact ¡on ¡Service ¡Commands ¡

• Availability ¡

– SLA ¡penalty ¡ – Customer ¡dissaOsfacOon ¡due ¡to ¡delays ¡in ¡uOlity ¡services ¡ (turning ¡on ¡power, ¡blackouts ¡detecOon,…) ¡

• Integrity ¡

– Extra ¡labor ¡and ¡operaOon ¡costs ¡due ¡to ¡false ¡posiOves ¡ ¡ – Cost ¡increase ¡for ¡the ¡customer ¡

| 43

Cost ¡of ¡ConfidenOality ¡

• Compromised ¡confidenOality ¡

– Leads ¡to ¡invasion ¡to ¡privacy ¡through ¡load ¡profiling ¡

• Legal ¡acOon ¡and ¡lost ¡confidence ¡
• Current ¡surveyed ¡SLAs ¡do ¡not ¡contain ¡provisions ¡for ¡

confidenOality ¡

| 44

Provisions ¡for ¡Service ¡Level ¡Agreements ¡

• Availability ¡

Guarantee ¡that ¡usage ¡data, ¡commands ¡and ¡pricing ¡arrive ¡in ¡ a ¡?mely ¡manner ¡within ¡regular ¡load ¡ ¡

• Integrity ¡

Guarantee ¡that ¡X% ¡of ¡usage ¡data, ¡commands ¡and ¡pricing ¡ are ¡not ¡tampered ¡ ¡

• ConfidenOality ¡

Guarantee ¡that ¡X% ¡of ¡usage ¡data ¡privacy ¡is ¡not ¡ compromised ¡

| 45

Cost ¡for ¡Ahacker ¡

• Stop ¡ahack ¡

– Block ¡compromised ¡enOOes ¡

• Slow ¡down ¡ahack ¡

– Rate ¡limiOng ¡of ¡compromised ¡enOOes ¡

• Facilitate ¡ahack ¡

– Misdiagnosis ¡or ¡misconfigured ¡response ¡ – Collect ¡informaOon ¡on ¡the ¡ahacker ¡and ¡the ¡strategies ¡ used ¡

| 46

IMPLEMENTATION ¡& ¡DEPLOYMENT ¡

| 47

Framework ¡

¡

• Intrusion ¡response ¡systems ¡can ¡be ¡based ¡on: ¡

– HeurisOcs ¡ – Machine ¡learning ¡ – Game ¡theory ¡

| 48

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

• Assumes ¡security ¡game ¡between ¡ahacker ¡and ¡defender ¡
• Uses ¡an ¡Ahack-­‑Response ¡tree ¡to ¡model ¡system ¡
• Computes ¡the ¡opOmal ¡response ¡strategy ¡that ¡minimizes ¡the ¡

cost ¡for ¡an ¡administrator ¡

• 𝑠(𝑡,𝑏,​𝑡↑′ )=​(​𝜀↓𝑕 (𝑡)−​𝜀↓𝑕 (​𝑡↑′ ))↑​𝜐↓1 𝐷​(𝑏)↑​𝜐↓2 ¡

– C(a) ¡is ¡the ¡cost ¡funcOon ¡introduced ¡by ¡our ¡cost ¡model ¡

| 49

RF ¡Lan ¡ Hardware ¡Meters ¡ IDS ¡Management ¡Console ¡

AMI ¡Testbed ¡Architecture ¡

Virtual ¡Machines ¡ Virtual ¡Meters ¡ CollecOon ¡Engine ¡ ITRON ¡

IDS ¡sensor ¡ Trilliant ¡Table ¡TstBench ¡ ¡ (solware ¡meter) ¡

Data ¡Management ¡ System ¡(Oracle ¡DB) ¡

Cell ¡Relay ¡ meter ¡ meter ¡ meter ¡ meter ¡ Trilliant ¡Table ¡TstBench ¡ ¡ (solware ¡meter) ¡ Ethernet ¡ Ethernet ¡

| 50

Testbed ¡

| 51

Testbed ¡

| 52

FUTURE ¡WORK ¡AND ¡RESEARCH ¡ QUESTIONS ¡

| 53

Future ¡Work ¡

• Automate ¡the ¡assignment ¡of ¡weights ¡in ¡dependency ¡model ¡

using ¡minimum ¡administrator ¡input ¡

• Automate ¡the ¡generaOon ¡of ¡relaOons ¡between ¡CIA ¡
• Complete ¡case ¡study ¡by ¡defining ¡models ¡for ¡the ¡different ¡

security ¡implicaOons ¡

• Design ¡a ¡“security ¡inspired” ¡metering ¡SLA ¡
• Complete ¡implementaOon ¡in ¡RRE ¡framework ¡
• IniOate ¡tesOng ¡within ¡testbed ¡using ¡realisOc ¡AMI ¡
• OpOmize ¡performance ¡

| 54

Safety ¡

• Ahackers ¡can ¡drive ¡automated ¡responses ¡by ¡triggering ¡IDS ¡

sensors ¡

• A ¡separate ¡unit ¡to ¡include ¡the ¡admin ¡to ¡the ¡loop ¡in ¡the ¡case ¡

for ¡some ¡specified ¡acOons ¡

• AcOons ¡with ¡safety ¡issues ¡should ¡be ¡semi-­‑automated ¡

– Provide ¡a ¡choice ¡for ¡the ¡admin ¡with ¡alternaOves ¡

• Define ¡a ¡safety ¡criterion ¡for ¡AMI ¡

| 55

Research ¡QuesOons ¡

• Design ¡modular ¡response ¡acOons ¡and ¡cost ¡model ¡

– Ensures ¡compaObility ¡with ¡different ¡technologies ¡and ¡ implementaOons ¡

• Automate ¡generaOon ¡of ¡response ¡acOons ¡
• Propose ¡Performance ¡metrics ¡for ¡automated ¡responses ¡

| 56

Conclusion ¡

• Formed ¡a ¡response ¡acOon ¡taxonomy ¡with ¡learning ¡and ¡

modifying ¡categories ¡

• Current ¡cost ¡models ¡rely ¡on ¡subjecOve ¡administrator ¡

parameters ¡or ¡staOc ¡values ¡

• Defined ¡response ¡cost ¡model ¡to ¡include ¡parameters ¡from ¡

the ¡taxonomy ¡

• Map ¡response ¡parameters ¡to ¡monetary ¡values ¡using ¡SLAs ¡

and ¡other ¡cost ¡factors ¡

• Plan ¡to ¡implement ¡automated ¡response ¡for ¡AMI ¡testbed ¡

| 57

QuesOons? ¡

Robin ¡Berthier ¡ ¡rgb@illinois.edu ¡ ¡ Ahmed ¡Fawaz ¡ ¡afawaz2@illinois.edu ¡ ¡ William ¡H. ¡Sanders ¡ ¡whs@illinois.edu ¡ ¡