Attack Vectors and Mitigations
This is a guide on attack vectors and mitigations.
Mobile Devices and Malware
One of the biggest technological trends over the last number of years has been the use of smartphones in a corporate environment. And so let's talk about mobile devices and malware. First of all, mobile devices, smartphones, and tablets are widespread in their use.
Whether we're talking about iOS devices, Android-based devices, or Windows phones, to name just a few. The issue as it alludes to security is that these devices can contain sensitive information. Or if they don't actually store sensitive information, they can provide access to sensitive information, such as through a VPN app that connects to a corporate network.
And so in many cases, what's important with mobile devices in the enterprise is to use data loss prevention or DLP tools. The idea is to prevent sensitive data leakage by looking carefully at how people are working with sensitive information, and perhaps, preventing it from being forwarded through email. So because mobile devices are so widely used, it makes them a target for malicious users. We also have to bear in mind that many users of mobile devices will be in contact with outside networks with that mobile device.
Whether they connect to their home Wi-Fi network with a smartphone, whether it's work-issued or personal. Or whether they connect to a Wi-Fi network at a library, in a coffee shop, the list goes on and on. As with full-sized computers, mobile devices need to have patches applied to the operating system, as well as to any apps that are installed. And because they're so small, mobile devices are easily lost or stolen. And so in case any of those happens, we want to make sure that we've got proper screen lock mechanisms in place.
That GPS is enabled for tracking the location. And that remote wipe is enabled for administrators so they can make sure that any sensitive data that was on those devices is removed when that device is lost or stolen. In the enterprise, it's always important with mobile devices that there is a centralized way to manage and monitor them on a larger scale.
So we can have a centralized security baseline to harden mobile devices in a consistent way in accordance with organizational security policies. So let's say for example, our policies dictate that bluetooth is always disabled, that we restrict installing apps from app stores, and that the camera is turned off.
Well, that's pretty easy to do if you have a mobile device management tool centrally that applies the settings to the devices. At the same time, we should also have reports and alerts that are configured for non-compliant mobile devices because they could present a risk if they're allowed on the network.
So mobile device security, first thing we have to bear in mind is that they're really similar to any other computing device, although some users don't think of it that way. And there are some security techniques that we can implement to make them a little bit safer to use in a corporate environment. Such as a work partition, so we keep apps on the device for work separate from personal apps, settings, and data. And sandboxing, which really is the same kind of thing if we're going to be doing testing of any kind, we want to make sure it's separate from any sensitive part of the device. And the controlling of applications, as we've mentioned, to make sure they don't get installed from app stores.
They should be controlled by the enterprise. BYOD or Bring Your Own Device to work introduces mobile devices to the corporate network. And so the centralized security baseline and hardening is extra important in that type of case. The other thing to bear in mind is that because mobile devices are really just like computers, they are computers, they often don't have an antivirus or a host firewall solution installed.
Now, most people wouldn't think twice about making sure both of those things are installed and kept up to date on a desktop computer or a laptop. But again, a lot of people don't think of mobile devices as a full-fledged computing device. Some examples of exploits that can cause problems as related to mobile devices would be malware infections in apps, especially free ones.
Not always, but often free ones that are installed, even in some cases from a trusted app store. Now, if users are jailbreaking their iOS devices, or on the Android side, if they're rooting it, which essentially means what they're really doing is modifying the device without approval from their carrier.
So that they have more functionality, or they can install some apps that otherwise wouldn't install. Problem is that when you jailbreak an iOS device or root an Android device, any malware infections now could have full access to the operating system running on that mobile device.
And then there's phishing, which applies not only to mobile devices, but any type of computing device. So we might get, for example, messages that appear to be from a legitimate source. So for example, imagine that we have this kind of grammar in an email message.
We information your Apple ID was login in another device. Now, even though that might look like a legitimate message from Apple Corporation, the bad grammar is a dead giveaway. That's some kind of a scam. Or as another example, you get an email message from a friend in your contact list or a business associate that gives a link that says you might be interested in it. So we want to make sure that we watch out for these things to make sure that mobile devices are being used properly in a corporate environment, and we're not introducing additional malware because of their use.
BYOD And Business
It's becoming increasingly difficult these days to find corporations that don't support BYOD. BYOD stands for Bring Your Own Device. And it lets employees use their personal mobile devices on a corporate network. Now, that device could be a laptop that's owned by the user, a smartphone, or a tablet. So this has become increasingly popular.
What we need to determine is why it has become popular, and how it relates to security. First of all, there are many advantages of letting users bring their own mobile devices to work to use them to be productive. First of all, you could argue that it makes them more productive employees.
They're using their own device, which would allow them to work even when they're not on a work network. It can also increase employee morale, because they're given the ability to use something of their own in conjunction with work activities. And at the same time, it also would prevent employees from carrying two phones if their job requires them to have a work-issued phone. But like everything, there's another side to the coin.
Disadvantages of BYOD would include the increased complexity for implementing security policies by IT staff. So we have to be careful. Because a device might be sold, for instance, without first being properly wiped of company data. User devices can also access secured company networks as well as other insecure networks, like a Wi-Fi network in a mall or a Wi-Fi network at the employee's home.
There are privacy issues we need to consider with BYOD. So if we've got corporate monitoring software installed on mobile devices, we need to make sure it's only monitoring work activities and not the personal usage of that same device. There are some terms we should be aware of.
The first of which is personally owned, company enabled, otherwise called POCE. And this is essentially what BYOD is. Where the device is owned by the employee, but the employer manages the device and sets guidelines for how it can be used. The other option is Corporate Owned, Personally Enabled, otherwise called C-O-P-E or COPE, where the device is owned by the employer. And the employer allows the device to be used for personal use.
But the employer also manages the device and all of the data that exists on it. But we can't talk about BYOD without taking about mobile device partitioning. This is used to separate the personal and corporate use of the mobile device as well as data that might be stored on it. So for example, in the case of corporate email, we might have a separate account or even a totally separate app than the user would use for personal email on that same device.
And data loss prevention, or DLP, can monitor message content and maybe prevent data sharing with apps or users outside of the company. Now, preventing data sharing from the corporate partition to a personal partition is also an important aspect of managing a BYOD device. And a separate personal versus corporate partition also facilitates remote wipe of the corporate partition should the device be lost or stolen.
Outsourced IT
With IT, there are times when a single organization just can't do it all. Enter outsourced IT. What is outsourced IT? Essentially, it's the concept of contracting outside organizations to provide IT services that would traditionally be done by a division within the company.
Now, like most things related to IT, there are advantages and disadvantages of outsourcing various IT tasks. When we talk about outsourcing, we're really talking about hiring IT consultants outside of our organization, whether they be individuals or consultant firms. At the same time, with the explosion of cloud computing over the last few years, we could also consider that a form of outsourced IT.
Let's start by talking about some of the good things about outsourcing IT tasks to outside organizations. The first is it could result is reduced costs. Because in the case of cloud computing, instead of us acquiring all kinds of equipment and configuring it and supporting it, we could simply use services and only pay for what we use through a cloud provider environment.
It could also improve security. Depending on what we're doing and what we're outsourcing, we could have some expertise that otherwise wouldn't be available within our own organization that helps improve the security of building an application or deploying some kind of a solution. It also can allow more complex IT tasks than could otherwise be handled in-house.
We also would have more available technical resources and specialized skills that we can select from before we hire outside help. And it also can be used to ease disaster recovery. Certainly that is the case if we are outsourcing our DR to a cloud provider, maybe having alternate systems always available and running in the cloud. But like everything, there are disadvantages to outsourced IT as well.
One is the outside lack of familiarity with the corporate networks and systems. So if we're doing this for the first time with a new consultant, an individual or a firm, then they're going to need some time to get up the speed to what we're doing on our network or with our applications as related to why we're hiring them.
They need to be somewhat familiar with it. Then there's regulatory compliance. We're placing a lot of trust in outsourced IT, that they are keeping up their end of the bargain when it comes to proper governing of security standards. So outside consultants are cloud providers. We need to make sure that they are in compliance with regulations that we need to be for the current project that we're hiring them for.
Otherwise, fines could be levied for compliance failure. And that's the last thing we want, is to be hit with a fine that really isn't directly our fault, but rather it's the outsourced IT that was the problem. But it's part of our responsibility to make sure we check into it. The other disadvantage is that we're actually introducing outside sources to internal IT systems. So we also want to make sure that individuals that will have access to whatever it is we need them to do that we're outsourcing them for.
We need to make sure that they are trustworthy and that there are thorough background checks. There's always an extra risk introduced when additional people that don't work directly for the organization have access to our systems. The other thing we have to consider, especially in the case of cloud computing, is the SLA, the service level agreement.
The cloud provider service level agreement might not meet our business requirements. And so that might prevent us from outsourcing IT, or it might diminish our capacity to use the services offered by some other third-party like a public cloud provider. Some common examples of outsourced cloud security services would include things like disaster recovery as a service, otherwise called DRaaS. Now, this could be used so we have alternate IT system site running in the cloud for failover.
At the same time, cloud backup and archiving is also helpful because if we lose our data on-premises, we've got a copy of it stored elsewhere offsite. Another example of a cloud security service that we might outsource is security as a service, otherwise called SECaaS. So we might want something as simple as a Layer 4 packet filtering firewall running in the cloud. And we would forward and route our traffic there, whether from on-premises or from what we're doing in the cloud, to make sure it gets examined properly.
Another common use of this these days is as a web application firewall. A web application firewall is different from a packet filtering firewall because it is designed specifically to look at HTTP web conversations to determine if there's some kind of specific web app attack that might be taking place. It's designed to do just that. So rather than host that on-premises, a common trend is for that to run out in the cloud through security as a service.
The same goes with things like malware scanning and denial of service mitigation handled by cloud providers as opposed to us having to invest heavily to make those things possible and happen internally. Or we might have a hybrid of both where, for instance, malware scanning we handle on our own devices. But we also have any traffic that we generate in the cloud go through a malware scanner in the cloud before it can go elsewhere, such as to other customer systems.
Smart Appliances and IoT devices
It's not often that somebody will ask you if you trust your refrigerator. But, believe it or not, there's actually some merit to that kind of statement. Let's talk about smart appliances. Smart appliances are appliances that have some kind of implemented computing device for additional functionality. And it can be any type of appliance.
It could be a refrigerator. It could be a toaster. It could be a washer. It could be a dishwasher. You get the idea. Now technically, an IoT device is an Internet of things device that has a network connection for something that normally wouldn't be, whether it's a fridge, or a toaster, or whether it's our home environmental control, baby monitors, smart vehicles, medical devices. Now why on Earth will we want these things connected to the Internet?
Well, there are plenty of advantages to this. First of all, its increased functionality. For instance, at the industrial level, we might be able to take stock of items that are missing from a large refrigerator so we know what to order. Or at the personal level, we could turn on or off home appliances remotely. And there's increased convenience with the fact that all of these smart and IoT devices would have up-to-date information.
For example, imagine a smart power meter that tracks your power consumption, whether at the personal or the industrial levels. Well you can connect to it from anywhere at any time, normally from an app that you install on a smart phone, and get up-to-date power consumption usage. And that's just one example. But there are problems with smart appliances and IoT devices on a very large scale.
One of those problems is platform fragmentation. What this means is that different types of devices run different software and hardware. And sometimes they don't talk together properly, so it can prevent interoperability or the simplified sharing of information. However, the other problem is that it can be difficult to control these smart appliances and IoT devices.
In some cases, they have little to no customizability, so they're shipped from the manufacturer, maybe as is and that's it. You can't configure it in any way. You can't change passwords. You can't patch it and so on. Now, when we deal with smart appliances and IoT devices, we have to consider the fact that its multiple platforms that we're going to have to support.
And if they do support it, patch them. So your smart fridge might run a variation of a Linux watered down operating system. Whereby your power meter might run a watered down version of the Windows operating system. So you've got all these different types of platforms and different versions that now you're going to have to support, either on a home network or in some cases in an enterprise environment.
One of the biggest problems with IoT devices is the inability to change default configurations like passwords and port numbers and so on. As a result of the explosion in popularity with these types of devices, over time there have been botnets that have been created by malicious users.
A botnet is essentially a network of robots under command of the malicious user. When we say robots, all we really mean are compromised devices, in this case, IoT devices. It's becoming a problem. Now, you might ask what a malicious user is going to do if they've got 2,000 smart fridges under their command. Well, it could be a bigger problem than you might think. They would be able to remotely, perhaps, control them, maybe turn fridges off.
Which could be a problem in the case of, let's say, the medical industry that might need to keep some things frozen. At the same time, it also could cause a distributed denial of service attack. In other words, a network flood attack against some victim on the Internet. So we have to be very careful and do our homework when it comes to our selection of smart appliances and IoT devices to ensure that they do allow the changing of default configurations and they can be patched.
Wearables and Vulnerabilities
Wearable computing items have become all the rage in recent years. Let's talk about wearables and their related vulnerabilities. So what do we mean when we say wearables?
We're really talking about electronic devices that are actually worn by the user, hence the word wearables. These could be considered Internet of Things, or IoT devices because they communicate on a network. Now often wearables are used to collect data and provide some kind of a service based on that collected data. So what are some examples of wearables? One would be physical activity trackers for those that are into fitness.
Or there are also head-mounted displays with cameras for convenience and for recording visual activities. There are devices to treat health issues. There are smartwatches that people can wear that are much more than just a time piece. There are wireless earbuds, IoT eyeglasses, the list goes on and on. So essentially they're tiny computers that serve some kind of convenient functionality that can communicate on a network.
And that's where we have to think about these security issues. Now the advantages are great. Wearables are small and lightweight, they're designed to be easy to bring with us. They can collect data that would otherwise be difficult to obtain. Imagine having to manually track how much you have run if you're a jogger versus using something as simple as an IoT pedometer type of device.
They can also provide convenient functionality like making a phone call from a smart watch, tracking exercise patterns over time, administering the proper drug dosage. Now the disadvantages would be, first of all, that there would be limited battery life. So one of the problems with wearables is that the battery technology requires us to make sure that they're always at charge.
There can also be privacy issues because the device itself might always be collecting and sending private information. Because these are very small devices, they probably don't have a lot of computing power. So anything that requires massive computations for the data collected by the wearable would have to be sent out to some centralized server over the Internet before we might get results sent back.
And you'll find, if you look carefully into a lot of these wearables, whether you read about them, use them a lot, or whether you actually perform packet captures. Is that you'll notice that often they do talk to the cloud or they might require a cloud account when you set them up for the storage of some of this data. So there are other security issues such as a lack of standardization.
Because wearables are still really in their infancy, there are not a lot of standards on how to make them robust, and at the same time, secure for the average consumer that isn't a computer expert. And like most IoT devices, another problem is you can't change a lot of the configurations and they can't be patched.
So if a vulnerability is discovered in a wearable device, as long as you're using that wearable device and it's connected to a network, you might be exposed to potential exploits. But it's not all doom and gloom. We can do some things about this. One of which is to enhance security by requiring strong passwords on these devices, as inconvenient as it may be. If the device supports it, encrypting any saved content is crucial.
Often wearables will actually save the bulk of their data in a cloud account. Well, in the same way, make sure that that data is encrypted. We also want to make sure that we at least limit or restrict Bluetooth and Wi-Fi connectivity for these devices. Otherwise, simply going into a coffee shop with a smart watch might make you vulnerable. In the sense that a malicious user in that same coffee shop might quickly discover that you've got a vulnerable device that can't be patched and take advantage of it. Maybe even adding it to a botnet for the purpose of a future distributed denial-of-service attack.
TLS
I'll talk about TLS. TLS stands for Transport Layer Security. It's the successor to the older Secure Sockets Layer, or SSL. But the purpose of SSL and the newer TLS is to secure network communications. Although SSL really shouldn't be used because of vulnerabilities known that could be taken advantage of. So when we talk about SSL or the newer TLS, it secures network communications but not just for web servers over HTTP.
Or if it's secured, it's actually using HTTPS. So we could use TLS to secure communications to SMTP mail servers, or to LDAP directory servers that might be used for user authentication. Either way, if you're going to be using TLS, you need a PKI security certificate.
Now, PKI stands for Public Key Infrastructure and this certificate will certainly be required on the server. Think of online banking where you have a security connection, well, the server needs a PKI certificate. But your client device, your browser does not. However, in some cases for highly secured websites, it might be a requirement that not only the server has a PKI certificate. But any connecting clients each have their own unique device certificates.
Public Key Infrastructure, or PKI, is essentially a hierarchy of digital security certificates that are also sometimes called X509 Certificates. These certificates are used for security. They get issued by what's called a certificate authority, a CA, that must be trusted. Now, you could set up your own certificate authority within your company, and issue your own certificates.
You just need to make sure that all of your apps, like web browsers trust your personally created certificate authority. Of course there are third party trusted certificate authorities available out on the Internet, such as Symantec. So the certificates get issued to users, or devices, or even applications. And the certificate contains a unique public and private key pair.
They're different, yet they're mathematically related. Now when we have two different keys in this way, it's called asymmetric keys. We've got a diagram where pictured at the top in the PKI hierarchy, we start with the certificate authority, or CA. Larger enterprises might then at the next level, issue certificates for subordinate certificate authorities, or subordinate CAs.
Each subordinate CA in turn would be responsible for issuing and managing things like user PKI certificates, device or application PKI certificates. Now, when we talk about the contents of a PKI certificate, remember that we talked about the public and private key pair. Well, besides the keys, there are also digital signatures, specifically that of the certificate authority.
Then there's the subject identity that is also stored within a certificate. In the case of a user, that would be something like a user email address. If we've got a PKI certificate to secure a website, then the website URL or IP address would be within the certificate. Although you can get wild card certificates, for example, which might include just part of the DNS name of an organization.
So it could be used by multiple servers. [PKI and wildcard certificates have expiration dates.] So for example, you might get a certificate issued from a CA, where by your certificate is stamped, so it's only good for two years. So it needs to be renewed within the two years, otherwise it's not usable. We know that the public and private key pair also exist within the PKI certificate. And they're used for things like digital signatures and encryption.
Also, how the keys can be used, such as whether or not they can be used for signatures, for example, is determined within the PKI certificate. And also, we've got the location of the certificate revocation list, or CRL. The CRL is the list of serial numbers for expired certificates that apps can check so that they aren't trusted any longer.
The Heartbleed OpenSSL exploit was a great example of how SSL can be exploited. Specifically, OpenSSL was exploited with the Heartbleed bug by essentially returning more memory contents than was originally intended. And that, really, is in response to especially crafted requests from malicious users. So at the top of the diagram, we have the benign use of OpenSSL where a client application might say, please respond with five characters and there's the word apple. [An illustration displays, which contains two objects, a user and a server.
The user requests information from the server. The presenter indicates the word "Apple" that displays between the two objects.] And the server has all of these different items in its memory, but it only returns what was asked for. So the five characters here are apple. But the malicious use of OpenSSL requires a malicious user to send specially crafted requests that would say, for example, please respond with five characters, apple.
But the request actually asks for more than just that information and memory. So the server returns not only what was asked for, but additional information. And this is where a malicious user would be able to take advantage of servers using OpenSSL. Luckily, these days, there are patches for OpenSSL to prevent the Heartbleed exploit from functioning.
So with TLS, we should be using it. Its older counterpart, SSL should be disabled in both web server engines and web browsers. And another growing trend is the requirement to use TLS due to the known vulnerabilities with SSL. As a matter of fact, TLS is going to be required for PCI DSS compliance by June 30th, 2018. PCI DSS compliance is required if you're an organization that deals with card holder data, like debit cards and credit cards.
One last aspect about PKI certificates is that they aren't specific to SSL or TLS. So you can get a PKI certificate, let's say for a web server. And it doesn't matter if you're using SSL or TLS on that web server, although we know we should only be using TLS. So SSL and TLS really determine how certificates are going to be used during communication.
Use BitLocker to Protect Data at Rest
I'll demonstrate how to use Windows BitLocker to protect data at rest. The first thing I'll do here in Windows 10 [The device desktop displays. It contains a Recycle Bin icon. ] is I'll go to my Start menu and I'll type in bitlocker. [The presenter types "Bitlocker" into the Start menu search field.
The search suggestions include a Best match section, which contains a Manage BitLocker option. ] From here, I've got an option to Manage BitLocker. So when I go ahead and click on that, [The Control Panel window opens on the BitLocker Drive Encryption page. It contains three sections: Operating system drive, Fixed data drives, and Removable data drives - BitLocker To Go. ] I'll see that I've got an option for my fixed Operating system drive, so drive C.
We can see BitLocker is currently turned off, but I could turn it on. [He indicates the following entry in the Operating system drive section: C: BitLocker off. It includes a Turn on BitLocker link. ] And down here under Removable data drives, we've got the BitLocker To Go option.
So this is a USB stick that I've plugged in. And notice that it's labeled as drive letter D and BitLocker is off. [He discusses the following entry that displays in the Removable data drives - BitLocker To Go section: ZOOM (D:) BitLocker off. ] So what I'd like to do is make sure that I encrypt any data stored on this particular USB stick using Windows BitLocker. So I'm going to go ahead and click on that. [He expands the ZOOM (D:) BitLocker off entry. ]
That opens up, down below, an icon for that drive, and then we've got an option or a link that says Turn on BitLocker. I'm going to go ahead and click on that. [He clicks Turn on BitLocker. The BitLocker Drive Encryption (D:) wizard opens on the Starting BitLocker page. It displays that BitLocker is initializing the drive. ] So currently, it's initializing the drive to make sure that it's ready to accommodate BitLocker.
Now because the contents of the USB stick will be encrypted, we then have to decide how it will be decrypted. [When the initialization completes, the Choose how you want to unlock this drive page opens. It contains two checkboxes: Use a password to unlock the drive, and Use my smart card to unlock the drive. ]
We can specify a password to unlock the drive or a smart card, if we're using multi-factor authentication. In this case, I'm going to use a password. So I'll go ahead and enter and reenter the password and then I'll click Next. [He selects the Use a password to unlock the drive checkbox and two associated text input fields become activated: Enter your password and Reenter your password. He enters a password in both fields and clicks Next. ]
Next, we've got a plan B, in case we forget the password that's used to unlock the BitLocker encrypted drive or if we lose our smart cards, if we use smart card authentication. [The next step presents three options for backing up the recovery key: Save to your Microsoft account, Save to a file, or Print the recovery key. ] So I can save my backup recovery key to my Microsoft account online or to a file, or I can print it. In this case, I'm going to choose Save to a file. [File Explorer opens with Downloads selected in the navigation pane. It includes File name and Save as type text boxes.]
We can see the file name says BitLocker Recovery Key, and then we've got a unique identifier followed by a .TXT file extension. [He discusses the entry in the File name text box. ] So I'm going to go ahead and save this in my Downloads folder on my machine. [He clicks the Save button and File Explorer closes. ] And then the Next button becomes available in the wizard. So I'll click Next. [The Choose how much of your drive to encrypt page displays. It contains two radio buttons: Encrypt used disk space only (faster and best for new PCs and drives), and Encrypt entire drive (slower but best for PCs and drives already in use). ]
Now what I want to do is encrypt the used disk space only, as opposed to encrypting the entire drive ahead of time. [The Encrypt used disk space only (faster and best for new PCs and drives) radio button is selected. ] So that's what I'm going to do. And I'll go ahead and click Next. [The Choose which encryption mode to use page displays. It contains two radio buttons: New encryption mode (best for fixed drives on this device), and Compatible mode (best for drives that can be moved from this device). Compatible mode (best for drives that can be moved from this device) is selected.]
Then I have to determine if I want to use some of the new security enhancements for Windows 10. Which means that older versions of Windows won't be able to unlock this BitLocker enabled drive. So depending on whether I want to move this USB stick to other versions of Windows or just on this machine will determine the choice I make here.
I'm going to choose New encryption mode (best for fixed drives on this device), and then I'll click Next. [The final confirmation page displays. ] And it asks me, am I ready to encrypt the drive? So I'm going to click the Start encrypting button. [The wizard closes and a Bitlocker Drive Encryption message box opens, notifying the user that the encryption is complete. ] And before too long, we'll have a message that says the encryption is complete, I'll close that. [He returns to the BitLocker Drive Encryption page in the Control Panel window.]
We can now see that our USB stick has BitLocker To Go enabled. [He indicates the Removable data drives - BitLocker To Go section, in which the entry is updated to: ZOOM (D:) Bitlocker on. The section includes an icon for the drive and several links. ] We have other links where we can Back up our recovery key, Change the password, Remove it, Add smart card, Turn on auto-unlock. Or even Turn off BitLocker if we change our mind down the road. [He discusses the links in the section. ]
So I'm going to go ahead and unplug that USB drive. [The entry and links no longer display in the Removable data drives - BitLocker To Go section. ] Now when I do that it disappears from the list on the screen, so I'm going to ahead and plug it back in. [One entry, D: BitLocker on (Locked), displays in the Removable data drives - BitLocker To Go section and includes an Unlock drive link.
A Location is not available notification displays, with the following message: Access is denied. ] Now notice when I do that, it's locked and it says that Access is denied because it's BitLocker protected. [He clicks OK and the notification closes.]
So having done that, I'm going to click the Unlock drive link where I'll specify the password. [A BitLocker (D:) authentication box opens. It includes an Enter password to unlock this drive text box. ] And if I've entered it correctly, I'll be able to unlock the contents of that encrypted drive, as we can see here. [He enters a password and clicks the Unlock button. The ZOOM (D:) BitLocker on entry, associated icon, and links display in the Removable data drives - BitLocker To Go section. ]
So at this point, we have the option of going into the file system on that USB stick as normal. [He clicks the icon and File Explorer opens with the ZOOM (D:) folder selected in the navigation pane. No entries are listed in the central pane. ] And we can see it opened up here automatically in Windows Explorer. Notice here that we don't have anything on that drive currently.
Data at Rest
I'll discuss data at rest. Data at rest refers to data in storage, whether that's being stored on-premises, on our own disk subsystems, or in the cloud. Storage details about how that data is stored and how it's retained can be dictated, in some cases, in some industries, by regulations.
Some examples of this would be such as the data must be stored on-premises, and not in the cloud. Or if it is going to be stored in the cloud, the data needs to be stored within national boundaries, which would mean having knowledge of the specific data center region where that data's physically stored.
Regulations might stipulate that backups must be encrypted for additional security, that backups are stored offsite. And again, the cloud is a form of that. And also, data retention policies, whereby we might have to keep certain types of records for a number of years stored in a certain manner. But there are definitely negative impacts if sensitive data is leaked.
And we've seen this in the media over the last couple of years. When private data gets compromised, it means that some or all of that data might be very sensitive. And as a result, we could expect a loss of shareholder or customer confidence in the organization.
And not to mention that it can also open the company to legal liability. Now, this sensitive data is sometimes called personally identifiable information, or simply PII, P-I-I. And it includes things like mother's maiden name or a Social Security number.
A person's financial history, their medical history, their email address. Now, protected health information, like it implies, deals specifically with medical information related to an individual, including things like medical insurance coverage and usage over the years.
And this is often simply called PHI. What can we do then about sensitive data that's stored, so data at rest, whether on-premises or in the cloud? Well, one common trend is cyber insurance for larger organizations that might store a large amount of sensitive information for customers, or in the case of the medical field, patients.
Cyber insurance might be acquired with a specific policy clause that states what would happen if sensitive data is leaked and the organization is then subject to lawsuits. Then we have to think about the data in transit. Not only should we think about protecting the data at rest, such as encrypting it.
But what about making sure that while it's being transmitted, we use something like TLS, or IPsec, or a VPN to make sure it's also transmitted securely? Now, data at rest can be encrypted using many different solutions, including the built-in Windows BitLocker tool, or in Linux, we might us dm-crypt.
Different cloud providers also have their own special way of encrypting data stored in the cloud. So we might take advantage of that. And also, certainly on-premises, we might have a SAN storage disk array, which also would include its own type of vendor encryption to protect the data at rest.
Securing Data in the Cloud
The popularity of cloud computing for individuals and enterprises has grown over the years. And as a result what's gone along with that is how to properly secure data that's stored and processed in the cloud. In the cloud you might be dealing with sensitive data, and it would apply to many different types of organizations.
Things like business plans, trade secrets, financial records, customer or patient personally identifiable information. We then have to wonder, are public cloud providers hacking targets? Because if you think about it, they have thousands of customers, in other words called cloud tenants.
That are sharing these pooled IT resources that are owned by the cloud provider. So for a malicious user, if they can somehow infiltrate the cloud provider network, it could give them potential access to the tenants. But luckily, due to the economies of scale, because cloud customers have a lot of customers, that means they have the money to focus on strong security.
And many public cloud providers actually must get third party audit compliance accreditation for things like PCI DSS. Otherwise they would lose a large customer base. There's also availability, whereby data can be replicated within and between data centers, or even geographical regions for business continuity.
So if there's some kind of a regional disaster, your data might have been replicated to another region, so it's still accessible. Securing data in the cloud also includes encryption of data in motion over the network, as well as data at rest. We can manually choose our own encryption tools and then upload data into the cloud.
Or the encryption solution could be made available from the cloud provider. We also have think about cloud provider data sanitizing practices. In other words, what happens when we delete data that was stored in the cloud? Is it actually truly deleted so that other cloud tenants can't recover it in the future?
And this might be required depending on the type of business we're in. And depending on the regulations that we must comply with. Then there's the concept of protected or shielding virtual machines. [Windows and Linux display as examples of virtual machines. ] This essentially means that virtual machines in a data center can be started or stopped by data center personnel, that's it. They can't get into the data within that virtual machine.
Then there are virtual networks that we can define in the cloud, just like you could set up multiple network segments in an on-premises network environment. It's important that we think about how we're going to segment our virtual networks. For example, if we're going to have sensitive database servers. Then they should be on their own network segment that's firewalled appropriately from other network segments.
Or if we're going to be using IoT devices at all, they should definitely be on their own network segments. So that if they're compromised, at least there aren't other sensitive machines on that same network segment. Virtual networks also allow for the defining of firewall rules for in and outbound traffic. And in the cloud, as well as on-premises, we should always follow the rule of denying all traffic by default.
And then adding specific exceptions for the traffic that absolutely must be allowed in or out. When it comes to virtual machines, these can be created from cloud provider template galleries. So that it includes, perhaps, not only the operating system, but the most up to date patches, certain configurations for the OS.
And even apps that are installed and configured. Things like databases, so that it makes it very easy to provision these resources quickly from these templates. Of course, we can also create virtual machines manually in the cloud. Or we can migrate our on-premises existing virtual machines to the cloud so we can reuse them.
So whether we are dealing with virtual machines in the cloud or not, it doesn't matter. We need to follow standard operating system hardening procedures. There's nothing different about hardening a virtual machine. And whether it's in the cloud or on-premises, administrators will often manage cloud resources through an HTTPS web GUI interface.
Although command line interfaces are often available by various cloud providers as well for automation purposes. We should enable auditing, so we can track which administrators perform which actions against cloud resources. And that can be controlled at a granular level with role-based administration. For example, if I've got an assistant admin, Tom, that needs to be able to start and stop virtual machines in the western region.
I could build a role for that where all of those permissions are available for VMs in the western region. And add Tom as an occupant of the role, and therefore he would get only those permissions. At the same time, it adheres to the principle of least privilege. Then we can run applications in the cloud, whether it's a native web app in the cloud.
Or whether it gathers data from a mobile app running on mobile devices. But we're really talking here about processing data in the cloud. And then dealing with the data output, which often needs to be encrypted. Data also needs to be encrypted whilst in transit over the network, and often that would be done using HTTPS. Bear in mind that protection of our data at rest also includes protection of backups, which also might need to be encrypted.
And we want it highly available, so it really should be replicated across regions where the cloud provider has data centers. There are some negative business impacts if our data isn't properly secured in a cloud computing environment. Number one, we may be legally liable if proper security controls are proven to not have been implemented.
There could be damage to the company's reputation. Of course there's going to be disruption to business processes. And depending on the type of business you're in, it could mean a longer time to market for whatever product or service you're using compute power for in the cloud. And it also can result in loss of competitive advantage. For example, if sensitive trade secrets unique to your organization are stolen and leaked to the wrong hands.
Encrypting Cloud Data
I'll demonstrate how do we encrypt data stored in the cloud. The first way that we'll look at this is having local data like I have pictured on the screen here. An instance of File Explorer is open and the contents of the Sample_Data_Files folder displays. Five files are listed. [An instance of File Explorer is open and the contents of the Sample_Data_Files folder displays. Five files are listed. ]
I've got a few files that are currently not encrypted. I'm going to encrypt them using a tool outside of a cloud provider, and then I'll simply upload them into the cloud. So they will be protected that way. So I'm going to select my files here, and I'm going to right-click. And I'm going to use a tool that I've installed called AxCrypt, [The presenter selects all five files and right-clicks.
The shortcut menu opens and he hovers the cursor over the AxCrypt option to open its fly-out menu. Options such as Encrypt, Encrypt a copy, and Encrypt copy to .EXE display. ] where I'm going to choose Encrypt. [The AxCrypt 1.7.3156.0 dialog box opens. It includes text fields for entering a passphrase and verifying the passphrase. ] It asks me for a passphrase, so I'm going to go ahead and put it in.
And then I need to verify or confirm it, because I'm going to need that passphrase to decrypt these files. I'll go ahead and click on OK, and after a moment, we'll see that all of these files are now encrypted. [He enters a passphrase, verifies the passphrase, and then clicks OK to close the dialog box. He indicates the files listed in File Explorer, which now display with associated shield icons. ]
Now we can see that it's got the little icon for the encryption tool that I chose in this case. Now, the next thing I do is simply upload these things to a cloud storage location. So whether we're using Google Drive or whether we're using Dropbox or Box.com, or in this case, Microsoft One Drive, it doesn't make a difference. It's all the same when it comes to cloud storage. So I'm simply going to select these encrypted files, [He selects all five files. ] and I'm going to cut them, and I'm going to paste them into OneDrive. [He selects OneDrive in the navigation pane. ]
So after a moment, we can see that I've got my encrypted files in OneDrive. [He pastes the files in the central pane. ] So not only is it cloud stored, but it's also been encrypted. But there is another aspect to cloud encryption, and that is where the cloud provider gives you the option to encrypt. Let's take a look at that with Amazon Web Services in this example. [He switches to an instance of AWS, which is open in a web browser.
The ribbon includes options for Services and Resource Groups, and the AWS services page displays. It includes sections such as Recently visited services and All services. ] I've already logged into my AWS account, so I'm placed here on the AWS Management Console page. I'm going to go down under the Storage section and click on S3. [The Storage category displays in the All services section, and includes options such as S3 and EFS. He clicks S3. ]
S3 allows us to create storage locations or buckets, as they're called, to store data in the cloud. [The Amazon S3 page opens. It includes a table with three columns: Bucket name, Region, and Date created. There are two entries. ] I've already got a bucket I've created called bucket172. And if I click to open that bucket, [He clicks the bucket172 entry in the Bucket name column. The bucket172 page opens, and it contains four tabs: Overview, Properties, Permissions, and Management. The Overview tab is selected and a table displays with four columns, Name, Last modified, Size, and Storage class. It contains one entry for Internal. ]
Just like I would look at the contents of a disk drive, I can see I've got a folder called Internal. And within it, we've got nothing. [He clicks Internal and the associated page opens on the Overview tab. It contains buttons such as Upload and Create folder. No objects are listed. ] I've got an Upload button, so I'm going to go ahead and click on it. [The Upload wizard opens. It contains four steps: Select files, Set permissions, Set properties, and Review.
The first step, Select files, displays. It contains an Add files button and an area to drag and drop files. ] And I can either drag and drop files here or click Add Files. [He clicks Add files and five files are listed. There is also an Add more files button. ] So I have selected some files that are currently not encrypted from my local on-premises station, and I've dragged them here as specified in this wizard, so I can upload them to the cloud, okay.
So the next thing I'm going to do is click Next. [The second step, Set permissions, displays. It includes the sections: Manage users, Access for other AWS account, and Manage public permissions. ] I can set the permissions for these objects in the cloud, but I'm going to leave them as they are by default. [He indicates the Manage users section, in which Read and Write object permissions have been set for the user. ]
I'll click Next again. [Step 3, Set properties, displays. It includes sections such as Storage class, Encryption, and Metadata. ] Then I get to determine whether or not I want to encrypt it, to protect the data at rest. [He discusses the Encryption section, which contains three radio buttons: None, Amazon S3 master-key, and AWS KMS master-key. The None radio button is selected. ]
So in this case, I'm going to use the option called Amazon S3 master key, and then I'll click Next, [The final step, Review, displays and it contains section for Files, Permissions, and Properties. ] and I'll click Upload. [He clicks Upload to close the wizard, and returns to the Overview tab on the Internal page in AWS. ] So after a moment, my files from my local on-premises device that were unencrypted are now stored up here in the cloud. [A table with four columns displays with the following headers: Name, Last modified, Size, and Storage class. Three entries are loaded.]
And if I were to select one of them, let's say CustomerTransactions. [He clicks the CustomerTransactions.xlsx entry in the table and the file opens. There are three tabs: Overview, Properties, and Permissions. Overview is selected and details such as Owner, Last modified, and Storage class display. ] And if I were to click on Properties, [Four properties are listed: Storage class, Encryption, Metadata, and Tags. ] we can see whether or not encryption is enabled. Currently, AES 256 bit encryption has been enabled. [He indicates the Encryption property, which displays the encryption: AES-256. ]
So whether you're using tools like AxCrypt, and there are many other ones, to encrypt data on-premises before we put it in the cloud, or encrypting using the cloud provider solution, in the end, we are protecting the data as it's being stored.
Data Loss Prevention
Data loss prevention solutions have been around for a while. But what's changed now is how they can be applied to cloud computing and mobile device usage in the enterprise. Data loss prevention is normally just called DLP. And its purpose is to control how valuable data is used.
Data such as intellectual property, confidential corporate data, or personally identifiable information related to things like customers. Their financial history, their mother's maiden name, credit card numbers, that type of thing. So the idea is to prevent data leakage, to prevent data disclosure outside of the organization.
Or in some cases, even within certain departments within the organization. DLP risks include malware that could leak sensitive information. For example, a user might be tricked into clicking a link in an email message that looks legitimate. Which, in turn, can steal some data and make it available to unauthorized parties. Users that use social media, like Facebook, or Twitter, Instagram, could either intentionally, or unintentionally make some data available.
Either photos or file attachments that really shouldn't be shared in that way. The use of laptops, tablets, and smartphones also presents a risk because they're designed to be portable. People take it them with them whether they're working at home, traveling on an airplane, at the coffee shop enjoying a nice coffee. Either way, they could be connecting to a multitude of different networks.
And because they're small, these devices can easily be stolen or in some cases, lost. So that can also be another source of data leakage in some cases. And a big one that we've heard over and over in the media over the years, is removable media such as USB flash drives. Their use should be severely restricted. Maybe for instance, only company-issued USB flash drives are allowed to be used and if they are used, they must be encrypted.
The risk origin, when it comes to these risks, usually goes back to people. User training and awareness is absolutely fundamental. Especially to prevent social engineering scams that can trick users into clicking things or providing sensitive information. DLP is designed to protect data in use. This is data being processed, for example, by a database or by a big data analytics engine in the cloud. It's also designed to protect data in transit.
Data being sent or received over a network either by encrypting or preventing certain types of data from being sent, for instance, to certain email addresses outside of the organization. DLP also protects data at rest. This is data that is being stored, for example, by encrypting or limiting who has access to it. Network encryption is often implemented using things like VPNs.
Where we have clients or individuals working from remote locations connecting over the Internet to a corporate network. And if it's through a VPN connection, that data as it traverses the Internet is protected because it's encrypted within the VPN tunnel. Or we might use IPSEC not just with a VPN, but perhaps separately to encrypt all network traffic, especially on an internal or a cloud-based network. TLS or Transport Layer Security supersedes the old SSL standard, which is often used to protect communications to and from HTTP web servers.
So that's certainly one way to prevent data from being leaked, preventing it from being exposed in plain text over a network. Stored data encryption can come in many forms, including using things like Windows Encrypting File System or EFS. The EFS lets us encrypt individual files or folders and it's tied to a user account. Where Windows BitLocker encrypts entire file systems, not just individual items within them. And it's tied to the machine, as opposed to the user.
If we're using Linux, we might look to use something like DM-Crypt to protect data at rest. And public cloud providers always have options to encrypt data stored in the cloud. Perhaps they would offer the ability to encrypt using AES 256-bit encryption. To implement your DLP solution, the first step is to identify the data that needs to be protected.
This might be trade secrets, or customer financial records, that kind of thing. Next we identify the threats to that data that we have deemed is valuable to the organization. After we've done those two things, we can apply DLP techniques. And often, this is policy-driven, we have policies that determine how data is treated. And how it's prevented from being disclosed outside of the organization. And like all security solutions, it needs to be monitored continuously over time to ensure that it's still effective.
Because we all know that in the IT security realm, threats evolve constantly. So for example, we might even use built in solutions, built into things like the Windows operating system. We might use Microsoft Group Policy settings to control removable media. Maybe to completely restrict it from being used, or to ensure that the only way it can be used is if the USB media is encrypted with BitLocker. When it comes to mobile device computing in the enterprise, there are some challenges with BYOD or Bring Your Own Device.
Where people use their personal laptops, tablets, or smartphones to conduct business. We need a centralized Mobile Device Management, otherwise called an MDM, where all of these mobile devices are registered with this central admin tool. And then we have centralized and standard control, such as perhaps configuring apps such that a VPN connection would be triggered when a specific app is opened on the mobile device.
We might enforce strong device authentication requirements, device encryption. We could enable remote wipe through an MDM policy. We can control which apps can be installed, if any, by the user. We can disable things like Bluetooth and the mobile device camera.
The list goes on and on, but having a centralized way to do it means we can consistently apply organizational security policies to prevent data loss on mobile devices. Mobile devices are often partitioned or containerized. Which means we've got a corporate partition, which contains company-related apps, settings and data. And of course, if it's BYOD, then the user also would have their personal apps, settings and data.
So having a corporate partition, then, allows us to selectively wipe that if the device is lost or stolen, while leaving the personal information intact. DLP solutions, whether it's on a mobile devices or not, can prevent sensitive data from being forwarded through email.
Or from being sent in the first place, perhaps email addresses outside of our organization. We can prevent data from being printed, copied, or pasted, or even stored in an alternate location. And that would also include, perhaps, preventing sensitive data in one smartphone app from being copied into a different app in the personal partition.
Multi-factor Authentication
Usernames and passwords have been used for decades to authenticate to computer systems. These days, multi-factor authentication makes that much more secure. Multi-factor authentication is simply called MFA.
It's the process of using multiple pieces of evidence, otherwise called factors, to authenticate users, applications, or devices. So normally, multi-factor authentication will use, at minimum, two of the following categories. Something you are, so that's biometric authentication, it would include facial recognition, fingerprint scanning.
Something you have is another category. That would be something in your possession, like a smart card. And then there's something you know, which would be a PIN or a password. So two or more of these is called multi-factor authentication. And that's why username and password is not MFA, because both of those fall under something you know. MFA examples would include using a bank card and a PIN for that card, or a password and a changing numeric code from a separate device.
Which maybe would be received via SMS text message on your smartphone, or even via an app on your phone, which is often called a virtual MFA key fob. We could have a password and a one-time token which never gets used again, so it truly is a randomized value. We might use a fingerprint or a smart card and a password. All of these combinations represent multi-factor authentication.
There are many advantages to using this type of authentication. The first of which is that it increases security, because a password wouldn't be enough, in this example, if we're using MFA, for a thief to access a victim's bank account, if that's what they're after. And it can be very difficult to crack remotely, especially if we're talking about physically possessing something like a smart card. Now, while it does increase security, it doesn't mean it's impenetrable.
So in some cases, we might be able to find that malicious users can partially or fully circumvent MFA through phishing attacks, where they trick victims into giving them necessary authentication information. Or man-in-the-middle attacks, where the attacker might be able to intercept authentication information.
But again, depending on the specific attack or the specific MFA method being used, the attackers still might physically need to have something in their possession, such as a card. But there have been known hacking attacks where that is no longer the case. Notably, RSA security token cards have been hacked.
Then there's ATM skimming for bank machines, where malicious users will place a small device that fits over the ATM. Which is where a victim would enter their bank card or their credit card. There's a PIN pad they would enter their PIN in, and that's all being captured by this skimming device. Which the malicious users can then collect that information from, either by coming on premises or wirelessly.
Enable Cloud Multi-factor Authentication
Malicious users don't like multi-factor authentication because it makes it much harder to crack a user account. And in this video, we're going to take a look at how to enable cloud multi-factor authentication, specifically using Amazon Web Services, although it can be done in many other cloud provider environments.
So here on the AWS Management Console page, where I've signed in with my account already. [An instance of AWS is open in a web browser, on the AWS services page. ] And if you don't have an account, you could always sign up for a free trial one. I'm going to scroll down under Security, Identity, & Compliance, [The indicated category displays in the All services section, and includes options such as IAM and Inspector. ] and I'm going to click on IAM. IAM stands for identity and access management.
And this is where we can build users and groups and set permissions to cloud resources, and also enable things like multi-factor authentication. [The Welcome to Identity and Access Management page opens. The navigation pane includes options such as Dashboard, Groups, and Users. Dashboard is selected and the sections IAM users sign-in link, IAM Resources, and Security Status display in the central pane. ]
The first thing I'll do is I'll click the Users view over on the left. [The presenter clicks Users in the navigation pane and a table displays in the central pane. It includes Add user and Delete user buttons. There are six columns: User name, Groups, Access key age, Password age, Last activity, and MFA. Five entries are listed. ]
That's going to give me a list of user accounts here. [He indicates the User name column. ] And I can see that I've got a MFA, or multi-factor authentication, column over on the right, where I can see that it's not been enabled for any of these users. [A "Not enabled" status displays for each row in the MFA column. ]
I'm going to select user JGold. [He clicks JGold in the User name column. The Summary page opens, and contains details such as User ARN and Path. There are four tabs below these details: Permissions, Groups, Security credentials, and Access Advisor. Permissions is selected and a table with two columns, Policy name and Policy type, displays.
There is one entry for AmazonEC2FullAccess. ] And I'm going to go to Security credentials. [He clicks the Security credentials tab. Sections such as Sign-in credentials and Access keys display. ] Now from here, we don't have an assigned MFA device. What does that mean? [The Sign-in credentials section lists the following details: Console password, Console Login link, Last Login, Assigned MFA device, and Signing certificates. He indicates Assigned MFA device, which is set to No. ]
We could have a multi-factor authentication, or MFA, device like a hardware key fob that has a numeric code synchronized with the cloud that changes periodically. So not only do we have to have our username and password, we also have to put in this code that changes frequently. And that's where we get our additional factor from something we have, the MFA device.
So if I click the little pencil icon next to No for assigned MFA device, I get options. [The Manage MFA wizard opens. It contains a Select the type of MFA device to activate section, with two radio buttons: A virtual MFA device, and A hardware MFA device. ] I can select the type of MFA device to activate, like a virtual one, which is really like an app on a smartphone.
Or I might have a physical hardware key fob that has a little display, a LED, with the numeric changing code. So in this case, I'll choose a virtual MFA device, [The radio button for A virtual MFA device is selected, by default. ] and I'll click Next Step. [A description related to installing an AWS MFA-compatible application to activate a virtual MFA device displays. It includes the following checkbox, which is cleared: Don't show me this dialog box again. ]
And I'll click Next Step again. [A QR code for scanning displays. There is also a Show secret key for manual configuration section, which is collapsed, and text input fields for entering authentication codes one and two, respectively. ] So at this point, I can either scan in this code using, for example, my smartphone if I have a scanner app installed. Or I can just expand the secret key down here. I'll just click Show secret key for manual configuration. [He expands the Show secret key for manual configuration section, and the secret configuration key displays. ]
Or I could enter this into my MFA application. So I'm using the Google Authenticator app, and I've just scanned in this QR code. And it knows it's for Amazon Web Services. It knows the username JGold. It knows all of that. So I'm going to go ahead and continue with this.
So right now, I can test this out. I've got a numeric code on my smartphone that has a countdown every 30 seconds. The numeric code changes twice a minute. So to test this out, what I need to do, let me just put in the authentication code. I need to put in my authentication code down here. So here it's 442447. [He enters the code in the text input field for Authentication code 1. ] And then I'll wait for that to time out, and I'll plug in a second one.
So I've entered the next code, [He enters a code in the text input field for Authentication code 2. ] and I've got to go ahead and move on with this. I'm going to click Activate Virtual MFA. [The following message displays: The MFA device was successfully associated with your account. ] And it says it was successfully associated with my account. [He clicks Finish and the wizard closes. He returns to the Security credentials tabbed page, on the Summary page for the user JGold. ]
So here, I've got a console login link for this user. [In the Sign-in credentials section, he indicates the URL displayed in the Console Login link field. ] Let's see if it actually works. Let's put that into another web browser tab. And let's sign in as JGold to see if MFA is actually enabled. [He switches to the AWS sign-in page, which is open in a web browser.
There are three text boxes: Account ID or alias, IAM user name, and Password. A Sign In button is also available. An account ID has been entered in the Account ID or alias text box. ] So here, I'm going to put in the IAM user name in this case of jgold. And I'll specify the password for that account. [He enters "jgold" in the IAM user name text box, and enters a password in the Password text box.] Then I'll click Sign In. [The Multi-factor Authentication page displays.
It contains an MFA Code text box, a Submit button, and a Cancel link.] And sure enough, it wants my MFA code from my smartphone app, my virtual MFA device. So I'll put in the code as it is currently. And remember, it's only good for 30 seconds. So I'm going to go ahead and Submit, and then it's letting us in. [He enters a code in the MFA Code text box and clicks Submit.
The AWS site launches on the AWS services page. ] So you can see that this makes it much more difficult to log in as that user. Because not only do we need the username and password for the account, which we entered, [He indicates the user name, JGold, and the associated account ID that displays on the ribbon. ] we also need a unique numeric code that changes every 30 seconds.
Single Sign-On and Identity Federation
Users accessing apps inside of and also outside of the organization has become increasingly popular. Let's talk about Single sign-on and identity federation. Single sign-on removes multiple login prompts so the user authenticates once and is then authorized to use multiple services. In order for this to work, we need a centralized identity provider to store user credentials.
And this removes the need for redundant user account information on multiple hosts. So what has to happen then is this centralized identity provider has to trust relying entities. In other words, it has to trust the web applications that will rely on this identity provider for authentication. But this also works in reverse where the resources need to be configured to trust the identity provider.
Now, when we say resource all we're talking about is a web application. Which is sometimes called a relying party because it relies on successful authentication to the identity provider. Now often this trust is established by exchanging public keys. So that when we get something digitally signed with the private key of the identity provider, we've got its public key and we can verify the authenticity of that signature. The idea with identity federation and single sign-on is that each and every application does not perform the authentication.
Instead, they're configured to forward authentication requests from users to the identity provider, a centralized location. The identity provider can then send a digitally signed security token after successful user authentication to the app. And this would be interesting because it's digitally signed by the private key of the identity provider, which gets verified on the app server by the related public key.
As we can see, identity providers generate what are called security tokens after successful authentication. And the service that does this is called a Security Token Service or STS. The security token can also contain what's called a claim about a user or a device. And this is just a property or an assertion related to that user or device such as a user's date of birth, or the department that a device resides in, or a user email address, and so on.
And these claims are actually consumed by applications that the security tokens are presented to. So therefore, that's why the identity provider, you'll often hear it referred to as a claims provider. So this mechanism then can be used for web single sign-on or SSO for internal or public cloud applications. Some of the benefits of SSO in identity federation include reduced cost, since once it's set up we've got a single centralized repository for user authentication.
It can also reduce complexity instead of having to manage multiple identity stores. It certainly can enhance security where we don't have applications performing their own authentication, instead it's handled centrally. There's more accountability due to centralization where authentication occurs. And this is often used to facilitate on-premises to cloud resource access for users. So let's say you've got user accounts on-premises in Active Directory.
You could keep those accounts and not duplicate them while allowing access through single sign-on to cloud resources. And in the same way it can also do the same type of thing to facilitate business to business, or B to B resource access. Let's take a look at this through a diagram [An illustration of the sign-on process has three components: a user station, a web application, and an identity provider.] where in the center, we've got a user station with a web browser. In step one, the user is trying to connect to a web application over on the right, otherwise called a relying party.
Now that web application will have been configured to trust the identity provider so it's not going to do the authentication. Instead, in step number two it's going to send a redirection, often an HTTP redirect URL back to the user station. And in step three, the user station and this happens without the user's knowledge or effort. In step three the redirect goes to the identity provider and the user then has to authenticate.
After successful authentication in step four, the identity provider digitally signs a token, which might include some claim information, which goes back to the user's station. And in step five, the user's station takes that digitally signed token and forwards it off to the web app. And the web app will verify the signature of that token, and then the user is allowed access to the resource. Some common identity federation standards include OAuth, which is the Open Standard for Authorization.
And as an example, imagine that you have the ability to sign in to multiple third party websites after signing in only once to Google. So you're not really signing into those third party sites, at least not visually, you're being passed through with your authentication token. SAML, the Security Assertion Markup Language, is another common identity federation standard that also supports claims.
Common identity federation products include cloud provider directory services, such as those made available through Microsoft Azure and Amazon Web Services. Also, we've got Microsoft Active Directory Federation Services, or ADFS and the open source Shibboleth SSO Solution. Open ID is another solution that's designed for Internet single sign-on where you authenticate once and then you're authorized for multiple websites.
Cyber Insurance
Most of us realize how important it is to have home insurance as well as car insurance. And organizations are starting to come around and realize some of the benefits of cyber insurance. Now we have to think about the result of malicious attacks and how it can disrupt business processes. It can shut down websites.
It can lead to sensitive data exposure. An attack could flood a network with useless traffic, thus preventing legitimate traffic from getting through. In some cases, some attacks can actually damage physical equipment, or in the worst case scenario can endanger human lives.
Cyber insurance then is designed to protect against malicious attacks, and you would pay monthly premiums like you would with any other type of insurance. And in some cases, there could be a premium reduction if you've got documented acceptable security controls that are compliant with third-party security standards.
So cyber insurance then could be said to be a form of risk transference, where we're transferring some risk from the organization as related to IT security to the insurer. The insurer, depending on the policy, will provide coverage for things like third-party liability, system and data restoration expenses, financial loss due to systems that are down for a period of time, reputational damage, fraud coverage.
And depending on the policy, you might also have other clauses that deal with coverage related to legal costs, or regulatory fines that are applied to an organization, or even employee malicious acts. Now something that comes up often in the discussion of cyber insurances, what about making a claim for a recently discovered breach that occurred in the past? Well, that's really going to be dependent upon the insurance carrier and the specifics of your insurance policy. Nonetheless, cyber insurance is definitely growing in popularity.
Threat Identification
One problem with mobile devices is that they're so small that they're easily lost or stolen. That's convenient for the user, but it's a problem when it comes to security. Then there were app stores, depending on the mobile device operating system will determine the specific app store that provides apps that can be installed on that device.
The problem is that some app stores are more secured than others and in some cases, we could have malware embedded within free apps. Now it's not just free apps but commonly that is the case. Mobile devices must also have a host firewall app installed. Since most mobile devices are going to be connected not only to the internet, but to different Wi-Fi networks that might even be private, with no connection to the internet, but that still could present a threat.
So we want to make sure that our firewall app is configured to not allow any connections to the phone or tablet, unless initiated by that phone or tablet. At the same time, we have to make sure, just like a regular, full-sized computer, that the mobile device has an antimalware app to watch for malware. [IT threats to mobile devices include a lack of host firewall and antimalware apps. ]
We then have to make sure we think about the sensitive data that's stored on the device. If any sensitive data is stored on the device, it must be encrypted. In some cases, the data might not actually be on the device, but rather accessible through an app on the device.
Well, in that case, we want to make sure that app, like a VPN app is secured and that users are not selecting options to remember passwords and so on. So what we can do further about mobile device threats? One option is to consider not allowing BYOD, bring your own device. Now the advantage of BYOD is that users can bring their own mobile devices whether it's a laptop, a tablet or a smartphone into the company network. And they can access company resources, so in some ways it's good.
They can be productive. But at the same time, it's a little more difficult to manage at the IT level, because you've got to use a device that has both personal apps and settings, as well as corporate apps and settings. And yes, it could be partitioned, but it certainly does complicate things a bit. Also, you don't really have control of these specific platform that's currently in use, since it's a personally owned device.
So one option might be to not allow this, and instead, deal with company issued mobile devices only. Now, in some cases, that's not convenient because then employees would have to handle two mobile devices at all times. So the corporate partition then, separates apps, settings, and data, and it also facilitates remote wipe so that if we have a lost or stolen device, IT staff can remotely wipe the corporate app, settings, and data, from the device.
Also, we have to make sure that we've got a host firewall, as well as anti-malware app installed on the mobile device. And many corporations these days restrict app installation, so only the IT department can push out apps to the mobile device. For a number of years, there's been a big movement to the cloud and as a result security is at the forefront, when it comes to cloud computing.
One trending cloud computing is to enable multi-factor authentication or MFA. Where we have for example, a user name and a password and something else like a hardware. Or a virtual keyfob that's got to a changing numeric code that's synced with the cloud server. That way, knowledge of just the username or password is not enough to login to a cloud account and access cloud resources.
Of course, cloud encryption is a big deal, [Cloud encryption of data at rest is another example of cloud hardening trends. ] whether we encrypt data ourselves using an app of our choosing ahead of time before we put data in the cloud, [The presenter refers to manually encrypting data first before uploading it. ] or we do it using cloud-provider encryption.
Or maybe even both, in some cases. Now, this might be dictated by regulations where it stipulates that we've got to use a certain type of encryption. And that that encrypted data must be stored, for example within national boundaries. These days cyber insurance has grown in popularity for organizations because it transfers some of the risk of IT computing to the insurer.
And it can protect against things like, legal costs that might arise, let's say from sensitive data that got leaked that was protected properly. Or expenses related to system and data recovery, extortion, such as through ransomware, lost revenue due to systems that might have been hit by a distributed denial of service attack. And therefore were unavailable for legitimate use and also reputational damage. Naturally, as it's the case with insurance, it is specific to the policy.