BG - Security Testing for Smart Metering Infrastructure - Robert Hawk & Steve Vandenberg

ready yeah great hey um my name is Steve Vandenberg I am the team lead for security uh for BC Hydro smart meter infrastructure program uh this is Bob haulk my teammate um we've got a full scope uh 1.8 million uh meter deployment in uh British Columbia Canada uh so many of you are probably better pentest ERS than I am you can make uh perhaps ness's sing and dance uh some of you may be able to go barehanded on the code and find uh zero days and I very much admire those skills myself I've put together uh Security Programs for large organizations including uh security testing and uh I've got some uh learnings and observations that I'd like

to share with you and hope that you'll be uh finding useful so uh here goes so first the disclaimer uh this presentation is not about anybody that uh myself or Bob has worked for first a big shout out uh to my homies at bsides Vancouver uh we've got a great infoset Community up there and a beautiful city so if you have the opportunity please come up and check it out it's happening uh March 15 uh 2015 so first some example Ami hacks uh Ami Advanced metering infrastructure has gotten to be a very crowded space for security research uh these are by no means uh the only um recent hacks out there uh there are you know four that uh

I have some some interest in so I've wanted to share with you just from the point of view of showing you that it's a crowded space it's a space that's getting a lot of interest both from the good guys you know the infoset community doing some good research and the bad guys so this is what we need to think about when we're looking at developing testing programs uh looking into the eye of the meter uh don Weber did this uh at Defcon in 2012 uh this is a hack that's got to do with interfacing with the optical Port the optical Port on a meter is a maintenance port and if you talk to it right you can

get the meter to do a bunch of unexpected stuff Puerto Rico utility uh found this out or one like it uh when they experienced an optical Port hack which was an inside job to lower electric rates for people that could pay the corrupt insiders uh this was uh investigated and you know Case Closed uh by the FBI it was reported uh by cruds on security those two have to do with the optical maintenance Port as well we've got an RF Hack That was um that was given at uh the uh chaos Communications Congress in 2011 uh what they did was they looked at the Privacy implications of um of the RF emanations from from the

meter uh the meters uh got rfm minations in a couple of uh uh ways uh both the um uh radio frequency uh uh and mesh that goes back to the utility also the home area network looking at uh the radio frequency aminations they were able to look at not only when people were home uh but you know what kind of appliances were running uh perhaps even what people were watching on television a lot of The Angst out there over Ami deployments is going to be over uh privacy issues people have got a lot of concerns over you know what can I do with the data uh in a smart meter if a smart meter is

co-opted versus you know a flywheel meter which was uh you know an all style flywheel meter which really had nothing that could be could be used uh by by a bad guy uh this was a really nice uh presentation we are so screwed yeah I think that really was the title actually uh because I was unable to discern any other this was given by uh Larry peshi at Defcon 21 and this was a combined physical and cyber assault on a connected grid router the connected grid router is a device it's a field area router sits on a pole and when those meters are all talking to each other forming their mesh the last guy the 2000s and first

meter takes um takes that signal the com the combination of all of those signals uh and hands it off to the connected grid router which goes ahead and sends it back you know to the to the to the headend at the utility and that along with every other part of the uh system is open potentially to exploitation my system isn't open to any of these exploitations you know if it was I wouldn't be standing here I'd be on a plane back to Vancouver uh to either get fired or you know fix all my stuff uh because we we do a really good job of fixing but again we've got to let you know the past be our guide there's

research going on now uh and you know both both bad research and and good research that we need to protect our system from so with that let me hand it off to uh Bob and uh I'll be back thank you Steve all right I want to talk about uh Ami projects and programs and then I want to contrast Ami projects and programs with standard it I think a lot of people uh here will understand and appreciate standard IT projects uh over Ami now Ami projects tend to be very large they're state or provin size they're also very expensive and complex networks very resource intensive as well lots of people working on this for the deployment and the integration to the

utility there's complex and emerging Technologies some times absolutely brand new tech for example IPv6 been around for quite a long time however it's starting to be used on mass in Ami networks as well there's some older technologies that are being used in new and interesting ways some scatter technologies that didn't exist in the IT world are starting to be imported into the IT world or over it networks Ami projects tend to be multi-year deployments they're not spanning just a few months or a few weeks they tend to go on for years and years and years the very first smart grid project that came out in Italy or the Ami project that came out in Italy

