Professor Messer’s CompTIA SY0-601 Security+ Training Course

How to Pass Your SY0-601 CompTIA Security+ Exam

Are you planning to take your SY0-601 CompTIA Security+ exam? In this video, you’ll learn how to
prepare and which resources will give you the best chance for success.

Configuration Management – SY0-601 CompTIA Security+ : 2.1

Documentation and configuration management can be a life saver when things go wrong. In this video,
you’ll learn about network diagrams, baseline configurations, standard naming conventions, and more.

One of the challenges with information technology is keeping up with all of the changes that are
constantly occurring with your configurations. For example, you’re going to have new operating
systems, patches to those operating systems, upgrades to applications, modifications to the network.
And new applications are going to be installed all the time.

One of the primary goals for the information technology team is to document all of these updates and
changes so that you have a way to look at where the configurations are for all of these systems.
Whenever there are changes to the application, you have to modify and update the documentation that
you’ve created for that application. With good documentation, you should be able to rebuild the entire
application instance from the very beginning by only referring to the information you have in your
documentation.

Part of the documentation you’ll create will be the network diagram. It’s important to know what
devices are connected to other devices. And it’s also important to know where these devices may be
physically located in the network. This might involve a map that shows what devices are connected to
each other.

Or if you really want to get down to exact physical location, you could create a diagram of exactly what
happens to be in a particular rack. And if you want to get detailed about where things may be
connected, you may also want to include information about patch cables and patch panel locations so
that you can identify and track exactly the path the wire takes from beginning to end.

In a data center, you can have equipment spread across many different racks. And they’re all connected
to each other with wires that go under the floor. Make it very difficult to see when you’re looking at all
of these systems. In this data center, someone has even documented what’s in an individual rack. You
can see there is a picture diagram of the rack that has been created. And they have documentation
there that explains exactly what’s on the inside of that particular rack.

Not only do we need to understand more about the way the network is designed, we also have to
document the way the application is designed. So we’ll want to create a baseline of this application and
understand the firewall settings, what patch levels are configured for the operating system and the
application itself, what operating system version is in use to have this application work properly. And
you may, of course, need to update this documentation any time any one of those components is
updated.
To see if you’ve done all of this documentation properly, you’ll want to occasionally perform an integrity
measurements check to see if all of the details in your documentation match what is running in that
particular application. You should be able to check against these well-established baselines that you
originally created. If you do happen to find a deviation from the previous baseline that was created, you
need to understand exactly what the deviation is and what you may need to do to correct that.

It’s also good to have a standardized naming and numbering format for the devices and cables in your
environment. That way, you can refer to those in a document or change control meeting. And everyone
understands exactly where that equipment is located. This means that you can give a task to someone in
a data center, and they’ll know exactly what rack to go to because you provided an exact asset tag, the
name of the computer, a location, and perhaps even a serial number.

For network equipment, it’s good to have switches and routers that are clearly labeled and interface
names and patch panel numbers on each one of those. It’s also a good idea to have a standardization for
the usernames that are used in your environment and the email addresses that will be used in your
email servers.

If we look at this picture of a data center again, you can see they’ve done extensive documentation.
Each aisle has a letter associated with it. And each rack itself is labeled so that someone can cross-
reference from information that’s provided to them in other documentation.

On the network interface or distribution panel side, you can find exactly what module is in use and the
port numbers associated with those modules. And if we look at devices that are in the rack, we might
find labels that are attached to those devices. Or in this case, there are tags that are physically attached
to the devices with barcodes.

There might also be standardization for IP addressing in your organization so that you know exactly what
addresses are used at which locations. This might allow you to create a standardization for the number
of subnets that would be associated with a particular IP address range and the number of hosts that
would be on that subnet, and then you might assign different IP ranges to different networks or
different locations. And those locations can then subnet from there.

Some organizations will also reserve certain IP addresses so that on a particular subnet, you know that
the dot 1 address is always the default gateway. Or you might have other reserved addresses for
printers, routers, and other devices that are always going to be found on these subnets.

Protecting Data – SY0-601 CompTIA Security+ : 2.1

There are many different ways to protect our application data. In this video, you’ll learn about data
sovereignty, data masking, encryption, tokenization, and more.

An organization’s data is one of the most important assets they have, so it’s up to you as an IT security
professional to make sure that data is safe. One of the challenges with approaching this problem of
protecting data is that the data is in so many different locations. It could be on a storage drive; it can be
traversing the network or it may be in the memory or CPU of a system.

We also have to think about other technologies that we can combine with this data to protect it. For
example, we can include encryption or set up specific security policies. And of course, we may want to
have different permissions to this data depending on where you work in the organization, which would
be another way to help protect the data.

Our communications to practically every country in the world are available through the internet. So we
have to have rules that determine how data is protected in each of these different territories. This falls
under the category of data sovereignty, where we need to understand the laws associated with data
depending on where that data happens to geographically reside.

Some of the rules around data sovereignty are specific to these locations. For example, the GDPR, which
is the General Data Protection Regulation is a set of rules in the European Union. These rules specify that
if data is collected on EU citizens, that data must be stored in the European Union.

The GDPR regulations are extensive and complex so it’s important that you understand the scope of
those if you’re planning to collect this type of data on your network. And you may find that this is not
the only case where the data you’re collecting has to reside in that same country. There are many other
countries with similar rules, so make sure you understand those if you’re collecting and storing this
information.

Another way to protect data is by masking the data. This is a way to obfuscate data that makes it more
difficult to read. Data masking can look like this bank card number on the receipt where most of the
bank card has been masked out by asterisks. The only thing you would be able to read are the last four
digits of the number. We can, of course, use this data masking with any type of information so this might
help protect personal identification information or PII, and any other sensitive data as well.

As we see this information stored on something like a receipt, we see these asterisks. But the data
itself– including the full credit card number– may be stored on other servers within the organization. It’s
just that we don’t have rights to be able to see that number so any time we would print it or create a
receipt, the number is masked automatically.

There’s many different techniques you might see used for masking this type of information. It might be
encrypting some of the data. It might be moving the numbers around so they’re not in the same order,
or it may be substituting with different information completely.

Another way to protect data is by encrypting that information. Whenever we have the original
information that we’re planning to encrypt, we refer to that as text and the information that we created
after the encryption process is ciphertext. This encryption process allows us to go back and forth
between text and ciphertext as long as we have the proper key and the proper process for encrypting
and decrypting that data.

One of the important characteristics of data encryption is the concept of confusion. Confusion means
that the information that we are encrypting and putting into the ciphertext is very different than what
we originally started with the plaintext. Let’s take for example, a very simple bit of plaintext, Hello,
world. And I’m going to encrypt that phrase into a PGP-encrypted message.

This is the message that I created that was encrypted from the original plaintext, Hello, world. You can
see that the original plaintext and the resulting ciphertext, are dramatically different. And so this would
qualify as having confusion as part of the encryption mechanism.
 Another important characteristic of data encryption is the concept of diffusion. Diffusion means that if
you change one piece of information in the plaintext, that the resulting ciphertext is going to be
dramatically different between these different versions. For example, let’s take that original Hello, world
plaintext and the PGP-encrypted ciphertext.

Let’s change this Hello, world plaintext to be Hello, world with an exclamation mark. You will see that
the resulting ciphertext only has a similarity at the very beginning, which is the PGP header. And
everything else in this particular encrypted message is dramatically different than the one that was with
the original ciphertext. All we changed was one character in the plane text, but thanks to diffusion we’re
able to get a very different result with our ciphertext.

If you’re protecting data you need to know where this data is located. And if you have this data on a
storage device, we refer to this as being data at rest. So this could be a hard drive, an SSD, NMVME, M.2
drive. It doesn’t matter where we’re storing it, as long as it’s in a file that’s on that storage device, it’s
data at rest. To be able to protect data at rest, then we need to encrypt the data on the drive.

So this might include whole disk encryption. It might include encryption built into the database. Or we
might individually encrypt files or folders in that storage device. We might also want to assign
permissions to the data that’s stored in this drive. So we might have a particular file or folder that’s only
accessible by certain users or certain groups of users.

Data that’s moving across the network is referred to as data in transit. You might hear this also referred
to as data in motion. This means that we have data that’s going between switch interfaces, router
connections, and the devices that are on the network themselves. There are many different types of
devices sending this information back and forth and every step along the way, we have some data that’s
in motion.

We will often allow or permit access to this data using a firewall or intrusion prevention system. And of
course, we might encrypt the data as it’s going through the network. Which means no one would be
able to view that information and understand anything going by, because it’s being sent in the
ciphertext form.

If you’re using TLS, which is transport layer security the newer name of SSL, or IPsec which is internet
protocol security, then you are encrypting this data as it’s in transit. And if we have this data that’s in the
memory of our systems, we consider that to be data in use. This would be data that’s in our system
RAM, our CPU registers, or the caches that are on our system.

This data is almost always provided in a decrypted or plaintext view. That’s because it’s much easier to
perform calculations and be able to read this information if it’s not encrypted. And because this data is
in memory and not in an encrypted form, it becomes a very useful place for attackers to focus their
efforts to be able to gather this data.

An example of attackers going after this data in use, was with the Target network in November of 2013.
Over 100 million credit card numbers were stolen, because the attackers put malware on every single
checkout register. So even though we were sending information across the network in encrypted form,
the attackers were focusing on the credit card numbers that were in the memory of those checkout
registers and they were able to look at the data in use on every point-of-sale terminal.
 Another way to protect data is to show a completely different data than what was originally there. We
call this tokenization. And it’s when we take sensitive data and replace it with a completely different set
of data. Here’s an example of tokenization that is a Social Security number 266-12-1112. Instead of
storing that information in our database as that Social Security number, we’ll now store it as a
completely different number.

If someone does gain access to this information and tries to use that as a Social Security number, they’ll
find out very quickly that that number is not valid. This is very commonly used with credit card
transactions. If you’re paying for something with your phone or your watch, it is using tokenization to
transmit a token of your credit card information and not your credit card number directly.

This is not a hashing mechanism and we’re not encrypting the data either. We’re simply replacing one
set of numbers or characters with another set of numbers or characters. There’s no additional
encryption or computational overhead on any device using this tokenization. Here’s how this
tokenization process starts.

It begins with the phone that we’re using where we register our credit card on our mobile phone. And
we have a credit card number with four and a bunch of ones and 1 2 3 4 at the bottom. Once we register
that with the token service server, it provides us with a token instead of a credit card number and that
token is stored on our mobile device.

We’ll now take our phone or our watch to the store and we’ll pay for everything at checkout using near
field communication. That is going to communicate to the merchants payment server, which will then
communicate back to the tokens service server to check the token that we provided during the checkout
process. That will confirm that that is a valid token for a valid credit card number, and it informs the
merchant that that particular token is valid and that transaction is approved.

If you’ve ever worked with a Microsoft Office document that didn’t allow you to modify parts of the
page, or you worked with a PDF that wouldn’t allow you to copy or paste, then you’ve seen information
rights management or IRM. IRM is used to prevent certain things from occurring within document. For
example, you can prevent copying and pasting, controlling screenshots, managing the printing process,
or restricting people from making changes to the document itself. The goal with IRM is to limit the scope
of what people can do with this document. So if an attacker does gain access to someone’s workstation,
they would only be able to manipulate that document from the perspective of that user’s rights and
permissions.

Data Loss Prevention – SY0-601 CompTIA Security+ : 2.1

Data loss prevention can help protect sensitive data from unauthorized use. In this video, you’ll learn
about DLP, USB blocking, cloud-based DLP, and DLP in email systems.

We maintain and collect a lot of different types of data on our networks. We could keep social security
numbers, credit card numbers, health care information, and other sensitive data that we must protect. If
attackers focus on our network, they’ll want to have access to this sensitive information.

There are so many places to obtain and store this information on our network. So we need intelligent
systems called Data Loss Prevention, or DLP, that’s able to look in many different locations and protect
our data from prying eyes. An endpoint DLP solution would reside on our local workstations and devices.
And they’re examining everything that is being transferred into or out of our device.

We can also have DLP technologies on our network that’s examining all of the packets going across the
network and making sure that no sensitive information is stored in the network traffic. And to look at
data at rest on our servers, we may want to have a DLP system that is running on the servers
themselves. In some cases, DLP is designed to block access to different types of hardware. For example,
DLP on a workstation would be able to allow or disallow access to data that’s being stored on a USB-
connected drive.

An example of how important it is to have DLP associated with these USB flash drives occurred in
November of 2008 with the US Department of Defense, where suddenly, a worm was able to move
throughout the network because it was replicating itself using USB storage. The US Department of
Defense immediately banned the use of USB-connected media devices and blocked all of those devices
from working on their network. Every device on the US DoD network had to be updated to be sure that
this DLP solution was in place. They finally lifted the ban in February of 2010 and put in much stricter
rules on how these flash drives were able to be used.

We’ve talked about our devices, and our networks, and our servers. But what about devices that are
stored outside of our organization in the cloud? Well, of course, there’s cloud-based data loss
prevention technologies as well.

This type of DLP also lives in the cloud. And it’s able to look for all of the traffic going through to see if
any particular predefined data strings exist within those data flows. This cloud-based DLP could also
block data from going to certain URLs to prevent people from storing that data on an insecure cloud-
based storage system. This could also block viruses, and malware, and anything else that might traverse
the network.

The ability to send and receive emails also makes it very easy to transfer sensitive information into and
out of your network. To be able to prevent this, we need to have data loss prevention on our email
systems. This will look at both inbound and outbound emails and block any information that is
categorized as sensitive.

Inbound emails can be filtered with this DLP using keywords or by identifying emails that are coming
from imposters. These emails are then quarantined and can be examined by an email administrator to
validate whether this is legitimately a DLP filtering function or if it may be a false positive. A good
example of outbound DLP filtering might be to block anything that looks like a wire transfer– maybe
somebody trying to transfer W-2 information or anything related to employees’ personal information.

A good example of how important it is to have DLP in our email systems occurred in November of 2016.
An employee at the Boeing organization e-mailed their spouse a spreadsheet that they would then be
able to use as a template for a different project. Unfortunately, hidden in that template spreadsheet
was the personal information of 36,000 Boeing employees. And by sending this information to his wife
over nonsecure channels into their own personal email, he had now transferred out social security
numbers, dates of birth, and much more information as well.
Ironically, Boeing does sell their own version of a DLP software. But it wasn’t in use in this particular case
because it’s only used on classified networks. This is just another example of how important DLP is,
whether it’s on your servers, your network, or your email system.

Managing Security – SY0-601 CompTIA Security+ : 2.1

There are various security requirements that need to be considered when managing an organization’s
data. In this video, you’ll learn about geographical considerations, SSL inspection, hashing, and API
security considerations.

We often think of our technology being in the cloud, or being at a data center, but we really do have to
think about where this technology is located and how that has an effect on how we secure the
applications and the data. From a legal perspective, we have to understand how security is affected by
this difference in location. Whether we’re doing business across state lines or international business. We
also have to think about if we need to get to another country for recovery, for maintenance, or for
anything else we need to do. There are additional legal concerns.

Your passport for example is an important legal document that we use when we’re traveling to another
country. All of the personnel that are associated with performing functions relating to that business
process would probably need to have a passport and have that process already taken care of before you
need to be able to use it.

Every business has some type of legal representation, whether it’s someone who’s internal to the
company or a third party that you’re contracting with, and they should be always involved in the
legalities of how you’re managing and controlling the data and systems in your network. Some of these
same geographical considerations apply for our backups. Where are your backups stored? Are your
backups stored on site, or off site, and if they are stored off site what type of access and control do you
have over that data? Perhaps even more importantly, what type of access and control does a third party
have over the data at the location where that information is stored.

And these geographical considerations become important if we need to declare a disaster and we need
to bring up a new data center at a remote location. We need to make sure we have a way to get people
to that remote location and we have to make sure that the data and processes we’re managing at that
location fall under the legalities for that particular geography. It’s also important that we manage the
recovery process if we need to respond to an attack. This has become a commonplace issue across all
organizations and we need to have a formal process in place so everyone knows what the next steps will
be.

Before any type of response to attack, or recovery to attack, we need to document the entire process
from beginning to end. This is probably going to be the most time consuming part of this entire process
but it’s one of the most important parts as well. We need to have documented processes that help us
understand and identify when an attack is occurring, and we need to make sure that if an attack is
identified, that we’re able to contain it and limit the scope of that attack.

If we’ve identified an attack then we obviously can’t prevent it from occurring, but we can prevent it
from gaining access to information that could be more damaging. For example we need to make sure
that we’re able to limit how people are able to get data out of our network. That exfiltration process is
 important to the attacker, because they’re able to move that data out of your network and into their
secure facility.

We also want to be sure that if an attacker does get onto our network, that they are limited in the type
and amount of data they have access to. So if there is any sensitive data, we want to be sure that we
store it or maintain security to that data so that an attacker would not have access to that sensitive
information.

We often talk about the need to secure data as we are sending it across our network and if we’re in a
browser connecting to a third party site, we often refer to SSL, or what is now referred to as TLS, to be
able to encrypt that data. SSL is Secure Sockets Layer, and TLS is the newer Transport Layer Security that
effectively replaced SSL. It would actually be unusual to find anyone using SSL because it is much older
and should have been replaced by now by TLS, but we often refer to this pair of protocols as SSL even
though most of the time we really are referring to TLS.

One of the challenges for the security professional is that there may be information within this
encrypted data that could be malicious and something that we may want to block from coming into, or
out of our network. Unfortunately, all of the data is encrypted and if it’s encrypted we have no idea
what’s inside of that SSL encrypted information. There are ways though that we can perform SSL or TLS
inspection where we can view the information within this encrypted data to be able to determine if
there’s anything malicious inside.

Now obviously, this is not something that can be done very easily and it has to be something that has
been specially configured on your computer to be able to perform this SSL inspection. But this is a very
useful tool for security professionals and you’ll find that many organizations will perform SSL inspection
to be able to maintain the security of their data.

The ability to perform this SSL inspection is all based on trust. Your browser trusts the device that it’s
connecting to across the network and is able to perform the encryption from end-to-end. What we’re
able to do with SSL inspection is put ourself in the middle of the conversation, but continue to have the
trust both on the client side and the server side. This trust inside of your browser comes from a list of
certificate authorities that is embedded and inside of your browser on your device.

If I was to look at the number of certificate authorities that were trusted by my browser, I would see
over 170 different certificates that my browser trusts any time they see a site that has been signed by
any of those certs. This means for every site you go on the internet, there has to be some interaction
with a trusted certificate authority. That trusted certificate authority has to sign the certificate for that
web server, and that is the certificate the web servers providing to you.

You are doing the verification and checking the signature to make sure that the signature on the website
matches the signature that would come from one of these certificate authorities, and that is the trust
we talk about when we refer to encryption and using SSL. Since we’re simply performing a check to see
if this has been signed, we are also trusting that the certificate authority has done their job to make sure
the site that they are giving the certificate to is a site that is legitimate.

So they’ve done some checks to make sure that they’re sending the certificate to a trusted email
address, they might have made phone calls or performed additional verifications, and only after doing
those checks do they sign the web server certificate that you’re seeing when you visit that site. Each
time you visit one of these locations, your browser looks at the certificate on that web server, it looks at
the signature, and then it checks from its list of over 170 trusted CA certificates, to see if that signature
is matched by any one of those. And if that matches, your browser encrypts the information and
continues to work normally. If something doesn’t match up, there will be an error message on the
screen and a notification that there’s some type of certificate error.

So how can we get into the middle of this conversation and look into the nonencrypted data, even
though both the server and the client are sending encrypted information from those devices. The way
that you do it, is you first have to have a device in the middle of the conversation, this is often a firewall
or some type of SSL decryption device that is specifically designed to provide this proxy functionality.
Inside of this device, we’re going to add our own internal certificate authority. This would be one that
we create just for use internally within our organization and it would not be used for anything that
might be outward facing.

We would then add our internal CA certificate to every user’s device on the network. This means that
we become another one of those 170 plus trusted CAs that is listed in a browser. And we’ve done it for
every browser, on every device, on our internal network. Now that our internal devices trust our
internal CA just as much as they trust an external CA, we can begin the process of communicating
securely between a user and a server.

The first thing that will happen when a user tries to communicate using this encryption, is there will be a
hello message sent to the server. So in this case, the user is sending the Hello to professormesser.com.
That Hello message is intercepted by our SSL decryption device and instead of sending that Hello
message to prof Mr. dotcom that device is going to create a message as a proxy and send that message
to professormesser.com. The Professor Messer web server is now going to respond back with
information about its web server certificate that has been signed by a public CA. This SSL decryption
device will check that certificate and make sure that everything in that certificate is valid. If it is, it will
create a new certificate for use on the inside of the network. So we’re effectively decrypting traffic so
that we can look into the data and then reencrypting it with our own internal communication process
and send that to the user. That allows us to sit in the middle of the conversation and everything that’s
going outbound and inbound is able to be decrypted, analyzed, verified, and made sure that nothing
inside that data flow is malicious.

One of the things you probably noticed in this course is that we use hashing for so many different things.
Hashing is used during encryption, digital signatures, and other processes for cryptography. The hashing
process itself is simply taking an amount of data and representing it as a short string of text information.
We often refer to that short string as a message digest. This hashing process is a one way trip, unlike
encryption where we can encrypt data and then decrypt data to be able to receive the original plain
text, you can’t do that with hashing.

Once you hash the data and create that message digest there’s no way to undo that process to
somehow get the original data that we started with. This is why we use the hashing function for
passwords so that no one would be able to look at our hashed information and somehow be able to
discern what the original password might have been. If you’ve ever downloaded documents or an
application from the internet, you’ve noticed they put a hash next to that download. It’s there to make
sure that you can provide integrity once you receive a copy of that download. You can perform your
own hashing function and compare it to the hash that was posted on the public website and make sure
that both of those match. If the hash is the same on both sides, then you know that the document that
you’ve received is exactly the same document that was used to create the original hash.

This hashing is also used for digital signatures, because we are able to use the integrity built into the
hash, to confirm that we’re receiving the same message that was sent. We can confirm that this
message was sent from a particular individual using the authentication features in a digital signature,
and we can also verify that it must have come from a particular person using the non-repudiation
functionality of the digital signature.

One of the most important characteristics of a hash, and one of the reasons we will often retire older
hashes, is that we run into problems with collisions. When you create a hash of a particular value there
should only be one way to get that particular hash, and that’s if you were able to hash that original
value. You should never take two very different messages, hash them, and somehow end up with the
same hash. We call that a collision and it usually indicates that there is some type of cryptographic
vulnerability associated with that hash algorithm.

Let’s take an example of a hash using a good hashing algorithm like SHA256. SHA256 is 256 bits of a
message digest, or what turns out to be 64 hexadecimal characters. Let’s take a simple hash such as the
term, my name is Professor Messer, with a period at the end. If we perform a SHA256 hash of that, we
get this message digest in return. If we perform another hash of some text that’s very similar, except,
my name is Professor Messer, ends in an exclamation mark, we also get a SHA256 hash, but notice that
the hash values are very, very different between the two. Here we’ll put them right next to each other,
and you can see they are dramatically different even though all we really changed was one single
character of the original message. This is why we use this hashing function to provide additional security
for our data, because if only one single character is changed, we get a dramatically different hash and
we know immediately that we should not trust the information that we’ve received.

With the advent of mobile devices and cloud based technologies, we’re taking more and more
advantage of APIs, or Application Programming Interfaces. Not only are we communicating and
controlling applications with these APIs, but we also have to put security methods in place to be able to
protect the data that is being sent and received from these API calls. This means that there could be
multiple places to perform functionality. There could be interactive users that are logging in to a login
page, and of course, we have to make sure that that process is secure. But there may also be an
application or a mobile app that is accessing or logging into the system, not using the login page but
using the application programming interface. Although the functionality is very similar, which is logging
into the app, the method that’s used to perform that log in is very different between a login page and
the API. So we have to make sure that we are managing the security, not only for our interactive users,
but also for API based applications.

One method used by attackers to be able to intercept and perhaps even change this API information, is
an on-path attack. This is when the attacker sits in the middle of the conversation and is able to view all
of the traffic going back and forth, and in many cases modify or replay some of the traffic it has seen in
these API calls. This means that an attacker can sit in the middle of the conversation, get an
understanding of the way the API operates, and then put their own data into the API flows.

An attacker might see a bank transfer take place and then create their own API call that might transfer
information into their account. This is called API injection and it’s another concern we have when
 making sure that our API applications are secure. And if an API has not been properly developed or
tested, an attacker may be able to find a vulnerability that wouldn’t be able to use the functionality of
the application, but it might be able to cause the application to fail. This would be a denial of service
attack, and it would then prevent anyone else from gaining access to that application. This is why many
organizations will have additional security for their API based applications, especially as it relates to
authentication.

There will be limited use of the API to only applications or users who are authorized to use it, and you
will only use communication to that API over encrypted protocols. The API should have some security
controls that would limit what the API is able to do based on the user’s rights and permissions. For
example, if a user should only have read only access to data, then those should be the only API calls
accessible by that user. And just as we have a next generation firewall that we might use for our
network traffic, we have a web application firewall that we commonly used for our application traffic. So
if we’re using web based applications or API based applications, we can configure our web application
firewall to monitor and control all of the communication to that particular user’s data.

Site Resiliency – SY0-601 CompTIA Security+ : 2.1

Maintaining uptime and availability during a disaster is often the primary objective of the IT team. In this
video, you’ll learn about hot sites, cold sites, and warm sites.

If you’ve gone through the process of creating a disaster recovery plan, then you know these disasters
can happen at any time. That’s why it’s always important to always have backups, always have the data
synchronized, or be ready to put those plans into action at any moment. If this disaster requires that
your data center physically move to the disaster recovery site, then you’ll need to flip that switch and
move everything over to that alternate location.

You may be in that location for an extended amount of time. This is not going to be a few hours before
things revert back, and sometimes this can take days, weeks, or even months before you’re ever able to
move back to your original data center. That’s why you not only need processes and procedures for
getting up and running at the disaster recovery site, you also need the processes and procedures for
moving back to the original location.

