Gain in-depth knowledge for passing your exam with Exam-Labs CAS-004: CompTIA Advanced Security Practitioner (CASP+) CAS-004 certification video training course. The most trusted and reliable name for studying and passing with VCE files which include CompTIA CASP+ CAS-004 practice test questions and answers, study guide and exam practice test questions. Unlike any other CAS-004: CompTIA Advanced Security Practitioner (CASP+) CAS-004 video training course for your certification exam.

Risk Management (Domain 4)

8. When Risk Management Fails (OBJ. 4.1)

Welcome to our first case study. In this course, I'm going to pick an event that happened back in 2017. This is all about what happens when risk management fails. stripped directly from the headlines. Here we are. Amazon had a massive Amazon Web Services outage this month that was caused by human error. That was the whole source of it. It was an inept administrator. Somebody basically made a mistake. One incorrect command was entered, and large portions of the Internet went down and started suffering because of it. Let's take a look at this a little bit more in depth. This happened back in February of 2017. A routine maintenance action was being conducted by the Amazon Web Services employee. As a result of an incorrect command being inputted, he had an accident and hundreds of websites were taken offline. Big-name companies like Slack and Netflix and others rely on Amazon Web Services, and they went down because of this. The technician was utilising a standard operating procedure that he had done hundreds of times before. He wanted to take a small number of servers offline, but he put in the command incorrectly. When he did that, the entire US east One region went down. And this is based out of Virginia; it hosts tonnes of large websites. Now, there are lots of servers here and lots of cloud services that all went down because of one incorrect command. As he was trying to fix the billing system, the employees were debugging an issue with the billing system, and they accidentally took more servers offline than they needed to. This caused a cascading effect and eventually started a domino effect that took down two other servers and then two other subsystems. It then went on and on and on, and it rolled from one to the next to the next. And looking back, we can go there's.all these things that we should have done to prevent this. But at the time, they were just following their standard procedures the way they've always done their business. Now, this was a failure of internal processes, and it was an accidental threat. They weren't doing it purposely. This wasn't an insider who did it maliciously. It wasn't an inside threat. It was just an accident. They removed a significant portion of the capacity they had, which caused each of these subsystems to start requiring a full restart. When this happened, the subsystems started restarting. There were things like S Three, which is storage buckets on Amazon, and they were unable to provide the service requests anymore because they became overwhelmed. because the S-3 went down. This started causing other AWS services in the East region to start going down as well. S-series consoles are now being phased out. Then the elastic computing went down. Then Elastic Beanstalk went down, and then Lambda went down, and all of these services started becoming impacted. This then impacted Amazon's customers because everyone is relying on these Amazon services. When we look at this case study, what happened? What concepts do you see here being illustrated? Well, first we had an accidental threat. Somebody made a mistake, and it hurt the system. We had employee risk management failures. Maybe the staff wasn't properly trained, and they didn't have the up-to-date skills they needed. Maybe this was one of the risks that was assumed. They had operational risk here because of internal failure from an internal process and people causing large testing errors that weren't accounted for inside of their own risk management. Now, as you can imagine, it was never supposed to happen this way. However, all of these bad things lined up just perfectly, and it all went haywire pretty darn fast. It took hours for Amazon to get this back online, and lots of their customers were ultimately affected by the outage. It was a really bad day to be an AWSweb admission down there in the East region, I'm sure. And this shows why it's important for us to do proper risk management. If we'd had all of these things looked at through a risk management lens, we might have put better mitigations in place or avoided some of these risks. And everything fell into place perfectly for this major outage.

Policies and Frameworks (Domain 4)

1. Policies and Frameworks (OBJ. 4.1 & 4.3)

In this section of the course, we're going to cover the various policies and frameworks that may be important to your organisation when dealing with governance, risk, and compliance. In this section, we're going to be focused on two objectives. Objective four one given a set ofrequirements, apply the appropriate risk strategy strategies. And objective four. Three explain compliance, frameworks, and legal considerations and their organisational impact. As we move through this section, we're going to start out covering policies, which are a type of administrative control. This includes policies and security practises like the separation of duties, job rotation, mandatory vacation, lease privilege, employment and termination procedures, training and awareness for users, and auditing requirements and their frequency. Next we're going to dive into some frameworks, regulations, and standards. things like Savsa, COVID, IDOL, NIST, CMMI, GDPR, PCI, DSS, Copa, and many others. Then we're going to discuss contracts and agreements,things like SLAs, MSAs, NDAs, MoUs, Isas, VPAs,operational level agreements, and privacy level agreements. Finally, we're going to dig into some legalconsiderations and how you can integrate diverse industriesduring a merger or acquisition, because this isone of the times that information security professionalsreally need to be intimately involved with thebusiness side of an organization. As you can see, there is a lot for us to cover in terms of policies and frameworks. So let's get started.