was 5 years long and I believe it cost a billion euros multiple vendors are required to make Ami projects a reality for utility by the time utility gets into an Ami space they're no longer just the utility they're a conglomeration of Telos and service providers for a lot of different applications and communication networks now let's take a look at that that contrast IT projects tend to be three to five years for the software Hardware sometimes on a three-year schedule uh you know you swap out servers uh Windows 2003 to 2008 that's 5year life cycle tend to be 1 to three quarters to implement for an application into a larger infrastructure you can have tens of servers

hundreds of network devices and you could be rolling out to thousands of uh end user devices such as smartphones tablets and laptops now let's take a look at the Ami space in the Ami space we have equipment that is going to last 50 plus years out there some of the traditional five-wheel meters that are on the side of businesses and houses have been there for 50 to 7 years now replacing them with smart CPU enabled devices and these devices still have to be out there for quite a long time 2 to 5e deployment for most of the projects that I've looked at hundreds of servers in the backend data centers to collect this information thousands of network devices

out in the field and even in the data center and millions of end noes sometimes you talk to it professionals and they're like okay I've the largest Network I've worked on has had 100,000 workstations well imagine a a Network that has into them millions of end noes that need to be administrated and and managed let's talk about the security test scope the security test scope of what needs to be tested for an Ami space deployment we'll start off with the meter the meter can be installed on the side of a house or a business and it can have multiple ways of communicating back to the utility it can either be Wireless or it can be through a PLC

Powerline connection the meter will also have multiple radio interfaces if it's uh if it's a radio enabled meter one of the radio interfaces is a zigg network the zigby network will allow the meter technician to associate with the meter from a distance not too far off a distance but from for example roadside to the to the meter that's on the side of the the house or the business the zigby network is also utilized for the home area network or sometimes referred to as a business area network or the band when it's being utilized for businesses this is the Network that is actually used for the smart appliances air conditioning units that have CPUs refrigerators that have CPUs that can

actually get onto this network and are enabled for things like time of use and rate of of service the meter itself will operate with the rest of the meters in its cell in a hierarchical network that is set up in a radio mesh so all these meters will talk to each other they don't necessarily understand each other's communication but they will forward messages forward forward forward in through the layers until they finally get to their field area router so this is much like how a cellular network works for a telephone system in the case a meter cannot talk to other meters and or to the field area router there are RF land extenders that allow the signal to

be captured and transmitted forward the field area routers as Steve was indicating a few minutes ago are the final aggregation point before the signals are aggregated and sent off to the data center at the utility where the bills are generated and the data is analyzed in the case of smart metering equipment we're talking millions of meters generating equip the equ the equipment and the the software generating millions of of um lines of of information this is essentially Big Data okay this is all going back to the data center and there is a lot of information while we're testing all the hardware and all the software there's something that needs to be kept on eye on and that is the software releases

versions and patches that are coming out over time can essentially make a testing plan obsolete or a test obsolete before the actual deployment is even over so test plant test plant should have a a common set of criterias and goals the principles of these common criteria and goals have to be able to bring the utility the vendors and the service providers together to agree upon the language and a variety of other things so that those goals can be established the best way to do this we found the best way to do this was a standards based approach AMC and nist IR 7628 the nist inter agency report 7628 for cyber security of uh smart grid and

and smart metering networks was a great way to go these standards were developed utilizing a risk assessment methodology the risk assessment methodology was based on controls for devices as well as the interfaces in between the devices something that's really important to keep your eyes on if you're looking at this space is that by the time you put this equipment together it becomes ecological it actually is almost like a living being there's so many pieces to it that you can't say okay I've tested all the pieces and it's all good we need to actually test the interrelations and the functions between the pieces as well now what's really important is that when you're taking a look at testing the various individual

components that in itself doesn't really matter as much as how they're being utilized and it's really important that the standards that are being adopted be use cased for the business the utility that is actually implementing these various Technologies of course there's a note at the bottom prepared to change the test plans based on the priorities of the test cycles and what you find out things will change over a long period of time now this one's common sensical develop a test plan beforehand yeah you got to you got to decide what you're going to do before you actually do it but a lot of people a lot of security testers we love to get our hands right

onto the equipment and and just dig right in create use case documents to shape your test plans the use cases of actors the actual resources and how they interrelate is really necessary do security assessments this is not when you actually start looking at security tools such as nessus or Cod Nomicon a security assessment we take a look at the use case we take a look at storyboards we take a look at architecture we take a look at um things like the manufacturers documentation the documentation that's that's created internally within the utility put all of that together to get a conceptual idea of how this thing is supposed to work and create test plans based on that tie

