Cloud Native Pharma

**NOTE: Generated via ML. Expect crazy stuff to be translated that may have never actually been said by the host or guest :-) ***

EPISODE 11

[INTRODUCTION]

[00:00:15] ANNOUNCER: This is the Cloud Security Today Podcast, where leaders learn how to get cloud security done. And now your host, Matt Chiodi.

[INTERVIEW]

[00:00:29] MC: Mike, thanks for joining us on the program today.

[00:00:32] MT: Thanks for having me. Good to be here.

[00:00:34] MC: Well, it wasn't that long ago that you and I actually spoke. And so, I'm glad that you agreed to come on, so we can just maybe get another level of detail around cloud and get your thoughts on cloud security. But maybe before we do that, I'd love to have you just tell us a little bit about yourself, your company, and then your role at Takeda?

[00:00:54] MT: Sure. So yeah, Mike towers. I'm the Chief Information Security Officer here at Takeda. I've been here at Takeda a little over three years, I've been the top security executive from an information security and cybersecurity perspective now for four different global pharmaceutical companies. And so, been doing this for a while. Each one of those roles, even though all of them were in life sciences, I would say the maturity and the starting point, if you will of the function was different. And the companies were obviously different in terms of their focus and maturity and culture. So, Takeda, specifically, where I am now and have been for, as I said, a little over three years, is the second oldest biopharmaceutical company in the world. It was founded roughly the same month that the US Constitution was written. So, it's about 240 years old.

[00:01:51] MC: I did not know that.

[00:01:52] MT: And it's built up a while over acquisitions like a lot of other pharmaceutical companies have been but Takeda, which is still officially a Japanese company, was very, very Japan centric, up until the acquisition of Shire, about two and a half years ago where it became much more prominent, I would say, in the US business.

There's plenty of biopharmaceutical companies that are non-US, Roche, Novartis, GSK, et cetera. None of them are American companies, but the vast majority of their business is done in the US because it's just the largest pharmaceutical and life science market. So now, Takeda is similar in that regard. So, we're still a Japanese company. We're still headquartered in Tokyo. But the US is our largest market and we operate in about five different therapeutic areas is our focus.

One of the things that's the toughest in the biopharmaceutical industry is focus, because it's really easy to get tempted to try to solve a lot of different problems. But we're focused in areas like oncology, rare disease, gastrointestinal, as well as neuroscience. So, my role as CISO, just basically at the top security executive accountable for all the information security, information protection, cybersecurity risks. I also have a compliance data privacy responsibility for the company as well. And here at Takeda, like many other companies, we have a large and pretty robust enterprise risk management program where the company's top business risks are continually reviewed, and discussed and monitored. And this risk area, broadly speaking, what we call information protection, cybersecurity, is one of the top risks at the enterprise layer as well.

So, that basically means that I have a responsibility to report regularly on how we're doing to the CEO level, the board level, et cetera. Because it's obviously a pretty prominent risk that most companies are wrestling with, and we're no different.

[00:03:57] MC: So, I was looking at your LinkedIn profile. And if I have this right, it looks like you've spent the majority of your career in healthcare. But what I found most interesting was that back in 2008, it looks like you pivoted from IT to security when you were at GSK. I don't know if that's accurate or not. But maybe if it is accurate, talk with me a little bit about, maybe your motivation from that transition. So, I know there's a lot of people that are on the IT side of the house who want to make that transition over to security. What was your motivation for that? And maybe just talk about how you prepared yourself for that role?

[00:04:34] MT: Yeah, interesting story and transition there, Matt. So yes, I was at GSK. I had been at the parent and legacy companies of GSK for quite some time. Again, like other large corporations, there was various legacy companies that merged, acquired, divestiture, et cetera. So, I was in different parts of the legacy organizations but I was always in a technology role, everything from Unix systems programming, to relational databases, to some of the early stages of ecommerce. I actually did a stint in unified collaboration for a while. I had a really interesting job called Emerging Technologies, where we looked at a lot of new stuff that was coming down the pike and whether or not it would make sense for us to adopt at the corporate level, some pretty heavy hitters of the past like BlackBerry came through that process.

[00:05:32] MC: Sure. I remember that.

