Data Security Standards

Physical security is a very important aspect of overall security, the security posture of an organization, including of its digital IT systems and resultant data. When we talk about physical security, we have to always remember that all IT systems at the end of the day use underlying hardware, which is housed somewhere physically that runs those systems. And so we have to think about security at that level. Now, in the case of something like cloud computing for public clouds, that equipment would reside in a data center and that would be the responsibility of the cloud provider or if they're only using a small section of space in a data center, physical security would be the responsibility of data center management. But even at a much smaller scale, if we work from home or if you run a small business, in some way, you will be interacting with technology. So we even have to think about security at the physical level, even for a small home office and storage devices and laptops, tablets and smartphones. So limiting physical access is always the first part of physical security.

 

Now, we've mentioned the relationship between physical security and cloud computing. We know that cloud computing is a form of outsourcing. It's really risk transfer. You are transferring some of the risk of the underlying infrastructure, the responsibility for making sure it's up and running to the cloud service provider. And we know that as cloud customers, we do not have access to cloud provider hardware. It sits in a data center somewhere. You're going to be relying on public cloud services. It's important to know that cloud providers do publish security audit results from a variety of different third-party sources to assure their customers, that would be us, of their compliance with certain security standards, laws and regulations.

 

The physical security can come in many forms as depicted on the screen, whether it's video surveillance cameras. This could even serve as a deterrent before break-ins might occur, for example. Or they could detect that a break-in has occurred already. Then we have things like physical safes in which we might store sensitive documents that might contain credentials for highly privileged accounts or that might contain storage media or backup tapes

 

for important data. Depicted in our picture, we also have keys. Now, these could be physical keys, of course. We're talking about physical security to gain access to perhaps a building or a floor in a building or an equipment rack within a data center, although building security nowadays usually uses proximity wireless cards. Physical security would also include security guards, for example, around or in a military installation or a data center or mall security guards. There might be a retailer that stores some sensitive customer information, like credit card details on storage media within their retail store. So security guards would be another important layer of security to consider to secure those types of assets. When it comes to physical security for buildings and properties, besides security guards and video surveillance cameras, things like proper lighting, fencing and barricades, all of that can go a long way to preventing physical access or physical damage to resources.

 

So with physical security, assets need to be identified or inventoried. Imagine, for example, that the assets we're talking about would be computers of any kind that contain sensitive data. We need to know where those devices are, who is using them, how they're configured, how they're being used. So the location needs to be known because in some cases, depending on where an asset like sensitive data for customers is being stored, there might be different laws that might apply to it, like within national boundaries. Now, when you inventory assets, the next thing to do is to prioritize them so you know where to focus the attention for security, both at the physical level and at other levels, such as with things like encryption of data at rest. Now the inventorying of assets should be something that's done periodically, recurring, not just once, because by periodically inventorying to determine, for example, even what devices we have on a network, this can help us identify suspicious changes like newly present devices on the network that shouldn't be there and that were not there in the past. Part of threat hunting.

 

And then, of course, we have the marriage of both physical and digital security. Things like car door locks and alarms. Car door lock can be digital, but it also might accept a physical key, although that seems to be changing over time. The use of multi-factor authentication or MFA, such as having a smart card that you insert into a reader. The reader might be built into something like a laptop or a desktop or a keyboard, or it might be an external USB device having a key fob with a code that changes periodically in synchronization with the server side component like a VPN. Encryption of data at rest, as we've mentioned, just in case storage devices are physically stolen from equipment racks or from home offices in the form of USB thumb drives. Another physical security concept to consider is air-gapping a network. Air-gapping a network means it does not have a physical connection, whether wired or wirelessly to other networks. It's an isolated network. And you would do this for very secure networks where you don't want to take a chance that there would be some kind of outside connectivity to the network. Even having cable locks to deter laptop computer theft, these things can go a long way in preventing not just the theft of that physical device, what's more important is the data and configuration settings on it.

 

And another interesting aspect of physical security is the use of drones. Now, drones have become very inexpensive for the average consumer and can be equipped with Wi-Fi network capabilities, cameras and so on. So we have to think about things like proximity security and no-fly zones. Now, some sensitive locations like airports and surrounding areas are always considered no-fly zones, and some drones in their circuitry have a built-in list, which is actually an updatable list when you update the firmware of no-fly zones, where the drone cannot be used, cannot be flown. However, whether for organized crime or nation-state surveillance, drones can also be used for reconnaissance because they're very inexpensive, easy to use and are actually easy to hide. Connaissance would mean, for example, using a drone to fly over even a data center to determine what kinds of physical security steps have been taken to secure that facility, at least from an external perspective. And of course, at the military level, drones can of course, be weaponized. So these are all things that we must consider when it comes to physical security and potential attack vectors and what to look out for.

 

Personally Identifiable Information otherwise called PII spelled PII consists of one or more pieces of information that can be used to uniquely identify an individual. And as you might imagine, this needs to be safeguarded. So we're talking about data privacy in terms of its collection, the transmission of sensitive data, how and where it's stored, how it gets shared, if it gets shared at all, and how that data is used or processed. Most of these data privacy activities are outlined in privacy impact statements or consent documents that individuals must sign off on when their data is going to be collected or used in some manner.

 

