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 A I bot for Twitter and
in less than 24 hours because of human interaction and manipulation,
the A I bot became racist, sexist and hateful,
not to mention spiteful and Microsoft was forced to remove the A I from Twitter, MS L.
Not only did it point out the complexities of the human mind,
but it also pointed out how we can manipulate
A I and 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 gonna 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,
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 reutilize 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 janitor down the
street doesn't have access to the data as well.
Finally, we want to patch our system, 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 is 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 a back.
This is where we take different attributes of the user
to identify whether or not they're liable to have access.
When you want to use la privilege.
We discussed in the previous slide we want to test and
whether 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 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,
which is this session alone,
we're not gonna allow you to do a replay attack
and gain access to the specific uh information again,
using a different session.
Again, we want to patch,
we want to provide web application firewalls which
are specific input validation or web based.
And then we want to do
Bola and of course BFL A when we talk about those access controls,
we want to use business object level
authorization or Bola to utilize restrict access,
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 BFL A to ensure users
can only perform actions appropriate to their current role.
If I have an IT department filled with 30 different employees.
And one it person is delegated to specific servers and 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 uh authorizations appropriately,
cryptographic failures to note 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 a 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 secure out.
Am I using an algorithm that is compiling the encryption
in such a way that it's not easily reversed?
For instance, de
is an old encryption algorithm that we no longer use.
But if you are using de 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 1234 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 link.
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 multifactor 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
series
this provided a unique law or vulnerability within the M FA 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 isn't properly 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 life cycle.
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 a life cycle of security,
security needs to be involved from the get go.
We need to provide the secure coding practices and the secure design.
Well, at 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,
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 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 a network,
how am I configuring it to maintain that security level?
If I have a SIEM that's operating with a firewall
and the firewall is feeding logs to the SIEM.
Am I doing it in such a secure manner to where those logs are
being properly secured from point A IE the firewall to the SIEM 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 gets 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
and detect those flailings within our system at the get go
and finally application firewalls.
How am I securing my application properly utilizing
a firewall as a defense in depth measure.
When we talk about security misconfigurations,
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 two or three years,
T Mobile suffered from using hardened
credentials or default credentials in their route
and has provided data breaches because of those credentials,
had their employees followed and forced security policies to change the
credentials of 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 feelings 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 are so
s that we utilize,
how are we operating when we talked about the default credentials?
I guarantee there was an so
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? Am I prepping for it
or am I just going to throw things on my network?
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
to make sure that we have the authorization, we have the proper process,
we have to 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.