Some disaster recovery locations are what we call hot sites. These are sites that are an exact replica of
what we are running in our production environment. This means that we have duplicate hardware,
duplicate servers, all of the equipment and infrastructure is duplicated. Whenever we purchase
something for our production network, we’re often also purchasing something for our disaster recovery
network.

This also means that there needs to be some process in place to keep everything synchronized. Perhaps
everything is updated in real time between these two locations with high-speed network connections so
that your data center and your disaster recovery site are constantly in sync. Or perhaps you’re sending
periodic updates to the disaster recovery site.

For example, you could send updates every hour that provide synchronization between the data that’s
in real time at the data center and the disaster recovery site information. Because these two sites are
designed to be a mirror image, it should be a relatively easy process to flip the switch that moves all of
 the data from the primary location to the disaster recovery site. And when you make that switch,
everything will be ready to go at the DR location.

A cold site is effectively the complete opposite of a hot site. This is effectively a room with a bunch of
racks in it, and it has none of your equipment currently in place, none of your data, and none of your
applications. This means that you’ll need to bring the data with you. Maybe there are backup tapes or
backup drives that are used, and you bring all of that with you to the cold site. There are also no people
at the cold site, so you have to make sure that you bring the personnel that will then be attending to all
of these systems that you will be installing and running at the cold site.

A warm site is somewhere in the middle between a hot site and a cold site. Instead of being immediately
ready to go or having nothing available, it’s usually a location that has racks and some equipment that
you can at least get up and running in a relatively short period of time. They might provide servers or
equipment for the infrastructure, and you would simply bring your configurations to plug in to their
equipment.

The description of exactly what’s included with the warm site is usually part of the disaster recovery
contract. There’s usually a balancing act between the equipment that’s available and how much you
have to pay for that disaster recovery functionality. The more equipment that’s available at a warm site,
the more money that will be required on a monthly or annual basis to maintain that DR location.

Honeypots and Deception – SY0-601 CompTIA Security+ : 2.1

There is a constant battle taking place on your network between the attackers and your defensive front.
In this video, you’ll learn about honeypots, honeynets, fake telemetry, and DNS sinkholes.

A honeypot is a system, or series of systems, that’s designed to look very attractive to an attacker. And
hopefully, the attacker will try to gain access to these fake honeypot systems that are on your network.
The actual attacker is probably not a human being– it’s probably an automated system. But that means
that we can look to see what processes the attackers are using to identify, and then what methods
they’re using during their attack of, these types of systems.

The honeypot is effectively a virtual world so that the attacker would be trying to gain access to a fake
system and not to your actual production data. There’s many different kinds of honeypot software that
you could install on your network. You could use Kippo, Google Hack Honeypot, or Wordpot, for
example.

And with the software you’d install, it is a constant battle to make sure that the software you’re using is
something that can accurately represent real data and real systems. The attackers have systems in place
to perform checks to make sure that the systems they’re attacking are real and not honeypots. Your
honeypot software has to be able to look and feel like a real system so that an attacker will attempt the
exploits against that honeypot.

Once you start adding more honeypots to your network, you’ve created a honeynet. This is multiple
honeypots where you can begin gathering information from multiple sources. You may find that an
attacker starts on one server and goes to others. Or you may find that multiple attackers arrive at one
time performing different functions on different honeypots. A good example of a honeynet and a system
 that’s in place to be able to share the information that is found in these honeynets can be found at
projecthoneypot.org.

Inside of your honeypots and your honeynets, you’re going to put your honeyfiles. This is very attractive
bait that you’re hoping that the attacker will go after. This might be a file name, for instance, called
passwords.txt which is oh so appealing to that attacker. They want to be sure they gain access to that
file.

If that file is accessed by the attacker, you can receive an alert that says that someone must have gained
access to passwords.txt. It’s effectively a way that you can know if someone did try to attack that system
and what type of information they were able to gather.

One of the advantages we have with our modern technology is the ability to gather large amounts of
data, in some cases very diverse data, and be able to analyze that data to try to find things that are
similar or contrasting within those data files. This is machine learning that takes this big data and is able
to identify patterns and information within that very large data source. To be able to have this machine
learning understand what we’re looking for, we need to train it with actual data.

So we’ll feed it with malware, ransomware, viruses, and anything that will show the machine what bad
data, or malicious data, might look like. The machine learning programming will then get an
understanding of the type of data it should be looking for and how it may be able to identify this
malware from the way that it operates rather than from a specific signature. The attackers know that
you’re using this type of example to be able to train the machine.

So they’ll add their own fake telemetry into this data to try to get the machine to think that the malware
is actually something good. This means that they can send this fake telemetry into the machine. And
once the training is over, they can then send their malicious software through, and the machine will not
be able to identify it.

Another useful tool for a security professional is a DNS sinkhole. The DNS, of course, is the domain name
service that is handing out IP addresses that are associated with fully qualified domain names or FQDNs.
It’s very common for a client with an FQDN to be able to ask a DNS server for the proper IP address so
that it can then communicate directly with that service.

A DNS sinkhole, however, performs the opposite of this process. When the client requests the IP address
of a particular FQDN, this device gives a response back with incorrect or invalid information about that
service. This can be bad if an attacker is implementing a DNS sinkhole, because they may be able to
redirect users to a specific location or may create a denial of service where no one is able to
communicate to the proper service.

This is more commonly used, however, to provide intelligence for the security professional. We know
that there are certain sites that a user will visit if they happen to be infected with a type of malware. So
instead of allowing that user to communicate to that external server, we’ll instead configure a DNS
sinkhole. And if anyone ever requests the IP address of that malicious site, we will provide it with an IP
address of a machine inside of our location that we can then create a report on to determine who might
be infected with this malware in our organization.
This is a function that’s often integrated into an intrusion prevention device or next-generation firewall.
If someone tries to communicate out to one of these known malicious sites, the DNS sinkhole will send
an IP address that redirects them to a known good site.

And this also will create an alert, or an alarm, so that the security team within the organization will know
that a particular device is infected with this malware. This means that the device with the infection will
not be able to communicate out to the command and control. And it also means that your security team
can clean those devices before that infection spreads.

Cloud Models – SY0-601 CompTIA Security+ : 2.2

A cloud-based infrastructure can take many different forms. In this video, you’ll learn about IaaS, SaaS,
PaaS, cloud deployment models, and more.

If you’ve contracted with a cloud service provider to outsource your equipment, then you’re probably
using the model of Infrastructure as a Service, or IaaS. You may hear this sometimes referred to as
hardware as a service because that is what this service is, simply providing you with the hardware
required to get your services up and running.

This means a cloud service provider is going to give you a system that has a CPU, there’s storage, there is
networking connectivity, but that’s it. You are still responsible for the operating system and the
application that will run on that particular infrastructure. This means that you’ll be managing the system
from the operating system on up through the application. And that also means that you’ll effectively be
responsible for the data security on that system

Although this data is being stored on this third party cloud hosted device, you still have control over how
that information is stored. So you could encrypt that data, so that no one at the cloud service provider
would be able to look into your private information.

A good example of infrastructure as a service might be a web service provider that gives you a server but
nothing else. You still have to load the operating system and the applications that are running on that
operating system. And then you pay the web service provider a certain amount a month to be able to
have that system running in the cloud.

There are some cloud models that require almost no effort on your part. You don’t have to load an
operating system. You don’t have to configure or write any software. You don’t have to make sure that
the system is constantly updated and patched. This is called Software as a Service, or SaaS.

Software as a Service is on-demand software that you would simply log in to the system and begin to
use. You don’t have to configure the operating system. You don’t have to write the application. And you
don’t have to maintain the application or the data. The third party cloud provider does all of that for
you. You simply log in and use the service there provided. This means that you could use a third party to
provide your email services for your organization, or maybe all of your payroll services are managed
through a software as a service model.

In this model, you usually have data and applications all in the cloud and the third party service provider
is in charge of managing both the applications and the data. With Software as a Service, you’re not
 responsible for application development. You’re not responsible for the maintenance of that
application. You simply log in and use the application as it’s running on that service.

A good example of Software as a Service would be something like Google Mail, where it’s a complete
mail system all ready to go. All you need to do is connect to it and begin sending and receiving email
messages.

There is a cloud model that is a middleground between Infrastructure as a Service and Software as a
Service. This middleground is called Platform as a service, or PaaS. In this model, the cloud service
provider is giving you a platform that you could use to develop your own applications. They would
provide the operating system, the infrastructure underneath, some virtualization services, and would
provide you with the building blocks you need to write your own applications that are customized just
for you.

Like many cloud services, this application development platform is usually hosted with a third party. So
they have access to all of your applications, to your data, and anything else that makes up that particular
application. You can think of this as a service provider giving you the building blocks you need to create
a modular application instead of you having to build or write the programming for that application from
scratch.

If you need a login screen, you can simply take the building block for a login screen and start with that.
Then you might want an inventory screen, you can grab the building block for the inventory screen and
add it to the application. This greatly speeds up the application development process and allows you to
create an application that’s customized for your specific needs.

A good example of this is the Platform as a Service offering available from salesforce.com. They give you
the building blocks and your developers put those building blocks together to create your customized
application.

There is another model of cloud computing that covers everything else and that would be Anything as a
Service. This is often abbreviated XaaS. This would be a broad description of any type of service that is
provided over the cloud. This usually describes a set of services are available on the public cloud rather
than being something in a private cloud in your own data center. And it often describes a pricing model
that allows you to pay for what you’re using instead of paying a large upfront cost or ongoing licensing.
This makes it a little bit more economically feasible for organizations to get started.

The concept between Anything as a Service would be that anything that you’re currently doing in-house
with technology could potentially be outsourced into a cloud based system. This would mean that IT
would be less of an ongoing break/fix organization and more of one that is focused on taking the
technology needed by the organization and applying that into a cloud based service.

If you were managing all of your own services internally in your own data center, this would be an on-
premises type of model and everything from the networking, storage, servers, and virtualization, as well
as the operating systems, middleware, and runtime, running on those systems would all be in-house
along with the data and the applications. All of the technology needed to run this application would be
on systems located on your premises.
 If you wanted to take some of your on-premises and move it into a cloud based Infrastructure as a
Service, you would then take the networking, storage, servers, and virtualization part of this application
and have that hosted in the cloud at a cloud provider. All of the other pieces, the operating system the
middleware, the runtime, the data, and the application itself, would still be your responsibility to
manage.

If you wanted to outsource the entire process to a third party so they managed everything from the
application all the way down, that would be Software as a Service. And of course, the middleground as a
Platform as a Service, where you are responsible for creating and managing the application and the
application’s data but all of the other services associated with that application are provided by the cloud
service provider.

As you can see, these cloud service providers are a huge part of what we’re doing with these cloud
models. And they’re the ones providing us with the ability to perform Infrastructure as a Service,
Platform as a Service, or Software as a Service. Depending on the service, there may simply be a flat fee,
where you pay a certain amount for that particular service every month, or the billing may be based on
how much you use that service. So as more of your clients are using a cloud based application or
transferring data in and out of that application, the costs of using that application may increase.

With these cloud models, you are outsourcing some of this technology but there will still be a need to
have people in your organization that are able to manage different parts of this cloud. For example, you
may have an internal staff that’s responsible for interacting with the cloud based provider. There may be
a development team, especially if you’re using Platform as a Service, and you need to create your own
applications. And there’s probably going to be operational support to make sure that the applications
that you’re hosting in the cloud are working the way you would expect.

Many organizations will interface with a third party called a managed service provider, or an MSP. These
managed service providers handle many aspects of managing technology for their clients. And they
might also be a cloud service provider on top of that. Not all MSPs are cloud service providers, but it’s
not uncommon to see those two types of services combined within a single MSP.

The traditional role of a managed service provider is to provide things like network connectivity
management, make sure that wide area networks and local area networks are up and running, to
provide backups and disaster recovery planning, so that you always know that your data will be safe.
And an MSP can also provide growth management and planning, especially if your organization is one
that’s bringing on more people and you need to be able to grow the infrastructure in the applications to
manage this growth. Many MSPs are working with very large organizations and they understand some of
the challenges with making sure that your systems are able to scale.

There is a niche of MSPs called a managed security service provider, or an MSSP. This would be a
managed service provider that focuses on IT security. So they may manage your firewall, be able to add
and remove rules from the firewall rule-base, they may provide patch management, security audits of
your systems, and they could provide emergency response services, especially as it relates to IT security.

Although cloud based systems can run from anywhere, it’s sometimes useful to differentiate an on-
premises cloud based service from one that is off-premises. An on-premises service, which we
sometimes refer to as on-prem, are services that are running in our local data center. We’d be managing
the electrical and HVAC for that data center and everything’s located within our building in our facility.

If we are running off-prem, or off-premises services, those servers are not located in our building and
very often are located in the building of a third party. It’s common with these hosted and off-premises
services to be running on hardware that’s provided by the cloud hosting provider. And we often find
that this is a specialized data center environment at this cloud provider that has multiple links to the
internet and other types of redundancy built into their data services.

If you hear someone referring to the public cloud, they’re usually referring to a service that is available
on the internet for anyone on the internet to be able to access. It is effectively public to everyone. There
are some organizations that would like to have their own cloud services but they might find it difficult to
implement or it may be too costly to do on their own. In those situations, they may want to use a
community model, where several organizations that have a similar set of goals might pull all of their
resources together to create a shared set of cloud services that all of them can use together.

If a public cloud service is one that is available to everybody on the internet, the private cloud service
would be one that is the opposite. This would be a cloud service that is internal in your own data center
that only you would have access to. And in some situations, an organization can use multiples of these
models. For example, they might have services they’re running in the public cloud that is accessible by
everyone on the internet but there might be some internal services that are only running on their
private cloud. In those situations, we have a hybrid model, which would be a mix between those public
cloud models and the private cloud models.

Edge and Fog Computing – SY0-601 CompTIA Security+ : 2.2

An optimal cloud computing infrastructure will make strategic use of edge computing and fog
computing. In this video, you’ll learn how edge and fog computing are used to create an efficient and
effective cloud computing design.

Cloud computing has changed the way that we approach the deployment of applications and the use of
those applications. It gives us a massive amount of computing power located in the cloud. We have
instantly available access to all of this power, and we can store amazing amounts of data all in this
cloud-based infrastructure.

If you’ve ever managed a cloud-based infrastructure, then you know you can click a button and instantly
deploy new applications. It’s very easy and very fast to have exactly the power you need in the locations
you might need it. The cloud has also changed the costs involved in deploying these new applications.
Instead of creating your own data center and purchasing your own equipment, you can simply buy some
time on a cloud-based service and pay as you go. Although cloud computing provides significant
advantages, there are some disadvantages as well.

For example, the cloud may not be at a location that is near you. There may be some delays in
communicating between your location and the location where these cloud applications are hosted.
There might also be limited bandwidth. Since this is going across a wide area network connection and
it’s not technology that’s located in your facility, there is limited bandwidth between you and the cloud.
It may also be difficult to protect the data that you’re storing in the cloud because it’s often stored in the
format required by the cloud service provider, and it may not allow you to do any type of encryption.
And of course, because these applications are located off-site in the cloud, it requires some type of
connectivity to be able to communicate with those apps. So we would need some type of private
network connection or internet-based connection to be able to use any of those applications.

In recent years, we’ve seen an enormous increase in the number of IoT, or Internet of things devices
that we’re adding onto our networks. It’s not unusual to have climate control alarm systems and lighting
systems all running inside of our homes but also accessible as Internet of things devices on the internet.
This makes it very easy for us to pop open an app on our mobile device and control what the lighting
might be in our house, we can change the temperature of the room, and we can make sure that our
alarm systems are up and running.

A lot of the technology and the data for these devices are occurring on the device themselves. We call
this edge computing or sometimes just abbreviated as edge. This means that the applications that are
running and the decisions being made from the data created by these applications are all occurring on
the local system and don’t have to go out to the internet. Since there would be no requirement to
communicate this data out to the internet, we don’t have to worry about latency or any type of wide
area network or internet connectivity.

That also means that because this is a device that’s running locally in our environment that the speed
and performance of this device should be at the local speed of our network. We should also think about
edge computing from a data perspective. All of those Internet of things devices, your garage door
opener, your washer and dryer, your climate control system, are all collecting data on your network.

These devices use this data to make decisions about how they should operate. For example, a climate
control system can look at the temperature in a room and determine if it should cool or heat the room
based on what the current temperature might be. There is not a need to go out to the internet and
process any data just to make those local decisions on the climate control device.

But there may be times when these Internet of things devices may provide additional functionality by
taking some of that data and moving it into the cloud for processing. There may be also a midpoint,
though, between having the data locally and having the data on one centrally stored cloud-based server.
Instead of consolidating all of this data in the cloud for all devices, we can have a subset of devices
consolidated in the fog. This is fog computing. It’s a distributed cloud architecture that allows us to send
information into the cloud for processing without requiring that all of this data be consolidated in one
single place.

This means that any data that our IoT device needs to make local decisions can stay local on that device.
It doesn’t need to go into the cloud. But we might want to take some of the data created by these
devices and move it into the cloud for additional processing. We can then compare the data that we’re
seeing with data seen by other people and be able to use that to be able to make our devices work more
effectively. From a privacy perspective, this means that we can keep sensitive data on our local network,
and we can only send into the fog the information that we might feel a little more comfortable sharing
with others.
 Here’s a visual perspective of our Internet of things devices, the fog computing, and the cloud
computing that sits above that. For example, let’s look at an Internet of things device such as an
automobile. Inside of our cars, we have over 50 different CPUs that are collecting data across many
different systems. For example, information about our tires can be used by our suspension system and
our braking system to make our cars safer. All of that data is being collected locally and is being acted
upon by devices that are on our edge or local device.

That data doesn’t need to leave the car because we’re using all of that data locally. But there are
circumstances where we might want to send some of that data into the cloud to be able to consolidate
it with what other people may be seeing for the same types of tires or the same types of braking
systems. Instead of sending all of that up into one single consolidated view, we could send that into the
fog. These nodes are going to provide real-time processing of this data, it might optimize or buffer this
information or consolidate it so that it can be used later, and we might want to send this data into the
fog just so that we can then take that data and send it down to another Internet of things device.

Once that data is in the fog, the manufacturer of our car may want to consolidate that into a much
larger database to begin performing some advanced analytics. So the data could be moved from the fog
into a cloud-based data center and consolidate that from everyone who owns the same car that you do.
This multitiered architecture allows us to still get the data we need to perform the analytics that are
important, but it limits the type and the amount of data that would finally be rolled up into our data
center. Having local processing on the edge device and a midpoint in the fog allows us to have a much
more efficient cloud computing experience.

Designing the Cloud – SY0-601 CompTIA Security+ : 2.2

Cloud technologies have added new capabilities to application deployments and modularized
applications. In this video, you’ll learn about virtual machines, application containerization,
microservices, serverless architectures, and more.

The cloud has forever changed how we deploy applications. We can click a button and have access to
amazing amounts of computing power. The cloud also provides elasticity. We can deploy new
application instances to handle the load, and then as that load decreases, we can remove those
instances.

We can also provide access to our applications from anywhere in the world, using these cloud
computing technologies. To provide this functionality, we have to spend a lot of time planning how our
applications will be developed, and how we can deploy them in this cloud-based infrastructure.

One place to start with these cloud technologies is to take all of these systems that would normally run
on our desk and run those systems in the cloud. We’re able to do this by using a thin client.

Instead of having a full-blown computer, we can simply have one, that provides us with just enough
computing power to be able to connect to a desktop that is running in the cloud. You’ll sometimes hear
this referred to as a Virtual Desktop Infrastructure or VDI, or if we are running this in the cloud, it may
be provided through a third-party service as Desktop as a Service or DaaS.

What you would be running locally is a single device that allows us to connect a keyboard, a mouse, and
a monitor, and that device, then connects to our desktop that’s running in the cloud. That means that
 this device doesn’t need a high-end CPU or a lot of memory, because the application is running in the
cloud.

We just need a system that has just enough power to provide us with the remote desktop view of what’s
happening with those desktops that are running on the cloud service. There’s obviously an important
network connection, and we need to be sure that we have the bandwidth, and the speed, to be able to
support running our desktop in the cloud.

The services that we’re using in the cloud are often running on many different operating systems, but all
of those operating systems are executing on one single physical piece of hardware. This is virtualization.
And allows us to run many different operating systems on the same physical device.

If we were to look at a block diagram of this virtualization, it starts with the hardware itself. So we have
the infrastructure in place, and on top of that, we’re running a piece of software called a hypervisor. The
hypervisor is the management software, that is able to manage all of the different operating systems
that are running on this computer.

And on top of the hypervisor, are these guest operating systems. You might have one virtual machine
with an operating system and an application, a separate virtual machine with another guest operating
system and application, and there’s a third virtual machine with yet another guest operating system and
application.

You can see that with every virtual machine we’re having to run an entire guest operating system for
each one of these. This requires additional CPU, additional storage, and additional memory, for each one
of these virtual machines, even if we’re running similar guest operating systems for each one of these
applications.

From this perspective, we consider virtualization to be relatively expensive because of the resources
required to have each separate operating system running simultaneously. Or what if we could run these
applications, but instead of having separate guest operating systems, we had a single operating system
running.

And that’s exactly what we do by using containerization. This application, containerization, means that
we’d still have our physical infrastructure, we would have a single host operating system, and then we
would use some type of container software such as Docker, to be able to run multiple applications
simultaneously in their own separate sandbox, but not have separate host operating systems for each
one of those.

Each one of these applications is self-contained. So everything you would need to run application, A, is
in the application A container. These applications also can’t interact with each other because they have
no idea that those other applications are there. Application A’s container has no idea that any of these
other containers are running at the same time.

These application containers are also in a standard format. So we could take this container off of this
particular system, and move it to any other system to be able to create additional instances for this
application.

This is also relatively lightweight to deploy an application because you don’t need to deploy a separate
operating system, every time you want to deploy a new application. Instead, you’re using the kernel of
 the operating system that’s currently there, and simply deploying containerization software on top of
that, that then runs the separate applications. This allows us to have a very streamlined container and
allows modularity between different systems.

Here’s both virtualized and containerized applications next to each other. And you can see what the
virtualized applications we have, that separate guest operating system with each one of those
applications. With containerized applications, it’s a single host operating system and we can deploy
separate application containers on top of that.

Many of the applications we use from day-to-day are one very large application that is built on a single
codebase. This application does everything using this enormous amount of code that has been
programmed into that app.

Everything within this application is all self-contained in the app. So everything associated with the user
interface, with putting data into the application and out, and any business logic, is all contained within
the same amount of code. As you can imagine having a very large codebase that has all of these
different functions, creates additional complexity. This also creates complexity when you need to
upgrade or update just one part of the application.

There’s no method in these monolithic applications, that allow you to update just a single feature.
Instead, you have to replace the entire codebase to be able to use those new functions. It would be
much more efficient if we could take each one of these individual pieces of the application, and break
them out into separate services.

That’s exactly what we’ve done with the Microservice Architecture. Which uses APIs or Application
Programming Interfaces, to break up the application into individual services. These are microservices.
And there’s usually an API gateway, that manages the communication between the client that we’re
using on our systems, and all of those different functions built into the application.

There might be multiple databases or single-shared database, that is able to be used through this API
gateway. If we need to add new features to the application, we can simply add new microservices into
this view, and if we need to increase the scalability of an application, we only need to increase the
microservices that are being used the most. This also means that if certain microservices become
unavailable, the entire application doesn’t fail, only that particular service related to the application.

And the segmentation allows you to have much tighter control of data security since you can limit what
microservices might have access to different types of data. If an organization needs to roll out additional
inventory tracking services, they can increase the number of inventory microservices available.

And if there’s very limited use on a report writing service, we might only need one single microservice to
manage the report writing. If any one of those needs to be changed, updated, or new features added,
you only need to change the microservice associated with those particular features.

We can expand on this segmentation of functions using a serverless architecture. This allows us to take
the operating system completely out of the equation, and instead perform individual tasks based on the
functions that are requested by the application.

The developer of the application will then take each individual function of that application and deploy it
into what we call, a stateless compute container. These compute containers are simply processors that
 are designed to respond to our API requests. So our application will send in the API request to the
compute container, and the results of that API requests are sent back to the client.

This allows us to have compute containers that are only available as we need them. So as people are
doing inventory management, we may have a lot of inventory compute containers that are being built
and torn down as people are accessing those services. If nobody is using any of those inventory features
of the application, then you don’t have to keep a separate server running and maintained for something
that’s no longer in use.

If a user does need to perform an inventory function, we can spin up an individual compute container,
perform that request, and then disable that compute container, meaning that it is ephemeral or
temporary in use. These containers might run for a single event, and once that event is done, the
container disappears. It’s very common to have the serverless architecture running at a third party. So
that third party would be in charge of the security of the data and the applications used for this app.

It’s very common for organizations to build cloud-based services that are running at a third-party cloud
service provider but are only used for internal use. We would commonly separate these into Virtual
Private Clouds or VPCs. This is a pool of application instances, that is contained within one single VPC
container. As we build more applications, we might build more VPCs to contain those applications,
effectively creating separate clouds for each of those apps.

The challenge we have is getting all of our users wherever they might be, to be able to access the
application instances that are running in each of these virtual private clouds. And the way that we
provide that access, is through something called a Transit Gateway. You can think of this Transit
Gateway as a router that’s in the cloud. This provides us with the connectivity we need to connect all of
our users.

Normally, we would have the users connect into this Transit Gateway using some type of virtual private
network connection. This means that we could have users at home, or in our offices, connect through
this Virtual Private Network into the Transit Gateway, where they would then have access to all of the
application instances running on the multiple Virtual Private Clouds.

When you start deploying these different cloud-based applications, there’s a need to protect the data
that’s associated with these applications, and a need to protect the applications individually. We
commonly do this using resource policies in our cloud services. For example, in Microsoft’s Azure cloud,
you can configure a resource policy that would specify which resources may be provisioned by an
individual user.

