Cloud Computing

amcqwy3c

Chapter_14.pptx

Home >Information Systems homework help >Cloud Computing

William Stallings Effective Cybersecurity 1st Edition

Lecture slides prepared for “Effective Cybersecurity”, 1/e, by William Stallings.

Chapter 14

Technical Security Management

The term technical security is often used to contrast software- and hardware-based security controls with management and operational security controls. Technical security management refers to the overall development of a management plan and policies to effectively manage the design, implementation and evaluation of technical security controls. For example, the use of virtual private networks and firewalls are technical security controls; training employees in acceptable use policies, security auditing, and the development of a security governance structure are nontechnical security controls.

The Information Security Forum’s (ISF’s) Standard of Good Practice for Information Security (SGP) divides technical security management into two main areas: security solutions and cryptography. With respect to security solutions, the SGP addresses the need for an overall security architecture to provide a framework for technical security control development and then details policies and procedures in specific technical areas (see Sections 14.1 through 14.7). For a detailed technical discussion of these topics, see Stallings and Brown’s Computer Security: Principles and Practice [STAL18].

With respect to cryptography, the SGP is concerned with developing management guidelines for the choice and use of cryptographic algorithms, for cryptographic key management, and for implementing a public key infrastructure (see Sections 14.8 through 14.10). For a detailed technical discussion of these topics, see Cryptography and Network Security by Stallings [STAL17].

Technical security controls