[00:05:33] MT: So, I was, and interestingly enough, the biggest focus that I had in the 2005, 2008 timeline was I was in the third-party conductivity, and third-party partnerships space. That was back when a lot of the big companies started doing some more large-scale outsourcing. We started to recognize and realize that a lot of the business processes that we historically did soup to nuts on our own. We were partnering with outsource partners, whether it was because it was commodity or whether it was because there was better expertise. So, there's a lot of outsourcing and a lot of partnerships. And at the same time, we were also very acquisitive. And when you're acquiring a company, especially at really tiny company, for most of the lifecycle that acquisition until you fully integrate them, they might as well be a third party as well.

So, I was given an opportunity to run a function that basically was, I would say, half technology and half business about what does it mean to truly be partner centric, which was a really exciting opportunity to look at things more from the business side. And then the CEO approached me and basically said that they were going to create a senior security leadership position, and asked me if I was interested. So, it's not something I applied for, something that I asked for, I was viewed as a potential fit for it because of this role in, I would say, the business partnering side.

Even though there wasn't a security executive position or senior security position, there was pockets of security going on. There were antivirus people, there was the firewall people, most of whom were buried within IT. And at the time, frankly, I was a pretty challenging partner of them because of my role in the third-party space. I was working with him quite a bit. I remember the conversation because my reaction was, A, I'm flattered, but B, why me? Because I didn't have a lot of security expertise. And back then most of the folks that were working in security, or at least security leadership, were I mean, it's unfair, obviously, to generalize, but broadly speaking, a lot of security leaders at the time were either ex-military or ex law enforcement. I was neither. 

So, I think my reaction was, why me? And the discussion that I had was basically around, this has become almost passé now, and kind of cliché-ish. But back then anybody who was looking or smelling like they were doing security, they were very obstructive. Some people will call like the group of no, very good at stopping things. Because the least risk option was basically to do nothing. I was actually asked to lead the function, because I think I established reputation doing a lot of that third-party stuff where when you're signing up to do a clinical trials partnership, or an acquisition or even a large-scale outsourcing.

I mean, heck, at the time, we were outsourcing our email to a Microsoft product that eventually became Office 365. So, we were doing some pretty progressive outsourcing things. It's not the type of area that you could really say no to. It has to be, how can we do this safely? So, a lot of, I would say, risk reward negotiation, et cetera. A lot of, I think what prepared me for the role. And I think, frankly, why I was chosen to lead the role was that I was already doing some of this and I think, doing pretty well, in this risk reward type of discussions, which I think at the end of the day, a good security leader is about making informed risk decisions. So. that was really where it started.

I leveraged obviously, my technology background, you know, obviously, because information security, which I think we all believe now is a business problem. But let's face it, it's also very tech centric, because that's generally speaking out, controls are enforced. Back then I was really excited about it. And I would say since then, one of the things that I've learned and I've grown to appreciate about it is any of us that work in IT, depending on what you do in IT, I think broadly speaking, one of the things that is a continual tension point is how close you truly are to the business. If you're in a data center role, if you're in a helpdesk role, if you're a network administrator, Unix administrator, those are the types of roles frankly, to get done in any company. I think sometimes we all want to find some personal motivation by having what we do day to day contribute to the overall company.

One of the things that I can honestly say that I learned pretty quickly, when I became the head of security was of all the technology roles that I had, this was by far the closest I felt to the business. Because every part of the business is constantly making security decisions, whether they know it or not. And they're constantly making risk decisions. So, to me, that was an exciting opportunity to do that. I frankly, don't see myself doing anything else, because I think it's become something that I've really gotten comfortable with, and I think I've excelled at, and I think it's a constantly challenging and evolving space.

[00:10:35] MC: Having come from the IT side of the house, I would assume that, you could potentially have what I would call an outsider view of security, like you said. You weren't in law enforcement, you didn't have that military background, I didn't hear you say that you came from network security or even compliance and audit. So, I guess my question is, how has that changed your approach to security now as a CISO, versus perhaps someone who has only done security, their entire career?

[00:11:05] MT: Well, I think the biggest mindset, I would say, principle that doing that, in my past has brought me into this role is, and I think security as a whole is starting to evolve this way. But I think frankly, I probably had a little bit of a leg up on it was, I don't think and didn't think, and yes or no terms or trade off terms, it was about enabling the business. So, what do we need to do to enable the business and I think recognizing and realizing and having the discussions around risks that you're willing to accept, and risks that you want, and you’d feel comfort with more controls. I think that type of thought process, if you will, was something that being in IT for a while, which you're constantly challenged with enabling the business, making sure they have applications that work, making sure they have networks that are fast enough to work, making sure that you have the appropriate conductivity amongst data sources, all of those things that you need to do to enable the business. That's the part of the the environment that I came from.