This would limit the functionality that a certain user would have on building out and creating new
services within the Azure cloud. So a user might be able to create a service in a particular region, say, the
North America region, of the Azure cloud, but deny any type of services being built anywhere else in the
Azure cloud.

A resource policy in the Amazon cloud would allow someone to specify a particular resource and then
determine what particular actions can be permitted for that individual resource. For example, you might
allow access to an API gateway, from a particular IP address range but deny access from any other IP
addresses.
 And another resource policy feature of the Amazon cloud would be to allow a list of users access to a
particular resource. So you could specify the individual users who can access an application instance,
and deny access to anyone else.

As you can imagine, organizations who are rolling out these cloud services may be deploying services
from multiple cloud providers simultaneously. Some application instances might be running in the Azure
cloud, other application instances in the Amazon cloud, and yet another set of instances on the
Rackspace cloud. There needs to be some way to consolidate the view of all of these different services
into one single management interface.

To be able to do that, we use Service Integration and Management or SIAM. This is the natural next step
when you begin deploying these different application instances to multiple providers. This is called
multi-sourcing, and it’s a way to ensure that your application will stay up and running and available,
regardless of the status of any individual cloud provider.

The problem is that the Azure cloud, the Amazon cloud, and the Rackspace cloud, all work very
differently. It’s a different process to deploy application instances. It’s a completely different process to
monitor those instances.

A Service Integration and Management Console would allow you to bring all of those service providers
into a single view, and allow you to manage them from one single interface. This makes a much simpler
management process for organizations that need to deploy and monitor these cloud-based applications.

And of course, this is a constantly changing playing field, with different methods of deploying
applications, and different service providers. So your Service Integration and Management Console will
be able to bring all of that down into a single unified view, making it much easier to manage these
applications ongoing.

Infrastructure as Code – SY0-601 CompTIA Security+ : 2.2

An important characteristic of cloud computing is the ability to easily deploy perfectly configured
application instances at any time. In this video, you’ll learn how infrastructure as code can be used to
simplify and streamline the deployment of cloud-based application instances.

In previous videos, we’ve talked about deploying new application instances and having those new
deployments occur automatically behind the scenes without any type of human intervention. But how
are we able to deploy very complex and multi-serviced applications without having anyone physically
installing those apps? Well, we do it by implementing infrastructure as code. We’re able to describe the
application instance in a series of code that we can then deploy any time we’d like. This is very similar to
writing code for an application, except we’re writing code that would help describe the application
instances that we would then deploy.

For example, we might describe infrastructure as code as being certain hosts such as mail.example.com.
There would be web servers that would also have hosts associated with them, and there would be, for
instance, database servers associated with that application instance. And within this description of the
infrastructure, we can add other configuration settings that would be specific to those individual servers.
This means every time we deploy an application instance, we use this description of code to be able to
deploy it identically every single time. This is a fundamental characteristic of cloud computing. It’s this
ability to easily deploy application instances and have those application instances follow a very specific
configuration setting.

We cannot only deploy application instances with this same type of infrastructure as code, we can
perform a similar function with our infrastructure devices. This would be SDN, or Software Defined
Networking. With SDN, we are separating the functionality of our networking devices into two planes of
operation.

One of these is the control plane, which handles the management and ongoing configuration of the
device, and the data plane is the part of the device that handles the actual operation. For example, on a
router, you might have a control plane that allows you to configure the router and set up any routing
tables, and then you would have the data plane of the router, which is performing the actual router
forwarding. This allows you to separate the functionality of these devices into these separate planes of
operation, and it allows you to configure the device without affecting what’s being forwarded through
that device.

Another important characteristic of SDN is that it is agile, which means you can make changes
dynamically at any time. This is especially important for cloud computing, since we know that cloud
computing application instances can change dramatically from moment to moment. It’s also important
that we’re able to manage this SDN from one single point of view. We call this a single pane of glass,
where we can sit at one management console and see the deployment for all of our SDN devices.

This should also be a technology that we can programmatically deploy, so if we have a new application
instance deploying, we can also deploy the appropriate networking infrastructure along with it. And we
also need this entire process of automated deployment to follow a set of open standards. That way
we’re not locked in to any particular implementation of an SDN. Instead, we can use a very open and
standard process regardless of the underlying infrastructure.

Here’s an example of deploying security devices using software defined networking. Let’s say that we
have an internet connection that’s coming into a load balancer, and that load balancer is providing a
load across multiple web servers. But we would like all of these web servers to be able to communicate
with each other, and we would also like to provide connectivity to a database server, but we’d also like
to make sure that all of this communication is safe.

So we might deploy an internal firewall using software defined networking that would connect web
server A, web server B, and the database server all to each other, but be able to manage the flows of
traffic between all of those devices. We also might want to deploy a firewall or IPS between the internet
and our load balancer to provide additional security to the web server front end. What’s important to
keep in mind is that all of these devices are software-based, and they can be deployed automatically
using software-defined networking.

As cloud-based architecture is constantly in motion, we are installing new application instances and
tearing down additional instances, and the amount of data that’s moving in different locations is
changing all the time. But we still have a need to be able to monitor and understand what the traffic
flows are for all of these different application instances. And the way we do that is through SDV, or
Software Defined Visibility. This allows us to deploy next-generation firewalls, intrusion prevention, web
application firewalls, and other security devices while at the same time being able to understand exactly
what type of data is flowing between all of these systems.

This will almost certainly include something like a Security Information and Event Management, or a
SIEM, where we can roll up all of that data to one central consolidated database. It’s also important that
this software defined visibility understand the VXLAN, which is the Virtual Extensible LAN, which is an
encapsulation method used in cloud-based technologies, and also understand what type of data might
be encrypted using SSL or TLS. The foundation of what we are deploying and the way that we’re
deploying these applications is changing all the time, so our SDV has to also understand all of these new
technologies as we put them into service.

Here’s an example of some of the information we might be able to get from software defined visibility.
We would deploy our security devices, and those devices would be able to understand the application
flows that are traversing the network. From there, we’re able to get real-time views of web usage, host
name usage, and the top applications in use based on what these devices are seeing on the network.
And if we identify a potential threat on the network, we can use APIs to control what these application
devices may be sending across the network.

Virtualization Security – SY0-601 CompTIA Security+ : 2.2

The security of our cloud-based systems is paramount. In this video, you’ll learn about the importance of
VM sprawl avoidance and VM escape protection.

One of the huge advantages that cloud computing brings is the ability to deploy a new set of application
instances with the click of a button. This process can be automated so that multiple servers, databases,
and security devices can all be deployed automatically at an instant. We need to make sure that the
process we have for deploying these application instances also considers the process of recovering those
deployed instances and returning all of those resources to the pool. This is the problem we have with
virtual machine sprawl. We have all of these virtual machines that keep being built on our network and
we don’t deprovision these instances when they’re no longer needed. At some point, we aren’t sure
exactly which virtual machines are related to which application instances, and now it becomes much
more difficult to remove these resources from the network.

This is why it’s important to have a formal process for provisioning an application instance, and then the
deprovisioning of that application instance. It’s also a good idea to make sure that every virtual object is
identified and that you have a way to track it from the moment it’s created until the moment that it’s
deprovisioned. One of the useful characteristics of a virtual machine is that it is self-contained.
Everything happening within that virtual machine only happens as part of that VM and has no effect on
any other VMs that might be running on that network.

Unfortunately, there is an attack type called a virtual machine escape that would allow someone on one
virtual machine to be able to gain access to resources that are on a completely separate virtual machine.
This is obviously a significant exploit, because these virtual machines should never be able to share
resources between each other. And finding an exploit that would allow someone to hop from virtual
machine to virtual machine would be a significant security concern. Someone who had access to this
kind of exploit would effectively have full control of your virtual environment, your applications, and all
of your data.

Fortunately, these types of exploits are very rare. But an example of one that occurred was in March of
2017, at the Pwn2Own competition, which is a hacking contest. If you’re able to gain access into a
system, you would effectively be able to take that system home with you. This exploit started by taking
advantage of a JavaScript engine bug in Microsoft Edge Browser. This bug allowed code execution within
the Microsoft Edge sandbox, which then allowed someone access to the Windows 10 kernel. That user
then took advantage of a Windows 10 kernel bug, which compromised the guest operating system of
that virtual machine. At which point they were able to take advantage of a hardware simulation bug in
VMware, and escape that particular VM host into a separate VM host on that service. This was obviously
a significant security flaw, and instead of this being something that was seen in the wild, there were
patches deployed for the virtual environment, the operating system, and for the Edge browser.

Secure Deployments – SY0-601 CompTIA Security+ : 2.3

The application development process can be a challenge to implement. In this video, you’ll learn how to
securely create and deploy applications from the development process through production.

If you’re an organization that does your own development work, there’s always a challenge in getting
the application from the development process and move it into the production environment. This
sounds like something you could simply copy over into production and start using. But there’s many
checks along the way to make sure that the process is going to go smoothly.

You also have challenges in rolling out updates to application or patching existing operating systems or
applications. A good example is the Microsoft Patch Tuesday, where you need to test and deploy these
new patches into your Windows operating system. But do you simply deploy them without testing? Or
do you go through a testing process first? And what does that testing process look like? And how long
does it take between the time that you receive the patch and the time that it’s deployed into
production?

Each of these scenarios where you’re moving an application from a nonproduction environment to the
production environment should be very closely monitored. So in this video, we’ll look at all of the
different steps that many people follow between the time from beginning to end of the application
development process.

There are many uses of the term sandboxing in information technology. But when we refer to
sandboxing in this video, we’re referring to the application development process. A sandbox is an
isolated testing environment that can be used by the developers to test different aspects of the
application that they’re building. They can write some code, run it in the sandbox environment. And if
something doesn’t work or goes wrong, the only people it will affect are people using that particular
sandbox.

The developer can try a lot of different ideas and concepts with their code, try it in the sandbox, and see
what the results might be. And they can do this without worrying that any other part of the production
environment or anything outside of development will be affected by what they do in their sandbox. The
sandbox can be used over and over again by the application developer to continually build onto the
application that they are creating.
 The application development process generally starts with a developer. This would be a programmer
who writes the code in a secure environment and begins testing out different aspects of the code’s
functionality. The developers will commonly use the sandbox to perform tests and will continue to add
on to this code until they have an application that they can begin testing.

The testing environment is a bit more formal. The application developers have now created different
aspects of the application and are bringing all of that code together to see how all of those different
parts will react with each other. This will be the phase where the application developers can check to
see if the features and functions of the application are working as expected.

Once the application developers feel that the application is working as expected, they can hand that
application off to the QA team. This is the quality assurance team. And since they are outside the scope
of the development team, they can really put the application through its paces to see if it’s working as
expected.

This would also be the group that tests new features that have been added to the application and make
sure that the new capabilities are working as well. This would also be a good time to make sure that any
of the old errors that were previously fixed are still corrected in this version of software. Too often, we
can deploy new software that accidentally re-enables old bugs. And it’s up to the QA team to prevent
that from happening.

Once the QA team has performed their tests, and they feel that the software is ready to be released,
there may still be an additional set of tests that need to be done before handing it over to the end users
in the production environment. This would be the staging environment. And it’s a chance to test the
application in a real-world environment that really does test all of the capabilities that the production
environment will call for.

It’s at this staging phase where you might take a copy of production data and copy that over to be used
as if it was in a production environment. This will perform a final test of the data. This will also give you a
chance to see what the performance of the application might be once it’s put into a production
environment. This is the last chance to check the features and usability of the application before
handing it over to the users. So this would be a perfect time to put the application through a lot of tests
and make sure that it’s ready to go into production.

Once all those previous tests are complete, it’s time to turn the application over to the users and put the
application into production. For the end users, this might be one of the most challenging parts of the
process because they now have to be trained on the new features and become comfortable with the
changes in the application.

The team making this transition into production may also have a number of changes. They might have to
implement new servers. There may be additional software that has to be installed. And this may have to
restart or interrupt service for the existing production users.

Before deploying this application into production, it’s a good idea to get a security baseline of exactly
what is required to secure this application and maintain the security of this application. We want to
define all of the important security characteristics for this app. So we want to check the firewall settings
that are required to have this application work and still be secure, want to check patch levels of the
application and the operating system. And we want to make sure the operating system files are also up
to date with the latest security patches.

If we deploy multiple versions of this application instance, then we want to be sure that this security
baseline is followed for each one of those instances. And if we make any changes to this application, it
could affect firewall settings, patch versions, and any other security aspects. So we want to make sure
that we always keep these security baselines up to date.

It’s also a good idea to perform some integrity checks once this application has been deployed into
production. This gives you a chance to check the existing production environment and make sure that it
matches all of the requirements set on the original security baseline. If you find that the firewall settings,
the patching of the operating system, or any of those other important security baselines is not matching
in the production environment, then that should be an immediate concern and something that needs to
be corrected as soon as possible.

Provisioning and Deprovisioning – SY0-601 CompTIA Security+ : 2.3

Cloud computing has put an updated focus on our approach to provisioning and deprovisioning
applications. In this video, you’ll learn about scalability, elasticity, and orchestration of application
instances.

Provisioning is the process of making something available. If you are provisioning an application, then
you’re probably going to deploy a web server, a database server. There may be a middleware server and
other configuration and settings to be able to use this particular application. That’s one of the reasons
why, when we describe the deployment of an application, we’re referring to it as an application
instance, because it usually involves many, many different components all working together.

Of course, the provisioning of this application instance also includes security components. We want to
be sure that the operating system and the application are up to date with the latest security patches.

We also want to be sure that our network design and architecture is also secure. So we might want to
create a secure VLAN just for this application. There might be a set of configurations and a firewall for
internal access and a completely different set of security requirements for external access.

And if we’re deploying software to a workstation, we may want to run our own scans of that software
and make sure there’s nothing inside of that binary that may look malicious. This also would be a good
time to check the security posture of the workstation and make sure that the workstation itself is up to
date with the latest patches and is running all of the latest security configurations.

The workload associated with this provisioned application can vary widely depending on many different
criteria. Maybe at a particular time of the year, an application gets busier, or maybe the popularity of an
application has taken off. And suddenly, a lot of people are wanting to use this application.

When we first build this application instance, we’re creating a particular level of scalability. We know
that based on the particular web server, database server, and all of the other components that make up
this application instance– that we can support a certain load. For example, you might build an
application instance that can handle 100,000 transactions per second. And everything that you put
together would be able to handle any load up to that point.
 But if an application becomes very popular, you may find that 100,000 transactions per second isn’t
enough. Maybe you need to increase the capabilities of this application to support 500,000 transactions
per second. To be able to do that, we may deploy multiple application instances.

That increase or even decrease of available resources for an application refers to elasticity. We define
the elasticity as the ability to increase or decrease the available resources for this application based on
the workload. As this application becomes more popular, we can create new application instances to
increase the number of available transactions per second. If we know that our application scalability can
support 100,000 transactions per second and we suddenly need 500,000 transactions per second, then
we can take advantage of this elasticity and create five separate application instances all running
simultaneously.

If the application becomes less popular, then elasticity works in the other direction. And we can
decrease the number of application instances available, thereby decreasing the number of transactions
per second that can be supported by this application.

Once you have this application that can be provisioned, you might want to automate the process of
making this application available through a method called orchestration. Orchestration is really the key
to cloud computing because you’re able to automate the provisioning and deprovisioning of these
applications.

This orchestration allows us to instantly provision an application without any type of human
intervention. So we could deploy servers, network configuration, security components, and anything
else associated with that application.

You can even orchestrate where this application instance will be provisioned. So you may want to have a
provisioning of the application in Europe for the times that Europe is awake and then create new
application instances in the United States when those particular users are available.

You can then automatically deprovision the application instances in Europe as the day is ending and
then, ultimately, deprovision the ones in the United States once the sun sets there. Then the process can
restart itself the following day through the automatic provisioning and deprovisioning of the app.

Not only are we provisioning the application components, but we’re also provisioning all of the security
components as well. So the automation that you’re building with this orchestration is going to apply to
all aspects of this application and the security components as well.

If we’re building out and provisioning new applications, then, eventually, we may be deprovisioning or
removing those application instances as well. This is not simply turning off the application. This is
completely removing any remnants of that application from running in your environment.

If you’re deprovisioning a web server or database server with an application instance, then you also
have to deprovision all of your security components as well. Not only are you removing the firewalls and
other security devices, you may have to remove individual rules in the existing firewalls that remain. So
make sure that if you are provisioning and opening up those firewall rules– that you are, during the
deprovisioning process, removing those firewall rules.
 And, of course, decisions have to be made over the data that was created while this application was in
place. It may be that the data is copied off to a secure area or it may be that everything that was created
during the use of that application is now removed during the deprovision process.

Secure Coding Techniques – SY0-601 CompTIA Security+ : 2.3

An application developer must use many different techniques to keep their code secure. In this video,
you’ll learn about stored procedures, obfuscation, input validation, memory management, and more.

Creating an application is always a balancing act between, how much time it takes to create the app and
the quality of the final product. We want to always have an application that is able to do all of the things
we need, but we also want to have the application be secure.

We also have to think about the entire process for creating the application, and things like the QA
process, take a lot of time as we begin testing and verifying different features of the application. And of
course, eventually, some type of security vulnerability may be found inside of that application, and that
would need to be patched before someone was able to exploit that vulnerability.

One way to make an application more secure is to create stored procedures for your database calls. For
example, this is a SQL database call, where it is a select command, where we’re asking for data from the
database, from a particular table in the database, and a particular value within that table.

If the client using this application realizes that these requests are being made directly from the
application to the database, they may be able to modify the information within this query and gain
access to information that normally would not be available.

To avoid this, a stored procedure is created on the database server itself. So instead of having the client
send this information to the database server to run that query, that query is instead stored on the
database server, and the application just sends a message saying, CALL, and then the name of the stored
procedure to run.

Using this format, the client is not able to modify any of the parameters of that database call. They can
only choose to either run that stored procedure or not run that stored procedure. This would mean the
app developer would need to create stored procedures for every database query that could be called by
that application. And by doing so, they’ve created an application that’s much more secure, and it
prevents the users from making any direct database calls.

Another method that application developers use to make their code a bit more secure, is to use
obfuscation. Obfuscation is a way to take something that normally is very easy to understand and make
it so that is very difficult to understand. From an application developers’ perspective, they’re taking,
application code that they’ve written, and they’re changing that code to make it very difficult to read by
other human beings.

Fortunately, the computer understands the obfuscated code perfectly. It only prevents human beings
from being able to read through that code and understand what’s going on. The obfuscated code makes
it more difficult for someone to look at the software, and determine where any security vulnerabilities
might be.
 Here’s an example of code obfuscation. This is a single line of code in PHP that puts on the screen a
message that says, Hello world, so it’s echo, a quote sign, Hello World, in the quotes, and a semicolon.
This exact same function can be represented by this amount of code. This is obfuscated code, that has
taken a very simple echo message and put this on the screen, and turned it into something that’s
extremely difficult for a human to look at, and understand that that’s what’s going to happen.

If you were to run this code with PHP on your computer, it would be able to output at the bottom, Hello
world. So all of this obfuscated code, which looks nothing like the original echo command, ends up
performing exactly the same function.

Another security issue might arise when an application developer chooses to reuse code between
different applications. This is a very common thing for application developers do, because they’ve spent
all that time, to create code that performs a particular function in one program, and now they need
exactly that same capability in another program, so they simply copy and paste that between
applications.

However, if that code has a security vulnerability associated with it, copying that code to multiple
applications, now spreads that security vulnerability into all of those other apps. Another challenge
developers have, is to make sure that the code that they’ve put into the application, is actually,
performing a useful function.

There can be instances, where a code has been added to a particular application, it runs through the
logic of the application, creates calculations, stores variables in the application, and then none of that
information is used anywhere else in the app. We refer to this as, dead code, where there has been a
code put into the application, it is running through and processing some type of logic, but the ultimate
results of that logic aren’t used anywhere else within the app.

Any type of code added to an application, adds the potential for a security issue. So it’s important to
make sure that any of the coding that we’re doing, is following the best practices, and avoiding any type
of code reuse, or dead code.

One of the main functions of an application is for us to put data into the app, and then we get some type
of result back out of the application. One of the ways that attackers is able to identify vulnerabilities of
an application, is to find a place where the input is not properly being validated.

For example, if an application is asking for a zip code, then it’s expecting a certain set of numbers, over a
certain range. And in many applications, there are multiple places for data input. This might be a file
that’s uploaded, it might be putting information into a form, and all of this information needs to be
validated.

The application should be checking through all of the data to make sure it’s in the right format, and if it’s
not the right format, it should add any corrections. We refer to this as, normalization. For example, a zip
code should only be a certain number of characters long, and it should usually consist of a series of
numbers or a very specific combination of letters and numbers.

If the information being input into the application does not match what’s expected from the input
validation, then the application should put a message on the screen to the user to correct the problem,
 or there may be logic within the application that’s able to fix the input without any other type of user
interaction.

Attackers will use fuzzers and other techniques to try to find a way around the input validation. So, it’s
very important that the developers address any type of input going into their applications. The
application developer can choose to validate this input in different locations.

When commonplace is on the server itself, we call the server-side validation, because the data is sent
into the server, and code on the server, is able to look through the data, and validate that the input has
been done correctly. This would prevent the user from making changes to the data before it gets to the
server, in the hopes that it would somehow get around the validation process.

Some applications will validate the data on the client-side before it’s sent to the server. The end-user
application will validate the input on the client’s machine, and then it will determine if that is
appropriate to send to the server. This might speed things up a bit since you’re not waiting for the
server to evaluate the input, and then provide you with any type of feedback since all of those checks
are being made on the local machine.

Although, it’s common to use both client-side validation and server-side validation. Using server-side
validation is usually considered the safer alternative. And if you only had to choose between one of
these, you would probably choose server-side validation.

When we’re using an application, we don’t often have to think about how the memory is being used
within the app. That’s a major concern for the developer. They have to keep track of where all these
variables are stored, and make sure that all of that information is available to the application. We also
have to think about this from a security perspective, because users will input different types of data into
the application, and that information will be stored in memory.

Malicious users will try to get around some of these input validations, to put their own data into the
memory of your computer. A good example of one of these security problems would be, a buffer
overflow. In certain situations, the user might be able to send more data than what was expected and
overflow a section of memory.

This might cause the application to crash, or it might cause the application to provide the user with
additional access, that they would not normally have. This is why it’s sometimes better for the
application developer, to write their own logic for the application, rather than use some type of third-
party library, which could be insecure.

This is an ongoing challenge for application developers because they write all of this logic for their
application, but there may still be certain features or functions that need to be added, that they have
not written any code for. One way to speed up this process is to use code that has already been written
by someone else.

These would be third-party libraries or information, that’s contained within software development kits
or SDKs. This extends the functionality of the programming language; it speeds up the development
process and gets the application built that much faster.
 Unfortunately, these libraries are written by someone else. So we are not sure exactly how secure the
library might be. It might be that library is very secure, or it may be that there are vulnerabilities within
that library, and using that library in our application could open up our application to an exploit.

If you’re an application developer, and you’re trying to decide if you should use an application library, or
not, make sure you’re doing your research and you know exactly how secure that library is.

In many applications, we’re inputting a lot of sensitive data. We could put in our name, our address, our
birthday, our social security number, information about our family, our medical information, and so
much more. That information needs to be secure. We need to make sure that we are encrypting this
data when we’re storing it into some type of database or storage system.

If we’re sending that information across the network, we need to make sure it’s sent in an encrypted
form as well. And if we’re displaying this information on the screen, we may want to filter out some of
this information or display it in a way that’s more secure.

Any time we have data going into an application, or being sent from that application, we need to check
it and make sure that any type of data is not being exposed. By doing this, we can be assured that all of
the data will be protected from the time we put it into the application, until the time we see it on our
screen.

Application developers are constantly making changes to their application code, and it’s very common
for them to use version control. This means that they could write some software, check it into a version
control system, and then next time they’re ready to update this code, they can keep track of anything
that may have changed between one version and another. This is a feature, of course, it’s not just used
for application development. You’ll see this in operating systems, file systems, and wikis, and other
locations as well.

Version control can also be very effective from a security perspective. It’s useful to look at a particular
file today, and compare it to what that file was a week ago, or a month ago. If we’re trying to determine
if a file may have been changed over time, using version control, is a great way to make that
determination. Saving this information for historical reference can be a valuable security tool, but you
want to make sure that a third party is not able to gain access to that sensitive information.

Software Diversity – SY0-601 CompTIA Security+ : 2.3

One way to minimize the attack surface is to use different application binaries to perform the same task.
In this video, you’ll learn about software diversity and some of the advantages and disadvantages of this
security strategy.

Attackers are very good at finding a vulnerability in a particular application and then exploiting that
vulnerability wherever they happen to find that application running. This is one of the reasons why we
have constant patch updates for operating systems and applications. If an attacker finds a vulnerability
in Windows 10, we’ll need to update everyone’s Windows 10 operating system to make sure that that
vulnerability is patched.
 A unique approach to this type of problem is to create software that’s different on everybody’s
workstation. This would mean that everyone would still be running Windows 10. But everyone’s
Windows 10 binaries would be slightly different from one machine to another.

We refer to this as software diversity. We use different tricks in the compiler to change where the paths
go during the compilation process. This means that the final binary file will be different every time you
compile the application. This won’t change the functionality of the application or the way that it works.
It only changes the final binary file itself.

This means if an attacker finds a vulnerability inside of this file in a person’s machine, and they create an
exploit for that vulnerability, they may find that they’re not able to use that exploit on a different
person’s machine because it’s running a different version of that file. This obviously creates some
additional work to create the different binaries for this application. It also creates additional work to
deploy these different binaries to these different devices.

But if you’re able to have this diversity in applications between all of these different machines, you could
minimize the attack surface if anyone does find an exploit with this particular application. But this would
limit the potential for an attack because any type of vulnerability, and ultimately, any exploit would be
limited to only a certain type of binary file.

Automation and Scripting – SY0-601 CompTIA Security+ : 2.3

One challenge for any developer is the process of creating and publishing application updates. In this
video, you’ll learn about continuous integration, continuous delivery, and continuous deployment.