the test plan strategies back to the Open Standards why because you have validity and it'll be good for things like audit later on consider all the threat vectors we have cyber physical social and yesterday year we used to call these physical administrative and Technical but you know sometimes times change let's take a look at some of these threats physical threats threats well I can put a rare earth magnet right on the meter that'll actually kind of mess with its uh ability to measure the power I can take the 5-year-old approach and take a hammer to the meter okay I can go into the cyber attacks RF denial of service the meters in a lot of cases will operate on

known frequencies uh this is forward- facing on the internet what their frequency ranges are and that can be uh jammed possibly the optical Port attacks that Steve was talking about there is an optical Port to interface with a meter if the if the actual radio stage dies on it and believe it or not anybody can buy the optical plug up gear it's available online zigg or dmp3 attacks these are protocols that have been around for a while but they're being used in new and interesting ways and in actuality they some of them are available to Big attacks as was discovered with dmp3 last year there is a lot of different attack vectors for that protocol social attacks somebody can

call a do somebody can call a call center and actually talk the call center representative into giving up information on a service point a combination attack let's go to a big box store buy ourselves a a home area network device and call the call center and see if we can get some social engineering in place to get that associated with a specific service point so we can find out what's going on at that service Point what types of smart appliances are there and what their usage is but why do we want to do this stuff well the goals are at the bottom there possibly turn off the power mess with the billing increase it lower it

depending on what we want to do know when people are home what they're doing now for the rest of this I'm gonna turn it back to Steve Steve hey thank you Bob so now we're ready to go ahead and get our test plan rolling we've got to ensure a production like environment sounds really simple and it is really simp simple if you're testing a router or a meter and what you need to do is just get the right version with the right software and move it to your lab but that's not what we're doing here we are going to be testing a system that's got maybe 1.8 million endpoints The Meters thousands of field area routers

hundreds of servers so what we need is we need an environment that can stand as a proxy for that because we probably can't build that back at the lab we're spending a lot of money on these results so we've got to be sure that they're valid we need not only production like equipment in other words the same versions that are going into the field but we need production like configuration now we need this for a couple of reasons we're not testing this for a hobby and we're not going for bug bounties here what we're doing is we're protecting the critical infrastructure that keeps the lights on and and in order to do that I need the results that

I get to be actioned okay I need the results that I get to be able to hand off to a vendor and have them fix the equipment before it goes out in the field I need results that I can give to my implementation team to tweak configurations before it goes out into the field perhaps and I'm not going to be able to do that unless I can get all those parties on side in other words I've got to get them to believe me that this result is a valid result and the only way that I can do that is if I've got a really good production like environment so that I can know the issues that I

find are issues that we're going to have in the field so I already said we're not going to get 1.8 million real meters and x000 field area routers moved in into my lab so what I've got to do is I've got to document any differences between the production and the test environment and I've got to discuss these with the vendor and the implementation team beforehand so we all agree how the differences are going to impact results we've got to agree that the results that I'm going to get are going to be valid because I'm going to expect action on their part and I'm going to expect action um with a defined process that's is going to be able to you know fix this

stuff in time more than that we're going to need to build the test environment troubleshoot it and maintain it now let's talk about that who's going to build a test environment oh yeah well the the lab will build it well wait a minute we're looking at a system which while it may be built from standard Parts those parts are going to be configured in a way in my Ami deployment that's probably never been done before now who's going to know how to do that the test lab yeah well you know maybe if they've done a lot of Ami work but they're probably not going to be able to get the environment exactly right who's going to be able to get the environment

to be exactly like from a security point of view the production environment well the same people building the production environment so I've got to have a really good liaison with my vendor and with my implementation team my other team leads because I'm going to be reaching out to them to build up this environment or advise my team while we're building it up troubleshoot it because just like we're going to have problems in the field that need you know good Engineers good programmers Etc to go ahead and solve we're going to have those same problems in the produ in in the in the non-production in in the test environment and we're going to have to maintain it so we've got to know what a

false positive is I got to know the differ the difference between a problem and a security problem okay that's where the troubleshooting comes in and like Bob was saying I'm looking for an environment with multiple vendors products that's got to live and remain useful for maybe two to five years so it's going to need maintenance it's going to need upgrade to keep it like the production environment big projects like Ami don't get completely designed then completely tested then rolled out it's not like a cell phone Ami my team may be one step ahead of deployment now the good news is you know as the security lead I'm going to have the ability you know I've been

