Pass Your CompTIA CASP+ CAS-004 Exam Easy!

CompTIA CAS-004 CompTIA Advanced Security Practitioner (CASP+) CAS-004 exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. CompTIA CAS-004 CompTIA Advanced Security Practitioner (CASP+) CAS-004 exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the CompTIA CASP+ CAS-004 certification exam dumps & CompTIA CASP+ CAS-004 practice test questions in vce format.

Policies and Frameworks (Domain 4)

5. Standards (OBJ. 4.3)

In this video, we're going to talk about standards. Now, standards don't have the same enforcement as laws and regulations, but instead they're created for specific industries to be followed as a best practice. Now, some standards, though, do have penalties associated with noncompliance, and that makes them extremely important. One such standard is PCI DSS, or the payment card industry data security standard. Now, PCI DSS is an agreement that any organisation that collects, stores, or processes credit card customer information has to abide by. This is not actually a law or regulation, but instead it's a contractual agreement and standard that must be followed if the organisation wants to handle credit card transactions. So, to prove compliance with the requirements, an organisation must receive an external audit at least once a year. If you fail to comply with these standards, you can lose your ability to take credit cards, and for an e-commerce company, that would completely demolish your ability to do business. So while PCI DSS isn't a law or regulation, it is really important that you follow it closely and make sure you don't run astray. Now, the other standards we're going to discuss don't necessarily have that level of strict compliance required, but instead become more of a best practise for you to follow. These include things like ISO, CMI, NIST CC, and CSA STAR. ISO, or the International Organization for Standardization, is a group of standards created as a series of best practises across multiple industries. Each set of standards is labelled with an ISO number and a series number. For example, the ISO 27,000 series refers to the information system security management overview. The ISO 27,001 series refers to how to manage information security, and ISO 27,002 is going to refer to the different information security controls that you could use. As you look at the entire ISO 27,000 series, there are about 60 different standards for different parts of an organization's.its network, its policies, and its controls. CMI, or the Capability Maturity Model Integration, is a standard model that focuses on processes and behaviours that are used during the development of software, products, and services within your organization. If you're working in an organisation that builds new processes, services, and systems, you may choose to implement the Capability Maturity Model Integration as one of your organisational standards. Now many of us Government contracts issued to software development companies require that CMI be used when you're developing things in your organization. CMI is going to categorise an organisation with a certain maturity level anywhere from one to five. One represents immaturity, and five represents maturity. Now, this doesn't mean that every organisation needs to aim to be a five, though. For example, the government contract may specify that they only work with organisations that are at levels three, four, or five. Now, if you're level three, for example, you have a defined process, whereas a level four has a quantitatively managed process, and level five is an optimising stage focused on additional continual ess, and level fiveWe have NIST. NIST is the National Institute of Standards and Technology. And this is a U.S. agency. Under the US Department of Commerce, NIST supplies industry, academia, government, and other users with over 1300 different standards that can be used. Now, as an information security professional, though, most of what you're going to be concerned with is in the NIST 800 Series publications. For example, NIST Special Publication 853 is used for security and privacy controls for federal information systems and organizations. This publication has over 800 controls listed across 18 areas for you to consider in your risk management framework. NIST also has the NIST Cybersecurity Framework, called the CSF, and it was derived from NIST 853 It's written more in business terms, which makes it a lot easier to understand and utilize. Now, NIST also has a privacy framework that you can use that's going to help you, as an organisation, comply with different privacy regulations like GDPR. Next, we need to talk about common criteria, or CC. Common Criteria is a set of standards in which computer system users can specify their security, functional, and assurance requirements for a given system. This essentially allows an organisation to determine the different security levels they require based on different protection profiles. Think about it this way There's a common set of standards against which all products can be categorized, and it's going to let you pick which products you want to use based on their Common Criteria levels. Just like when you go to the movies, you're going to choose a PG or an R movie. It's kind of like that. Now, these levels are called evaluation assurance levels, or EALs. The EALs go from EAL One all the way up to EAL Seven, with seven being the highest level of assurance. So for example, if I look at a Windows 2008 server, it was assessed as an EAL Four Plus system. This is commonly accepted as good enough for most users' IT systems. Now, because it's an EAL Four system, it is methodically designed, tested, and renewed. On the other hand, the US Military's Joint Strike Fighter, or J-35 airplane, has an operating system with an EAL level of seven required.This means they require every possible mechanism for violating security to be anticipated and planned for in every part of the operating system used to run this aircraft. To be an EAL 7 under the Common Criteria, you have to have a formally verified design and be tested. Doing so, though, dramatically increases the cost of developing the software code that makes up the underlying operating system. So there is a trade-off in terms of cost and security. When you choose an EAL level, the higher you go, the more security you have. However, the costs will be significantly higher. Next, we have the Cloud Security Alliance for Security, Trust, Assurance, and Risk, or CSA star.This is a publicly accessible registry that documents the security and privacy controls that are provided by popular cloud computing offerings. The CSA Star is essentially a standard that the cloud providers are going to be compared against, and this allows organisations to better understand their security and compliance pressure when they're going through the principles of transparency, rigorous auditing, and comparing it against a common set of standards between different providers. Now, there are two levels of CSAStar, level one and level two. Level One requires a self assessment.This is where the organisations can submit to a security and privacy self-assessment against the cloud control matrix and the GDPR code of conduct. For level two, a third party audit is going to be conducted, and this is where the organisation is still evaluated against those same standards as level one. But it's being done by an outside, trusted third-party audit package that's going to give you better results through the process.