The application development process is a constantly moving and constantly changing process. And it
becomes important to be able to keep up with these changes, not only so that the application can
change, but so that the security based on that application can stay up to date. We can also create
automation around the deployment of these applications and automation based on how we react to
problems that might occur when that application is executing.

For example, if we know that the storage area of log files for an application was to fill up, it would cause
the application to fail. So we might want to constantly monitor that particular drive and make sure that
it never gets to a point where it gets too full or too highly utilized. If we do constantly monitor this drive,
and we notice that it’s running out of drive space, we can then automatically work behind the scenes to
delete any older files or free up any needed disk space. These checks become especially important for
cloud-based technologies because they may be automatically provisioned and deprovisioned. And we
need to perform checks when we’re provisioning and adding that application instance and perform
other checks when we’re deprovisioning that application.

One important place to use this automation is when we are doing Continuous Integration, or CI. This is
when the application developers may constantly be updating an application and perhaps even merging
it into a central repository many times a day. This, of course, could open up the potential for a security
issue. So we need to make sure that we have the automation in place to perform these security checks.

If a developer checks in some new code, then there are some automated security checks that we know
have to be made. And then we need to evaluate the updated code with the existing set of security
baselines. Once the software comes out of the development process, there might be even more
 extensive security checks made so that we can be sure that anything deployed to production will be as
safe as possible.

If we can automate the checks during the development process, then we should also be able to
automate the checks during the testing process. This is called continuous delivery, where we’re going to
automate the testing and the release of this particular application. Our automated security checks will
occur during the testing process. And it will wait for us to click a button to deploy this application into
production.

If you want to have the entire process automated, we refer to that as continuous deployment. With
continuous deployment, we’re not waiting for a human being to click a button and send that application
into production. Instead, the entire testing process and the deployment process is automated. If a
problem is found during that testing process, the application will obviously not be pushed to production.
But if all of our automated security checks go through all of the code, and everything looks perfect, we
can automatically send that to production without any delays at all.

Authentication Methods – SY0-601 CompTIA Security+ : 2.4

We use many different technologies during the authentication process. In this video, you’ll learn about
directory services, federation, attestation, and more.

Many operating systems will use a feature known as directory services. This is a central database that
stores usernames, passwords, computers, printers, and other devices that might be connected to the
network. This database is distributed across multiple devices, and those databases will communicate to
each other, and send replication data so that every database is always up to date with the latest
information.

This means that when a user needs to access the network, they simply use their single username and
password, and those credentials are checked against this directory services’ database. The users only
need to remember this single authentication method, and that single method generally gives you access
to all of the resources you need on that network.

One of the most common directory services in use is Microsoft’s Active Directory. We commonly use the
Kerberos protocol or LDAP to be able to access that database from an external device. Instead of
maintaining your own database of usernames and passwords, you can use authentication information
that’s already contained at a different site. This is called Federation. And it’s a way that you can allow
someone to authenticate to your network, using credentials that are stored with a third party.

To enable this Federation, you would need to coordinate the authentication and authorization process
between your organization, and the third party that’s providing these credentials. But once that process
is complete, someone can log in with that third-party username and password. So you can present a
login page that will allow someone to log in with their Twitter account, their Facebook account, their
LinkedIn account, or others.

Once that trust relationship is in place with the third party, your users can simply choose the
authentication type that works best for them, and use those credentials to gain access to your network.
 These days users can be located anywhere in the world, and they’re often using a VPN or some other
type of connectivity to gain access to our local network. As security professionals, we want to be sure
that our users are connecting to our network, using the hardware that we provided to them.

We don’t want them to use a piece of third-party hardware and software, to be able to gain access to
our internal network. To be able to prove that the hardware that they’re connecting with is really the
hardware we’re expecting, we need to provide a functionality called attestation. With attestation, you’re
having this system a test, that the hardware that is connecting into your network, is the hardware that
you originally set up as something trustworthy, that is allowed access to your internal systems.

If we’re managing a single device, it’s relatively easy to determine if that device should be connecting to
our internal network. But when we have thousands of devices that we’ve deployed to all of the users in
our organization, we need some automated process to be able to confirm, that the hardware that’s
connecting into our network, is hardware that’s trusted.

With remote attestation, we have checks that occur on that remote device, and that device will provide
a report to a verification server, that will then allow that device access to the network or prevent access
to the network. This attestation report is usually encrypted and digitally signed using keys that are
located on the Trusted Platform Module of that remote device.

This report might also include a unique identifier for that hardware such as an International Mobile
Equipment Identity number or IMEI. By going through this attestation process, we can be assured that
the device that’s on the other end of this communications path, is one that is trusted and is allowed
access to our network.

Another type of authentication can be found with an SMS. This is a Short Message Service or we
commonly refer to as a text message. You’ve probably used this process when authenticating with a
third-party website. You would provide your username and password, and a message is then sent to
your phone over a text message or SMS.

There’s usually a code contained within that text message, and you would put that code into the login
form to confirm that you are the person who has that phone in your possession, and you can now
approve that you’ve received that text message.

The use of SMS message, is generally considered to be less secure than other methods. It’s relatively
easy for someone to reassign a phone number so that the SMS message is redirected into another
person’s phone.

SMS messages can sometimes also be intercepted by a third party, giving them access to a code that
normally only you would have available. These types of security issues are relatively rare, but if someone
wants a higher security method for authentication, they might want to consider using something other
than SMS.

Instead of relying on a text message, we may rely on our mobile device having a particular application
installed. This is a push notification, where the server is pushing down the authentication information to
your mobile device. It uses this mobile device app to be able to receive the pushed message and display
the authentication information.
There are also some security concerns associated with push notifications. It could be that the application
receiving the push notification might have vulnerabilities that would allow a third party to view that
information.

Or it could be that the app is not using encryption, and that push notification is being sent to the phone,
in the clear rather than using some type of protected mechanism. With the right app, however, this is a
relatively safe process, and probably more secure than something like SMS.

Another type of authentication uses a pseudo-random token generator to create what would seem to
be a random set of numbers that are used during the login process. This might take the form of a
physical device, like this token generator that would fit on a keyring. Or it may be an app on your mobile
phone that’s effectively providing the same coding information that you would get from a physical token
generator.

Many of these token generators use a functionality called TOTP, that stands for Time-based-One-Time
Password algorithm. This means the pseudo-random number will be available as a login credential for a
certain amount of time, usually about 30 seconds, and after that 30 second period is over, a new
number is generated.

When this TOTP device is first rolled out, there is a synchronization process using a secret key and the
time of day. Once that process is in place, the Authentication Server, and the token generator, or token
generator app, will know exactly what the next number is in sequence based on what the time of day is.

It’s common to use these by putting in your username, your password, and then opening up your app,
finding the number, and adding that number into a field on the login page. If you’ve used multifactor
authentication from Google, Microsoft, Facebook, and others, you’ve probably used an app like this that
uses TOTP.

There’s another authentication type that’s very similar to TOTP, but instead of having a number that
changes every 30 seconds, you have a number that you would use one time during the authentication
process, and then you would throw away that number and never use it again.

This is called HOTP or HMAC-based One-Time Password algorithm. Usually, you would provide
somebody with a sheet of numbers that they’re able to use during the login process, and then they use
each one of those numbers each time they authenticate to the system. Once they’ve used the number
they can cross it off their list, and they will never use that number again.

This is a similar authentication process to TOTP. You would log in with your username, your password,
and then provide your HOTP passcode. This is also a code that might be stored inside of an app so that
you don’t have to carry around additional papers or worry about what that next number is going to be.

The app will tell you what the next number is on your list. You can find both hardware and software-
based token generators for HOTP, and these will integrate with whatever server you’re using for the
authentication process.

Since many of these authentication methods are based on something you have, which would be your
mobile phone, we could also use a phone call to perform the same type of function. Instead of having an
app, you would use to provide that pseudo-random number, you would have an automated process call
you, and tell you the pseudo-random number.
 So you pick up the phone, and the automated message would say, your code is 1-6-2-5-1-7 and you
would type that in along with your username and password, to complete the authentication process.
The disadvantages of receiving phone calls for authentication are very similar to the disadvantages of
receiving an SMS or text message.

Someone can modify the phone configurations, or configure forwarding, on your phone number so that
they receive the phone call rather than you. These phone numbers can sometimes be also added to
other phones so that when the phone rings, it rings across multiple devices simultaneously, and
someone can intercept that call before you have a chance to hear it.

There are some authentication factors that never change. These are values that you’ve remembered,
and you have to remember what that particular value is to complete the authentication process. A good
example of this is a Personal Identification Number or a PIN. These are numbers that we use when
authenticating with an automatic teller machine, for example.

We might also have a code that is alphanumeric, so we’re using a set of numbers and letters, to be able
to provide the static code that we would use for authentication. A password or passphrase is a good
example of an alphanumeric static code.

And if you carry around a smart card, you may find you also use that smart card for authentication. This
might be something that requires contact, so you would slide the smart card into a laptop, or this may
be contactless, where you have to get it near the reader for it to be able to read the information on that
card.

This type of smart card functionality is very common on credit cards, but we can also use this for access
control cards that we would use to gain access to laptops, computers, and other devices. The key with
this authentication factor is it’s something you have. It contains a certificate on that card, and no one
else has a copy of that card and that certificate. So if you’re sliding that smart card into a laptop to gain
access, we’re assuming that you would be the only one who would have access to that card.

Obviously, someone could accidentally lose this card or misplace it, and someone else could gain access
to that card. So very often smart cards are used with other authentication factors such as username,
passwords, Personal Identification Numbers, or fingerprints.

Biometrics – SY0-601 CompTIA Security+ : 2.4

There are many ways to authenticate someone based on a biometric feature. In this video, you’ll learn
about fingerprint scanners, retinal scanners, voice recognition, and more.

A biometric authentication factor refers to something you are, this would be something like a
fingerprint. For example, fingerprint scanners can be found on phones, on laptops, and to access doors
of data centers and other facilities. You might also use the retina that’s inside of your eye as a biometric
authentication factor. The retina is these capillaries that are in the back of your eye. They are a relatively
unique feature of your eye and they don’t often change, making them a very good biometric factor to
use for authentication.

We can also use the iris of our eye as an authentication factor. That’s in the front of our eye, and there’s
usually specific textures and colors associated with your iris. Our voice makes for a very good
 authentication factor, so we might have to say something to be able to gain access using voice
recognition. And if you have a mobile device you may be using facial recognition, the camera in your
phone looks at the face of whoever’s holding the phone, and is able to either allow or disallow access
based on those facial features.

A biometric factor that’s rarely used, but is relatively accurate is a gait analysis. This examines the
different characteristics that someone has when they’re walking. Everyone has a different way of
walking, and gait analysis will be able to measure those differences and determine one person’s gait
versus another. And similar to retinal scanners where we were looking at capillaries in the back of the
eye, we also have vascular scanners that can look at veins that might be in our arms. This can look at the
blood vessels in our extremities, and determine who a person is based on the unique layout of their
veins.

Using biometrics as an authentication factor is an uncertain science. There are differences in users,
there’s differences in the sensitivity of the readers that we’re using for biometrics, so we have to spend
some time to make sure that the sensitivity levels are providing us with the correct access for our users.
One of the metrics you would examine to determine how well your biometrics are working is a false
acceptance rate, or an FAR. This is how often your biometric system will approve an unauthorized user
by looking at these biometric values. This is obviously not something you would want to have happen on
your network, so it’s common to increase the sensitivity of the biometric reader so that you can
decrease the false acceptance rate.

On the other end of the spectrum is the false rejection rate, or FRR. This is someone who is authorized
to get into the system, they put their finger on the fingerprint reader of the biometric system and
instead of getting a green light, they get a red light. Even though they are authorized, they are now
rejected from that biometric reader. A large number of false rejections can frustrate users, and it can
prevent people access into places where they are authorized to go. So it’s common to decrease the
sensitivity of the biometric system to reduce the number of false rejections.

Somewhere in the middle of those two is a sweet spot that we call the crossover error rate, or CER. This
is an area where we have minimized the number of false acceptance rates, and we’ve minimized the
amount of false rejection rates, and effectively gotten both of those down to an equal level. There’s
obviously some measurement between these two values that would work for your organization, and it’s
up to you to adjust the sensitivity of your biometric system to find that correct setting.

Here’s visually how this might work, we have a number of errors increases on the y-axis, and the
sensitivity levels are changed on the x-axis. If we have low sensitivity, then we might have a number of
users gaining access to the system who are unauthorized. That is a false acceptance rate. And the less
sensitive we are, the higher that false acceptance rate. If we increase the sensitivity, it now becomes
more and more difficult for an authorized user to gain access because they keep getting rejected with
the false rejection rate. So as we change the sensitivity to be somewhere in the middle, we’ll get a
crossover error rate, or CER, where the FAR and the FRR meet right in the middle.

Multi-factor Authentication – SY0-601 CompTIA Security+ : 2.4

We use many different factors during the authentication process. In this video, you’ll learn about the
AAA framework, multi-factor authentication factors, and multi-factor authentication attributes.
 We’re all familiar with the process of authenticating into a system. Usually you use a username, a
password, and perhaps some other type of authentication factor to gain access. This is often combined
with what we call the AAA framework, this is authentication, authorization, and accounting. This starts
with identification, the process of proving we are who we say we are. This is commonly a username that
we would provide during the login process, and that username is one that associates an account with us,
as an individual.

It’s one thing to say that you are who you say you are, but you also have to prove that during the
authentication process. This is commonly done by using some type of authentication factor. Such as a
password, a biometric factor, or one of the many other authentication factors that we will discuss in this
video. Once you’ve now, proven that you are who you say you are, now we need to determine what you
would have access to. This authorization process may allow you access to a particular file share, or it
may allow you to print to a particular printer.

And the last A in the AAA framework is accounting. This is keeping track of exactly who may have
authenticated onto a network. There are a number of different ways to provide this authentication
process. Some are in the cloud, and some are on premises.

A cloud based authentication is often going to involve a third party to manage that platform. We will
have that service provided by a Cloud service provider, and we will simply use that service as part of the
authentication process. This is usually a centralized platform in the Cloud that can be accessed from
anywhere in the world. And it might often include an API integration so that we can have applications
access this and provide the same authentication to the same centralized database.

There might also be the ability to add on additional options in the Cloud that we can turn on and turn off
as we need them. And on premises, or on-prem authentication system would be one in our local data
center. This would require our own internal staff to be able to monitor and configure anything
associated with this authentication system. And if there are users on the outside of our network that still
need to authenticate through our internal system, we need to make sure there are processes in place
for them to be able to provide that authentication.

When we are authenticating into a system, there are a set of factors that we would use. Those three
factors are something you know, something you have, and something you are. You can add on to those
factors, some attributes. Those attributes would be somewhere you are, something you can do,
something you exhibit, and someone you know. An authentication factor is comparing a characteristic to
what you know is associated with an individual. An authentication attribute is a bit more fluid. It may not
necessarily directly be associated with an individual, but we can include these with other authentication
factors to help prove someone’s identity.

The authentication factor of something you know is something that’s in your brain, and only you happen
to know what this particular value is. One of the most common things that we know is a password. And
we commonly use a username and password to be able to gain access to a system. But we could also use
a personal identification number, similar to the numbers you would use at an automatic teller machine
for example. This is something that is not usually written down anywhere. This is also something that’s
in your brain and something that you know.
 On many mobile phones, you also have the option to use a particular pattern that you’ve memorized.
This is very similar to a password you might have memorized, but instead you’ve memorized a set of
patterns that’s on the screen, and you can duplicate those patterns to gain access to your phone.
Another authentication factor is something you have. This is usually a device or some type of system
that is near where you happen to be. Something like a smart card for example, would be a card that we
keep with us. This is sometimes even a card that’s also used as identification, and this might integrate
into other devices by sliding it into a smart card reader. These are usually used in conjunction with a
personal identification number so that you’re using not only something you have, but you’re combining
it with something you know.

Another factor of something you have might be a USB token, where we might have a certificate that’s
loaded on this USB drive, and you have to provide that certificate to be able to gain access to a system.
Since you are the only one who has this USB token, and that certificate is not on any other USB drive, it’s
assumed that this would be something that you would have with you. If you’ve ever carried around one
of these hardware-based pseudo-random number generators, then you’re familiar with something you
have. There are also software based versions of these that can be loaded on a mobile phone, and in both
of those situations, it would be something you have.

And another common factor of something you have might be your phone itself. It’s common to send an
SMS message or text message to your phone, and if you have your phone you’re able to repeat that text
message back during the authentication process. And the third authentication factor is something you
are, this is a biometric factor, so this might be a fingerprint, an iris scan, or perhaps a voice print. This
usually works by taking a mathematical representation of some part of you or your body, such as a
fingerprint and storing a mathematical representation of that fingerprint. The next time you use your
finger on that biometric reader it will perform the same calculation and compare that to what’s been
stored previously.

These biometric authentication factors of something you are is certainly associating these characteristics
with a specific individual. It would be very unusual for someone to be able to change their fingerprint, or
change their retina. So we can associate these types of biometric features with an individual for
effectively their entire lifetime. And although these biometric factors are very good at the
authentication of an individual, they’re not fool-proof and they should usually be used with other
authentication factors as well.

One of the authentication attributes that doesn’t necessarily identify a specific individual but can help
with the authentication process, is some where you are. This would provide an authentication factor
based on where you might happen to be geographically. For example, authentications may be allowed if
you are in the United States, but if you’re outside of the United States the authentication process would
fail. We can sometimes use IPv4 addressing to determine where a person might be, although this
process is a bit imprecise and may give us incorrect information about what country a person may be in.

This is a bit more difficult with IPv6 where specific country associations aren’t available. But this can give
us a good amount of information that can help us make decisions whether a user is authenticated, or
not authenticated. Another way to gather a person’s location is through GPS or perhaps triangulation
with certain wireless networks that may be in the area. This is also not a perfect way to determine
where someone might be and there are ways to get around or even spoof GPS coordinates, but this can
help in the authentication process to be able to allow or disallow access to the network.
Another attribute that can be used for authentication is something you can do; this is your personal way
of doing things. A good example of something you can do might be your signature. The way that you
write your signature is something that’s very unique to you and it’s very difficult for someone else to be
able to replicate that. These attributes may seem very similar to biometrics, but biometrics can provide
us with characteristics that are very specific to an individual, whereas something you can do is a much
broader description of a characteristic.

Another set of attributes would be something you exhibit; this is a personal way that you do things. For
example, the way that you walk is very unique to you, and someone can perform a gait analysis to be
able to compare the way you walk, versus the way that someone else walks. Another attribute that you
exhibit might be the way that you type, you might type at a particular speed or there might be a
particular timing between keys that’s very unique to you. And sometimes it’s not what you know, but
who you know. And the attribute of someone you know can help give you a little bit more credibility
when you’re trying to gain access or authenticate to a system. We use attributes of someone you know
in cryptography when we’re creating a web of trust like we do with certificates, or when we’re creating a
digital signature.

Disk Redundancy – SY0-601 CompTIA Security+ : 2.5

A goal of any security professional is to maintain constant access to data. In this video, you’ll learn about
disk redundancy and using RAID to increase uptime and availability.

In this next series of videos we’re going to talk about redundancy. This is how we duplicate parts of a
system so that it’s always up and running, and available for the users. This is usually a reaction to some
type of failure that’s occurred, and if something has failed, we still want to keep all of the systems up
and available for use. The goal is for the organization to continue operating even though there’s been
some type of failure with part of the systems.

This could be related to hardware, you might have a motherboard fail, or power supply go out, and you
still need to make sure that everything is able to work. You also might have problems with the software.
If there is a bug in the software that causes a service to crash or the application is not working as you
would expect, there still needs to be some type of process in place to maintain the uptime and
availability of those services. And of course, this might also mean that we’re building networks that are
able to maintain and stay up and running even when part of the network may have failed.

Another way to maintain the uptime and availability is to create redundancy in a completely different
geographic area. This is especially useful if the area you’re in suffers some type of major outage caused
by hurricanes, tornadoes, flooding, or any other type of major disturbance. If you have some type of
redundant location that is outside the scope of that hurricane or flood or natural disaster, like a separate
data center, then you can keep uptime and availability with the services in that separate geographical
location.

This might be part of a normal operation you have, there might be a data center on the east coast and a
data center on the west coast, and if anything happens on either one of those coasts everybody can
start to use the other data center to maintain the uptime. This might be part of the normal disaster
recovery process. You might have a data center in Florida and one in Denver, and if there is a hurricane
in Florida all of the processes can now be running from Denver.
 When we’re connecting up network devices such as network drives, we often will configure multiple
links in the network to provide redundancy if one part of the network was to fail. We call this Multipath
I/O, or Multipath Input/Output. This allows us to create other routes on the network that we can use to
work around any problems we might have. For example, if we have a Fiber Channel network we might
have multiple Fiber Channel switches, that way if we lose one switch we can redirect the traffic through
the other switch.

We can also create redundancy with the drives themselves, this would be RAID, or a Redundant Array of
Independent Disks. Most of the redundancy in RAID comes from using multiple drives within a single
array, where you can store some or even all of that data on that redundant drive. This way if you do lose
one of those physical drives, you have separate pieces of that data stored on other multiple drives as
part of that array.

When a drive fails in a RAID array the users usually don’t know that any problem has occurred. The RAID
array continues to be up and running, and all of the data continues to be available. The system
administrators will then, behind the scenes, replace the bad drive. That redundant information is then
rewritten to the replacement drive, and now you’re ready for another failure should one occur.

If we review some of these RAID levels from our A plus studies, we can start with RAID 0. RAID 0 is no
redundancy whatsoever, it’s usually called striping without parity. Where you have very good
performance to be able to read and write to that array, but if you lose any drive in that RAID 0 array,
you’ve also lost the data, and there’s no redundancy available. That’s why most places will start with a
RAID 1 at a bare minimum. RAID 1 is what we call mirroring, where we can take one physical drive, and
duplicate all of the data on that physical drive to a separate physical drive. It’s a mirror of the
information. That way if we lose any one of those drives, all the information continues to be available
and accessible on that separate drive.

Another redundancy type is RAID 5, where we have striping with parity where we’re putting pieces of
information on separate physical drives, and then on a last physical drive we’re putting some parity
information. If we lose any of the drives on that particular array, it will rebuild the data based on the
parity information that’s put on that extra drive. And of course there are combinations of RAID that you
can choose, RAID 0 + 1, or 1 + 0, RAID 5 + 1, and other combinations as well. By combining these RAID
types together you can customize the redundancy for your purposes. And you’ll be prepared regardless
of what physical drive might fail.

Network Redundancy – SY0-601 CompTIA Security+ : 2.5

There are many methods of maintaining the uptime and availability of networks. In this video, you’ll
learn about load balancing, NIC teaming, port aggregation, and more.

One of the easiest ways to maintain uptime and availability on the network is to include a load balancer
as part of the network infrastructure. The load balancer, as its name implies, is going to balance the load
between multiple servers so that one person will access the load balancer, and then the load balancer
will decide what server is able to provide that particular service. You’ll commonly have multiple servers
on a load balancer that are active, which means if anybody is making requests to the load balancer,
those servers will be available and provide a response to those requests.
There might also be other servers connected on this load balancer that are up and running and ready to
go into action but are currently in a standby mode, and the load balancer will not send any of the traffic
to those standby servers. The load balancer is always sending hello messages and checking in with those
servers that are active. If any of those active servers suddenly don’t respond back to these health
checks, then the load balancer makes a decision to disable the connection to that server and perhaps
use a standby server as a replacement.

Here’s an example of a user on the internet that is accessing these servers. When this hits the virtual IP
address on this load balancer, the load balancer then determines that server A is available, and it sends
the traffic to server A. Most load balancers will also remember which servers were being used by a user,
so if this request comes from the same user, the load balancer will remember that this user was using
server A, and it will send that traffic to the server A device.

Of course, there may be times when server A becomes unavailable. This might be because of a hardware
failure, there might be a power supply that goes out, or the software that’s running on the server
suddenly crashes and is no longer able to provide the service. In that case, the load balancer will
recognize that that server has failed, and it will put that server into an offline mode. Since this load
balancer also has standby servers, it can enable one of those standby servers to be online and available,
and any future requests from devices on the internet will use the new server instead of going to the one
that’s currently unavailable.

Even if you don’t have a load balancer, you can still provide redundancy to a server using multiple
network interface cards on that device. We refer to this as NIC teaming. You might also see this referred
to as Load Balancing Fail Over, or LBFO. This allows us to plug in and use these multiple connections to a
server, but instead of having a primary connection and a standby connection, we can use both of those
connections simultaneously and aggregate the bandwidth between both of them. This provides us with
increased throughput, and it also provides us with a way to have redundant paths should one of those
connections fail.

On the server, this is usually configured by installing multiple network interface cards on the server, and
in the server operating system, those cards are bound together to look as if they are one single
interface. We’ll also configure the switch side of this to be able to interpret any of the traffic going to
and from those connections as something that’s being NIC teamed in the server. Just as we had a load
balancer that sent hello messages to make sure that it would get a response back from those network
interfaces, we also have the same functionality within the server. The server is going to have the
network interface cards talk to each other, usually over a multicast connection. Those multicast hello
messages will go out periodically, and the other interface cards on that server will listen and respond to
those hello messages.

If for some reason a network connection becomes unavailable, perhaps a switch has failed or someone
accidentally unplugs a cable, that hello message will not get a response from the interface card that’s
been disconnected. The server will recognize that that card is no longer talking on the network. It will
administratively turn it off and use the other available network interface cards to provide the
redundancy and the connectivity for all of the users.

Here’s an example of using this port aggregation where we have a server that has two network interface
cards, and both of those network interface cards are going to connect to a switch. We will configure
 inside the server that will be doing port aggregation across both of those interfaces, and we’ll also
configure the switch for port aggregation so that both sides of this connection recognize and understand
that this is one single logical connection rather than connecting two physical separate interfaces. This
allows multiple users to send traffic through the network and to have a higher bandwidth and
throughput between the server and that last switch.

