Data poisoning constitutes an attack strategy, where the training data utilized to construct machine
learning or artificial intelligence is manipulated or poisoned.
In 2016, Microsoft came out with a new AI bot for Twitter and in less than 24 hours, because of human
interaction and manipulation, the AI bot became racist, sexist and hateful, not to mention spiteful,
and Microsoft was forced to remove the AI from Twitter itself.
Not only did it point out the complexities of the human mind, but it also pointed out how we can manipulate
AI in construct of how we interact with its machine learning algorithm.
When we talk about data poisoning, we're looking at data quality.
How good is the quality of data?
You have to remember that data is only as good as we put in.
If we put garbage in, we're going to get garbage out.
It's like anything else.
If you train something to act a certain way, and the quality of that training is poor.
Don't expect the data that's feeding that program to be excellent by nature.
Poor data is going to constitute a poor program.
We also need to constitute data monitoring because along with excellent data, we also need to ensure
that that data is being perceived and written correctly.
And so we want to monitor that data and how it interacts with the systems in place.
If we put in garbage and we expect garbage out, if I put in excellent data, I want to make sure that
the data that's going through being rewritten and utilized by the program is not only of high quality,
but it's maintaining that high quality standard as we move forward.
We want to use outlier detection methodologies.
How is the detection of that data being utilized within our processes?
We don't want to just depend on one functionality.
We want a redundant functionality.
We want multiple systems to detect if something is going astray.
We want to validate the model that we're using, just like statistics.
If I provide statistical analysis to something, and that statistics is leaning left or right or sideways
in any way, shape or form.
Don't be surprised when the model that we're utilizing leans left, right or sideways as well.
We want to verify the data processing.
Is it being processed appropriately?
We often see within data processing standards that when we utilize data and we're expecting an output
for a specific scenario, we can't utilize that same data processing scenario.
We need to rewrite how that data is processed for the specific output that we're expecting.
We want our access controls to be stringent yet usable by the average employee.
If I'm looking at physicists and I'm providing access to physicists for the data that they're requesting,
I want to make sure that the generator down the street doesn't have access to the data as well.
Finally, we want to patch our systems.
Believe it or not, patching represents a unique and robust system that could play permanent damage
within our systems.
If a vulnerability exists.
If I fail to patch a system and its processing data, even if the data is great and it's excellent,
and we're using it just the way we want.
If somebody takes advantage of a vulnerability because we didn't patch the system correctly to fix a
flaw or a fault within the configuration.
Don't expect the data to be great when it comes out of the end.
We want to talk about broken access controls as well.
We want to prevent unauthorized access to sensitive data and functionality.
We can utilize this in a variety of different standards.
We can use rollback rule based access control, where we're using different rules or scenarios to limit
the access of our different systems.
We can do attribute based access control or Abac.
This is where we take different attributes of the user to identify whether or not they're able to have
access.
When are you going to use least privilege, which we discussed in a previous slide?
We want to test and weather to make sure that access control is being utilized properly.
Even if we have specific rules based or access or attribute based access controls in place.
If we don't test it, we're not really sure if it works the way it's supposed to.
We want to make sure error handling is correct.
If I provide an error and somebody, a malicious actor is able to read that error, and then that error
is then pointed to a specific fault or vulnerability, then a malicious actor could take advantage of
that vulnerability because we didn't handle the error properly.
We want to identify session management.
It's not uncommon for malicious actors to piggy tail off a specific session, and then repeat that session
via a replay attack and gain access to our systems.
By using proper session management, we can dictate, hey, this access for the specific length of time
was for this session alone.
We're not going to allow you to do a replay attack and gain access to this specific information, again
using a different session.
Again, we want to patch we want to provide web application firewalls which are specific to input validation
or web based.
And then we want to do Bola.
And of course BFL when we talk about those access controls, we want to use business object level authorization
or Ebola to utilize restrict access to specific business objects or resources.
We don't want to just give any business object or business department within our industry access to
the same information that we would operations or finance or HR.
We want those to be specific to the level of authorization that they're allowed.
And finally, business flow level authorization.
We want to implement VFR to ensure users can only perform actions appropriate to their current role.
If I have an IT department that's filled with 30 different employees and one IT person is delegated
to specific servers, another one is delegated to operating systems and one is delegated to help desk.
I don't want those interchangeable.
I obviously don't want my help desk guy having access to my server information, and vice versa.
If there's no need for it, there's really no reason to have full access, even if they're working in
the same department.
And I need to limit those authorizations appropriately Cryptographic failures denote a vulnerability
or weakness within the symptoms, cryptographic algorithms, protocols or key management systems.
That's a lot to take into play, but you need to remember that cryptography is the combination of the
algorithm and the key to denote a specific encryption over a specific protocol.
If I have a failure or a vulnerability within the system, then I have a cryptographic failure.
We denote this by a secure algorithm.
Am I using an algorithm that is compiling the encryption in such a way that it's not easily reversed?
For instance, Des is an old encryption algorithm that we no longer use.
But if you are using Des, even with a very high level key, then that algorithm is then weak and it
provides a cryptographic failure.
If we're using key management within the system, and I have a high cryptographic algorithm such as
AES using a 128 bit encryption, then I need to make sure that my key management is high as well.
I don't want a key that's like one, two, three, four and expecting my secure algorithm to keep my
encrypted traffic secure.
Obviously, having a high key or a high key management within the within the overall cryptographic function
is important.
But it's not just about keeping my key respectable and length.
I also need to be aware that those key management institutes a functionality where the key is being
stored properly in a secure location that doesn't give everybody access to it.
And so I need to have proper key management when it comes into play.
I need to have password storage.
Is the storage of the passwords being provided with the proper level of security?
Am I using salt?
Am I using a pepper?
Am I using hashing or am I storing those passwords in the clear on a random server out in the middle
of nowhere that anybody could hack into?
I want to provide a secure random number generator before we saw within several encryption algorithms
or several multi-factor authentication systems, that the random number generator wasn't truly random,
and you could identify what the next number was going to be implemented into the series.
This provided a unique flaw or vulnerability within the MFA architecture, so we need to make sure that
our secure random number generator is truly random and it is secure, meaning that somebody can gain
access to it and then pinpoint the next random number to be generated, we need to provide certificate
pinning and digital signatures.
Where is the authorization coming from?
Are we authenticating the traffic that's going back and forth.
Both of these constitute a specific security vulnerability.
If the digital signature or the certificate pinning is improperly introduced and kept secure, we need
to provide an application firewall.
It's not enough just to provide error handling and to make sure that our application is unique.
If we can do an application firewall, then we control the access within our systems, and we can provide
an extra level of security to ensure that our overall system does not suffer from a cryptographic failure.
And just like patching before, it never changes.
We're always going to keep our systems up to date with the newest patches to secure those known vulnerabilities,
those known flaws within our systems.
Finally, we have insecure design.
Within insecure design, we have secure development lifecycle.
We talked a little bit about development of software and how it needs to be secured from the from the
beginning of the process all the way to the get.
If you take a known piece of software and you try to put in security in the middle of the project,
or even after the project is already done, you're going to suffer from vulnerabilities because there's
no way you can 100% secure that software.
You're also going to cost you more.
When we talk about development, life cycle of security, security, what needs to be involved from
the get go, we need to provide the secure coding practices and the secure design well into the beginning
stages.
Before we even start coding, we need to do a component analysis.
How is that design being implemented as a whole?
It's not enough just to put our network together and go, oh, I need another router to encompass extra
users.
That's going to provide us with an insecure design.
We need to establish that.
Hey, I'm setting up this network now, and I'm expecting to have to expedite or to add on to this network
in the future.
Let's design it from the get go.
For expansion, we need dynamic application and security testing when we're designing, or ensuring
that we have applications being dynamically tested throughout the process.
If I provide a new application or I pick up an application from a third party vendor, am I testing
it properly?
Am I going through and dynamically testing it to make sure there's no vulnerabilities or flaws, not
just within the software itself, but how it interacts with the software that I'm already using on my
systems and the operating system that it's supposed to run on.
We need to do runtime application and self-protection.
Again, we need to do static application security testing.
I need to go code by code, line by line, to verify that there's no indicative nature of vulnerabilities
or flaws within that software that I'm getting ready to put on my systems.
I need to maintain access controls and error handling configuration Curation management, where we're
configuring the software.
We're configuring the design of the hardware to be robust and secure in nature.
If it's interacting with other components on our network, how am I configuring it to maintain that
security level?
If I have a SIM that's operating with a firewall and the firewall is feeding logs to the SIM, am I
doing it in such a secure manner to where those logs are being properly secured from point A, i.e.
the firewall to the SIM itself?
Logging and monitoring.
Again, if I'm going to provide logs and I need to do monitoring, how am I pulling that off?
Am I using a SIM if I'm not using a SIM, how am I maintaining those logs?
How am I continuing to monitor those logs to ensure that if an attacker comes in, I can use detective
methodologies to ensure that my system as a whole is not going to be taking control of for the next
three years, because we're able to monitor it and detect those failings within our system at the get
go.
And finally, application firewalls.
How am I securing my applications properly, utilizing a firewall as a defense in depth measure?
When we talk about security misconfigurations, Configurations.
We need to enforce our security policy to talk about security.
Misconfigurations when we talk about security misconfigurations, nothing comes to my mind more than
the recent troubles that we've seen with T-Mobile over the last 2 or 3 years.
T-Mobile suffered from using hardened credentials or default credentials in their routers, and has
provided data breaches because of those credentials.
Had their employees followed enforced security policies to change the default credentials off the get
go, those data breaches never would have occurred.
It's so imperative that we follow our own security policies to ensure that those security policies are
being followed, that it makes up nearly almost all of our data breaches that we see today.
Now, I know some people are gonna be like, wait a second, did you just say almost all?
Yes, I did.
Human error makes up 93% of all security failings across the board, and that's a failure of our security
policies.
How are we enacting those security policies within our network?
It's not always the IT or the cyber guy that's making that mistake.
Sometimes it's as small of a person as the receptionist at the front desk, clicking on a phishing email
she should have never clicked on in the first place.
Enforcing security policies is the best thing that you can do when it comes to configuration of our
systems, the standard operating procedures or SOPs that we utilize.
How are we operating?
When we talked about the default credentials, I guarantee you there was an SOP in place for T-Mobile
to follow for that technician to follow when they were reconfiguring that router, replace it.
Otherwise the default credentials would not have been in place.
And finally, are we following proper change management?
Am I going through the notations of change management and my prepping for it, or am I just going to
throw things on my network willy nilly whenever I feel like it?
Change management is there for a reason, and we need to follow the proper outlines and procedures associated
with change management to make sure that we have the authorization.
We have the proper process, we have the pull back if something goes wrong.
Change management is so important for us as IT and cyber professionals.
And yet sometimes it is often ignored.
And that introduces that human error which again makes up for our vulnerabilities that we see within
most networks.