All right, let's take a look at a pretty
broad and all encompassing module.
Module 15 deals specifically with data
security, and there's a lot of aspects to data security.
Got a lot to talk about in this module.
First, the definition of data, critical data, business critical data.
Data in general is ones and zeros.
It exists in three states.
We're going to talk about that here in a second.
Critical data is essential for some function or purpose.
If it's business critical, it's essential for the survival of the business.
Data is the heart of any organization.
Critical data contains information important for business operation.
Now, there are differing levels of
importance, and that's where classification comes in.
Identification and classification of
business critical data is the first step in securing an organization's data.
We have to identify catalog what we have.
We have to rank it on criticality and sensitivity.
We need to come up with classification levels, which we're going to talk about.
We need to assign each data set at a
classification level, and then we need to implement countermeasures and controls
designed to protect the data, different classifications.
Now, you'll spend more money to implement more protection.
What you stand most at risk, if it's
disclosed, dictates what you spend more money for.
Again, we mentioned before that everything is cost benefit driven.
Quantum analysis assigns quantities to
everything qualitative is opinions, best guesses, and so forth.
But most everything is ultimately boiled
down to dollars and cents, the amount of data or amount of financial
impact and what we spend towards protection.
We have lots of risk calculation, risk formulas and so forth.
At the end of the day, that all applies numeric values and that's how we rank
everything and identify critical versus less critical.
Examples of critical data.
Accounting files, pretty self explanatory.
Ledgers, accounting information, who owes
us, what we owe people, banking information.
Databases or any business related data.
Databases are the heart and soul crown jewels of any organization.
That's where we store all of our mission critical data.
Business related data, customer information, so forth.
Operating system files purchased with the computer, CDs, software, etc.
Any supporting software for restoration.
A lot of times we'll call that restoration media.
Important office documents, spreadsheets, etc.
Software downloaded, purchased from the internet.
You can almost always go back and redownload it.
But for quick access, anything that you've
purchased should be available in a local backup.
All right, contact information, email address book.
A lot of times that contact information is populated databases.
An email address book actually does qualify as a flavor of database, even
though it's not a relational database like we typically think within databases.
Our data security.
All right, involves securing data, right?
Controlling access to ones and zeros.
Now, we've talked about this in bits and pieces throughout the course.
It requires identification, authentication,
authorization, accounting, auditing, and so forth.
The three states of data.
We've touched on these in earlier modules, but it's all about protecting ones and
zeros from unauthorized disclosure, improper modification, ensuring that
they're available when and where they're needed by authorized individuals.
Again, CIA, we've mentioned that more than once.
Data at Rest is data on a fixed storage device.
Data at rest, think of hard drives.
Data at rest, think of non volatility
storage, which means it doesn't require electricity to maintain its information.
Data in use would be data in memory.
Ram, for example, is a volatile storage device.
If you take power away from RAM, you lose the information.
Anything in RAM, if the system powers down, is lost.
We'll talk a little bit more about that in forensics.
But anything that's memory resident is data in use.
Then data in transit is ones and zeros across a communication medium.
Again, examples, data in use might be resident memory on a laptop.
When you're working with sensitive data, it exists in memory.
A memory dump of that system can give you all sorts of useful information.
We may want to consider encrypting data even as it resides in memory so that it's
not subject to disclosure in the event of, say, memory dump or memory access.
Data at rest or data in rest in a fixed
storage device, data in transit, anything to get across the communications medium.
The controls, again, are the safeguards we're going to put in place to protect the
ones and zeros in all three of these states.
Unintentional acts of misuse, destruction, or data modification.
Intentional or unintentional.
Again, data at rest, inactive data stored
digitally at a physical location or physical device.
Data in use, in memory, data in transit, traversing some means of communication.
Anything in motion is in transit across a wired connection, across a wireless
connection, across an infrared smoke signals, just kidding.
We don't use those anymore.
Examples, customer bank balance, data stored in RAM, email being sent.
With emails, there's a couple of different security considerations.
You want to protect the email itself and the communications media.
So a TLS connection and an encrypted email.
It's double bagged, more or less.
Security controls for data at rest, data
encryption, password protection, tokenization, which we'll talk about, data
federation, data in use, strong authentication,
tight controls on the data's accessibility, full memory encryption, or
partial memory encryption, strong identity management.
Again, all of this starts with properly identifying and authenticating your users.
Making sure that they are in fact who they say they are.
Remember that single factor authentication
like passwords is the weakest form of authentication.
You need something more than that.
You also have malware infections, things like that.
Start with strong identity management.
Data and transit, SSL and TLS, we've had more than one discussion of that.
Email encryption tools like PGP or SMI, we've talked about that as well.
And firewall controls.
Again, these are just a few examples, not an exhaustive list.
The information management lifecycle.
Basically, we've got the collection, the
creation through the destruction and all steps in between.
The management of information helps organizations meet, we've talked about
this before, legal compliance and competitive requirements.
Information lifecycle management monitors
and tracks the passage through all stages from creation to destruction and helps the
organization reduce cost, reduce risk, maintain effective governance.
Your stages are creation or collection, organization, utilization, remediation,
storage, and erasure, which sometimes is swapped out for the term destruction.
You should not maintain any information longer than you have to, period.
You
can more effectively secure information by not having it there in the first place.
If it's not necessary, get rid of it.
If you're at the end of a retention period, get rid of it.
If you're not required to retain it, get rid of it.
Otherwise, you incur risk just by maintaining or storing the data.
We're always spending money to protect anything in our organization, and the more
sensitive it is, the more we spend towards protection.
That's directly related to countermeasures and controls implemented.
Data roles and responsibilities.
Now, these definitions will vary
considerably in job roles from text to text to text.
You may see other sources of information
that throw a little bit of a different spin on who's responsible for what.
It also is a little bit different
depending on the access control model that you're using, whether it's DAC versus MAC
versus R back or discretionary versus nondiscretionary models.
The data owner, let's start off with that.
The data owner has the ultimate
responsibility for the security of the data.
The ultimate data owner is the CEO of an organization.
Starts off with the big Kahuna, it's their responsibility.
However, is the CEO going to be the one
making all of the security decisions on how to protect?
Are they going to be configuring access
control lists and doing backups and restores and maintaining log files?
Probably not.
They're going to delegate that responsibility to business unit managers.
The business unit managers will delegate
certain responsibilities to things like the custodian.
We have multiple roles in the models here
that are responsible for or use the data a certain way.
We're going to lay out some definitions
and I'm going to talk about a couple of variations of that.
The CEO is the ultimate data owner.
They're going to delegate ownership down to business unit managers and so forth.
We're then responsible for making
decisions regarding the data, who has access and so forth.
That can also vary depending on the model.
Discretionary access control model, the owner dictates who has access.
In a non discretionary, a central body does that.
The data controller and the data processor.
Normally, you'll talk about data owner, you'll talk about data steward or
custodian, and then you also talk about the user.
Those are the three basic levels.
Now, you may actually have an administrator thrown in there as well.
But for simplicity, let's say this, the data owner is responsible for safeguarding
the data, makes decisions regarding classification levels, things like that.
The custodian protects the data, backups and restores, makes sure it's available.
In a DAQ model, the custodian also will potentially assign permissions or allow
access, and the user actually uses the data.
An administrator is often thrown in there as well, a security administrator.
The admin in a non discretionary model or even discretionary for that matter, will
actually set permissions, provide access, configure access, control list.
Again, you'll see a little bit of
variability on these definitions across different sources.
The controller and the processor.
The controller collects and controls the
processing of data provided to the data processor.
The processor actually processes the data by a given controller.
If you are the owner of the data, but you're outsourcing it for additional
processing, something like that, that may go to the controller of the processor.
If these are third parties, you need to secure that transfer.
You need to set up internet connection security agreements and memorandums of
understandings and service level agreements and all that good stuff.
You're also responsible for the security
of the data while it's under their control.
This is business partner relationships, security vetting and that thing.
So that may be internal and it may be external.
All right, so the user, again, is
ultimately going to use the data, whatever it's intended for.
But all of these entities are responsible
for recognizing how to safely handle the information and handle it securely.
There'll be a policy that dictates how to
treat this data, typically different classification levels, how to protect it
at rest, in use, and in transit, backups, and so forth.
So a privacy officer is a dedicated role for...
There's lots of sea level roles these days.
Chief security officer, chief executive
officer, chief technical officer, chief privacy officer is responsible for privacy
related concerns where we've got person identifiable information or private data.
We're supposed to do our best to protect this information.
There are repercussions, regulatory compliance requirements, and so forth if
person identifiable or private information is disclosed.
Large scale data breaches can cost you lots and lots of money in fines and
penalties and also in loss of market, reputation, and customer base.
They're a senior executive who's
responsible for the privacy organization's data.
They maintain privacy policies as well as
investigate and track incidents and security loopholes.
The data protection officer is
responsible for meeting the compliance requirements of the organization.
Again, compliance is a big deal these days.
Lots of stuff to comply with.
You also have a lot of nebulous, unclear directives.
Having two different auditors present you with the same criteria can also be a
little bit maddening since you'll get two different interpretations of the criteria.
There can be some confusion there.
A full time role for compliance is not a
bad idea, depending on the organization size and structure.
Data classification, monster important.
My grandfather, he didn't make this up, but he used to say all the time, a place
for everything and everything in its place.
My dad will definitely concur with that.
That's filtered down to me as well.
Everything should be identified and
everything should be classified by a bucket and labeled accordingly.
You should have a classification for
everything and everything should be classified.
Formal definition for all different data types.
The classification schemes are laid out with specific criteria of what it takes to
meet that classification level, which is typically sensitivity.
When you look at things like military
versus private sector, it's the level of severity to national security or to the
organization's survivability and profitability.
You have things like grave, serious, some
damage in your standard classification schemes.
Data classification, assigning sensitivity levels and trying not to get too crazy
with the granularity here because then there's confusion.
Generally speaking, top secret, secret,
confidential, sensitive, unclassified, and different levels.
Four to five levels is generally the most you're going to want.
A lot of times it's a four level system, zero through three.
Data classification provides organizations sense of data criticality.
Well, security needed to be implemented for different types of business data.
Again, you have top secret, high level
confidential, proprietary information for internal use, public documents.
That doesn't really follow any specific standard.
It's a hodgepodge between the two.
But then you directly identify what needs to be done to protect
that data at rest and transit and use backups and so forth.
Your data security technology.
First and foremost, you have a classification scheme, you lay out.
Also, the classification and declassification process.
Really important that you elaborate on,
formally document, identify, there we go, the steps required for declassification.
Once data gets a classification level, it's not going to stay there indefinitely.
It's sensitivity can actually drop over time, and then you have declassification.
You want Periodic Reviews for declassification just so you're not
spending more money than is necessary to protect the data.
Data access control.
Authenticates and authorizes users to access data.
We've talked about access control.
We're going to talk more about access control lists, access control models.
Data encryption.
We've definitely talked about encryption, symmetric and asymmetric.
Transforming information, transforming it
mathematically in a way that cannot be read by an unauthorized party.
Got it. Data masking, protecting information by
obscuring specific areas of data with random characters or codes.
Think of that as redaction.
Data resilience and backup, making a duplicate copy of critical data.
It's going to be used for restore and recovery purposes.
We're going to finish this module off with
discussions of backups and folds and incrementals and differentials.
You want to also accommodate local
restorations and remote off site restorations.
We'll talk about business continuity and
disaster recovery planning in a later module, which definitely involves backups.
Data destruction, destroying data so that
it cannot be recovered and used for wrong motives.
We got a forensics module we're going to
be talking about in a bit, and it's forensics is all about finding artifactual
data and evidence and just deleting data is not good enough.
There's all sorts of forensic recovery procedures that can be deployed.
So destroying data that cannot be
recovered and used for wrong motives and then data retention, securing data
securely for compliance or business requirements.
Now remember, you only retain data as long
as it's required and then you get rid of it.