But as you can see from this diagram, there are some places where losing a switch could lose
connectivity to the server. For example, there’s a single switch that both of these connections are
plugged into, and if that switch fails, then we lose connectivity to the entire server. To provide another
level of redundancy, we can configure the connections to go to different switches. We’ll still have the
same two network interface cards in the server, but instead of plugging both of those into the same
physical switch, we’ll separate them into different switches. That way, if we lose either one of these
switches due to a hardware problem or a connectivity issue with the cables, we’ll have a separate path
that can be used for all of our users to maintain the connectivity to that server.

Power Redundancy – SY0-601 CompTIA Security+ : 2.5

Maintaining a power source is an important part of any security strategy. In this video, you’ll learn about
UPS systems, generators, dual-power supplies, and power distribution units.

Perhaps the primary resource we need to be able to operate our computers, our laptops, and mobile
devices is power. To be able to maintain power during times of brownouts or complete outages, we can
use a UPS, or uninterruptible power supply. This is a device that has batteries inside. And if the power
goes out, we use the battery power instead of using the primary power source. This is a temporary
power source, because those batteries are only going to last for a certain amount of time. But if you’re
only concerned about temporary outages, a UPS can be a very useful tool.

You’ll generally find three different kinds of uninterruptible power supplies. And they usually are a little
more expensive as you get some more advanced features. One of the simplest and least expensive of
the UPS is an offline or standby UPS. This is a UPS that is not normally enabled unless power is lost. If the
UPS recognizes that the power source is gone, it will switch over to battery power. So there’s a short
time frame between the time when power is lost and then power is made available from the UPS.

Another type of UPS is a line-interactive UPS. If the voltage is slowly diminishing on the line, the UPS can
slowly ramp up the amount of power being provided by the batteries. So during brownouts or times
when the voltage is not at optimal levels, the line-interactive UPS can fill in the differences for the power
source.

The kind of UPS that’s probably the most complex and the most expensive is the online, or what is called
the double conversion, UPS. This UPS is always online and always providing power to your devices. And
if the power does go out, there’s no switching process, because you’re already on battery power.

There are many different kinds of devices that you can purchase. And there are different options
available depending on the model. Some have an auto shutdown capability. So when power is lost, it
can send a signal to your computer to automatically power it down safely so that no information is lost.

There are also many options for battery capacity so that if you lose power, you may be able to maintain
uptime for an hour, two hours, or more. You can often choose a UPS that has a different number of
 outlets on the back of it. And many UPS devices will have phone line or cable modem suppression. So
you can remove any type of voltages from those connections as well.

If you need power to be maintained over a longer time frame, then you might want to move up to a
generator. A generator is a long-term power backup that can keep the power running for days or even
weeks at a time. As long as you have fuel available to run the generator, you can maintain the power.
These generators can often power an entire building, or at least a number of outlets inside of that
building.

Often the outlets are marked to show that they will provide power during an outage. Once the power
goes out, there’s usually a 10- or 15-second waiting period to see if the power happens to turn back on.
And if it does not, the generator turns on and begins providing power to the building. During that 10 or
15 seconds, though, you will need some type of internal power in the building to make sure that all of
your systems remain up and running, which is why you might combine both the UPS and the generator
power to make sure that all of your computing systems stay active and available.

If you’ve ever connected a computer to the power source, then you’re probably familiar with connecting
that power cable and turning on the computer. But what if there’s some type of hardware failure and
the power supply itself fails? In that scenario, you might want to have a server that has multiple power
supplies inside of it where you can plug in multiple power sources. And if you happen to lose one of
those power supplies, the other power supply continues to provide power to that device.

These power supplies are designed so that each individual power supply can support the power for the
entire system. This means if you plug in one of those power supplies, as we see in this picture, that
single power supply can provide 100% of the power load for that server. If you plug in two separate
power sources to both of those power supplies, then each power supply will be providing 50% of the
load for that server.

This picture is in the middle of an installation where half of the power is being provided by one
particular power distribution unit, and there will be a separate power distribution unit that handles the
power for the other side of the power supplies. These power supplies are often hot-swappable as well.
So if one of these was to fail, you can pull this power supply out, put a new one in-line and plug it in, all
while the computer remains up and running.

A power distribution unit, or PDU, is usually a device that provides multiple power sources. This is a very
simple PDU that has eight different power interfaces inside of it. It connects to an ethernet network.
And each one of those interfaces can be controlled across the network. These PDUs also have
monitoring capabilities. So they can report back if there are any type of power problems. And they can
constantly monitor the power load across all of those interfaces on the PDU.

Replication – SY0-601 CompTIA Security+ : 2.5

Replication is a useful method of maintaining application and data availability. In this video, you’ll learn
about SAN replication, VM replication, and a comparison of on premises and cloud redundancy.

When we deploy an application instance, it’s very common that the computing engine that is able to
manage the front end for the users is separated from where the data is being stored. And if we could
store the data in a centralized facility the multiple front ends are able to access then we have more
redundancy. If we lose one of these front ends, we have other front ends that can still access the same
amount of data that we have in this data store.

We refer to this data store as a storage area network or SANs. The storage area network is high
performance storage with built in redundancy and we’re usually able to access this over very high speed
network. Not only does this allow multiple front ends to this data store but we can also replicate the
data between storage area networks.

So we could either have a primary and a backup storage area network or both storage area networks
could be active simultaneously. And they’re constantly replicating data between each other to maintain
everything at exactly the same state. You could also do this across multiple locations. So you can have
one data center with SAN and another data center with SAN and then constantly replicate that data
between those data centers.

If a data center suddenly becomes unavailable or you want to switch everyone from one data center to
another, you will always have access to the data. If real-time replication of data between SANs isn’t
available, you can create a SAN snapshot. The snapshot will take data from one storage area network.
Take the exact makeup of that data and then copy that data to a separate storage area network.

The snapshot can be taken at an interval that you choose. So it might be taken every hour or every 24
hours or whatever interval makes sense for that data and that application. If there’s an outage and you
need to move to the backup storage area snapshot then you’ve only lost the data that occurred
between the snapshot and the current time frame.

Our cloud based application instances rely heavily on virtual machines. And being able to have multiple
virtual machines running simultaneously. We also have the ability to replicate virtual machines. So we
can update one VM and have those updates replicate to all of the other VMs that might be running in
our environment.

This allows us to maintain consistency between all of the separate virtual machines. Once we update the
primary VM all of those updates can be rolled out to every other virtual machine that we’re running
wherever it happens to be in the world. This replicated VM also acts as a backup. If we happen to lose
the primary virtual machine we can roll a new virtual machine from the replication and continue to have
uptime and availability on the new VM.

This VM replication is very efficient. If you change only one file on a virtual machine, you only have to
copy those changes to all of the other VMs to maintain the replicated data. You don’t have to duplicate
the entire VM from one place to the other if the only thing that’s changed is that single file.

When you’ve got all of these cloud based systems, you may want to decide to have the data replicated
into a local service. Or into a service that might be in the cloud. And there are advantages and
disadvantages for both of those decisions.

One concern may be with the speed of the network connection that you’ll be using to provide this
replicated data. If there’s a large amount of data that has to be replicated having devices that are local
on your network would provide very fast connectivity. Connections to the cloud are almost always going
to be slower than devices that would be in a local data center.
 But if you’re going to have all of this equipment in your own local facility you’ll need to purchase all of
that. That’s going to take quite a bit of money to spin up all of these separate storage drives. Cloud
storage systems tend to have a low cost entry point and then you would scale up the costs as you use
more of those resources.

And from a security perspective if you’re storing data locally then exactly who has access to that data.
Storing data in the cloud could possibly open access to that data up to others. So you may have to add
additional encryption or the security mechanisms if you’re planning to store data in the cloud.

Backup Types – SY0-601 CompTIA Security+ : 2.5

There are many different ways to backup data. In this video, you’ll learn about incremental backups,
differential backups, compare NAS to SAN storage, and more.

If you’re using an operating system based in Microsoft Windows, there is a bit associated with every file
system object called the archive bit or the archive attribute. This archive bit is turned on whenever a file
is modified. If you wanted to go into the Properties of a file and look at the Attributes– there’s a button
here showing the Advanced Attributes. There is a check mark here that shows the “File is ready for
archiving.” That is the archive bit. And by examining that, you can see what files may have changed since
the last time a backup has occurred.

It’s very common, when performing a backup on a system, that you back up every single file on the
system. This is called a full backup, and it will take everything that is stored in that operating system and
save it in that full backup. Once the backup is complete, the archive bit is cleared, signifying that no
changes have been made to that file since the last backup.

An incremental backup will occur after the full backup has occurred, and it will back up all of the files
that have changed since the last incremental backup. This is a bit different than a differential backup,
which also occurs after a full backup, but the only files that are backed up are the ones that have
changed since the last full backup. Let’s look at these visually.

And we’ll start with an incremental backup. Up as I mentioned, the first thing you want to do is perform
a full backup of the system. The next time you perform a backup, you’re going to back up the data that’s
changed since the last full backup and since the last incremental backup. This is especially important to
remember during the restoration process, which requires not only the full backup but every incremental
backup that has been made since that full backup occurred.

Let’s look at this visually, and we’ll start with a Monday, where we perform a full backup and back up
everything on our system. This is an incremental backup process, so on Tuesday, we’re only going to
back up all the files that have changed since that last full backup. On Wednesday, we’ll also perform an
incremental backup, and we’re only going to back up the files that have changed since the last
incremental backup.

And in this particular case, the amount of data that has changed between Tuesday and Wednesday is
less than the data that changed between Monday and Tuesday. You might also perform an incremental
backup on Thursday, and this would be everything that has changed between Wednesday and Thursday.
And now on Friday, we want to restore this whole system. And for restoration, we’ll not only need the
full backup, but we’ll need every single incremental backup that has occurred since that full backup was
taken.

A differential backup starts a similar way, where we have a full backup that backs up everything on the
system. Each subsequent differential backup, though, is going to back up everything that’s changed
since the last full backup. So every day, the backup is going to get bigger and bigger and bigger as we
change more and more information since the last full backup. If you need to restore, the only two things
you’ll need is the full backup that originally occurred and the last differential backup.

Let’s see the differential backup visually. We’ll take that full back up on Monday. On Tuesday, we’ll back
up only the things that have changed since the last full backup. On Wednesday, we will also back up
everything that has changed since the last full backup. So you can think of the Wednesday backup as
including everything from Tuesday plus everything that has changed since then. Thursday will be
everything that’s changed since the last full backup. And then finally, when we’re ready to recover this
data, we will need only the last full backup and the last differential backup that’s been made.

Let’s summarize all three of these backup types. On a full backup, we are backing up all data on the
system. The process of backing this up is going to take quite a bit of time because we’re backing up
everything that’s on the system. But restoring this data only requires the single set of backup tapes, so
the restoration time is relatively low and only requires that single tape set. When you perform a full
backup, all of the archive bits are cleared on all of those backed up files.

An incremental backup is going to back up new files and all files that have been modified since the last
incremental backup. The backup time is relatively low because we’re only backing up files that have
changed, but the restoration time is relatively high because we need to restore from not only the last
full backup but every other incremental backup that’s occurred as well. And of course, after we perform
an incremental backup, all of the archive attributes are cleared.

A differential backup is going to back up all data modified since the last full backup. This means it will
take a moderate amount of time to perform this differential backup each day, and every day the
differential backup gets longer and longer and longer to take because we’re adding on more data every
differential backup. Restoring a differential backup is also a moderate amount of time, because we’re
not going to need any more than two sets of backup information. That would be your full backup and
the last differential backup. When you perform a differential backup, you are not clearing the archive
attribute because you’re going to perform this backup again on the next differential backup.

In an enterprise, we’ve traditionally thought of backups as something you perform to a magnetic tape.
This is a sequential storage device, because you have to forward through this tape to be able to find the
data that you’re looking for. And the tape sizes range anywhere from 100 gigabytes in size to multiple
terabytes in size for each one of those cartridges. One advantage to tape is that it’s relatively easy to
store and very easy to ship around, so this makes a perfect archive medium, especially if you’re keeping
something offsite.

Many enterprises have moved from tape backups to disk backups because the price of hard drives has
decreased so much through the years. Hard drives are also a faster medium to use if you’re writing or
reading from that drive. And it’s also a method that can be used with deduplication and compression of
data, making for a more efficient set of backups.
 And some backup strategies will use a copy or an image of a system that is an exact duplicate of a
system at a particular point in time. This may not allow you to keep different versions of a particular
image in a single backup medium, but it is something that you’re able to keep offsite and then be able to
use later on if you need to restore that system.

When you’re storing files to a drive over the network, there are two popular mechanisms that you can
use. One of these is a Network Attached Storage, or a NAS. A NAS provides access to a large storage
array that’s connected over the network. We also refer to a NAS as file-level access. This means if you
need to change any portion of a file on that NAS, you have to rewrite the entire file on that device. This
may not be a problem if these are very small files, but if you need to change or modify part of a very
large file, it will require overwriting the entire file on the NAS.

A SAN might be considered a more efficient way to store data. This is a Storage Area Network, and it’s
often configured to look and feel like a separate storage drive on your system. An important
characteristic of a SAN is that it provides block-level access. This means if you need to change a single
portion of a very large file, you only need to change that portion on the disk instead of having to rewrite
the entire file to the SAN. For both a NAS and a SAN, you obviously need plenty of bandwidth to be able
to transfer files across the network and store them in that drive array. This can sometimes require a
completely different network that is designed to only provide file access for the NAS or the SAN.

These days we’re performing more backups to the cloud. A cloud-based service can provide us with an
automatic offsite backup function, where we would be taking files on our local device and backing them
up to a device that’s located somewhere else in the cloud. This can often support many, many devices in
our environment, but it requires that we have enough bandwidth to be able to transfer these files back
and forth to that cloud-based service.

Another type of backup would be an image backup. Instead of backing up individual files on a system,
we back up everything that is on a computer and create an exact duplicate or replica of that entire file
system. This means we’re backing up the operating system, the user files, and anything else that might
be stored on that computer. If we need to restore this data, we restore an exact duplicate of that
particular system all simultaneously. This ensures that we’ll be able to restore everything to exactly the
way it was when we originally took that image backup.

When we perform these backups, it can be to an offline backup system or an online backup system.
With an offline backup system, you’re backing up your local devices to this backup component. It’s
usually something that performs very quickly, and it’s over a secure channel. We have to make sure that
the communication between the system that’s being backed up and the backup service itself is
protected and constantly maintained, and it often requires that this information be stored at an offsite
facility for disaster recovery purposes.

An online backup is one that is constantly accessible and constantly updated throughout the day. This is
one that occurs over the network, usually to a third-party or cloud-based service, and it’s usually over an
encrypted channel. Since this backup is always online, it’s often accessible from any of your devices. So
you may be able to back up to this online backup system from your workstation but be able to access
that backup from your laptop or your mobile devices. Because this online backup system is constantly
providing a backup and storing this information in the cloud, it requires enough bandwidth to be able to
transfer these files and store them in a reasonable amount of time.
 Resiliency – SY0-601 CompTIA Security+ : 2.5
There are many different strategies that should be used to maintain uptime and availability. In this
video, you’ll learn about non-persistence, high availability, the order of restoration, and technological
diversity.

A cloud-based environment is constantly in motion. We are creating new application instances and
tearing down old application instances all the time. We refer to these changes as non-persistence,
because it’s very unusual in a cloud-based environment to have any particular service, that’s always
going to be permanent. If we’re creating an application instance for a short period of time, and we want
to tear that application instance down, we may want to recover it later and continue using that service.

We can take a snapshot of that application instance and capture the current configuration, or the
configuration and all of the files that we’ve changed on that instance. Later on, if we’d like to recreate
that instance, we can use the snapshot to be able to restore from where we left off. If we take multiple
snapshots of that application instance, then we have different versions that we may be able to revert to.

This is especially useful if we install a new version of software and realize there’s an issue we could
easily revert to one of those previous snapshots. We can also separate out the data from the
configurations. If we make a change to this instance, and we realize that the data is OK, but the
configuration needs to be modified, we could roll back the configuration of the application but leave all
of the data in place.

Based on the way the application is written, we may have many options available for reverting back to
previous snapshots. And some systems will even allow us to have everything on a single boot media, so
we could plug-in a USB drive or an optical disk and be able to launch an entire system all from this single
boot drive. If you’re creating redundancy in an environment, this means that you have options should
there be some type of failure.

But that doesn’t always mean that these options will provide immediate availability or maintain uptime.
Sometimes this means that we’ll have to go to a specific machine and power it on to be able to take
advantage of this redundancy. But some redundancy is immediately available. In the case of high
availability, you may be able to have devices that are always on and always available. And if the primary
system fails you have immediate accessibility and can maintain the uptime and availability of that
application.

This also means that you might have multiple components working together. There might be multiple
firewalls that interact with multiple routers, which are then connected to multiple switches, and if any
one of those happens to fail, your system still remains up and running using this high availability. And as
it sounds, this high availability does come with a cost.

If you need to have high availability of firewalls, that usually means that you’re going to need multiple
firewalls in place, which means you’re going to need to buy two of those to be able to implement some
type of HA configuration. And there is always some type of additional contingency that could be created.
It could be multiple firewalls, then you might need multiple routers. And then you might need multiple
switches, which then might lead you to multiple power systems, which might require you to have
multiple internet providers, and so on.
You can always increase the amount of high availability, but that’s also going to increase the amount of
costs associated with that implementation. If you’re in a situation where you have to rebuild an
application instance, you need to make sure that you perform that restoration in the correct order. The
different application components will probably need to be restored in a very particular order. For
example, there may be a database that’s at the core of this application.

And all of the components that use this application instance will access this single database. That means
that you will need to restore the database before anything else is restored, because that is going to be a
key component of getting this application up and running. We also have to consider how the original
backups were made.

For example, if you took incremental backups, and you need to perform a restoration, you will need the
last full backup and then all of the incremental backups that have been made since that time frame. But
if you had a differential backup, when you perform that restore, you will only need the last full backup
and the last differential backup. And one key to providing uptime and availability is to have diversity of
technology.

For example, a zero-day vulnerability might cause an outage with a particular operating system. But if
you’re running different operating systems, you may still be able to provide uptime and availability,
because that zero-day attack is only going to affect a subset of your services. Some organizations might
implement this diversity of technology by using different types of security components.

So they might not only have a firewall, but also might implement an IPS, and they might also have a
separate spam filter. You can even add on to this a diversity of vendors, so that your firewall is from one
vendor, your IPS from a separate vendor, and the spam filter from yet a third vendor. This means not
only are you using different technologies from different manufacturers, but now you have some
flexibility during the purchase process and during the renewal process.

This might also help if you need technical support, because you’re not relying on any single vendor to
provide you with those support services. We can also be diverse with our cryptography. And if you think
about it, the cryptography we’re using today is only temporary. Eventually the capabilities we have to be
able to brute force our current key sizes is going to be surpassed by the power of the CPUs we have in
the future.

So we will eventually be providing upgraded cryptography as the years go on. We could also incorporate
cryptographic diversity today by using different certificate authorities. That way, if one happens to be
breached, we still have other components that were from a completely different certificate authority.
And from a security control perspective, diversity is incredibly important.

We might have, of course, administrative controls that determine what security policies we’re going to
use. We would then combine that with physical controls that might be locks on a door and prevent
people access to a particular area, and we’ll combine that with technical controls that require someone
to authenticate and provide access to the file system itself. All of these are combined together to create
the diversity of security controls.

And that provides us with defense in depth, which is a much better security philosophy than using only
one of those security controls.
 Embedded Systems – SY0-601 CompTIA Security+ : 2.6
We are installing an increasing amount of embedded systems on our networks. In this video, you’ll learn
about security concerns surrounding systems on a chip, field-programmable gate arrays, SCADA devices,
IoT devices, and more.

An embedded system is a computer and software that has been built for a very specific purpose. This
can be a device that is created to perform a single task, or it may be working with many other devices to
be able to perform additional tasks. These embedded systems are created with this single goal in mind.

Very often, they’re created with special hardware that fits into particular sizes, or it may be created to fit
a particular cost. Some common examples of embedded systems might be the traffic light controllers
that control the red, green, and yellow lights on the highway. It might be the digital watch that you’re
wearing.

That’s a very specific embedded system. Or maybe something like a medical imaging system, which is
created to perform a very specific medical function and does not have any capabilities outside of that
scope. Often, an embedded system is running on a System on a Chip, or an SoC. The System on a Chip
has multiple components on the single platform.

And often, there may be a single chip which handles multiple functions on that single board. These are
very common with embedded systems, primarily because they’re something you can buy off the shelf.
They’re very flexible in their capabilities. And you can customize the software to perform many different
functions.

You may not be able to tell from this picture of a Raspberry Pi, but this is a relatively small form-factor.
You can see an HDMI interface. There’s USB interfaces on the side, and an RJ45 connector for ethernet
connectivity. There’s not only support for those external interfaces, there’s usually memory that’s built
into the board itself.

And it’s very common these would have a very low power consumption, because these are very simple
devices that don’t require a huge power draw. Of course, there are security considerations to consider
when working with a System on a Chip. It may be that the hardware you’re using on this SoC device is
not able to be upgraded.

This Raspberry Pi is a very good example, where most of the components are soldered to the board.
There’s not a lot of modularity in this particular system. So it becomes very difficult to swap any
components out.

Although it might be easy to change the software that’s running on this SoC device, it would not be easy
to add additional hardware components to this, especially security type components. It would be
difficult to find a firewall or some other type of security device that you could integrate into this
hardware.

Here’s a better view of this Raspberry Pi 3 Model B. You can see that all of this is very integrated. There
are some interfaces for USB, for ethernet. There’s an AV interface, a camera interface, and a link for
HDMI, all contained on this single System on a Chip.
 A common type of hardware that you’ll find on embedded systems is an FPGA. This is a Field-
Programmable Gate Array. You can see an example of an FPGA on this particular board, right here in the
middle. This is an integrated circuit that you can program after the device is shipping.

It effectively allows you to field-program functionality within this particular FPGA. Since this is an array
of logic blocks that can be software controlled, you can have new software pushed to this device. And
that software can then effectively reprogram the FPGA.

This provides a lot of flexibility for the developer. They can ship a product. And then later on, if they
want to add new capabilities or modify the functionality of the device, they can simply add new
software which will reprogram the FPGA. This is a technology you’ll find on many different kinds of
devices. Switches, routers, firewalls, and other security components make extensive use of these FPGAs.

If your organization works with industrial hardware, then you’re probably familiar with SCADA. This is
the Supervisory Control And Data Acquisition System. You may sometimes see this referred to as an
Industrial Control System, or ICS. You’ll commonly find SCADA systems in place where there is a large
amount of industrial equipment.

So if you are in a power manufacturing facility or you have a manufacturing floor, all of that equipment
can be networked. And it can all be controlled from a computer using this SCADA network. This is useful
when you want to monitor these devices from a central management console.

And you may want to change the configuration of this industrial equipment. And you can do that all
through the front end of the SCADA system. These are not the kinds of systems that you would have
directly connected to the internet, not only because it’s impractical, but it’s also insecure.

Instead, this would be something that is segmented off from the rest of the network. And you would
have to go through some type of security controls just to gain access to the SCADA network. Devices
that would commonly be connected to the internet are the Internet of Things devices, or IoT devices.

We sometimes refer to these as smart devices. And they’re devices that can be connected to many
different types of systems inside of our homes and businesses. For example, on your air conditioning
system, you might have an IoT device handling the air control. So you’d be able to connect through an
app on your phone, and effectively see what the temperature is in your house and be able to modify the
heating or the cooling.

There’s also home automation IoT devices, such as video doorbells, garage doors, and security systems.
Or you might be wearing an Internet of Things device, such as a smartwatch or a health monitor. If
you’re working in a large facility, it might be common to plug in an IoT device that’s able to manage the
heating, the air conditioning, the quality of the air, and perhaps even the lights. This will allow a facilities
manager to be able to configure automation, and be able to keep a constant watch over all of those
components in the building.

Although these IoT devices are very functional for monitoring the heating and cooling or the video
doorbells that we might have, these are not necessarily systems that have been created by security
professionals. These IoT devices are on the internet. They’re also connected to our home networks. And
so, there is an important consideration for security.
 On my network, I have a separate network set aside for IoT devices, that is segmented from my local
home network that has all of my computers on it. That way, if someone does gain access to one of these
IoT devices, they would not have access to any of my personal data on my local home network.

Many embedded devices are very specialized. For example, a medical device, such as a heart monitor or
insulin pump, is a very specialized device that has a single goal in mind. Unfortunately, the nature of
these embedded systems doesn’t always allow the manufacturer to upgrade the operating system. So
you may find that these devices, although very important and very specialized, may be running older
versions of operating systems.

Our automobiles have now very specialized and multiple embedded systems. And you’ll find that almost
every aspect of the car has monitors sensors. And they can all communicate with each other to make
the driving experience that much better.

A similar set of specialized embedded system exists on aircraft. There’s many different networks and
many different sensors, all communicating amongst each other. This would not be a place where you
would want a denial of service. And you want to be sure that no one has access to those networks, to be
able to create any problems on an aircraft.

And in our homes and businesses, we’re starting to put more and more sensors on our utilities. And
you’ll find many embedded systems that are watching water, electrical, and other types of utility use. In
your home or business, you may be using VoIP. This is Voice over Internet Protocol, or Voice over IP.

This is the latest technology to replace what was our old analog phone lines, or what we used to call the
Plain Old Telephone Service, or POTS. Our Voice over IP telephones are very complex embedded
systems that allow us voice communication, and provide many different functions as well. Each one of
our Voice over IP phones is a standalone computer. They all have separate boot processes and
configurations. And there are many different capabilities that allow us to communicate via voice, video,
and other functions, as well.

Another common place to find an embedded system is in the air conditioning and heating systems in our
homes and businesses. This is HVAC, or the Heating, Ventilation, and Air Conditioning systems. These are
usually very complex systems, especially when you get into larger environments. And they’re usually
integrated with the fire system, as well.