2. Policies (OBJ. 4.1)

Previously, we discussed the importance of administrative controls. Now, these are the types of controls that we use to create policies that are focused on reducing security risk within our organization. This includes policies and security practises like the separation of duties, job rotation, mandatory vacation, location lease privilege, employment and termination procedures, training and awareness for our users, and auditing requirements and their frequencies. Now, in this lesson, we're going to dive a little bit deeper into all of these different concepts. First, we have policies that are focused on the separation of duties. Now, separation of duties is a preventative administrative control, and it's one that should be considered whenever we draught up our organisational, authentication, and authorization policies. Separation of duties is designed to prevent fraud and abuse by distributing various tasks and approval authorities across numerous different users. For example, let's say you work in the accounting department. You can't go and request a check be sent to an employee and also approve that same request. We do this to prevent fraud because two users now have to work together to steal money from our organization. In the cybersecurity world, a good example of this is when one administrator has the rights to create backups of a given server, but another administrator has the proper rights to do the restoration of those backed-up files. Any function in an organisation that could be deemed high risk should employ proper separation of duties. For example, if you've ever seen a war movie in which the military is attempting to launch a missile, such as Crimson Tide, you'll notice that two people each have a different physical key and are both required to use that key to launch the missile. This specific type of separation of duties is known as dual control. Now, another type of separation of duties is called split knowledge. This is when two people each have half of the knowledge required to do something. For example, let's imagine I have a box that holds my family's super secret recipe in it.Now, I can lock up that box with two different combination locks. I know the combination to one of those locks, and my wife might know the combination to the other. We can't open the box by ourselves because we only have half of the information. We each only know one combination. So we have to work together to unlock that box and get the recipe out. In the cybersecurity world, we can accomplish this using encryption. We'll take the key, break it up into two pieces, and give each half of that key to a different administrator. Second, we have job rotation. Job rotation is another administrative control. With job rotation, different users are trained to perform tasks of the same position, and this helps prevent and identify fraud that could occur if only one employee had that job. Basically, if multiple people know how to perform a certain job, then it's more likely that somebody can detect unusual activity than if there's only a single person who does that job by themselves. Besides the security benefits of protecting against fraud and abuse, job rotation also provides a great opportunity to cross-train your employees and to develop trained personnel to back up the primary employee in case of an emergency. Job rotation is definitely a control to consider when you're writing your organization's security policy. Third, we have mandatory vacation policies. Now, this is the other side of job rotations. With mandatory vacations, we require that every employee take a vacation at some point during the year. Again, this makes them have to take a vacation, and it forces someone else to come in and do their job functions for them. Once somebody else is performing those job functions while the other employees are on vacation, they may uncover some kind of unusual activity such as fraud or abuse that has to be looked into further. Now, in addition to the security benefits of protecting against fraud and abuse, job rotation and mandatory vacations also provide us with the ability to cross-train our employees and develop trained personnel to back up the primary employee in case of an emergency or if that employee quits their position. Fourth, we have policies that are focused on the use of lease privilege. Lease privilege is the concept of providing users or services with the lowest level of access required to perform their job functions. Our goal here is to keep the overall access rights to all the systems and servers at the lowest possible level. And we want to prevent users from having privileges that they simply don't need. To properly implement lease privilege, we need to understand each user's job functions and restrict their ability to be identified. Level of Access This can be quite time-consuming to set up, but it is well worth it from a security perspective. A classic example of lease privilege is providing two accounts to an IT administrator. One of these is their admin account, and the other one is their normal user account. The administrator should only log into their admin account to do their admin functions, but they should use their normal account for all of their email, web browsing, and other business-related functions. Another facet of lease privilege is the concept of "need to know." While every staffer may have a similar account level, such as a standard desktop user account, not every user needs access to every single file. Therefore, we need to implement proper access controls for different files, folders, and resources using technical access controls. For example, if somebody is working in sales, they probably don't need access to the files created by human resources because they contain every employee's personally identifiable information. Or somebody who's working in accounting probably doesn't need access to a large format printer because that's going to be used to print out banners by our marketing department. Instead, the easiest method of using lease privilege is to assign your users into groups based on their work roles, and then you assign these groups the rights needed for those specific job functions. Remember, if a user gets moved to a new job function, we need to ensure that we remove their old access. Otherwise, we could get privileged creep, and they'll retain their old access and their new access, giving them additional privileges that they shouldn't have. Fifth, we have employment and termination procedures. These policies are considered administrative controls, and they're focused on what to do when you hire or fire an employee. When we consider this, we're talking specifically about the security of the information system and not about the human resource portion of this process. But we still need to consult the human resource team. when developing this part of our organisational security policy. Organizations need to consider how personnel are going to be screened and their backgrounds checked for the positions they're hiring for. How are these candidates going to be hired, how are they going to be onboarded, and how are they going to be terminated and offboarded when you're done with them? When screening personnel, many organisations consider a candidate's criminal background, their credit history, their work history, their educational background, their certifications and licenses, and even conduct drug tests. These various needs are all going to be decided by human resources, but our organization's security policy should also address some of these areas if they are pertinent to your business model. When you're hiring personnel, you need to make sure you're requiring them to sign all the appropriate documents, including privacy statements and nondisclosure agreements. Then the employee should undergo mandatory cyber security training and processing, which will end with the employee being given access to the network and receiving their username, their password, and their hardware authentication token. If you're using multifactor authentication from a physical security standpoint, the new employee also needs to get their building access identification badge and access to their work center. Now, while employees are generally very cooperative during the hiring and onboarding process, they may not be as cooperative if you're terminating them. If termination is friendly, such as the employee leaving your organisation for a better position elsewhere, they're likely going to be cooperative, and they'll turn in their user access, their hardware tokens, their identification badge, and even conduct an exit interview. During this type of offboarding process, it is also important to remove their access from the network and disable their accounts. Now, if the termination is unfriendly, such as when you have to fire an employee, then their network access and physical access should be removed immediately. The employee should also be escorted out of your building by security, ensuring they're not taking any company resources, data, or property with them as they're leaving. We provide training and awareness for our users. Now, there are three different terms used for user training and awareness in your exam, and each one has a slightly different meaning. These include security awareness training, security training, and security education. Security Awareness Training is used to reinforce for users the importance of their help in securing the organization's valuable resources. This includes things like educating users on the current threats facing the organisation as well as what to do in the case of an event or an incident. All employees should attend security awareness training at least once a year. Studies have shown that this is by far the best return on investment that a company can make into their security policy, as users are one of the largest vulnerabilities in most organisational networks. The second type of training we have is known as security training, and this is used to teach the organization's personnel the skills they need to perform their job in a more secure manner. This training is usually focused on the IT staff and administrators as well as your other technical employees. For example, if you're a system administrator and you want to train to learn the most secure way to set up a user account or to create a password, this is a form of security training. This type of training is very procedure-based and specific to your network configuration. Now, security education is our third type. Security education is a more general type of training by nature. Now, this course, for example, is security education for cybersecurity professionals who are looking to gain more expertise so they can better manage the security programmes at their organizations. This type of education is less procedural and more generalised for all networks and all organizations as opposed to being focused directly on your particular network or your particular industry. Now, when you conduct security awareness training, you need to develop that based on the intended audience, and there may be multiple versions of this training. For example, this training might consider the risks faced by each level of the organization, such as a manager who's facing different risks than somebody who works in accounting or someone who works in IT. All of them have different needs. Now, specialised training can be developed for our organisation based on the ethical laws, regulations, and business models that we have as well. This type of training for management should include a discussion of policies, guidelines, and standards, whereas when we do it for technical staff, they may be given training on how to best identify and respond to an attack. Also, whenever your organisation conducts a security audit, you need to take the types of issues that are found there and feed those back into your training program. Let's say you just did a penetration test and you found that a lot of your employees are clicking on links in phishing emails. Now, you need to start training your users on how to recognise phishing and make that part of your training curriculum if they have found that employees are using weak passwords. For example, you need to train your employees on how to create more secure passwords. We want to feed all that back into your training. The 7th thing we need to talk about is auditing requirements and their frequency. Now, auditing and reporting are essential items for our organization's security, and they need to be discussed within our security policies. What are we going to audit? How is it going to be reported to management? And how often are we going to do those? Audits are all going to be detailed inside our policy and are things we need to fully think about. Audits may be required based on contractual obligations. For example, if you process credit cards, then you must follow the requirements for PCI DSS, which requires we conduct an external audit of our systems at least once per year. Now, if you're in the federal government, then FISMA is going to apply to you, and it recommends you audit your systems at least annually, too. Unfortunately, audits are only as useful as our configurations. And this is why it's important to know what we're going to audit, what the scope of that will be, and to what level. If we try to log and audit everything, we're going to drown in a sea of logs. And this makes it very likely that we'll miss something important. Conversely, if we don't log and audit enough things, then we might miss something that's really important. So there is a balancing act here. Now, this may sound like a lose-lose scenario, and all hope is lost, but that's not true. With time, we can find the appropriate balance between auditing important items and neglecting others, so we don't bog down our systems and our staff with unnecessary or redundant auditing. Over time, we're going to develop patterns of behavior, and we can begin to use those to determine what is normal and what is abnormal for our organization. And this helps us fine-tune our auditing. For example, should we be concerned if a user tries to log in and they use the wrong password? Well, probably not, because the user may have just typed it in incorrectly. But should you be notified if they try to log in three times with the incorrect password? Probably because most users aren't going to make the same mistake three times. In this case, our system may lock the user out and log that issue based on our lockout policy. This is the key to good auditing: deciding what the threshold is going to be that makes an event worthy of being reported in an audit. So, in summary, remember that we can use various policies and security practises to help mitigate our risk. These become a form of administrative control for us, and they're things like separation of duties, job rotation, mandatory vacation, lease privilege, employment and termination procedures, and training and awareness for our users when you consider your auditing requirements in their frequency. Remember, this is a form of detective control within our organisation that we use too.