given the ability by my management who understands this issue to pull the plug oh that's a power joke no if I need to but I don't want to do that I mean I'm I've I've got to be in a situation where I have um the ability to help deployment while maintaining the security that I that I that I need so getting that test environment getting the good technical advice is going to be very important to do that in a timely fashion so before starting okay before I get you know the tools out I've got to get the results of the security testing carried out by the manufacturer or others this is going to help me to eliminate redundant and

expensive testing and shape my test plans for the it pen test think of this like a part of the Recon phase think of it as a Recon phase with lots of lawyers okay because there's a lot of equities at stake here no even if I'm a huge customer of a meter vendor or a network equipment vendor they're not just going to FedEx me over the results of all the pen testing that they've done even if I've got a second eyes deal with another utility they're not going to share this stuff freely this is about good relationships it's about good non-disclosure agreements and it's about measured sharing for Mutual benefit with with your partners this is going to enable me to shape the

test plans make sure that my testers are shooting with a rifle not a shotgun because the ammo can run into the millions of dollars it's going to allow us to pick up where other testing left off and it's going to allow us to further explore their findings we're going to talk about this when we get to you know where do we go from here when we've got to end the program these these other um utilities other manufa facturers other service providers they wanted to test the whole world but they couldn't everybody's got limited time and limited money so what they want to do is and what I want to do is I want to make sure that I pick up

where they left off and I you know go ahead and I and I and I run everything that I can down to ground and then you know perhaps in a measured way be able to share it again with the manufacturer and with the partners so that we can all benefit security testing is going to need a big support structure if I'm looking at testing Ami deployments again we're not looking at testing a thing I'm not even looking at testing you know a collection of things a network I'm looking at testing you know a network that goes over potentially hundreds of square miles with millions of devices and in Ami the real benefit to the customer okay

the user of our electricity doesn't happen just when we get the billing information back to the meter Ami doesn't deliver on its business case merely by not having meter readers we do a lot of stuff with the information that we get to help operate our system better to help uh people save energy and that means that there's a big attack surface and there's a lot of stuff for us to test so we need sub substantial support from the manufacturer I should say manufacturers because even if you're looking at the largest Ami equipment vendors manufacturers they don't make the whole system they'll be the meter they'll be all the uh back hul they'll be the routers and then there'll be the

applications that we use to do stuff with the information once we get it back to the back to the utility so this is a Loosely coupled system and I've got to test the whole thing and a lot of what I'm going to be looking for is in the interfaces so I'm going to need support for test environment construction and maintenance in a timely manner because getting my test environment up and right once the stuff is out the door not so good better to get it done while I can still fix my stuff before it leaves I'm going to need uh defect triage vetting of false positives this deployment may be your first Ami deployment the manufacturer may know

more about the equipment especially his equipment than you do they're going to be able to help you vet false positives you're going to get a result you may not know exactly what to do with it what you need is to be able to look at at that result with someone who understands exactly how things should work maybe on how things had issues and other testing to help you get out the false positives get good evidence know that they're false positives set them to the side and then run the real defects to ground you're going to need their their um help for defect resolution again I'm not looking to you know put this program together to write a paper about I'm

looking to get this program together to help my Province be safer so I've got to get these issues fixed and maybe they're going to be fixed in the manufacturer's Factory maybe they're going to be fixed in my um you know implementation uh teams uh area there's a lot of people that may need to be involved to resolve the defects and I've got to get them on board and make them part of this got to get information for white box testing what I'm talking about here with white box testing is not setting up my red team with you know admin accounts and passwords what I'm talking about here principally is information now there's always the white

box versus blackbox debate I come down on the side of white box for AMI deployment why is that because the same equipment is used many places in the world and like Bob was saying over very long uh life cycles sooner or later a lot of this information is going to get out I'm not talking about the proprietary information about my system what I'm talking about here is there will be information getting out about meters and uh routers of various manufacturers and when it does bad guys are going to be able to use that against me the least I can do in my opinion and G is give my team every advantage to find the results that are going to help

me deploy safely so what I want to do is put all the information that I can about the equipment in their hands so that they can help me out they can use their time wisely and all of this needs to be formed in a common understanding with the manufacturers and test lab beforehand we're looking at potentially a long project here people are going to be moving on and off the project toward the end of the project money may be getting low time may be getting short and that's the time that I'd better have all this made part of the contract so there's a common understanding as to who does what in this testing program and who's got the