So what are some examples of personally identifiable information? Well, think about things like web browser cookie contents. On an end user device, a web browser cookie is a small text file that contains information related to that current browsing session, even for a given site. Sometimes it can contain sensitive confidential information and as such, depending on what the contents of the web browser cookie consist of will determine whether or not it's considered PII. The user location, which is available via GPS, can be considered personally identifiable information at a given point in time, and as such it might need to be safeguarded. And of course there's financial details like credit card numbers, bank account numbers. Depending on how it's being used and the point in time at which it's being referenced, an IP address can also be considered personally identifiable information. Again, it depends on specific configuration settings, but it does fall under this realm.

 

A subset of this is what's called Sensitive Personal Information or SPI. You'll sometimes see it listed for short, just as sensitive information or SI. But regardless, it is the same thing as SPI. Now, usually sensitive information is something that is safeguarded due to the fact that it could be used to discriminate against individuals; things like political or religious preferences or membership in various types of trade unions or sexual orientation, or how people associate in terms of gender or genderless. All of this is considered SPI.

 

On the medical side, we have protected health information or PHI. So this is medical information that needs to be safeguarded, that can be traced back to an individual. So things like details related to a specific health plan and health insurance, of course, medical technical details like specific blood type medical history, surgical procedures in conjunction with patient's information, this is definitely considered PHI. So now that we've covered various examples of sensitive data across our wide realm of categories, the next thing to think about is how it will be protected.

 

Usually this is dictated by various laws, regulations, even in some cases contractual requirements that security controls need to be put in place to protect PII, and that we have a way to demonstrate that those security controls are effective at protecting it. Depending on the nature of the type of PII that's being handled, a breach of certain types of PII can have severe consequences, both legal and financial, if it can be demonstrated that the proper steps were not undertaken for the protection of that PII. Now, how do we know what applies to a given sensitive data? Because data privacy laws will vary around the world, and that's true. But we have to think about the order of precedence. Normally, we would first consider global data privacy standards that apply to sensitive data. Once we've identified data as being sensitive, regardless of its location on the planet, then we would take a look at national laws or regulations that might apply if data is related to citizens that have a certain nationality or if that data resides within certain national boundaries. Then we would look at even more specific security and privacy issues related to regional and finally, local storage of data.

 

So in order to protect PII, the first thing we have to know is what we have. What do we have in terms of sensitive data? That's where data discovery and classification automation is very important, whether on-premises or in the cloud. So where do we have this information and how much of it do we have? Once we have identified that, we can determine do we really need to store this type of information? Do we need to store, for example, credit card details? And once we determine that we will be storing some sensitive data, how will it be protected? Usually when we look at security standards, laws and regulations, in most cases they're pretty general in terms of how they suggest to protect data. Usually it doesn't go into detail on specific technologies, at least in most cases. So it's usually up to the security technicians or the cybersecurity analysts to determine which security controls should be put in place or if they're already in place, how effective they are. Let's also not forget that an important part of protecting PII is monitoring. We need to be able to identify suspicious activity in its many various forms which can be related to the protection of sensitive data.

 

So let's talk about one of the things that we can do to prevent ourselves or to at least minimize the impact of being exposed to data breaches, and that would be Data Loss Prevention or DLP. This is also sometimes called data leakage prevention, but it means the exact same thing. And what that is, is that we want to prevent the disclosure of confidential information to unauthorized parties, whether that be intentional, such as an insider job, maybe someone within the organization being paid off to divulge sensitive data, or whether it happens by mistake because an employee's computer was somehow compromised or infected with malware. Now, depending on the nature of your industry and the nature of where your organization does business will determine whether or not there are regulations that require DLP to be implemented.

 

So how can we implement DLP? Some are tangible and some are intangible methods. Intangible would include things like user awareness and training, probably one of the most effective ways of securing an environment, and this needs to be periodic and recurring through training, for example, so that people are aware of scams, how malware can infect a machine very easily, and also being aware of organizational security policies and remaining compliant with them. Data loss prevention can also be built into new employee/new hire onboarding, and that would also include contractors. Over time, most organizations will experience some kind of a security incident at the IT level, and so that can be incorporated into future training for user awareness and training seminars. Again, this should be a recurring event.

 

Now, on the tangible and technical side, how can we implement data loss prevention? This can be done either on-premises and/or in the cloud. In order for this to be effective, one of the first tasks in DLP is to discover the data that you have, and that can be much more difficult than it sounds when you think about data sprawl across an on-premises environment and also throughout a cloud or multiple cloud environments. So data has to be discovered and classified. We have to know what kind of sensitive data we have and how it's being used before we can properly craft policies to protect it from unauthorized disclosure. So we can use templates depending on the tool that we're using to discover and classify data. A template might, for example, look at a series of numbers to determine that it's a credit card number and classify that as financial data.

 

