Roark Pollock: Hi, I'm Roark Pollock. And this is the first season of the Secure Tracks podcast, where we host rail industry leaders to talk about operational rail technologies in cybersecurity. In this episode, we're hosting our first guest from a rail integrator, and we'll be talking about embedding cybersecurity into greenfield rolling stock builds. So let's talk about rail tech systems on rolling stock with someone who helps build today's digital trains, Bruno Corasolla. Bruno is the current global head of digital trains are Hitachi rails innovations, vehicle steam, and has been at Hitachi rail for over six years. Prior to Hitachi rail, Bruno spent 13 years at Embraer as an aeronautical systems development engineer. So Bruno, welcome to the show. And thank you for joining us today.

‍

Bruno Corasolla: Hi, Roark. Thank you for having me. It's good to be here.

‍

Roark: Absolutely. Well, Bruno, one of the things I like to do is kind of explore with people, how they got into cybersecurity. And I know you've had some changes throughout your career. So to start, I know you've got an electrical engineering degree and a master's degree in aeronautics, how did you go from aeronautical systems development to building trains in the train industry first of all.

‍

Bruno: It is it was a bit like a personal change, I had to move contents move countries and then I had to find a find a new job, and I found that another railway industry is very much on like to the to the aerospace industry template. Aero product development is very much especially rolling stock is very much like aircraft, like the skills and process that you need to use are very similar. The end with just a lot of mechatronic systems that rely on human operation carried passengers up and down. So it's even in terms of regulations and so on. Rail was picking up and getting closer and closer to aviation today. So it's a very similar type of industry. 

‍

Roark: That makes sense. I never really thought about it that way. But that does make a lot of sense. So there's a good fit there. And, then, as far as you know, how you got into the cybersecurity side of the business, because most of us, like myself, most people I know. We didn't start in cybersecurity but we've somehow found our way into the industry. What was the path that led you into the cyber?

‍

Bruno: It's a funny story that, as you know, my background is in product development. So my life was all around safety, operational requirements, availability, etc. And then someday, the Senior Director of Hitachi came around the firm with a printed copy of further the IEC 62443 standard thing, we need people to understand that, and I took a took that, that like this, the size of ages, and read them through the to the weekend. And next Monday, like another coffee chat. I told him I understood the process behind all of that and so on. And before I knew what it was, I became responsible for cybersecurity, like, oh, you understood the process. Very good. Now, that's yours. 

‍

Roark: Got it. That's awesome. I only know a few people who have probably read the IEC 62443 standards cover. All right, well, that's good. And I know as part of that, you've ended up moving from England to Brazil. That's mean from Brazil to England, and that's a big move—certainly worse weather. I would think. 

‍

Bruno: Absolutely. It wasn't because of the weather. Yeah, yeah. It was personal. My now wife she was already living here in the UK, and then when we decided to move together, we had to choose either Brazil or UK.

‍

Roark:  That's always a good reason. Keep the wife happy, yeah. All right. Let's jump into our first topic today and talk about, from your perspective, the drivers for cybersecurity and rolling stock. Design and build projects. I know, we don't have to go back very far, not too many years, to find the time when cyber wasn't even a consideration in the design of rolling stock systems. And, probably not even too far back beyond that, were there when we didn't even have very many digital systems on rolling stock designs, or they weren't a consideration? So what is the biggest driver and getting cybersecurity tools built into rolling stock designs? Is it just the concern that the threat landscape, is it the new industry standards that are coming out in different parts of the world, is it just the fact that the operator orders it and it's part of the requirements that drives the rail integrators to start building in cyber into those rolling stock builds?

‍

Bruno: Is a bit of everything that was said, it's like, not long ago, the like cybersecurity was assumed to be like purely an insurance activity, something that we'll do at the end of the younger design, you just assured is a secure tick. And soon, as the requirements were rising, our customers, their operators, their asset owners, and also a small group with inside companies found that we will be able to be exposed to the risks of the developer product without considering cyber security. That means that need to be embedded in the design. So there's a bit of everything. So generally, the requirements that we receive, from our customers, from operators or from passive owners and to today are generally more generic in terms of cybersecurity, more focused on business on the business, cybersecurity, on the IT side of cybersecurity, business risks related to cybersecurity more on the ISO 27,000 world of when requirements, but this is this is changing. So, not much comes out as formal requirements for the product itself. But we found that deriving from the business risks, the way we design our product, we need to embed that function from the beginning.

