CompTIA CySA+ Cybersecurity Analyst Certification: Compliance and Assessment - Frameworks, Policies, Procedures, And Controls

Objective 5.3  Explain the importance of frameworks, policies, procedures, and controls

Organizational Governance Flow
Organizational governance can be a complex mechanism within an organization. As a reminder, governance imposes requirements on an organization for compliance with certain rules. Governance can be external to the organization, in the form of laws, regulations, and standards. Governance can also be internal to the organization, taking the form of internal policies and procedures. Also, remember that the internal governance of an organization exists primarily to support and articulate external governance. For instance, if a law or regulation requires that a specific data type be protected to a certain level, then internal policy should be written to support that requirement and require all organizational personnel to comply with it.
Very often governance can establish the rules, methods, standards, and processes an organization must use to perform certain tasks, engage in certain activities, or support policies. These are typically mandatory in an organization and are considered as part of governance. In this module, we will discuss the various governance vehicles used to enforce compliance with laws, regulations, and policies. We’ll discuss frameworks, policies, procedures, and controls.

Frameworks
A framework is an organized methodology used to establish processes and activities that an organization may employ to create or manage a program. For example, the NIST Risk Management Framework (RMF) establishes a phased lifecycle approach to managing risk throughout a system’s entire useable life. The RMF provides for detailed steps and processes that an organization can use to categorize its systems, select security controls to protect those systems, implement those controls, assess control effectiveness and risk, gain approval to operate a system, and continuously monitor risk. The RMF is a useful framework that an organization can tailor and use iteratively to meet its needs.
There are other examples of frameworks designed to be used in various security or risk-related scenarios. There are management frameworks, control frameworks, risk frameworks, and so on. Each of these provides the overarching roadmap used to develop, implement, and manage a security-related program. Frameworks can be either risk-based or prescriptive.

Risk-Based
A risk-based framework allows for some level of modification or tailoring, depending on the needs of the organization. It also allows for a certain level of subjective decision-making regarding risk in the organization and risk of the program in question. A risk-based framework does not necessarily require a lockstep, by-the-numbers approach, although there is a formal structure provided that can be used as a guide whenever possible. Examples of risk-based frameworks include the NIST RMF, OCTAVE, and ISO/IEC standards (discussed previously in Objective 5.2)

Prescriptive
Conversely, a prescriptive framework is very much a sequential, by-the-numbers approach to a program or process. It requires strict adherence to rules, requirements, phases, and steps to be accomplished to achieve the objectives of the activities using the framework. It normally does not allow for subjective measurements or decisions. Examples of prescriptive frameworks include laws and regulations, strict standards, go/no go compliance assessments, and quality control models.

Exam tip: Understand the differences between risk-based and prescriptive frameworks. Risk-based frameworks are structured but allow some leeway in their interpretation and implementation, due to the dynamic nature of risk. Prescriptive frameworks are stricter and should be followed exactly. Examples of prescriptive frameworks are laws and regulations, compliance frameworks, and so on.

Policies and Procedures
As previously mentioned, policies and procedures are internal governance, which is created to support external governance, typically in the form of laws and regulations. Policies and procedures articulate the requirements handed down from external governance, such as ethics, legal liability, due care and diligence, data protection requirements, organizational structure, privacy, employee rights and responsibilities, and so on.
Policies are directive in nature and normally cover a wide range of security programs and issues.

Examples of policies might be data sensitivity and protection policies, backup policies, equipment care and use, acceptable use policies, onboarding policies, termination policies, and so on. Policies are typically short and to the point, and they plainly point out what the requirement is that members of the organization must comply with. Policies may also assign responsibilities and provide enough details to support the requirement. This may include stating what the ramifications of noncompliance with the policy may be.
Procedures support policies in describing in detail the steps that must be taken to comply with the policy. Whereas a policy will tell you what the requirement is, the procedure will tell you how to carry out that requirement. Senior management normally develops policies, often with input from lower-level technicians or managers, but line managers and knowledgeable employees typically develop procedures that are approved at the senior management level.
In the sections that follow, we are going to discuss an example of the policies you will find in an organization, including code of conduct, acceptable use, password and account management, data ownership, and several others. Understand that these are only a sampling of policies you need to be aware of for the exam; organizations can and do produce many other types of policies that are specific to the organization or the requirements laid out by other governance.