IT technicians can create DLP policies that control the exposure of data, sensitive data within the organization and also outside of the organization. Now, in order for those policies to be applied, and this will really depend on the solution that you're using, but generally speaking, you're going to probably need some kind of a software agent, a client endpoint agent on client devices to be installed. For example, if you want to be able to monitor how sensitive documents created in Microsoft Office are handled, you'll need an agent installed that monitors that in real time to prevent things like intellectual property from leaving the organization or being attached to email messages being sent through social media and so on.

 

So we need to have a way then that we can detect that these DLP policies have been violated. Now having client agents is the first part of that, but having it reported centrally is going to be what's important. This is just another variation of analyzing log events and threat hunting, in this case, specific to policy violations based on our data loss prevention environment.

 

So what are some examples of what we might implement within a DLP policy? The limited use of removable media like USB thumb drives, maybe only a certain type of thumb drive is allowed or maybe they're blocked completely. We can't write data to thumb drives. If you're in a Windows environment, for example, and those computers are joined to an Active Directory domain, you can quickly deploy those types of settings, limited removable media use using Microsoft Active Directory Group Policy. But there are so many other things that you can do with DLP policies like prevent the printing of sensitive data, prevent the forwarding of certain types of data, prevent file attachments because the client agent would detect that it's sensitive data or perhaps the client agent can detect if a user has signed in not just with username and password, but also a smart card, in which case sensitive file attachments might be allowed. We can limit social media content if social media access is allowed at all from a work environment.

 

So in the right of our diagram here, we have DLP policy configuration which can consist of conditions such as my example of signing in not only with a username and a password, but also with the smart card. So it might mean that you have a higher level of security clearance and therefore you should be able to send sensitive documents through file attachments to internal email addresses. So the policies for DLP will consist of conditions and actions that are either allowed or denied.

 

To create these DLP policies, we have to think very carefully about how data might be leaked, what are methods of data loss? It could be network print jobs where a printer gets compromised and sensitive documents are still in the print queue and that data might be retrievable through a compromised network printer or even documents that get scanned on network printers where the document is physically left on the scanning glass. And if that device is compromised or even if someone else within the organization on that same floor, let's say, if they can issue commands to scan in that document, whether they're physically present at the network printer or from their station, that could be a security risk.

 

We already know that storage media can be a way that data gets exfiltrated out of the organization. Even the use of digital cameras, taking pictures of sensitive locations or lost employee smartphones where remote wipe should really be enacted to wipe any sensitive data or configurations from the phone.

 

Another way to lose sensitive data is through hardware and software keyloggers. Keyloggers, as the name implies, track every key pressed on the keyboard. A software keylogger is usually easily detected with most anti-malware solutions, but hardware keyloggers physically, for example, plug into the back of a computer in a USB port and on the other side of that connector, a USB keyboard would be plugged in. Everything typed into the keyboard goes through that hardware keylogger, which might even have a built in Wi-Fi access point to allow remote connectivity to get a dump of what was typed in on the keyboard. That can be very scary, but of course it would require physical access to a device to do that. Infected files like spreadsheets and databases can also result in data loss.

 

The sending of email messages, whether intentional or unintentional, by internal employees with sensitive information, can be a problem, can result in data loss.

 

Social media posts such as posting pictures or posting documents, even imagine a security technician within an organization making a social media post about their workday and configuring a specific model of a security appliance. Now that information is out there. One thing that attackers would need to know to compromise an environment is what is being used and how it's configured.

 

There could also be covert actions like specially crafted DNS queries or even specially formed IP packets that can be used to exfiltrate data directly or indirectly outside of an organization.

 

And let's not forget about physical documents. We talked about network print jobs. If physical documents are printed and then discarded in a waste bin without being shredded, then attackers could potentially use a method called dumpster diving, which means what it sounds like, going through garbage, looking for documents that might contain clues about how something is configured or passwords or server names and so on.

 

Now, let's always remember that encrypting data provides data confidentiality. And so even if encrypted data happens to get stolen, it's generally considered to be inaccessible by the thieves because you shouldn't be able to easily decrypt encrypted data. Of course, the details really matter here. How is it encrypted? Is it symmetric encryption? Is it public and private key or asymmetric encryption?

 

But generally speaking, if something is encrypted on storage media and you steal the storage media, you're probably going to have a very difficult time decrypting that data. Let's not forget, we should be encrypting everything over a network as well. So you can configure DLP policies for the given DLP tool you might be using on-premises or in the cloud to enforce things like data encryption. Imagine that you're a cybersecurity analyst that gets hired as a consultant for a company you're not familiar with already. One of the things you would have to know among many is, is there a DLP solution in place? Do we know if we have sensitive data? And of course, are we monitoring for DLP policy violations?

 

For organizations that will deal with European Union customers, the General Data Protection Regulation, or GDPR, is a big deal. What's this about? This is a legislative act that results from the European Union or the EU. Okay, but what does it do? The purpose here is to put control of personally identifiable information or PII into the hands of the person that owns it, in this case for EU citizens. Now, this is all about data privacy for citizens of the European Union, regardless of where organizations might be located in the world.

So this is about data privacy then, which means that we're talking about the collection of it, how it gets retained and for how long, how that PII gets processed or how it will be used by organizations that collect it, and also whether or not sensitive data owned by an individual will be shared with other entities such as with marketing firms or advertising agencies.

 