3. Frameworks (OBJ. 4.1)

Its governance is used to provide a comprehensive security management framework for your organisation to build upon. These frameworks include policies, standards, baseline guidelines, procedures, and information classification and life cycles. Now, policies are used to state the role of security in an organisation and to establish the desired end state of the security program. This is going to be provided by senior management, and it clarifies which level in the organisation will enforce security and to what categories we're going to apply. Controls. Now, policies are going to be very broad, and they provide a basic foundation upon which our standards, baselines, guidelines, and procedures will be built. Security policies are built to fill one of three levels. It can be organizational, system-specific, or issue specific.Organizational security policies provide a general direction and goals, a framework to meet the business goals, and a way to define the roles, responsibilities, and terms in your organization. System-specific policies address the security needs of a specific technology, application, network, or computer system. System-specific policies are much more technical, and they're focused on protecting a certain piece or system of technology. Now, issue-specific policies are built to address a specific security issue, such as email privacy, employee termination procedures, or other certain issues. Now, policies in general are further going to be separated into one of three categories. They can be regulatory, advisory, or informative. A regulatory policy addresses mandatory standards and laws that affect our organization. Advisory policies provide guidance for acceptable activities, and the most common of these would be your AUP or acceptable use policy, which companies use to provide their employees with a list of things you can and cannot do on their network. Informative policies will focus on a certain topic, and they're designed to be educational in nature. For example, a company may wish to provide its employees with an informative policy on the use of social media outside of business hours. Standards are used to implement a policy inside an organization. These may include things like mandatory actions, steps, or rules that are needed in order to achieve the desired level of security. Baselines are created as reference points that are documented for use as a method of comparison during a future analysis. Now, for example, if we receive a brand new server, our team can configure it as securely as possible and then use that configuration as the baseline against which other servers of the same type may be compared later on. Guidelines are not required actions, but rather recommended ones. Guidelines are flexible in nature, allowing for exceptions and allowances when a unique situation occurs. Procedures are detailed step-by-step instructions that are created to ensure personnel can perform a given action. These procedures are where the high-level policies are going to be transferred through standards and guidelines into actionable steps. For example, your service desk should have a procedure for how they create new accounts. That way it's going to encompass all the security-related policies, standards, and guidelines for your front-line employees to follow in one simple guide. Now, to aid in the development of these policies, standards, guidelines, and procedures, some organisations look to enterprise security architecture frameworks. For the purpose of this lesson, we're going to take a quick look at four of them SABSA, COBIT, idle, and NIST Special Publication 853. First, we have SAVSA, the Sherwood Applied Business Security Architecture. And this is a risk-driven architecture. It attempts to consider the security problem by examining the what, where, when, why, who, and how the problem intersects with Savsa's six layers. These are operational components: physical, logical, conceptual, and contextual. Second, we have COBIT. COBIT stands for "Control Objectives for Information and Related Technology," and it's a security control development framework that divides it into four domains. We have planned and organised to acquire, implement, deliver, and support, monitor, and evaluate Each of these domains is then broken down into one of 34 other processes, and it is very similar in framework to other things like idle, PMI, ISO, and TOGAF. Third, we have Idle, which is an IT service management framework. This framework is by far the most popular service management framework in the world. Now, while it's not strictly a security framework like SAVSA or, to a lesser extent, COBIT, Idle does include information security as one of its 34 practices. Within its framework, idle is heavily used by the IT operations side of most businesses, works well with agile development, and blends wonderfully into a DevOps or dev stack ops environment. If you're working at a Fortune 500 company, it would be very unusual if you found yourself not using the Idle framework. For that reason, I actually teach a full line of Idle certification courses to help you earn your certifications as an Idle Four Foundation Certified Professional, an Idle Managing Professional, or an Idle Strategic Leader. If you're interested in learning more about those, just visit my [email protected], we have the NIST Special Publication 853, which is a security controls framework that was developed by the US Department of Commerce. Each control is placed into one of three classes. They can be technical, operational, or management. Each of these three classes then contains numerous security controls beneath it. If you're working for a government agency, you're likely going to be working within the framework of NIST Special Publication 853.