Exam tip: Remember that policies are directive in nature and tell you what you must do. Procedures support policies by dictating the details of how you will do it.

Code of Conduct/Ethics
A code of conduct or code of ethics dictates to individuals how they must carry themselves from a legal, moral, or ethical perspective. Typically, an individual agrees to this code when they join an organization and voluntarily chooses to abide by its behavioral requirements. Organizations have codes of conduct, whether it’s an employer or a professional certification organization, such as CompTIA, for example. In agreeing to a code of conduct, you accept the consequences of behaving according to the code, as well as the consequences if you do not. An employer may state that failure to adhere to the code of conduct may result in punitive measures or even termination. The human resources and legal department should jointly manage this aspect of employment.
A code of conduct normally requires that members of the organization behave ethically, honorably, and responsibly, that they practice due care and due diligence, that they observe and obey all policy requirements of the organization, and that they operate legally in all aspects of their professional career. All persons desiring to test for or who have achieved a CompTIA certification must abide by CompTIA’s Code of Ethics, detailed here: https://www.comptia.org/testing/testing-policies-procedures/test-policies/continuing-education-policies/candidate-code-of-ethics.
Failure to adhere to this code may result in the revocation of your certification.

Acceptable Use Policy (AUP)
An organization will have many different policies, but none is probably more critical than the acceptable use policy. An acceptable use policy is the core policy the drives what individuals, such as employees, contractors, and even business partners, are allowed to do on the corporate network. The AUP typically covers anyone who legitimately accesses the network. Employees typically sign and accept the policy when they are first hired. There may also be periodic reviews of this policy where employees have to acknowledge any changes or updates to the policy.
The AUP drives what employees are allowed to do and not do on the corporate network. In draconian organizations, this could include prohibitions on web surfing to other than approved websites, as well as no expectations of privacy on the network, forbidding private data to be processed or stored on the network at all. The AUP also covers the typical restrictions against prohibited content, such as pornography, hate speech, terrorist or criminal sites, and so on.
The AUP, like all policy documents, should also declare what the consequences are for violating the policy. This could include censure, loss of pay, suspension, criminal prosecution, and even termination. The policy should be administered by the information technology department but informed and supported by the cybersecurity, human resources, and legal departments. It should be promulgated across the organization, and all authorized users of the network should be aware of its contents. They should also be required to read and sign the policy, acknowledging that they have read it and understand it, ideally annually.
While it’s best to keep the policy confined to the authorized use of network resources and the Internet, the policy could be very broad and account for other issues, such as e-mail use and installation of unauthorized software, for instance. In a less-restrictive environment, organizations could allow their employees some limited personal use of corporate IT assets, such as allowing them to engage in off-duty online education, view medical appointments and banking information, and so on. Normally the policy provisions allowing these behaviors would take place after on-duty hours.

Password Policy
A password policy is also a critical policy in the organization. In the “old days,” a password policy was sufficient and directed how authorized users would create and protect passwords. Today, organizations are finally using a wide variety of stronger authentication methods (multifactor authentication, for example). Usernames and passwords are still present, unfortunately, so it’s necessary to still have a password policy that is probably part of a larger authentication policy.
If you still use passwords in your organization, you should make every effort to minimize their use and implement stronger user identification and authentication methods. These would include multifactor authentication technologies.

Multifactor authentication involves the use of different factors to authenticate, including the following:
- Something you know (such as a password)
- Something you are (such as a fingerprint)
- Something you have (such as a token or smartcard)
- Your location (from where you are attempting authentication)
- Other characteristics (time of day, authorized host, and so on)

Remember that for multifactor authentication to work, you must use at least two of these factors together. Many people think that the username and password combination is multifactor, but those are two things you know, so they comprise only one factor.