So, solving problems and building up capability is something that I was wired to do rather than frankly, what happened a lot of times with security is that you figure out ways to justify, “Well, this is probably not a good idea to do, let's do something else.” So, to me, it was always around a negotiation to do what is intended to do what is needed, but doing it as safely as possible. I think that was something that I was wired to do pretty early and I think it was something that made me fit right in.

[00:12:40] MC: I think it was probably a couple of weeks ago now. You and I, we spoke about a piece that you wrote in Navigating the Digital Age, it was called 'The Path to a Successful Cloud Transformation'. Talk with us a little bit about where Takeda is today with your cloud transformation. And then maybe, what the next 12 to 24 months looks like.

[00:13:02] MT: Yeah, so specific to Takeda, having gone through that integration with Shire, the company that we acquired, Shire. Even though Takeda was the acquirer, Shire was only a little bit smaller than Takeda. So, we basically doubled the size of the company. And to Takeda, also, I mentioned the age of the company, but it's historically been a very conservative company, and it's also been historically a very decentralized company. I've often said that, and I've teased leaders that were here before me that I think Takeda insulted the word integration with past acquisitions, because it was just basically a loosely coupled connection of businesses that were really tightly interwoven.

So, it was a very, a lot of variability. And then here comes Shire, which, again, doubled the size of the company. So those problems, and that the issues of variability and the issues with decentralization basically came to a head where the collective foundation of technology that we had, was nowhere near capable of meeting the business requirements moving forward of being a top 10 global pharmaceutical company. So, there was a scale issue at a scale expectation. But also, we recognize that we needed to start to think about how to be more quicker, how to pivot more quickly, how to launch and change things more rapidly, because of the expectations and at the time, what was a growing recognition that technology underpinned everything that we wanted to do.

We had this aspiration with a pretty fractured foundation, and we made the call, and frankly, the recognition that the only way that we could meet the business needs moving forward but also quickly rationalize and solve some of the past under investments and past decisions to not integrate the company's very well, that the cloud was the best way to do that. At the time, we had highly variable legacy systems, highly variable legacy processes. And the cloud gave us a point to unify that, as well as build the right foundation for an aspiration to connect more directly with physicians, patients and other parts of a more holistic digital ecosystem that the cloud became almost a requirement to do that. That was something that even if we had a complete fresh starting point, we probably wouldn't have been able to – we definitely wouldn't have been able to build up that capability using traditional premise systems.

So, for that reason, the cloud was something that we committed to about two years ago. And then we started a more aggressive approach to not only adopt the cloud as our technology foundation, but also rewire our company to be more cloud native from an innovation perspective. So, understanding the benefits the cloud gives you in terms of speed and flexibility and elasticity, that's something that across the board, the company wasn't really ready to execute on yet. The cloud, not only became a replacement for data centers, but also a way for us to host this new type of technology that we were going to be pivoting for.

So, we made a pretty robust and direct decision to get out of the data center business completely, move as much of our workload to the cloud as we can, recognizing that we will move everything there, but we would, as we would like to. And then also recognizing that we will still have and do still have cloud native systems that we don't directly host on our own cloud instance. The workdays, the service now is the O 365s the world. So, we have plenty of those solutions in place as well.

The legacy applications that we standardized on and we chose to run the new combined company on, we made a commitment to move all those to the cloud as quickly as possible. And we're about halfway through that migration. We also made that point two years ago that everything from that point forward would be cloud native. So, we've built up capabilities like for DevSecOps, and digital innovation and more digitally native application security. So, in terms of our, I would say, cloud migration, we're about halfway through. And we expect to be done with that in probably another 12 to 15 months.

So, in 12 to 15 months, we will basically be fully cloud native, with the exception of what I would call, on premise physical equipment proximity requirements to stay on premise, which is predominantly mostly acute in the manufacturing space, and the research and development space, where you have this massive equipment that you have on premise that requires local computers to run it, and therefore requires on premise computing. But other than that, we’ll be exclusively cloud, within probably, I would say 15 months from now.

[00:17:59] MC: So, if I think if I do the math correctly in my head, that's pretty rapid. That's what, just over three years, is that right? It'll take you guys, three to three and a half years?

[00:18:07] MT: Yeah, the integration helped us trigger this quickly. Because like any other integration, you get simple called integration funding, restructuring, funding or whatever. But you negotiate a level of investment that's needed to integrate the two companies together more appropriately. By leveraging that as kind of like some seed money if you will, start this process. It probably took us about a year to get our house in order in terms of building up the appropriate integration foundation. And then this cloud transformation was built in the back end of that. So, I think in reality, it ends up being probably closer to four years. But it's a three to four-year timeline.