various responsibilities that we've that we've talked about so again get this part get this to be part of the contract upfront so handling the results we do a full scope test plan we've let the genie out of the bottle if this information leaks so it it better not but as always confidentiality versus availability I could have 300 to 500 people working on an Ami deployment they don't all need to know the security test results but some of them do or at least some portion of it if they're going to help because I've got to get the defects resolved I may have to tweak my schedule for deployment and in order to do that there's going to be you know more than

more than just my team that's got to be in on some of these results so I've got to look at how the information is going to be handled how I'm going to let the genie out of the bottle but not too much and certainly not in a way that's going to be dangerous to any of my stakeholders document Control Systems yeah I'm going to use encryption I'm going to use password management and document repositories but don't wrap encryption around this thing put it on a USB stick and lock it up in a safe because it's not going to be useful to anybody and it's going to be less useful as time goes on so I better make sure that the

result that I got day one one of my testing is available to examine a fix in year four so I need to make sure that I've got my stuff together with regards to a true document control system not merely making information unavailable remember if we're looking at a Loosely coupled system with a utility various vendors various service providers they will have a variety of infrastructures to keep this information safe so perhaps you're living in a house which is to say it infrastructure that was not designed to handle SE uh sensitive pent test results they may not they may never have envisioned that you'd be doing this kind of testing so they may not have what you

expect regards document control systems do you trust can you trust the document control systems and the practices of service providers that you need to bring Under the Tent in order to fix the gear okay think about that beforehand get this agreed beforehand how are you going to disseminate this and how are you going to keep it under control most of all know that you are responsible for the information and what the information leakage could could damage okay and I mean that not only legally Because by the way you will be responsible for it legally but morally you could be using Ami gear that's the same as is going to be used in France or in China

by people who have never heard of your team and your project but who will suffer if you don't do your job right because when your information leaks they may not be thinking about about doing bad stuff in Vancouver they may be thinking about doing bad stuff in LA and I don't want to give the bad guy a weapon to attack somebody who well I don't want to give them a a weapon to attack anybody uh but I want to make sure that my stuff gets gets deployed properly but do think about your responsibilities here so using the results rather like a dog chasing ing a car the dog better figure out what to do with the car once

he catches it so you've got a whole bunch of results now from your security testing well a lot of people say great you know um fix it again not as simple as an iPhone what's going to be the criteria for halting deployment you've got 3 to 500 people working toward a schedule that may have been mandated by the regulator you're on a burn rate of huge amounts of money here halting deployment may be necessary and my management would would support me in this but I've got to have some criteria that are going to be agreed upon it can't be that you know I hit the red button and everything stops how are defects going to be

mitigated okay maybe we can wrap security round stuff maybe we can armor it before it goes out maybe I can put some armor on there that's going to be you know rock solid until I can do the fix that I want so I've got to look at you know a variety of options here I've got to uh look at what conditions if any are going to be applicable for deployment maybe I could change the use case okay maybe this device that was to be used by my technician to maintain the meters or deploy them maybe it can't be used over the Internet maybe that's just a nogo no matter how much armor wrap around the thing but

maybe I could use it on my corporate Network that's got better security again I'm just saying you need to be open to a variety of solutions you know not just hey I'm the security Guy and um you know my answer is no so let's think about setting an achievable goal okay when we start out we've got to think about what done looks like okay I'm a security guy I would love to test forever I would love to keep you know my team large forever because I believe that that's the way that I serve the people of in my case the province but you know the reality is everything's got to have a beginning a middle and an end you know especially

projects deployment projects for Ami every test finding is going to point to the need for more testing so what I've got to do here is I've got to figure out beforehand how am I going to deal with that okay when have I achieved the risk levels that I need so that I can feel safe about my system okay where am I going to stop what I'm talking about here is not cheaping out I'm not talking about about stopping because you know you've only got a certain amount of money although you know money is necessary and you need money to test what I'm talking about here is when is it the right time to stop I flew down

here on a Boeing 737 I think Boeing's a great company and I hope they did a lot of testing to make sure that I'd get down here in one piece but ultimately they had to put the 737 into production or you know I'd be riding down here on a horse right my Ami system is not going to benefit anybody if I never get it deployed so I've got to look with a really sober eye at you know what my testing looks like when do I stop what are the other parts of my security program that kind of you know pick up where testing leaves off so that I can deploy the right way and not rely