Examples of multifactor methods include the use of a smart card (something you have) and a personal identification number, or PIN (something you know), or biometric authentication methods, such as a retinal scan, fingerprint, and even DNA (something you are) and a password or PIN. A common example of multifactor authentication is the use of automatic teller machine (ATM) cards.
In the event you’re forced to use passwords for the network or even certain specific applications, here are the guidelines that should be included in your password policy:
- Use complex passwords consisting of each of the following: uppercase letters, lowercase letters, numbers, and special characters.
- Use longer passwords, ideally 8 to 20 characters, depending on the technologies you use. This increases your possible keyspace, or numbers of combinations of characters, you can use.
- Do not use dictionary words or any word that can be derived from any number of different types of dictionaries, such as an ordinary language dictionary, foreign word dictionary, and medical, sports, and technical dictionaries. Avoid using common things such as your spouse’s name, child’s name, pet’s name, or special dates, and, obviously, passwords should not contain any part of the user’s name.

Passwords should expire after a certain amount of time. In days long past, six months might have been the limitation. For passwords these days, with the rapid increase in computing power and the ability of malicious entities to crack passwords much faster and much more efficiently, it’s not uncommon to see 90 or even 60 days’ expiration time, particularly for critical systems and applications.
Passwords should be recycled so they cannot be reused for at least several password change cycles. The default for Windows is 0 passwords remembered, but it can be set for up to 24 previously remembered passwords. This makes it so users cannot revert to a previously used password in any reasonable amount of time, assuming your password policy requires a maximum password age (expirations) and minimum password age (discussed next).
Just as there’s a maximum password age, there should be a minimum password age. This prevents users from having to change their password at the normal expiration time but then changing it back to something else immediately. The theory is that if the users are required to keep a new password for a certain amount of days, it becomes a habit to them and they get used to it, so they are less likely to change it. This also prevents them from quickly recycling through the number of passwords in the password history file to reuse an older password.

The password policy should also discourage users from compromising passwords by writing them down in an easily accessible place, sharing passwords with another user, and so on.

Finally, the password policy should state that the users’ organizational passwords be unique from personal passwords, such as personal e-mail and social media. This will help prevent the situation where a password is exposed in, say, the LinkedIn breach of 2012, where nearly 170 million credentials were leaked. If the user’s password was the same as their organizational password, it would be easy for an attacker to then go try it against the organization’s systems.

Passwords for critical systems and accounts, such as the true administrator or root account, should be secured in a locked area, and they should require two-person integrity to access them. This is if an emergency happens and the administrator password must be used. Hopefully, if your account management policies and procedures are written correctly, this should never happen, since ordinary users who should need administrative rights will have separate accounts for that purpose.

Data Ownership
Organizations are responsible for the data they generate, store, process, transmit, and receive. Even in cases where there is no overall regulation or law that prescribes this, which is rare, the organization has a responsibility to itself to take care of its data. This includes protecting it from unauthorized access, ensuring its integrity is maintained, and making it available for the authorized users who need it.

One of the most critical policies that an organization can create is a data sensitivity policy. This typically defines what an organization considers to be sensitive or important data and how it must protect that data. An element of this policy, or even as a separate policy, is that of data ownership. The data owner is responsible for and accountable to the organization for protecting certain data types. This data owner may be responsible for several data types, or just one specific type. Typically, the data owner is a senior leader or manager in the organization designated in writing to be the responsible data owner.
The data owner determines data sensitivity, provided that the law or other regulations don’t already prescribe this, to what level it should be protected, and who is responsible for implementing the protections. The data owner also determines who has authorized access to the data.

Similar to a data owner, a data custodian is responsible for the protection of designated data types as well. However, whereas the data owner makes decisions regarding data and its protection, a data custodian implements those decisions at the functional level. This is usually a lower-level cybersecurity or IT technician who is responsible for implementing permissions on data objects, such as files and folders, as well as performs the technical aspects of giving individuals access, as directed by the data owner. This person is also responsible for the day-to-day maintenance of the data, including backing it up, checking for integrity, reviewing audit trails related to the data, and so on. Ultimately the CEO or CIO is responsible for all data in the organization, but this ownership, as well as responsibility and accountability, can be delegated down to another legally authorized entity. In fact, certain regulations, such as the European GDPR, require the appointment of such persons, such as a data privacy officer, a data processor, and a data collector.