6. Contracts and Agreements (OBJ. 4.3)

In this lesson, we're going to talk about the various types of contracts and agreements that may be used in your organization. This includes SLAs, OLAs, MSAs, NDAs, MoUs, ISAS, BPAS, and privacy level agreements. First, let's talk about service level agreements, or SLAs. This agreement is concerned with the ability to support and respond to problems within a given time frame while providing the agreed-upon level of service to your end users. SLAs provide a written agreement for not only the security priorities, but also the operational priorities, responsibilities, guarantees, and warranties for a given service and its components. For example, in one of my previous organizations, we had an SLA with a supplier that would provide us with replacement devices within 4 hours of an outage. These agreements can help bring some level of predictability to an otherwise hard-to-predict area if your service provider ends up living up to the end of the agreement. Of course. Now, similar to an SLA, we have OLAs, which are operational level agreements. Now, an Ola is an internal agreement that provides details of the relationships involved between different departments of an organisation as they support each other's business functions. For example, you might have an operational-level agreement between the Information Technology Department and the Public Relations Department. It might say that the Public Relations Department is responsible for the daily updating of the website, but the IT department is responsible for the maintenance and backup of that web server. Next, we have a master service agreement, or MSA. Now, an MSA is a contract in which both parties agree to the terms that are going to govern their future agreements. Essentially, this is an agreement for future agreements, allowing the organisations involved to negotiate future contracts much more quickly because they just referenced the MSA. Now, an MSA, or Master Service Agreement, may sound strange at first if you've never used them, but they're extremely helpful in the IT world. This is where we can have an open-ended contract that we can negotiate upfront, and then when we need to execute that contract, we just create a statement of work for each specific project that comes up in the future. For example, in my company, I have a Master Service Agreement with one of the distribution platforms I use to host my courses. Now, we do a lot of business together, and it'd be really time-consuming to have to renegotiate a new contract for each and every course I develop. So instead, we developed one master service agreement, and each time I have a new project, I simply draught up the new statement of work with the details of how many hours of video it is or how many lessons it is, and then we move forward on the project. Using an MSA in this way makes our contracting process go much more smoothly. Now, nondisclosure agreements, or NDAs, are the next thing we need to cover. An NDA is signed between two parties and defines what data is considered confidential and cannot be shared outside of this relationship. NDAs are often used by organisations to protect their intellectual property. Now, some organisations even require their employees to sign an NDA as a form of non-competitive clause in their employment contract because they fear that the employee might take the information they learn from the organisation and then go off and start their own business. Now, when two companies are working together to develop a product, they can also use an NDA. This allows the two companies to know the data they can share and aids in the development of the product without the fear of the other company stealing their trade secrets. Now, NDAs don't prevent the data from actually being shared through some kind of technical control, but instead, this is an administrative control. This is because an NDA states the penalties for breaking the NDA, which may include things like fines, forfeiture of intellectual property rights, or even jail time in extreme circumstances. If you want to implement a technical control to prevent data from being shared, then you need to look at a Data Loss Prevention System, or DLP. Remember, NDAs are a binding agreement, and they can be upheld in the legal system under contract law. An MoU, or Memorandum of Understanding, is a nonbinding agreement, and this happens between two or more organisations to detail an intended common line of action. It is essentially a formal version of a gentleman's agreement because it's actually written down and signed by both parties. Now, an MoU is often referred to as a "letter of intent," a phrase often used within an organisation between two of its smaller internal divisions. For example, in one of my past organizations, I was the director of the service desk, and I provided service to several thousand employees. We had an MOU in place with one critical business unit that we would embed one of our field service technicians at their office so we could minimise the time to repair issues that might pop up at that location. Now, the MOU was not binding on my part, and at any time I could have cancelled the MOU or pulled my person back into my service desk, but it did provide some formality to the agreement made between that director and myself. Another example of an MOU in the cybersecurity world is when research consortiums are being developed. For example, the Alabama Cyber Research Consortium signed an MoU between seven different universities in Alabama that provides subject matter experts in cybersecurity to help develop new solutions for training and educating the next generation of cybercurity experts, as well as to conduct research and foster interuniversity cooperation in that field. Many times, you have multiple organisations that want to work together and share information between their networks. To do this, you need to create an interoperability agreement between all those organisations to allow information sharing to occur. Interoperability agreements are binding agreements, and they're used during normal operations. They're most commonly used between two smaller companies that are owned by one larger company. Now, when this happens, each company may be run separately, but they interconnect their networks together for a better utilisation of their resources and to share systems, servers, network connections, and software. People often confuse interoperability agreements with reciprocal agreements, but they're really not the same thing. An Interconnection Security Agreement, or ISA, is another type of agreement that focuses on connecting the systems of two organizations. Now, this is an agreement for the owners and operators of an IT system to document what technical controls each organisation has to meet for this interconnection to happen. If our organisations plan to connect our network to another organization, it's a good idea to ensure that we have an interconnection security agreement in place that details exactly what level of security each organisation needs to meet. A good example of an interconnection service agreement would be if an HVAC service provider wanted to connect their system diagnostic computer to your network to use it for transporting data back to their database. In this case, it may not make sense for the HVAC provider to create a separate network connection to transfer this little bit of data, so they want their data to ride on top of your network. But if we do that, we need to consider the security implications of that and what level of security we'll require before we allow them to connect their devices to our network. Now, a business partnership agreement, or BPA, is conducted between two business partners and establishes the conditions of that relationship. This includes stipulations like each person's responsibilities, as well as the revenue system and data sharing details. For example, in my company, I entered into a business partnership with another company to produce an online training course on wireless hacking techniques. In our agreement, it clearly stated that I was responsible for writing and filming the videos, but the partner was responsible for providing a file server for me to upload the content to once it was filmed. And then they took care of all the editing, the production, and the captioning. The agreement was detailed, so I got X percent of the sales and they kept Y percent of the sales. Now, when you use a BPA or business partnership agreement, you can also include language in that agreement about the security that each organisation has to maintain for that shared data or those shared resources. For example, if our organisation doesn't allow the use of external hard drives, we should specify that in the partnership agreement in order to give instructions on how files are going to be delivered to us. Because we can't do it through a hard drive, maybe we're going to do it through a cloud service provider or some other technical means. Next, we need to talk about privacy. Now, one of the largest privacy concerns today is how to collect, process, and store PII or personally identifiable information. Whether this data is on our employees or our customers, if we're collecting this type of data and using it, it's our corporate responsibility to provide adequate protections for it. For this reason, we need to generate a privacy-level agreement. This agreement or policy should address, at a minimum, what personally identifiable information can be shared, with whomit can be shared, and how we're going to transmit and exchange this type of data securely and confidentially, as well as how the owner of the information can opt out of the collection and use methods that we're going to be using. Now, the first step in protecting PII is to understand what constitutes this class of information. If a piece of data can be used either by itself or in combination with other pieces of data to uniquely identify a single person, it is considered PII. So what are some examples of PII? Well, this is things like a person's full name, their driver's licence number, their Social Security number, their date of birth, their place of birth, digital versions of the person's biometric features, their financial account numbers, their addresses, their email addresses, and even their social media names. All those things can be considered PII. Now, different countries and governments hold companies to different levels of protection, and they have different classifications for PII. So it is really important that you check with your legal team while you're redeveloping your security policies to ensure you're meeting any legislative or due care requirements. This includes ensuring that you're meeting any local, state, national, or international laws, or any standards, regarding the protection of sensitive and personal data about our customers or employees. When dealing with privacy level agreements, you're going to set out in contractual terms how any third parties you deal with are going to ensure the information they host for you is not seen by the wrong set of eyes. This is especially important when you're hosting your data in the cloud or you are the cloud host yourself. The privacy-level agreement should include detailed information about escalation procedures. if you have a privacy breach occur, such as how the breach is going to be reported, how quickly the report could be delivered to the customer, and who would have responsibility for contacting the appropriate authorities.