[SPONSOR MESSAGE]

[00:18:46] MC: Prisma Cloud secures infrastructure, applications, data, and entitlements across the world's largest clouds, all from a single unified solution. With a combination of cloud service provider API's, and a unified agent framework, users gain unmatched visibility and protection. And for our federal customers, Prisma Cloud is now FedRAMP moderate. To find out more, go to prismacloud.io.

[INTERVIEW CONTINUED]

[00:19:12] MC: Now, when we were talking a few weeks back, if I recall what you said correctly, you said something to the effect that you didn't think it was possible to provide good security without going to the cloud. And so, I love that statement, because that's not – I don't hear that a lot when I talk to the guests, when I talk to different CISOs. So, maybe you can unpack that a little bit for us. What did you mean by that? Maybe there's more context to it as well.

[00:19:37] MT: Well, a couple things. I would say first and foremost, we're in the biopharmaceutical business, and in order for us to attract and retain the skills internally to manage and run the infrastructure, to support a $33 billion company across 110 countries, just to build that capability internally would require a level of skills, that there's no way that we can do that, as well as the people that are in this business. The Microsofts, the AWS, the Googles of the world, whatever cloud partner you choose to partner with. And many of us partner with all three, if not other ones that may not be included in those three.

But they're all in that business. They excel in that business. So, why wouldn't – inherently, I'm less secure, because let's keep in mind, security is also about availability, it's not just about protection. So, there's no way that I could staff up the ability to do that, as well as a cloud partner can.

Secondly, the international expansion, and the international requirements that continue to evolve and grow from a security perspective and a privacy perspective, and an encryption perspective, one could argue this is less about pure security, more about privacy, but one of the privacy regulation, key tenants is to adequately protect the data. And things like encryption, for example, where, again, in a company that this is not our core competency to build that and do it at a level of speed that the business would be able to function under, just couldn't happen, unless that we're talking massive budgets and massive staffing that would no longer or dev never be feasible for a company like ours.

And then thirdly, I would say is the speed requirements, and the flexibility requirements. So again, if to meet the demands of the business, from a speed perspective, I've seen it. So, it's not just about it being likely. It would have been an absolute fact that we would have cut corners, and again, cutting corners is obviously not the most secure thing to do as well. So, for those three factors, in my mind security was better and is better in the cloud. Because I wouldn't be able to beat the staffing and talent requirements, the international encryption and privacy support requirements, or the flexibility and scalability requirements internally without massive underinvestment or other functional gaps that would make the environment less secure.

[00:22:21] MC: One of the biggest challenges that security teams often face when they move to the cloud, is they feel like they don't have that same level of visibility, control and governance that they had in the on prem world. So, I'm curious from a people process and technology perspective, how are you guys addressing this? I know you said you guys are three and a half, this will be a three and a half, four-year process for you. So obviously, it wasn't one thing that you did. But how are you addressing this? Are there any specific examples you can share? I'd love to hear that.

[00:22:55] MT: Well, there's a lot of, I think, I'll call it mindset assumptions that are made just because you have the tangibility of having things on premise that are – so, just for example, just because you have everything on premise and have more direct control, doesn't mean you're going to have the I will call hyper standardization necessary to do something like full performance and utilization visibility, or full access control visibility. So, when we built and we're building up the cloud capabilities, one of the things that we absolutely made sure that we built soup to nuts and was full visibility, full transparency of configurations, full transparency of cost drivers, and all of that, because the cloud, again gives us the opportunity to do that in a more standard way for a company, again, with our size and our breath. The on-premise world, the number of variables that you have, in terms of how this can be done, are quite significant.

In the cloud world, again, broadly speaking, it's a choice of one of three, you're either Google AWS, or Microsoft. So, that is a much better story than the choice of 20, or a choice of 50. And then they give you the necessary set of tool sets and partnerships. And of course, people who read things about this, you have to recognize and I will continue to reinforcement, that you also have to recognize that by going with the cloud, you're not completely handing this problem to somebody else. It's a shared responsibility model. So, you get a series of tools and a series of capabilities that you can apply, you can adjust the knobs that are best for you. But they're all built with transparency and visibility in mind, which is one of the things that we've adopted. Before we “close any doors” or ratchet up any controls, full visibility was the first and foremost requirement. So, we built full visibility into this model.