Data Retention
Data retention is yet another policy-driven element of data security. You should probably have a data retention policy because of any legal requirements imposed by external governance, such as laws and regulations. Data retention essentially tells an organization which sensitive data it should keep, and for how long, and how it must be protected in storage.

The data retention policy can be a part of a larger data use or data sensitivity policy if needed, as long as it can be articulated back to a legal requirement to retain data.

As a general rule, organizations do not keep large amounts of data unless legally required; the storage requirements alone can be unsustainable. In addition to storage requirements, the organization has to ensure that it can quickly access this data when required, typically during an audit, inspection, or investigation.
If no laws or regulations are requiring an organization to retain data under specific circumstances, the organization should carefully consider whether or not it actually needs to retain the data. It may need to keep data for business purposes; this might include data such as business records, financial data, plans, proprietary data that it uses to conduct its daily business, and so on. Even when not required by regulation, if an organization decides that certain data is sensitive enough to retain, there should be a policy that dictates this, by describing the data type, the justification for keeping it, and the specific data retention requirements. These would include the amount of time data is retained, and how it must be protected during retention.
As part of data retention policies, the organization should also describe how it disposes of certain data when its retention requirement time has expired. This can include destruction by secure means, such as a high-grade document shredder, mulching, or incineration. It could also describe how to destroy, or even reuse, media that the data is stored on. Keep in mind that the methods for destroying data no longer needed on media include wiping, physical destruction, burning, and degaussing.

Work Product Retention
Part of the data you may retain for business purposes includes work products, which are those products that contain information as the result of doing business. You’ll hear this sometimes referred to as an organization’s “intellectual property.” It could mean financial products, process products, human resources products, or any other type of product created as a result of the organization performing its primary mission or from the different programs and processes that support the mission. These products should be evaluated for retention per the organization’s retention policy. This information should be assigned a specific data type and protected according to policy.

As a general rule, the more data an organization retains, the more difficult it is to protect that data, in terms of allocating resources for protection as well as for retention. That’s one of the reasons an organization should carefully consider retaining only the most important data it needs for care and diligence, legal liability, and to maintain business continuity.

Account Management
Account management includes the processes and activities associated with managing accounts during their lifecycle. The account management lifecycle typically is composed of account verification, account creation, provisioning, authorization change, account validation, and, finally, termination or disposal. Account management is a complex process within an organization that seriously affects the security of the organization. As such, there should be definitive policies and procedures created for it.
Remember that not only people (employees, contractors, business partners, customers, suppliers, and so on) have accounts, but also machines and other entities. Also keep in mind that these various entities don’t only have internal network accounts; they have accounts for extranets, specific databases and applications, and specific systems. Part of account management means segregating all these different accounts for different resources in the organization both logically and physically.

Different functions may provide different account management functions in the organization.

For example, the help desk may be in charge of routine account maintenance, while there could be a dedicated section of IT or IS (information security) focused on verifying and validating accounts, changing permissions to resources, and even provisioning administrative-level accounts.
To begin with, having an account in the organization should mean that a person has the following:
- The proper clearance to access the organization’s network
- The appropriate need to know based on their job duties
- The approval of someone authorized to grant such approval in management

The organization must develop, as part of its procedures, steps to verify the need for an account through a supervisor or manager, the identity of the person or entity requesting the account, and the resource access needed by the account.

