It's really interesting when you look at the security space.
We spend about $150 billion a year now on IT security tools and services.
Mostly on tools that are pretty good.
Most of the EDR [endpoint detection and response] software out there and the firewalls
and intrusion detection and prevention systems and WAFs [web application firewall], SIMs, all that stuff,
they're actually pretty good and everyone has them.
No one hooks up to the internet without a firewall.
Yet, the global cybercrime market is about $6 trillion.
If cybercrime were a country, it would be the world's third largest GDP [gross domestic product].
Why does this happen?
Why did people deploy all these really good tools and then still get breached every day?
A lot of it is a combination of unfamiliarity with tools
meaning you aren't able to get the most out of your investment.
You set up something wrong or you have something misconfigured.
I know I've certainly seen analyst reports that something like 99% of firewall breaches
are caused by simple misconfiguration, not technology problems.
When we say "misconfiguration," this doesn't just mean human error.
It can, but it can also mean things like, "I had to make a network change."
Your network, your application, things like that change all the time.
That may require a change in your security stack to accommodate it
that just doesn't get made.
Or a change is made but then it's rolled back for some other reason
or something isn't implemented in time.
Of course, the threat landscape changes every day.
Every minute there's some additional threat out there
and that also may require a change in some of your security stack configurations.
If you are susceptible to some attack because of drift,
either in your environment or in the threat landscape around you,
that is indeed because of misconfiguration.
That doesn't mean you necessarily made a mistake.
It could be that, but it could just be the landscape changed
and you didn't catch up to it.
It turns out, there's a very, very common cause of breaches
because you have the tools to either stop something
or, in more cases, detect something.
We spoke earlier about the dwell time, how long malware is active on a network.
If something gets into your network, it's not silent.
There were probably logs on your SIM that you could have seen
and that could have alerted you to, "I've got this active attack on my network"
but it didn't set off the right flags.
In many cases, this is a lack of SIM tuning.
The SIM is the thing that collects all the logs from all the security tools in your networks
and then you write rules to tie them together and say, "If this happens, this happens.
This doesn't happen, this happens in five minutes, that's bad so send up a flare
because I need to know about it."
If you don't have that tuned appropriately and on a frequently updated basis,
along with the threat landscape,
you could consider that a misconfiguration
and that means that you're going to miss the telltale signs of a breach in your network.
Rather than maybe detecting something five minutes or five hours
or even five days into a breach, it's five months.
The attacker had much more time to extract data from your network
and do a lot of damage.
When we think about the actual risks that people face on their networks,
and the impact of misconfiguration,
that is indeed the source of the majority of breaches in a network.
Making sure that everything is tuned correctly and configured correctly all the time
turns out to be much more important than making additional investments in security,
just making sure that what you have is actually working correctly.
That's step number one in keeping your network safe.
Breach and attack simulation tools let you realistically simulate an attack
on your own network using your own tools but doing it in a safe manner.
This isn't something you do in a lab typically.
It's not something that you do in a class.
You have software in your network which is emulating the behavior of real attackers.
The way that something moves through the network,
the initial transmission vectors,
actual emails with malicious attachments, things like that.
You're really testing your security stack against the actual tactics and techniques and procedures
that bad guys are going to use to break into your network.
We spoke earlier about how the traditional IT security best practices
are now very, very relevant for automakers
because their threats to their backend systems,
the things that do billing and firmware updates and safety and all that stuff,
now look very much like other IT deployments.
It's now very important for automakers to run the same kind of real-world security assessments
on a continuous basis against their networks and their security stacks
so that they know, "If I'm hit by this new attack, this threat, maybe this old attack,
am I susceptible?
Is it going to make it through my defenses?
Or if it does, if something just appears on the inside of my network somehow,
am I able to quickly detect and put out that fire?"
Breach and attack simulation,
which has certainly been gaining a lot of ground in more traditional IT spaces,
is extremely relevant for automakers as well to protect all those backend services.
With a breach and attack simulation system such as Keysight's Threat Simulator,
what you're really doing is you're putting software agents in your network
and then there are some typically out in the cloud
and they talk to each other in the way
that a real attack would sort of go from an attacking system to a victim system.
The same communication protocols, the same ports, the same data is sent over them.
The difference is what makes it safe is rather than talking to an actual application,
or actually running malware live on some end user's work station,
you're talking only to your own software agents,
or you're simulating the way that a piece of malware would behave on an endpoint.
So if you can accurately reproduce the registry mods and system calls
and file system touches and things like that,
that a real piece of malware would do,
you can see if your EDR software can detect that.
Similarly, if you're making all the same network connections and behavior
and you take the same amount of time and send the same data in the same way
and do the same sort of probes that real malware does,
you can test your NDR [network detection and response] software.
And all of those alerts and things like that bubble up to a SIM.
You can see, "If this happens, this happens, this happens,
which is exactly what would happen in a real attack,
is that going to set off the right alerts on my SIM
or do I need to go back and tune something to make sure
that when a real attacker runs the same attack on my network,
that I can detect it and flag it or block it or take remedial action?"
Let's talk about the way that breach and attack simulation
is different from some of the other, maybe more widely known security testing mechanisms,
penetration testing or red teaming.
When I say pen testing or penetration testing, there are different kinds of that.
You can think about like pen testing against a particular device,
like a car where you're trying to break into it,
or in the more traditional IT space,
penetration test means, "I'm on the outside of the network and I'm trying to get in."
The overall concept is obviously similar
but maybe different scope, different goals, things like that.
When you hire a pen test team to maybe break into your network,
you're really hiring a bunch of hackers,
typically fairly expensive.
They will almost certainly find a way in
so what you're really getting is, "Here's a way that someone can get into your network."
Modern pen testers tend to be more focused on things like social engineering attacks
and physical attacks.
When I say physical attacks, not kicking a door down,
but they might try to tailgate someone and get into an office
or they may sit in your office parking lot in a van
and try to hack their way onto the WiFi network.
They may try a social engineering attack:
find out that the CFO has kids who play soccer
and then they find out the name of the soccer team
and the name of the coach and they spoof an email from the coach,
which the person is likely to answer,
that says, "Here's the donut and orange juice schedule
when everybody's supposed to bring something."
The CFO answers it and that gets their malware onto the network.
That's all perfectly appropriate stuff
but penetration testers tend to not conduct exhaustive attacks.
They're not going to try every single security control in your network.
They're going to keep trying something until they find their way in and then they're done.
They checked that box and they've done their thing.
Penetration testing also obviously gives you information about your security
at a point in time.
Typically you're going to do this once or twice a year
so you'll know something about your security in January and July.
What the team in July finds is probably going to be very, very different
from what the team in January found.
It's certainly not a continuous assessment.
It's good.
We never say don't do pen testing, but you're going to learn very different things.
Red teaming is typically more of like a gray box approach
where the attackers know something about your network.
Typically, red teams have a more restricted tool box
because you're often asking a red team to emulate a particular attacker:
"I want you to use the kind of TTPs that ABT29 is currently using
to get into networks and steal this kind of data."
So you're really emulating a particular attack.
Again, it's not a bad thing to do and you can certainly learn a lot.
It's not going to be exhaustive because if the tactics and procedures and tools
that are used by a particular attacker are outside the scope of their current work,
they're not going to exercise those.
You're not going to know if your security stack is tuned to stand up to those.
It's more limited in that way.
It also is very expensive because you're still hiring a pretty expensive team of security experts
to try to conduct these attacks against your network.
Now you're paying two security teams.
One that's your actual defensive team
and then another team that's running around attacking it.
It's great to do and if you're a very well-funded organization,
go for it, absolutely, it's a good thing to do.
Unfortunately, that's out of reach of a lot of IT shops
just because it is so expensive and not everyone can do it.
With breach and attack simulation,
you're really deploying software that's doing all this for you.
It can be very automated.
You can literally run tens of thousands of assessments every day
and exercise your entire security stack,
even bubbling up through the SIM to your security team.
"Here's today's latest malware.
Am I able to respond to that malware appropriately?"
You can do this every day.
You can look at the change in your security posture over time
and answer the question, "Am I safer today than I was last week,
or last month, or last year?
What's the return I got on all my security investment, etc.?"
The fact that it's exhaustive and automated,
and certainly less manpower-intensive,
makes it a much more cost-effective option for many more organizations.
It makes breach and attack simulation a much more realistic option
for ongoing security assessment than some of the other tools.
The exposure, the risk profile that auto manufacturers have
now that cars are connected to the cloud, to the greater infrastructure,
to 5G networks, all that,
is really something unprecedented.
We haven't had to deal with heavy deadly machinery being effectively computer-controlled
on a large scale before.
Payment information, personal safety, threats to national security, these are not exaggerations.
These are all very real risks.
We discussed earlier how an attack against a traditional IT system, a phishing attack,
can have a downstream impact that sends a car off the road,
or steals payment information from tens of millions of users.
It's very important now for auto manufacturers and those operating the networks
that maintain the connectivity between the backend services and the cars themselves,
to have very, very good security.
The threat landscape changes all the time,
their application deployment profile and things like that are going to change all the time
so it's very, very important for them to now continue security assessment,
to continue probing and attacks
using real techniques that real bad guys would use against their networks
to make sure they they are as well-protected as they can possibly be
against those attacks that you know will happen.
People will absolutely try them.
If you put anything on the internet, someone's going to try to attack it.
It's certainly in the automakers' best interest to stay ahead of that curve
by first launching those attacks themselves.
That's why breach and attack simulation is such an important tool
for auto manufacturers in maintaining the security of their extended ecosystem.