There are a lot of different components all working together to provide this HVAC functionality. It’s very
common in large HVAC implementations to have a computer that monitors and maintains all of the
HVAC for the facility. This would be a computer that would be able to monitor and even change the
configuration in the heating and air conditioning systems.

And with components like this that affects so many different people in a particular building, it’s
important that we apply the proper security to these HVAC monitoring systems. We want to make sure
that no one from the outside is able to get unauthorized access to these. Because if they do that, they
can turn off all of the heating, all of the air conditioning, and create, in some cases, very dangerous
situations for the people in the building.

And what would a conversation of embedded systems be without a discussion of drones? These are
flying vehicles that are becoming more and more common in our skies. These may be devices that are
 manually controlled from the ground, or there might be some type of autonomy that will allow these
devices to perform functions without any type of human intervention.

These are increasingly used for both commercial and non-commercial uses. And at least in the United
States, you have to have a federal license to be able to fly one of these drones. It’s very common to find
security features and fail-safe functionality built into these drones. That way, if anything occurs while
this device is in the air, you can get it back on the ground safely without harming anybody else who may
be around.

An embedded device that many of us have in our homes and businesses is a printer a scanner or a fax
machine. These are sometimes referred to as Multi-function Devices, or MFDs. That’s because in a single
device, you can have a scanner, a printer, a fax machine and more, all inside of this single embedded
device.

These are multi-function devices because you may have a scanner, a printer, and a fax machine all in this
single unit. And because of that, these have become increasingly complex with very sophisticated
firmware. For example, because of the scanning functionality of this device that’s used to either scan an
image for use locally or scan a document that we can fax to someone else, those images are stored
somewhere on this device, usually with the internal memory of this multi-function device.

And it’s not unusual to have a way to retrieve those images later, whether that is something that is
intended or not intended by the MFD manufacturer. There might also be logs on this device that can
give an attacker information about who this device has communicated with, or what phone numbers
have received faxes.

The embedded devices that we have in our automobiles or the industrial equipment that we’re using
very often will use an RTOS, or a Real-Time Operating System. This is an operating system that’s
designed to work on a very deterministic schedule. This means that the hardware and software of this
device is able to operate with very specific scheduling.

This also means that there’s no process on this particular device that would override or take control of
the system, and not allow other parts of the system to operate. A good example of this is the Real-Time
Operating System that’s used for the anti-lock brakes that are in our automobiles, because those need
very specific updates on the wheel slippage that is occurring when someone’s trying to brake their car.

This adds a bit of complexity when you add some security aspects to a Real-Time Operating System. You
don’t want the security system to get in the way of the Real-Time Operating System. But you also want
to be sure that the RTOS is secure. Because of the nature of these Real-Time Systems, it’s often difficult
to know exactly what’s running inside of those embedded systems. So you may not know what type of
security is even running inside of that Real-Time Operating System.

The cameras and the monitoring systems we’re using for video surveillance are also embedded systems.
The cameras themselves have become very advanced with their functionality, and being able to change
what they can see during the day versus what they can see at night. There’s motion sensitive
functionality, or even the ability to track different objects as they’re going through the camera’s vision.

These cameras might also be monitoring very sensitive areas. So it’s important to make sure that the
proper security is put into the monitoring systems, so that only authorized users are able to see what
the cameras are seeing. These cameras may be mounted very high on a building or they might be on the
roof.

So it may not be very easy to change a camera or replace that hardware. Many of these cameras,
though, do support firmware upgrades. So there may be a way to constantly monitor and protect those
systems when security patches are released.

Embedded Systems Communication – SY0-601 CompTIA Security+ : 2.6

Embedded systems can use many different methods for communication. In this video, you’ll learn how
embedded systems use 5G, narrowband, baseband, and Zigbee networks.

With the increasing number of embedded systems that are being deployed, it’s important to know how
these devices communicate to each other. So in this video, we’ll look at the methods for embedded
system communication.

The fifth generation of cellular communication is 5G, and it’s a technology that was introduced in 2020
to be able to provide high-speed communication over wireless networks. 5G communication can use
very high frequencies to be able to get speeds that are upwards to 10 gigabits per second. Many of the
more common connections will probably be around 100 to 900 megabits per second, but that is still a
significant throughput that can be used over these wireless cellular networks.

These are going to have a dramatic impact on the capabilities of our internet, of things devices, these
will have large amounts of bandwidth available to these devices, you’ll be able to transfer larger
amounts of data, there will be faster networking and notification of these devices, and there will be the
ability to send more information into the cloud, hopefully, to provide even more processing
functionality, using these high speed 5G networks.

To connect over one of these cellular networks, you need to have a Subscriber Identity Module or what
we commonly call a SIM card. This is a universal standard for an integrated circuit card, and it’s common
to see these in our mobile phones. But of course, if you have internet of things devices that will be using
these 5G networks, then they’ll also need a Sim card inside of those IoT devices.

These SIM cards provide that important connection, between the internet of things device, and the
cellular network. These will often contain an IMSI. This is an International Mobile Subscriber Identity
value. This allows the mobile network provider to be able to recognize this SIM card and be able to add
it to the cellular network. This might also contain authentication details, contact information, and other
important information about the IoT device.

If you’re managing a large number of IoT devices that are connected over a cellular network, then you’re
probably going to be responsible for managing all of the SIM cards that are connected to those IoT
devices.

If the embedded device is not using the cellular network to communicate, then it may be using
frequencies over a narrowband connection. This is allowing communication across a very narrow range
of frequencies, and it’s very common to be able to send this communication over these bands, across a
very long distance.
 As you can see by this picture, this narrowband signal, uses a smaller amount of the frequency
bandwidth, than a broadband signal might allowing you to have many different communications in a
single set of frequencies, and very often this can communicate over much longer distances.

You might find this narrowband communication, where there is SCADA equipment, or sensors, that are
in oil fields, and these sensors may be distributed across a very large geographical distance.

If broadband is using a large number of frequencies to be able to communicate, then a baseband is using
a single frequency to be able to communicate. This is very often done over a single cable or a single fiber
connection, and it’s usually using a digital communication. Since there is a single frequency being used
for this communication, anything going over this link is going to use all of the bandwidth on that
connection.

This can support bidirectional communication, although the communication is usually going one way or
the other, over a particular fiber, or copper connection. It’s very common to see baseband being used
on our wired ethernet connections. For example, the 100 megabit, 100BASE-TX, the gigabit, 1,000BASE-
T, and the 10 gig, 10GBASE-T, are all ethernet standards using baseband, and the term, base, in the
name is referring directly to that baseband communication.

But you may notice that your internet of things devices in your home are not connecting using a wire,
they’re communicating over wireless networks. And they are very commonly using a standard called
Zigbee. This is an IEEE standard, specifically standard, 802.15.4 Personal Area Network, and you can see
based on that name, why we call it Zigbee.

This is an alternative to WiFi, it’s different than Bluetooth, it’s a way to communicate with all of these
IoT devices, over longer distances, using less power. This also allows all of your IoT devices to create a
mesh network. This means that devices on one end of the home can hop through other IoT devices to
communicate with your management stations, that might be on the other side of your home.

This means if you’re changing the temperature of your air conditioning controls, or you’re modifying the
lighting on these IoT devices, it’s eventually communicating through the Zigbee network, to be able to
control that device.

In the United States, Zigbee communicates over the ISM band. This is the Industrial, Scientific, and
Medical band, and there are frequencies in the 900 megahertz and 2.4 GHz frequencies that are used by
Zigbee. This means that you can have all of these IoT devices meshed together and use this wireless
communication, without any special licensing required to be able to communicate, on these
frequencies.

Embedded Systems Constraints – SY0-601 CompTIA Security+ : 2.6

There are advantages and disadvantages when using embedded systems. In this video, you’ll learn about
the limitations associated with power, networking, upgradability, patching, and more.

One of the challenges you have with embedded systems is they’re usually running on a device that is not
a fully capable computer. This is often a low cost device sometimes it has been purpose built or maybe
using off the shelf like this Raspberry Pi. And so there are a number of constraints associated with this
design. As you can see from this example, there may be limited number of features available.
 There may be interfaces on this device that you might have on your home computer that simply won’t
appear on this embedded device. This is also very difficult to upgrade there may be operating system
limitations on the size of the storage of this device. And as you can tell it would be very difficult to
upgrade the hardware of this embedded device.

There might also be a limitation in the type of communication. This device has wired interfaces but the
embedded device used somewhere else may only be able to communicate over wireless and over
specific wireless technologies. But that’s usually the trade you have with embedded devices because
they’ve been built to perform a specific function. There’s no need to put additional memory or
additional communications capabilities in these devices if they’re never going to use that functionality.
We can keep our costs down because we built this device to perform that single function but of course,
this comes at the trade of having this additional functionality.

A common constraint for these embedded devices is power. We’re often putting these devices out in
the field and there may not be a direct power source for this embedded device. Often we’re plugging
into a battery connection or we’re recharging the batteries with solar power throughout the day. There
may also be times where you have to physically service the embedded device just to change the
batteries out because there’s no other option for powering that unit.

These embedded devices are low cost devices they’re often purchased off the shelf. And that means we
might have limitations over the CPU and computing power of the embedded device. This may not
necessarily be a bad thing lower speed CPUs tend to create less heat and that may be an advantage
especially for these smaller devices.

The location of these embedded devices can also limit what we’re able to boot from a networking
perspective. If this is a sensor that’s on an oil pump in the middle of a field we may not have the ability
to run an ethernet connection or be able to connect it to a tornado 2.11 wireless network. The
geographical location of the embedded device may determine what type of networking can be used by
this device. So there may be trade off as to the type of network and the speeds we may have available
to communicate to that embedded device.

These low cost embedded devices also don’t have a lot of additional cryptographic capabilities. There is
a CPU but of course, that CPU is limited. And there’s usually no additional cryptography hardware on
that device unless it’s been designed that way from the very beginning. If we need to add or change
cryptography functionality you’re probably not going to be able to do that using the hardware on that
device.

Many of these purpose built devices have no physical keyboard or mouse there may not even be a video
connection and that complicates the upgradability of these devices. You may not be able to connect to
this device over the network to perform a firmware upgrade. And you may have to visit the device
directly to plug-in a USB drive or some other type of firmware upgrade process.

If there is any type of security on these embedded devices, it’s often an afterthought. It may be that
there’s no authentication required to gain access to the firmware on the system or it may be a very
limited type of authentication. We’re used to using things like multi-factor authentication and
connecting to directory services with our mobile devices and our laptop computers. But these are
functions you may not find on an embedded device.
 These embedded devices also have a very specific function and it’s unusual for that device to have any
additional capabilities beyond that. This is not usually a device that allows you to add on additional
functionality after the fact because it has been specifically engineered and designed to perform that
single function. And additional capabilities was not in the original plan.

Being able to have an embedded device that performs one particular function means that we can design
it very specifically just for that function and nothing else. By designing this way we can keep costs low,
which is especially important if we’re creating a lot of these embedded devices. We also have to think
about how using lower cost components may affect the quality of that device. By using the lower cost
components we may be limiting the lifespan of that particular embedded device.

And with many of these embedded devices you don’t have direct access to the operating system or the
software that’s running on that device. And it may be very difficult to gain access to the operating
system on that device. From a security perspective, we’d like to be able to audit that device, make sure
the operating system is up to date, make sure there’s no security issues. But if you don’t have access to
the hardware software makes it very difficult to perform that task.

Physical Security Controls – SY0-601 CompTIA Security+ : 2.7

We often focus on digital technologies to protect our networks, but there are many physical devices that
can provide additional security. In this video, you’ll learn about access control vestibules, alarms, signs,
industrial camouflage, and more.

If you would like to limit the access to a particular area you might want to use a barricade or a bollard.
These are used to prevent people from accessing a particular area or in the case of bollards usually
would prevent someone in a car or truck from entering an area. These can be used to restrict access
temporarily to a particular area, for example, there may be construction going on and instead of having
people walk through the construction area, you could surround it with barricades.

You could also use something like bollards, which are these concrete poles which are designed to stop
large items from being able to pass through an area. This could be used as a concrete barrier to prevent
cars or trucks from entering a particular location. And you could use a water feature such as a moat to
surround an area and that would create a natural barricade.

If you’ve ever visited a highly secure data center then you probably step through an access control
vestibule. There’s usually a door providing access to the vestibule and another door providing access to
the data center that’s just beyond. The configuration of the door locking mechanisms will depend on the
vestibule that you’re using.

For example, it might be that all doors are normally unlocked until one person opens a door. And as
soon as that door is open all of the other doors in the vestibule are locked automatically, or it could be
that all the doors are normally locked and if you unlock one of those doors it restricts any of the other
doors from being unlocked at the same time.

And it may be that these locking mechanism is based on whether the doors open or not. If someone
opens the door it may restrict other doors from being open at the same time. This allows the person
who’s managing access to the data center to control exactly who may be allowed access through the
vestibule and to limit how many people can pass through at any particular time.
 Here is the view from outside of an access control vestibule, looks like you need to first authenticate to
gain access through the locked door. Once inside you may have to provide some type of identification to
whoever may be sitting here for security. And then inside the room that security would then open the
second door and allow you access to the data center.

Another type of physical security device is an alarm system. If you have an alarm system on a door or
window you know that the alarm goes off if that door happens to open or the window is open, that’s
usually based on a circuit. There’s usually a sensor connected to the door or window and if that door
window moves then the circuit is broken and the alarm goes off.

There are also motion detection that you can get with certain alarms that will look for reflections or
some type of infrared motion and be able to alarm if it happens to see either of those. Your alarm
system might also have a duress button, sometimes this is called a panic button if you feel the situation
is threatening and you want to be able to call for a third party you can push the panic button and it will
handle calling for additional reinforcements.

It’s always important to provide signage, so that people know exactly what should be expected from an
area. There may be certain types of protection that are required, maybe a particular group of people is
allowed or not allowed on a location and there may be a requirement to inform people of a dangerous
environment.

This is not only important for the people that work in a particular area but you also have to consider
visitors who’ve never been in the area before and know nothing of the requirements or the potential
danger of an area. Signs for personal safety may provide information about fire exits, there may be
warning signs that describe where there may be chemicals or other types of construction going on. And
it may be useful to also point people towards medical resources or first aid kits.

And although this sign doesn’t have any contact information, it might be useful to add some contact
details here especially if there are any emergencies. If you have a very large facility, you may want to
consider adding video surveillance, this is sometimes seen as a CCTV or closed circuit television,
especially if it’s an environment that’s only accessible from that single facility.

The features that are enabled in these cameras can also be important, some cameras can constantly
monitor an area but only inform you if there happens to be some type of motion detection. Or there
may be specific object detection built into the camera that can recognize whether something moving
through the camera range is an automobile or a person’s face and be able to lock onto that and track it
as it moves from place to place.

Very often many cameras are installed in a single facility and all of those cameras are brought back to a
single recording device. From that device you can either monitor in real time or be able to go back in
time to see what may have happened previously. I visited probably hundreds of data centers and it’s
remarkable how many of them you may have driven by not realizing that just inside that building was
millions of dollars of technology.

This is industrial camouflage; it’s concealing what would be an important facility behind what is normally
seen in a particular area. If you’re in an industrial area this looks like a building that could be a
warehouse, it might be a small workplace, or it could possibly be a data center. Of course, you wouldn’t
 put signs telling people that the data center is here and looking at this there doesn’t seem to be any
type of visual cue that tells us that inside of this building is a data center.

I’ve visited data centers that have water features around them to prevent people from gaining access
and they might have a guard gate in front that would prevent someone from driving in. If you ever look
at a data center like this you may even find that they’re big planters in the front that are actually
bollards, very large concrete devices that would prevent somebody from driving into or through the
walls of that building.

Although we can automate many aspects of security one of the best physical security features we have
are people. And we can put guards and access lists in front of a facility to be able to have a human
interaction with who might be coming in. This would provide a validation of existing employees and
allow them access to the building and it would allow someone to provide authentication of any guest
that may be arriving and make sure that they have the proper access to the facility.

In many environments you’re required to carry around an ID badge and display that badge at all times,
so that anyone walking by can easily see that you are where you are supposed to be in that building. If
there is a security guard, they may be able to look at an access list to confirm whether someone should
have or not have access to a particular part of that facility.

And if you’re an employee you’re probably using that ID badge to unlock a door which of course will
create a log entry. If you’re a visitor, the security guard is usually adding your name to a visitor logs, so
that everyone knows exactly who has gained access to that facility. If you’ve worked somewhere with
security guards you may have noticed that it’s unusual to have a single security guard working.

It’s very common to see more than one working at the same time, this is called two-person integrity or
two-person control. This is a way to minimize the exposure you might have especially for someone who
is in control of access to a building. This two-person integrity ensures that no single person would have
access to any particular asset in the building, for example, to enter a locked area may require two
separate security guards to be present.

And in some facilities we can replace a human who’s doing rounds and checking things periodically with
a robot, this is an emerging technology but it’s one that allows us to replace the human with something
that is much more automated and then have our human guards perform much more important tasks.

If you’ve ever gained access to a room or through a locked door using a fingerprint or handprint then
you were using biometrics. Biometrics can also be used for retinas, and voice prints or anything that
might be associated with an individual. This is usually storing a mathematical representation of
something you are, so this might store a mathematical representation of your fingerprint and not the
actual picture of your fingerprint.

But of course your fingerprint is something that is very difficult to change and it’s something that’s also
very difficult for someone else to duplicate. This means that, that particular mathematical
representation is something that could only be associated with you. These biometrics are powerful
physical controls but they aren’t foolproof.

We very commonly would combine biometrics with some other type of authentication. This particular
biometric system requires you to put in a biometric fingerprint and then also include a personal
 identification number. The secondary bit of authentication is one that makes sure that the person is
providing the biometrics is the person who really should gain access into that room.

And indeed there are many different ways to control access through a door, for example, a traditional
lock and key is one of the most common and well-known ways of locking a facility. This door might
include a deadbolt for additional security. And if this is an office you may be using an electronic lock, this
could be a keyless lock like the one shown here or it may require you to put in a personal identification
number.

There might also be locks that are based on a token, this would be one that’s associated with an RFID
badge like this one. It could be a magnetic swipe card or it might be a key fob that’s connected to your
key ring. We’ve already seen that biometrics can be used for door locks especially handprints or
fingerprints and in some cases, you might even use a smart card with a personal identification number
to gain access through a locked door.

Here’s the inside of one of those RFID badges, you can see the antenna around the outside that receives
the power for the RFID and is able to send and receive signals and on the inside of this is the RFID chip
itself. Cable locks are often used to prevent a piece of equipment from being stolen in an area, these are
usually temporary locks but they’re ones that can be connected to almost anything around you.

For example, you may connect a cable lock to a laptop and then connect the other end of that cable to
something sturdy that can’t be moved such as the leg of a table. This is a standard type of connector
that has a reinforced notch and if you look at your laptop you’ll probably see on the side of it that there
is a notch that is perfectly sized to fit one of these cable locks.

This is obviously not something that is built for long-term protection and you can see by the size of this
cable that it would not be very difficult for someone to cut through with the right equipment. But if
you’re in an area temporarily and you simply want to prevent a piece of equipment from being stolen
while you happen to be working this might be a great way to provide that level of security.

In a previous video we talked about an exploit called Juice jacking– this is where you’re connecting your
mobile device like a mobile phone to a USB charging port. That USB charging port is also transferring
information over the data lines as well. And if your device is susceptible to this juice jacking you may be
unknowingly providing your data to a third party.

This is why some people will use a USB data blocker like this small cable here, which connects to the USB
interface but only connects to the power lines of the USB connection and not the data connections. And
if you are someone who is traveling or needs access to power in an area where normally you would not
be working it may be worth your while to bring along your own power adapter and avoid this problem
entirely.

Providing proper lighting is one of the best security controls you can have, especially in environments
that need to be monitored 24 hours a day. The attackers avoid any place that may be lit, because they
don’t want to be seen. It’s easier to see exactly who might be in a particular area if there’s plenty of
lighting and if you’re using cameras that don’t use infrared then you’ll want as much lighting as possible
to get the best possible picture.
There are many different kinds of lighting and many different ways to install these lights, so you want to
make sure that the lighting for an area matches the requirements that you have for security. You want
to make sure you’re providing enough light levels for the cameras or the people who need to be
monitoring that area.

You also have to think about the lighting angles especially if there are shadows and you’re doing some
type of facial recognition. This can be especially useful for cameras that need to avoid any shadows and
glare to be able to get the best possible picture. Although fences are very good ways to prevent
someone from gaining access to an area they might also advertise that you have something in this area
that you don’t want people to gain access to.

And it may be that you have to use different types of fences depending on the security that you need. If
it’s OK for people to be able to see into a particular area, then you may want a fence that you’re able to
look through. This of course also means that you’re able to look out to see who may be on the other side
of the fence.

But there may be times when people shouldn’t have access to be able to see what’s on the inside and in
those cases you may want to use an opaque fence. With the right kind of fence you have a very solid
security barrier, this is usually a fence that might be very difficult to cut through and usually they’re tall
enough to prevent somebody from climbing over the fence especially if you add razor wire or some
other method to prevent somebody from gaining access over this fence.

When we’re putting together plans for physical security, we’re planning for the worst possible scenario.
And one of those scenarios might involve a fire, especially a fire in an area with lots of electronics. In
that situation you wouldn’t necessarily want to use water but instead use some other type of fire
suppressant.

You’ll first want some type of warning or alarm that the potential for fire exists, there may be a smoke
detector, flame detector, or heat detector that can tell you when this situation may be occurring. You
may want to use water where appropriate, especially if there isn’t a lot of electronics. But if there is
something that is plugged into the wall you may want to use chemicals.

We used to use halon for this method but these days we use something that’s a little better for the
environment, such as DuPont’s FM-100 and this is a chemical fire suppression that would be able to put
out the fire in a data center without completely destroying all of the electronics. It’s usually useful for
the security team to be informed or get an alert if something is occurring in an area that they aren’t
actively watching.

We would commonly want to have sensors that are deployed that provide us with this type of
information. For example, you may want a motion detection sensor, so that you could tell if anyone else
happens to be in a particular area. This might also be combined with noise detection, so that you could
see if there are any noises occurring in an area and recognize if any increase or decrease in sound is
occurring.

If you need to gain access to a room there may be an electronic code reader which has a sensor inside of
that, that recognizes the RFID chip that’s in your access card. You might also want to include moisture
detection which might tell you if there is a water pipe that breaks and water begins flowing out onto the
floor. You might be able to get a heads up very quickly and prevent any further water damage.
If you’re in a data center, one common sensor to have been a temperature sensor especially when you
have all of this equipment that can very quickly heat up the room. It’s nice to know if there happens to
be a spike or an increase in that temperature, which may show you that there is a problem with the
cooling system in the data center.

Some security teams have started to use drones to be able to monitor large areas especially when those
areas are places that would not be easy to access through a car or by walking. This might be a situation
where there are multiple buildings, and you could have a drone quickly cover a very large area in a very
short period of time.

These drones may not be used for constant security but may be used for very specific situations. For
example, if you need to perform a site survey or be able to assess the damage that may have occurred
already at a facility, a drone would be a great way to deploy and be able to get a wide view of a
particular area.

Mini drones include sensors that may show us motion or any type of heat in an area and mini drones
include high resolution video, so that you’re able to get a recorded view of exactly what the drone was
able to see. Some specialized environments may have a Faraday cage, this is a method of signal
suppression that was originally created by Michael Faraday in 1836.

This is a mesh of conductive material that either restricts or prevents radio signals from traversing
through this particular cage. A good example of this is the window on a microwave oven, which allows
you to see in but prevents any of those microwaves from getting out. This is not a solution that blocks
every type of radio signal and there are some types of radio signals that can’t be blocked by a Faraday
cage.

You also have to keep in mind that if you’re blocking radio signals you could be blocking the ability for
someone to call for help or call 911 on their mobile device. So there always needs to be a way for
someone to gain access to a proper emergency service, even if you’re blocking those signals. If you’re
working on an internal network and you realize you have something you need to provide access to
people on the internet you may not want those people getting into the internal network of your
organization.

In those cases, you may want to build a separate physical network called a screen subnet. We used to
call this a demilitarized zone or a DMZ, this is a network that does have controlled access usually
through a firewall and people coming in through the internet would have access to the services that are
on the screen subnet.

But this would also prevent these people from the internet from gaining access to your internal
network. So you can still keep all of your private resources private and still provide access and resources
to the people that might need it from the internet. In some very secure facilities we have to think about
the access that people might have to the cabling and the fiber that are running our networks.

This is a protected distribution system or PDS and it usually requires that you have all of your network
cables and infrastructure behind some type of protected environment. This means that all of your cables
and fibers that are on your networks may be inside of a metal conduit, which would effectively prevent
somebody from gaining physical access to those cables.
 This also means that someone wouldn’t be able to break a cable apart and put their own tap in the
middle effectively allowing them access to all of the data that flows over that cable. This might also
prevent a denial of service, because if you’ve got all of your cables inside of this metal conduit no one
would be able to cut or modify any of those cables or fibers. And to ensure the ongoing security of your
protected distribution system, it’s very common to have periodic audits to make sure that nobody can
gain access to your networking infrastructure.

Secure Areas – SY0-601 CompTIA Security+ : 2.7

The security of a network can sometimes be related to a physical location. In this video, you’ll learn
about air gaps, vaults, safe, and hot and cold aisles.

In the world of IT security, we’re often concerned about making sure that no one is able to access
through the network to our important internal assets. But it’s just as important that we create a physical
barrier from the outside to all of our internal systems as well.

This is something that should be part of security policy. It should be built in to the normal operations of
your organization. And the goal would be to prevent anyone from the outside from gaining physical
access to your systems. Although we have firewalls that would prevent someone from digitally gaining
access to these devices, we have to have physical security controls to prevent physical access to these
devices. If someone had physical access to your computer or to a server, they would effectively be able
to circumvent all of those security controls.

And just as we have to control access to our live systems, we also have to control access to our backups.
Our backup systems have all of the data that’s contained on those servers. So they are just as important
to secure as the live running systems.