In general, account management procedures and policy elements should include the following:
- Everyone should have a normal user account at minimum, even administrators.
- Normal user accounts should not have administrative access to any types of applications, shares, systems, network devices, and so on.
- There should be no guest or common use accounts.
- Administrative-level accounts should be granted only to those personnel who have a valid need, based on their duties and verified by a manager.
- Administrative account holders should only be using their administrative-level account for specific duty-related tasks, and not everyday activities, such as surfing the web or e-mail.
- All accounts should be periodically audited for necessity or to make sure they are not performing any functions they should not be.
- Administrative-level accounts, in general, should be audited daily for any access to resources or use of special privileges.
- All accounts should be periodically validated with a supervisor or manager.
- Any time an administrative account is created, there should be a paper trail or other documentation to back it up.
- At any given time, a cybersecurity analyst should be able to look at an audit trail to see what a particular account has done in every instance from the day it was created until the present. This is useful for security, nonrepudiation, and establishing usage trends for administrative-level accounts.

Always ensure that account management operates on the premise of least privilege. In other words, you should have only those privileges or permissions necessary to be able to perform routine daily job functions. Privilege creep occurs when an account, over time, acquires privileges that it should not have because it has not been properly monitored or validated regularly. That’s why part of the account management lifecycle includes occasional periodic account validation.
Account management procedures should be separated by job function, enforcing the separation-of-duties concept. For example, users who create accounts, such as account operators, should only be able to create and/or delete accounts. They should not be responsible for giving account permissions to resources. There could be another function tasked with placing user accounts in the correct resource or permission groups or roles. Typically the data owner will decide who has access to which resource, so that should be a function of the data owner versus an account operator, for example. Furthermore, the individuals who audit account usage should not be the ones to create or delete accounts or assign resource permissions. Again, this enforces the concept of separation of duties. What you want to avoid is a situation where someone could create an account, assign permissions to it, perform some illegal task, delete the account, and then delete the audit trail associated with the account.

Continuous Monitoring
Continuous monitoring is a concept promulgated by several risk management frameworks, including NIST. Continuous monitoring means several things. At a lower system and infrastructure level, it means to consistently gather data from a variety of sources and be able to perform historic and trend analysis on it, as well as to be able to view data in real time and get alerts in case something happens. Monitoring your network is the best way to ensure you can detect incidents when they happen and respond to them. From another perspective, continuous monitoring means continuous risk management. This means monitoring for changes in risk and responding to them when they happen. This also means monitoring the organization’s environment, both internal and external, to detect changes in risk factors that may affect the system or organizational risk.
When monitoring for risk, the organization should look for changes in threats, vulnerabilities, impact, and likelihood. Threat modeling is one way to monitor threats. This looks at threat scenarios and how that might affect the organization. Vulnerability assessments performed periodically are a component of continuous risk monitoring. Factors that affect the likelihood or impact are also carefully monitored. This could mean changes in infrastructure, resource allocation, and both external and internal risk factors that may affect impact and likelihood.

As we are discussing policies and procedures, you should ensure that the organization has a policy for continuous risk monitoring and management. Risk doesn’t only occur one or two times a year when you do a risk assessment. Risk is ongoing and changes constantly; therefore, risk management should change with it. Ensure that you have a policy for continuous monitoring, at the systems and infrastructure event level as well as at the organizational risk level.

Exam tip: Understand that policies are required for implementation, and examples of common policies in organizations include account management policies, password policies, and, probably the most critical one, the acceptable use policy.

Control Categories
The exam objectives call for you to understand the different categories of controls. For the CySA+ exam, these are managerial, operational, and technical. Traditional security foundations typically refer to these as administrative, technical, and physical, but we will use the CompTIA terms here, albeit with some additional guidance on the use of these terms, as they depart from traditional security thinking somewhat. In the next few sections, we will discuss what each of these categories of control means. We will also discuss the different control types or functions, which, again, can be a little bit different from what we see in traditional security texts.

Managerial
These controls—sometimes referred to as administrative controls—are those that are implemented as policies, procedures, standards, and guidelines. Managerial controls typically tell you what security requirements are and how you should implement them. As their name suggests, managerial controls are created and implemented by the management of an organization.
Examples of managerial controls might include acceptable use policies, privacy policies, and backup procedures. Typically, for each managerial control, there is a roughly corresponding technical or operational control that implements the requirements of the managerial control. For example, an encryption policy, as a managerial control, would direct that you use a particular type of encryption method, algorithm, or strength. A technical control would complement that using the prescribed encryption method, such as AES-256.

