2019年律師的CS50--網絡安全 (CS50 for Lawyers 2019 - Cybersecurity)

字幕列表影片播放

[MUSIC PLAYING]
SPEAKER: So today we're going to have our first of a few discussions
about cybersecurity, and later on we're going
to talk a little bit about cybersecurity in the context of the internet
and some of the challenges that it brings up there.
But today we're going to focus mostly on cybersecurity issues related
to your machine, your computer without necessarily
being connected to the internet.
Before we do, we need to understand a little bit more
about our machine's infrastructure, its hardware.
And the biggest question to ask at the outset
is, when we talk about the system's memory, what do we mean by that?
That term kind of gets thrown around and it means a couple of different things,
potentially.
It might mean your system's RAM or random access
memory, which is a rough translation of how much computing power it has,
how many things it can do.
And we can also talk about hard drive space
as another example of system memory.
Hard drive space is usually just free storage, basically.
How much room do we have to literally store files on our machine?
How much memory does your computer have?
Maybe you do or maybe you don't know.
If you take a look at your system information
or look up the computer that you bought on the internet,
you might find that if we're quoting memory in terms of RAM,
that your device might have as low as 512 megabytes of RAM, which
is about half of a gigabyte.
And that's not very much, most machines have much more than that now
unless you have a low powered Chromebook,
for example, that you use for travel.
Memory on the RAM scale might go as high as 32 gigabytes of RAM,
which is quite a bit more than that.
That's generally for really high end computers.
Computers, in particular, that process a lot of graphics.
So sometimes computers that are specifically dedicated for gaming
might have that much RAM.
But typically the range is somewhere between four and 16 nowadays.
When we're talking about hard drive space, that number is quite a bit
bigger.
So the typical hard drive nowadays might be as low as 128 gigabytes,
if the drive is a solid state drive, versus a hard disk drive.
We won't go into too much detail about the distinction between those two
things, other than right now to say those are just two
different ways to store data long term.
So that might be the low end.
The high end is probably somewhere on two terabytes of information.
One terabyte is 1000 gigabytes, give or take.
So two terabytes would be about 2000, give or take, gigabytes.
So quite a bit.
Maybe even as high as four terabytes.
That's quite a bit of storage information.
That's enough to store several hundred HD, high quality films.
But there's much more to memory than just RAM and hard disk space.
There's actually kind of a hierarchy of memory that exists within your machine.
Most of these numbers, though, aren't usually quoted
in the specs of a device.
So there's RAM, random access memory, and then
there's a series of caches, each of which gets successively smaller.
So they're going to be quite a bit smaller than the four gigs,
say, of RAM that your device has.
But they're also a little bit faster, and the reason these things get faster,
these caches get faster, is they are getting closer and closer
to the computer's processor, which is really the only part of the device that
is able to manipulate information.
It's the only part that can process information.
So the memory that we're feeding to that processor
needs to get faster and faster, such that it
can continue to swap things in and out.
So we have the RAM, maybe an L3 cache, a Level 3 cache, Level 2, Level 1,
and then finally CPU memory, which is the processor memory itself.
Plus some small bits of memory called registers,
which are used to be the final sort of pass of information from RAM
or this hierarchy of memory into the CPU.
But again, every file on your machine lives somewhere permanently
on a disk drive.
And there are, again, two different kinds of disk drives.
We have solid state drives and hard disk drives.
We should treat them as effectively identical
for purposes of our discussion today.
They-- solid state drives tend to behave a bit differently than hard disk
drives, they tend to be a bit more secure than some of the vulnerabilities
that hard disk drives present, which we're
going to talk about a little bit later in today's lecture.
But in general, when we talk about hard disks or storage space
for the rest of today's lecture, we're going
to be mostly focusing on hard disk drives.
They're also just much more prevalent still.
Solid state drives are coming into their own and becoming more and more frequent
as they appear in devices, but hard disk drives
are still far and away more and more prevalent within devices
that exist now.
They are just storage space, though, we can't do anything
with data that is stored on disk.
We have to first move it to RAM and then have
it sort of go up and down that chain of RAM, the different caches to the CPU,
in order to actually manipulate the data.
Once we're done manipulating it, and maybe we're
turning our computer off for the evening,
then all of the data that is in RAM will be stored back into the hard disk space
so that we're able to access it at another time.
One thing to keep in mind as we begin this discussion of memory,
though, is that memory is really just an array.
And we've talked about arrays already, where each cell of that array
basically is one byte wide.
And recall that one byte is eight bits.
We may have anywhere between 512 megabytes of memory,
so about 512 million of those little one byte
sized cells, maybe as high as four, 8, 16, and so on gigabytes.
And we have quite a few of those items in our array.
But it really is just an array, which means
we can jump to different addresses.
It has the same properties as any other random access
array that we've already discussed.
Different types of data take up different amounts of memory
on our systems.
So if we think about a very low level programming language like C,
which is this is just an example.
Different programming languages may store different types of data
using different amounts of space.
But if we look to just the most base level of data
and think about the smallest individual pieces into which we can break it,
we may be able to store an integer, for example, in four byte.
Which means we have exactly 32 bits worth of space to store an integer.
Characters will take up one byte, so we have only eight bits worth of memory
required to store a single character.
So capital or lowercase letters, digits, punctuation marks, and so on.
Not a huge variety of options there.
Floats are-- you may recall are real numbers,
numbers that have decimal points in them.
Doubles are, as well.
They're double precision floating point values
and they take up four or eight bytes.
So basically the idea here is different types of memory
will take up different amount of space and then
we eventually can construct these things into pixels, and images, and films,
each of which will also take up different amounts of space and memory
if we are manipulating or working with that data.
So again, let's think of memory as a big array of individual byte-sized cells.
Because it is an array, that means we have random accessability.
We can say, I want to go to memory address x and see what is there.
I want to go to memory address y and change what is there.
We have the ability to do that.
We don't have to iterate through step by step by step in order to make changes.
If we did, the processor would be quite a bit slower having to perform this,
we might term linear search as we try to iterate through memory
to find the one byte we're looking for.
It's very helpful to be able to jump to a particular byte.
And that means that every location in memory must have an address.
We must have a way to refer to that individual byte
in order to randomly access it.
We can't just look at this grid of cells and say, I want to go to this one
and sort of, you know, imagine particular spot.
We need to say, I want to go to exactly this memory address.
OK?
So s-- the fact that memory cells have an address
is what comes into play when you think about this idea
of a 32-bit system or a 64-bit system, and this
may be a term that you've heard before.
It refers to the ability to process an address.
So for example, a 32-bit computer, a 32-bit system,
can process memory addresses up to 32 bits in length.
Which means it understands memory address zero through memory address
right up to four billion, a little over four billion.
But it doesn't understand memory past that.
Now interestingly, this doesn't mean that a 32-bit system
is limited to four gigabytes of RAM.
There are some software tricks that we can pull using something called virtual
memory, which we're not going to get into in any more depth than to refer
to it as virtual memory today, that allow you to use more than four
gigabytes of RAM on a 32-bit system by doing-- sort of, you know,
pretending that things live somewhere where they don't.
But when you talk about a 64-bit system, that
means we have many more memory cells that we
can refer to without running into our sort of artificial limit of how high we
can count.
Now granted, there are no memory banks out there
that have all of the memory addresses from zero to 64 bits worth of memory.
That's somewhere in the quintillion or higher.
It's a very, very large number and we don't yet
have the storage capacity to store that much data on our machines.
But theoretically, it is possible that with a 64-bit system
we could have very, very large amounts of RAM and again, the more RAM we have,
generally the more quickly our computer is
going to operate because there's more space for it to store information.
It doesn't have to keep sending stuff back to the hard drive
when the RAM is full because there's so much information
being processed at once.
More of it is available in that quicker, more accessible bit of memory.
So recall that with each bit, remember a bit can only take on one of two states.
Zero or one, off or on.
Or you can think about it in terms of electricity, which is how RAM actually
works, as being unpowered or powered.
That again means that we have 32--
two to the 32nd power, excuse me, possible memory addresses.
So about four billion memory addresses.
Now it is sometimes the case that programmers, and subsequently,
those who may need to read their code, may need a way
to refer to specific memory addresses.
But a memory address like this, which is a memory address.
There are zeros and ones in this address.
This is exactly how we would refer to an address in memory.
This is rather cumbersome.
No programmer wants to talk to another programmer and no programmer wants
to talk to an advisor by saying the code that lives at 00101 and so on.
That's just not-- that doesn't make any sense.
That's just not how we would talk and it would take forever just
to say the name of the memory before you even get
to the point of what is in that memory.
And so rather than using binary notation to refer to a memory address,
computer scientists will oftentimes use something called hexadecimal notation.
Hexadecimal is 16 hexadecimal, 6 and 10.
And so this is the base 16 number system.
It's a different number system than the decimal system, base 10,
that we have used since childhood to count and understand
place values of numbers and so on.
What's convenient about hexadecimal being
base 16 versus binary being base two is that four binary digits or four bits
can be represented using a single what is often called hex digit.
So for every group of four binary digits that we have,
we can represent that more succinctly using just one hexadecimal digit.
And because there are four bits, that means
we have two to the fourth, or 16 different combinations.
So we can account for every single possible on off
combination of all of the four bits in that cluster using a single hex digit.
So we might instead refer to this memory address looking like this.
And there are some letter characters in there,
and that's because in order to represent a single digit in hexadecimal,
we need to be on the count higher than 10
using two digits, as we are confined to in decimal.
In order to represent the number 10, we need
a one and zero, a one being in the tens place and a zero in the ones place.
But in hexadecimal, we need 16 possible digits
to represent all of the 16 possible values at any given place value.
So here's an example of something that a programmer might see.
This is using a tool called GDB, which is
a debugging tool that is used to debug or root out problems in some low level
code.
And all we're seeing here is a bunch of memory addresses.
So I've highlighted them here in yellow.
We don't need to worry too much about the context around this, what these all
refer to.
But basically, these things on the left, EAX, ECX and so on are registers.
Those are things that are very close to the memory.
And they are storing the memory address of something else.
And so all these things on the left here are just memory addresses,
and the things on the right are translations of those memory addresses
in some cases into decimal numbers that make
more sense to us having used the base 10 or decimal system for quite some time.
So we can map all of the different possible values in hexadecimal
to their binary equivalents as well as to decimal numbers
that we're familiar with.
So again, here we have all of the possible combinations of four bits
or zeros and ones showing you what they translate to in decimal,
recalling that for every set of four bits here we see, the one on the right
is the ones place, the one to its left is the twos place.
Then we have the fours place and the eights place.
Because again, our base is two.
Every place value is a power of two as opposed to a power of 10
like we would in decimal.
And then it's hexadecimal equivalent.
So again, for every single one of those combinations,
we have one distinct way to represent it using a single hex digit.
And sometimes you'll see the hex digits for 10
through 15, which are a through f, presented in capital letters.
I like to present them in capital letters,
but sometimes you see them in lowercase letters as well.
That is immaterial to it.
And this zero x at the beginning of it, I should mention that as well.
Zero x means absolutely nothing.
It is purely a note for us as human beings
when we are seeing something like this that we should interpret it
as hexadecimal numbers as opposed to as decimal, for example.
Because we could have a valid hexadecimal string that is--
I'm going to use the zero x here just for second--
0x, five, zero.
If we saw that, we might read it if we didn't have a 0x in front of it,
we might read that as 50, which would be not actually accurate, because 0x,
five, zero is actually 80 in decimal notation.
So that 0x is really just a guide for us as human beings
to say, OK, what I'm about to read here is a hexadecimal number.
Let's just do a quick exercise where we translate
some binary into hexadecimal and then subsequently into decimal as well.
And so here, we have eight bits, each of which again is a zero or a one,
and our goal is to translate this into ultimately decimal,
but let's start by translating it into hexadecimal.
The first approach is counting from right to left,
we want to split these into groups of four.
It so happens that we have eight bits here,
and so this splits pretty cleanly into two groups of four.
But if we, for example, had seven bits, like if this wasn't here,
we would start by having one zero one zero,
and then whatever we had left over, we would just
pad with extra zeros at the front so we always had a cluster of four bits
at a time to work with.
Each of these maps directly to a single hexadecimal digit.
And sometimes you may be able to just quickly do this in your head,
or you can jump back to the table that we had here
to see when I see this particular pattern,
I want to plug in this hexadecimal digit.
And so if we do that here, we see that the one on the left, 0010,
this is in binary again.
A zero in the ones place, a one in the twos place,
and nothing else, which means we have one times two.
And so this would be a two.
And 1010, well, that's a one in the eights place and a one
in the twos place, which is 10.
But in hexadecimal, we would represent that as a, because again,
we need to confine this idea of 10 to a single place value.
We can't have two digits to represent it using hexadecimal notation.
And so this binary value, 001010, is 0x--
again, human convention to prepend a 0x in front of anything
that is a hexadecimal number--
0x2a.
Now, how do we translate this to decimal?
Well, it may help to think about how we translate this or understand
this number, 123.
When we see it, one two three just written out,
we are really doing something like this in our head where we're saying,
there's a one in the one hundreds place, there's a two in the tens place,
and there's a three in the ones place.
And we've just over time internalized that
and have been able to very quickly understand
that the number I'm talking about here is 123.
Well, another way to think about these labels here,
one hundreds place, tens place, and ones place, might be to say,
we have the 10 squareds place or the 10 to the second powers place,
the 10 to the first powers place, and the ten to the zero powers place.
Any number to the zero power is always one,
and so this is really the ones place, the tens place, and the hundreds place.
With hexadecimal, we don't have 10 as the base of the exponent here.
Instead, we have 16 as the base of the exponent.
But the rules are the same.
We have a 16 to the zero place which is one.
We have 16 to the first power or 16s place,
and we have a 16 squared or 256s place.
In our example number here, we didn't go that high.
We had 0x2a.
We only had two digits, which means we really
only needed these two place values, the 16 to the zero power and the 16
to the one power.
Now, we just translate this in exactly the same way that we would intuitively
do it in when we're counting in decimal or reading a decimal number.
This is zero times 16 squared plus two times 16
to the first power plus a times one, or 16 to the zero power.
Two times 16 is 32, and a, which again is hexadecimal's way of representing
10, 10 times one is ten, so what we're really saying
is that we have 32 plus 10.
And so to translate this hexadecimal number, 0x2a, into decimal,
we end up with 42, because 42 is 32 plus 10.
So hopefully, that gives you a bit of a better understanding
of what these cryptic number strings that you might have seen before mean.
And if you're working with programmers or you're ever analyzing source code
and you see references like this, hopefully this
gives you a better understanding of what they mean
and what they likely refer to on the system
and how that might affect things.
Let's talk a little bit more about the function, how memory actually
works now that we know how to access individual parts of it.
With the exception of hard disk space-- so again,
the permanent storage space on your device--
memory on your computer is termed volatile,
which means two different things.
One, that the memory is constantly changing.
Things are cycling in and out of it.
It's very dynamic in terms of the values that are being stored there,
again because the RAM is sort of this holding ground for everything that's
going to eventually need to go to the processor,
and things are getting swapped in and out pretty frequently.
But the other really key detail about volatile memory
is that it requires power.
If it is unpowered, if there is not electricity literally
flowing to the RAM at any given time, that is a problem
and that memory will no longer work.
In fact, after some amount of time, a pretty small amount time
like 30 seconds to a minute perhaps, without power, the electrical charge
which is used to maintain each of those individual cells of memory--
remember, a little bit of electricity being one,
and the absence of electricity being zero
is how the computer can store this idea of zeros and ones
on a physical manifestation thereof.
Without power, that electrical charge eventually dissipates.
It does not just stay.
it goes away.
And the state is eventually lost such that unpowered for about a minute
or so, all the data in RAM has effectively turned into zeros.
It has completely become completely unpowered.
Now obviously, that would be very bad if our entire system
relied on this technology.
But it's only RAM and the caches from RAM going forward that rely on this.
Processing can only happen in the processor.
This probably makes a little bit of sense.
And again, recall that a 32-bit processor
can understand 32-bit addresses.
That also means that it only has 32 bits of space in which to do anything.
So it only can work with four bytes of information at a time.
And maybe if you have a computer that has multiple cores,
maybe you've heard that term before, multicore processors,
you might have a few of these processors that can do four bytes at a time.
But either way, we're still talking about a very, very small amount
of information, maybe four to 16 or 32 bytes.
That's not very much at all when you consider
that a basic document perhaps using Microsoft Word
will contain enough metadata to be about 15,000 bytes before you even
type a single character into it.
So a lot of metadata there, and that amount of empty files
gets pretty big pretty quickly.
Because the process can only process 32 bits worth of information
at a time, any given processor, we need to move data to it frequently.
And that's what the caches are for, and that's
why each one needs to be faster and be able to get information
to the processor pretty quickly.
Because even though the processor can only
process four bytes or 32 bits worth of information at any given time,
it can do two to three billion operations per second,
so that's what a gigahertz is.
And in terms of when a processor's speed is quoted,
it's sometimes said it's like 2.4 gigahertz or 2.6 gigahertz or so on.
That means that the computer can do 2.4 to $2.6 billion things per second.
So again, 32 bits, not a lot of information at any instant,
but there's a lot of those instants within a second.
It can do two to three billion things per second, each one of those things
operating on exactly four bytes at a time, 32 bits at a time,
on a 32-bit processor, as opposed to a 64-bit processor which
can process a little bit more data.
Let's take a look now at what we determine
on your computer as the motherboard, or sort of the control
processor for everything that your computer does,
and highlight some of the different pieces of where
things live on your physical device.
So right here are some slots for RAM, so these are
basically sticks that get plugged in.
A RAM stick is just a green chip.
It looks similar to the motherboard.
They're usually green.
They have some gold connector pins at the bottom of them,
and they plug into the motherboard.
And information can then be stored there and flow to and from when
needed by the processor and so on.
So that's where these go.
This particular motherboard, which is from a computer that's
about 15 years old.
For example, I don't think most of us have
floppy drive connectors on our computers anymore, but this one still does.
Here is where the CPU would live, so this
is where the actual processor goes.
And that processor again can only do 32 or 64 bits worth of information
at any given time.
And on top of the CPU, it's not pictured here, but typically on top of the CPU
there's a giant fan, literally like mounted or screwed right above it.
And again, that's because the computer is doing two to three billion things
a second, so it gets quite hot.
And to prevent a CPU meltdown or a core meltdown,
you want to make sure to have air constantly flowing
across the top of the device as well as a heat
sink to pull all the heat away from the CPU such that it doesn't overheat,
which would create quite a big problem and eventually might
result in computer breakage if left to overheat
for a prolonged period of time.
Over here is a graphics processor.
Graphics processors are really just CPUs that
are specialized to do certain operations that make interpreting graphics
on your monitor much easier.
The math for those is usually a bit more complicated,
and so modern devices may have both a CPU and a GPU, a Graphical Processor
Unit, as opposed to relying on just the CPU you to handle
all of those different things.
And it similarly would have a heat sink and a fan mounted with it as well.
And then over here at the top, it's pretty small.
There are things called SATA connectors.
SATA connectors are what you might use to connect hard drives to your machine
so that you can extend the storage capacity of the device.
But all of these things might live on your computer,
and also all of these things in shrunk down form will live on your laptop
and even in your mobile phone.
This basic idea exists just in smaller and smaller scales
with all of the parts being similarly scaled down.
So again, CPU memory, what actually lives in the CPU as well
as the registers, those really fast things right around the CPU memory,
is the fastest memory on your machine.
But there's the least of it.
And the reason for this is that it's very, very expensive.
It is the most expensive stuff in your computer.
That is basically the price that you are paying
when you buy the computer is for that processor
and the materials that are used to allow electricity
to conduct through it very quickly really
determines the cost of the device.
So there's the least amount of it, but it is the most important memory
on your machine.
The caches, one two and three, are each successively slower than CPU memory
but also successively cheaper.
So your l1 cache is going to be a little bit slower than your CPU,
but there will be a little bit more of it.
And your l1 cache will be a little bit larger than the CPU space
that you have, but it'll be a little bit cheaper.
The l2 cache may be a little bit larger than the l1 cache
but a little bit cheaper.
Again, this is really just referring to the materials that are
used to make the memory operational.
RAM is slower but cheaper.
RAM typically used to be the most expensive
or be considered the driving cost.
If you had more RAM in your computer, that made it more powerful.
That was the cost driver.
This is becoming less and less the case.
It's still more expensive than hard disk space, which
is effectively free at this point.
It's really just how much stuff we can literally
fit into the container for the hard disk itself, which is just pure storage.
But RAM is slower memory than any of the caches,
but you're able to have more of it because it is less expensive.
So that's memory.
But in terms of hard disk space, that does not work in the same way
that RAM and the other volatile memories work,
and hard disk space is non-volatile.
Information in the hard disk is not changed terribly often,
only when we're certain that we're done working with it in RAM.
And the data there is also persistent, and that's
because it does not rely on electricity to store state.
Instead, and we're talking again specifically now about hard disk drive,
solid state drives behave a little bit differently.
They use microchips that do some different things.
But we're talking about hard disk space, HDDs, traditional hard disks.
Each cell of a hard disk is instead controlled by magnetism,
so data is stored magnetically.
If there is a--
we'll just say for purposes of this discussion
here that if the magnetism is in a down position, so south for example,
it's oriented south, that would be zero.
That's a way to represent zero.
And any magnet that is in the up position
is one, so we can have these flip states of the polarity is pointing up or north
and the polarity is pointing down or south to represent zero and one as
opposed to using powered versus unpowered to represent one and zero,
respectively in a RAM or volatile memory situation.
Because these magnets, though, don't require power
in order to work long term, that means that when the computer shuts off
and they become unpowered, the data remains.
And this is a really good thing, right?
Because if every time we shut off our computer
we lost literally all of the files we'd ever saved on it,
that would not be very effective.
We would lose a lot of the utility that we rely on computers for.
And so the way that hard disks work is specifically designed such that memory
can persist after the computer is shut off.
But again, that memory can not be processed directly in the hard disk.
We have to move it to the processor eventually.
So if our system detects that we need a chunk of memory
from the hard disk, that's all going to be moved from the hard disk
to RAM using something called a bus.
Much like a bus is used to move human beings from one place
to another in large quantities, a bus is used
to move data from one part of your machine to another in large quantities.
And in fact, if you ever see a SATA connection from a hard drive to RAM
using one of the SATA connectors we saw a moment ago on the slide,
there's usually a long, thin strip that connects them together.
That strip also forms part of the bus that
is used to transfer data from the hard drive
to the RAM in fairly large quantities.
In general, when we're working on a program,
the data for that program including the code that actually is running
is moved from hard disk to RAM.
And it stays in RAM, assuming there's no space constraint that
forces it to have to leave which sometimes can happen if you're
running a lot of programs at once.
You may notice your computer slows down quite a lot.
That's because the computer is going to have
to keep swapping things in and out of RAM
in order to process multiple things.
That's why you don't want to leave several hundred tabs open,
for example in your browser, or have 20 or 30 programs running
at once on your computer if you can avoid it,
because it's going to slow down and require things
to be swapped in and out of RAM such that it can
be moved to the processor quite a bit.
That's really going to slow things down.
While the program is running or being used by the computer,
everything will stay in RAM.
All the data will keep being manipulated there,
and then ultimately when we close the program
or once we otherwise indicate we haven't used it for some time
and the computer realizes it needs that space for something else, all
of those bits and bytes have been manipulated in RAM
will be sort of picked up and moved back on the bus back to a hard disk
where they will be resaved with the new state, such that any changes that you
make in a program will ultimately be saved back to hard disk,
but only once the program is completely done being used by the computer
and it realizes it can free up that information
and save it for long term storage.
Hard drives, though, are not unbreakable.
They have a lot of moving pieces.
A typical hard disk drive consists of several platters,
some thin metal circles spinning around a central axis very rapidly,
about 4,000 to 5,000 revolutions per minute.
So very, very quickly, with a magnetic read
write arm that extends over across the diameter of the disk, basically.
And each one of the little rings that gets
formed as you do this, as is the read write arm moves in and out,
it can access different sectors on the disk,
and those different sectors are the things that
get zeroed and oned over time.
So it is possible for hard drives to fail.
There's usually a couple ways that this happens.
If the read write arm jams, because it is on some sort of track that
moves in and out, if it jams without collapsing,
your hard drive will just stop working, basically,
because you can't read or write information anymore using that arm.
But it is also possible for the hard disk arm to break and fall.
That arm spins just above the top of these disks, and if it crashes into it,
you'll hear that sound.
That'll be a very unique and interesting sound to hear.
Suffice it to say, your hard drive at that point
is destroyed, because the collapse will crash everything,
and these things are spinning very, very quickly,
and so they're going to shred themselves from the inside.
And you will no longer be able to get any data off of that drive.
But if it's just the arm that gets stuck moving in and out but it doesn't fall
down, you will still be able to recover data from that hard drive,
and we'll talk about that shortly.
Because a hard drive failure does not mean that the data is unrecoverable
if the hard drive hasn't literally suffered this catastrophic shredding
sort of thing that happens.
That's going to render it unusable.
But if it's just the arm that gets stuck, it is still usable.
So what happens when we actually delete something on our machine?
It turns out that overwriting hard disk space
is actually a very, very time consuming and what
we might consider computationally expensive operation for the machine.
You could think about it as it has to pull all of the data from the hard disk
into RAM, change all of those bytes to delete what was there before,
and then put all of that data back.
The computer for some large files, say you
want to delete a video file like a movie, that
might be several gigabytes, so several billion bytes worth of data
that we have to delete.
The computer does not want to incur that sort of cost.
Deleting a file if it actually had to do it that way would be very, very slow.
It would compromise any other program that you had running on your machine.
And so that's not how computers actually delete information.
Rather, they just forget where the data live.
It turns out there's also something called a page file that
exists on your machine that is basically the home
address of the first byte of every single file
that you have on your machine.
And when you delete a file typically in your computer,
it just forgets where it lives.
The bytes that made it up are still there.
The zeros and ones that comprise that file don't go anywhere.
They may eventually be overwritten by some other file that
happens to be stored in that same spot, because the computer now
thinks it's open because it forgot that you live there.
And even then, this only happens when you empty your recycle bin or trash
if you're using a Mac.
If you just put something in the recycle bin,
that's not actually deleting it in any meaningful way at all.
It hides the icon.
You can't really click on that icon anymore,
but you haven't deleted that file, and you probably
know this because you can restore things from the recycle bin.
But even when you empty the recycle bin or empty the trash on your machine,
you're still not actually deleting anything in the sense
that you might be thinking is how we delete things.
Instead, your computer's just forgetting what was there before.
But those bits and bytes that comprise those files that you have deleted
are still there, and that creates a couple of really interesting security
implications.
So files that get deleted aren't really deleted,
which means that we can recover the information from them if we need to.
How exactly might we do that?
Well, there's definitely some tools out there that can be used to do this.
And again, this requires that the hard drive was not
physically destroyed in some way by the collapse of the read write arm.
But we can literally just connect the hard drive to something and have
a specialized tool that reads over all of those individual sectors
on the disk-- and this is a very slow operation for sure--
read over all of the individual sectors on that disk and just
say, well, this is a zero and this is a one and this is a zero
and this is a one until we end up with this huge file that
is all the zeros and ones that comprised what was originally
the state of that hard drive.
And we usually refer to this file that gets created,
this clone of the hard drive, as a for forensic image.
It's really just a huge file that is a complete replication
of the bit by bit content as well as any metadata that
might be associated with it that can be then created
and read on a different computer so that even though the hard drive this was
plugged into, maybe the computer got destroyed,
where we can make a copy of it and read it on a different machine instead.
So we go from this to how do people pick out what those files were?
Again, computers only understand zeros and ones
and at the end of the day, all of the stuff that
is stored in your hard drive, all those files,
anything that was stored in RAM when it was powered,
is still just zeros and ones.
They don't have icons like we see on our desktop.
They don't mean anything intuitively.
So how do we figure out what those files are?
Well, it turns out that many of them have what is called a signature
or a magic number associated with them.
A magic number is just a way to refer to the first few bytes of a file
where many file types, for examples, PDFs, most image files, most music file
types and so on, happen to start in a particular way.
This isn't a way that we ever see when we open one of these files.
But in the metadata at the beginning of those files,
there's usually a sequence of bytes that represent
a signature in effect of saying, the file that I'm about to open is a PDF,
and you can generally rely on that because these first four bytes
or whatever are these values.
Now again, it's four to eight bytes, which
means there are two to the 32 to two to the 256ish possibilities for what
these first bits are.
That's a lot of different combinations.
And so if we see a magic number randomly appear in some forensic image
or on some hard drive, the odds are pretty
good that if we see that pattern, we know that that pattern generally
refers to a file of that type, that what we have found
is the beginning of a file of exactly that type.
And we can start to interpret it in that way
maybe and maybe be able to reconstruct something from it.
So for example, it turns out that most PDFs have in their metadata--
and we never really see this--
the characters percent PDF at the beginning of them.
And that translates into this sequence of bits using the Ascii
table that we've talked about before, and we
don't need to get into a lot of detail, and it translates
into these hexadecimal values.
And so generally, if we happen to encounter exactly this pattern of 32
bits, which we should only expect to see at the beginning of a PDF
or otherwise once every one in two to the 32nd times--
like it's pretty uncommon to see exactly this pattern
and we're looking for exactly that pattern.
If we see those bits, generally what we can do
is start to interpret the rest of this file as a PDF
until we encounter some signature that we've reached the end of that.
Whether that's a whole bunch of zeros or whether that's a signature
that is again perhaps the start of another PDF.
Now, of course it's possible that you'll end up with a false positive.
For example, anybody who's examining these slides
at some point in the future-- say that my hard drive crashed
and I happen to literally have the characters percent
PDF typed on to this slide.
If you were to forensically recover my hard drive and analyze it
and you found this PowerPoint file that is where I'm presenting the slides from
and you saw literally the characters percent PDF in it as zeros and ones,
you might mistakenly think, this happens to be a PDF
and start to interpret from this point forward,
this yellow point forward as a PDF.
But it wouldn't work.
And that's OK.
You might get a false positive sometimes,
and then you just kind of disregard it and you keep looking.
You look for a different type of file.
You look for a different file signature and so on.
But it can happen that you have a false positive like this
in situations where you're trying to sort it out,
because you have no other context clues.
All you have are the bits and the information
that you know about file signatures.
OK, so we have this empty trash or empty recycle bin icon or menu
option on our computers.
But now we know it doesn't actually empty the trash at all.
So how do we actually delete files from our hard drives
as opposed to just having our hard drives forget
or our systems forget where on the hard drive that file lived?
We probably want to do that at some point, get rid of the data
on our machines.
How exactly can we go about that?
Well, there's actually relatively few ways to actually delete this data.
The first of which we've already kind of discussed,
which is physically destroying the hard drive.
There are services out there that will shred your hard drives for you.
If your read write arm breaks in a catastrophic way,
your read write arm will shred the device for you itself.
That's one way to ensure that your data is protected or deleted
is to make it absolutely impossible to recover information
from it by physical destruction.
You can use a tool called a degausser A degausser is really
just a very strong magnet that you hold over the device for a period of time.
It will also usually cause some sort of physical damage,
because it's also going to mess up some of the metal that
is inside the machine that is not storing data
but is just structural metal.
So usually a degausser will not only wipe out information
by setting all of the bits, flipping the polarity of all the bits from south
to north or something like that, but it will also
usually cause some sort of mechanical wear just based
on the strength of that magnet.
But then we have this thing Secure Empty Trash.
We saw this in the menu a second ago.
What do you think Secure Empty Trash might do?
Well, one thing that you might think is that it
would overwrite the data with random bits, and you would be correct.
That's what Secure Empty Trash does.
So instead of just deleting information from the hard drive
by forgetting where it lives, instead we actually go to that spot.
And instead of writing all zeros or all ones,
we just write random bits over it.
But it turns out that this is actually not good enough
to delete information on a single pass.
But a single pass is actually what Secure Empty Trash does.
It only makes one pass through, randomly setting each bit of that file
to a one or a zero.
But it turns out, and the physics of this is a little bit beyond me,
but it turns out that when the polarity of a magnet on a hard drive
is flipped from zero to one, there's actually sort of this lingering halo
effect that it leaves behind so that you can tell that this bit is a one now,
but it used to be a zero.
And that effect lingers for a little while.
But if you keep changing it multiple times over and over,
eventually that effect gets lost.
So you can tell what bits--
imagine every bit was a one after you make one pass through it.
All of those things that were ones before, their polarity didn't flip.
There's no halo effect.
But everything that used to be zero and is now a one
has this slight signature left behind that says, this used to be a zero.
And a good forensic analyst is able to take a look at that.
As it reads, it can read the polarity of the magnet
and see that it's slightly not exactly zero and not exactly one and say, OK.
Well this bit probably used to be the opposite.
And so even making one random pass across a hard drive
is not enough to definitely securely erase the data on it.
You actually have to make it's considered
to be seven passes is the industry standard
to make sure that enough randomness has affected each of the individual magnets
such that you can't tell what was there before.
So to truly securely erase the hard drive and preserve it in a state where
you can actually use it, you need to use--
and there are software tools that do this--
a tool that will overwrite the drive randomly
multiple times to eliminate any of that lingering halo effect.
But Secure Empty Trash does not do that.
It only makes a single pass over the drive.
So enough to cover it up for undescerning
eyes, but experts who study this and work with this kind of data
regularly might still be able to figure out what the original data was
if just a single pass is made.
So why is this important?
Well, there's two reasons.
One, as attorneys, we want to make sure that we are doing everything
we can to protect our clients' data.
And also as we're working with those who may be less technically inclined, it's
important for us as part of our competent representation of clients
to inform them about what we can about the technology implications of some
of the things they do from a legal perspective.
And so if you're working in a large firm environment or as an in-house counsel,
it's probably not going to fall to you as an attorney
to develop some sort of protocol for establishing the best
practices for working with client data.
But it is really useful to understand what these protocols are
and how you might be able to contribute to a conversation
about making these protocols more robust.
Here are some basic strategies that you can use as an attorney
to protect your own client data but also to advise clients
so that they can protect their data for their clients and so on.
So the first one is quite easy, and that is to encrypt your hard drive.
So we talked about encryption previously,
but you can also encrypt your own hard drive such
that when your computer turns on, you need to enter a password.
It's again similar to this public private key idea
that we've previously discussed.
You need to type in this password in order for your entire hard drive
to be unencrypted such that you can then read the data on it.
Most operating systems now provide tools that
are built into the operating system itself so that you can do this.
So there's really no excuse not to do it.
It is a very easy, straightforward and simple way
to take a pretty strong step at protecting the data on your machine
easily.
Again, this usually requires a password.
Typically it'll be after you turn your computer on before the operating
system itself loads, the operating system being one of the few things that
is not encrypted such that it can then open the files
and unencrypt everything and so on.
But it will not proceed past the operating system load point
until that password is provided.
But do be careful, because some of these systems,
particularly the more advanced ones, after a certain number
of incorrect guesses will begin to securely wipe your hard drive using
multiple passes of zeros and ones.
And so if you think there's a danger that you might forget your master
password so to speak for this hard drive encryption,
you might want to keep something somewhere to remind you.
I wouldn't recommend like sticking a sticky note on the monitor
or anything like that, but have some sort of way
to remember that password in the event that you might forget it,
because you might lose data if you guess wrong too many times depending
on which hard drive encryption tool you are using.
Another relatively easy thing to do is to avoid
using insecure wireless networks.
These are generally not as common anymore.
Most people have wireless networks that require a password,
and usually wireless networks that require a password will then
have encryption for that individual making the connection
on the system on the network.
But unsecured networks do provide opportunities
for those listening using tools that are called packet sniffers, which
are literally just listening and gathering
data on all of the packets of information
that are being transmitted over the internet in the vicinity
of the unsecured wireless network.
And so you might see-- this as a screenshot of a tool called Wireshark,
and it's a little blurry.
There's not a lot of relevant information here.
But on an unsecured network, it is possible to read
all of the bytes and bits that are flowing through,
translate them into their Ascii equivalence,
and realize that this person is providing a username
and password and an action logging in.
And so anybody who is able to then take this information and see what IP
address it came from-- and we'll talk about IP addresses shortly as well--
or where it was going to might be able to use
that data to log in as that person, which would definitely not
be a good thing at all.
One way to get around this if you find yourself in a situation
where you need to connect to the internet to do work
or for whatever reason you need to be connected to the internet
even if you're not sure about the quality of the network
is to rely on private or work provided VPN services.
VPN is a virtual private network, and it provides a way
to connect to a trusted encrypted network, have that network act as you,
effectively for providing encryption services for your web traffic
even if you're not sure that your traffic itself is unencrypted.
So VPNs are available at most businesses or also available online.
Relatively inexpensively, you can buy tools
that would allow you to make use of a virtual private network.
Password managers.
Password managers are great.
Honestly, I can tell you that I don't know most of the passwords
that I use on a daily basis because I rely on a password manager.
There are several services out there--
Last Pass, One Password, and others.
Basically, the idea is the tool will generate passwords for you.
You only have to remember the master password, the one
password that you can use to unlock everything
to open the password manager itself.
And then once you're logged into the password manager,
you just direct it to log in on your behalf to different services.
You usually tell it this is the URL I'd like you to go to,
this is the username to use, and then the secretly generated password
that you don't generally know is stored in the password manager itself.
Some of these tools are local to your machine.
More often than not, they are starting to migrate
to be cloud based services, which does introduce another interesting question
of do you trust your data to be stored on the cloud as opposed
to being stored on your device?
And that's really a question that you should
consider when you're thinking about using one of these tools.
Most of these tools also have an excellent secondary effect,
which is that they often provide two factor authentication support.
And two factor authentication is something
that we will talk about shortly as well, but it is usually something
that you know, like a password or something
that the password manager knows, and something you have like your cell
phone, for example, that might be getting a text message with a code
that you're you're supposed to enter as well.
And the idea is that an adversary who is trying to hack into your account
probably may know your password but won't have your phone,
or may have your phone because they took it but won't know your password.
And so these two factors are designed to preempt basic hacking attempts.
But as I mentioned, these tools are great,
but you should be skeptical of them, particularly
if they are cloud based, because it is possible for bad things to happen.
So for example, not too long ago, a few million users
of the password manager Blur had information that was leaked online.
None of this information was actually their passwords.
It was more customer related information, sort of ancillary
this is their email address and some other stuff.
But it hits a little close to home.
And so again, always be skeptical when thinking
about your own data and your clients' data.
But these tools are generally more good than bad.
But again, the decision of whether to use these tools really
does ultimately fall to you having done research into them,
seeing whether or not they make sense for you,
whether you want to take advantage of the advantages that they offer.
If you're not going to use a password manager,
you should at least be sure to use complex passwords
and certainly make sure to avoid using the same password for multiple services
unless it's like a throw away password that you use on things
that you don't care about.
But you want to definitely avoid using the same password
on important services.
So like your Gmail account or any client log in related information
that you have, or anything banking.
You want to use different passwords for all of those things.
Passwords that have less than eight characters
or less than or equal to eight characters,
you should effectively consider have been broken and hacked already.
Those are not secure.
Computers are definitely powerful enough nowadays that it can be brute forced
in a relatively short amount of time.
We're still talking maybe days here for an eight character password,
but that is not that much of an effort.
Passwords should be at least 12 characters now for sure.
You should definitely have a mix of uppercase, lowercase letters, numbers,
symbols, anything like that.
But anything that is less than or equal to eight characters
should definitely be considered to be effectively hacked already.
And if it hasn't been hacked already, certainly it
is capable of being hacked very easily by anybody who
wants to put in the effort to do so.
You should also change your passwords as frequently as you can.
For example, I have a bank that requires me to change my password every 90 days
in order to continue to use their online banking services.
And on the one hand, yes, you may find that kind of annoying.
But on the other hand, it's good to keep things changing so that you're never
having a password get stale and potentially then leaving it vulnerable,
especially if it's the password that you may have
used on multiple services in the past.
It's a good thing to keep in mind, especially
if you don't have that many passwords that you
need to maintain to change them as frequently as you're able to.
Creating backups.
Creating backups of information is really
important, because sometimes things will go wrong that you don't expect,
like maybe your hard drive will suffer some sort
of catastrophic mechanical failure and you wouldn't otherwise have a way
to get that information back.
So periodically backing your data up protects you
in the event of hardware failure or in the event
of some sort of ransomware attack where an adversary breaks
into your network, your office's network for example,
and doesn't take any data away but encrypts it using their own public
and private key such that there's no way for you
to read that information until you usually pay them
some ransom, which is usually money or something like that
or bitcoin or the like.
So you should back your data up pretty regularly.
You can back it up in the cloud using cloud based document storage services.
You can also just back it up on paper in certain situations as well.
But definitely back it up to non network connected machines,
so a computer that you have that is never connected to the internet
and is primarily used just for its hard drive space, basically.
Or to flash drives or CD ROMS if you're still using that technology.
Just have some offline way to access important data in the event
that something goes really, really wrong.
Also, have an archival plan for data.
You don't need to keep data around forever.
We oftentimes think that because we're living in this digital age
that everything we do persists forever and needs to persist forever
and is tracked.
But that's not entirely true, particularly
if we are proactive in doing our part to archive or delete data
when we no longer need it.
Particularly when you're considering client data,
it is important to develop a consistent plan for when
you are done working with that data.
So for example, it may be the case that in your firm after three years of no
longer having any matters related to that client,
it is just your office's policy to delete that client's data.
And that might mean transferring other data that
might be on a shared disk with them off of it
and literally going through the process of either destroying the drive
or doing the multiple passes over the drive using zeros and ones randomly
just to obscure that data, because having that policy of not keeping
things forever generally protects you, protect your clients if that data is
no longer needed.
Also, make talking about data security a priority.
I know it's not exactly the buzziest conversation
to have around the water cooler, but a lot of people
are not as thoughtful about technology as you may be taking this course.
And it may be a shock to them to realize that when
they delete a file on their machine, it doesn't actually do anything,
basically.
It just forgets that information, but that information still lives on.
You don't have to be a tech expert to educate others.
Particularly as someone who's coming into it with maybe a bit more of a leg
up in understanding technology, speaking to individuals
who may not know anything about what this technology is you
can really do yourself and your colleagues and your clients a service
by making this part of a typical conversation.
Share your knowledge with others in your office and in your field.
And finally, think about establishing a compliance protocol.
A lot of these things that I've just described
are very, very easy to set up at the outset.
It is not difficult to say, I'm going to change all my passwords,
and I'm going to use this password manager,
and I'm going to write this policy for deleting information and archiving
information periodically.
The problem is that it becomes over time something that we forget to do.
And having regular periods of having someone
designated to make sure that these policies are being followed
is really important, as we'll see shortly when we talk about some
of the ABA ethical requirements for lawyers dealing with technology.
You want to make sure that if you establish some of these ground rules
for working with data, that you continue to follow these rules as you work
with this data for the months and years and so on going forward
as opposed to just doing it once and forgetting about it.
Because technology is not static.
It's going to continue to advance, and we need
to stay ahead of that as attorneys.
It's part of our obligation to really understand this technology,
stay current with any changes, and adapt and change our policies accordingly
so that we're always staying as close to the cutting edge as we possibly can.
I really encourage you to volunteer with the compliance team.
You may have a compliance team, particularly
if you are at a large office or in-house counsel
setting, who is tasked with developing these technological policies.
And even if you don't feel like you want to advise on new avenues to pursue
or new policies to initiate, you still should be part of that conversation.
You do bring something valuable to the conversation just having the knowledge
that you have from a course like this and should be part of this conversation
so that you can contribute to it more in the future as well.
I'd like to conclude our discussion today about security
by drawing your attention to two really important ABA ethical decisions
that relate to lawyers and technology and what
lawyers should do in the event of a data breach at their office.
And let's start by taking a look at formal opinion 477R which
was released by the ABA in May of 2017.
This opinion deals with attorneys' obligations with respect to technical
know how.
So it is now considered part of competent representation
for an attorney to be considerate of the technological implications of what
they do in their office.
What does it mean to store documents?
What does it mean to secure communications with clients?
It is incumbent upon us as lawyers to stay abreast of these developments
and really be informed about them and inform
our clients about the ramifications of some
of these new technological advancements.
It also formalizes the requirement of offices and firms
to have a compliance protocol.
What do you do when you receive client data?
Now, this opinion came out in 2017.
It replaced something from 1999, which at the time
the previous ABA opinion stated that all communications, including
unsecured unencrypted email, were generally
considered quote unquote secured.
Obviously, I think we can agree that is not the case anymore
and certainly the ABA agrees that is not the case anymore.
That's because we've transitioned from a time when a lot of lawyerly work
was done not using the internet, not using emails.
It was done using fax and paper and so on.
And now we've transitioned to a mostly electronic way
of providing legal services to our clients,
and so our technological rules of our self-governing ethics
need to evolve to account for that.
It also brings up a very interesting question which is something just
to think about going forward or discuss with others in your group of how
do you reconcile a situation where you have a client who doesn't want
to use secured communications or doesn't want
to secure their data in working with you?
How does that square with your job or your requirement
as an attorney to ethically abide by this opinion
and be mindful and guard clients against technological mistakes?
Is it possible to provide competent representation to a client
if they are unwilling to adhere to your firm's compliance protocol?
It's a really interesting question that I don't have an answer to
but provokes an interesting discussion about what does it
mean for us to have client intake and work with clients,
and what happens when the client's wishes run
against our ethical obligations?
That's not a novel question to lawyers.
That presents itself in different ways, but via technology,
do we have yet another way we might have to consider this dilemma?
Subsequent to 477R, a year and a half later in October of 2018,
the ABA issued formal opinion 483, which kind of
is the natural follow on to 477R, which deals with what
happens if a lawyer's information is breached?
If there is a data breach at the firm and client data is compromised,
what do you have to do?
One important thing to think about here is that this opinion formalizes
the notion that has sort have long been held in technological circles
that there are two kinds of businesses that exist--
ones that have been hacked, and ones that will be.
Not ones that might be or not ones that could be.
And perhaps even these are ones that have been and they don't know it yet.
But it's just such a part of life nowadays
that businesses either have been hacked or will be hacked,
and that is the mindset that you should have
when you are thinking about protecting client data, bringing in consultants,
and hiring people to do their best work to defend your clients' data.
Now, it turns out that law firms tend to be excellent targets for hackers,
and the reason for that is that they have a lot of very valuable data.
And unfortunately, the history is such that it is not always as well protected
by law firms as it might have been by the clients themselves,
because we as lawyers have been as equipped
to have a conversation about technology and how that technology might
affect our representation of clients.
The opinion describes a bunch of different cyber episodes, so to speak,
that might comprise a data breach, which would rise to the level of needing
to report to a client.
These include things such as ransomware attacks,
as we've discussed a little bit earlier today,
systems attacks that might break or somehow damage
the infrastructure of the firm or workplace,
as well as exfiltrations, which are probably the worst
kind of breach, which is someone hacks into your system
and is able to remove data such that you may not even have a copy of that data
anymore, and that's why having backups is so important, but removes
that data from your servers, for example, to the adversary's servers.
There is no ethical violation in being hacked.
It's really important to make that very clear.
The ethical violation occurs when non reasonable efforts are made,
unreasonable efforts are made to protect that data.
If we as attorneys are making reasonable efforts to protect our clients' data
and we still get hacked, we have not necessarily done anything wrong
as long as we were doing our best to protect or prevent that
from happening in the first place and once we
detect that it has happened, to make every reasonable effort to stop
the attack if it is ongoing from continuing.
This also introduces a very interesting question
of what to do with former client data that has been hacked,
and that's why it's really important to establish
some sort of archival or deletion plan for working with that data.
The ABA proposes a couple of different ways
to resolve how to deal with informing a former client about information related
to a hack.
But one of the most important things to draw from this opinion, I would say,
is discussion about data retention needs to be
part of your firm's intake process or your intake
process for dealing with new clients.
Who owns what has always sort of been part of the conversation.
Generally as we know, we return client data to them
when we are done working with it.
How does this work in a digital context?
It is really important for your intake plan
at your firm to handle what happens to digital versions of client data
when the representation has concluded because the matter has concluded.
Speaking of concluded, that is going to wrap up our discussion today
on security.
This will be the first of our two discussions
generally at length about security in the legal context.
But hopefully you've come away from today
with a better understanding of how your system works, what memory is,
and why when we delete things on our hard drives,
it doesn't actually get deleted and what some of the ramifications
might be for that.
And hopefully you also have come away from this
with an understanding of what to do going forward establishing
best practices for working with client data
to stay within the ethical guidelines proposed by the ABA,
and just to generally have a more technical conversation with clients
about your representation of them and what happens to their data
when that representation has concluded.