7. Legal Considerations (OBJ. 4.3)

In this lesson, we're going to discuss some various legal considerations that you need to think about inside your organization. This includes due diligence, due care, export controls, a legal hold, and eDiscovery. First, we have due diligence. Due diligence is defined as having escalated all reasonable measures to address a given risk. Due diligence is often confused by some people with due care. Due care is defined as having taken all reasonable actions to prevent security issues or to mitigate a possible security breach. The difference between these is that due diligence is all about information gathering, while due care is all about taking action. Let's dig a little bit deeper here by going over an example of due diligence and due care. Let's say that we want to outsource credit card processing for our new ecommerce website. We start by conducting due diligence, and we investigate all the different companies that offer this service. We look at their track records, their level of security, and the technologies involved. As part of our research, we find that credit card processors are now starting to use a new electronic chip to accept payments. Now, at this point, we've just gathered the information and taken no action. This is all due diligence. Now, this is where due care is going to come into play. We now are going to decide that instead of accepting the newer, safer chip, we're only going to accept the older magnetic strip type of credit cards because it's cheaper for us to do that. A few weeks go by, and there are no issues at all. But then a data breach occurs, and all the credit card numbers in our database get stolen. So an investigation is conducted, and it's determined that if we had accepted the new electronic chip cards, then the credit card numbers wouldn't have been stored in our database, and no loss would have occurred. Further, as it's now considered commonplace for us to use those new electronic cards, that means we are now deemed liable for the customer's losses because we didn't exercise due care. Next, let's talk about export controls. Export control regulations are federal laws that prohibit the unlicensed export of certain commodities or information for reasons of national security or trade protections of trade.Usually, something here is going to be subject to export control if it falls into one of three categories. First, the nature of the export has actual or potential military applications or economic protection issues. Second, the government has concerns over the destination, country, organization, or individual that you want to ship this thing to. Or third, the government has concerns about the declared or suspected end use or the end user of this export. All right, what does that have to do with you as a cybersecurity professional, and why should you really care? Well, some things that we use in the IT world are subject to export controls. For example, some forms of encryption software are subject to export controls. and since the information created or used by your organisation can also be subject to export controls. It's important to understand export controls when wetalk about an export, it isn't just materialobjects, but it can also be any oral,written, electronic, or visual disclosure. It can be a shipment, transfer, or transmissionof commodities technology, information, technical data assistance, orsoftware codes to anyone outside of the US. to a non-U.S. citizen or a foreign embassy or affiliate. Because of this, your organisation may need to validate that it's not subject to export controls when delivering content or technology to somebody outside the US. For example, my company has about 50% of its students outside the United States. So we have to ensure that the things we teach are not subject to export controls. For example, maybe I want to make a course on how to conduct penetration testing. And I developed some really cool tools that I'm going to give to all of my students. Well, if I have a student in Iran or North Korea or someplace that the United States considers a country of concern or where terrorists support the country, then I may not be able to include that tool or that information in my course because it would be illegal for me to give it to those people. This could be a dual-use technology under the laws of the United States as an export control. It says you can't give it to somebody because penetration tools can also be used for hacking. Now, another legal consideration you might come across is what's known as a legal hold. Now, a legal hold is a process that an organisation uses to preserve all forms of potentially relevant information when litigation or lawsuits are pending or reasonably anticipated. Usually the legal holders initiated by anotice or communication from a lawyer toanorganisation that suspends their normal dispositionor processing of records, such as backuptape, recycling, archiving, media off, or otherstorage and management of documents and information. A legal hold will be issued as a result of a current or anticipated litigation, audit, government investigation, or other such matter to avoid the destruction of evidence being destroyed.Now, if you remember when we talked about data retention and data destruction, we created policies around our normal timeframes for keeping data and information. But with the legal hold, all those data destruction timelines get bypassed because we must now keep all that data until the legal actions are fully complete. For example, let's say my normal timeline to destroy data is after 90 days, but we get a legal notice in the mail that says we're being sued for something. Part of that notice will say that I must have a legal hold now placed on all that data to make sure any pertinent data to the case doesn't get deleted or modified until the lawsuit is settled or completed in court. Now, another concept that relates to legal holds is called e-discovery. Ediscovery, or electronic discovery, refers to discovery in legal proceedings, such as litigation and lawsuits, government investigations, or Freedom of Information Act requests. where the information sought is in electronic format, such as saved electronic files, emails, chat logs, and other electronically stored information. Electronic discovery is subject to the rules of civil procedure and agreed-upon processes, often involving a review for privilege and relevance before the data can be turned over to the requesting party. Electronic information has an intangible form and volume, and it is both transient and persistent. And this makes it much more complicated to fulfil these discovery quests than it used to be when you dealt with paper-based information. Also, the electronic information being requested is usually accompanied by metadata that is not found in paper documents. And that can play an important part as evidence, too, such as the date and time that the document was written. That could be useful in a copyright case. Now, the preservation of metadata from electronic documents does create special challenges for our system administrators. So these are the types of things you need to consider when you're writing your organization's policies on how you're going to respond to a legal hold or an Ediscovery request. Finally, let's discuss the concept of third-party attestation of compliance. Now, sometimes your contracts may include a clause saying you need to meet certain standards or regulations in the course of your business. To take it a step further, they may require you to attest to your compliance or even require a third-party attestation of compliance. Now, an attestation just means that you're stating that you met the requirements and are compliant. But a third-party attestation of compliance means that somebody else came into your organisation and did an independent audit, looked at everything you had, and validated that you met the requirements. For example, there are many consulting companies that hire cybersecurity analysts and pen testers to conduct these third-party risk assessments. That way, they can provide their third-party attestation to large corporations. Some of these third-party attestations are going to be required by law, while others are required by a standard. For example, PCI DSS requires any level one organization, which means that an organisation that does at least $6 million per year in credit card sales must have an annual assessment performed by a third party who then attests to their compliance.