Operational
Operational security controls are typically physical controls and other operational procedures. These include processes or procedures performed by people. This might include cameras placed throughout the facility, gates, guards, guns, locked doors, alarm systems, and so on. These controls are designed to protect personnel, equipment, and facilities from a physical or operational threat. Note that there can be significant overlap between managerial, operational, and technical controls, thus making discerning the control categorization a bit difficult sometimes.

Technical
A technical, or logical, control is a control implemented with technology, such as firewalls, intrusion detection/prevention systems, encryption, audit logs, object permissions, and so on. Typically a technical control is the implementation of a corresponding managerial control that issues a requirement, and the technical control implements that requirement.

Exam tip: Previous CompTIA exam objectives for both the Security+ exam (SY0-501) and the CySA+ exam (CS0-001) categorizing the types and functions of controls have changed significantly since these two previous exam iterations. CompTIA, for both the new SY0-601 and the CySA+ CS0-002 exams, has reclassified control types and functions. Although the practical day-to-day definitions have not changed, be aware that they are now classified differently on each exam, so you should know the new categories and types.

Control Types
All controls are designed to perform one or more overall functions: to prevent a malicious act or a violation of policy, to detect either a malicious act or a violation of policy, or to make up for a deficiency in or lack of a control. More often than not, a control can overlap in function and perform several different functions at one time. It’s not unusual to see a control be both a deterrent and a preventative control, for example, or to be both a compensating and corrective control. We will discuss the different control functions next.

Deterrent
A deterrent control is one that deters a person from performing a malicious act or violating policy. An example of a deterrent control might be a closed-circuit television camera (CCTV). Its mere presence lets a would-be intruder know that their actions are being monitored and recorded. Just knowing the control is there might be enough to deter anyone who might violate policy by entering a restricted area, for instance. The key thing about a deterrent control is that the person who may perform the act or violate the policy must know that the control exists for it to be a deterrent to them.

Preventative
A preventative control does exactly what its name indicates. It prevents someone from violating a policy or performing a malicious act. Note this is almost the same definition as a deterrent control. However, there is a critical difference between the two types of controls. A preventative control will do its job regardless of whether someone knows about it or not. An example might be a firewall rule that blocks video chat. Regardless of whether a person knows it exists, it will still prevent someone from violating a policy that prohibits video chat outside the organization. As mentioned earlier, the key difference between that and a deterrent control is that a deterrent control must be known about to be effective. Referring back to the example of a CCTV, it would not be effective as a deterrent if a person did not know it was there. It still might be effective as a detective control, discussed next, but not as a deterrent control.

Detective
A detective control is one that detects an incident or can provide information about the incident. Good examples of a detective control would include CCTVs, an alarm system, and an audit log. Note that detective controls are reactive: they do not prevent or deter malicious acts or policy violations; instead, they only serve to alert someone after the act or violation has occurred, even in the case of real-time monitoring and alerting.

Compensating
The compensating control is used to temporarily strengthen or take the place of a missing or ineffective control. Consider a section of fencing that has been damaged due to a break-in. Until that piece of fence is repaired, a compensating control might be for a guard to be placed at the break in the fence. Obviously, it’s not as effective as the fence being there, but it will serve to deter people from entering the break in the fence as well as prevent that from happening. It also serves to reduce risk, which is one of the main functions of security controls.
Another example may indicate that compensating controls are not always as temporary as we would sometimes like. Consider a smaller organization that does not have enough people to adequately separate security duties, such as reviewing audit logs. The organization may outsource some of its security functions, such as security device monitoring, to a third party that also reviews audit logs. While log review should be performed normally by a trusted security administrator within the organization, until the organization can hire someone to do that, it must rely on an outsider to perform that task. This is then not an ideal control but rather a compensating one in this case.