‍

Roark: Got it. What are the most common tools that you see coming to you, at least as far as the requirements that you're seeing from the asset owners? Or the operators today? That does it vary by geography? It's similar across the globe. What do you see?

‍

Bruno: It is not similar around the globe and in its customer to the customer because he depends on it depends on the level of knowledge the customer or the customer has cybersecurity and also the infrastructure they have ready to operate our products and still be compliant to the regional cybersecurity legislation. We see like places like the UK US where the legislation is a bit more developed, the recontact coming stronger from customers while all the other areas are catching up. And we will see some if not requirements, at least some more discussions around the cybersecurity related to the products saying that the kind of solution the kind of tool that most as of today. The internal monitor and threat monitoring, intrusion monitoring is the is probably the tools that are requested more directly from these customers than those not it's not the only one but it's the one that we would get more direct requirements from customers.

‍

Roark: Of course. Got it. And are you seeing any emerging kind of requirements coming from them? Or do they typically look to you as the rail integrator and designer to kind of make suggestions from a cyber standpoint?

‍

Bruno: Absolutely some of these customers don't have developed the cybersecurity infrastructure to manage their cybersecurity operation. So they rely on our review on how the which each threat and which parts of the product needs to be better want to or need to generate some information for them to consider in their operation. So, so the, it really,depends on the on the customer and how developed they are on the on their cybersecurity process.

‍

Roark: Anything that you're starting to see just now emerge as new requirements or things that people are starting to ask for. Or, as it pretty much started to stabilize a little bit.

Bruno: It's starting to stabilize more than we used to see the same requirements coming over and over tender after tender. Now for the more recent, more recent tenders and contracts, we're seeing more, if not the detailed more product oriented requirements coming over. So the operator nasty owners understand how to fix the products as part of their of their process, right, and how to how they would would use these these products in their operation. So this is becoming probably a bit simpler to to process that in order to derive requirements or problems.

‍

Roark: Got it? Got it. Okay, that makes sense. So I know one of the things that's kind of driving the industry or at least, spurring the industry a bit is, is the new regulatory requirements, things like, I know, we have the new TSA directives security directives in the US that were published last year, how do the rail integrators think about these new requirements. Do they typically kind of proactively tried to start incorporating what's coming, what's being asked for and those requirements, or is it a trickle-down effect where it starts with the operators and then it feeds into their requirements and becomes part of what you then have to design to?

‍

Bruno: Formally, we wouldn't we would wait for the, for the operator, but they say this is not how it should work. Like the TSA set directives, here in the UK we have for a while the NIST directive leads us to in UK and in Europe. Now with Europe passing very close to pass the Cyber Resilience act, that will start the start the providing requirements for for mostly for the Brayton asset owners, and in theory, distribute the good flow downwards will cascade to the to integrater. But we we need to be ahead of requirements at that generally, the lifecycle development cycle of a product, it can't, it doesn't support something completely new being introduced within the product or the product cycle. So we need to be a bit ahead of the requirements and finding what was more likely that the customers will require. But also the and also supporting we said some many times we need to support them in understanding what is their role and our role. We think there's a whole a whole security environment. So yeah, we will definitely need to start implementing introducing now something that will be used in five, six years time from now. 

‍

Roark: Yeah, makes sense. So you're kind of you kind of maybe answered this question, but it's something that I was curious about. And and with some of these regulatory requirements is, and you don't have to answer this if you don't want to or have an opinion on it. But what are your thoughts on the government regulations that I've seen mostly applied to the operators and asset owners? And it's almost curious why those regulations don't also apply to the rail integrators or the builders. So I'm curious on your thoughts, you know, should the regulatory requirements also enforce those same cybersecurity standards on the integrators from a builder standpoint, and from a rail operator standpoint? So that you're addressing both sides of the equation from my perspective

‍

Bruno: There’s a form of more formal and business kind of response like they're positive and negative on this like positive. The if these requirements were set out for the for the integrators would be better for in a way that clear requirements will be established from  the regulation standpoint, these will remove some risk on our onproduct development. So we will know which requirements to comply to and let the integration know how this will work to the to the, to the to the operator. But, there's there will be also a negative point on this, that the very likely the overall product costs will probably be higher, because we will be addressing a generic requirement that not always would fit on every operation, every customer said every customer would have a different a different way to manage their cybersecurity risks, and not like there's no one size fits all for solutions for solutions here.