So the GDPR is applicable for organizations. Now, these organizations, as we know it doesn't matter where they are located physically, anywhere in the world, as long as they are processing EU citizen private data, the GDPR applies to those organizations. For individual EU citizens, what are their rights? Well, organizations that will collect or gather EU citizen private data have to be very clear about how they communicate getting consent from citizens such as on a web form for data collection, use, sharing and so on. EU citizens also must have the ability to view any of their collected sensitive data and also have the ability to modify that data.

 

Now for organizations that can prove they are compliant with GDPR, this is going to be something that's going to boost potential customer or existing customer confidence, especially for European Union citizens. But this is serious business. Organizations must have a GDPR representative that they appoint as per GDPR Article 27. This means having some kind of a local presence in each EU country where the organization will be doing business and will interact in some way with personally identifiable information of EU citizens. This local presence could be an internal employee that works for the organization, or it can be an external representative that's hired by the organization so they don't have to be part of the company doing business necessarily.

 

In order to become compliant with GDPR, an organization must first take inventory of the sensitive information that they have. That means they have to determine if it is personally identifiable information specifically for European Union citizens. The next thing that the organization would do is perform a risk assessment against that sensitive information to determine potential threats and then identify potential mitigations against those threats.

 

The third step of GDPR compliance involves applying security controls to protect EU citizen private data that can come in many, many forms, including multi-factor authentication, encryption and data masking to hide sensitive information on screens to name, but just a few. In addition, organizations must ensure that they periodically review their specific security controls and how they are compliant with GDPR.

 

Now, we said that this is a big deal. So what happens if organizations are found to have not complied, willfully not complied with the GDPR? One possibility is the organization being banned from doing business with EU customers. And then of course, having fines imposed up to €20 million. That's around 20 or 21 million USD. And that would be for each infraction, or it could be up to 4% of the previous year's worldwide income, as reported by the organization. So as you might guess, the European Union is not playing around when it comes to data privacy for its citizens.

 

The Health Insurance Portability and Accountability Act, otherwise called HIPAA is all about data privacy for protected health information or PHI in the United States. You might recall that protected health information is anything that is considered sensitive medical data related to an individual like patient medical plans or a patient's blood type over time, their medical history, those types of things. As you might imagine, that is the type of stuff that must be kept secure and away from unauthorized eyes. And that's where HIPAA stems from.

 

So this has been around since 1996. There are a couple of concepts we first have to get out of the way, and that would be different types of electronic records. There are variations on it. The first is an electronic medical record, an EMR. This is the location where a doctor, when a patient visits a clinic, for example, records all of the information about the visits over time and the results of things like blood tests. Now, that might sound obvious, but we've also got some other variations, like an electronic health record, an EHR.

 

This one is a little bit different because it's the same type of collected medical information for patients but the difference is that instead of an EMR, where it's really designed to be used within a clinic or within a doctor's office, an EHR is designed to be shared electronically among different healthcare environments. And then there's the personal health record, the PHR. This usually includes a complete medical history for a given patient that's under custodian care, where that custodian could be the patient themselves, or it could be a family member. But a PHR is different from an EMR and an EHR because with a PHR it's completely in the control of whoever is the custodian of that person's medical information.

 

So what do we have to think about in order to be compliant with HIPAA? Well, it's not all just about IT stuff and technical stuff. There are physical safeguards, things like security to limit access to entire buildings or floors within a building and individual rooms. In order to limit access to patient medical information, the use of security guards is recommended. Having secure equipment racks that can actually lock, this would be in wiring closets or server rooms or in entire data centers. We want to make it very difficult for anybody to gain access to storage media that might contain protected health information.

 

Physical device security, such as devices existing in locked rooms like server hardware, encrypting any storage devices, including on smartphones, having cable locks for laptops to help prevent their theft, maybe even having location tracking enabled on portable devices like laptops, tablets and smartphones.

 

Now because protected health information needs to be stored somewhere, we have to think about what happens once the storage media has reached end-of-life and it's going to be decommissioned, so wiping off storage devices. Now, we all know that when it comes to deleting files or entire disk partitions, even even partition tables, which record which partitions are on a disk, in some cases, all of that data can be recovered even after those actions have taken place. Okay, so then what should we do to wipe storage devices?

 

Well, there are many ways to deal with how to cleanse storage devices to make sure any data artifacts cannot be recovered by unauthorized parties. Things like performing multiple-pass random data overwrites of storage media, software type of solution, or the physical destruction of storage media devices, the physical shredding of storage devices or drilling of holes through disk platters, that type of thing. In other words, we need to make sure there are no data remnants that can possibly be recovered in any way.

 

What about technical safeguards? Well, with HIPAA, a lot of the standard fare for security controls comes into play. Things like network access control or NAC limiting who can gain access to the network in the first place and making sure that their device is hopefully not infected with malware when they do connect to the network, using some kind of network encryption to protect all data in transit, whether we're using IPsec, HTTPS, SSH or any combination thereof, having network perimeter firewalls configured correctly for a given environment, so allowing the appropriate traffic in and out, having intrusion detection systems configured to detect potential suspicious activity, going through the standard hardening techniques to harden hosts like Linux or Windows machines, patching them, making sure that those individual hosts have software-based firewalls configured as well as having network perimeter firewalls.

 