8. Integrating Industries (OBJ. 4.3)

When conducting acquisitions and mergers, it's important to consider the similarities and differences between two organisations when you attempt to integrate them across diverse industries. Now, often these days, two very different organisations might be trying to come together, and they can have very different cultures regarding rules and policies, different regulatory requirements, or even different geographic service areas that have to be considered. Each of these areas can bring new growth opportunities for the organization, but they also carry new risks and security weaknesses as well. Every organisation has its own rules for how it conducts information technology inside its business. When we're combining two different organizations, we have to consider how things are currently being done in each of them and then how we can best blend those two different rule sets. Remember, rules are directive and specific in nature, so they can be really hard to standardise across diverse organizations. Now, let's take, for example, two companies that want to come together. Now, some companies don't let end users configure their workstations, and others may allow end users to have local admin rights. While there is no correct answer, this is one aspect of culture that must be considered when attempting to standardise and reduce risk in the new combined organisation of these two companies. Now, policies, on the other hand, are easier to standardise because they're more generic in nature and don't provide specific solutions or methods. The language used in writing a policy tends to be much more broad-reaching, and each piece of an organisation can implement it as they see fit. For example, something like "the highest possible data integrity" shall be provided for. Data deemed financial in nature could be accomplished using many different types of integrity checks, not necessarily specifying the use of a certain one like Shaw 256. Now, you have certain organisations that are regulated by the federal government based on their field of business. For example, let's say you work for a radio station. You have to follow the regulations that are set forth by the Federal Communications Commission during the merger of two divergent organizations. One might be heavily regulated, and the other may not. If this is the case, we must use due diligence and due care to understand all the regulations involved and decide which parts of the business must meet regulations and which parts are not required to meet them. Another security concern during an acquisition or merger is the geographic differences involved. Often, two companies are not located in the same city, state, or even the same country. This can lead to different cultural issues, language differences, or different cultural norms that we have to work through and modify together. Beyond this, though, there are also some security concerns that we have to face. The first one is confidentiality and encryption. Some technologies are not allowed to be exported to certain areas of the world because of their encryption strength. because this is subject to export control. Therefore, we cannot simply make a blanket policy or rule regarding the use of these encryption techniques, because if we have one facility in the United States and another in Africa, we may not be able to use the same technology. Besides these encryption differences, there are often legal and regulatory differences between different countries and geographic areas. For example, the privacy requirements in the United States differ from those in the European Union because the European Union follows GDPR requirements. This leads to an issue of standardization across the entire organization. We can either standardise by requiring the organisation to meet the highest level requirements, even though this would cost us more in terms of resources, or we can choose to segregate the organisation and meet the requirements locally where possible, though this might also increase our risk posture towards it. There's really no right or wrong answer to all this stuff. It's a decision that has to be made for the business based on a cost-benefit analysis and a risk-benefit analysis within your own companies.

Go to testing centre with ease on our mind when you use CompTIA CASP+ CAS-004 vce exam dumps, practice test questions and answers. CompTIA CAS-004 CompTIA Advanced Security Practitioner (CASP+) CAS-004 certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using CompTIA CASP+ CAS-004 exam dumps & practice test questions and answers vce from ExamCollection.