‍

Roark: True. Good point. Yeah, I know

‍

Bruno: In my very personal opinion. It shouldn't be rolled out to the to the integrators that each should each integrate to should be aware of these regulations and find the best balance on the relationship with the customers like setting the band to the customers they are trying to reach, prepare the products to be to fit into the cybersecurity environment.

‍

Roark: Got it? Yeah, that does make sense, I hadn't thought about the fact that those standards don't actually apply to every single operator in those in those regions.

‍

Bruno: And even way the they deliver the way they are comply to those requirements may be slightly different depending on the size, you think like an upgrade with multiple fleets, from different suppliers that operate in different parts of controlling even in different countries, they would have a different operational environment, then local operator that has probably one only one fleet for one supplier, and operate in a very a much more limited threat environment, and they need to be very only to one country, or one country set of regulations.

‍

Roark: Yeah, and I'm sure if I think about it, if I were a rail operator, if I was CISO for a rail operator, I probably prefer to have the flexibility to design the requirements for an RFP from you the way I want it implemented, not necessarily the way you implement chosen implemented. So makes good sense. All right, so enough about kind of the driver. Let's talk a little bit about embedding cybersecurity now into your rolling stock design and hold the whole design and build process. You know, it's if I take a step back and then make an analogy to the cyber or to the safety world, it's not been too long ago, safety wasn't embedded as part of the rolling stock does that well, maybe it's been a century? I don't know, it's been longer than cyber, certainly. But safety is now embedded throughout the whole process. Right? It's it's a part of the design and engineering process. And maybe if you think and think about safety as an analogy, where do you think we are from a cybersecurity standpoint at getting cyber embedded into the engineering process? We're rolling stock, just like we have now with the maturity of the safety, safety in our in our design and engineering process?

‍

Bruno: Yeah, where we are is like is in clear development, like in many, many areas from from the regulations and standards side, as you see we have new regulations coming over every every quarter every six months. And similarly, standards to try to comply to regulations or to bring the industry to the to the same level. Currently, we have  international regulations for cybersecurity are being discussedת being created, at this very moment, something that doesn't exist. But the embedding the cybersecurity in the product, product development cycle, in the same way as safety is what we see being the way ahead. We are not there yet. Also, most of these integrators, they don't have either the knowledge or they are not they couldn't get to the to the league and have the opportunity to get cyber security as part of a product, product development cycle that is quite long for Rails. So like we were talking about five, six years development cycle many times, you don't have don't reach the don't reach the product limit, and then the sweet spot when can bet to the best influence into the design.

‍

Roark: Yeah. Okay. And maybe just tell us a little bit, you know, how you're seeing the cybersecurity teams involved in that design and build process? Where do they get involved? Are they involved throughout?

‍

Bruno: Yeah, ideally, ideally, the as I said, the same thing, this cycle, so long, the sooner they're listed there, the cybersecurity teams getting forward, the better for different reasons. Like the understanding the product you're developing, to reach to which kind of operation to each to each execute, but also operational requirements, even a subsequent team to put the first to start assessing the product and the risks, the risks that the product will be, will be exposed to, and also placing said, influencing the design in a direction to make the compliance later, much simpler to achieve. So if you embed many times, if you embed a security function, in the early days of the product, the product development, the impact on the actual product in terms of cost complexity is not that much compared to doing that later. Yeah, you take one, one function, for instance, as an example; the user authentication is something that if you embed user authentication, in the core design of your product from the beginning, that's perfectly fine. So the the the additional cost is possible, various more, why would you prefer doing that? Well, later in the design is the cost and even even though it's many times not even capable of embedding, or including that .

‍

Roark: It's not an easy overlay, it's, it's got to be included from the beginning. Right. Okay. And, and I know, you know, we talked about embedding it in, from your perspective, but certainly, rail integrators rely on suppliers for a lot of what they do from a cyber standpoint. And so, I'm interested in the relationship between the integrators and the security vendors or the security community, how the integrators engage with the security vendor community, and vice versa. And your thoughts on, you know, are your expectations of the security vendor community and perhaps, are there some things that are not happening today that you'd like to see better work in that in those relationships?

‍