you know on on an infinite um you know large scale test plan so we've got to figure out how to handle transition to to production the project is winding down but I would say if testing is important during the project phase why is testing any less important during the production phase as Bob said we've got systems which could have 50 or more years of life many new versions of applications many great devices have yet to be added to the Ami system part of the advantage of Ami is that I'm open to you know adding new devices to the network that's what I want with an Ami system but I've got to make sure that I

do it safely what if some defects survive the project how are you going to manage them to closure you could say well you know I'm going to do another test cycle to make sure it's closed well may be a little easier said than done you may not have that full scope test environment available anymore you may not have your whole team available anymore think about what evidence you would use to cause those defects what evidence would be acceptable to you what kind of assertions maybe a test by somebody else that you trust with you know evidence screenshots and you know assertions from from their you know management and so forth that you know these are our actual

tests maybe you need to review their test environment all of this is possible but think about it beforehand and get those get those get those agreements in in place because ultimately remember we need to deploy the system safely and I'm only going to be able to do that if I can close those defects with real evidence okay Victory is not achieved by having you know X defects that never get closed Victory is achieved by having zero def defects and X closed you know in a really proper and auditable way is your third- party test program going to continue do you have the resources for that and I mean not only money but but the people you know the

market is very tight for these kind of people right so are they all going to sit around while you you know are in the maybe less active production stage you could move the uh program inhouse that's a really good idea especially if you've got a lot of good experience during the project phase however that is a I mean that is a different skill set make sure that you've that you've got that you know resourced up make sure that's a business that you want to be in the test environment has to continue to be production likee and if it was located offsite you've got to decide where the test environment is is going to live so again

all the questions that you answered when you were going into the project phase have got to be answered for the for the transition to production stage because what you don't want to do is you don't want to drop the ball you don't want to put huge res sources into a uh test program and then stop the test program have the production system keep going and not be able to to pick up and you know Harvest all that value and keep your rate payer safe so with that I thank you very much for your attention and uh I welcome your questions

please sure so the uh the question was how serious uh would it have to be for us to halt deployment so first uh I'm I'm not going to tie this to any particular uh of of my employers I can say in the abstract that in order to Halt the appointment there would have to be no other way to mitigate change the use case and so forth I can tell you knowing the Ami space and knowing that the equipment was something or the the equipment would be something that was vetted by myself and my team you know from day one before the sourcing that I cannot imagine a situation where we would halt deployment in other words decide to put the

flywheel meters back I can think of situations where we would change the configuration change the use case and you know otherwise make sure sure that that we're not deploying bad bad stuff I mean the consequences of deploying bad stuff are dire and I I don't only mean because somebody's going to get get the the the ability you talked about the red button most modern Ami deployments have remote disconnect and reconnect okay bad guy can turn off the power if we don't do our job right so the consequences are dire we also live you know somewhat in a in a fishbowl environment I mean we could have multiple Regulators uh we've got you know certainly an infoset community

that is keeping a real good eye on us we really don't want to deploy bad stuff not only for you know moral reasons but if I deploy bad stuff someone will know they'll probably know soon and my chickens will come home to roost please

en en

sure Bob do you want to take this one sure all right so uh the as I understand the question it's to do with uh traditional skada stacks and how fragile they are well I'm G to I'm going to add on to the to the nature of your question if I may and say that a lot of times Ami infrastructures are eventually going to tie into smart grid infrastructures and generation transmission distribution and the customer domains are all going to be connected from end to end right at that point in time it's really important to understand that what's happening in the Ami space is actually going to tie in to the to the substation and transmission

assets and we're going to run into protocols that have been in Scatter networks for for Thousand Years now right in that in that case a lot of times I was mentioning protocols old protocols being used in new ways right or in New under new circumstances you're going to find the necessity for hardening and armoring systems bringing that that information over from it type systems and and relying on layers of encryption relying on on hardening of things that that hadn't been hardened before right and that's just prudent it activity I hope that answers your

question jur

so I think last year you everyone saw a a a lot of outing of dnp3 okay that was that was all over the place a lot of conventions there was a lot of people that stood up and basically said yeah look there's a problem in D MP3 and this is what it looks like right so to that end you're starting to see a lot of reactivity from manufacturers fixing those problems or addressing them and that evolution is now kicking up because the marriage of it and OT coming together all right any other

questions okay thank you very much