We mentioned storage device encryption, while specifically in Linux, you can use a number of different utilities like dm-crypt. You can use on the Windows side, Microsoft BitLocker, or you can also acquire self-encrypting drives, discovering and classifying data to detect what data is sensitive. What is perhaps considered to be sensitive medical information is absolutely key. We have to be able to account for where that type of data exists.

 

And employing data loss prevention or DLP solutions to prevent or at least mitigate the amount of data exfiltration that there might be. It's possible that on the Cybersecurity Analyst+ exam you might get situational or scenario-based questions that will test your knowledge of which safeguard would best improve a given situation. So read those questions carefully.

 

So what about noncompliance with HIPAA when it should have been in place? What happens? Well, at the civil level, civil violations could be up to 250,000 USD. That would be a total for all violations on an annual basis. If it can be proven that there was willful violation, that could include fines that get imposed as well as prison time for up to five years. So a lot of these data privacy regulations are not kidding around. It is serious business.

 

The Payment Card Industry Data Security Standard, otherwise called PCI DSS is an international security framework that relates to the protection of consumer cardholder data. So think about things like debit cards and credit cards and how important it is to safeguard that type of information. So the goal is to harden payment card processing environments, including at the point of sale, so retail outlets that have card readers all the way through to the transmission of that cardholder information to the provider to ensure that transactions are processed correctly. Now, as is the case with a lot of these security frameworks and even laws and regulations, they get updated periodically. So it's important for affected organizations to track when there are changes. For example, the current version of PCI DSS is version four that was published in March of 2022, but the previous version, 3.2.1, still will remain valid until March 2024. So in larger organizations, you might have an IT regulatory analyst that is responsible for tracking these types of things. Now, each type of card will have its own specific compliance details. So, for example, the compliance details might differ between Visa, Mastercard and American Express.

 

Now for organizations to implement the appropriate safeguards to be compliant with PCI DSS. It begins in step one with identifying cardholder data and where it's stored, if it's being stored, as well as how the data is collected, such as at a point of sale terminal, how that data is transmitted, so the network path that takes and whether those networks are secured. When it comes to the storage of cardholder information, unless you absolutely need to store it, you shouldn't be storing it. It's just another potential security breach that you don't need. The next thing to do for proper PCI DSS implementation is to assess, implement or modify existing security controls or identify new ones. Security controls protect assets. So controls would include things like network firewalls, storage encryption techniques, the changing of vendor default settings such as on network equipment. The next thing to consider in step three is having a periodic review of security control efficacy, the periodic updating of network diagrams, making sure they are up to date with current configurations and periodic vulnerability assessments. Now for PCI DSS compliant, the general rule of thumb is you need to have four security scans that need to be performed per calendar year. So in other words, you should run a vulnerability scan once every three months or if there's a major network configuration change. The last part of PCI DSS implementation is the periodic creation of PCI DSS compliance reports.

 

There are a number of different PCI DSS compliance levels. Now, these compliance levels are based on the number of transactions for a given organization dealing with cardholder data on an annual basis. So level one, for example, would apply to organizations with more than 6 million card transactions, level two would be 1 to 6 million card transactions, level three would be 20,000 to 1 million transactions, and level four would be less than 20,000 transactions.

 

Then we have the notion of PCI DSS control objectives. In other words, what are the security objectives? What are we trying to achieve The first one is to establish and maintain a secure network. Second, protect payment card and cardholder data. Three, maintain a vulnerability management program. Four, implement strong access control measures and protect identity and access management. Five, monitor and test networks and network traffic regularly and evaluate their effectiveness and six, to maintain a personnel-wide information security policy. So definitely user security awareness and training. Now those six control objectives are split into twelve requirements and those twelve requirements are further divided even further into hundreds of subrequirements. It's all in the PCI DSS documentation, which is freely available on the Internet.

 

So in order to satisfy some of those control objectives, what can we do? So let's say the goal is to build and maintain a secure network. What can we do about that? Well, maybe you would have firewalls that would help you enable a secure network environment or changing system defaults on network equipment on a network like routers and switches. If the goal is to protect cardholder data, we can apply storage data encryption and network encryption for transmission. If the goal is to maintain a vulnerability management program, we can have antivirus solutions and making sure they're up to date on all endpoint devices. We can apply security to all software development life cycle or SDLC phases where it applies. Implement strong access control, well, we can give access to sensitive data on a need to know basis only. Every user would be required to have their own unique user account. We might even have physical security controls in place to make sure we have limited access to stations that have access to cardholder data.

 