Bruno: Yeah, the ideal world from the from the integrator perspective, the our design should be vendor agnostic. So, the earlier we open for the market, these today it it requires data integrator to engage to as many vendors as possible to understand the viability of solutions there they exist or their coverage, the talking from data diodes to regional detection systems to integrating user authentication as I mentioned, this is the this is what the how the integrators are facing this, this problem today, probably our point of improvement for the vendors, and that would facilitate the facilitator that relationship with facilitate this, this interface is the as the standards for for for cybersecurity, not only for rail, but in general for for for control systems. Is up are getting more established, is maybe to describe and link their solutions to the to security functions that are described in these standards. I'm saying, for instance, the IEC 62443 - that's the standard for the majority of the control systems. If we if we could see if we could understand the solutions the vendors are offering in terms of these are these are the IEC 62443-2-3 functions, dash 4 extreme functions or the to dash for functions that are covered by the product that we're offering. This would facilitate interface with integrator, so that wouldn't require the integrator to be to have. So deeper knowledge in the cybersecurity in the in that relationship. So this will make the integrator life much easier.

‍

Roark: Okay, good. Good point. All right. You know, we're talking about cyber here as if it were kind of like a piece of hardware, or even a software solution built into kind of rolling stock environments. But that's just a piece of the picture for me from a cyber standpoint, I'm sure you're the same way, I think cyber is more of a process at the end of the day. And so for a lot of operators, that means there's a big part of cyber that's either internal processes for their teams, or they outsource it as a security service. Perhaps they're building new SOC, for their control, or for their operational rail tech environments. And so we're getting to the point where a lot of our security capabilities are pretty sophisticated, especially on rolling stock systems now. So as you think about the services part of it, or the, you know, what it takes to manage these tools? Do you envision the rail integrators getting into operating some of these security capabilities as a potential new source of revenue? And perhaps even a recurring revenue stream? for it? Is that going to be something that's left up to kind of the traditional systems integrators?

Bruno: It's easy, the possibility compact in the same way that array integrations they be times they have maintenance contracts for with for the for the fleets that provide similar way, similar way? Yeah, yeah. That will be an extension is not it's not something that we are there yet. I don't know. Any other integration may have. But he did is it's a possibility, because at the end of the day it’s being able to offer a service offer managing cybersecurity risks based on the tools and information that is available for no specific product. So yeah, the rail industry today is used to is a very good in managing safety risks. It's a process that is like, embedded in the railway industry in general, especially the operators, but not as much for managing cyber risks. So the this this, this will be a possible business. Yeah, that will be something that we're also supporting our customers on, find the best areas to invest in the in security, rather than simply requesting everything from every part of the chain. Right, and integrity and everything. So that's how it was done today, even in maintenance.

‍

Roark: Exactly. Well, that's what made me that's what, you know, maybe that brought the topic up, because I know a lot of the integrators are maintainers as well, especially in rolling, especially on the rolling stock side. So that's kind of where it came up. And I can certainly see it being a kind of reasonable next step for some of them. So, okay. Makes sense. All right. So one question I wonder about is, did the operators get very specific about specific tool sets and specific designs even, maybe so far is going to ask for specific vendors as part of their rolling stock requirements for new builds? Or is that something that you ever see from them? Or is it really something that's left up to you as the integrator to figure out what parts fit best together to service their requirements?

‍

Bruno: Yes, so far, we haven't seen any specific requirements for cybersecurity vendors or specific solutions. But similar to what happened in other areas. So for instance, when integrating digital digital platforms that we end up for some customers, getting requirements for specific vendors, is when the customer has a level where they want to integrate that fleet or that product into an existence Cybersecurity infrastructure. Even if they already have a sock there, or they have other fleets with a service, like even solution ready, implemented, they have built their process around that solution. That when I see that a possibility to get receiving specific requirements about vendors, but as of today, we never obviously never saw any any specific requirements for cyber security, as I said, it's something that may make me happy in the future.

‍

Roark: I was going to ask for specific vendors as part of their rolling stock requirements for new builds? Or is that something that you ever see from them? Or is it really something that's left up to you as the integrator to figure out what parts fit enough together to service their requirements?

‍

Bruno: Yeah, so far, we haven't seen any any specific requirements for for for cybersecurity vendors or specific solutions. But similar to what happened in other areas, for instance, when we're integrating digital platforms that we end up for some customers, getting requirements for specific vendors, is when when the customer has a level where they want to integrate that fleet to that product into an existent cybersecurity infrastructure. Even if they already have a SOC there or they have other fleets with a service, but even solution ready, implemented, they have built their process around that solution. That when I see that possibility to get receiving specific requirements or about vendors, but as of today, we never I never saw any any specific requirements for cybersecurity, as I said, it's something that may make me happy in the future.