An air gap is a way to provide a physical separation between devices or between networks. This might
be a common way to prevent access between a secure network and an insecure network. Or you may
want to have an air gap between different customer’s networks.

In many environments, the entire infrastructure is on one big shared network. So you’re able to move
between different systems, different virtualized environments, and move using the existing switches and
routers on that network. But in some networks, we need an air gap. We need a physical disconnection
so that it would never be possible for someone on one network to gain access to resources that might
be on another network.

A good example of this are stock market networks, or power systems, or perhaps it’s the networks that
we have in our airplanes, or nuclear power plants. These would be networks where we never want
someone to gain access to these networks– even accidentally. So having an air gap network would
provide physical isolation and restrict access to those resources.

We talked earlier about controlling access to backups and other resources. And it’s not unusual for large
organizations to have an entire secured room where they can store this valuable information. This
would be a vault or an entire secure room where you might keep all of those backup tapes. This would
also be a great place to keep any other type of protected resources or resources you might need if there
was some type of outage or natural disaster.
 These vaults are commonly onsite in a facility that you’re able to access while you’re in the building. If
your facility isn’t large enough to support a vault, then perhaps all you need is a safe. It has the same
type of safety and locking mechanisms as a vault.

But it’s something that’s a lot smaller. It’s also a lot less expensive to implement. You can usually install
one onto an existing area of the room. This does have limited space, however– does not have as much
room as a vault might. But it would allow you to install this at many other locations rather than having
one centralized vault in one building.

Another important secure area in a data center are the hot and the cold aisles that are used in that
facility. In a data center, we have a lot of equipment. It’s usually stored in racks inside of that data
center. And all of that equipment is constantly generating heat.

To be able to offset all of this heat, we usually have extensive cooling systems in these data centers.
That cooling system is able to cool all of the equipment in this rack and keep them all at an optimal
temperature. One of the environmental challenges the data center administrators have is they need to
keep this equipment cool.

But this is a very large room. And, relatively speaking, the equipment in the room is taking up a relatively
small amount of space. It would be much better if we could only cool the sections of the room where
the cooling is required and not have to worry about the environment elsewhere in the room.

To be able to do that, we separate the room into cold aisles and hot aisles. The equipment that’s in
these racks– it’s designed to blow air in a single direction. Cool air is provided to the equipment on the
cold side, or cold aisle. That is sent through the equipment and heated up into the hot aisle. On the hot
aisle, we have ventilation equipment that captures the hot air and sends it back into the cooling system
to simply recycle that back into the cold aisle.

Here’s a data center using a hot aisle containment system where all of the hot air is trapped inside of
this area. We have cold air that’s coming up through the bottom of these racks. All of that cold air is
pushed through those systems and into the hot aisle. And that hot air is going to be captured up high
and sent back into the cooling system, where it’s recycled back through the cold aisle.

Secure Data Destruction – SY0-601 CompTIA Security+ : 2.7

There are many ways to permanently remove data from a storage device. In this video, you’ll learn
about physical destruction, purging data, and data wiping.

As a security professional, you’ll be tasked with knowing what data can be destroyed and what data
must not be destroyed. There’s usually a data destruction and media sanitization policy as part of your
normal security policies, and this can sometimes be a legal issue. There may be types of information,
such as emails, where you are legally obligated to keep that information around and it must be stored
for future reference. You might even want to consider having an offsite storage to be able to have all of
that information archived.

You also don’t want to take something that is critical information and throw it out with the regular trash.
This would mean anyone going through your trash or your garbage cans would be able to find any of this
media or this printed material. Physically destroying the drives may be a much better idea than simply
throwing them out with the trash. And in some cases, we want to be able to reuse these storage devices
for other purposes in our organization, but you want to be sure that no one would be able to recover
any of the previous data, so sanitizing these storage devices the proper way will make sure that no one
can go back and see anything that was stored on that device previously.

If you’re throwing out printed material or any type of media, you want to be sure that your garbage
facility is secure. Usually you want to put this behind a fence and often use a lock so that third parties
can’t gain access into that garbage. You might also want to shred all of these important documents so
that no one would be able to read anything that’s there. Of course, you can only go so far with the
shredding process. This takes time and money, and of course someone who really has a lot of time could
put all of these small pieces of shredded documents back together.

That’s why many governments will simply burn any of the documents that they don’t want somebody
else to read, because there’s no way to undo that burning process. And if you really wanted to be sure
that all of these documents were unreadable, you would pulp this paper, which would be removing the
ink from the paper and recycling the paper so that no one would be able to read what was there
previously.

One way to prevent anybody from gaining access to the data stored on our storage devices might be to
physically destroy our hard drives and other storage media. You might want to use a shredder or a
pulverizer to do that, or simply use a drill to put a hole directly through the hard drive, which would
mean no one would be able to read anything on that drive. You can also use a hammer to break these
platters, which would also prevent anyone from recovering any data.

You can also use a strong magnetic field, which is a degausser, to be able to remove all of the data that
is stored on the magnetic fields of this hard drive. Not only does this delete the data from the platter, it
also removes any of the important configuration information on the drive, which means that this hard
drive would never be able to be used again. And like our paper media, we could also burn our digital
media as well. There are organizations that will incinerate your digital information, making sure that no
one would be able to recover that data.

You usually don’t have a pulverizer or an incineration tool inside of a facility, so you’re often sending this
equipment out to a third party and having them do the pulverizing or the incineration. In that scenario,
you need some type of evidence that the destruction was actually done. These certificates are provided
by a third party that confirms that they were able to destroy everything on these drives, and they
provide you with the documentation or paper trail that shows exactly what serial numbers and devices
were destroyed by this third party.

If you don’t want to destroy the media– you may just want to remove some of the data from the media.
If you want to remove a portion of the data, then you’re doing a purging of that information. This would
remove a single file or a section of data from an existing data store. For example, if you want to delete
some of the data that’s in a database, you would simply perform a purge on that data.

In some cases, we want to remove data so that it could never be restored. And in that case, we would
want to wipe that particular data. This is an unrecoverable removal of that data. So not only are we
deleting the file or deleting that section of the database, we’re making it so that that data could never
be restored on that system. This is the process we would normally go through if we wanted to reuse
that hard drive or reuse that storage media on another system but make sure that the person using it on
that other system would not be able to recover the original data.

There could be significant financial reasons to make sure this data is erased. An example of this occurred
in July of 2013 with the UK National Health Service Surrey. They had hard drives that were sent to a third
party to be destroyed, but the third party did not destroy those drives and instead sold those drives on
eBay without removing any of the data. A person who purchased this drive on eBay contacted
authorities, and the National Health Service was fined 200,000 pounds.

There are a number of relatively simple ways to be able to remove this data so that no one would have
gained access to it. To do individual files, you could use something like SDelete, which is a utility
available from Windows Sysinternals. You might also want to delete everything on the drive. There are
many utilities to do this. One of the more popular is DBAN, which is called Darik’s Boot and Nuke.

And lastly, if you wanted to physically destroy the drive, that would be the ultimate way to make sure
that no one would gain access to that data. And you can either destroy a device yourself or send large
groups of devices off to be destroyed by a third party.

Cryptography Concepts – SY0-601 CompTIA Security+ : 2.8

The fundamentals of cryptography apply to many aspects of IT security. In this video, you’ll learn about
cryptographic concepts such as keys, lightweight cryptography, key stretching, and homomorphic
encryption.

The word cryptography is derived from the Greek word kryptos, which means hidden or secret. That’s
certainly how we use cryptography in IT security. This includes confidentiality, which means we can
make information secretive. We can encrypt data so that nobody else can see that data. We can also
provide authentication and access control, so that we can verify a person who might be logging into a
system is really that person.

And we can provide non-repudiation, which means if someone sends us information, we can verify that
they were really the person who provided us with that information. And cryptography also provides us
with a way to verify integrity. If we download a file or an email, we can verify that that email or that file
was never changed from the time that it was originally sent.

There are a number of terms that you’ll hear use with cryptography. The first one we’ll look at is plain
text. This is the unencrypted message that you usually start with. We often refer to this as in the clear
message. When we encrypt this plain text, it’s called a ciphertext. That’s because we used a cipher to be
able to encrypt and protect the information contained in that plain text.

If you’re a researcher who’s trying to find vulnerabilities in these ciphers, then you’re performing
cryptanalysis. This is the art of cracking the encryption that already exists. And finding those vulnerable
ciphers is an important part of cryptography. It allows us to identify and stop using vulnerable
cryptography and focus instead on using strong cryptography.

When you’re encrypting data, it’s very common for everyone to understand the encryption and
decryption process. And very commonly, those ciphers are publicly available for anyone to read. The
part that is unknown is the key. The cryptographic key is information that is added to the cipher to be
 able to encrypt the plain text. Usually, larger keys create more secure encrypted data. And sometimes
using multiple keys in this encryption cipher create another level of protection.

Because larger keys tend to be more secure, we like to use encryption methods that use the largest
possible keys. But we don’t always have a large encryption key that we’re able to use. So instead of
using a large encryption key, we’ll take a relatively small encryption key and find ways to make it larger.
For example, we could hash a password and then hash the hash of the password, and so on. This is
sometimes referred to as key stretching, or key strengthening.

This makes it very difficult for an attacker to be able to brute force the original plain text. They would
have to brute force each one of the subsequent hashes to be able to finally get back to the original
plaintext. This means the attacker has to spend much more time on the brute force process, making it
that much more difficult to be able to determine what the original plaintext might have been.

Fortunately if you’re a programmer, you don’t have to create one of these key-stretching algorithms
from scratch. There are a number of libraries that already exist to do this. For example, the bcrypt
library will generate hashes from passwords and it is an extension to the already existing UNIX crypt
library. Bcrypt uses the Blowfish cipher to perform these multiple rounds of hashing on the plain text.

Another common key-stretching library is the PBKDF2. This is the password-based Key Derivation
Function Number Two. It’s part of the RSA public key cryptography standards, and it’s a library that you
can use to make your applications much more secure. If you’re performing a cryptographic function, this
usually requires extensive CPU and additional resources.

But there’s a type of cryptography that’s focused on providing these cryptographic functions without
having a high-end CPU, and without using a lot of power. This is lightweight cryptography. And the
emphasis of this line of research is coming from internet of things devices, or IoT devices, which have
limited CPU and limited power available. There’s a great deal of research being done on lightweight
cryptography. And it’s being led by the National Institute of Standards and Technology, or NIST.

They want to find ways to provide the most powerful cryptography using the least amount of power,
which would be perfect for these internet of things devices. Another emerging cryptographic technology
is homomorphic encryption, or HE. When you work with encrypted data, it’s very difficult to perform
some type of action to that data. You would commonly need to decrypt the data, perform the function
on the decrypted data, and then re-encrypt the answer once you have it. With homomorphic
encryption, you perform the calculation, while the data remains encrypted.

You can perform calculations on data, in its encrypted form, and save the results as encrypted data, the
entire time never having decrypted any of that information. This provides a number of advantages,
especially if you’re storing information in the cloud. That data can always be in an encrypted form. And
it also allows people to perform actions on this data, and get research information from the data,
without ever having access to the original data source.

Symmetric and Asymmetric Cryptography – SY0-601 CompTIA Security+ : 2.8

Symmetric and asymmetric cryptography are the fundamentals of our data security. In this video, you’ll
learn about symmetric encryption, asymmetric encryption, creating the key pair, and sending data
securely using both symmetric and asymmetric cryptography.
 Let’s begin our conversation of the differences between symmetric encryption and asymmetric
encryption, by focusing first on symmetric encryption. This is encryption where you use a single key to
encrypt the data, and when you want to decrypt the data, you use exactly the same key to decrypt it.

This means that if this key does become available for others to see, that you’ll have to completely redo
all of your encryption because now everyone has a copy of the key that can be used to decrypt this data.

You’ll sometimes hear symmetric encryption referred to as a secret-key algorithm or a shared secret.
That’s because that single key is the secret that everyone needs to know, to be able to decrypt the
information. One of the challenges you have with symmetric encryption is it’s difficult to scale.

How do you share a key with others, when you don’t currently have a way to encrypt that information?
You can think of this as somebody carrying the key in a locked case, they’re protecting the key until they
get to their destination, and only then can they share that key with another person.

But across the network, you don’t have a locked case. And since you don’t have a key that both sides can
share, you don’t have a way to encrypt the key, to be able to send it to the other side. This means we
have to find other ways to be able to share this key so that we can use symmetric encryption.

One way to get around this problem of scalability is to use asymmetric encryption. The problem, though,
is that asymmetric encryption requires more overhead and more work by the CPU. Symmetric
encryption requires relatively fewer resources than asymmetric encryption.

Often, you’ll see the two combine, where you’ll use asymmetric encryption in order to transfer a
symmetric key to someone else. So very often those two algorithm types are used in conjunction with
each other.

Unlike symmetric encryption, where there is a single key, with asymmetric encryption, there are
multiple keys. You’ll sometimes hear this referred to as public-key cryptography, because, there is a
public key and a private key. In some situations, there can even be more than two keys, but for the
examples that will give today, we’ll deal with the two keys, a public key, and the private key.

The private key as the name implies, is the key that only you have access to. It is a private key because
nobody else knows what that key is. There is another key that is mathematically related to the private
key called the public key. This is the key that you give to everybody.

You can post the public key on a public key server, you can hand it out to people in email messages, you
can put it on your website, and everyone who wants to be able to encrypt information and send it to
you needs to have your public key.

Once somebody encrypts data with that public key, the only way to decrypt that information is by using
the corresponding private key, and of course, that’s the key that only you have access to. Interestingly
enough, you can also do this the opposite way. You can encrypt information with your private key, and
the only people that would be able to decrypt it, are the people that have the public key. This is the
process that we would use for doing something like, a digital signature, for example.

So although we’ve named these keys public and private, they’re really only named that way, because
that’s how we’re using them. The two keys are mathematically related and depending on which one you
 choose when you create the keys, is the one that becomes the private key, and the one that becomes
the public key.

Although these two keys are mathematically related, you still can’t derive one key from the other. If
everyone has access to the public key, they still would not be able to determine what the private keys
should be, even though they have full access to every part of the public key. It’s this interesting
relationship between the public and the private key, that enables us to use the encryption that we have
today on the internet.

To better understand this relationship between the public and the private key, let’s go back to when we
originally create this key pair when using asymmetric cryptography. We would build both of these keys
at the same time. We have a large random number, there’s a key generation program, that is input, and
the output to that program, creates the two keys, the public key, and the private key.

By running this key generation program, which uses large random numbers, and prime numbers as
input, it runs it through a generation program, and it outputs two separate keys. Of those two keys, we
choose one of them to be the public key, and one of them to be the private key, and then we share the
public key with everybody, and we keep the private key private to us.

Let’s look at the process that’s involved in encrypting and decrypting information using asymmetric
cryptography. Let’s take a scenario, where Bob and Alice are communicating to each other, and Bob
would like to send some information to Alice that is encrypted. Bob will need a way to create this
encrypted message, like a laptop. He’ll need the original plain text. This plain text says, Hello Alice, and
then he’ll need Alice’s public key.

To obtain this key, Bob can ask Alice for her public key, he can retrieve her public key from a public key
server, or he can visit Alice’s home page or anywhere else Alice may have posted the key and download
the key from there.

Bob then combines the plaintext, with Alice’s public key, to create the ciphertext. Once the ciphertext
has been created, the only way to obtain the original plaintext is to decrypt it with the private key. You
cannot use the public key to somehow undo the encryption process that you’ve already done.

This means that Alice will receive the ciphertext message, and will apply her private key, to be able to
decrypt that ciphertext, and once that’s decrypted, she’ll be able to see the plain text that says, Hello
Alice.

This is the process that occurs every time someone wants to send information using asymmetric
encryption. If we wanted to reverse this process and have Alice send encrypted information to Bob, she
would need Bob’s public key, she would encrypt the data, send that ciphertext to Bob, and Bob would
use his private key, to decrypt that ciphertext.

We spoke earlier of the difficulties in being able to scale asymmetric key, because there’s no easy way to
transmit that symmetric key across the network, without first encrypting it. And since you haven’t sent
the key across the network, there’s no way to have a known key on both sides, that you can use for the
encryption process.
One way to get around this problem is to use asymmetric encryption, in order to create a symmetric key
on both sides, without having to send that symmetric key across the network. To be able to do that, you
use public and private keys on both sides.

Let’s take the example again of Bob and Alice. We know that Bob and Alice use asymmetric encryption,
which means, that Bob has a private key, and Alice has a private key, and of course those private keys
are only known to their owners.

You can combine your private key, with someone else’s public key, to create a symmetric key. And if you
use the related public and private keys on both sides, you end up with a symmetric key that’s identical
to each other. So even though Bob’s private key and Alice’s public key created the symmetric key, it’s
exactly the same symmetric key, if you combine Alice’s private key and Bob’s public key.

By doing this, the same symmetric key can be created on both sides of the conversation, without ever
having to send the symmetric key across the network. In fact, this is the process used for Diffie-Hellman
key exchange, and it’s a key exchange process that’s used extensively every day.

Hopefully, you’re starting to see that asymmetric encryption, can provide us with functionality that
symmetric encryption simply can’t do. But there are some drawbacks to using asymmetric encryption.
We’re using very large integers of very large prime factor numbers, and that calculation requires CPU
overhead and resources on a machine, to be able to encrypt and decrypt that information.

Of course, we have mobile devices, and internet of things devices, that may not have the computing
power that our local workstations have, but they still need to be able to encrypt and decrypt
information. For those, we would use, Elliptic-Curve Cryptography, or ECC.

Instead of using these very large prime numbers, we’ll use curves, to be able to create, the asymmetric
keys that we would use for public and private key encryption and decryption. ECC can use smaller keys,
to maintain the same security as non-ECC algorithms, and they require, a smaller amount of storage and
a smaller amount of data that would need to be transmitted across the network. This allows us to have
access to the powerful features available with asymmetric encryption, while we’re using our mobile
devices and IoT devices.

Hashing and Digital Signatures – SY0-601 CompTIA Security+ : 2.8

We use hashing and digital signatures extensively to ensure safe and secure data transfers. In this video,
you’ll learn about hashing data, salting a hash, and creating a verifying digital signatures.

A hash is designed to take any type of input, whether that’s a document, some audio, a video file, a very
large file, or a very small file and create a very specific unique string of text that’s associated with that
file. This is sometimes referred to as a message digest, and you can think of it as a fingerprint. If you take
a fingerprint and look at it, we know where that fingerprint came from. We know there’s only one thing
that can be associated with that fingerprint and that no other person has that particular fingerprint. Just
like you’re not able to recreate an entire person based on their fingerprint, you can’t recreate an entire
file based on the hash.
 This hash is a one-way trip. Once we take the hashing algorithm and apply it to some data, that hash
provides us with some output that does not allow us to go the other direction and somehow recreate
the data based on that hash. Because of that, it’s a perfect solution for storing passwords.

We can take a password, which really no one should have access to, create a hash of that password, and
then refer to the hash every time we want to authenticate. This allows us to store the password
securely. And if somebody did gain access to those hashed passwords, they wouldn’t have any idea what
the original password was.

We can often use hashing to provide integrity. So we can take a hash of a file, we can copy that file
somewhere else, we can perform that same hashing algorithm, and then compare the hash that we got
on both ends. If the hashes are identical, then the file that we copied is exactly the same file as the
original.

We also use hashing in combination with encryption to create digital signatures. That provides
authentication, which tells us where this data came from, non-repudiation, which means we can tie it
back to a specific person, and of course, the integrity feature is still part of that hashing algorithm. One
unique aspect of a hash is that there is always a unique hash for a particular kind of input. You will never
have two different kinds of input create the same hashing value. If you do find that two different inputs
are creating the same hash in the output, then you’ve found a collision, and this is something you would
not want to have with a hashing algorithm.

Let’s have a look at some hashes. We’ll perform a SHA256 hash, which is a 256-bit hashing algorithm. It
outputs the equivalent of 64 hexadecimal characters. And we’ll take a single sentence. My name is
Professor Messer with a period at the end. If we hash that single sentence, we get this entire value as
the SHA256 hash.

Let’s create a hash of a similar input. We’ll have an input of My name is Professor Messer with an
exclamation mark at the end of it. You’ll notice that the hashing value of this second input is very
different than the hashing value we had on the original input. In fact, almost every single character of
that hash is a different value even though the input for each of those hashing algorithms only was
changed by one single character. This is a good example of the differences that you’ll see in a hashing
output when using two different kinds of input.

We mentioned earlier that the only time we should see an identical hashing value is if the input values
were identical. With a hash, we’re taking an input of any size, any type of file, and we’re creating a fixed
size string from that that we’re calling a message digest, a checksum, or a fingerprint. Each one of these
hash values should be unique if it is a unique type of input, and we should never have a hash appear
that’s identical to another if there are different inputs involved. There have been cases, however, where
a hashing algorithm did create the same hash for different types of input.

This occurred with the MD5 algorithm. They found this collision problem in 1996. This is one type of
input that was used for MD5, and here’s the second input.

You’ll notice that these inputs are almost the same, but all of the characters marked in red are the
differences between these two different inputs. If we hash the first input and hash the second input, we
should get two different hash values. But with MD5, we got exactly the same hash value, and that is a
collision, and it’s another reason why we usually don’t use MD5 to be able to perform a hash.
 We mentioned earlier that it’s very common to use hashing to verify the integrity of information. For
example, you may go out to an internet website and download a file, and along with the file name at
that site, it may provide you with a list of hashes associated with these files. This means that you could
download the file from their website and perform the same hashing algorithm to the file that you’ve
downloaded.

If you then compare the hash that you created with the hash on the website and those two hashes are
identical, then you have an exact duplicate of the file that was originally posted on that site. And as we
mentioned earlier, it’s very common to use hashing when storing passwords. Instead of storing your
password in plain text, we store your password as a hash, and we can create and compare that hash
every time someone logs in.

Storing passwords is an interesting use case for hashing. It could be that you have hundreds of
thousands of user accounts on a website, and statistically, it could be that multiple users happen to be
using the exact same password. If you’re storing those hashes in a file, you could see that there are
multiple users that are using exactly the same password. We don’t know what that password is, but we
do know if we perform a brute force on that hash and we’re able to determine what that password is,
then that same password will work for every single one of those identical hashes.

To be able to avoid this, we want to add some randomization to these hashes. We call this random value
salt, and it allows us to add some randomization during the hashing process so that if even everyone
was using the same password, every single one of the stored hashes would be very different. Each user
might be using the same password, but each one of those passwords would have a different random salt
associated with it and therefore, a different hash would be stored. This means that if we had already
created some rainbow tables based on these hashes, and rainbow tables are pre-computed hash values,
we would not be able to use those rainbow tables because this extra randomization of salt has been
added to every single one of those hashes. If an attacker understands the process that’s used to add the
salt, then they could still go through a brute force process to try to determine what that password is, but
that is a much longer process to go through than looking up information in a rainbow table, and the goal
here is to slow down the attacker as much as possible.

Let’s take a scenario where everyone is using exactly the same password, but we’re going to store that
password information along with a salted hash. Let’s take our password. In this case, we’ll use the
password of dragon, and the hash for dragon looks like this.

Let’s say that everyone is using the password of dragon, but for each account, we’re going to add an
extra piece of salt to that, which of course is going to give us a different hash in every single one of those
scenarios. So if an attacker was able to get a copy of our hash file, they would see what they thought
were five different passwords. In reality, it’s the same password with the salt added for that
randomization.

Another useful function of hashing can be found with digital signatures. Digital signatures allow us to
send information to another party and have that person confirm that what they received is exactly the
information that we originally sent. These digital signatures proved the source of the message and
where this came from. We can verify that the digital signature isn’t fake, it hasn’t been modified, and it
really came from that original person. And because the digital signature was made with the private key
from the original user, we know that this document could not have come from someone else.
 Because the digital signature is created with the private key, it’s verified with the public key. If I was to
sign a document with my private key and send it to you, you would use my public key, which of course is
available to everyone, to verify the contents of that message. This also confirms that it came from me
because the only person who could have digitally signed this is the person with the private key, and I’m
the only one who has my private key.

Let’s look at how a digital signature is created. We’ll take a scenario where Alice is hiring Bob, and she
wants to send Bob a message that says, you’re hired, Bob. But she wants to make sure that Bob is able
to verify that this message is legitimate and that it really came from Alice. Alice is going to perform a
hashing algorithm on this entire plain text message, and out of that, we’ll get a hash of the plain text.
The person receiving this message could look at the hash to at least verify the integrity of the message,
but we don’t want somebody modifying anything in the middle of the conversation.

So the next step is for Alice to encrypt that hash that she created with her private key. And of course,
the only person with Alice’s private key is Alice. The results of that are what we call a digital signature.
And we can attach that digital signature to the original plain text and send that entire message to the
recipient.

On the other side, we have Bob, who has received this message from Alice. The message says, you’re
hired, Bob. And of course, we didn’t encrypt the message. We simply created a digital signature and
attached that signature to the message. And of course, you can see at the bottom, there’s our digital
signature.

To be able to verify this digital signature, Bob is going to reverse the process that Alice created. So the
first thing he’ll do is use Alice’s public key to decrypt the digital signature that she sent, which of course
is simply an encrypted version of the hash. After that decryption has been performed, Bob is left with
the hash of the plain text.

Now he wants to perform exactly the same hashing function that Alice originally did, so he’ll take that
plain text of your hired, Bob, run it through the same hashing algorithm that Alice did to see if he can get
a hash of that plain text, and then compare those hashes to make sure that they are the same. And if
those hashes match, then he knows that this message is legitimate. It really did come from Alice, and
nothing has been changed with that message while this message was being sent to Bob.

Cryptographic Keys – SY0-601 CompTIA Security+ : 2.8

Our cryptographic keys are often the only unknown variable when protecting data or creating digital
signatures. In this video, you’ll learn about key strength, key exchange, and how to protect different
sessions with dynamic keys.

Cryptography is an interesting science because it allows us to protect data, but the process that we use
to protect the data is well known by everyone. The algorithms that we use, the processes that we use,
to be able to take plaintext, convert it into ciphertext, and then back to plaintext, is a process that is
open and available for anyone to view.

