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.