4. Regulations (OBJ. 4.3)

When developing a security policy, it's always a good idea to bring in the experts from the legal, human resource, and public affairs departments, as well as any other key stakeholders. There are numerous laws and regulations that our organisation may be subject to, and these professionals can assist us in ensuring our policy meets or exceeds all the various legal and regulatory requirements. For the exam, you need to be familiar with various laws, regulations, and standards that may apply to your organization. To be successful on the exam, you need to ensure that you understand how each one might affect your organisation based on its industry or the type of information you process. In this video, we're going to discuss a bunch of different regulations. Now, you don't have to memorise everything I'm about to say, but you should be able to do some keyword association. For example, if I say HIPAA, you should realise this affects health data. And so if you work at a doctor's office, hospital, or health insurance company, HIPAA is going to affect you. So let's start talking about laws and regulations. And first, we're going to start off with HIPAA. the Health Insurance Portability and Accountability Act. This affects healthcare providers, facilities, insurance companies, and medical data clearinghouses. If we're processing or storing medical data, it's likely affected by HIPAA. Now, it's also enforced by the Department of Health and Human Services, and it provides standards and procedures for the storing, using, and transmitting of medical information and healthcare data. The Healthcare and Education Reconciliation Act of 2010 affects both healthcare and educational organisations by increasing some of the security measures necessary to further protect healthcare information. Next we have Sarbanes, Oxley, or socks. This was a law that was enacted by Congress under the name "Public Company Accounting Reform and Investor Protection Act of 2002." But you almost always hear people call it Sarbanes Oxley.It was named after two lead centres who sponsored this bill and fought for it to become a law. Now, if your organisation is a publicly traded US corporation, it's affected by this regulation, and it must follow certain accounting methods and financial reporting. Failure to follow Sarbanes Oxley can't even result in your senior leadership getting jail time for noncompliance. So it's very serious; you follow it. Next, we have Graham Leach. Blylie, Act, or GLBA. And this was the Gram Leach Blylie Act of 1099. That affects banks, mortgage companies, loan offices, insurance companies, investment companies, and credit card providers. Basically, it affects most financial institutions. The GLBA has a direct impact on the security of personally identifiable information, allows for the sharing of financial information with third parties, and provides guidelines for securing that financial information. Next, we have the Federal Information Security Management Act of 2002, known as FISMA, and this only affects federal agencies. Each agency is required to develop, document, and implement an agency-wide information system security program. FISMA's goal is to create a more secure network across the whole of the US government prior to this act. There was a Computer Security Act of 1987, but FISMA replaced it and added some more stringent requirements for us in the federal government. Another federally focused regulation is the Federal Privacy Act of 1974, which affects any US government computer system that collects, stores, uses, or disseminates personally identifiable information. Note that the Federal Privacy Act only places requirements directly on the federal government agencies as they collect the information. It does not apply to private corporations. For example, my company, Dion Training, is a private company, so we don't have to follow the rules of the Federal Privacy Act because we're not the US government or one of their agencies. Next, we have FERPA, or the Family Education Rights and Privacy Act, and this is a federal law that protects the privacy of student education records. This regulation applies to all schools that receive funds from the US Department of Education, including colleges and universities in the United States, both public and private. Next, we have the Computer Fraud and Abuse Act of 1986. This act defines hacking of what is referred to as protected computers, which includes computers that hold financial records or government information. Based on this very wide definition and the increased use of many of our devices, even a smartphone could be protected under this law. If our organisation conducts penetration testing, then we want to make sure our scope of work and authority are adequate to ensure that we don't run afoul of this regulation. Next, we have the Economic Espionage Act of 1996, and this affects organisations with trade secrets and anyone who tries to use encryption for criminal activities. Under this act, even intangible trade secrets, like certain processes and procedures, can be protected. If anyone tries to steal our trade secrets, they could be prosecuted under this federal law. Next, we have COPA, or the Children's Online Privacy Protection Act. Now, COPA imposes certain requirements on website owners and online services that are directed to children under 13 years of age, as well as other websites or online services that have actual knowledge that they're collecting personal information online from a child under 13 years of age. So let's pretend you're running a website like Facebook and are collecting data on all of your users. You would be subject to COPA. Now, big tech companies like Facebook try to say that they shouldn't fall under this law all the time because they're not targeting people under 13. In fact, when you try to create a regular Facebook account, it asks for your birthday to check your age, and if you're under 13, it won't let you create the account without parental consent. But this is really just leading to kids lying about their age and selecting a year a little bit older than what they are, so they can bypass that age check and create an account. Anyway, with COPA, the federal government can actually go after Facebook for this type of thing. And with COPA, the fines can come from the Federal Trade Commission, or the FTC, at $40,000 per violation. Now, if you're a smaller operator or a small business, this could bankrupt you. But if you're a big company like Facebook or Google or TikTok, it's not even a blip on your radar. Copa is thus a contentious topic. Now, this happens because it puts a lot of extra requirements on companies that are trying to serve younger markets with educational content. So keep in mind that if you're dealing with a product that may be used by younger users, copa can and will affect you. Now, everything we just discussed so far is based on US laws and regulations. But what about organisations that aren't dominating in the United States? Are there any regulations they need to be concerned with? Well, simply put, yes, there are a tonne of them. But for the exam, they're only going to look at a few of these. First, we have the Personal Information Protection and Electronic Documents Act. This is a Canadian law that's focused on private sector organizations. This law requires organisations to obtain consent when they collect, use, or disclose personally identifiable information. And they have to have clear, understandable, and readily available policies for their customers to read. Essentially, it was developed to ease the concerns of the European Union about the security of their citizens' information when they did business with Canadian companies. Next, we have GDPR, or the General Data Protection Regulation, and this is one of the biggest and best requirements in terms of consumer privacy protections. GDPR is a law created by the European Union. Now, GDPR states that personal data cannot be collected, processed, or retained without the individual's informed consent. Now, I talk about informed consent. This means the data must be collected and processed only for the stated purpose, and that purpose must be clearly described to the user in plain language, not in legal mumbo jumbo. So if you go to a website and they say, "Please enter your name, your email, and your home address so we can sell you this product and deliver it to your house," that is their stated purpose. That doesn't mean they can now send you junkmail every single week to your home address to try to get you to buy more stuff, unless that was part of their privacy policy that you accepted in clear language when you checked out. Basically, GDPR says that they have to be upfront with this and also provides a provision in the law to ensure a user has the right to withdraw their consent at any time. It also gives them the ability to inspect, amend, or erase any data that is held about them in the organization's database. This is often referred to as the right to be forgotten. Now, if you're a resident and citizen of the European Union, you can call up the company or fill out the form and say, "I want you to forget everything you've ever known about me," and they have to go in and scrub their database from all the information they have on you. This is part of that law. So if you're a European citizen, GDPR gives you a lot more protections. But if you're an American, GDP doesn't really apply to you, and you don't get those same rights. So if I'm sitting in Florida or Puerto Rico, I can't tell the company to forget everything they know about me. That's not something that companies are required to do for me. I can request it, but they are not required by law to actually do it.

Pay a fraction of the cost to study with Exam-Labs CAS-004: CompTIA Advanced Security Practitioner (CASP+) CAS-004 certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including CAS-004: CompTIA Advanced Security Practitioner (CASP+) CAS-004 certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide