Industries have different requirements and compliance standards. Learn about several common requirements that may apply to your data.
- Many times the policies that we create are actually created in order to help us comply with regulations and guidelines. Now, a regulation is a requirement usually imposed by a government that you might be operating under. A regulation example would be the HIPAA, healthcare regulations, in the United States. A guideline is something that you don't necessarily have to comply with, but it's highly recommended and if there is a security incident and it's proven that you did not comply with the guideline, you may fail to be able to do business in the same way in the future. An example of that would be PCI-DSS, that's the Payment Card Industry Data Security Standard, and what it does is defines how to set up a network so that you can receive payment card processing. If you don't comply with it and there's an incident, you might be banned from receiving certain credit cards in the future. If you were in compliance with it, then you're a little safer. With HIPAA, and I'm in the healthcare industry, I simply have to comply. So I'm going to start here by looking at an example of compliance with regulations and then we'll talk a little bit about some other standards and compliance issues. So first of all, we're going to look here at AWS and the HIPAA standard guideline recommendations that they have for AWS deployments. So you can see, first of all, they give you an overview of HIPAA, what it actually is and why you might care about it. It's the Health Insurance Portability and Accountability Act of 1996 and it requires that you protect personal health information, okay? They give you suggestions with a Frequently Asked Questions area about what is available to you for HIPAA and understanding it, and then they answer the question, "Is AWS HIPAA certified?" And it says, "Well, there is no HIPAA certification "for a cloud service provider such as AWS. "In order to meet the HIPAA requirements "applicable to our operating model, "AWS aligns our HIPAA risk management program "with FedRAMP and NIST 800-53, "which are higher security standards "that map to the HIPAA Security Rule." In other words what AWS is saying is when it comes to the cloud, there's really not a standard for how to do it. So what we did is we said, "Well, what would HIPAA require "in the real world and what can we do in the cloud "that's even more stringent?" And that's what they did to give HIPAA regulations. Now, further down in this document they do give you extra information on how to go about deploying solutions in the AWS cloud in compliance with HIPAA regulations. You'll find similar documentation at Azure and GCP, and IBM Cloud, and other cloud service providers as well. So check with your service provider, see how they recommend that you comply with whatever the regulation is that you're concerned about. It might not be HIPAA, it might Sarbanes-Oxley, it could be something else. So make sure you're in the compliance. Now let's talk a little bit more about the issue of compliance and audit requirements. First of all, we have the issue of laws and regulations. So there are privacy laws, like HIPAA, which guarantees the protection of personal health information. There are other laws that may require the protection of any personally identifiable information, PII, and so we need to make sure we're in compliance with those. There could be data retention laws. This is particularly of importance to financial industry organizations where you have to keep your data for a period of time for audit procedures and so forth. Of course, there are specific healthcare information laws, as we've seen, and there are payment processing guidelines. I talked about PCI-DSS as one example of that. Now, one of the key things that you can do in order to help you come into compliance is implement procedures in your company for data classification. Data classification is a common compliance requirement. Meaning that, in order to be able to come into compliance, our data must be classified so that we can say, "Well, your requirement is that data "of a certain classification be encrypted, for example, "and all of our data in that classification is encrypted." But if you're not using data classification, you cannot come into compliance. So data classification enables authorization. You can do the right authorization because your data's classified. User A can access Top Secret, User B cannot, right? So that's authorization enabled by classification. Confidentiality can be enabled by classification because we say anything that's Top Secret must be encrypted at rest and in transit. So therefore, we have action that can be taken because it's classified. It also enables lifecycle management. Any data older than five years that is not Top Secret must be destroyed if it has not been accessed by anyone in the last 12 months. So that might be a policy that you have for data destruction. And then examples of classification models would be things like Top Secret, Secret, Unclassified. The point is that you could come up with your own, you can call it Most Important, Moderately Important, Least Important, it doesn't matter what you call the labels. What matters is that those labels work for your organization and that those labels are linked appropriately to authorization, authentication, encryption techniques, and so forth that help to secure your data.
This Total Seminars course covers the exam certification topics. For information on additional study resources—including practice tests, lab simulations, books, and discounted exam vouchers—visit totalsem.com/linkedin. LinkedIn Learning members receive special pricing.
This course was created by Total Seminars. We are pleased to offer this training in our library.
We are a CompTIA Partner. As such, we are able to offer CompTIA exam vouchers at a 10% discount. For more information on how to obtain this discount, please download these PDF instructions.