So, even if we weren't comfortable that we fully had certain things controlled, at least we had the visibility and know what was going on. And that's something that to build across the level of variation of, again, all countries who do business with, all the therapeutic areas we do business with, and the sheer size and scale of our environment, that was an important first step for us is that making sure that we had that level of visibility. We have it, it's a lot of data that generates a lot of logs, but we're pretty confident we have that level of visibility. Now, we wouldn't be able to build that in the older environments.

[00:25:27] MC: So, I think there's something you may have alluded to a little bit earlier on, and that many organizations, they're in the cloud to some extent, but they're in this process of shifting their security left. Meaning they're trying to move security closer to the developer in the hopes of catching security issues, before they make their way into production, cloud environments. I would love to get your take on maybe what you've seen work well in this area. And then perhaps, if you have any anecdotes on what you've seen also be a train wreck. I'm a firm believer in studying both success and successes and failures. So, I'd love to hear what's worked well. Even if it's anecdotal, maybe some things that are not a good way to do, shift left, and some people use that synonymously with kind of DevSecOps.

[00:26:14] MT: Yeah, it's a great question. And I think a couple thoughts coming to mind here. So broadly speaking, if you look at the industry overall, and there are some exceptions here and there, like in the tech industry. But in an industry like biopharmaceuticals, there's been interesting phase shifts, if you will, of what the predominant operating models have been. So, 12, 15 years ago, we all were doing a lot of application development. It may have been done in languages like Visual C, or Visual Basic, or Lotus Notes, or some of these other types of platforms, but there was a lot of application development going on.

And then the pendulum swung to a very cots centric approach, customized off the shelf software. You buy your CBILS, you'd buy your PeopleSoft, you'd buy your JD Edwards, and we all – none of us really wanted to take on the burden of supporting stuff that we had built. We'd rather have a support contract with somebody to support the software that we would buy. So, we would all make statements like, we're never going to build anything, we're only going to buy. 

Now with the cloud, the pendulum swinging back again. A lot of us are developing our own capabilities, because that's the best way to leverage some of this technology and some of the variability that you have in a mobile space, in a multinational space, et cetera. So, the focus of moving the security left has basically allowed us to build in not only leveraging the cloud from an automation perspective, but also leveraging some of the quick checkpoints that you have in an agile working model, or a backlog from a sprint capabilities or sprints that you may run within agile. As well as some of the technologies that are available to do quick iterative code reviews earlier in the lifecycle.

We actually developed and launched completely separate groups that are focused on things like DevSecOps and digital innovation to do this as early as possible, and we've made a lot of headway within Takeda of shifting that focus to be further left and making sure that the appropriate checkpoints for application launches and release launches do have the security checkpoints in there. I think the pitfalls, I would say. So, I think the models that we built have worked pretty well. We've implemented technology in areas such as like I said, code review, but also API reviews and API protection. But other configuration management, configuration visibility to the containers in the cloud, et cetera. So, the technology options out there, they're quite numerous, frankly.

I would admit, one of the challenges is navigating how many technology options there are to do this. But I think one of the failures, at least one of the lessons learned that we had is it's very, very natural for us to think about what does it mean to be cloud native? And what are some of the new skills that you need for the cloud? But in reality, for any company, that frankly, wasn't found in the last two years, you're never going to be cloud native, because there's always going to be data that's on premise. But there's always going to be data in a legacy system. So, a development mindset, and in that regard, a security development mindset that assumes cloud only is likely, and we learned the hard way is going to fail, because it's very, very hard to find a boat that is purely cloud only. Because there's going to be a big SAP system, there’s going to be another large data repository that somewhere embedded in the business. And even if you're going through cloud migration, I mentioned before, we're on a four-year journey, that means half the application haven't moved yet. So, they're still on premise.

So, you're never living in one or the other. You're almost always living in both, and we've had to personally within our company, recalibrate our processes and our expectations to recognize that because of some of the overlaps, if you will, a recognition that we're going to be in this hybrid approach for quite some time.

[00:30:13] MC: So, Mike, you mentioned in your previous response about this whole shift from, billing our own applications, to buying COTS software, now back to building applications in a cloud native way. One of the things that, in security that we've talked about for a long time is the whole CIA triad, right? Confidentiality, integrity, availability. However, most security teams that I've been a part of usually focus only on the first two. So, they focus on confidentiality and integrity, and availability. I think they usually think, well, that's just something for the disaster recovery and business continuity teams to focus on.

