Okay,
one way to set permissions or set access controls is to use an access control list
setting an ACL and permissions to file and folders and windows.
Each object has a list of subjects and the level of access they have to the object.
An ACL or access control list is tied to the object.
A capability table is tied to the subject.
You've got a list of resources the subject can access in their level of access.
Then the combination of the two is referred to as an access control matrix,
which is both ACLs and capability tables, rows and columns in a table.
Access controls are used to authorize
users, groups, and computers to access files and folders on a computer.
So you can grant access to different security principles.
It's generally recommended that you put
groups on ACLs and you populate those groups with individual users.
That doesn't necessarily give you that granularity of access control since I
could belong to a group and I wouldn't necessarily have a need to know for a
specific file that maybe the rest of the group has access to.
But for ease of administration, you put
users in groups, you give groups permissions.
From a security perspective, everybody
should only have enough to do their job and nothing more, which would mean
individually pop in the access control lists as needed.
But that's a lot of overhead, administrative, and actually there's a
security issue with that, since you may actually, when the user leaves, you may
forget to take them off of an A CL somewhere.
When a user application request access to
the operating system, they need to submit their credentials to the OS.
The credentials are access tokens created
every time the user application tries to log in.
The OS then compares this access token.
I log in, my access token is my security ID and all of the security IDs for all the
groups I belong to in a Windows environment.
Whenever I try to access a resource, that access token is checked and I look for a
Sid that matches a Sid in the access control list.
If there are multiple Sid matches, you look for the least restrictive except in
the case of Denied, and it's checked for my level of access.
The OS compares these by using a reference
monitor which is implemented by the security kernel.
We talked about reference monitor in an earlier chapter.
That reference monitor will be invoked for every access attempt, which means
everything goes through a verification reference monitor.
It's going to determine whether I'm authorized.
Authorization says, Okay, you've been
identified, you have an access token, but are you authorized to view this object?
The access control entries can block or
permit the services depending on the object type.
Your typical ACL in Windows.
Windows has NTFS, New Technology File
System permissions that are actually made up of more atomic or granular permissions.
The special permissions you're seeing here
are 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.
I can remember it's 13 or 14 on that.
These are the special permissions, but
they are consolidated or grouped together for the molecular.
Atomic, granulars, molecular atoms combined together.
Full control is everything.
Modify is everything but delete sub files and folders.
In a nutshell, you can split errors even
further by assigning special access permissions.
You want to stay away from that and just
use the standard five NTFs and six NTFs folder permissions just
because it's easier to check effective access and so forth.
Full control, modify it, read and execute it, read and write.
Back in my Windows administration and Microsoft engineer training days, I could
rattle off all the subcomponents and so forth.
I don't do that on a regular basis
anymore, so I have to look at tables for it.
But full control gives you full control
over the file and the ability to sign permissions.
Modify allows you to actually delete, which is different than Read and execute.
Read and execute allows you to read the file and execute it.
Read allows you to read it and write allows you to actually add to it.
You can add to the attributes, add to the
content, the modify gives you the delete capability.
Full control gives you the ability to sign permissions.
Each of these permissions includes a
logical group of special permissions, which again are these.
Setting access control list and
permissions to files and folders and windows, you just right click any file or
folder object and you go to the permissions.
We're not going to do a lot of this in the demo.
You're going to be playing with some of this in the labs.
But go to the specific file or folder you
want to set a permission, right click, go to advanced, set add.
You can also set inheritance and ownership and so forth in the same locations.
Setting access controls and permissions to
files and folders in Windows, NTFS permissions to folders.
Now, folder is a little bit different
since folder has list folder contents, which would be like reading a folder.
These permissions do inherit down.
You can set permissions at the folder level and it applies to the files and
folders in the folder if you've set permissions inheritance to take place.
Your typical folder permissions are
everything we saw in NTFS plus this list folder contents.
Each of these permissions also includes a logical group of special, which again are
pretty similar to what we saw in NTFS file permissions.
Inherence is definitely a concern.
By default, inheritance flows down until you tell it to stop.
You could set different permission structures.
Then shared folder permissions or shared
permissions are going to add to this, which could be further restricted.
You combine shares with files and folders.
Everything we're talking about with NTFS requires that you're locally accessed in
the box, you're logged in, you're actually the local file system.
You have shared permissions which give you a window of access to the NTFS file folder
structure, and those can further restrict as well.
Those are actually a lot less granular.
You've got read change and Full Control.
All right, so in Windows, you've got
bunches, 14 special permissions, five NTFS, six folder.
In Linux, you got three.
You have Read, Write, and E xecute. Wow.
And we get everything done with those three permissions.
But in Linux, ACLs are used to implement access control using Read, Write, and E
xecute for the owner, the owner's primary group, and then everyone else.
So a little bit different.
So that access control list on that file
is set by using a plus R plus W and so forth.
Or you can use a numerical equivalent with
the Chmode command where you can use seven and six and five and four, which I'm going
to work through that here a little bit with.
You're going to be setting some of those permissions in the labs.
All right, set FACL command allows you to assign permissions to Alex, for example.
Get F ACL displays the file name, owner of the group.
And then the LS tack L shows you the LS shows you directory contents.
Ls tack L will show you the permissions. Crypting data rest.
Before we go any further, let's talk a
little bit about the Read, Write and the executes.
Read, Write and E xecute.
If I wanted to add permission to a file, I
could say plus Read plus Write plus execute.
I can add that to a file directly.
Then the mode command is used in Linux to
change the mode or change file permissions.
That may be a little bit cumbersome.
Instead, I can use numeric values, decimal equivalence that are based on the binary.
For example, if I wanted to add Read,
Write, and E xecute, I could just do seven.
There's the owner's primary group and then everyone else.
You actually have three sets of
permissions, Read, Write, E xecute, Read, Write, E xecute.
If I was to set Read, Write, and E xecute,
I'm flagging every bit and it's four plus two plus 2 plus 1.
If it was just read and execute, again,
you got four, two and one, you would flag Read and execute but not write.
You'd be adding 4 plus one, so that would be a five.
You can actually do any configuration permissions using the decimal equivalent,
which just indicates the bits you're flagging.
It's a lot easier to do 7, 6, 5, 4, 3, 2, 1.
For example, if you just had
execute, that's 4, 2, and 1, that's just one set, your numerical value would be 1.
I know that's a pretty quick overview discussion, but that's how it works.
A little trial and error, it makes total sense.
Or I could do plus R plus W plus X, but
it's easier to say Chimode 755versus plus, plus, plus, plus, plus, plus, plus.
Okay, I have a nice feature.
It takes a little getting used to, but that's how it works.
Are you encrypting data at rest?
Data at rest encryption falls into a couple of different categories.
We got disk encryption, which we talked about, file level encryption, removable
media encryption, and then database encryption.
So databases, data at rest, and actually
in transit between the web application and the database server.
All right, so disk encryption.
Bitlocker, Vericrypt, Rest in Peace, TrueCrypt, Gillisop, Semantic, etc.
You're going to be doing a lab on Vericrypt.
Vericrypt allows you to set up a shared folder or folder and actually mount
that as an encrypted volume and then password protected.
Vericrypt is the successor to the mighty
true crypt, which just went away under really strange circumstances.
A few years back.
You got BitLocker, which is native to
Windows OS, FinalCrypt, FileVault, Ghislassof, etc.
All right, so if I was to steal your hard drive out of
your computer, physically steal your device, I should be able to take the drive
out, plug it into another system, and then read the data directly because access
control list would mean nothing to another machine.
And if you're using a Linux system with an
NTSP file system driver, the Penguin would care as nothing about access control list.
So disk encryption prevents that from happening since you don't have the
encryption key and everything is gobbledygook on the drive.
File level encryption.
Implementing built in file system level encryption on Windows.
Efs provides file system level encryption
on Windows and it works a little bit differently.
You actually have a file encryption file
system attribute on the file itself and then it's encrypted with a symmetric
public private key, encryption of a symmetric key.
You've got the attributes that are set on the property of the file.
You just check Encrypt contents to secure data, and then it applies to any user that
has access to that file that's on the access control list.
There's a symmetric key that's encrypted
with their public keys that can then be decrypted with their private keys.
From a command line, use the Cypher utility to implement EFS, or you right
click it in the GU and say Encrypt contents to secure data.
The Cypher command can also be used to securely delete deleted data.
I did not know that until last November when the CH version 11 came out.
I was prepping and I was like, Why are we doing the Cypher command?
That's EFS.
We're talking about covering tracks and I didn't know that you could actually use
Cypher to securely wipe files from the drive.
I've been talking about Cypher for years
and just thought it was file system command line, EFS encryption.
Turns out it can securely delete files as well.
Pretty cool.
The Removable Media Encryption.
Implementing Removable Media Encryption in Windows.
You can actually right click, go to Start Control Panel, BitLocker Drive Encryption,
Manage BitLocker, and you can actually encrypt your removal drives as well.
Pretty cool. Plug the removable media device in, go to
BitLocker, and specifically lock the drive.
Then the password is entered and of
course, you'll require the password to unlock.
That gets turned into a symmetric key.
All right, database encryption.
In database encryption, converting a plain text database into a cybertext database.
I think we know what encryption is at this point.
Using encryption techniques, the main motive is to make the data unreadable to
individuals with potentially malicious intentions.
The database is generally a relational database, which is a whole bunch of
database tables that if accessed directly would typically be in the clear.
Databases are accessed, a lot of traffic, a lot of activity on a database.
When you're encrypting the data, you have
to go through the process of decrypting it.
That can actually definitely impact
performance, so it may or may not be implemented.
But there's a couple of different types of database encryption.
The transparent or external database encryption uses the symmetric key to
encrypt the database and all backups using a database encryption key.
Again, we're always using the symmetric key for bulk encryption.
Column level encryption encrypts
individual columns within the database using different encryption keys.
Semetric database encryption, enhanced,
transparent database, remains encrypted until it's not opened and accessed.
That's actually worded in.
Hold on a second there.
Database remains encrypted until it is opened and accessed.
I think the not actually the typo there.
Let's get rid of that.
Then asymmetric and database encryption, use the public key to encrypt the data and
private key per authorized user to decrypt the data.
Now, again, almost invariably, let's talk
a little bit more about EFS for just a second.
In EFS, you've got the file itself that's encrypted...
These are padlocks, by the way, with the symmetric key.
That symmetric key will unlock the file.
That symmetric key is then encrypted,
these are padlocks again, with the user's public key.
The user's public key, remember, is made public.
The user's private key is held on by the entity.
That means once that symmetric key is
encrypted, only the user's private key can decrypt.
But when the user uses their private key to decrypt, they unlock the symmetric key.
The symmetric key unlocks the blocks in the file.
Almost always, bulk encryption is done symmetrically.
Whenever there's an encryption of bulk data, assume there's a symmetric key, and
protecting the symmetric key is quite often done asymmetrically.
We've seen several examples of that, but I forgot to draw it out one more time.
Encrypting data in transit.
Protecting data in transit is more challenging than protecting data at rest
because you've got the potential for being intercepted.
Data in transit can be secured by encrypting the data prior to sending using
secured tunnels such as AHDPS, SSL, and VPNs.
Ssh, IPS, I'll throw that in there as well.
But typically, when we're sending data across an internet or network connection,
more often than not, it's an SSL TLS type of encapsulation.
All right, secure HTTP connection using a digital certificate.
Now, I went through this in a previous module.
So remember, when you request the
certificate from an SSL server, you're requesting a copy for verification.
You want to make sure that the certificate matches the website that it's signed by a
certifying authority you've chosen to trust and that it's currently valid.
If all three of those criteria line up, the client accepts the certificate, it
encrypts a symmetric key of its choosing, sends it to the server.
Server decrips its copy of the symmetric key.
We've securely distributed the key.
We use the key for the session and we use a different key for the next session.
Remember, there's httpsPS and there's S HPTP.
We'll do those in a previous module.
We're usually using the HPTP S variety, which again is SSL or TLS.
Viewing a digital certificate.
A certificate in Chrome, you can actually
click on the padlock, view the certificate.
Firef ox browser is similar.
And again, you want to verify that the certificate is in fact valid.
If there's ever any question of that, then you'll get prompted with the certificate
error and you're supposed to investigate certificate errors.
But here's the problem with certificate errors.
Once a user has been told one time that,
Oh, don't worry about it, that's internal CA, don't worry about it.
Once they've been told one time it's okay
to accept a certificate error, they're not going to think twice about it in the
future, and they're going to accept it again and again and again.
You should always pay attention to certificate errors.
Proxies or man in the middle attacks are
situations where the attacker is impersonating using a copy of the
certificate they're hoping that the end user accepts.
One more quick overview of SSL and a man in the middle using SSL.
Here's my attacker acting as a man in the middle.
Let's say my victim is over here.
Remember, a man in the middle attack is
the attacker getting the victim to connect through them to the resource.
Imagine the victim wants an Https connection.
I'm going to right.
The attacker then forwards a request for HPPS to the server.
The server responds with its valid certificate, legitimate certificate, which
the attacker is going to use to build the tunnel with the server.
Again, the attacker comes up with the
symmetric key, sends it to the server, and that establishes the tunnel.
The attacker would then, in this situation, try to spoof that certificate.
The attacker sends the victim a spoof certificate that may not be quite right,
not signed by a certifying authority they've chosen to trust, all the fields
may look good, but generally that generates a certificate error.
So if the victim says, Okay, I'll accept it, there's a second
tunnel that's built here with the spoof certificate.
So what ends up happening is you've got a
clear text traversal as it crosses from one tunnel endpoint to
the next, and the attacker gets to inspect it as it pops from tunnel to tunnel.
That's an SSL bridging man in the middle
attack by impersonating a valid certificate.
We have some utilities that make really good looking spoof certificates.
Cain's look perfect, except they're not
signed by a certifying authority you've chosen to trust.
Ssl certificates.
Those can be actually configured in Windows Server.
You can also install a third party certificate in Windows Server.
But you're going to go through a lab for
installing and configuring an SSL certificate on a Windows Server.
You're also going to look at certificate generation using OpenSSL.
I'll leave the details of that to your lab.
Then under the database discussion.
Enabling Encrypted Connections for an instance of SQL Server database engine.
Not generally the guy to administer SQL
Server, but you want to enable TLS Encryptionto secure the data transmitted
between SQL Server and clients and applications.
We know what TLS Encryption is, so that's going to require certificates.
This computer should contain an installed certificate.
The certificate should be issued for server authentication.
Again, certificates have different purposes.
It must match the fully qualified domain name of the computer.
Using a self signed certificate for encryption only offers limited protection.
Remember self sign, you really have no
confidence in the identity of a self signed certificate.
The version of Microsoft Windows operating system running the application decides the
level of encryption to be used, whether that's 40 to 120 bit.
In Oracle, I'm going to be honest with
you, I have never sat in front of an Oracle box, at least configuration.
I've footprinted and I've attacked them, but never actually configured one.
Enabling SSL TLS Encryption to Oracle Server will be similar to Windows.
You add the client server, Oracle Server
to any client, you add a public key certificate, it's got the corresponding
private key, and there's a little bit of an example of the interface.
But again, never done it.
E mail Encryption, MS Outlook.
By default, Outlook supports the SMIME standard.
You have two basic flavors of email encryption.
The most widely used, PGP and SMIME.
Smime uses X.509. To implement SMIME Encryption, the center of the recipient
must have a mail application that supports the SMIME standard.
Outlook does, Gmail does, Yahoo does, and so forth.
Steps to encrypt a single message.
You're going to right click, check
Security Settings, select Encrypt the message contents and attachments.
Compose your message and then click Send.
But you're going to have to have your
certificates installed ahead of time to do this.
When you send an encrypted email to a
recipient, you need the recipient's public key.
You're going to need the certificate of whoever you're sending it to because
you're going to be encrypting the symmetric key with their public key.
We're going to go through one more time
just so we've got it down, what's required for Bob and Alice to communicate or sign.
Here's Bob. Bob is in red.
Bob's got a certificate, it's got his name and his associated public key.
Bob also has the corresponding private key.
Alice is in blue.
Alice has a private key.
Alice has a certificate that has her name on it and her public key.
Now, let's say that Alice wants to send an email to Bob.
What does she want to do with it?
She wants to digitally sign it.
Alice creates an email.
Alice would then append, for signature purposes, append an MD5 hash of email.
What would she need to encrypt that MD5 hash?
Her private key.
Her private key encrypts that MD5 hash.
What does Bob need to do on the receiving end to verify that signature?
Bob needs to generate his own MD5 hash of the message.
It's clear text, that's easy to do.
Bob then also needs Alice's public key to decrypt the hash Alice encrypted.
If those two match up, that file is intact.
That's digital signature.
Now, let's imagine that Alice wants to send Bob an encrypted email.
Alice will come up with a symmetric key to encrypt the email.
Imagine, let's get rid of the 75 piece.
Let's do a different envelope. All right, so Encrypted.
Alice would have to encrypt it with a symmetric key.
That's supposed to be a padlock.
The email is encrypted with the symmetric key.
She encrypts the symmetric key with Bob's public key.
When Bob receives the email, Bob uses his
private key to decrypt the public key, which decrypts the email.
If you wanted to do both, you definitely can.
You would have to have Alice's private key
to sign, Bob's public key to encrypt the symmetric key.
Bob would have to have Alice's public key to verify the signature.
In a confidential, Bob would have to have his
private key to decrypt the encrypted symmetric key of this public key.
If you are a bit frustrated with the
public private key thing, that means you're completely human.
This used to drive me nuts.
My very first 2153 class, man, I can still remember that.
Windows NT 2000 infrastructure class, this drove me absolutely insane.
Public key, private key.
One key encrypts, the other key decrips and vice versa.
Public, remember, is given out to everybody.
Private is kept private.
If you keep those rules in mind, you're in great shape.
But this old fizzle, you think you got it, then you're like, don't got it.
Then eventually the light bulb comes on and you got it.
It's one of the more confusing, difficult
concepts in cryptography, but you will get there eventually, guarantee it.
You need these keys and these certificates to perform these types of encryption.
In addition to just clicking on options,
you're going to have to have the certificate of the recipient.
Ms Outlook using digital certificates, and you're going to get a digital certificate
ID, send a digitally signed message, encrypt the message with Outlook, encrypt
all outgoing Outlook messages, which part of that, again, is the SSL TLS piece.
Remember, the email, you've got the actual
pipe, the data pipe, and you've got the actual contents itself.
We have a couple of different categories of opportunistic TLS and things like that.
But it is definitely recommended since
SMTP is Cortex that you use SSL TLS connection.
All right, Gmail.
Gmail supports SMIME Encryption along with secure Gmail and Google Chrome extension.
Steps to encrypt, enable SMIME, compose the message, click the lock icon at the
bottom right of the recipient, send the email message.
Steps to encrypt, you send encryptedpted.
And again, I'll let you walk through the steps on that on your own.
But it's pretty straightforward once
you've got those certificates installed. ight, data masking.
Data masking or data obfuscation, hiding original data with random characters.
When you see dot, dot, dot, dots over a
password, for example, that's an example of masking.
The idea is to prevent shoulder surfing, over the shoulder types of attacks,
temporary mass sensitive data transit without affecting the original data at
rest, static data masking, marks data at rest, stored in database.
Again, this can be actually applied to the data itself or through some a view.
But that random character just, it's like red action.
All right, database de identification methods.
Deidentification is the process of segregating or replacing an entity's
personal identityfrom the data stored in a database.
All right, so personally identifiable.
You don't want to be identified in
customer health care information, patient databases, things like that.
Anything that's personally identifiable is subject to legal requirements to protect.
We have lots and lots of regulations that
deal with person identifiable data and also liability if that data is disclosed.
You can use masking, which is again, replacing critical information with
characters, wild card, it's asterisks, hashes, things like that.
Bucketing, replacing unnecessary information with some uncommon values.
Tokenization, replacing sensitive data in a field with arbitrary tokens.
The tokens act as a replacement for encryption keys and then
hashing or salting is transforming data into a nonreversible format.
Remember with hashing always you can't reverse it.
You have to recreate it over and over and over again.
We talked about that password cracking.
Okay, salting is helpful.
I don't think we've mentioned salting at all yet in this course.
One of the problems with hashing is you
can create what are called rainbow tables and the rainbow tables expedite the
cracking of hashes because you've just done all your hashing ahead of time.
Salting adds a second variable to a password, for example, and that's meant to
defeat precomputed hash attacks or precomputed rainbow tables.
It's transforming data in an unreversible format.
Salting is adding random characters, so
you can't do all your homework ahead of time and crack all the hashes.
That's generally used in password storage,
but salting in general is just a second variable.
Peppering. If you ever run across that term,
peppering is a fixed value in the algorithm, whereas salting is a variable.
Data breach notifications and escalations.
It may be required that you notify your customer based on a data breach.
The first responsibility is to notify the
customers or users of their compromised data.
Now, up until California SB 1386, which is
one of the first pieces of legislation that said, hey, you've got to inform your
users if person identifiable information has been compromised.
Up to that point, companies want to sweep that stuff under the rug.
Data breaches didn't happen.
We're not telling anybody.
Nowadays, you have to notify them.
Third to notify can be a violation of security norms.
It can be a violation of the law.
These notifications should include the
type of data affected, the extent of the breach, how many data subjects are
concerned, and the steps taken to mitigate further compromise.
Even if it's possible that your
information has been compromised, you should just be notified.
Things like driver's license, social security number, things like that.
The escalation of a data breach. Initial escalation.
This is part of incident response too.
Notify teams such as the IT desk, administrators, application managers, unit
level notified teams, information security authority, organization level managers
such as executives, and your whole notification or escalation procedures,
that's all laid out in your incident response policy.
External level, notified teams like ISPs, third party contractors, etc.
Public notifications and disclosures need
to inform the affected individuals, organizations, third parties about the
data breach through social media, mainstream media.
Public notifications should be disseminated in appropriate manner,
rebuild confidence of customers, and convince them to avoid legal consequences.
You only report what you have too lately
because reputational hits and so forth are definitely a problem.
A lot of that is based on how much attention is drawn to it.
But you do follow legal requirements.
You're going to have a mouthpiece of sort, somebody that's
designated to communicate with the public, public relations entity, that thing.
Data sharing and privacy agreements, an inner connection security agreement.
It's a mutual agreement between the
organization and a third party that decides to connect their IT systems.
Again, an ISA is drafted between two
entities that are going to do business together.
Basically, we're getting together and
saying, Hey, how are we going to protect data?
How are we going to communicate?
How are we going to share information?
Data sharing and usage agreement, documented agreement between the provider
and receiver, which contains a clear understanding of what
type of data is to be shared, how the data needs to be handled.
A service level agreement is typically contractual in nature.
It states the level of service the
organization expects from a vendor, along with the metrics and detailed terms of
penalties if the service levels are not met.
Really important.
Service level agreements have financial penalties if they're not met.
Certain levels of service are expected, uptime, throughputs, and so forth.
Confidentiality and non disclosure agreements or C&DAs.
Security contract signed between two individuals or companies for maintaining
the confidentiality of information shared between them.
Rights management services.
Active Directory has several tools for management.
There are Active Directory Rights Management Services interface.
We actually have a lab that's going to bring you through some of these tools.
Security solution designed for data security through proper implementation of
access policies and a couple of third party utilities as well.
Solar Winds, Foxit, Manage engine, Netflix auditor, etc.