Corrective
A corrective control is used to temporarily correct a nonsecure condition caused by a malfunctioning, ineffective, or missing control. This typically happens due to an incident, and something must immediately correct the nonsecure condition caused by a control failure. A corrective control is considered temporary, and it is also not an ideal control solution. Therefore, in these two ways, it is very much like a compensating control. The key difference here is that a compensating control may be more long term, proactive, and planned in nature, whereas a corrective control is usually reactive due to an incident or obvious failure of a previously functioning control.

Exam tip: On the exam, if presented with a scenario that causes you to have to choose between a corrective and compensating control, look at the context of the scenario. If the control is reactive and short term in nature, it is usually a corrective control. If it is proactive, longer term, or planned to make up for a known ineffective or missing control, then it is a compensating control.

Recovery
A recovery control is traditionally one that is used to take a system or organization from a nonsecure or unsteady state to a secure one after an incident. For example, backup tapes that are used to restore a server whose operating system has been damaged due to an attack would be considered a recovery control. As control functions sometimes overlap, you might also consider this control to be preventive in nature (preventing data loss by performing backups) or even corrective (restoring the data from backups corrects a nonsecure condition—that is, data loss), although considering it a corrective control might be a stretch.

Exam tip: For the exam and its objectives, the recovery control type/function is no longer listed on CompTIA’s exam objectives. However, traditional (and current) security thinking and teaching still acknowledge this classification of control function. For the exam, recovery controls are typically categorized as compensating or corrective controls.

Physical
Physical controls are normally considered a category of controls versus a control function, but their categorization for the exam objectives doesn’t make too much of a difference in understanding them. A physical control, as mentioned earlier, is a control designed to protect the physical environment of the organization—its people, equipment, facilities, systems, and data. Physical controls include the obvious: gates, fencing, guards, CCTVs, and so on. But they also include environmental controls, such as those that protect against temperature fluctuations and excessive or insufficient humidity, since significant variations in those two measurements can be detrimental to sensitive equipment.

Exam tip: The physical control type/function is no longer listed on CompTIA’s exam objectives as one of the three main types (categories) of controls. Traditional (and current) security thinking and teaching still acknowledge physical controls as being one of the three main types (managerial/administrative, technical/logical, and physical/operational). For the exam, physical controls are categorized as a subtype of control, not a main type.

Audits and Assessments
For our discussion on frameworks and policies, you should definitely have an audit policy as well as an assessment policy.
An audit policy essentially states what the organization will audit in terms of specific resources, such as systems and data, and how it will audit them. This policy could be connected to your data sensitivity policy somewhat, in that once you know your data sensitivity levels and how they must be protected, you should audit those particular data types accordingly. Your audit policy should restate this. It should state how often sensitive data types are audited and what information you need from the audit trail.

Information from an audit trail could include the following:
- Which user or entity accessed the data
- The time and date the data or system was accessed
- What actions were performed on the data (read, changed or modified, deleted, and so on) or system
- From what host the data was accessed

You would audit sensitive data so that in the event of an incident or investigations into unauthorized access of data, you would be able to trace those actions back and show what happened as well as hold someone accountable for the incident. You should implement your audit policy by assigning the proper audit configuration items, such as read or write success or failure, for example, to systems, folders, and files that contain sensitive data.

An assessment policy should detail what types of assessments the organization routinely performs, how often and why, and what the organization expects to have as a goal from the assessment. For example, the assessment policy may require that vulnerability assessments be required once per month. This vulnerability assessment policy or element may state that vulnerability assessments should be performed once per month, or weekly on certain subnets if the network is very large, and what types of vulnerabilities should be looked for.

The policy may also dictate what kind of software is used for vulnerability assessment assessments, and the day of week or time of day they are conducted. It will probably also require that the department in charge of performing vulnerability assessments develop detailed procedures for them.

Other assessments might include penetration testing assessments, tests and exercise of the incident response plan, business continuity and disaster recovery exercises, and so on. These types of assessments may also be separate and included in the appropriate response plan policies. In any event, policies should set forth requirements for the different types of assessments, as well as who will conduct them and, to a small degree, how they will be conducted.