Security controls (that is, safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained in the hardware, software, or firmware components of the system

Technical security controls

Security controls (that is, safeguards or countermeasures) for an information system that are primarily implemented and executed by the information system through mechanisms contained

in the hardware, software, or firmware components of the system.

Security architecture

A security architecture is a unified security design that addresses the necessities and potential risks involved in a certain scenario or environment

It also specifies when and where to apply security controls

In a security architecture, the design principles are reported clearly, and in-depth security control specifications are generally documented in independent documents

A security architecture can be considered a design that includes a structure and addresses the connection between the components of that structure

A security architecture is a prescriptive document that uses a set of coherent models and principles to guide the implementation of the information security policy of an organization

A security architecture is a unified security design that addresses the necessities and potential risks involved in a certain scenario or environment. It also specifies when and where to apply security controls. The design process is generally reproducible. In a security architecture, the design principles are reported clearly, and in-depth security control specifications are generally documented in independent documents. A security architecture can be considered a design that includes a structure and addresses the connection between the components of that structure.

A security architecture is a prescriptive document that uses a set of coherent models and principles to guide the implementation of the information security policy of an organization.

Security architecture

A security architecture has the following key characteristics:

It consists of a transparent and coherent overview of models, principles, starting points, and conditions that give a concrete interpretation of the information security policy, usually without speaking in terms of specific solutions

It reduces a complex problem into models, principles, and subproblems to be understood

The models and principles show where you take which type of measures, when the principles are applicable, and how they connect with other principles

A security architecture has the following key characteristics:

It reduces a complex problem into models, principles, and subproblems to be understood.

The models and principles show where you take which type of measures, when the principles are applicable, and how they connect with other principles.

One of the most widely used security architectures is the Sherwood Applied Business Security Architecture (SABSA) Enterprise Security Architecture [SHER09]. SABSA was developed to provide an end-to-end framework for deter- mining, designing, and deploying security in a way that is traceably aligned with the business and into which the many traditional standards and processes can be incorporated. It is now widely recognized as the leading methodology for developing business operational risk-based architectures in general [BURK12, SHOR10]. SABSA takes a carefully designed and business-focused path from eliciting key business service requirements through to identifying the security architecture, services, mechanisms, and components needed to support the business while also addressing service management.

The SABSA model consists of five hierarchical layers, with a sixth layer spanning the other five (see Figure 14.1):

Contextual security architecture: This layer describes the key business issues, starting with the assets, the motivation for providing security, the business processes, the organization, geographic dispersion, and key time- related considerations in these processes. Business drivers—the desired outcomes for the business—are assets at the contextual layer, and they are determined from various sources, such as interviews and plans. The motivation for security is determined by looking at what regulations or risk factors are associated with the business drivers, and the business processes can be described.

Conceptual security architecture: The security characteristics of each of the business drivers are considered at the conceptual layer. For this purpose, an organization may use the SABSA information and communications technology (ICT) Business Attribute Taxonomy, a set of attributes described in business language that reflect security characteristics. The standard taxonomy has 53 such attributes, including the traditional security attributes confidentiality, availability, and integrity. By associating a set of these attributes with each business driver, you can define a security architecture in a way that provides full traceability back to business needs. At this layer, the security domains and associated policy architecture are defined, both of which are key to defining ownership so that correct security governance is applied. The architectural strategies are also defined in this layer—specifically, the risk/control strategy and compliance framework and the SABSA multitiered approach of deterrence, prevention, containment, detection, and recovery/restoration. Security performance and service level agreements (SLAs) are also defined at the conceptual layer.

Logical security architecture: This layer provides a design layer view, focusing on the delivery of services and information to meet the security concept.

Physical security architecture: This layer deals with the delivery of tangible items to support the logical services.

Component security architecture: This layer defines the hardware and tools to deliver the physical design and provides a mapping to conform to standards.

Security service management architecture: This layer addresses issues related to how the organization manages the architecture.

The most powerful tools in the SABSA architecture are attributes and attribute profiling. Attributes provide a conceptualized and normalized way of describing a business driver (a security-focused version of a business requirement). Normally one, two, or three words make up an attribute, such as available or access controlled, and the attribute is assigned to a business driver (which supports a business requirement). Attributes are used to tag aspects of the architectural design to allow two-way traceability up and down the layers to provide transparent traceability to the stakeholders and to understand the controls that support the various business requirements.

Table 14.1

The SABSA

Matrix for

Security

Architecture

(Table is on page 486 in the textbook)

An important guide to the use of SABSA is the SABSA security architecture matrix, shown in Table 14.1. Each row corresponds to one of the six layers of the architecture. The six columns define the key questions that need to be addressed at each level (what, why, how, who, where, and when). If an organization addresses the issues raised by each and every one of these cells, then it has covered the entire range of questions to be answered and can have a high level of confidence that the security architecture is complete. The SABSA process of developing enterprise security architecture is a process of populating all 36 of these cells.

The matrix also provides two-way traceability, as shown in Figure 14.1:

Completeness: Has every business requirement been met? The layers and matrix allow you to trace every requirement through to the components that provide a solution.

Justification: Is every component of the architecture needed? When someone asks “Why are you doing it this way?” the rationale is plain if you trace back to the business requirements that drive the specific solution.

malicious software (malware)

Software that exploits vulnerabilities in a computing system to create an attack

malicious software (malware)

Software that exploits vulnerabilities in a computing system to create an attack.

Malware protection activities

Malicious software (malware) is perhaps the most significant security threat to organizations

The National Institute of Standards and Technology (NIST) SP 800-83, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, defines malware as follows:

“A program that is covertly inserted into another program with the intent to destroy data, run destructive or intrusive programs, or otherwise compromise the confidentiality, integrity, or availability of the victim’s data, applications, or operating system”

Malware can pose a threat to application programs, to utility programs, and to kernel-level programs

Malware is also used on compromised or malicious websites and servers, or in especially crafted spam emails or other messages, which aim to trick users into revealing sensitive personal information

Malicious software (malware) is perhaps the most significant security threat to organizations. National Institute of Standards and Technology (NIST) SP 800-83, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, defines malware as follows:

malware: A program that is covertly inserted into another program with the intent to destroy data, run destructive or intrusive programs, or otherwise compromise the confidentiality, integrity, or availability of the victim’s data, applications, or operating system

Hence, malware can pose a threat to application programs, to utility programs (such as editors and compilers), and to kernel-level programs. Malware is also used on compromised or malicious websites and servers, or in especially crafted spam emails or other messages, which aim to trick users into revealing sensitive personal information.

Types of malware

Although the terminology related to malware is not consistent, the following list provides a useful guide to the various types of malware:

■ Adware: Advertising that is integrated into software. It can result in pop-up ads or redirection of a browser to a commercial site.

■ Auto-rooter: A malicious hacker tool used to break in to new machines remotely.

■ Backdoor (trapdoor): Any mechanisms that bypasses a normal security check; it may allow unauthorized access to functionality.

■ Exploit: Code specific to a single vulnerability or set of vulnerabilities.

■ Downloader: A program that installs other items on a machine that is under

attack. Usually, a downloader is sent in an email message.

■ Dropper: A malware installer that surreptitiously carries viruses, back- doors, and other malicious software to be executed on the compromised machine. Droppers don’t cause harm directly but deliver a malware payload onto a target machine without detection.

■ Polymorphic dropper: Also called a polymorphic packer, a software exploit tool that bundles several types of malware into a single package, such as an email attachment, and can force its “signature” to mutate over time, making it difficult to detect and remove.

Flooder: A tool used to attack networked computer systems with a large volume of traffic to carry out a denial-of-service (DoS) attack.

Keyloggers: A software tool that captures keystrokes on a compromised system.

Kit (virus generator): A set of tools for generating new viruses automatically.

Logic bomb: A program inserted into software by an intruder. A logic bomb lies dormant until a predefined condition is met, at which point the program triggers an unauthorized act.

Malware as a Service (MaaS): A web-based provider of malware. MaaS may provide access to botnets, support hotlines, and servers that regularly update and test malware strains for efficacy.

Mobile code: Software (for example, script, macro, or other portable instruc- tions) that can be shipped unchanged to a heterogeneous collection of plat- forms and execute with identical semantics.

Potentially unwanted program (PUP): A program that may be unwanted, despite the possibility that users consented to download it. PUPs include spyware, adware, and dialers and are often downloaded in conjunction with programs that users actually want.

Adware

Advertising that is integrated into software; it can result in pop-up ads or redirection of a browser to a commercial site

Auto-rooter

A malicious hacker tool used to break in to new machines remotely

Backdoor (trapdoor)

Any mechanism that bypasses a normal security check; it may allow unauthorized access to functionality

Exploit

Code specific to a single vulnerability or set of vulnerabilities

Downloader

A program that installs other items on a machine that is under attack; usually a downloader is sent in an email message

Dropper

A malware installer that surreptitiously carries viruses, back- doors, and other malicious software to be executed on the compromised machine; droppers don’t cause harm directly but deliver a malware payload onto a target machine without detection

Types of malware

■ Flooder: A tool used to attack networked computer systems with a large volume of traffic to carry out a denial-of-service (DoS) attack.

■ Keyloggers: A software tool that captures keystrokes on a compromised system.

■ Kit (virus generator): A set of tools for generating new viruses automatically.

■ Logic bomb: A program inserted into software by an intruder. A logic bomb lies dormant until a predefined condition is met, at which point the program triggers an unauthorized act.

■ Malware as a Service (MaaS): A web-based provider of malware. MaaS may provide access to botnets, support hotlines, and servers that regularly update and test malware strains for efficacy.

■Mobile code: Software (for example, script, macro, or other portable instructions) that can be shipped unchanged to a heterogeneous collection of plat- forms and execute with identical semantics.

■ Potentially unwanted program (PUP): A program that may be unwanted, despite the possibility that users consented to download it. PUPs include spyware, adware, and dialers and are often downloaded in conjunction with programs that users actually want.

Polymorphic dropper

Also called a polymorphic packer, a software exploit tool that bundles several types of malware into a single package, such as an email attachment, and can force its “signature” to mutate over time, making it difficult to detect and remove

Flooder

A tool used to attack networked computer systems with a large volume of traffic to carry out a denial-of-service (DoS) attack

Keyloggers

A software tool that captures keystrokes on a compromised system

Kit (virus generator)

A set of tools for generating new viruses automatically

Logic bomb

A program inserted into software by an intruder. A logic bomb lies dormant until a predefined condition is met, at which point the program triggers an unauthorized act

Malware as a Service (MaaS)

A web-based provider of malware. MaaS may provide access to botnets, support hotlines, and servers that regularly update and test malware strains for efficacy

Types of malware

■ Mobile code: Software (for example, script, macro, or other portable instructions) that can be shipped unchanged to a heterogeneous collection of platforms and execute with identical semantics.

■ Ransomware: A type of malware in which the data on a victim’s computer is locked, typically by encryption, and payment is demanded before the ransomed data is decrypted and access returned to the victim.

■ Remote access Trojan (RAT): A malware program that includes a back- door for administrative control over the target computer. RATs are usually downloaded invisibly with user-requested programs—such as games—or sent as email attachments.

■ Rootkit: A set of hacker tools used after attacker has broken into a computer system and gained root-level access.

■ Scraper: A simple program that searches a computer’s memory for sequences of data that match particular patterns, such as credit card numbers. Point-of- sale terminals and other computers usually encrypt payment card data when storing and transmitting it, and attackers often use scrapers to locate card numbers in memory before they are encrypted or after they are decrypted for processing.

Mobile code

Software that can be shipped unchanged to a heterogeneous collection of platforms and execute with identical semantics

Potentially unwanted program (PUP)

A program that may be unwanted, despite the possibility that users consented to download it; PUPs include spyware, adware, and dialers and are often downloaded in conjunction with programs that users actually want

Ransomware

A type of malware in which the data on a victim’s computer is locked, typically by encryption, and payment is demanded before the ransomed data is decrypted and access returned to the victim

Remote access Trojan (RAT)

A malware program that includes a back-door for administrative control over the target computer; RATs are usually downloaded invisibly with user-requested programs—such as games—or sent as email attachments

Rootkit

A set of hacker tools used after attacker has broken into a computer system and gained root-level access

Scraper

A simple program that searches a computer’s memory for sequences of data that match particular patterns; point-of- sale terminals and other computers usually encrypt payment card data when storing and transmitting it, and attackers often use scrapers to locate card numbers in memory before they are encrypted or after they are decrypted for processing

Types of malware

■ Spammer programs: Programs used to send large volumes of unwanted email.

■ Spyware: Software that collects information from a computer and transmits it to another system.

■ Trojan horse: A computer program that appears to have a useful function but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the Trojan horse program.

■ Virus: Malware that, when executed, tries to replicate itself into other executable code; when it succeeds, the code is infected. When the infected code is executed, the virus also executes.

Spammer programs

Programs used to send large volumes of unwanted email

Spyware

Software that collects information from a computer and transmits it to another system

Trojan horse

A computer program that appears to have a useful function but also has a hidden and potentially malicious function that evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes the Trojan horse program

Virus

Malware that, when executed, tries to replicate itself into other executable code; when it succeeds, the code is infected; when the infected code is executed, the virus also executes

Types of malware

■ Web drive-by: An attack that infects a user system when the user visits a web page.

■ Worm: A computer program that runs independently and propagates a complete working version of itself onto other hosts on a network.

■ Zombie, bot: A program that is activated on an infected machine to launch attacks on other machines.

Web drive-by

An attack that infects a user system when the user visits a web page

Worm

Zombie, bot

A program that is activated on an infected machine to launch attacks on other machines

A computer program that runs independently and propagates a complete working version of itself onto other hosts on a network

The nature of the malware threat

The European Union Agency for Network and Information Security’s annual threat report lists malware as the top cyber threat for 2016 and 2017. Key findings of the report include the following:

Businesses experienced far more malware threats in 2017 compared to 2016.

Ransomware continues to dominate the Windows malware scene, with an evolution from 55% in January 2017 to 75% in July 2017.

There is increasing threat from clickless malware, which is automated malware injection programs that do not require user action to activate.

There is also a rise in fileless malware, which is malware code that resides in RAM (random access memory) or propagates through the use of carefully crafted scripts, such as PowerShell, to infect its host.

There has been a growth of malicious functions being packaged within Potentially Unwanted Programs (PUPs). While legitimate browser developers like Firefox and Chrome are making efforts to tighten security, the adware industry is creating its own custom browsers without any built-in security features and bundling them along with adware applications. They will replace your own browser as the default browser and expose you to the greater risks of using such a browser.

The European Union Agency for Network and Information Security’s annual threat report [ENIS18] lists malware as the top cyber threat for 2016 and 2017. Key findings of the report include the following:

Businesses experienced far more malware threats in 2017 compared to 2016.

Ransomware continues to dominate the Windows malware scene, with an

evolution from 55% in January 2017 to 75% in July 2017.

There is increasing threat from clickless malware, which is automated malware injection programs that do not require user action to activate.

The battle against malware is never-ending. It is an ongoing arms race between malware producers and defenders. As effective countermeasures are developed for existing malware threats, newer types and modifications of existing types are developed. Malware enters through a variety of attack surfaces, including end-user devices, email attachments, web pages, cloud services, user actions, and removable media. Malware is designed to avoid, attack, or disable defenses. And malware is constantly evolving to stay ahead of existing defenses.

Given the complexity of the challenge, organizations need to automate anti- malware actions as much as possible. Figure 14.2, based on one in the Center for Internet Security’s The CIS Critical Security Controls for Effective Cyber Defense [CIS18}, indicates typical elements. Effective malware protection must be deployed at multiple potential points of attack. Enterprise endpoint security suites should provide administrative features to verify that all defenses are active and current on every managed system. There should be systems in place to collect ongoing incident results, with appropriate analysis and automated corrective action.

Practical malware protection

IT management can take a number of practical steps to provide the best possible protection, including:

Define procedures and responsibilities to deal with malware protection on systems

Where practical, do not grant administrative or root/superuser privileges to end users

Have a system and policies in place to keep track of where sensitive data is located, to erase data when no longer needed, and to concentrate security resources of systems that contain sensitive data

Conduct regular reviews of the software and data content of systems supporting critical business processes

Ensure that user and server platforms are well managed

Key staff should regularly participate in security training and awareness events that cover malware

Establish a formal policy prohibiting the use of unauthorized software

Install and appropriately maintain endpoint defenses

Use Domain Name System (DNS) based protection where practicable

Use web filtering software, services, or appliances where practical

Implement application whitelisting where practical to allow systems to run software only if it is included on the whitelist and prevent execution of all other software on the system

Implement controls that prevent or detect the use of known or suspected malicious websites

Employ software or services that enable you to know where you are vulnerable

Gather vulnerability and threat information from online sources

Monitor available logs and network activity for indicators of malicious software

Have a backup strategy for your systems; ensure that the backup stream is encrypted over the Internet and enterprise networks

Enable employees to report problems to IT security

IT management can take a number of practical steps to provide the best possible

protection at any given time, including the following:

Define procedures and responsibilities to deal with malware protection on systems, including training in their use, reporting, and recovering from malware attacks.

Where practical, do not grant administrative or root/superuser privileges to end users to limit the damage done by malware to gain the status of an authenticated user on a system.

Have a system and policies in place to keep track of where sensitive data is located, to erase data when no longer needed, and to concentrate security resources on systems that contain sensitive data. Section 14.6 elaborates on this topic.

Conduct regular reviews of the software and data content of systems supporting critical business processes; formally investigate the presence of any unapproved files or unauthorized amendments.

Ensure that user and server platforms are well managed, especially Windows platforms, which continue to be a major target. Tasks include:

Install security updates as soon as available. Patch management software and outsourced services help in this regard.

Enforce password selection policies to prevent password-guessing mal- ware from infecting systems.

Monitor systems for new unexplained listening network ports.

Key staff (for example, information security specialists, IT personnel responsible for system and application software) should regularly participate in security training and awareness events that cover malware.

Establish a formal policy (as part of acceptable use policy) prohibiting the use of unauthorized software.

Install and appropriately maintain endpoint defenses, including the following:

Use centrally managed antivirus and anti-spyware software where appropriate. An example is Microsoft System Center Endpoint Protection.

Enable and appropriately configure host-based firewalls where practical.

Enable and appropriately configure host-based intrusion prevention where practical.

Where feasible, make available protection software that is licensed for personal use.

Use Domain Name System (DNS)–based protection where practicable. A particular type of malware allows attackers to hijack the DNS settings of PCs, home gateways, and applications. Hijacking these settings allows an attacker to launch man-in-the-middle attacks against DNS transactions. These attacks overwrite DNS settings located on the subscriber’s computer or home gate- way to new fraudulent or malicious targets. This change effectively allows the attacker to take over (hijack) traffic for the unsuspecting Internet broadband consumer [MAAW10].

Use web filtering software, services, or appliances where practical. Examples of useful tools are the free Squid caching proxy, Forcepoint Web Security, and Microsoft Forefront Threat Management Gateway.

Implement application whitelisting where practical to allow systems to run software only if it is included on the whitelist and prevent execution of all other software on the system.

Implement controls that prevent or detect the use of known or suspected malicious websites (for example, blacklisting).

Employ software or services that enable you to know where you are vulnerable. Examples are Nmap, which is open source, and Metasploit, which has open source and commercial versions. Commercial tools include Nessus and Rapid7.

Gather vulnerability and threat information from online sources, as discussed in Chapter 3, “Information Risk Assessment.” Additional resources include:

Google’s hostmaster tools to scan your sites and report malware

DShield, a service of the Internet Storm Center that provides a variety of tools

15. Monitor available logs and network activity for indicators of malicious software. This includes:

Regularly check antivirus logs.

Regularly check DNS traffic for queries to known malware hosting domains.

Centralize event log management and apply appropriate logic to identify out-of-spec results. An example of a tool that facilitates this is Microsoft System Center Operations Manager.

Subscribe to Shadowserver notifications for networks you manage. The Shadowserver Foundation is an all-volunteer, nonprofit, vendor-neutral organization that gathers, tracks, and reports on malicious software, botnet activity, and electronic fraud. It discovers the presence of compromised servers, malicious attackers, and the spread of malicious software. This reporting service is provided free of charge and is designed for organizations that directly own or control network space. It allows them to receive customized reports detailing detected malicious activity to assist in their detection and mitigation programs.

Have a backup strategy for your systems, including PCs, servers, and data storage devices. Ensure that the backup stream is encrypted over the Internet and enterprise networks.

Enable employees to report problems to IT security. In this regard, useful measures are:

All relevant points of contact should have current information in whois. This is an Internet program that allows users to query a database of people and other Internet entities, such as domains, networks, and hosts. The information stored includes a person’s company name, address, phone number, and email address

Use standard abuse reporting addresses, as specified in RFC 2142, Mailbox Names for Common Services, Roles and Functions.

Make sure your domain or domains are available at the Network Abuse Clearinghouse, which enables targets to report the origin of an unwanted message.

The preceding list includes recommendations from ISO 27002, Code of Practice for Information Security Controls, the SGP, the Payment Card Industry Data Security Standard (PCI DSS), and COBIT 5. The list also includes additional recommendations.

Capabilities of malware protection software

There are numerous open source and commercial malware protection software packages available for enterprise use

SP 800-83 lists the following as desired capabilities in malware protection software:

Scanning critical host components such as startup files and boot records

Watching real-time activities on hosts to check for suspicious activity

Monitoring the behavior of common applications

Scanning files for known malware

Identifying common types of malware as well as attacker tools

Disinfecting files, (removing malware from within a file), and quarantining files, (files containing malware are stored in isolation for future disinfection or examination)

There are numerous open source and commercial malware protection software packages available for enterprise use, and most of them have similar capabilities. SP 800-83 lists the following as desired capabilities in malware protection software:

Scanning critical host components such as startup files and boot records.

Watching real-time activities on hosts to check for suspicious activity; a common example is scanning all email attachments for known malware as emails are sent and received. Configure anti-malware software to perform real-time scans of each file as it is downloaded, opened, or executed, which is known as on-access scanning.

Monitoring the behavior of common applications, such as email clients, web browsers, and instant messaging software. Monitor activity involving the applications most likely to be used to infect hosts or spread malware to other hosts with anti-malware software.

Scanning files for known malware. Configure anti-malware software on hosts to scan all hard drives regularly to identify any file system infections and, optionally, depending on organization security needs, to scan removable media inserted into the host before allowing its use. Users should also be able to launch a scan manually as needed, which is known as on-demand scanning.

Identifying common types of malware as well as attacker tools.

Disinfecting files, which refers to removing malware from within a file, and quarantining files, which means that files containing malware are stored in isolation for future disinfection or examination. Disinfecting a file is generally preferable to quarantining it because the malware is removed, and the original file restored; however, many infected files cannot be disinfected. Accordingly, configure anti-malware software to attempt to disinfect infected files and to either quarantine or delete files that cannot be disinfected.

Capabilities of malware protection software

Malware protection software does not provide the same level of protection against previously unknown viruses or other malware as it does against known threats and attack signatures

Accordingly, you should also have in place other measures, including:

Application sandboxing

Intrusion detection software to scan for anomalous behavior

Awareness training that provides guidance to users on malware incident prevention

Firewalls that by default deny unexpected behavior patterns

Application whitelisting to prevent intrusion of unknown software

Virtualization and container techniques to segregate applications or operating systems from each other

Malware protection software does not provide the same level of protection against previously unknown viruses or other malware as it does against known threats and attack signatures. Accordingly, you should also have in place other measures, including:

Application sandboxing, as discussed in Chapter 8, “System Development”

Intrusion detection software to scan for anomalous behavior

Awareness training that provides guidance to users on malware incident prevention

Firewalls that by default deny unexpected behavior patterns

Application whitelisting to prevent intrusion of unknown software

Virtualization and container techniques to segregate applications or operating systems from each other

Managing malware protection software

With any form of software that is installed on enterprise systems, you should have specific management policies for the life cycle of the software

Management policy should dictate the following measures for managing malware protection software:

Document procedures for selecting, installing, configuring, updating, and reviewing malware protection software

Deploy the software on all systems exposed to malware

Ensure that the installed suite of malware protection software protects against all forms of malware

Maintain a schedule for automatic and timely distribution of malware protection software

Configure malware protection software to be active at all times, provide notifications when suspected malware is detected, and remove malware and any associated files immediately upon detection

Review devices regularly to ensure that designated malware protection software is installed, enabled, and configured properly

With any form of software that is installed on enterprise systems, you should have specific management policies for the life cycle of the software. Management policy should dictate the following measures for managing malware protection software:

Document procedures for selecting, installing, configuring, updating, and reviewing malware protection software.

Deploy the software on all systems exposed to malware, including those that are connected to networks or the Internet, support the use of portable storage devices, or are accessed by multiple external suppliers.

Ensure that the installed suite of malware protection software protects against all forms of malware.

Maintain a schedule for automatic and timely distribution of malware protection software.

Configure malware protection software to be active at all times, provide notification when suspected malware is detected, and remove malware and any associated files immediately upon detection.

Review devices regularly to ensure that designated malware protection software is installed, enabled, and configured properly.

Identity and access management

The SGP defines identity and access management (IAM) as follows:

Identity and access management (IAM) typically consists of several discrete activities that follow the stages of a user’s life cycle within the organization. These activities fall into two categories:

Provisioning process, which provides users with the accounts and access rights they require to access systems and applications

User access process, which manages the actions performed each time a user attempts to access a new system, such as authentication and sign-on.

IAM addresses the mission-critical need to ensure appropriate access to resources across increasingly heterogeneous technology environments and to meet increasingly rigorous compliance requirements. This security practice is a crucial undertaking for any enterprise. It is increasingly business aligned and requires business skills, not just technical expertise. Enterprises that develop mature IAM capabilities reduce their identity management costs and, more importantly, become significantly more agile in supporting new business initiatives.

There are three deployment approaches for IAM:

Centralized: All access decisions, provisioning, management, and technology are concentrated in a single physical or virtual location. Policies, standards, and operations are pushed out from this single location.

Decentralized: Local, regional, or business units make the decisions for all access choices, provisioning, management, and technology. There may be enterprisewide policies and standards, but they provide guidance for the decentralized providers.

Federated: Each organization subscribes to a common set of policies, standards, and procedures for the provisioning and management of users. Alternatively, the organizations can buy a service from a supplier.

The SGP defines identity and access management (IAM) as:

There are three deployment approaches for IAM:

Centralized

All access decisions, provisioning, management, and technology are concentrated in a single physical or virtual location

Decentralized

Local, regional, or business units make the decisions for all access choices, provisioning, management, and technology

Federated

Each organization subscribes to a common set of policies, standards, and procedures for the provisioning and management of users

Provisioning process, which provides users with the accounts and access rights they require to access systems and applications

User access process, which manages the actions performed each time a user attempts to access a new system, such as authentication and sign-on

An architecture for identity and access management is a high-level model depicting the main elements and interrelationships of the IAM system. Figure 14.3 shows a typical architecture for an IAM system, whether centralized or decentralized.

Figure 14.3 includes the following elements:

■ Identity management service: Defines an identity for each user (human or process), associates attributes with the identity, and enforces a means by which a user verifies identity. The central concept of an identity management system is the use of single sign-on (SSO). SSO enables a user to access all network resources after a single authentication. The service implements facilities to enable user registration, changes in the user’s status or other details, and deregistration. Identity management enables creation, deletion, or modification of the user profile and change of the user’s role or association with a function, a business unit, or an organization.

■ Directory: Provides a central identity repository and reconciliation of identity details between application-specific directories. Some items to be stored for each user include the following:

■ User credentials, such as user ID, password, and possibly certificates to enable authentication

■ Attributes, such as roles and groups that form a basis for authorization

■ User preferences to enable personalization

■ An access control policy that defines access permissions for distinctive

data entries

■ Access management system: Implements user authentication.

■ Portal: Provides a personalized interface for all user interaction with system resources.

■. Provisioning services: Covers centralized user administration capabilities. Provisioning services serve to automate the task of changing users’ rights and privileges across multiple enterprise applications. They enable fast creation of new employee accounts and augment existing security practices by allowing administrators to quickly cut off terminated accounts.

single sign-on (SSO)

A security subsystem that enables a user identity to be authenticated at an identity provider— that is, at a service that authenticates and asserts the user’s identity—and then have that authentication be honored by other service providers

single sign-on (SSO)

Federated identity management

When multiple organizations implement interoperable federated identity schemes, an employee in one organization uses SSO to access services across the federation, via trust relationships associated with the identity

Beyond SSO, federated identity management provides a standardized means of representing attributes

Another key function is identity mapping; the federated identity management protocols map identities and attributes of a user in one domain to the requirements of another domain

Federated identity management refers to the agreements, standards, and technologies that enable the portability of identities, identity attributes, and entitlements across multiple enterprises and numerous applications and supporting many thousands— or even millions—of users. When multiple organizations implement interoperable federated identity schemes, an employee in one organization uses SSO to access services across the federation, via trust relationships associated with the identity. For example, an employee may log on to her corporate intranet and be authenticated to perform authorized functions and access authorized services on that intranet. The employee could then access her health benefits from an outside health care provider without having to re-authenticate.

Beyond SSO, federated identity management provides other capabilities. One is a standardized means of representing attributes. Increasingly, digital identities incorporate attributes other than simply an identifier and authentication information (such as passwords and biometric information). Examples of attributes include account numbers, organizational roles, physical location, and file ownership. A user may have multiple identifiers—perhaps associated with multiple roles—each with its own access permissions.

Another key function of federated identity management is identity mapping. Different security domains may represent identities and attributes differently. Further, the amount of information associated with an individual in one domain may be more than is necessary in another domain. The federated identity management protocols map identities and attributes of a user in one domain to the requirements of another domain.

Figure 14.4 illustrates entities and data flows in a generic federated identity management architecture.

The numbered links in Figure 14.4 indicate the following actions:

The end user’s browser or other application engages in an authentication dialogue with an identity provider in the same domain. The end user also provides attribute values associated with the user’s identity.

Some attributes associated with an identity, such as allowable roles, may be provided by an administrator in the same domain.

A service provider in a remote domain that the user wishes to access obtains identity information, authentication information, and associated attributes from the identity provider in the source domain.

The service provider opens a session with a remote user and enforces access control restrictions based on the user’s identity and attributes.

The identity provider acquires attribute information through dialogue and protocol exchanges with users and administrators. For example, a user needs to provide a shipping address each time an order is placed with a new web merchant, and this information needs to be revised when the user moves. Identity management enables the user to provide this information once, so that it is maintained in a single place and released to data consumers in accordance with authorization and privacy policies.

Service providers are entities that obtain and employ data maintained and provided by identity providers, often to support authorization decisions and to collect audit information. For example, a database server or file server is a data consumer that needs a client’s credentials in order to know what access to provide to that client. A service provider can be in the same domain as the user and the identity provider. The power of this approach is for federated identity management, in which the service provider is in a different domain (for example a vendor or supplier network).

The goal is to share digital identities so a user is authenticated once and then can access applications and resources across multiple domains, such as autonomous internal business units, external business partners, and other third-party applications and services. The cooperating organizations form a federation based on agreed standards and mutual levels of trust to securely share digital identities. Federated identity management reduces the number of authentications needed by a user.

Iam best practices

Make people your first line of defense; train staff to spot the warning signs of phishing attacks and social engineering

Patch promptly and completely

Encrypt sensitive data

Use multifactor authentication (MFA)

Implement least-privilege access controls

Implement controls and monitoring tools to access privileged systems and data

Protect your mobile and cloud applications

Stop breaches that start on endpoints

Implement portals for accessing the web as SaaS applications

Andy Zindel’s blog post “IAM Best Practices to Reduce Your Attack Surface” [ZIND17] provides a list of best practices for avoiding common security mistakes with IAM, based on experience by Verizon and Centrify, a security services firm:

■ Make people your first line of defense: Train staff to spot the warning signs of phishing attacks and social engineering.

■ Patch promptly and completely: This helps guard against many attacks.

■ Encrypt sensitive data: Make your data next to useless if it is stolen.

■ Use multifactor authentication (MFA): Limit the damage that can be done with lost or stolen credentials.

■ Implement least-privilege access controls: Make sure that only staff who need access to systems to do their jobs actually have it. This reduces insider abuse and accidental data leakage.

■ Implement controls and monitoring tools to access privileged systems and data: Stay informed about who accesses what data when and be alerted when suspicious activities occur. Log files and analytics systems provide early warnings of breaches.

■ Protect your mobile and cloud applications: Improve security with context- based adaptive MFA and eliminate the use of easy-to-remember, reused, and/or improperly stored passwords to secure app access.

■ Stop breaches that start on endpoints: Grant access to apps and infra- structure only from trusted and secured endpoints. Manage and secure your heterogeneous endpoints through a single source of identity and a least- privilege access model.

■ Implement portals for accessing the web as SaaS applications: Improve end-user productivity and secure every user’s access to apps through federated SSO to eliminate the risk of redirection to phishing websites.

Intrusion detection

Intrusion

Violations of security policy, usually characterized as attempts to affect the confidentiality, integrity, or availability of a computer or network

Intrusion detection

The process of collecting information about events occurring in a computer system or network and analyzing them for signs of intrusions

Intrusion detection system (IDS)

Hardware or software products that gather and analyze information from various areas within a computer or a network for the purpose of finding and providing real-time or near-real-time warning of attempts to access system resources in an unauthorized manner

Host-based IDS

Monitors the characteristics of a single host and the events occurring within that host for suspicious activity

Network-based IDS

Monitors network traffic for particular network segments or devices and analyzes network, transport, and application protocols to identify suspicious activity

It is useful to begin by defining the following terms:

■ Intrusion: Violations of security policy, usually characterized as attempts to affect the confidentiality, integrity, or availability of a computer or network. These violations come from attackers accessing systems from the Internet or from authorized users of the systems attempting to overstep their legitimate authorization levels or using their legitimate access to the system to conduct unauthorized activity.

■ Intrusion detection: The process of collecting information about events occurring in a computer system or network and analyzing them for signs of intrusions.

■ Intrusion detection system (IDS): Hardware or software products that gather and analyze information from various areas within a computer or a network for the purpose of finding and providing real-time or near-real-time warning of attempts to access system resources in an unauthorized manner.

■ Host-based IDS: Monitors the characteristics of a single host and the events occurring within that host for suspicious activity. This vantage point allows host-based IDSs to determine exactly which processes and user accounts are involved in a particular attack on the operating system. Furthermore, unlike network-based IDSs, host-based IDSs more readily see the intended outcome of an attempted attack because they directly access and monitor the data files and system processes usually targeted by attacks.

■ Network-based IDS: Monitors network traffic for particular network segments or devices and analyzes network, transport, and application protocols to identify suspicious activity.

Intrusion detection system

An IDS comprises three logical components:

Sensors

Sensors are responsible for collecting data

The input for a sensor is any part of a system that contains evidence of an intrusion

Types of input to a sensor include network packets, log files, and system call traces

Sensors collect and forward this information to an analyzer

Analyzers

Analyzers receive input from one or more sensors or from other analyzers

The analysis engines are responsible for determining if an intrusion has occurred

The output of this component may include evidence supporting the conclusion that an intrusion occurred

The analyzer provides guidance about what actions to take as a result of an intrusion

User interface

The user interface to an IDS enables a user to view output from the system or control the behavior of the system

In some systems, the user interface may equate to a manager, director, or console component

An IDS comprises three logical components:

Sensors: Sensors are responsible for collecting data. The input for a sensor is any part of a system that contains evidence of an intrusion. Types of input to a sensor include network packets, log files, and system call traces. Sensors collect and forward this information to an analyzer.

Analyzers: Analyzers receive input from one or more sensors or from other analyzers. The analysis engines are responsible for determining if an intrusion has occurred. The output of this component may include evidence supporting the conclusion that an intrusion occurred. The analyzer provides guidance about what actions to take as a result of an intrusion.

User interface: The user interface to an IDS enables a user to view output from the system or control the behavior of the system. In some systems, the user interface may equate to a manager, director, or console component.

Intrusion detection assumes that the behavior of the intruder differs from that of a legitimate user in ways that are quantifiable. Of course, you cannot expect that there will be a crisp, exact distinction between an attack by an intruder and the normal use of resources by an authorized user. Rather, you must expect that there will be some overlap.

There are two general approaches to intrusion detection: misuse detection and anomaly detection (see Figure 14.5).

Misuse detection is based on rules that specify system events, sequences of events, or observable properties of a system that are believed to be symptomatic of security incidents. Misuse detectors use various pattern-matching algorithms, operating on large databases of attack patterns, or signatures. An advantage of misuse detection is that it is accurate and generates few false alarms. A disadvantage it that it cannot detect novel or unknown attacks.

Anomaly detection involves searching for activity that is different from the normal behavior of system entities and system resources. An advantage of anomaly detection is that it is able to detect previously unknown attacks based on an audit of activity. A disadvantage is that there is a significant trade-off between false positives and false negatives.

Figure 14.6 suggests, in abstract terms, the nature of the task confronting the designer of an anomaly detection system. Although the typical behavior of an intruder differs from the typical behavior of an authorized user, there is some overlap in these behaviors. Thus, a loose interpretation of intruder behavior, which catches more intruders, also leads to a number of false positives, or authorized users identified as intruders. On the other hand, an attempt to limit false positives by a tight interpretation of intruder behavior leads to an increase in false negatives, or intruders not identified as intruders. Thus, there is an element of compromise and art in the practice of anomaly detection.

Table 14.2 Test Outcomes

(Table is on pages 505 in the textbook)

Table 14.2 clarifies the relationship between the terms false positive, true positive, false negative, and true negative.

Host-based intrusion detection techniques

Host-based IDSs:

Add a specialized layer of security software to vulnerable or sensitive systems

Monitors activity on a system in a variety of ways to detect suspicious behavior

The primary purpose is to detect intrusions, log suspicious events, and send alerts

The primary benefit is that it detects both external and internal intrusions—something that is not possible either with network-based IDSs or firewalls

Use either anomaly or misuse protection or a combination of the two

For anomaly detection, two common strategies are threshold detection (this approach involves defining thresholds, independent of the user, for the frequency of occurrence of various events) and profile based (A profile of the activity of each user is developed and used to detect changes in the behavior of individual accounts)

Host-based IDSs add a specialized layer of security software to vulnerable or sensitive systems; examples include database servers and administrative systems. A host-based IDS monitors activity on a system in a variety of ways to detect suspicious behavior. In some cases, an IDS halts an attack before any damage is done, but its primary purpose is to detect intrusions, log suspicious events, and send alerts.

The primary benefit of a host-based IDS is that it detects both external and internal intrusions—something that is not possible either with network-based IDSs or firewalls.

Host-based IDSs use either anomaly or misuse protection or a combination of the two. For anomaly detection, two common strategies are:

Threshold detection: This approach involves defining thresholds, independent of the user, for the frequency of occurrence of various events.

Profile based: A profile of the activity of each user is developed and used to detect changes in the behavior of individual accounts.

Network-based intrusion detection systems

A network-based IDS (NIDS) monitors the traffic on the network segment as a data source

Network-based intrusion detection involves looking at the packets on a network as they pass by some sensor

Packets are considered to be of interest if they match a signature

Three primary types of signatures are:

String signatures (looks for a text string that indicates a possible attack)

Port signatures (watches for connection attempts to well-known, frequently attacked ports)

Header condition signatures (watches for dangerous or illogical combinations in packet headers)

A network-based IDS (NIDS) monitors the traffic on the network segment as a data source. This is generally accomplished by placing the network interface card in promiscuous mode to capture all network traffic that crosses its network segment. Network traffic on other segments and traffic on other means of communication (such as phone lines) can’t be monitored by a single NIDS.

Network-based intrusion detection involves looking at the packets on a network as they pass by some sensor. Packets are considered to be of interest if they match a signature. Three primary types of signatures are string signatures, port signatures, and header condition signatures.

A string signature looks for a text string that indicates a possible attack. An example of a string signature for UNIX might be “cat “+ +” > /.rhosts”, which, if successful, might cause a UNIX system to become extremely vulnerable to network attack. To refine the string signature to reduce the number of false positives, it may be necessary to use a compound string signature. A compound string signature for a common web server attack might be “cgi-bin” AND “aglimpse” AND “IFS”.

A port signature watches for connection attempts to well-known, frequently attacked ports. Examples of these ports include those for Telnet (TCP port 23), FTP (TCP port 21/20), SUNRPC (TCP/UDP port 111), and IMAP (TCP port 143). If any of these ports are not used by the site, then incoming packets to these ports are suspicious.

A header signature watches for dangerous or illogical combinations in packet headers. The most famous example is WinNuke, where a packet was destined for a NetBIOS port and the urgent pointer, or out-of-band pointer, was set. This resulted in the “blue screen of death” for Windows systems. Another well-known header signature is a Transmission Control Protocol (TCP) packet with both the synchronize (SYN) and finished (FIN) flags set, signifying that the requestor wishes to start and stop a connection at the same time.

A NIDS sensor sees only the packets that are carried on the network segment to which it is attached. Accordingly, a NIDS deployment is typically set up as a number of sensors distributed on key network points to passively gather traffic data and feed information on potential threats to a central NIDS manager. Figure 14.7 provides examples of NIDS sensor.

There are four types of locations for the sensors:

■ Outside the main enterprise firewall: This placement is useful for establish- ing the level of threat for a given enterprise network. Those responsible for winning management support for security efforts find this placement valuable.

■ In the network demilitarized zone (DMZ), inside the main firewall but outside internal firewalls: This location monitors for penetration attempts that target web and other services that are generally open to outsiders.

■ Behind internal firewalls: A sensor can be positioned to monitor major backbone networks, such as those that support internal servers and database resources.

■ Behind internal firewalls: A sensor can be positioned to monitor LANs that support user workstations and servers specific to single departments. Locations 3 and 4 in Figure 14.7 can monitor for more specific attacks at network segments, as well as attacks originating from inside the organization.

Demilitarized zone (DMZ)

A perimeter network segment that is physically or logically between internal and external networks. The DMZ adds an additional layer of network security between the Internet and an organization’s internal network so that external parties only have direct connections to devices in the DMZ rather than to the entire internal network. This provides external, untrusted sources with restricted access to releasable information while shielding the internal networks from outside attacks

Demilitarized zone (DMZ)

Ids best practices

Create separate accounts for each IDS user and administrator

Restrict network access to IDS components

Ensure that IDS management communications are protected appropriately

Back-up IDS configuration settings periodically and before applying updates

Monitor and tune one IDS sensor at a time

Have alerts of a certain priority sent directly to a security administrator

Employ a log and alert correlation product in conjunction with the IDS

Have a system in place to ensure that IDS event logs are reviewed regularly

The following are some suggestions that security managers may find helpful:

■ Create separate accounts for each IDS user and administrator.

■ Restrict network access to IDS components

■ Ensure that IDS management communications are protected appropriately, such as encrypting them or transmitting them over a physically or logically separate network.

■ Back-up IDS configuration settings periodically and before applying updates to ensure that existing settings are not inadvertently lost.

■ Monitor and tune one IDS sensor at a time to prevent security staff from being overwhelmed by alerts and false positives.

■ Have alerts of a certain priority sent directly to a security administrator so attacks are quickly known or when other events might require administration attention. To reduce the noise, set alerts only to the risks the enterprise is most concerned about and don’t rely on out-of-the box settings.

■ Employ a log and alert correlation product (such as a security information event management [SIEM]system) in conjunction with the IDS. These correlation products do several things. First, they group alerts to reduce alert traffic. Instead, batches of alerts or events arrive in more manageable increments. They also provide insight across multiple platforms, including network and host IDSs, firewalls, and syslog events from other systems.

■ Have a system in place to ensure that IDS event logs are reviewed regularly. An example of such a product is Sguil, which is a free set of software packages.

A useful resource is SP 800-94, Guide to Intrusion Detection and Prevention Systems, which contains a tutorial on IDS function and a range of recommendations related to the procurement and management of IDSs.

Data loss prevention

Data loss is intentional or unintentional release of information to an untrusted environment. Data loss prevention (DLP), also referred to as information leakage, refers to a comprehensive approach covering people, processes, and systems that identify, monitor, and protect data in use (for example, endpoint actions), data in motion (for example, network actions), and data at rest (for example, data storage) through deep content inspection and with a centralized management framework. Over the past several years, there has been a noticeable shift in attention and investment from securing the network to securing systems within the network and to securing the data itself. DLP controls are based on policy and include classifying sensitive data, discovering data across an enterprise, enforcing controls, and reporting and auditing to ensure policy compliance. Sensitive information that is at risk of leakage or is actually leaked often includes shared and unencrypted content such as word processing documents, presentation files, and spreadsheets that could leave an organization via many different points or channels (for example, via email, instant messaging, Internet browsing, mobile devices, or on portable storage devices).

Data loss is intentional or unintentional release of information to an untrusted environment

Data loss prevention (DLP), also referred to as information leakage, refers to a comprehensive approach covering people, processes, and systems that identify, monitor, and protect data in use and data at rest through deep content inspection and with a centralized management framework

DLP controls are based on policy and include classifying sensitive data, discovering data across an enterprise, enforcing controls, and reporting and auditing to ensure policy compliance

Data classification and identification

Rule-based recognition

This technique efficiently identifies data blocks, files, database records, and so on that contain easily recognized sensitive data

Database fingerprinting

This technique searches for exact matches to data loaded from a database; this is a time-consuming technique but has a very low false positive rate

Exact file matching

This technique involves computing the hash value of a file and monitoring for any files that match the exact fingerprint; it is easy to implement and checks whether a file has been accidentally stored or transmitted in an unauthorized manner

Partial document matching

This technique involves looking for a partial match on a protected document. It involves the use of multiple hashes on portions of the document, such that if a portion of the document is extracted and filed elsewhere or pasted into an email, it can be detected. This technique is useful for protecting sensitive documents

All sensitive data within an enterprise needs to be protected at all times and in all places. As a first step, an enterprise needs to define what is sensitive data and, if necessary, establish different levels of sensitive data. Then there is a need to recognize sensitive data wherever it is encountered in the enterprise. Finally, there must be applications that recognize sensitive data in real time. The following are common approaches to the recognition task [MOGU07]:

■ Rule-based recognition: Regular expressions, keywords, and other basic pattern-matching techniques are best suited for basic structured data, such as credit card and Social Security numbers. This technique efficiently identifies data blocks, files, database records, and so on that contain easily recognized sensitive data.

■ Database fingerprinting: This technique searches for exact matches to data loaded from a database, which can include multiple field combinations, such as name, credit card number, and CVV number. For example, a search could look only for credit card numbers in the customer base, thus ignoring employees buying online. This is a time-consuming technique but has a very low false positive rate.

■ Exact file matching: This technique involves computing the hash value of a file and monitoring for any files that match the exact fingerprint. It is easy to implement and checks whether a file has been accidentally stored or transmitted in an unauthorized manner. However, unless a more time-consuming cryptographic hash function is used, this is trivial for an attacker to evade.

■ Partial document matching: This technique involves looking for a partial match on a protected document. It involves the use of multiple hashes on portions of the document, such that if a portion of the document is extracted and filed elsewhere or pasted into an email, it can be detected. This technique is useful for protecting sensitive documents.

hash value

A numeric value produced by a mathematical function that generates a fixed- length value typically much smaller than the input to the function. The function is many-to-one, but generally, each file or other data block input to a hash function yields a unique hash value

hash value

A numeric value produced by a mathematical function that generates a fixed- length value typically much smaller than the input to the function. The function is many-to- one, but generally, each file or other data block input to a hash function yields a unique hash value.

Data states

Key to effective DLP is to develop an understanding of the places and times at which data are vulnerable

A useful way of managing DLP is to categorize data

The three states and three key DLP objectives are:

Data at rest

Locate and catalog sensitive information stored throughout the enterprise

Data in motion (or transit)

Monitor and control the movement of sensitive information across enterprise networks

Data in use

Monitor and control the movement of sensitive information on end-user systems

Key to effective DLP is to develop an understanding of the places and times at which data are vulnerable. A useful way of managing DLP is to categorize data into three states: data in motion, data at rest, and data in use. Corresponding to these three states are three key DLP objectives:

Data at rest: Locate and catalog sensitive information stored throughout the enterprise.

Data in motion (or transit): Monitor and control the movement of sensitive information across enterprise networks.

Data in use: Monitor and control the movement of sensitive information on end-user systems.

Data at rest presents significant risk for enterprises. A large enterprise may have millions of files and database records on drives and removable media. A particular set of data files or records may have a “home” location, but portions of that data may also migrate to other storage locations, and this situation, if not monitored and controlled, quickly becomes unmanageable. One example of how data is replicated and proliferated is file sharing. With networked computer systems, file sharing for collaborative projects is common, but this may mean that the owner or creator of a file has no idea of what happened to the file after sharing it. The same risk exists with the many web-based collaboration and document management platforms in common use.

The fundamental task of DLP for data at rest is to identify and log where specific types of information are stored throughout the enterprise. The DLP unit uses some sort of data discovery agent that performs actions, as shown in Figure 14.8.

These actions are as follows:

Seek out and identify specific file types, such as spreadsheets, word processing documents, email files, and database records. The search activity encompasses files servers, storage area networks, network attached storage, and endpoint systems.

Once files are found, the agent must be able to open each file to scan the content for specific types of information.

The agent logs files that contain information of security relevance, and may issue alerts if a security policy is violated.

Port mirror

A cross-connection of two or more ports on a network switch so that traffic is simultaneously sent to a network analyzer or monitor connected to another port

port mirror

A cross-connection of two or more ports on a network switch so that traffic is simultaneously sent to a network analyzer or monitor connected to another port .

Data in motion

The term data in motion refers to data transmitted over enterprise networks and between the enterprise networks and external network links

Data-in-motion solutions operate in one of two modes:

Passive monitoring

Observes a copy of data packets as they move across a network link

This is done by a port mirror on a switch or a network line tap

Packets or sequences of packets containing information of interest are logged, and security violations trigger an alert

Active monitoring

Interposes a relay or gateway type of device on a network line to analyze and forward data packets

The active monitor logs and issues alerts but can also be configured to block data flows that violate a security policy

The term data in motion refers to data transmitted over enterprise networks and between the enterprise networks and external network links. Data-in-motion solutions operate in one of two modes:

■ Passive monitoring: Observes a copy of data packets as they move across a network link. This is done by a port mirror on a switch or a network line tap. Packets or sequences of packets containing information of interest are logged, and security violations trigger an alert.

■ Active monitoring: Interposes a relay or gateway type of device on a network line to analyze and forward data packets (refer to Figure 14.8). The active monitor logs and issues alerts but can also be configured to block data flows that violate a security policy.

To inspect the information being sent across the network, the DLP solution must be able to monitor the network traffic, recognize the correct data streams to capture, assemble the collected packets, reconstruct the files carried in the data stream, and then perform the same analysis that is done on the data at rest to determine whether any portion of the file contents is restricted by its rule set.

Data in use

Data-in-use solutions generally involve installing DLP agent software on endpoint systems

The agent monitors, reports, blocks, or quarantines the use of particular kinds of data files and/or the contents of a file

The agent also maintains an inventory of files on the hard drives and removable media that is plugged in to the endpoint

The agent either allows or disallows certain types of removable media, such as requiring that the removable device support encryption

Data-in-use solutions generally involve installing DLP agent software on endpoint systems. The agent monitors, reports, blocks, or quarantines the use of particular kinds of data files and/or the contents of a file. The agent also maintains an inventory of files on the hard drives and removable media that is plugged in to the endpoint. The agent either allows or disallows certain types of removable media, such as requiring that the removable device support encryption

Digital rights management

Digital rights management (DRM) refers to systems and procedures which ensure that holders of digital rights are clearly identified and receive the stipulated payment for their works

The systems and procedures can also impose further restrictions on the use of digital objects, such as inhibiting printing or prohibiting further distribution

There is no single DRM standard or architecture

DRM systems should meet the following objectives:

Provide persistent content protection against unauthorized access to the digital content

Support a variety of digital content types

Provision content use on a variety of platforms

Facilitate content distribution on a variety of media

Digital rights management (DRM) refers to systems and procedures which ensure that holders of digital rights are clearly identified and receive the stipulated payment for their works. The systems and procedures can also impose further restrictions on the use of digital objects, such as inhibiting printing or prohibiting further distribution.

There is no single DRM standard or architecture. DRM encompasses a variety of approaches to intellectual property management and enforcement by providing secure and trusted automated services to control the distribution and use of content. In general, the objective is to provide mechanisms for the complete content management life cycle (creation, subsequent contribution by others, access, distribution, use), including the management of rights information associated with the content.

DRM systems should meet the following objectives:

■ Provide persistent content protection against unauthorized access to the digital content, limiting access to only those with the proper authorization.

■ Support a variety of digital content types (for example, music files, video streams, digital books, images).

■ Provision content use on a variety of platforms (for example, PCs, tablets, mobile phones).

■ Facilitate content distribution on a variety of media (for example, CD-ROMs, DVDs, flash memory).

DRM is best understood in terms of the key components of a DRM system and their interconnections. Figure 14.9 illustrates a typical DRM model in terms of the principal users of DRM systems.

The principal users of DRM systems are as follows:

Content provider: Holds the digital rights to the content and wants to protect these rights. Examples are a music record label and a movie studio.

Distributor: Provides distribution channels, such as an online shop or a web retailer. For example, an online distributor receives the digital content from the content provider and creates a web catalog presenting the content and rights metadata for the content promotion.

Consumer: Uses the system to access the digital content by retrieving down- loadable or streaming content through the distribution channel and then paying for the digital license. The player/viewer application used by the consumer takes charge of initiating license request to the clearinghouse and enforcing the content usage rights.

Clearinghouse: Handles the financial transaction for issuing the digital license to the consumer and pays royalty fees to the content provider and distribution fees to the distributor accordingly. The clearinghouse is also responsible for logging license consumptions for the individual consumers.

In this model, the distributor need not enforce the access rights. Instead, the content provider can protect the content in such a way (typically encryption) that the consumer must purchase a digital license and access capability from the clearing-house. The clearinghouse consults usage rules provided by the content provider to determine what access is permitted and the fee for a particular type of access. Having collected the fee, the clearinghouse credits the content provider and distributor appropriately.

Figure 14.10 shows a generic system architecture that supports DRM functionality. The system is access by parties in three roles. Rights holders are the content providers, who either created the content or have acquired rights to the content. Service providers include distributors and clearinghouses. Consumers are those who purchase the right to access to content for specific uses.

The following services are provided by a DRM system:

Identity management: Mechanisms to uniquely identify entities, such as parties and content

Content management: Processes and functions needed to manage the content lifestyle

Rights management: Processes and functions needed to manage rights, rights holders, and associated requirements

Each management module is a set of common functions. The security/encryption module provides functions to encrypt content and to sign license agreements. The identity management service makes use of the authentication and authorization functions to identify all parties in the relationship. Using these functions, the identity management service includes the following:

Allocation of unique party identifiers

User profiles and preferences

User device management

Public key management

Billing/payments functions deal with the collection of usage fees from consumers and the distribution of payments to rights holders and distributors. Delivery functions deal with the delivery of content to consumers.

Drm best practices

Create a document classification matrix prior to implementing the solution

Begin user education to obtain employee buy-in

Recognize where the existing data resides and how those data are classified

Identify top data loss scenarios

Ensure that data owners and IT can easily monitor sensitive file usage

Strive to make the DRM system user-friendly

Review logs and alerts regularly and address suspicious events

Regularly carry out gap analysis that details the differential between the organization’s current risk level for data loss and the organization’s acceptable risk level

A report from NSS Labs [BAYL13] lists the following DRM best practices:

■ Create a document classification matrix prior to implementing the solution. This matrix should classify data types according to risk and is usually com- posed of either three or five classifications, with public data having a score of 1, and highly classified material having the highest rating. Each data classification should include mandatory controls that cover data protection while at rest and when in motion, with more sensitive data requiring rigorous access and audit logs. Integrate this classification matrix with existing authentication systems, such as password, MFA, or SSO. This ensures that only active accounts are able to access sensitive documents and also provides an audit trail from an official system of record (SOR).

■ Begin user education to obtain employee buy-in. This is critical to ensure protection of existing data and of newly created data. A risk-based approach is favored here, where those with regular access to confidential data should be thoroughly trained in their responsibilities. Users must understand the risk of data loss and the repercussions to their organization as a result of this data loss. Data owners must be responsible for appropriate labeling and protection of their data, and they should be familiarized with the relevant management-endorsed policies. Before deploying DLP or DRM systems, enterprises should attempt to manage contractor, partner, and/or employee use of public cloud systems (for example, Dropbox, iCloud) for storage of corporate data.

■ Recognize where the existing data resides and how those data are classified. Interview executives and peers to understand data flows within and outside the network. Examine controls and data stores currently in place. Seek out unprotected copies of confidential data; this data should be protected or deleted. Focus on first protecting the most sensitive category of data. In large enterprises, it is advisable to start with the highest-risk documents that are most likely to be exposed to greater risk (for example, be sent to an outside entity that is not fully trusted). Only when the most sensitive category of data has been protected throughout the enterprise is it safe to move to the next tier.

■ Identify top data loss scenarios. Knowledge of where data is, what form it takes, and who has access to this data will enable creation of tailored controls. These controls reduce the risk of data loss and lessen the damage resulting from such data loss scenarios. This measure requires a thorough understanding of business needs and practices, regulatory requirements, risk, and likely repercussions of data loss. Be sure to clearly define the classes of violation and specify real repercussions for offenders. Have documentation from HR, legal personnel, and senior management that supports the stipulation that rule violations will result in appropriate penalties. Users working with highly sensitive data must ensure that all confidential work is protected by DRM, even when documents are in draft stage.

■ Ensure that data owners and IT can easily monitor sensitive file usage; this monitoring of usage will increase knowledge of data usage within the organization. DRM tools should also be leveraged to gain visibility into data flowing across internal networks and to the Internet.

■ Strive to make the DRM system user-friendly. Requiring license verification each time a document is opened is good practice for high-security documents or for documents that need to be revoked instantly. However, be aware that requiring license checks creates access issues because these documents can never be used offline. There is an element of risk in that a previously unauthorized user is able to access the documents during this window of time. Time windows should be configured according to a document’s sensitivity and the organization’s appetite for risk.

■ Review logs and alerts regularly and address suspicious events. Modern DRM solutions enable control of documents even after they have been sent outside the enterprise or downloaded to a recipient’s end device. Document control enables users to specify granular control, which includes enabling or restricting recipients from viewing, printing, and copying content. Document permissions are dynamic (the document calls home to obtain updated permissions), and can be modified by the DRM administrator or document owner at any time. Document tracking enables users to follow documents after they have been sent. A full audit log details who opened a document, when, where, and on which device. Some solutions provide a geographic display that shows exactly where a document is being opened. This feature helps prompt investigation if, x for example, a sensitive document being accessed by a user at HQ is simultaneously being accessed using the same credentials at a different geo- graphic location.

■ Regularly carry out gap analysis that details the differential between the organization’s current risk level for data loss and the organization’s acceptable risk level. In DRM, it is often difficult to decide if there is an appropriate balance between protecting sensitive documents and keeping the permissions appropriate. If additional rules, policies, training, procedures, or technologies are warranted, these can be implemented, once they are endorsed by executive stakeholders.

Uses of cryptography

Cryptography is used to protect data at rest and data in motion, both inside and outside the boundaries of an enterprise’s IT system

Four uses for cryptography are:

Data encryption

Data encryption is a powerful and cost-effective means of providing data confidentiality and integrity

Once data are encrypted, the ciphertext does not have to be protected against disclosure

Data encryption is especially useful for transmitting data over the Internet or other network outside the control of the enterprise and also for storage in the cloud

Data integrity

Cryptographic algorithms provide an effective way to determine whether a block of data was altered in an unauthorized manner

Digital signature

The digital signature, or electronic signature, is the electronic equivalent of a written signature

In addition to ensuring data integrity, digital signature algorithms provide a means of linking a document with a particular entity, as is done with a written signature

User authentication

Cryptography is the basis for several advanced authentication methods

Instead of communicating passwords over an open network, authentication involves demonstrating knowledge of a cryptographic key

Using such a method, a one-time password that is not susceptible to eavesdropping is used

Cryptography is used to protect data at rest and data in motion, both inside and outside the boundaries of an enterprise’s IT system. Within a system, logical and physical access control, intrusion detection, firewall, and other security controls—possibly supplemented by cryptography—provide sufficient protection. But outside the control of the enterprise, using cryptography is often the only way to protect data. Four uses for cryptography predominate:

Data encryption: Data encryption is a powerful and cost-effective means of providing data confidentiality and integrity. Once data are encrypted, the ciphertext does not have to be protected against disclosure. Further, if ciphertext is modified, it does not decrypt correctly. Data encryption is especially useful for transmitting data over the Internet or other network outside the control of the enterprise and also for storage in the cloud.

Data integrity: Cryptographic algorithms provide an effective way to determine whether a block of data (for example, email text, message, file, database record) was altered in an unauthorized manner.

Digital signature: The digital signature, or electronic signature, is the electronic equivalent of a written signature that is recognized as having the same legal status as a written signature. In addition to ensuring data integrity, digital signature algorithms provide a means of linking a document with a particular entity, as is done with a written signature.

User authentication: Cryptography is the basis for several advanced authentication methods. Instead of communicating passwords over an open network, authentication involves demonstrating knowledge of a cryptographic key. Using such a method, a one-time password that is not susceptible to eavesdropping is used.

Cryptographic algorithm

An algorithm that uses the science of cryptography, including encryption algorithms, cryptographic hash algorithms, digital signature algorithms, and key-agreement algorithms

cryptographic algorithm

An algorithm that uses the science of cryptography, including encryption algorithms, cryptographic

hash algorithms, digital signature algorithms, and key-agreement algorithms.

Symmetric encryption, also referred to as conventional encryption, is a cryptographic scheme in which encryption and decryption are performed using the same key. A symmetric encryption scheme has five ingredients, as shown in Figure 14.11a:

■ Plaintext: This is the original message or data block that is fed into the algorithm as input.

■ Encryption algorithm: The encryption algorithm performs various substitutions and transformations on the plaintext.

■Secret key: The secret key is also input to the encryption algorithm. The exact substitutions and transformations performed by the algorithm depend on the key.

■ Ciphertext: This is the scrambled message produced as output. It depends on the plaintext and the secret key. For a given data block, two different keys will produce two different ciphertexts.

■ Decryption algorithm: This is the inverse of the encryption algorithm. It takes the ciphertext and the secret key and produces the original plaintext.

There are two requirements for secure use of symmetric encryption:

You need a strong encryption algorithm. At a minimum, the algorithm should be such that an opponent who knows the algorithm and has access to one or more ciphertexts is unable to decipher the ciphertext or figure out the key. This requirement is usually stated in a stronger form: The opponent should be unable to decrypt ciphertext or discover the key even if he or she is in possession of a number of ciphertexts together with the plaintext that produced each ciphertext.

The sender and receiver must obtain copies of the secret key in a secure fashion and keep the key secure. If someone discovers the key and knows the algorithm, all communication using this key is readable.

Symmetric encryption

There are two general approaches to attacking a symmetric encryption scheme

The first attack is known as cryptanalysis

Cryptanalytic attacks rely on the nature of the algorithm plus perhaps some knowledge of the general characteristics of the plaintext or even some sample plaintext/ciphertext pairs

This type of attack exploits the characteristics of the algorithm to attempt to deduce specific plaintext or to deduce the key being used

If the attack succeeds in deducing the key, the effect is catastrophic: All future and past messages encrypted with that key are compromised

The second attack is known as a brute-force attack

Brute-force tries every possible key on a piece of ciphertext until an intelligible translation into plaintext is obtained

On average, half of all possible keys must be tried to achieve success

Thus a secure symmetric encryption scheme requires a secure algorithm and a key of sufficient length to defeat a brute-force attack

There are two general approaches to attacking a symmetric encryption scheme. The first attack is known as cryptanalysis. Cryptanalytic attacks rely on the nature of the algorithm plus perhaps some knowledge of the general characteristics of the plaintext or even some sample plaintext/ciphertext pairs. This type of attack exploits the characteristics of the algorithm to attempt to deduce specific plaintext or to deduce the key being used. If the attack succeeds in deducing the key, the effect is catastrophic: All future and past messages encrypted with that key are compromised. The second method, known as a brute-force attack, is to try every possible key on a piece of ciphertext until an intelligible translation into plaintext is obtained. On average, half of all possible keys must be tried to achieve success. Thus a secure symmetric encryption scheme requires a secure algorithm and a key of sufficient length to defeat a brute-force attack.

Public key encryption

Public key cryptography, also called asymmetric cryptography, involves the use of two separate keys

A public key encryption scheme has several ingredients:

Plaintext

This is the readable message or data block that is fed into the algorithm as input

Encryption algorithm

Performs various transformations on the plaintext

Public key and private key

This is a pair of keys that were selected so that if one is used for encryption, the other is used for decryption

Ciphertext

This is the scrambled block produced as output

Decryption algorithm

This algorithm accepts the ciphertext and the matching key and produces the original plaintext

Public key cryptography, also called asymmetric cryptography, involves the use of two separate keys, in contrast to symmetric encryption, which uses only one key. The use of two keys has profound consequences in the areas of confidentiality, key distribution, and authentication. A public key encryption scheme has several ingredients:

Plaintext: This is the readable message or data block that is fed into the algorithm as input.

Encryption algorithm: The encryption algorithm performs various transformations on the plaintext.

Public key and private key: This is a pair of keys that were selected so that if one is used for encryption, the other is used for decryption. The exact transformations performed by the encryption algorithm depend on the public or private key that is provided as input.

Ciphertext: This is the scrambled block produced as output. It depends on the plaintext and the key. For a given message, two different keys produce two different ciphertexts.

Decryption algorithm: This algorithm accepts the ciphertext and the matching key and produces the original plaintext.

The process works (that is, produces the correct plaintext on output) regardless of the order in which the pair of keys is used. As the names suggest, the public key of the pair is made public for others to use, while the private key is known only to its owner.

As with symmetric encryption algorithms, the security of public key encryption depends on the strength of the algorithm and the length of the private key. Public key cryptographic algorithms are considerably slower than symmetric algorithms for a given data block length. Accordingly, public key cryptographic is almost always limited to use with small blocks of data, such as a secret key or, as discussed next, a hash value.

(Table is on pages 522 in the textbook)

As with any hash function, a secure hash function takes a variable-length block of data as input and produces a fixed-length hash value that is typically shorter than the input data block. Secure hash functions are an essential element of many security protocols and applications. To be useful for security applications, a hash function H must have the properties indicated in Table 14.3.

Figure 14.12 indicates two common ways in which hash functions are used. Figure 14.12a illustrates the use of a hash function to ensure the data integrity of a block of data, generally referred to as message authentication. The two important aspects of message authentication are to verify that the content of the message was not altered and to verify that the source is authentic. You can also verify a message’s timeliness (that is, ensure that it has not been artificially delayed and replayed) and that the sequence is relative to other messages flowing between two parties.

For message authentication, a hash value is generated for the source message. The hash value is then encrypted using a secret key shared by a cooperating partner. Then the message and the encrypted hash value are transmitted to the destination. The recipient decrypts the incoming encrypted hash value, generates a new hash value from the incoming message, and compares the two hash values. If you assume that only the receiver and the sender know the identity of the secret key, and if the received

code matches the calculated code, then the following occurs:

The receiver is assured that the message was not altered. If an attacker alters the message but does not alter the code, then the receiver’s calculation of the code differs from the received code. For a secure hash function, it is infeasible for an attacker to alter the message in such a way that the hash value is not altered.

The receiver is assured that the message is from the alleged sender. Because no one else knows the secret key, no one else could prepare a message with a proper code.

If the message includes a sequence number (such as is used with High-Level Data Link Control [HDLC] and TCP), then the receiver is assured of the proper sequence because an attacker cannot successfully alter the sequence number.

Figure 14.12b illustrates the digital signature process.

Digital signatures

NIST FIPS 86-3, Digital Signature Standard, defines digital signature as follows:

The result of a cryptographic transformation of data that,

when properly implemented, provides a mechanism for

verifying origin authentication, data integrity and signatory

non-repudiation

A digital signature is a data-dependent bit pattern, generated by an agent as a function of a file, message, or other form of data block

Another agent can access the data block and its associated signature and verify that (1) the data block was signed by the alleged signer and that (2) the data block was not altered since the signing

Further, the signer cannot repudiate the signature

NIST FIPS 86-3, Digital Signature Standard, defines digital signature as follows:

The result of a cryptographic transformation of data that, when properly implemented, provides a mechanism for verifying origin authentication, data integrity and signatory non-repudiation.

Thus, a digital signature is a data-dependent bit pattern, generated by an agent as a function of a file, message, or other form of data block. Another agent can access the data block and its associated signature and verify that (1) the data block was signed by the alleged signer and that (2) the data block was not altered since the signing. Further, the signer cannot repudiate the signature.

Digital signatures

Digital signatures are widely used for a number of purposes, including the following:

Digitally signing email messages to authenticate the sender

Digitally signing a software program to authenticate the source of the program and to counter the threat of software tampering

Verifying the authorship or origin of digital data

Ensuring the integrity of digital data against tampering

Authenticating online entities

Digital signatures are widely used for a number of purposes, including the following:

Digitally signing email messages to authenticate the sender

Digitally signing a software program to authenticate the source of the program and to counter the threat of software tampering

Verifying the authorship or origin of digital data

Ensuring the integrity of digital data against tampering

Authenticating online entities

Cryptography implementation considerations

SP 800-12, An Introduction to Information Security, lists the following as important management considerations for implementing cryptography within an organization:

Selecting design and implementation standards

Deciding between hardware, software, and firmware implementations

Managing keys

Ensuring security of cryptographic modules

Applying cryptography to networks

SP 800-12, An Introduction to Information Security, lists the following as important management considerations for implementing cryptography within an organization:

Selecting design and implementation standards: It is almost always advisable not to rely on a proprietary cryptographic algorithm, especially if the algorithm itself is secret. Standardized algorithms, such as AES, Secure Hash Algorithm (SHA), and DSA are subject to intense scrutiny by the professional community, and managers can have a high degree of confidence that the algorithms themselves, with the recommended lengths, are secure. NIST and other organizations have developed numerous standards for designing, implementing, and using cryptography and for integrating it into automated systems. Managers and users of systems should choose the appropriate cryptographic standard based on a cost-effectiveness analysis, trends in the standard’s acceptance, and interoperability requirements.

Deciding between hardware, software, and firmware implementations: The trade-offs among security, cost, simplicity, efficiency, and ease of implementation need to be studied by managers acquiring various security products meeting a standard.

Managing keys: This topic is addressed in Section 14.9.

Ensuring security of cryptographic modules: A cryptographic module contains the cryptographic algorithm(s), certain control parameters, and temporary storage facilities for the key(s) being used by the algorithm(s). The proper functioning of cryptography requires the secure design, implementation, and use of the cryptographic module. This includes protecting the module against tampering. A useful tool is the NIST Cryptographic Module Validation Program (CMVP), which validates vendor offerings using independent accredited laboratories. The validation is against the security requirements in FIPS 140-2, Security Requirements for Cryptographic Modules. FIPS 104-2 provides a detailed set of requirements at four security levels against which vendor hardware, firmware, and software offerings are evaluated (see Table 14.4).

Applying cryptography to networks: The use of cryptography in networking applications often requires special considerations. In these applications, the suitability of a cryptographic module depends on its capability for handling special requirements imposed by locally attached communications equipment or imposed by the network protocols and software.

(Table is on pages 527-528 in the textbook)

Table 14.4 Cryptographic Module Security Requirements from FIPS 140-2

cryptosystem (cryptographic system)

A set of cryptographic algorithms together with the key management processes that support use of the algorithms in some application context

cryptosystem (cryptographic system)

A set of cryptographic algorithms together with the key management processes that support use of the algorithms in some application context.

Cryptographic key management

Key management is the process of administering or managing cryptographic keys for a cryptosystem (cryptographic system). It involves the generation, creation, protection, storage, exchange, replacement, and use of keys and enables selective restriction for certain keys. In addition to access restriction, key management also involves the monitoring and recording of each key’s access, use, and context. A key management system also includes key servers, user procedures, and protocols, including cryptographic protocol design. The security of a cryptosystem is dependent on successful key management.

Cryptographic key management is a complex undertaking. The applications, protocols, and security functions in an organization require the use of many cryptographic keys. There are a number of different types of keys. For each key type, there are issues related to how long the keys should be in use and how to safely store and distribute them. A broad range of management and technical issues must be addressed. Fortunately, solid guidance is available from standards organizations.

Key management is the process of administering or managing cryptographic keys for a cryptosystem (cryptographic system)

It involves the generation, creation, protection, storage, exchange, replacement, and use of keys and enables selective restriction for certain keys

Key management also involves the monitoring and recording of each key’s access, use, and context

The security of a cryptosystem is dependent on successful key management

Group key

A symmetric cryptographic key shared among multiple participants. A block of data encrypted by any one participant using the group key can be decrypted by any other participant who shares the group key

group key

Key types

■ Private and public signature keys

The asymmetric key pair used to generate and verify digital signatures

■ Symmetric authentication key

Used for message authentication

■ Private and public authentication keys

Used to provide assurance of the identity of an originating entity when establishing an authenticated communication session

■ Symmetric data encryption key

Used to provide data confidentiality by encryption/decryption

■ Symmetric key-wrapping key

Also called a key-encryption key, is used to encrypt/decrypt other keys

■ Symmetric random number generation key

Used with a random number generation algorithm

One of the aspects of key management that makes this discipline so complex is the wide variety of key types employed in a cybersecurity deployment. SP 800-57 identifies several different key types:

■ Private and public signature keys: The asymmetric key pair used to generate and verify digital signatures.

■ Symmetric authentication key: Used for message authentication, as illustrated in Figure 14.12a.

■ Private and public authentication keys: Used to provide assurance of the identity of an originating entity (that is, source authentication) when establishing an authenticated communication session.

■ Symmetric data encryption key: Used to provide data confidentiality by encryption/decryption.

■ Symmetric key-wrapping key: Also called a key-encryption key, is used to encrypt/decrypt other keys.

■ Symmetric random number generation key: Used with a random number generation algorithm.

Key types

■ Symmetric master key

Used to derive other symmetric keys using symmetric cryptographic methods; the master key is also known as a key-derivation key

■ Private and public key-transport keys

Used to establish keys and, optionally, other keying material

■ Symmetric key-agreement key

Used to establish keys and, optionally, other keying material using a symmetric key-agreement algorithm

■ Private and public static key-agreement key

Long-term key pair used to establish keys and, optionally, other keying material

■ Private and public ephemeral key-agreement key

Short-term key pair used only once to establish one or more keys and, optionally, other keying material

■ Symmetric master key: Used to derive other symmetric keys (for example, data-encryption keys, key-wrapping keys) using symmetric cryptographic methods. The master key is also known as a key-derivation key.

■ Private and public key-transport keys: Used to establish keys (for example, key-wrapping keys, data-encryption keys, message authentication keys) and, optionally, other keying material (for example, initialization vectors).

■ Symmetric key-agreement key: Used to establish keys (for example, key- wrapping keys, data-encryption keys, message authentication keys) and, optionally, other keying material (for example, initialization vectors) using a symmetric key-agreement algorithm.

■ Private and public static key-agreement key: Long-term key pair used to establish keys (for example, key-wrapping keys, data-encryption keys, message authentication keys) and, optionally, other keying material (for example, initialization vectors).

■ Private and public ephemeral key-agreement key: Short-term key pair used only once to establish one or more keys (for example, key-wrapping keys, data- encryption keys, message authentication keys) and, optionally, other keying material (for example, initialization vectors).

Key types

■ Symmetric authorization key

Used to provide privileges to an entity; the authorization key is known by the entity responsible for monitoring and granting access privileges for authorized entities and by the entity seeking access to resources

■ Private and public authorization key

Used to provide and verify privileges

■ Symmetric authorization key: Used to provide privileges to an entity. The authorization key is known by the entity responsible for monitoring and granting access privileges for authorized entities and by the entity seeking access to resources.

■ Private and public authorization key: Used to provide and verify privileges.

cryptoperiod

The cryptoperiod of a cryptographic key is the time span during which a specific cryptographic key is authorized for use for its defined purpose

A number of potential security threats make it advisable that any key not be used for a prolonged period of time. These threats include:

Brute-force attacks

As raw processing power and the ability to use numerous processors in parallel increase, a given key length becomes increasingly vulnerable, and longer key lengths are advised. Any of the shorter keys in use need to be retired as quickly as possible and longer key lengths employed

Cryptanalysis

Over time, flaws may be discovered in a cryptographic algorithm that make it feasible to “break” the algorithm

Other security threats

Beyond simply attacking an algorithm directly in an attempt to discover a key that is being used, there are a variety of other methods of attack. They include attacks on the mechanisms and protocols associated with the keys, key modification, and achieving unauthorized disclosure. The longer a particular key is used for encryption and decryption, the greater the chance that some means of learning the key will succeed

The cryptoperiod of a cryptographic key is the time span during which a specific cryptographic key is authorized for use for its defined purpose. This is an important consideration. A number of potential security threats make it advisable that any key not be used for a prolonged period of time. These threats include:

Brute-force attacks: As raw processing power and the ability to use numerous processors in parallel increase, a given key length becomes increasingly vulnerable, and longer key lengths are advised. Any of the shorter keys in use need to be retired as quickly as possible and longer key lengths employed. For example, NIST used to recommend the use of 1,024-bit keys for certain asymmetric algorithms but now recommends 2,048 bits for these algorithms.

Cryptanalysis: Over time, flaws may be discovered in a cryptographic algorithm that make it feasible to “break” the algorithm. An example of this is the original NIST standard hash algorithm, SHA-1, which was used in its DSA. Once these weaknesses were discovered, NIST migrated to SHA-2 and SHA-3. Similarly, methods were found for breaking algorithms such as the RSA asymmetric algorithm at rates faster than brute force, which are thwarted by using longer keys.

Other security threats: Beyond simply attacking an algorithm directly in an attempt to discover a key that is being used, there are a variety of other methods of attack. They include attacks on the mechanisms and protocols associated with the keys, key modification, and achieving unauthorized disclosure. The longer a particular key is used for encryption and decryption, the greater the chance that some means of learning the key will succeed.

Accordingly, an enterprise should have policies for the maximum cryptoperiod of each key type.

Figure 14.13 illustrates the two aspects of a cryptoperiod. The originator usage period (OUP) refers to the time during which data is encrypted, and the recipient usage period (RUP) is the time during which such data continues to be maintained in its encrypted form and subject to decryption. The RUP often starts at the beginning of the OUP, but there may be some delay before data is decrypted. More significantly, the end of the RUP may extend a considerable length of time beyond the end of the OUP. That is, the policy may state that a given key may no longer be used for encrypting new data, but the data that has already been encrypted may be retained in the encrypted form, available for decryption for a further period of time. Hence the cryptoperiod extends from the start of the OUP to the end of the RUP.

(Table is on page 533 in the textbook)

Table 14.5 shows the cryptoperiods suggested in SP 80-57.

pseudorandom number generator

A function that deterministically produces a sequence of numbers that are apparently statistically random

pseudorandom number generator

A function that deterministically produces a sequence of numbers that are apparently statistically random.

A key may pass through a number of states between its generation and destruction. Figure 14.14, based on a figure in Key Management for Dummies [MOUL11], show the typical life cycle of a key.

The main cycle consists of six states:

Generate: New keys are generated using a random or pseudorandom number generator. The security challenge ensures that if an attacker discovers one key in a sequence of generated keys, it is not feasible to predict future keys. Cryptographic keys should be generated with a random number generation module that is at least compliant with the SP 800-90 family of standards, which consists of:

SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators: Specifies mechanisms for the generation of random bits using deterministic methods.

SP 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation: Specifies the design principles and requirements for the entropy sources used by random bit generators and the tests for the validation of entropy sources. These entropy sources are intended to be combined with deterministic random bit generator mechanisms that are specified in SP 800-90A to construct random bit generators, as specified in SP 800-90C.

SP 800-90C, Recommendation for Random Bit Generator (RBG) Constructions: Specifies constructions for the implementation of random bit generators. A random bit generator may be a deterministic random bit generator or a non-deterministic random bit generator. The constructed random bit generators consist of deterministic random bit generator mechanisms, as specified in SP 800-90A, and entropy sources, as specified in SP 800-90B.

Distribute/Install: This function raises several challenging security requirements. A stored key or newly generated key must be distributed to the individual or individuals that are authorized to use it. A mutual authentication is required. The distributor of the key must be assured that the recipient is authorized for this key. The recipient must be able to trust that the key is coming from the alleged source. Finally, the act of distribution, which is accomplished only by means of a protocol over a network or a physical transfer (for example, via a USB device) needs to be performed securely.

Use: In general, the use of a particular key should be restricted to a single purpose or application. Use of the same key in multiple applications expands the attack surface and increases vulnerability. In addition, a key should be used in a secure fashion that avoids disclosure.

Suspend: A suspend state is needed if there is a need to retain a key beyond its operational life. For example, an entity that uses a key for data encryption must suspend use of that key when the OUP expires. However, the key may remain usable if it is needed beyond that point to decrypt data.

Destroy: When a key is no longer needed, delete it from all systems containing a copy of the key, including backup and archive systems. The IT system needs to include a means, including audit trails, to determine where all copies of a key are located for this purpose.

Central to the key life cycle is a storage state. The storage must be both physically and electronically secure. Part of the security associated with a stored key is to encrypt the key. But this involves using a key-wrapping key, and its storage must be secure as well. Ideally, key-wrapping keys are stored on dedicated hardware. Two functions associated with a key storage facility are key backup and recovery. Again, the process of backup and the process of recovery must be performed in a secure fashion, and the backup storage must be secured.

Two additional states are associated with keys:

Rotate: The longer a key is used, the more encrypted material is potentially available to an attacker attempting to discover the key. The term rotate is generally used to refer to the process of replacing one key with another in accordance with the appropriate cryptoperiod policy for that key type.

Revoke: If a key is compromised, or if compromise is suspected, the key must be revoked and remedial action taken. First, the need to halt the use of the key must be securely communicated to any user of the key. Second, the recovery function appropriate for the level of risk involved must be performed.

Public key certificates

A public key certificate is a set of data that uniquely identifies an entity, contains the entity’s public key, and is digitally signed by a trusted party, called a certification authority (CA), thereby binding the public key to the entity.

Public key certificates are designed to provide a solution to the problem of public key distribution. Typically, in a public key scheme, multiple users need to have access to the public key of a given entity A, whether to encrypt data to send to A or to verify a digital signature signed by A. Each holder of a public/private key pair could simply broadcast its public key for anyone to read. The problem with this approach is that it is easy for some attacker X to impersonate A and to broadcast X’s public key improperly labeled as A’s public key. To counter this, it is possible to set up some trusted central authority that interacts with each user A to authenticate and then maintain a copy of A’s public key. Any other user could then consult the trusted central authority over a secure, authenticated communication channel to obtain a copy of the key. It should be clear that this solution does not scale efficiently.

An alternative approach is to rely on public key certificates that are used by participants to exchange keys without contacting a public key authority in a way that is as reliable as if the keys were obtained directly from a public key authority. In essence, a certificate consists of a public key plus an identifier of the key owner, with the whole block signed by a trusted third party. Typically, the third party is a CA, such as a government agency or a financial institution, that is trusted by the user community. A user presents his or her public key to the authority in a secure manner and obtains a certificate. The user then publishes the certificate. Anyone needing this user’s public key can obtain the certificate and verify that it is valid by way of the attached trusted signature. A participant also conveys its key information to another by transmitting its certificate. Other participants can verify that the certificate was created by the authority.

A set of data that uniquely identifies an entity and contains the entity’s public key

Are digitally signed by a trusted party, called a certification authority (CA), thereby binding the public key to the entity

Are designed to provide a solution to the problem of public key distribution

Figure 14.15 illustrates the overall scheme for the generation of a public key certificate. The certificate for Bob’s public key includes unique identifying information for Bob; Bob’s public key; identifying information about the CA; and certificate information, such as expiration date. This information is then signed by computing a hash value of the information and generating a digital signature using the hash value and the CA’s private key. Bob can then either broadcast this certificate to other users or attach the certificate to any document or data block he signs. Anyone who needs to use Bob’s public key is assured that the public key contained in Bob’s certificate is valid because the certificate is signed by the trusted CA. The ITU-T X.509 standard, The Directory: Public-Key and Attribute Certificate Frameworks, is universally accepted for formatting public key certificates.

PKI Architecture

End entity

This is either an end user; a device, such as a router or server; a process; or any item that is identified in the subject name of a public key certificate

End entities are also consumers of PKI-related services and, in some cases, providers of PKI-related services

Certification authority (CA)

A CA is an authority trusted by one or more users to create and assign public key certificates

CAs digitally sign public key certificates, which effectively binds the subject name to the public key

CAs are also responsible for issuing certificate revocation lists (CRLs). A CRL identifies certificates previously issued by the CA that are revoked before their expiration dates

Registration authority (RA)

An RA is an optional component that is used to offload many of the administrative functions that a CA ordinarily assumes

The RA is normally associated with the end entity registration process. This includes the verification of the identity of the end entity attempting to register with the PKI and obtain a certificate for its public key

Repository

The repository denotes any method for storing and retrieving PKI- related information, such as public key certificates and CRLs

Relying party

A relying party is any user or agent that relies on the data in a certificate in making decisions

These are the essential components of the PKI architecture:

End entity: This is either an end user; a device, such as a router or server; a process; or any item that is identified in the subject name of a public key certificate. End entities are also consumers of PKI-related services and, in some cases, providers of PKI-related services. For example, a registration authority is considered to be an end entity from the point of view of the CA.

Certification authority: A CA is an authority trusted by one or more users to create and assign public key certificates. Optionally the certification authority may create the subjects’ keys. CAs digitally sign public key certificates, which effectively binds the subject name to the public key. CAs are also responsible for issuing certificate revocation lists (CRLs). A CRL identifies certificates previously issued by the CA that are revoked before their expiration dates. A certificate could be revoked because the user’s private key is assumed to be compromise, the user is no longer certified by this CA, or the certificate is assumed to be compromised.

Registration authority (RA): An RA is an optional component that is used to offload many of the administrative functions that a CA ordinarily assumes. The RA is normally associated with the end entity registration process. This includes the verification of the identity of the end entity attempting to register with the PKI and obtain a certificate for its public key.

Repository: The repository denotes any method for storing and retrieving PKI- related information, such as public key certificates and CRLs. A repository can be an X.500-based directory with client access via Lightweight Directory Access Protocol (LDAP). It can also be something simple, such as a means for retrieval of a flat file on a remote server via File Transfer Protocol (FTP) or Hypertext Transfer Protocol (HTTP).

Relying party: A relying party is any user or agent that relies on the data in a certificate in making decisions.

A PKI architecture defines the organization and interrelationships among CAs and PKI users. PKI architectures satisfy the following requirements:

Any participant can read a certificate to determine the name and public key of the certificate’s owner.

Any participant can verify that the certificate originated from the certificate authority and is not counterfeit.

Only the certificate authority can create and update certificates.

Any participant can verify the currency of the certificate.

Figure 14.16 shows a typical architecture for a PKI.

Figure 14.16 illustrates the interactions of the various components. Consider a relying party, Alice, who needs to use Bob’s public key. Alice must first obtain in a reliable secure fashion a copy of the public key of the CA. This can be done in a number of ways, depending on the particular PKI architecture and enterprise policy. If Alice wishes to send the encrypted data to Bob, Alice checks with the repository to determine if Bob’s certificate was revoked, and if it wasn’t, she obtains a copy of Bob’s certificate. Alice can then use Bob’s public key to encrypt data sent to Bob. Bob can also send to Alice a document signed with Bob’s private key. Bob may include his certificate with the document or assume that Alice already has obtained or can obtain the certificate. In either case, Alice first uses the CA’s public key to verify that the certificate is valid and then uses Bob’s public key (obtained from the certificate) to validate Bob’s signature.

Rather than using a single CA, an enterprise may need to rely on multiple CAs and multiple repositories. CAs are organized in a hierarchical fashion, with a root CA that is widely trusted signing the public key certificate of subordinate CAs. Many root certificates are embedded in web browsers so they have built-in trust of those CAs. Web servers, email clients, smartphones, and many other types of hardware and software also support PKI and contain trusted root certificates from the major CAs.

Management issues

NIST SP800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, suggests the following general plan:

Analyze data and applications

Review sample policies

Draft certificate policy

Select a PKI product or service provider

Develop a certification practice statement

Start with a pilot deployment

Consider cross certification issues

NIST SP800-32, Introduction to Public Key Technology and the Federal PKI Infrastructure, suggests the following general plan:

■ Analyze data and applications: As with any application or security service added to the enterprise architecture, PKI has security implications. The usual risk analysis should be done. In addition to comparing the initial and operating costs of the PKI with anticipated cost reductions, a cost/benefit analysis should attempt to identify larger risks due to not implementing a PKI. The analysis should also identify the data and applications that will use PKI services.

■ Review sample policies: An efficient approach to developing a PKI is to collect sample policies and use them as templates to develop the enterprise PKI policy. A good resource for finding such policies is the OASIS PKI website. Another example is the X.509 Certificate Policy for the U.S. Federal PKI Common Policy Framework.

■ Draft certificate policy: A certificate policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery, and administration of digital certificates. Indirectly, a certificate policy can also govern the transactions conducted using a communications system protected by a certificate-based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications. A certificate policy can help a certificate user decide whether a certificate should be trusted in a particular application. For example, a particular certificate policy might indicate applicability of a type of certificate for the authentication of electronic data interchange transactions for the trading of goods within a given price range. A useful document in this regard is RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

■ Select a PKI product or service provider: An enterprise PKI can be partially or completely implemented in-house with proprietary or open source software. Part or all of the service can also be outsourced to a service provider. The enterprise needs to consider a range of issues, including interoperability, ease of adoption, flexibility of administration, and scalability.

■ Develop a certification practice statement: This is a list of the practices that a CA employs in issuing, suspending, revoking, and renewing certificates and providing access to them, in accordance with specific requirements (that is, requirements specified in the certificate policy or requirements specified in a contract for services).

■ Start with a pilot deployment: Because of the complexity of a PKI, it is best to start with a limited number of users on some number of internal applications.

■ Consider cross certification issues: It may be possible or advisable to develop certification agreements with suppliers, customers, or other entities that the enterprise interacts with. This would involve establishing a trust relationship between certain CAs in the enterprise and outside entities.

Technical security management best practices

Cryptography

Cryptographic solutions

Cryptographic key management

Public key infrastructure (PKI)

Security solutions

Security architecture

Malware protection activities

Malware protection software

Identity and access management

Intrusion detection

Information leakage protection

Digital rights management

The SGP breaks down the best practices in the technical security management category:

The SGP breaks down the best practices in the technical security management category into 2 areas and 10 topics and provides detailed checklists for each topic. The areas and topics are:

■ Security solutions: The objective of this area is to build a sound technical security infrastructure, applying security architecture principles and integrating technical security solutions covering the following topics:

■ Security architecture: Lists the requirements that need to be satisfied by the application of a security architecture to enable system developers and administrators to make more effective decisions and implement consistent, simple-to-use security functionality across multiple business applications and systems throughout the organization

■ Malware protection activities: Provides a checklist of management actions to protect against malware.

■ Malware protection software: Provides a checklist of management actions related to the use of malware protection software.

■ Identity and access management: Lists IAM practices that provide effective and consistent user administration, identification, authentication, and access control mechanisms throughout the organization.

■ Intrusion detection: Lists types of intrusions that should be detected and appropriate management policies for handling intrusions. The objective is to identify suspected or actual malicious attacks and enable the organization to respond before serious damage is done.

■ Information leakage protection: Focuses on identifying sensitive information that may be at risk of unauthorized disclosure and detection if disclosed to unauthorized individuals or systems. The topic lists management actions related to information leakage protection.

■ Digital rights management: Lists the recommended documented standards/procedures for the provision and management of digital rights management across the organization. The objective of this topic is to ensure that the access to and processing of highly sensitive information is restricted to specific functions by a limited number of authorized individuals.

■ Cryptography: The objective of this area is to deploy approved cryptographic solutions (for example, using encryption, public key infrastructure, digital signatures) in a consistent manner across the organization to help protect the confidentiality of information, determine whether critical information has been altered, provide strong authentication, and support non-repudiation.

Cryptographic solutions: The objective of this topic is to protect the confidentiality of sensitive information, preserve the integrity of critical information, and confirm the identity of the originator of transactions or communications. The topic recommends defining when cryptography should be used, selection of approved algorithms, and documented use of cryptographic solutions.

Cryptographic key management: The objective of this topic is to ensure that cryptographic keys are not compromised (for example, through loss, corruption, or disclosure), thereby exposing critical or sensitive information to attack. This topic provides guidance for managing keys in accordance with documented standards/procedures and in accordance with protection against unauthorized access or destruction.

Public key infrastructure (PKI): The objective of this topic is to ensure that a PKI operates as intended, is available when required, provides adequate protection of related cryptographic keys, and can be recovered in the event of an emergency. It details policies for using CAs.

summary

Explain the purpose and key characteristics of a security architecture.

Discuss malware protection strategies.

Understand the requirements for malware protection software.

Present an overview of identity and access management concepts.

Describe the principal approaches to intrusion detection.

Explain the key elements in a data loss prevention solution.

Understand the basic concepts of digital rights management.

Explain the key requirements for effective implementation and use of cryptographic algorithms.

Discuss the nature of public key infrastructure.

Present an overview of technical security management best practices.

Chapter 14 summary.

After studying this chapter, you should be able to:

Explain the purpose and key characteristics of a security architecture.

Discuss malware protection strategies.

Understand the requirements for malware protection software.

Present an overview of identity and access management concepts.

Describe the principal approaches to intrusion detection.

Explain the key elements in a data loss prevention solution.

Understand the basic concepts of digital rights management.

Explain the key requirements for effective implementation and use of cryptographic algorithms.

Discuss the nature of public key infrastructure.

Present an overview of technical security management best practices.