‍

Roark: Got it? Makes sense. For one last question. We're talking about what's driving the industry? What's, how do we get where are we, as far as embedding cybersecurity and rolling stock and the build of rolling stock? Where do you see things going over the next kind of three to five years? Do you have any thoughts on the threat landscape? And where you think that might evolve, but especially on cybersecurity, in rolling stock design and builds? Where do you think things are going? 

‍

Bruno. In the next three, five years, that's, that's when we will see probably the first products that were designed with a cybersecurity from the as a concern from the early days. So the we see more products with integrated from integrated identity authentication, user User Access Control, down to two intrusion detection and the and the amount of information being provided to security operational offices. This is where I see like a more integrated approach to cybersecurity with more information, more tools from the from product, the products are getting to operation need to be integrated into into a higher level. So cybersecurity environment, these will very likely require a lot of adjustments on the operational procedures, maintenance procedures, and there'll be a deep impact on how how would operate to operate operated, wrong rolling stock build. 

‍

Roark: Yeah, that's a good point. And you're basically saying those are just coming online because it takes three to five years just to develop these projects.

‍

Bruno: So yeah, it's, it's we're just getting some of the first fleets out there that have it designed from scratch. Absolutely, yeah, absolutely. And you get more and more integrated will require the changes in the in how you how the the the operators deal with these fleets. 

‍

Roark: Right. Any thoughts on how new projects starting in the next three to five years may change? Well, how the embedding of cybersecurity are the tools that we're using or the technologies that we're using?

‍

Bruno: Yeah, an example in how a future fleet may look like that the set we said we're talking about the user authentication and identity management. So, anyone getting to train to do any kind of operation being actually operating the trains being ready the driver a crew on retainer, they will need to they will need to handle to manage the team or the train will need to manage the their of their identity, their level of authorization, what kind of what kind of function they will be exposed and available for that, for that entity. And all these these will have a chain effect on all the infrastructure and processes that you need to have in place. To do a simple a simple task as a simple as getting to the train, identifying yourself as a driver, for instance. And in operating the train, something that today the driver takes a key, a physical key, that's the that's the user authentication. But their physical, their physical key that the driver is authorized to operate the train similar similar to maintenance, similar to operational staff. So the that's, that's how I see things will change. So the change of the change on the product itself will need to be extended to all the systems that are all the the the system, the process around operating that, that kind of product. So the this will be the biggest impact that I see. It's not far, it's probably in three, five years, as I said, we're likely to start seeing fleets that will require that this level for this level is level for changing operational procedures.

‍

Roark: I can see I can certainly see that. We see it in all kinds of other industries. And it world for sure. Absolutely never gets access to the data center. And these are rolling data centers after all.

‍

Bruno: Exactly. 

‍

Roark: Well, that makes that makes good sense. I appreciate that view of the future from you. So Bruno, let's wrap things up a little bit. You know, as somebody that builds all these digital trains, both the digital side, the cyber side, if you think about yourself as a CISO or if we have CISOs from rail operators that may be listening, what kind of advice or what bit of advice would you summarize, to give some of the CISOs out there that might be listening.

‍

Bruno: It’s a very clear advice getting involved in the in the requirements elicitation for when when your company's tendering product is creating the requirements for a new product, get the requirements there to fit into your ASMSs because this will help everyone this will help them because then they will need to fit this new product in manage that new product in terms of controlling the risks of having that product as part of their operational, the operational landscape. So it's a get involved early and get the get your ideas and your requirements into the in the in the tendering that tender requirements. 

‍

Roark: Yeah, well, I'm sure all the CISOs for rail operators out there if they're not already involved. David, love that bit of advice, because I'm sure there is, I would say in Texas “chomping at the bit” to get involved or get more involved. Yeah. So all right. I really appreciate that. Well, Bruno, if somebody would want to contact you. You know, are there any social media platforms that you're active on that would work or what's the best way to get in contact with you?

‍

Bruno: LinkedIn. So that's probably the best way to contact me. 

‍

Roark: Okay, and your name is there. There are no other people with our names. I don't think it's good and bad. so profound. Thank you very much. Thank you very much for joining us today. I really appreciate it. And thank you for listening. That's the end of our show today. And so until next time, keep those tracks secure. Bye. Bye. Thank you. Bye bye.

‍