Now, if you have an auditor in performing a PCI DSS assessment, there are a number of different statuses for assessor findings for each of the requirements. The first is in place. The assessor will provide the details about a specific requirement that is satisfied with the security control and it will be documented. Next. Another potential finding status would be in place with compensating control worksheet or CCW. This means that a compensating control was used to meet the requirement. And what's a compensating control? When you can't have the desired security control in place to protect something, maybe because it's prohibitively expensive or too complex to implement or would take too long, sometimes you'll have alternative solutions that would still meet the requirement, and that's what would be recorded on a CCW. Next, we have not applicable. This one means what it says. If we've got a requirement to protect a wireless network but there are no wireless networks, then it's just not applicable. Then we have not tested. This one also means what it says. It means the security controls to satisfy a requirement were not tested. It could be because a solution is in the midst of being deployed. And then finally, we have not in place. This could mean it's missing or once again, it could mean that it's in the midst of being deployed. So these are the things that cybersecurity analysts need to keep in mind when it comes to compliance with PCI DSS.

 

 So Amazon Macie then is a cloud-based service that's designed to go and discover data seeking any sensitive data. There are some built-in templates where it will look for things like user personal information such as home addresses, financial information like credit card numbers and so on. Of course you can customize templates to have it seek very specific types of information. [Video description begins] The Console Home of AWS Management Console is open in the browser. There is a search bar on the top and the console has two sections named Welcome to AWS and AWS Health. Both sections contain several subheadings. [Video description ends]

 

Now here in the AWS Management Console in the cloud, I'm going to begin in the Search bar by typing in the word bucket. In AWS a bucket is a storage location. It's called an S3 bucket, where the S3 comes from simple storage service. [Video description begins] The presenter types bucket in the Search bar which displays the results section. It consists of multiple categories where the Service category is selected and there is a list of services where he clicks on the S3 option which leads to the Amazon S3 page. On the right hand, there is a Create bucket button. [Video description ends]

 

Now, currently I don't have any buckets, so I'm prompted to create one. I'm going to click Create a Bucket, and I'll fill in some details such as the bucket name. [Video description begins] The Create bucket form opens up. There are multiple fields to be filled including Bucket Name, AWS Region, and so on. He types bucketyhz172 as the bucket name. [Video description ends] I'm going to create this bucket in the US East region, assuming that most access to the contents of this bucket because it will store files will be in that region. I can choose to copy settings from an existing bucket, but I'm just going to build it from scratch and notice that the default from a security perspective is that public access is blocked. So we're not going to allow anonymous access to the contents of this bucket. Now, in some cases you might want anonymous access enabled, such as if it's simply product documentation and that's all that's stored in the bucket that should be freely available to anybody over the Internet. That's not the case here.

 

Notice that the encryption type here will automatically be set to Server-side encryption using an Amazon S3 managed key as opposed to a customer-managed key. I'm okay with that for this example. So in the bottom right, I'll go ahead and click the Create bucket button. Okay, so the bucket name needs to be unique. It successfully created the bucket. [Video description begins] The page displays details like Name, AWS Region, Access and Creation date of the bucket created. [Video description ends]

 

So now if I were to go and search for bucket again here, now I have a list of my buckets which really consist of only the single new bucket that I've created. When you're going to use Amazon Macie, you don't have to create a new bucket. You can have it scour existing buckets. We're just doing everything all at once here. Let's open up that bucket. [Video description begins] The presenter clicks on the name of the bucket. [Video description ends] And in here I could do things like create folders.

 

So for example, maybe I'll create a folder called HeadQuarters and I'll go down in the bottom right and create the folder. There's the HeadQuarters folder. You don't need to have folders, but of course it helps you organize the contents just like it would on a normal storage media. If I open up HeadQuarters, I then have the option of course, of uploading content to it, which I will do.

 

So I'll click Add files. So I've added a couple of sample files here and I know that there is some sensitive data in here. So down in the bottom right I'll click Upload and because the files are pretty small, the upload will complete very quickly. I'll click Close. So now we've got our files here in our bucket.

 

One of them is just a test personally identifiable information or PII XML document. If I click on that to open up its properties and then click Open, it'll open here in the browser because this is an XML file and browsers know how to display those. So we've got some things like credit card numbers for Visa or Mastercard or Amex and so on. Okay, so we know there's some sensitive data in there that'll be perfect for this.

 

So in the Search bar at the top here, I'll search for Macie. There's Amazon Macie, so I'll go ahead and click on that and I'm going to click the Create job button in the upper right. [Video description begins] The Create Job screen is open in Amazon Macie on the browser. On the left pane, there are multiple options like Summary, Get started, Findings and so on where the Jobs option is selected. On the central pane, there are several steps where Step 1 Choose S3 buckets is selected. [Video description ends] So what it's prompting me to do is to select the S3 bucket or buckets that I want to search through looking for sensitive data. So my newly created bucket shows in the list, I'll put a check mark next to it and I'll click Next in the bottom right. I'll click Next in the bottom right again, and we can determine how often we want this discovery and classification job to occur. So it can be set Daily. It can be a One-time job. Besides Daily, it could be Weekly or Monthly. I'm going to leave it as a One-time job in this particular case. But realistically, because data will be updated, presumably unless it's an archive, you would want to have a scheduled recurring data discovery and classification job. Notice the sampling depth here is set at 100%. This means I want it to scour 100%. I want to do a full discovery and classification of every object.

 