Two different types of assessments you may be required to perform that your policy may address include compliance assessments and regulatory assessments. These are discussed next.

Regulatory and Compliance Assessments
Regulatory agencies often require specific assessments be performed periodically to ensure that organizations comply with their requirements. These assessments could take many forms, although typically you would see a unique version of a risk assessment or a controls assessment. Any so-called risk assessments do not necessarily produce a picture of true risk; they are assessments to determine compliance with controls or other strict requirements. This is particularly true in U.S. government agencies, such as the Department of Defense, or with certain types of data, such as HIPAA assessments.
Controls assessments perform two important functions: First, they can provide an organization with the knowledge that the controls selected for protecting assets are the correct controls and are functioning effectively. Second, they can assure an auditor that the organization is complying with control requirements. Control requirements alone do not provide a picture of risk. Unfortunately, however, that is often what you’ll see with regulatory or compliance assessments. The theory behind this form of assessment is that if you are using the correct controls, and they are effective, then you have taken steps to reduce risk. This is by and large true, but a control assessment does not take into account other factors, some of which can’t be measured by verifying and validating controls. These include threat scenarios, vulnerabilities, the impact to an asset or the organization if a negative event occurs, and the likelihood that a negative event will occur at all.

In the best scenario, a regulatory or compliance assessment will not only look at controls but also risk to the asset or organization. A complete end-to-end assessment should consist of several parts:
- Full threat modeling
- Vulnerability assessments
- Controls assessments
- Adversarial simulations (or penetration tests)
- Incident response, business continuity, and disaster recovery exercises
- Thorough risk analysis of likelihood and impact
- Consideration of external and internal risk factors
- Continuous monitoring

REVIEW
Objective 5.3: Explain the importance of frameworks, policies, procedures, and controls In this module, we discussed organizational governance, both internal and external. Remember that governance is the legal and ethical requirements imposed on the organization by laws and regulations as well as by the organization itself in the form of policies.
Frameworks are very important in that they establish a methodology and process for performing risk and security management functions. The two primary types are risk-based frameworks, which are a little bit more flexible, and prescriptive frameworks, which are very strict.
Organizations typically have many different policies and procedures that are established to guide and regulate the organization’s behavior and activities. A policy is a requirement; all employees and others accessing organizational resources must obey them. Policies explain the particulars of what must be done. Procedures support policies by providing detailed steps of how to perform a task or activity. Common policies that an organization develops and implements include the acceptable use policy, account management policies, password policies, data ownership and retention, and continuous risk monitoring. Other typical policies you might see include data sensitivity, backup policies, equipment control and care, and encryption policies.
We discussed controls at length, including categories and types. CompTIA provides for three different overarching control categories: managerial, operational, and technical controls. Managerial controls are those established by management and include policies and procedures. Operational controls include processes and procedures performed by people as well as physical controls. Technical controls, also known as logical controls, are those that are implemented using various technologies. Examples include encryption, authentication mechanisms, antimalware, and so on.
Control types determine what function a control serves, and controls can span several different functions at one time. Deterrent controls must be known in order to be effective, and preventive controls help to stop malicious acts to prevent policy violations, regardless of whether a person is aware of them. Detective controls are used to detect, discover, or investigate violations of policy or malicious acts. Compensating controls are put into place when the control is known to be ineffective or missing. Corrective controls are more immediate and temporary and usually put into place after an incident to correct a serious security issue. Physical controls include physical barriers and measures to protect people, facilities, and equipment. Environmental controls are those that detect and regulate environmental changes, such as temperature and humidity.
The organization must have strong audit and assessment policies. An audit policy details which different types of sensitive data may be audited as well as what should be included in an audit trail. The assessment policy should dictate what types of assessments the organization routinely undergoes, including vulnerability assessments, penetration tests, and scheduled tests and exercises of response programs. Regulatory and compliance assessments are designed to determine if the organization is compliant with various regulations, policies, and standards. These types of assessments are normally prescriptive and may not take into account the broader risk picture.