>> Course recap. The learning objective
for this lesson is to review key course components.
Let's get started. You made it to the end of the course.
What I want to do in this lesson is help reinforce
a lot of the items that we went
through in the entire course,
but these are going to be
key things for you to remember for the exam.
We're going to start off with risk.
Because in cybersecurity, everything starts with risk.
We can't formulate a response
if we don t know what our risk is.
The definition of risk for the exam purpose is,
risk is a measure of the impact and
the likelihood that a threat
will exploit a vulnerability.
The key components are highlighted in pink.
Likelihood is how realistic is the threat to occur,
is it highly likely or is it less likely?
Impact is if the risk were to happen,
how bad would it be for the organization?
Are we talking about loss of money?
Are we talking about loss of reputation,
loss of customers? That type of thing.
Then when we're measuring risk,
we have two types of analysis.
These are the quantitative and the qualitative.
Quantitative always uses numbers.
If you have a question on the test and it's asking you to
calculate something based on a number for risk,
then you know that's a quantitative analysis,
if it's asking you to use
words that you know it's a qualitative.
For quantitative, we have some terms and some formulas.
Our single loss expectancy is the cost of a single event.
How much did this one event cost us?
Annual loss expectancy is we take all the SLEs that
happened in one year for
this one device and add them together,
it's an annual cost.
Then our annual rate of occurrence is
how many times did it happen?
How many times did this one device
fail or did this one event happen?
If we want to calculate our annual loss expectancy,
we multiply the single loss expectancy times
the annual rate of occurrence.
You need to remember this formula,
it's going to be important.
Asset value is simply how much is this asset worth?
The exposure factor is what portion calculated in
a percent of the asset would be
lost if the risk were to happen?
The example we gave was if we're concerned
about natural disasters and
our building were to be hit by a natural disaster,
do we expect to lose
the whole building or a portion of the building?
Those type of things go into our calculations when
we're defining our risks and also our responses to it.
Keep in mind this other formula for
calculating your single loss expectancy,
it's the asset value times the exposure factor.
We also have our meantime to recovery.
This is the time that it takes us to get
a device back up and running once it fails.
Our meantime between failure is the amount of
time that transpires between two failures.
With risk responses, we have several ways of responding
to the different types of
risks that an organization might face.
The first is to avoid,
this is simply stop doing
whatever it is that's causing the risk.
We can also accept it,
which is where we determine that
the cost of preventing the risk or
the measures we have to put in
place to mitigate the risk,
cost us more than the damage would
actually cost us if it were to happen.
We can mitigate the risk
by using controls that will help us
lower our exposure and lower
the chances that the risk will occur.
Finally, we can transfer.
Typically when you're talking about transferring risk,
you're talking about insurance.
I also want to talk about the risk as it comes into
the different models of cloud operations.
For our software as a service,
the entire model is managed by the provider,
so all the risk is with them.
But as we move over to a Platform as a Service,
then you start to see that the abs and
the operating system are now under our control,
so that portion of the risks now is shifted to us.
Then we also have Infrastructure
as a Service where the platform,
the app, and the operating system
are now under our control.
More of the risk has shifted to us with this.
With a third party, with, for example,
the Software as a Service,
they assume all of the risk.
We also have regulations that
impact us with risks and also with our responses,
what we're required to do to mitigate certain risks.
We're going to start off with the General Data
Protection Regulation or the GDPR.
The key thing to remember, this is
the EU's data privacy standard.
We also have the Capability Maturity
Model Integration, or CMMI.
This is the Department of
Defense Standard that it uses for
vendors for ensuring they have
mature cybersecurity models in place.
We also have
the Children's Online Privacy Protection Act,
or COPPA, which is a U.S. federal
law designed to protect children.
We also have the Payment Card
Industry Data Security Standard,
PCIDSS.
The key to remember about this,
that is not a governmental regulation,
this is the payment card industry has created their own,
that anyone that processes credit cards has to follow,
and it's designed to protect payer information,
but also to help reduce credit card fraud.
Then lastly, we have
the Health Insurance Portability
and Accountability Act, or HIPAA.
This is the U.S. federal healthcare privacy law.
Let's talk about PKI.
What I want you to remember about PKI is that
the public key and a private key or a matched pair.
We can give our public keys away freely,
but we have to keep our private key secure.
The keys can be used to digitally
sign messages or files, and when we do this,
we are proving authenticity or ownership,
which also allows us for non-repudiation.
We can't deny that this is ours or that we
signed it because it's using our key to do it.
But we can also encrypt messages to
others by using their public key.
The problem this solves is it makes it easy for us
to give away our public key
and get other people's public keys,
and then send secure messages back-and-forth.
Because now we're not having to worry about
sending passwords for decrypting messages,
PKI really solves this.
Certificate authority is the entity
that issues and guarantees certificates.
A digital certificate is a public assertion of identity,
but it's validated by a certificate authority.
When a digital certificate is issued,
the certificate authority guarantees
that this one is who they say they are.
A wildcard certificate allows us to use
subdomains instead of just, for example,
domain.com and a certificate,
we could also use chat.domain.com
or mail.domain.com with one certificate.
That's the purpose of a wildcard certificate.
The certificate revocation list is
a list of all the certificates that have been revoked.
That way we're not going to be
using that to encrypt something or to
send something to someone else
using their certificate because we
have query the revocation list in
making sure that we're not using those.
A certificate signing request is when
we want to request a certificate
from a certificate authority,
we use a CSR for that.
Hardening. The basic definition of
hardening is to remove any unnecessary services,
software, and protocols from a device.
If you remove those and you're lowering
your exposure factor, and that's what we want to do.
We want to make sure that we are
lowering all possibilities of
exposure by removing anything that's not
absolutely necessary for this device to operate.
Hatching refers to installing vendor supplied updates,
and this will plug any holes, fix any bugs.
This is very critical because
bugs are constantly being found,
vulnerabilities are being found,
and we want to make sure we're
patching those as soon as we can.
Disk encryption encrypts the data,
and this is especially useful on mobile devices.
I also want to go over BIOS versus UEFI.
Keep in mind that bios is typically older,
UEFI is the newer version,
and we also have TPM or Trusted Platform Module.
This is a chip that's embedded on the motherboard of
devices that allows it to store keys for us.
Then we also want to use host-based firewalls,
block lists for apps,
host-based intrusion detection systems,
host-based intrusion prevention systems.
We want to make sure that when we're looking at these,
we are putting the appropriate level of controls
with these hardening steps
on the appropriate level of device.
For example, you might
want to use a block lists for apps so
that certain users are not allowed to use certain apps,
you may also want to use time restrictions for
things so that they can't use apps after hours,
and you want to make sure
that host-based firewalls are being used to
allow for only the necessary traffic
to come into a particular device,
all of these are involved in
the hardening process of a given device.
Now we're going to talk about the forensics process.
We begin with identification,
then we go collection,
then analysis, and then reporting and presentation.
It's very important that when we're
doing this entire process,
we remember the chain of custody,
because this allows us to do evidence preservation.
We have to make sure that any evidence that is
collected is identified properly,
labeled properly, and then stored
properly all the way through,
because if at any point it's outside of control,
then that can become tainted evidence
and then it can be thrown out,
or not allowed to be used in a prosecution
or in any type of proceedings against someone.
Incident response.
The first step is preparation.
This includes hardening our systems,
creating different policies and
procedures that we need for the organization.
Then we want to create our incident response procedure.
We do this ahead of time.
We don't want to do it as the incidents
happening because those are high stress times and we
want to be able to go and
pull out a document and follow that
step-by-step to make sure
that we're doing the things that are necessary.
Detection analysis is when we
decide if an incident has occurred,
and then if we have determined this is an incident,
how serious is it,
and then at this time we also notify the stakeholders.
Containment is simply limiting the scope of the breach,
we want to make sure that it's not
spreading throughout the organization.
Then once we have contained it,
we'll begin our eradication and recovery.
This is where we remove the cause of the breach and start
getting things back up to
running normal like they were before.
Then after everything is said and done,
we'll have our post-incident activity.
This is also your after-action review,
where we define what can we improve,
what did we do well,
what did we do not so well?
We want to document our lessons learned here.
Vulnerabilities. I'm going to go over this quickly,
because if you really want to get more information,
just go back to the particular lesson for this,
because there's a lot of details there.
But I want to have these terms in front of you,
so that you remember at
a high level what all of these are.
SQL injection is manipulating the SQL language to inject
data into a database to either
get it to send us data that it shouldn't,
or for us to put data that shouldn't be there.
LDAP injection manipulates LDAP strings to do similar so
that we can inject things in or actually
pull information back out of an LDAP directory.
Cross-site request forgery is when
the victim unintentionally
makes changes to their accounts,
and then because of that,
they're giving access to the attacker to their account.
Cross-site scripting manipulates the file paths
to control how a web app operates.
Finally, directory traversal is
accessing the directories outside of the web route.
The attacker should not have
access to this, but by doing that,
they're able to get in into
the operating system directories and then they
can copy data down or move
tools up and then further compromise the server.
Authentication. We always want to use
strong complex passwords for
everything. The stronger the better.
I mentioned a good technique is to choose
three or four random words and put those together
because that is a very difficult concept
for brute force attackers to crack.
But we always want to use strong passwords everywhere.
One of the things I want to mention here is
we don't want to reuse passwords.
You don't want to have the same administrator password in
all your servers, it becomes cumbersome.
But if one of those will ever be compromised,
it's easy for an attacker to pivot to
the other servers using the same password.
Federation is when we are trusting
the accounts that are from another organization.
They can access resources from us,
we can access resources from them by using
this shared model of federation.
OpenID, it has authentication to the OAuth 2.0 protocol.
Security Assertion Markup Language or SAML,
I want you to go back and review
that if you don't remember about that.
Then shibboleth is based on SAML and it's
often used by universities
and public service organizations.
Access control methods.
Discretionary access control is where
the owner decides who has access.
Active Directory is a good example of this.
Keep that in mind that this is easy to manage,
but it's very difficult to secure because it's
the owner of the resource decides
who gets to access it and who doesn't.
Mandatory access control is based on
clearance levels and it uses labels.
It is considered non-discretionary,
so if you see a question that's
asking about clearance levels and labels,
you know that that's mandatory access control.
Rule-based access control is
DAC when we're adding on the subjects roles.
For example, we may have a department
for human resources and one for finance,
and they may have different levels of
access based on those roles.
Attribute-based access control is when we're using
the subjects attributes and it uses XACML.
Rule-based access control is when the policies are
a system defined rules.
Let's summarize. We recapped risk,
we also went over PKI,
we discussed hardening and vulnerabilities,
we went over the forensics process,
and then incident response,
and we also discussed authentication and authorization.
Hope this lesson was helpful for
you, and I'll see you in the next one.