When you deal with extremely large numbers of objects stored in an S3 bucket, you can reduce the sampling depth, let's say, to approximately 50% or one half of the objects in the bucket that would be analyzed due to time constraints. However, here I want it at 100%. Down below under additional settings. I can also specify Object criteria. Maybe I only want to look at certain file extension types or files of a certain size and so on. But I'm not going to specify anything because I want to scour everything in the bucket. So I'll click Next. Data identifiers. Down below here, it has a recommended list of common things that we look for like AWS credentials, Canada driver's license, Canada passport number, social insurance number, credit card number, France passport number, and so on. Obviously, this is personally identifiable information. We can customize that, but I'm going to leave it as it is. I'll click Next so we don't have any custom data identifiers.

 

Next, again. In the allow list, we can specify things we want to ignore from being discovered and classified, but I'm going to click Next and then I need a Job name. I'm going to call it PIIJob1 and that's it. Then on the bottom right, I just click Next. On the Review and create screen, it will give me an estimation of the cost depending on how much data might be checked, how long it might take. But in this case, it's almost minimal information so there's no cost. Okay.

 

I've got my summary here. Down at the bottom, it says You haven't configured a repository for your sensitive data discovery results. I'm going to choose to override that with the understanding that Amazon Macie will only keep my discovery results for 90 days. That's fine. Then I can click the Submit button in the bottom right. Okay. So the job was successfully submitted and here we've got the Jobs view.

 

I've got an older job called SeekPII, but our current job is called PIIJob1 and it's currently active and running. If I click on that job, [Video description begins] The presenter clicks on the Jobs option on the left pane. It displays the details of two jobs PIIJob1 and SeekPII where their status is displayed Active (Running) and Cancelled respectively. [Video description ends] we get some properties shown over on the right. Again, the status is active and running. The scope for the job type is set as a one time job, of course, and it's only looking through 1 S3 bucket, so we'll just give it some time to run the scan. So we've got some financial data that was found in a file called Employee_Cards.xlsx. It's one of the files that we uploaded. If I click to open that up as I scroll down on the right and look at the details of what it found, under financial information, it's showing that we have two credit card expiration pieces of data that were found. If I click the link for the 2 next to credit card expiration, it gives me some JSON text referring to the cells.

 

This is an Excel spreadsheet and the column names and the row number in this case rows 2 and 3. So before we can determine which assets need to be protected, we have to know where those assets are. We have to know what sensitive data we have and of course, which laws, regulations or security standards might apply to determine the security controls that need to be put in place to protect those digital data assets.

 

In this demonstration, I will be classifying data using the Windows File Server Resource Manager component. Now the File Server Resource Manager is available on the Windows Server OS to be installed, but it's not installed automatically.

 

So the first thing we're going to do is verify that File Server Resource Manager. I'm just going to call that FSRM. Let's make sure FSRM is installed. One way to do that is by going into the Start menu and spinning up the Server Manager tool. You could also check this at the command line, of course, if we wanted to. [Video description begins] The Server Manager Dashboard window is open. The QUICK START section is selected. It displays five options; Configure this local server, Add roles and features, Add other servers to manage, Create a server group and Connect this server to cloud services. On the top right corner, there are options like Manage, Tools, View and Help. [Video description ends]

 

So one of the things I could do is go to the Tools menu. I could just go to the Start menu to check this out as well to see if File Server Resource Manager is there. It's already there. If it's not installed, we would go to Add roles and features and we would proceed through to the roles part of the wizard where under File and Storage Services, we could expand that. Then we would expand File and iSCSI Services and under there you would turn on File Server Resource Manager. So that's already been done.

 

So let's go ahead and fire up the tool. I'll do it here from the Start menu. [Video description begins] The presenter closes the window. [Video description ends] So I'll go to Start, Windows Administrative Tools and I'll choose File Server Resource Manager. Now this tool provides a number of features like managing disk space through Quota Management, screening which files are allowed to exist on the server, generating storage reports to see how the storage is being used on this host and of course Classification Management, which is going to be our focal point. [Video description begins] He clicks on the Classification Management option which expands to two sub categories, Classification Properties and Classification Rules. [Video description ends] If I drill down under Classification Management on the left, I can then click Classification Rules. We don't currently have any rules created, but let's pause for a moment and let's go check out the file system on this server to see what kind of sensitive data we might be able to discover by configuring an FSRM rule.

 

So if I go into the File Explorer on this server, I've got a drive F on this host. If I go to drive F, I've got a HeadQuarters folder and in it I've got a Customer_Details file. Let's just go ahead and open that up with WordPad so we can at least increase the size under the View menu. Let's just zoom in. Okay, so we've got some sample data here that includes email addresses, names and credit card numbers and credit card expiry dates. Okay.

 

Let's go back into FSRM and the Classification Rules view. Let's right click and Create Classification Rule. [Video description begins] A dialog box opens up with tabs like General, Scope, Classification and Evaluation Type. Under the General tab, there are two fields to be filled; Rule name and Description. [Video description ends] I'm going to call this SeekPII personally identifiable information. Now the scope, where do we want to look?

 

