Business View on Compliance

Businesses are taking an increased interest in how information risks are being managed and reduced. Security policies are not considered solely a technology issue anymore. The business also wants the security policies to reflect how they want information handled. You can look at the security policies collectively as a business statement of commitment to protect its information and customers. Good security policies keep the business healthy. Some of the basic concerns the business will have with implementing such a policy will include the following:

• Cost—Cost of implementing and maintaining controls

• Impact—Impact to customers

• Regulatory—Ability to legally defend

Policies are only effective if they are enforced. One thing management dislikes are surprises. Finding out later that security policies are too costly or impact the customers is not acceptable. To avoid this, management needs to be an important partner in implementing IT policies.

Protecting and Securing Privacy Data

In general, it is understood that privacy data must be protected. What is not so clear, however, is what constitutes privacy data. Some jurisdictions are very broad in their definition of privacy data, while other jurisdictions may narrowly define it. Generally, it's best to use the most comprehensive definition for an organization's industry, region, and regulatory mandates. For example, California Consumer Privacy Act has a comprehensive definition of privacy data elements. Depending on the environment in which an organization operates, privacy can take on different meanings. The American Institute of Certified Public Accountants defines privacy management as “the process of protecting the rights and obligations of individuals and organizations with respect to the collection, use, disclosure, and retention of personal information.” Thus, privacy is about the personal information that might be used to identify an individual. Examples include the following:

• Name

• Social Security number (SSN)

• Home address

• Email address

• Physical characteristics

Personal information can also be considered sensitive. Consider, for example, sensitive financial or health information. When combined with personal information, this information becomes personal and sensitive. For example, a person’s name by itself is not sensitive. Simply knowing there’s a person who is called John Smith has no value. Combining the name with other information make the information sensitive such as John Smith has a social security number of x can put the person at risk for identity theft. As a result, the protection of this data becomes increasingly important when you consider the risks posed to this data, such as inadequate access controls, improper use, or unauthorized disclosure, to name a few.

For both individuals and organizations, the collection of personal data provides many benefits. Organizations, for example, benefit from increased market intelligence and competitive advantage, whereas individuals benefit from things such as personalized services and targeted offerings. On the other hand, individuals might be subject to spam and identity theft if that data are not protected properly. (Identity theft is the theft of someone’s personal information for unauthorized use.) Organizations also are subject to litigation, negative publicity, and even financial loss.

Privacy data can be protected using numerous methods. For example, organizations can do the following:

• Develop appropriate privacy policies.

• Establish the position of a privacy officer . This is a senior-level management position within an organization responsible for handling privacy laws and their impact on the organization.

• Conduct training and awareness around data handling, identity theft, and social engineering . Social engineering involves manipulating people into divulging information.

• Consider adequate controls around data retention and data destruction.

• Conduct regular risk assessments of access controls.

• Limit data to only that which is required.

• Consider security technologies such as encryption.

Privacy laws and regulations vary not just by industry, but also by areas in which business is conducted. In North America alone, there are many laws concerning privacy. Popular examples include the following:

• Health Insurance Portability and Accountability Act (HIPAA)—The Privacy Rule within Title II of this act is concerned with the security and privacy of health data.

• GLBA—The Financial Privacy Rule within the act is concerned with the collection and disclosure of personal financial information.

• Children’s Online Privacy Protection Act (COPPA)—This act contains provisions for websites collecting personal information from children under 13 years of age.

• National Do Not Call Registry—This registry provides consumers with the choice to not receive telemarketing calls at home.

• California Consumer Privacy Act (CCPA) of 2020

• NYDFS Cybersecurity Regulation (23 NYCRR 500) of 2017

• Electronic Communications Privacy Act of 2000—This act regulates and protects the privacy of email and other electronic communications.

• The Fair Credit Reporting Act—This act regulates the use of consumer credit information.

As a result, IT compliance audits must consider privacy data and the application of an appropriate privacy control framework within organizations. First, consider the laws and regulations across multiple boundaries in which business is conducted. Further, the coordination between both general counsel and IT is necessary to understand both the legal and security repercussions.

Finally, organizations should consider a privacy audit. Most audits are concerned with the privacy oversight, privacy policies, and privacy controls within an organization. A privacy audit focuses on the following:

• Which privacy laws are applicable to the organization?

• Are the organizational responsibilities defined and assigned (for example, for the privacy officer and the legal department who is responsible for notifying regulators in the event of a privacy breach)?

• Are policies and procedures for creating, storing, and managing privacy data applied and followed?

• Are specific controls implemented, and are compliance tasks being followed? For example, is privacy data encrypted? Are there privacy statements and an opt-out mechanism on the organization’s website?

Designing and Implementing Proper Security Controls