The one variable that people don’t know, is the encryption key. And it’s that single encryption key that
allows us to encrypt data, to hash information, and to provide a digital signature. That’s why it’s so
 important to keep your private key private and to make sure that no one else can gain access to that
very valuable key.

In the world of encryption keys, a larger key tends to be more secure. That’s because if you want to
brute-force a particular key, you would have to run through every combination to see if you can
determine what that original key happened to be. And if it’s a longer key, then it takes a much longer
amount of time to perform the brute force.

For symmetric encryption, we tend to see keys that are about 128-bits or larger, and of course, as our
computing capabilities increase, we tend to increase the size of our keys so that we make it harder and
harder for someone to brute-force.

Asymmetric keys tend to be much larger than symmetric keys. These are keys that are using very large
prime numbers to perform these calculations. And asymmetric keys tend to be 3,072 bits 4,096 bits or
even larger.

One of the logistical challenges we have is the need to be able to share keys between two people so that
you can then perform an encryption. The challenge though, is how do you transfer a key to someone,
over a medium that is inherently insecure? There needs to be some way to be able to share encryption
keys, without having someone else be able to see us sharing those encryption keys.

One way to do this is an out-of-band exchange. This is one where you might want to call someone on
the telephone or use a carrier to send that key from one person to another. It’s out-of-band because
you are transferring this key outside of the network.

Of course, it’s much more convenient if you’re able to transfer this key directly across the network and
have it appeared instantly on the other side. We often do this by protecting this key, by using an
additional encryption method. For example, it’s very common to use asymmetric encryption to be able
to send a symmetric key to someone else.

Here’s one way to provide this very fast ability to exchange keys without sending the key in the clear
across the network. You could use asymmetric encryption to be able to encrypt the symmetric key inside
of it. The client would take this symmetric key, which would be the plaintext, and would encrypt it using
a server’s public key to create the ciphertext.

That ciphertext is then sent to the server. The server is able to decrypt that ciphertext using its private
key, which would allow it access to the session or symmetric key that we originally started with. This
means that we can transfer this symmetric key across the network in an encrypted form that uses
asymmetric encryption, to transfer a symmetric key.

If you’re using the symmetric key as a temporary session key, then it needs to be changed often. As the
name implies, a session key tends to be used for an individual session, and once that session is over, the
keys are no longer used.

We refer to this key type as an ephemeral key because it’s a key that’s not permanent. It’s also
important that these session keys are unpredictable because we’re using these as encryption keys for
our session, and we want to be sure that no one else is able to predict the type of key that we might
use.
 Another way to share a symmetric key between two devices without sending that symmetric key over
the network is with something like Diffie-Hellman key exchange. With Diffie-Hellman key exchange, you
would have a private key for each user. For example, Bob has his private key, and Alice has her private
key.

You would then use the public key of the other side. For example, Bob would use Alice’s public key, and
Alice would use Bob’s public key, and both sides would combine both of those together, to create a
symmetric key. And when you do that, on each side the symmetric key turns out to be identical. This
means that both Bob and Alice could calculate a symmetric key on both sides, and use exactly the same
key without ever having sent that key to each other.

But if your public and private key never change, this could create a vulnerability, especially if someone
has access to the raw data going across the network, and they somehow gain access to your private key.
Take, for example, web servers, which commonly use encryption keys for TLS or what used to be called
SSL, and they’re based on a web server’s key pair.

So web server has a public key, and a private key, that’s used for this asymmetric process. It’s this
asymmetric key pair that is then used to encrypt all of the symmetric keys that are used to communicate
back and forth to this website server. This means if you somehow gain access to the server’s private key,
and you capture the information going across the network, you can decrypt that information, to see
what’s on the inside.

For many websites, this provides a single point of failure for all of the encryption. So there needs to be
some other way to provide encryption to the server that would prevent somebody from being able to
decrypt it after the fact.

To work around this problem, many web servers have implemented Perfect Forward Secrecy or PFS. This
changes the encryption process so that you’re not using the same private key every time, to be able to
transfer that symmetric key across the network.

This uses an algorithm called elliptic curve or Diffie-Hellman ephemeral. In fact, this is a certificate that
shows that it’s using ECDHE and that is Elliptic Curve Diffie Hellman Ephemeral. These keys are created
just to transfer a single session, and then once that session is over, those keys are no longer used. This
means that every session will have a different set of encryption keys, which means we can’t go back
after the fact and decrypt all of that network traffic, based on a single server private key.

Since we’re creating these public and private key pairs on the fly for every session, there is some
additional overhead required to be able to perform this function. And not all servers are going to have
the bandwidth or capabilities in their hardware, to be able to perform Perfect Forward Secrecy.

We also have to make sure that the browser is communicating to this website server can support PFS,
and most modern browsers do. You’ll have to look at the individual browsers to make sure that those
browsers can support the same encryption method that you’re using on the webserver.

Steganography – SY0-601 CompTIA Security+ : 2.8

 It’s sometimes easier to transfer secret information through the use of a concealment. In this video,
you’ll learn about obfuscation, steganography, and how to hide data inside of image, audio, and video
files.

Obfuscation is the process of taking something that would commonly be relatively easy to understand
and make it very difficult to understand. This doesn’t make it impossible to understand. But it does make
it a lot more difficult for humans to be able to look at or read through some information and be able to
understand exactly what that information is saying.

We commonly see things like obfuscation being done with source code. This means the programming
language that we’re using is able to work properly. But we, as humans, aren’t able to read through the
code and understand exactly what’s happening with the logic of that program.

Another type of obfuscation is used to hide information within an image. We refer to this as
steganography. Steganography has a basis in Greek that means concealed writing. And it’s a way of
storing information that doesn’t necessarily make it more secure, but it certainly makes it more difficult
to know that that information is there. If someone knew the process that was in place to be able to hide
this information, they would very easily be able to retrieve that information that was obfuscated.

And because of that, we refer to this as security through obscurity, because this is not a true secure
method. Although this message is invisible to the human eye, there really is a message inside of the
image. We refer to the container that has this message inside of it as the cover text.

So in this example, the graphic that’s used on this particular view is the cover text. And inside of that
graphic is some additional details. And if you knew how to extract that information from the file, you
would be able to gather a list of IP addresses, names, and MAC addresses that are hidden from the
human eye but do exist inside of that image file.

There are a number of steganography tools that you can download and use as open source that are able
to store information in images. You can then send that image to someone else. And they can use a
similar steganography program on their side to extract this information from the image.

There are a number of different ways to hide information using steganography. One is based on the
packets going across the network. If you can add some additional bits of information to these network
packets, you can collect those bits on the other side. And now you can put together information that no
one had any idea was being transmitted that way.

As we’ve also mentioned, you can use an image to be able to transfer this information– and the larger
the image, the more information you’re able to transfer. And if you examine the output from a laser
printer, you’ll notice there are watermarks on every single page that provide information on the laser
printer and where it may be located. If I reverse the image, you can see the dots are a little bit easier to
read. And the structure and makeup of these dots provide other people with information about this
particular printout and which printer this came from.

Steganography, of course, is not limited to just images. You can store information within audio files. So
you could put documents, spreadsheets and other types of data within an audio file, send that audio file
to someone else, and they could extract all of that information on their side. Very similarly, you can do
the same thing with a video file– the larger the file, the more information you can store. And so video
 steganography allows you to store quite a bit of information– send that entire video to someone to
transfer all of that information at once.

Quantum Computing – SY0-601 CompTIA Security+ : 2.8

Quantum computing is quickly changing our perspective on technology and cryptography. In this video,
you’ll learn the basics of quantum computing and how our cryptography changes when using quantum
computing.

An emerging technology in computing is quantum computing. This is computing based on quantum

physics rather than being based on classical physics that uses 1s and 0s. This is not an upgrade to your
existing computing system, but a type of computing that’s used alongside of our existing computers.
This is an entirely new way of performing calculations.

With our traditional computers, we use classical mechanics, which uses bits. Those bits are 0s and 1s,
and we can apply algorithms towards those 1s and 0s to come up with a solution to a particular
problem. With quantum computing, we no longer have bits.

We have something called quantum bits, or qubits. These bits are not 1s, and they’re not 0s, but instead,
they exist somewhere in the middle between 1 and 0. They are effectively a 0 and a 1 at the same time,
and therein lies some of the complexities surrounding quantum mechanics.

Let’s compare classical computing to quantum computing. In our classical computing, we might want to
perform a binary calculation with four separate bits, and we can take any combination of those four bits
to come up with a value. For example, we can combine all of the different permutations of those four
bits, and we can look at every combination of those four bits to come up with 16 separate unique
values.

With quantum computing, we can represent all 16 of those individual classic bits as four individual
qubits because all of those are both 0 and 1 simultaneously. So if it only takes four individual qubits to
represent 16 values, we can start to scale this up very quickly. For example, if we had eight different
qubits, that would represent 256 values. If we had 16 qubits, that represents 65,536 values. And if we
look at 32 qubits, we now have over 4 billion values that are represented by a relatively small number of
qubits.

It’s the scalability that provides some of the biggest potential advantages for quantum computing. This
could, for example, allow us to search through enormous amounts of data in a very short period of time.
This would change medical technology, it might allow us to change the way we’re able to predict the
weather, this could have an impact in astrophysics, and so much more.

One place that quantum computing has a direct effect on technology with this scaling is cryptography.
Today, we use very large prime numbers to be able to create the complexity required to keep all of our
data encrypted. But what if you had a quantum computer that was able to perform these very large
calculations in a very short period of time? This would effectively render all of our existing cryptography
useless because our quantum computers would be able to brute force all of our encrypted data very,
very quickly.
A description of how this could be done with quantum computing was created by Peter Shor. He created
what’s called Shor’s algorithm in 1994, where he looked at how we were using prime numbers and came
up with a way that you could greatly shorten the process of being able to factor this information. This
could take processes that would effectively take longer than the lifetime of the universe and make them
something very feasible to use with quantum computing.

Fortunately, researchers are already looking at new ways to provide cryptography in this new world of
quantum computing. One of the ways to do this is with NTRU. This is a new way of performing
encryption with quantum computing that instead of using very large prime numbers uses a closest
vector problem. This is a problem that is still difficult for quantum computing to calculate and would be
a very viable way to provide encryption. Researchers are also putting together other ideas that will help
us maintain the privacy and encryption technologies we need, even in this newer generation of quantum
computing.

One interesting characteristic of quantum computing is that if you examine the quantum bits, you will
effectively be changing those quantum bits. This means that we can send information over a quantum
network, and on the other side, we’re able to tell if anyone was monitoring that conversation. This is
especially useful if you want to distribute encryption keys.

You might want to use Quantum Key Distribution, or QKD. This allows us to send our encryption keys
across the network to the other side without the worry of someone being able to intercept that key
somewhere in the middle. We would send that random string of qubits, which was effectively our
encryption key, across that quantum network channel.

Once the key is received, both sides can verify that key, and if it’s identical, then no one viewed that key
during the transmission process. However, if someone was to monitor that conversation, it would
change the keys that were received on the other side, and those two keys would not verify. This greatly
changes the processes and procedures we use for encryption, and we’ll want to keep a close eye on
quantum computing as this technology matures.

Stream and Block Ciphers – SY0-601 CompTIA Security+ : 2.8

We use stream and block ciphers to efficiently protect our important data. In this video, you’ll learn
about stream cipher methods and block cipher modes of operation.

When you want to encrypt some information, there are a number of different techniques you can use to
take something that is plaintext and turn it into ciphertext. One way is to perform a stream cipher. And
the other one is to use a block cipher. With stream ciphers, we are encrypting one byte at a time. So we
will take our plaintext, we’ll grab the first byte, we’ll encrypt that byte, and we’ll store the encrypted
information. Then we’ll take the second byte and we’ll encrypt that byte and store that second byte and
so on.

This allows us to encrypt very quickly because we can do this one byte at a time instead of using larger
groups of data to encrypt at a single time. This also means that we would not need as complex a
hardware or CPU infrastructure to be able to encrypt just a single byte of information. You often see
stream ciphers used with symmetric encryption where there is a single key that’s used for encryption.
And that same key is used for decryption. You don’t often see asymmetric encryption used in these
 stream ciphers because of the overhead and additional time it takes to be able to encrypt and decrypt
with asymmetric encryption.

One of the challenges you have with stream ciphers is you don’t know what’s coming later in the stream
until you get to that particular byte. And that means randomization of this data could be challenging,
especially if multiple bytes are input into the stream that are identical. You end up with identical bytes
on the encrypted side. So there’s often an initialization vector, or IV, that is added to the stream cipher
to add some randomization to the encryption process.

As the name implies, a block cipher is encrypting a fixed length block of information at a time. So instead
of taking a single byte, it will take a block of bytes and encrypt that entire block at one time. We usually
will see this with 64-bit or 128-bit blocks. And if the input into this block cipher doesn’t match 64 or 128
bits, we’ll often add padding onto that to fill in any of those short blocks. Like stream ciphers, block
ciphers also commonly use symmetric encryption so that they can encrypt as quickly as possible with a
minimum of overhead.

There are many different ways to encrypt a block of information, and we call these different methods
modes of operation. In this video, I’ll give you an overview of a number of different modes so that you
can see the differences between these different modes of operation for block ciphers. For each of these
modes of operation, it’s a similar type of input. We need a block of data. And it’s a standard sized block
of data for each of these modes.

We’re also going to have a specialized form of encryption that differs depending on the mode of
operation. The method used for encryption for one mode of operation is often quite different than the
method used in another mode of operation. These block ciphers will start by taking data and splitting
them into smaller fixed length blocks. If you do end up with a block at the end that does not fill in the
entire length of that block, we’ll often use padding just before the encryption process.

One of the simplest modes of operation for block ciphers is ECB, or electronic codebook. This is going to
use a single encryption key and perform exactly the same encryption for every block in the series. For
example, we’ll start with some plain text, we’ll use our symmetric key to be able to encrypt that data,
and we’ll end with some ciphertext. Then we’ll grab the second block of information, we’ll perform the
same encryption using the same encryption key, and we’ll have some ciphertext as the output.

Then we’ll grab another block of information, perform exactly the same encryption with the same key,
and we have some ciphertext in the output. And we will continue that process all the way through the
file until we have encrypted all of the blocks of that file. Each block is encrypted exactly the same way.
So if the input is identical, then the output will be identical for every block. Let’s take an example of this
where we have an image. And we would like to perform an electronic codebook encryption of that
image.

So we’ll take one block at a time from this entire view. If there’s no randomization, or no salt added to
this encryption process, we would end up with output that looks just like this. And although this
ciphertext is not identical to the original plaintext, it’s still close enough that we could tell what the
plaintext was originally.

This is one of the reasons why electronic codebook may not be the best block cipher to use in all
scenarios. Another common mode of operation is CBC, or Cipher Block Chaining. Cipher block chaining
 adds some randomization, which gets around a number of the problems we saw with electronic code
book. Each block is XORed with the previous ciphertext block. That means that we perform a different
set of input and output to that data to add some randomization.

The XOR stands for Exclusive Or. And it means that if you input two bits that are identical, the output is
zero. If you input two bits that are different, the output is a one. And this adds some randomization to
the final result. This process usually starts with the first block, which is an IV, or initialization vector,
that’s used instead of performing the XOR. This encryption process is very similar to the electronic
codebook. We do have plaintext and we have a block cipher encryption with a symmetric key. And then
we have the ciphertext output.

But just before the encryption occurs, you’ll notice that we’re adding some additional data. This is our
initialization vector, or IV, and this is going to add additional randomization to the final ciphertext. On
the second block of data, we’re going to use the resulting ciphertext as the initialization vector for the
next block. So you can see by adding this additional randomization to the encryption process, our
ciphertext will be different every time even if the plaintext is identical.

Another common type of block cipher mode is the counter mode, or CTR. Counter mode uses an
incremental counter to be able to add randomization to the encryption process. With counter mode, we
start with the incremental counter and then we encrypt that counter with the block cipher encryption.
After that encryption has been done, we will perform the exclusive or to the plain text to finally create
the ciphertext.

Instead of using the results of this encryption on the next block, we’ll instead simply increment the
counter and then perform exactly the same encryption with the next block of plaintext to create the
next set of ciphertext. These modes of operation can not only provide encryption but can also provide
authentication. A good example of this is GCM, or the Galois Counter Mode, which combines counter
mode with Galois authentication. This provides us with a way to not only encrypt data very quickly but
make sure that we can authenticate where the data came from.

This is commonly used in wireless connectivity, IPsec communication, and if you’re connecting to a
server using SSH or TLS, then you’re probably using Galois Counter Mode.

Blockchain Technology – SY0-601 CompTIA Security+ : 2.8

Although blockchain technology is often associated with cryptocurrencies, there are many other
implementations. In this video, you’ll get an overview of the processes used with blockchain
technologies.

A blockchain is a distributed ledger. It’s a way to keep track of a particular event. This is something that
many people can participate in, so that this ledger can be distributed throughout many different
devices. Because this ledger is distributed across multiple devices, we can now have checks and
balances. We can have an efficient form of processing these transactions, and everyone can see exactly
what’s happening on the blockchain. If you’ve ever purchased anything with cryptocurrency, then
you’ve used blockchain technology for your payment processing. This can also be done for digital
identification. We can keep track of components as they move along different sections of a supply chain,
or we could use this for secure voting.
Regardless of the underlying application, the fundamentals of the blockchain are the same across all of
these. The first step is adding a transaction. We might be voting online, we might be adding inventory
into a supply chain process, or we may be purchasing something with cryptocurrency. Before the
transaction is confirmed and verified, a copy of the transaction is sent to all of the devices that are
participating as part of this blockchain. All of these devices are maintaining ledgers, and they can check
balances and other information that’s important for completing this individual transaction.

Once this transaction is verified, it’s added into a block of other transactions that have also been
verified. This is the block of the blockchain, and it allows us to process many transactions at the same
time. To provide some integrity to the process, we’ll use a hashing function to be able to hash all of
these transactions, and we will add the hash to the block. That way if anything changes with this block,
we know that the block was modified, and therefore, the block would be invalid. Once that hash is
created we have a complete block that we can then add to the existing blockchain. So this block is now
copied to all of the devices maintaining that ledger across the entire blockchain network.

One of the concerns with having a distributed ledger is that any of these nodes on the network might
want to make changes to something that has already been verified. That’s why the hash was added to
each one of these blocks, so that if any changes are made we’ll know immediately that this information
has been modified. And since we’re able to verify the hashes that are part of every block, we will know
immediately if any changes have been made to any of this verified information. And we can discard
anything that doesn’t match or verify with that existing hash.

This is a broad overview of the blockchain process, but every blockchain technology has different minor
nuances that make it unique from others. And there may be different features or different capabilities
based on the type of blockchain that you’re using.

Cryptography Use Cases – SY0-601 CompTIA Security+ : 2.8

Cryptography provides numerous capabilities to our technical life. In this video, you’ll learn about the
use cases associated with the implementation of cryptographic technologies.

We use cryptography in many aspects of our lives. And in this video, we’ll go through a number of these
important cryptography use cases. We rely on our mobile phones, our tablets, and other devices to be
able to provide us with information throughout the day. But these mobile devices have limited storage,
limited CPU, there’s a certain battery life associated with these devices.

And we still want to be sure that all of the data on these devices is secure, so of course encryption is a
great way to protect the data that’s on these devices. But because there is a limited amount of power in
the CPU, we need specialized encryption for these devices. So it’s very common to use a smaller
symmetric key, especially in conjunction with elliptic curve cryptography or ECC, which is specifically
designed for environments like this, where we need very powerful encryption on a device with a limited
number of resources.

If we need encryption that works very fast and very efficiently, we can use the low latency is associated
with symmetric encryption. Symmetric encryption also has smaller key sizes, so it might be a better fit
for a number of different encryption projects. And it’s also important that we’re able to ensure the data
remain valid. We want to be sure that there’s no opportunity for data to change or be modified without
us knowing about it.
 So using some type of hashing provides that data integrity. We could also use larger key sizes and
increase the quality of the type of encryption that we’re doing to be sure that we have the most
powerful encryption available. If you want to keep information secure then you’ll want to use some type
of encryption. This cryptography allows us to keep things secret and private and we can encrypt
information that’s either part of a file. We can encrypt information on an entire drive or perhaps even
on an entire device.

By using hashing we can also maintain the integrity of data, we could use a hash as we’re downloading
files to make sure that the file download has occurred properly or we may want to store information like
passwords and hashing allows us to store the password without revealing that password to others.

Cryptography also allows us to hide information through the use of obfuscation. For example, malware
very commonly encrypts the malware itself within the software that it’s transferring in order to get
around the signature based detection that we have in most antivirus and anti-malware products. When
the application is executed, the malware is decrypted and it becomes executing on the local machine.

If you’ve ever logged into a device or authenticated onto a network then you’ve taken advantage of the
authentication capabilities of cryptography. We often use hashing to be able to protect those passwords
and we’re usually doing this so that no one can see the password that we happen to be using. We might
also add salt or some other type of randomization to the password, so that everyone’s hash password is
very different than everyone else is.

We can combine this hashing with asymmetric encryption to create non-repudiation, this allows us to
confirm that the information that we’re receiving from someone really did come from that person. This
is usually implemented as a digital signature, so that you can be assured that not only did that data
come from that person but none of the data that you’re looking at as part of that digital signature was
altered from the time that it was originally sent.

Cryptography Limitations – SY0-601 CompTIA Security+ : 2.8

Although cryptography provides significant functionality, it’s not without tradeoffs. In this video, you’ll
learn the use and limitations of using cryptography technology in practical use.

Although cryptography provides us with a number of very powerful capabilities, there are still limitations
into how we use cryptography. If you were to examine the way that cryptography has been
implemented with one application and compare that to a different application, you’ll probably see a
very big difference between those two. Those differences allow us to customize the way that those
different applications will be using this cryptography. But, of course, to integrate with that we need to
understand how that cryptography was originally implemented.

And it’s the implementation of the cryptography that is often its biggest weakness. For example, you
may use hashing to store passwords. But if you don’t apply a random salt to that password hash, then
you may not be storing things as securely as you could be. If you’re in charge of implementing some type
of cryptography on your network, your firewalls, or your VPNs, then make sure you do your homework
and that you’re implementing the correct type of cryptography for your purposes.

One of these considerations is speed. We have to make sure that the application can perform quick
enough with the type of cryptography that we’re using. We have to think about the overhead associated
with encrypting or decrypting this data. That means we need to make sure that the CPU can handle this
encryption and decryption process and that we have enough power in the system to be able to support
that. When we implement this encryption, it will put additional load on the CPU. It will use more power
and more battery life. And we, of course, need to consider that when implementing the cryptography.

If we’re using a block cipher to be able to encrypt data, it’s important to know that if we’re encrypting
16 bytes of data, that usually the encrypted information is also 16 bytes. So by using this encryption,
we’re not increasing the amount of storage that we might need. The only place where that does become
important to consider is when we might be encrypting less than the size of the block.

For example, if your block size is 16 bytes and you’re encrypting some data that is 8 bytes in size, you
have to fill in the other remaining 8 bytes so that you have a full 16 bytes to be able to encrypt. If the
block cipher is 16 bytes in size, then the amount of data that’s encrypted has to be 16 bytes as part of its
plain text. That means that we would have to add another 8 bytes to this, which would effectively
double the storage size of what we happen to be saving.

We also have to think about the size of the keys that we’re using during the encryption process. And
generally, larger keys will make it much more difficult to brute force. A good example of where a weak
key could be a significant problem was in the wireless encryption that we used for WEP. The weak
initialization variable that was used in RC4 resulted in cryptographic vulnerabilities that made it very
easy for someone to gain access to our wireless data.

You also have to consider how long someone’s willing to wait for this encryption or decryption process.
It takes time to perform encryption or hashing. And, of course, larger files are going to take a larger
amount of time. You might also want to consider the type of encryption you’re using. If you perform
asymmetric encryption, it may take much longer to perform that function than if you had used
symmetric encryption.

It’s also important to think about how long this encryption type is able to be used. As time goes on, our
CPUs get much more powerful, and we’re able to do brute forcing much faster than we have in the past.
A good example of this is when Data Encryption Standard, or DES, was released in 1977, it was
considered to be a very secure encryption type. But only 22 years later in 1999, we were able to put
together technology that was able to brute force DES in just 22 hours. If you use larger keys instead of
smaller keys, you might be able to extend the life of that encryption method.

Cryptography also relies on randomization. If you know what’s going to happen next, you may be able to
predict what’s going to happen with the encryption. So having some type of random number generation
that can’t be easily predicted is crucial for any type of cryptography. For example, Cloudflare has their
wall of lava lamps that provides them with a type of randomization that they can then apply back to
their encryption. And, of course, if you’re creating some type of passphrase, it needs to be something
that can’t be predicted. And something very random is a much more powerful passphrase than
something that can be predicted.

In most implementations, the process for encryption doesn’t change. But the key that’s used during the
encryption process does change. However, changing that key can add additional overhead. So using the
same key is something that’s commonly seen in a number of encryption mechanisms. The problem with
that, of course, is that if someone gains access to that key, they would effectively have access to
 everything that was encrypted using that key. So although there is some work involved to change that
key, there are some significant security advantages to doing that.

It may be that some of the devices you have don’t allow you to change the key. For example, Internet of
Things devices are relatively straightforward in simple devices and, in some cases, have the key
embedded in the firmware itself. That means if you need to change the key, you have to update the
entire firmware for that IoT device. And it’s in these Internet of Things devices where we start to see
large differences between the requirements for encryption and the resources that we might have
available to provide that encryption.

IoT devices have a limited CPU. They have just enough memory to keep the system running and, in some
cases, are running on battery power or limited power sources. If this IoT device is monitoring something
in real time, there’s not a lot of cycles available to perform encryption or decryption. So there needs to
be a happy medium between security on the device and having the device application work properly.

You might also find that these IoT devices are not really built for security. So it’s up to you to determine
what’s going to be required to provide the proper amount of security and the security updates for those
Internet of Things devices.