I think you touched on this a little bit. But I'm curious maybe, again, with your IT background and being in security all these years now, how have you kind of worked with your security team and your last three or so years in the cloud, to build availability into your approach when it comes to securing your cloud platforms? What does that look like for Takeda?

[00:31:14] MT: Yeah, it's a great question. I think first and foremost to this is recognizing that as an intellectual property driven industry, which of course biopharmaceuticals is, the protection of intellectual property has always been and will continue to be critically important. However, we need to recognize that the threat actor community and the risks and threats from a cyber and information security perspective, the whole threat actor community has started to shift their techniques, because they're recognizing that the inability for a business to operate is more impactful than the theft of data.

So, if you take a molecule, you take an early stage drug, and you prohibit that drug’s ability to get to market or to be invented, or whatever, of course, the company that may have invented that is going to be impacted, of course they will. But the chances of that, when you're talking about a biopharmaceutical value chain, for example, or either even other intellectual property rich organizations like the development of thermodynamics, or the Intel's of the world, the GE’s of the world, all these intellectual properties. For everything that's successful, there's 90 things that are failing. So, it's a pure definition of science, that you learn a lot from failure, based to the question you raised before, which is absolutely valid.

The impact of the C, if you will, for confidentiality, can be impactful, but the chances of it being impactful, percentage wise are relatively low. There's much better chance for you to impact an organization you're trying to attack by going after the A, because if you can't manufacture product, you can't ship product, you can't do business for a couple of days or a week, that's significantly impactful. So, we have to first recognize that the entire threat landscape has shifted where that's now the most prominent and impactful attack type. I mean, the most popular word nowadays in our lexicon is ransomware, which is designed by that very nature that sabotaging destruction is more impactful than theft.

And starting with that, as a guiding principle, designing the security program, to make sure that we focus on the availability and the uptime of the technology is one of the things that we tremendously have focused on, and have significantly invested in ensuring that that's one of the top priorities of our overall delivery and uptime, if you will. We personally or within my team, we map, I would say our security metrics to the resiliency of the value chain of the business. 

So, we're no longer measuring network security measures, cloud security measures, endpoint security measures. In our business, there's basically four parts of the supply chain. There's R&D, there's manufacturing, there's commercialization, and then there's post launch ongoing health care. Those four phases and the resiliency of those four phases is what the business depends on, and that's how we measure ourselves is on the resiliency variable, not the traditional, I'll say IT stack level. So, that's how we've changed to address that availability as it continues and will be continued to be key and focusing a lot more on the resiliency elements there.

[00:34:33] MC: I love that. That's awesome. Well, Mike, I tell you, I've really enjoyed having you on the podcast today. It's been absolutely fascinating to kind of hear about your career journey and just about how you guys, I think are taking a very healthy and wise approach to your cloud migration. So, I guess last thing is, if our listeners, if they want to connect with you, what's the best way for them to do that?

[00:34:55] MT: Well, I'm on Twitter, even though it's the typical Twitter caveat that opinions are my own. But I am available on there. I'm also on LinkedIn, those are probably the two the best ways to get a hold of me because I'm pretty responsive on both. I'm always looking for other connections, other conversations other collaboration. So, thanks for the opportunity. I look forward to hearing any follow ups, after hearing this.

[00:35:17] MC: Yeah, that's great. One last question, because I forgot to ask this last time, I would assume we all hear about the talent shortage in cybersecurity. Is Takeda hiring on the cybersecurity side? And if so, where should listeners go to look at open cybersecurity positions?

[00:35:32] MT: Yes, we're definitely hiring like any other security organization, you're right. Talent is scarce. And it's in high demand. Takeda.com has a link for careers. I highly encourage people go there. People go to our website on LinkedIn. I know we have at least a dozen openings in my team, if not more, across many locations across the globe. We have a global team.

So yes, please. We're always looking for – and I would say that, if you're not a deep security specialist, that's okay. One of the things that I think we need to learn in this industry is deeply experience security people aren't as highly available as we would think. So, the model that we have within my team right now is find a good athlete and teach the sport. And that's how we're building up the capability to at least help manage the talent gap.

[00:36:25] MC: I love it. I love it. So, if you're awesome at what you do, sounds like Takeda would love to talk with you. So, go visit takeda.com. Well, Mike, thanks again for joining us. Until next time.

[00:36:35] MT: Thank you.

[00:36:36] MC: See you later.

[00:36:37] MT: Take care.

[END OF INTERVIEW]

[00:36:42] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com.

[END]