We can tell it to look through certain types of files, application files, backup and archive files and so on. But we can also specify file system locations. If I click the Add button at the bottom here, I would be able to specify, for example, drive F, let's tell it, we want to search drive F, then I'll click the Classification tab. We want to look at the content of the file. So down below I'll click Configure and we can specify a Regular expression. So pattern matching or a string that's case sensitive or not, I'll just choose String and maybe the expression I'll look for is credit card. I need to have at least 1 occurrence for this. Okay. But there's something else I want to do. I'm going to click Okay for now on that.

 

I want to go to Classification Properties. What I want to do is I want to flag files with credit card information in them as financial. So I'm going to right click in the Classification Properties view and create a local property called Financial. It's just going to be a basic Yes or No, either yes, it is financial or no, it is not. There are other variations like Date-time, Number and so on. But Yes/No is perfect. So let's go back to our Classification Rule. There it is, SeekPII. I'm going to open it up and under Classification, remember we specified we want to look through the content so Content Classifier, the property I want to assign to files that match this is now showing up in the list as Financial. Again, that was under Configure, you might recall, credit card.

 

Okay, so now what I can do is I can Configure a Classification Schedule by clicking that in the right hand Actions bar. How often do we want to schedule this to occur? Really depends on the nature of the data and how often it gets created, updated or removed. However, in this particular example, I'm just going to run it manually one time by clicking Run Classification With All Rules and we can leave it Run in the background or we can choose to Wait for classification to complete. I'll choose that, Wait for classification to complete and I'll click Okay. It's currently running the classification.

 

Now what it will do is it will open up a Classification Report in a web browser for me. So I've got the host name, I've got the scope of the path where searched for something. Then I've got some statistic visuals here like charts. It looks like there's one file. That's what we're seeing here. And towards the bottom, the file is actually called Customer_Details.txt. If we were to go into the file system and if we were, let's say to right click on Customer_Details and go to Properties, under the Classification tab, notice that Financial has automatically been set to Yes, FSRM has discovered what we told it to seek and then flagged it as being financial information. The only reason the Classification tab is showing up here, by the way, is because FSRM is installed on this Windows server. You won't see this Classification tab if that option is not installed.

 

In this demonstration, we're going to be focusing on Service Level Agreements, otherwise called SLAs, and also their relationship to Service Level Objectives, otherwise called SLOs. Actually, let's start with the service level objective. The service level objective, the word objective is part of it, focuses on how to ensure that a given service is reliable. As an example, that might be described as being a minimal amount of downtime over a given period of time, such as over a month, or with a certain type of agreement with the provider for technical support, a certain, a maximum amount of time before calls are returned for technical support. That type of thing is called a service level objective or SLO, and normally it's part of an SLA, a service level agreement.

 

Now, service level agreements do not have to be tied solely to cloud computing, but they are a part of cloud computing. Here in my browser, I've searched up AWS Service Level Agreements and gone to the page for this. Each cloud service has its own service level agreement. For example, ALEXA FOR BUSINESS versus the AMAZON API GATEWAY, all the way down to things like AMAZON ELASTIC COMPUTE CLOUD, otherwise called EC2. This means virtual machines that you deploy as infrastructure as a service.

 

What's the service level agreement here? So for the Monthly Uptime Percentage, it states here that if we have less than 99.99% of uptime within a one month period, but equal to or greater than 99.0% uptime, then as an Amazon Web Services customer, you will receive a 10% service credit on your next bill. But if we end up, let's say, with less than 95.0% uptime over a month, then we get a 100% service credit percentage against our next bill. So of course, these details will vary in some cases across the board for different types of services. And this is just Amazon Web services. You get the same types of things for Google Cloud, IBM Cloud, Alibaba Cloud, and of course here Microsoft Azure, where we have Service Level Agreements for Online Services. [Video description begins] The Licensing Documents window is open in Microsoft Azure. There is a list of hyperlinked resources along with their details like Type, Date and Language in a tabular format. [Video description ends]

 

So I'll click on the link for the latest version of that and I'll download the file and that'll go ahead and open that file. In this case, it's a Microsoft Word document. So I can scroll down through it manually, but I can also search for something specific. For example, if I search for app service, where app service is really all about hosting web applications in the Azure Cloud, the SLA for app services gives me a definition of terms like Deployment Minutes, Maximum Available Minutes, and it says here it could be a web app, but it could also be a mobile app that we've developed in the Azure Cloud, an API app, a Logic app and so on. Then it defines what Downtime means in this context. This would be the total accumulated deployment minutes, which is defined up above across all apps within a given subscription during which the app is unavailable. It also shows me how the uptime percentage is calculated.

 

And then we get to the meat and potatoes of this SLA for this cloud service. If we have less than 95% uptime, then we get a 100% service credit. So similar in nature to what we saw with Amazon Web Services. Now, this is going to be absolutely crucial for organizations that will actually rely on IT services running in a public cloud environment.

 

Organizations need to know they can be assured that the services will be available when they need them. For something that's absolutely mission critical, maybe the possibility of something being available less than 95% of the time is unacceptable for things like emergency services. So in that case, organizations might opt to do something else, maybe run something in-house on their own platforms instead of doing it in the cloud. But from a security perspective, this is important because it deals with the availability side of security, making sure services and data are available when needed, and we have to always proactively plan for inevitable disruptions such as those that might also be caused by malicious actors.