Information security is largely about managing risk. That means IT controls are implemented depending on the risk they are designed to manage. Although the focus is on mitigating risk by implementing appropriate security controls, there are other ways to deal with risk. Risk can also be avoided, transferred, or accepted. For example, driving a vehicle poses many risks. Consider the risk of loss due to theft or an accident. Most people choose to transfer the risk by purchasing insurance. Others might accept the risk by not purchasing insurance. Still, others might avoid the risk altogether by choosing not to drive.

Every day, you make personal decisions that consider controls regarding risk. Being human naturally makes you vulnerable to many different threats, which can have a tremendous impact on you. Many people wear a seat belt while driving, for example, to mitigate the risk of injury during an accident. Now think about how you might choose to protect your family while at home. Door locks are a good place to start. Door locks are also a relatively simple control. Yet some people have alarm systems, whereas others don’t. The same concept applies to the threat of an assailant with a gun. Why doesn’t everyone wear a bulletproof vest?

Managing risks involves making trade-offs. A solid understanding of the risks and proper consideration of the trade-offs results in the controls you select for your personal security and the protection of information. It is necessary to properly assess and prioritize risk.

The process of selecting security controls needs to be part of an overall framework for risk management. For example, the following activities consider the implementation of controls within the context of such a framework:

1. Discover and classify data and information systems—First, consider the confidentiality, integrity, and availability of the data and information systems. Next, examine the potential impact on the organization should confidentiality, integrity, or availability being compromised.

2. Select security controls—After you consider the impact, select appropriate security controls based on the risk to the systems.

3. Implement security controls—After selecting controls, put the controls in place to ensure risks are reduced to an appropriate level.

4. Assess security controls—Evaluate the effectiveness of the controls. The assessment provides the necessary information to ensure they are implemented correctly and meet the security requirements.

5. Authorize the controls—After considering the system in relation to the assessment of the controls, determine whether the risk that remains, the residual risk, is at an acceptable level.

6. Monitor the controls—Once controls are set, put a system of continuous monitoring in place. Changes within the organization or the information system, for example, might result in the need to update the security controls. In addition, an event involving the identification of a new threat or an event resulting in a breach will require an immediate assessment and possibly a change to the applied security controls.

COBIT is a popular and widely used control framework for IT in general. A high-level control objective with COBIT as related to the IT process is to “ensure systems security.” These objectives have many common industry-accepted IT processes, including the following:

• Management of IT security

• Security plan

• Identity management

• User account management

• Security testing, surveillance, and monitoring

• Security incident definition

• Protection of security technology

• Cryptographic key management

• Malicious software, prevention, detection, and correction

• Network security

• Exchange of sensitive data

Although this framework provides a sound overall foundation of control objectives, other frameworks or standards provide more detailed guidance. Selecting security controls is best approached by first adhering to a common set of basic or baseline controls. Next, you might need to apply additional controls that are specific to the system or application. Finally, you might need to apply compensating controls. Compensating controls are necessary when a baseline security control cannot be implemented, for example.

Some common control baselines from the National Institute for Standards and Technology (NIST) are listed in Table 3-1. Controls described in the table are from NIST Standard 800-53. The controls are categorized by a high-level control family and include various controls that apply to each group. Within each family, the policy and procedures are always considered.

TABLE 3-1 Family of security control baselines and corresponding examples.

In another example, SANS (SysAdmin, Auditing, Network, Security) Institute created a list of 15 Critical Controls primarily addressing the technical control area. Many people are more comfortable with the 20 Critical Security Controls than with other more comprehensive frameworks. This is largely by design. The list is intended to be “real world” and to provide actionable guidance that considers those controls that provide the largest security gains based on existing threats and vulnerabilities. The following list represents the 15 Critical Security Controls as of Version 8:

• Control 01: Inventory and Control of Enterprise Assets

• Control 02: Inventory and Control of Software Assets

• Control 03: Data Protection

• Control 04: Secure Configuration of Enterprise Assets and Software

• Control 05: Account Management

• Control 06: Access Control Management

• Control 07: Continuous Vulnerability Management

• Control 08: Audit Log Management

• Control 09: Email and Web Browser Protections

• Control 10: Malware Defenses

• Control 11: Data Recovery

• Control 12: Network Infrastructure Management

• Control 13: Network Monitoring and Defense

• Control 14: Security Awareness and Skills Training

• Control 15: Service Provider Management

