Thank you so much. And I just love this village. You know, I have been coming to this village,
I think it is three years in a row. And I do miss DEF CON a lot. And some of you know my sister,
Karen Elazari, I often go to DEF CON with her and we definitely miss that experience. But I am
very excited to be here with you today. And today I'm also joined with a really good colleague of
mine, Anait, she is a spectacular engineer from the IoTG business unit with us. And we're going
to be talking with you today on this evolving landscape of baseline standards and regulation.
So first of all, let me check again. Can you all hear us great, Sam, Tim?
Yep, we can.
Wonderful. Well, as Sam shared, we are both from Intel. I work in the government's relation team
at Intel within the legal department. I work with governments around the world and policymakers
on issues of security policy. And I also lecture at the UC Berkeley School of Information,
where I teach in the Master in Cybersecurity program. And as many of you know, I'm also Israeli.
And usually when I come to this village, I start with a direct question. So let me do it again.
By now, most of you should be familiar with this face. And I hope you know him. This is Kevin
Finster. He's a researcher. And like many of you in the audience, he is also focused on embedded
systems. And specifically, he has a love and passion towards drones. And he has conducted
research on DJI, one of their drone systems, and he found the vulnerability that, according to him,
leaked personal information. And he wanted to report that vulnerability to DJI and, you know,
do the right thing and engage in disclosure. And at the time, DJI just launched their bug bounty
program with this media announcement, inviting the community, inviting the ecosystem to report
vulnerabilities to them. And, you know, it was not really clear what was the scope, according to the
reports. There wasn't really a bug bounty policy or contract. And there was some confusion between
the parties on this issue of the scope, according to the reports. So Kevin contacted DJI and asked
them, is this vulnerability that I found is in scope? And they, in fact, according to the reports,
suggested it is in scope. Not only that, they said that they would like to pay him $30,000
for that vulnerability. So for those of you engaged in bug hunting, just empirically speaking,
that's a pretty high bounty. And then the plot thickened. So there are two sides to this story,
and I encourage you to check out the links in the bottom. But Kevin felt that during the negotiation
on issues of disclosure, there were some issues that were unclear, again, because we didn't have
that scope and website. And then the plot thickened. And then in the draft letter mentioning
the Computer Fraud and Abuse Act, which is the main anti-hacking law here in the United States,
together with the DMCA, was mentioned, according to the reports in that letter. And Kevin ended up
walking away from this approved bug bounty of $30,000 and sharing on Twitter his version of
the story. And, you know, he did order a Tesla. He ended up canceling that order of a Tesla.
And it's just a story highlighting some of the nuance between laws and bug bounties and
vulnerability disclosure programs in this evolving landscape of anti-hacking laws.
And it's a story that I shared a lot during the last few years. And I'm actually happy
to report that we have seen, maybe also because Kevin went and shared this story,
a lot of progress in this area. We have seen a lot of safe harbor adoptions and a lot of
collaborations between companies and researchers. And even recently, it was announced this week,
and maybe you have seen the draft CISA binding operative directive from CISA, which is the main
federal cybersecurity authority that actually has also safe harbor language in it as well.
So all of this is very exciting. And for me personally, because I did spend a lot of time
on these issues between law and technology, and specifically this landscape for the last
years in my prior work at Berkeley, before I joined Intel, promoting this framework for
collaboration, it really is nice to see the growing adoption of safe harbor.
One of my key takeaways from this kind of evolving interaction between law and technology
is that laws are often basically evolving slower than technology. So we know that laws are slowly
being amended. It's not like innovation that is rapidly being developed. And laws often have
concepts like authorization or reasonable security or principles that are adapted with time. The
reason I bring this example is that if you even consider the CFAA, again, this main anti-hacking
law that I mentioned, and I'm sure many speakers are speaking about this law throughout DEF CON,
it is a law from 1986, before the internet as we know it today. And much has changed,
including hacking and security testing. And this year, the Supreme Court is going to actually take
one of the first court cases on this issue of authorization. And we will see how that will
evolve. But it just shows kind of how the laws are adapting to technology but are often behind.
And I think this is one of the main takeaways that for you in the audience today from our talk
is we're going to look at this landscape from both a policy and both from a technical perspective,
and we're going to see how things are fitting together. So I shared a little bit about my
background. Towards this week at DEF CON, a lot has been talked about in terms of disclosed I.O.
and bug bounty. You can check out my prior work in this area. But I'm very passionate about this
issue of collaboration between researchers and hackers and companies. And while I am a lawyer
and my background is legal, I'm not your lawyer. And today I'm going to be talking about my own
personal opinion and I'm not going to be providing any legal advice. So I know this is a little bit
of fine print. You would probably expect that from me, right? But it is exciting. And, you know,
if I need to complement kind of the prior discussion, I am also very excited to share
that we at Intel, which I've recently joined, we do have a safe harbor in a bug bounty program,
and we encourage you to not just engage with us, and we're going to talk a little bit about that,
but also know that we have that language in our bug bounty. And with that, I spoke a lot about
collaboration. I spoke about why this is important as we think about technology and laws and how they
go together. So I want to invite my fearless collaborator, Anait, to tell us a little bit
what it is in the evolving attack landscape and particularly the IoT ecosystem that is
sparking all this conversation around IoT proposed regulations and policies. Anait, please take it
away. Thanks, Amit. Indeed, it's a great collaboration. So hi, folks. Very glad to be
here. And as Amit said, I work directly on product definition side. So today we are talking about
security and regulation policies, right? And being on the receiving side of the regulatory
guidelines inside Intel, I spent time understanding and assessing the technical
implication. So first, I would like to start looking at the concern that triggers this rising
regulatory effort. And one of the key IoT security issue is the expanded attack surface. And that's
due to the increased number of the endpoint devices. So we all see this futurescape that predict
billions of devices with trillions of sensors. This large number of IoT devices that being
brought into the business triggers the growth of attack. Another issue is the sophistication
and evolving of the intent. It is clear that the attack target is not limited to the assets of IoT
device only. IoT device exposure opens a plethora of opportunity across the edge to cloud and
exposes a lot of valuable assets. So let's analyze the genealogy of the IoT attacks.
So what you see here is typical IoT solution that spans edge to cloud. So IoT device control
other devices in the system and itself, they being controlled by others in the edge to cloud
solution. This duality exposes enormous challenges for the security community and adds new dimension
to the system cybersecurity controls. Attacks that originate on the very left side at the edge
easily can propagate throughout the entire pipeline and single device can jeopardize the
entire solution. One notorious example of this type of scenario is a casino fish tank attack.
I don't know how many of you are aware of that story. But just a quick recap.
So using a trivial vulnerability in a smart thermometer in fish tank,
hackers gained access to casino network. They retrieved data about high paying customers and
then extracted that data through the thermostat and to the cloud and a result of it, 10 gigabyte
of data ended up in Finland. This looks like a Hollywood ready story, perfect for ocean trilogy
sequel. But from our perspective, this just proves the point that the simple device, in this case,
the thermometer, can break down the very tough protected end-to-end solution.
With that many new devices already deployed and even more on the way,
it is important to consider the unique challenges in IoT space.
And first, let's look at the technical side of it. So IoT business world is different from
traditional well-established and structured PC environment, cloud environment. There are
several factors that contribute to the technical and business challenges in our world.
It's a diversity of distinct market segment and the business model. So very range of the,
very wide range of the use cases that we are dealing with. IoT usages need to meet
stringent power performance and form factor requirements. Another challenge is the complex
ecosystem. There are many entities involved in defining finished and customer usable product.
Another distinction is the wide range of the software and firmware, which includes OS,
hypervisors, bootloaders, right? Of course, application and all the workloads that run
on top of it. Heterogeneity of the installed base in that end-to-end solution is also a pretty
unique factor. IoT is a mix of the green and brown field devices. And on top of it comes the icing.
IoT needs to be supported over extended lifetime, which is much longer than traditional PC
service. All these challenges become contributing factors to vulnerability of IoT devices and
introducing security risk. Those are the concerns that actually triggered and got reflected in the
policy arena. And here I would like to ask Amit, please share your insights from the regulatory
guideline perspective. Thank you so much, Anet. And you're exactly right. When it comes to the
evolving policy and regulatory sphere, the complexities that we're seeing in terms of
the various business model and the technical verticals also influence what are some of the
principles that the policymakers are considering as they're coming to proposed best practices,
reports, standard development, and laws and regulations and requirements in this area.
One of the interesting things is this idea of having the risk-based approach. This is, by the
way, an underlying principle for all security policy. But particularly in IoT, it's important.
Why? Because we have that horizontal but yet very versatile environment of devices, right?
Everything from the low-cost business model of the dog collar, if you will, to the sensitive
devices being deployed in critical infrastructure, election system, medical devices, and the like.
So with that diversity of technical systems, business models, economic consideration,
considering the risk of the device, not just in terms of which vertical and sector it goes into,
but what is the environment, what is the unique attack surface the device is being deployed in
from various kind of standpoints? That's one of the ideas when you think about the proposed
regulations, that the requirements should apply based on a risk-based approach. And you as
researchers should expect a lot more standards and thinking. This is already an established
principle in the security community and also in IoT, for example, 62443 IEC, but you should expect
more and more thinking and principles and standards around in this area. What more? Definitely the
regulatory environment should consider how to support innovations. A lot of these problems
are going to be solved by technology and we need to incentivize the development of innovation
and consider the fact that proposed regulations might hinder innovation if they're not framed
correctly. Interoperability. So this is a key issue. We need to think about how the IoT devices
are working together. How can we foster the secure deployment that is interoperable for IoT devices
and also how IoT devices are connecting edge to cloud with OT environments, with other environments.
All of that is putting interoperability in the kind of front. And here this idea of leveraging
international standards that are scalable, that are developed globally at forums like CTA, ISO, IEC,
JTC1, Etsy and the like, that is also very critical because as you know, technology knows no
boundaries. The deployment of IoT is obviously a global phenomenon, but the supply chain
of technology is global in its nature. So we want to avoid fragmented regulation or some kind of
requirements that are really localized because that's not scalable when you think about manufacturers
that are, and the supply chain that are globally, that are global in their nature. Another key
principle that is not unique just by the way for IoT but is really important for IoT is this idea
of design neutrality. That laws and regulations, because they usually adapt, they usually are
amended very slowly, they always walk slower than technology, should not bake into the legislative
language a specific design or a specific requirement that might become outdated or even
terms, for example, like passwords that might change with time or a unique technical definition.
Instead, we should leverage these international standards and principle-based approaches.
And with all of that, I think a lot of regulators around the world and policymakers are recognizing
the need to consider IoT as part of the broader ecosystem and enable private-public partnerships.
So I spoke a lot about the principles, but let's dive in. Let's look at a few examples of what is
really kind of cutting edge in terms of proposed regulation in IoT around the world. Now, this is
just an example. I'm going to walk you through more domains, but this is super interesting. It's
coming from the UK. Some of you may have heard about this in the past. I believe it's since 2018,
the UK, with their leadership, have put together an IoT security code of practice with 13
requirements. They've taken that effort a step farther, and now they're considering a law,
a regulation. This is, I believe, the third consultation already they are publishing
for this regulation. And by the way, now they're also considering to encompass PCs and laptops
as part of their regulation. They're really looking at three core requirements that are
proposed. The first one is around this issue of not having default password and having unique
authentication. This concept is one that we have seen in other regulations around the world.
If you look at the prior consultations, they say explicitly how they were motivated by the Mirai
attack. So you see the connection between the attack surface, the attack, and then the
regulators are considering action. The second requirement is around an issue which is very
close to heart to this community, having the public point of contact as part of a vulnerability
disclosure policy or program to allow researchers like you to submit vulnerabilities to the
manufacturer and have the manufacturer address the vulnerabilities. The third point which is
proposed is around this issue of support of security updates. By the way, they're also
referencing a standard, a technical standard, they have been developing as part of a broader consensus
at Etsy in Europe which really talks about consumer IoT requirements in more detail.
But it just kind of shows to you the connection between the standards and the proposed regulation.
So if we look at the broader landscape, we do have a lot of things happening in this sphere.
Everything from state laws, actually in Oregon and California we have laws already in effect
from January 2020 on connected devices, looking at this issue of reasonable security for connected
devices and they have some language there as well on the issue of authentication means and unique
authentication. We also have proposed federal laws. So this is very interesting. In the United States
there has been a number of proposed federal laws for all the United States on this issue of IoT
security. One of them is the IoT Cybersecurity Improvement Act that has been proposed for a while,
looking at leveraging federal procurement of IoT devices with requirements for all devices going
into federal procurement as a way to foster security of devices in all domains. We have also
seen a recent COVID white paper from the Cyberspace Solarium Commission proposing that we should have
all the market IoT federal U.S. law, so certainly an emerging area. We also have best practices and
standards. Okay, so this particular area is of particular interest and we're going to
dive in into the requirements or at least the consensus around what are some kind of the
foundational capabilities of IoT devices. This is an effort to bring all of industry together,
both at the international level, so that's at ISO, I'm an editor of one of the standards there,
but both in the U.S. with efforts like NISTOR 8259, that by the way is also referenced on the left in
the COVID white paper of the Cyberspace Solarium Commission, so you see the interaction between
the efforts. What's of particular interest for this community is that these are really technical
documents, they are horizontal, they reflect the consensus of all of industry, and they might shape
the future of both research and market demand in this area. We have also seen, based on kind
of these efforts of overall horizontal kind of trends, sector-specific requirements. So
for example, NIST has created and worked together on building consensus around NISTOR 8259,
which is always central to all the market. Now they've also released a draft on GitHub,
a federal profile of these requirements, that is in particular for the federal government
sector, so what goes under FISMA to federal agencies for that particular sector. In addition,
of course, this is not just in the U.S., I've showed the example from the U.K., we have seen
around the world attention to these issues with governments like Australia and the U.K. proposing
code of practices for IoT. Australia, in their recent announcement of what they're going to do
in terms of cybersecurity policy, they have a segment on IoT there. Of course, in Europe, a big
conversation around attestation, certification, and INISA is definitely also thinking about IoT.
So this is a global phenomenon, and we have seen leadership also from countries like Japan
proposing risk-based frameworks for IoT, so definitely of interest for regulators and
policymakers around the world. So finally, I talked about international standards and their
importance, how they've been developed in this area. We have seen two interesting also, I would
say, trends that go together with IoT. One of them is supply chain prosperity. This is, of course,
a big theme in the area of security policy, but in particular, it's connected with IoT. So those
of you who are long-term DEF CON attendees, or besides Las Vegas attendees, or just otherwise
might have seen talks from Alan Friedman on the initiative called the SBOM, the Software Bill of
Materials. So this is this idea that you should have transparency into the ingredients of the
software, and that transparency into the ingredients can support the other capabilities like updates
and the like. In this area, we also are getting to have some solutions around compute life cycle
assurance. Another trend that we have seen is the coordinate vulnerability disclosure trend that
goes together with IoT. So by that, I mean regulators and policymakers are also recognizing
the need to leverage the ecosystem, the need to have that collaboration to address the issues,
and they are coupling together with proposed reports and regulations and best practices,
this idea of having a process to receive vulnerabilities from the external community,
and you have seen the example from the UK, and to handle the vulnerabilities internally. So
bottom line, a lot of evolving kind of proposed, a lot of evolving kind of initiatives with
relationships between them, some are horizontal, some are sector-specific, and a bleed towards
other areas of security policy. Now we're going to drill down into this NISTR, which is this
consensus-driven best practice. This is not a regulation or a requirement per se, but it's a
consensus effort that is of interest for this community. You can see here on the left the C2
effort by the Council to Secure the Digital Economy, and all the different trade associations
really spanning the entire technology sector that have come together to define this consensus.
Anaita, I would like to invite you to present to us with more detail the technical elements that
are explored in the NISTR. Thanks, Amit. So yeah, you heard a lot about NISTR at the magic 8259
number, right? Let's take a closer look at what it is, what is the motivation and objective. As this
effort very well exemplifies what's happening in regulatory momentum. So what is this about?
8259 targets manufacturers. Specifically, the subject of this recommendation is framed around
the finished IoT devices. It provides the recommendation on cyber security activities
and capabilities to address customers' cyber security needs. So NISTR publication proposes
to normalize the manufacturer-customer relationship by leveraging the laws, regulations, and guidelines.
Let me set the expectations right. So 8259 is intended to address a very broad range of IoT
devices, from tiny little doorknobs to very complex critical infrastructure class of devices.
So expect to see what I would call it lowest common denominator. However, this is setting the
trend, right? It's also important to note that all other parts of the IoT ecosystem, other than IoT
device itself, are outside of scope of this NISTR recommendation. So overall, this is the first step
towards the making the IoT security more measurable. It is expected that eventually more
guidelines will be developed to address that out-of-scope problems, as well as more specific
market segment profiles and the risk-based recommendation will evolve from this one.
And we do see it happening already in the federal space, as Amit mentioned earlier.
So NIST emphasizes the message that IoT security shall start early on. So let's look at their
recommended actions. Again, remember, this is all about manufacturers. It is proposed that
IoT device manufacturers need to perform this action and provide the services to their customers
who would plan that cybersecurity for the devices within their system and environment.
So NISTR 8259 identifies six specific recommended actions, pre-market and post-market.
The first two activities assume that manufacturers have to have the full disclosure on device usages
and the security goals. This might be quite challenging, actually, as there are many cases
that we know when customers and manufacturers don't have that good collaboration. As a result,
manufacturers cannot expect what will happen with the device in the field.
Activity number three is the anchor point for the core baseline capability.
These capabilities are defined by NISTR 8259a and supposed to address what customers would
need to achieve their goals and fulfill their requirement. This is the most technically loaded
proposal in this recommendation. Activity number four addresses the support. So manufacturers
should consider all the resources required to support development and continued support of
the IoT device. That includes security code practices, vulnerability disclosures,
vulnerability responses, and floor remediation. Post-market, there are activities five and six,
and those are related to customer communication. Although I would call that really post-market,
as planning on how to address these activities needs to be baked in at very early stage of the
design of the product. There are several potential considerations listed in the publication for
this stage. Some of them are the lifespan expectation, the software update, device
retirement, and end of life. The main takeaway here, so NIST attempts to frame the security
actions around the different stages of the device lifecycle, bringing manufacturers to customers.
It calls out that pre-market development stage core capabilities needs to be addressed.
So now let's see what are those core capabilities and drill down here. This baseline represents
the industry-wide collaboration effort that Amit mentioned earlier, as a result of which
definition of common capabilities were produced. And the common is the key word here. This is not
exhaustive lips. Remember the lost denominator? This is starting point that set the direction.
Therefore, in each implementing organization, you may find the superset
capabilities that better fit their needs. There are six basic capabilities outlined.
First one is device identification, covers both logical and physical identification.
Second is device configuration that can be performed by authorized entities only.
Data protection addresses the protection of data from authorized access and modification.
Logical access to interfaces is about restricting of logical access to local and network interfaces.
Software updates recommends that, again, the update needs to be done in supervised manner,
updated only by authorized entities. And last one here is the cyber security state awareness.
So this capability is about the ability of IoT device to report its own cyber security state
and make that information accessible to authorized entities. So this was just a quick run
through these capabilities. There are many nuances to this baseline. So I would recommend
reading through NISTers 82598 document directly. And at this point, let's change the gear and look
on what's left outside of out of the NIST scope. So we did talk about the complexity of the
ecosystem. So NIST simplified the ecosystem model just to two entities. And we at Intel realized
that truly deployable IoT solution require more complex relationship. When we think about Intel,
we think about Silicon, which would be very left of this picture. It is our partner ecosystem that
builds out the rest of the story. So the analogy that we like to use a lot is the orchestra playing
together. So each player has a critical role in delivering finished symphony to the audience.
And the value chain in case of IoT device goes from the ingredient to manufacturers, OEM, ODM,
then through the ISVs, cloud service providers, solution integrators, and then only get delivered
to the end users. So all these artists participate in the security baseline definition
and implementation. But there is also the life after the deployment, right? The device goes to
the circular stages of the updates. And again, manufacturers, they have to rely on the rest of
the ecosystem to deliver the updates. So what do we do? So we realized that it's not an Intel
universe, so we have to work with the broad ecosystem. And we established the partnership.
So IoT Solution Alliance is our partnership framework. It covers 6,000 solutions, includes
more than 500 members, and of course, we work across the globe throughout our global platform.
As Amit mentioned, this is very important from the regulatory perspective, the global interaction in
the policy space. So our member companies, they span the globe and offer local expertise in
market worldwide. This is the community that we're closely collaborating on security as well.
And for the security discussion, it's important to establish the common ground, attack surfaces
and threats is that the common ground that we use to build the collaboration. So let's take a look
to this table. The attack surface sums up all the penetration points, otherwise known as
attack vectors. So a summary of exploitable vulnerabilities at device level. So we are
looking now at the device level is presented in this table, where different threats on the right
side are correlated with respective attack surfaces and components on the left side.
Moving from bottom up, you see the hardware layer, right? And then above it is the firmware
optional hypervisor when virtual machine monitor and then the operating system. And finally,
this user space where the application or workloads will be running. The attacks in the top layers
have been prevalent and known for quite some time already. But attacks are more and more
moving down the stacks, exploiting vulnerabilities all the way to the firmware and the hardware
layers as well, which could potentially give even more interesting opportunities,
higher privileges on the devices as well as those attacks can go fairly undetected.
So let's take an example. So by tampering with the firmware, it might be possible to subvert
the entire boot, right? And boot the operating system, which would be attacker's choice, right?
The desired operating system. This table overall is an eye chart, but I think the main takeaway
here is that the attacks are not singular, right? It's a multi-dimensional problem and spans across
the entire stack of IoT device and requires the protection mechanism at each layer as well.
So having this framework allows us to systematically analyze the security solution
to mitigate the risk from the very early stage of our product design phase. And we work with
our customer based on this taxonomy. And we do provide, of course, solutions and innovate the
hardware-based security technology in our product to build the defense in depth from the bottom up
and withstand the attack propagation. But, Amit, it's not only about our own innovation and our
own technologies, right? So can you share your thoughts about how this evolving attack surfaces
can drive a greater collaboration with technologists? Yes, absolutely. And I think, Amit,
you're exactly right. I think you've seen throughout this presentation so much of the complexity that
is pretty unique for the IoT ecosystem. And this is the vertical business model, the versatile devices
from everything from the dog collar to the sensitive systems, the type of the attacks and
how the attack surface is evolving, and also the technical challenges, right? And Amit
definitely provided a very extensive overview of this. All of this suggests that this issue is not
just going to be solved through the innovations, through the security capabilities that we are
going to bake into hardware and software and firmware. Yes, that is a critical piece of the
discussion. Yes, incentivizing the innovation, the R&D, the research, the pipeline, all of that is
critical, but we are still going to need the collaboration. And by collaboration, I mean
companies working with researchers, enabling the ecosystem, right? Collaboration between the
different verticals in the supply chain. Also collaborations between policymakers and legislators
and regulators as they're thinking about these issues between the public and the private industry
and having your expertise, the expertise of the crowd in these arenas as well, engaging in
that dialogue. And I think we have seen tremendous developments in that area. I think the safe harbor
kind of discussion is one of them. We have seen also growing collaboration and a lot of thinking
that goes into researcher relations. I don't know if you've seen some of my peers from PSIRT and
from Intel Security at the Red Team Village or in this village talking about how we collaborate with
the ecosystem, how we are funding academic researchers in this area. All that is critical.
So as we are thinking about this kind of conversation, it's really critical to get
the dialogue going. And with that particular recommendation, I would like to invite you all
to ethically hack us. We do have a bug bounty. It's a public bug bounty. We offer rewards. You
can check it out. You can check out the scope. We also have a vulnerability disclosure program.
You can report vulnerabilities to us. The collaboration with the researcher community
is extremely important to us. And we work with the entire ecosystem to drive security first.
So security at Intel.com, please report your vulnerabilities. Please continue the great work
and research in the embedded system arena, especially this village is dear to heart for us.
And let's continue the conversation. And we would like to welcome your questions. I did
went through in a true Israeli fashion and a little bit of my style. My sister always tells
me to slow down. I went through a lot of examples when I was talking. And I will provide you the
links to all of these resources that I've talked about and Ana shared as well in the Discord chat.
So this is just a little bit of preview. Please join us in the Discord if you want to get all
the details and all the information about what we shared with you today. You can find it there as
well. And we'd like to continue the conversation with you. Ana, for me, this has been a great
collaboration. The former hacker that I collaborated with in a talk is my sister,
Karen. I hope to continue that collaboration. Maybe she is here with us in the audience.
Karen, I haven't forgotten you, of course. But this has been a really joyful dialogue for me.
Thank you so much. Anything to share from your perspective, Ana, before we wrap it up?
No, this is a great journey. And this is a great example of collaboration. Again, I am on the
technology side. I'm on the product side. Amit represents a more regulatory perspective.
And this is when these two... when the two worlds meet, we see absolutely new perspective, right?
So collaboration is the key. And thank you very much. We are looking to hear from you.