Stop for a moment, review the 15 Critical Security Controls, and compare them with the controls listed in Table 3-1. How different are they? Is it possible to map many of the controls to controls of the other? Interestingly, the 15 Critical Security Controls map to about one-third of the NIST controls, to address the most critical controls based on an attack-based analysis. This basic control document was created based on the most prevalent types of attack. Again, these controls aren’t meant to replace a more comprehensive set such as that provided by NIST. Rather, these 15 Critical Security Controls provide simpler “quick wins.” Table 3-2 contains a sampling of the first five types of attacks considered when developing the Critical Security Controls. Each attack type is followed by the most related Critical Security Controls. The complete list contains more than 23 attack types.

TABLE 3-2 Summary of attacks correlated to the Critical Security Controls.

Choosing Between Automated, Manual, and Hybrid Controls

Policy enforcement can be accomplished through automated or manual controls. The time and effort involved in manual policy management can make automated tools an attractive option. Automated controls are cost-efficient for the large volume of work that needs to be performed consistently.

Automated control is configured into a device to enforce a policy requirement. Here’s a shortlist of several common automated controls:

• Authentication methods

• Authorization methods

• Data encryption

• Logging events

• Data segmentation

• Network segmentation

The number of automated controls is limited only by the technology’s capability. Continued improvement in technology allows for more automation. The biggest challenge isn’t automation but deployment cost and integration across the IT infrastructure.

Consider an example where a policy says that users must change their passwords every 30 days. A central authentication server exists within the environment. The challenge is how to configure every device to use the authentication server. The IT environment can have thousands of devices. Each may have to be configured. Once configured, these devices have to be monitored to ensure the configuration is not changed. As new devices are added, the same configuration has to be applied to every device from servers to smart appliances. The configuration of an automated control may be simple. Applying it consistently across thousands of devices becomes a major challenge. The problem gets more complicated as the number of automated controls increases. The diversity of the technology in the environment can make supporting automated controls more complex.

Many commercial products come with enterprise management software to solve this automation challenge. Central policy management software is designed specifically for this purpose. These types of applications create policy rules on a central server. These rules are then sent to the various devices via an agent or agent-less architecture.

Automated policy management tools take security policies and implement them as configuration updates. Once the device is configured, the automated control enforces the policy. The enforcement can be a preventative or detective control. Either way, the control is automated. The control either prevents an event that is outside policy, or it detects that an event occurred. Our example of a policy that requires a password to be changed every 30 days is typically preventative control. The central authentication server forces users to change their passwords at the end of 30 days.

Policy management tools also correlate large amounts of data. They can discover devices on the network. They can track which device has the policies applied. These tools can also monitor policy violations. The tool can identify devices that do not have the policy applied. These tools identify existing configurations to compare with the desired policy state. Deviation from policies can be automatically corrected. This is a powerful tool. Auditors and regulators often request extracts from the policy management tools. This extract can help them assess the level of policy compliance.

Not all controls can or should be automated. Manual controls are appropriate for low-volume work. It’s also appropriate for work that requires human judgment. Examples of manuals controls are as follows:

• Background checks

• Log reviews

• Access rights reviews

• Attestations

In each of these cases, volumes are low, and human judgment is important to the process. It is important that manual processes are clear. This means that both the step is clear and the criteria for the judgment are clear.

Let’s walk through background checks as manual control. The process should be clear as to how to collect the information for the background check. The criteria should also be defined. For many jobs, minor traffic violations are acceptable. For other jobs, such as commercial drivers, any traffic violation may be considered unacceptable. A clearly defined security policy ensures everyone is treated equally on background checks. This can avoid legal problems.

A human can review logs for unusual activity that is difficult to automate. For example, when a programmer is granted elevated rights to fix a production problem, logs are often reviewed. The logs are reviewed to determine if the programmer performed an activity that exceeded the scope of the fix. For instance, the log review may change if the programmer changes account data in a database. These types of changes to fix an application may be unusual and require management follow-up.

Access rights include a review by the business to ensure adequate segregation of duties. This type of review is manual and requires knowledge of how the business operates. Based on this knowledge, a reasonable balance is struck between operational efficiency and reducing risks.

An “attestation” is a formal management verification. Management is attesting that a condition exists. Some regulations require management to attest that security policies and controls are in place. For example, SOX requires this type of attestation from senior management.

When someone makes an attestation, they are personally liable for the accuracy of the statement. This is a way the law holds management accountable to ensure appropriate controls are put in place. Making a false statement is often a crime. However, making a statement you believe is true that later turns out to be false may be defendable. How defendable depends on the information on which you based the statement. It’s not if you knew, but whether you should have known. In other words, simply asking someone if the controls are in place is not sufficient.

Controls are rarely purely manual or automated. In many cases, they are a hybrid containing both automated and manual. For example, access rights reviews may be automated to send a generated list of access to be sent to a manager for a manual review. In this case, there are elements of both reducing the cost of generating the access list through automation and leveraging manual processes to yield the human judgment on the appropriateness of the access given the user’s role.