CompTIA Security SY0-601 Exam: Enterprise Security Concepts

- Objective: Explain the importance of security concepts in an enterprise environment.

Topics:
- configuration management
- data sovereignty
- data protection
- data loss prevention (DLP)
- data masking
- data encryption
- data at rest
- data in motion
- data in processing
- tokenization
- hashing
- rights management
- hardware security module (HSM)
- cloud access security broker (CASB)
- Secure Sockets Layer (SSL)
- Transport Layer Security (TLS)
- hot site
- cold site
- warm site
- deception
- disruption
- honeypot
- honeyfile
- honeynet
- DNS sinkhole

Enterprise security requires architecture and design around a number of important concepts to ensure the security of data and defend against threats—from foundationally ensuring baselined systems that process data; to ensuring the confidentiality, integrity, and availability (CIA) of the data; to defending against threats that could compromise the data.

Configuration Management
Configuration management is its own discipline that can be broken into subdisciplines. Configuration management has been around for decades and, while it has roots in technical management, it has evolved to incorporate many different concepts across multiple domains. As related to information and cybersecurity, configuration management is the process of identifying, controlling, and auditing the deployment and changes made to an established baseline. Benefits include the ability to do things more efficiently and effectively while providing strong security controls and best practice. Examples of these benefits are realized in the following processes:
- Provisioning new systems
- Replicating environments
- Recovering from disasters
- Onboarding and training employees
- Ensuring stability through change management
- Ensuring hardened and secure systems

It is important to understand how configuration management contributes to secure configurations. A baseline configuration is based on a component or a system and includes the configurations and settings that are set as the foundation for all similar systems. This way, for example, when a Windows desktop is deployed to a user, the Windows desktop deployed to another user is set up the same way, based on a well-documented baseline configuration. While having a baseline configuration may seem unnecessary for just two systems, you can imagine how useful it is in an organization with thousands or tens of thousands of systems. Without such configurations and the proper management of these configurations, an organization would be more susceptible to errors, malfunctions, and security breaches. Further, ongoing management and support of these systems would be overwhelming. It is therefore important that the configuration management process as well as all the baselines and standards be well documented. Consider, for example, the following:
- Baseline configuration: A baseline configuration should be documented such that another person could easily replicate the configuration, much like following a recipe. This standardization also helps in facilitating audit activities.
- Diagrams: Diagrams are particularly important for networks and interconnected complex systems. Examples include network maps, cabling and wiring diagrams, and application configuration and connections.
- Standard naming convention: An agreed-upon method of naming assets is valuable for everyday management and especially in the event of an emergency. For example, a computer could be named Therese-SF-Sales to indicate a computer assigned to Therese out of San Francisco in the Sales division. Computer names can indicate a number of physical properties, including building number, room number, and floor, or logical properties, such as owner, cost center, or function (such as email or web).
- Internet Protocol (IP) schema: As components and systems are added to IP-based networks, each is usually assigned an IP address. A small organization, for example, might designate systems by type according to the last octet of the IP address (for example, switches and routers could be numbered x.x.x.1 through x.x.x.10 and client computers x.x.x.11 through x.x.x.50).

Remember that configuration management documentation often includes diagrams, baseline configurations, standard naming conventions, and IP schemas.
Security baseline configurations can be built atop baseline configurations in a layered approach, or multiple baseline configurations can be created. For example, a different approach might be taken for the computer of a regular user and that of a power user. While most baseline configurations include hardened standards, a security baseline configuration can be more specific to the role of the specific system. An Active Directory (AD) domain controller, for example, may not need web server components installed on it, and a web server will likely be configured very differently from a database server.
Creating a hardened operating system is a large part of making sure that systems have secure configurations. Hardening the operating system includes planning against both accidental data deletion and directed attacks, such as by using fault-tolerant hardware and software solutions. In addition, an organization must implement an effective system for file-level security, including encrypted file support and secured file system selection that allows the proper level of access control. For example, NTFS allows file-level access control and encryption, whereas most FAT-based file systems allow only share-level access control, without encryption.
Organizations also must conduct regular update reviews for all deployed operating systems to address newly identified exploits and apply security updates and hotfixes. Many automated attacks take advantage of common vulnerabilities, often those for which patches and hotfixes are already available but not yet applied. Failure to update applications on a regular basis or perform regular auditing can result in an insecure solution that gives an attacker access to additional resources throughout an organization’s network.
Operating system hardening includes configuring log files and auditing, changing default administrator account names and default passwords, and instituting account lockout and password policies to guarantee strong passwords that can resist brute-force attacks. File-level security and access control mechanisms can be used to isolate access attempts in the operating system environment.

Data Confidentiality
Maintaining the confidentiality of data is an important component of ensuring data protection. Confidentiality is about protecting data and ensuring privacy so that only those who should be authorized to view data are allowed to do so. Data protection involves preventing theft or disclosure of data—both intentional and unintentional.
Most enterprises implement a variety of tools to provide for data confidentiality. This section covers these technologies and tools, including data loss prevention, cloud access security brokers, data obfuscation techniques, rights management, hardware security modules, and encrypted traffic management.

Data Loss Prevention
Data loss prevention (DLP) products identify confidential or sensitive information through content analysis. Content analysis techniques include rule-based, database, exact file or data matching, partial document matching, and statistical analysis.
Data loss is a problem that all organizations face, and it can be especially challenging for global organizations that store a large volume of personally identifiable information (PII) in different legal jurisdictions. Privacy issues differ by country, region, and state. Naturally, organizations implement data loss prevention tools as a way to prevent data loss. Data loss prevention is a way of detecting and preventing confidential data from being exfiltrated physically or logically from an organization by accident or on purpose. DLP systems are basically designed to detect and prevent unauthorized use and transmission of confidential information, based on one of the three states of data: in use, in motion/transit, or at rest. DLP systems offer a way to enforce data security policies by providing centralized management for detecting and preventing the unauthorized use and transmission of data that the organization deems confidential. A well-designed DLP strategy allows control over sensitive data, reduces costs by preventing data breaches, and makes possible greater insight into organizational data use. International organizations should ensure that they are in compliance with local privacy regulations as they implement DLP tools and processes.
Data can exist in different states: in use, in transit, and at rest. Protection of data in use is considered to be an endpoint solution. With data in use, an application is run on end-user workstations or servers in the organization. Endpoint systems also can monitor and control access to physical devices such as mobile devices and tablets. Protection of data in transit is considered to be a network solution, and either a hardware or software solution can be installed near the network perimeter to monitor and flag policy violations. Protection of data at rest is considered to be a storage solution and is generally a software solution that monitors how confidential data is stored.

With a DLP solution, a user can be alerted about security policy violations to keep sensitive information from leaving the user’s desktop. The following are some examples of actions for which an organization might want to alert users:
- Inadvertently emailing a confidential internal document to external recipients
- Forwarding an email containing sensitive information to unauthorized recipients inside or outside the organization
- Sending attachments such as spreadsheets with PII to an external personal email account
- Accidentally selecting Reply All and emailing a sensitive document to unauthorized recipients

USB flash drives and other portable storage devices are pervasive in the workplace and pose a real threat. They can introduce viruses or malicious code to the network and can store sensitive corporate information. In addition, sensitive information is often stored on thumb drives and external hard drives, which may be lost or stolen. DLP solutions allow policies for USB blocking, such as policies for blocking the copying of any network information to removable media or for blocking the use of unapproved USB devices.

Cloud Access Security Brokers
In recent years, many large organizations have embraced cloud services and begun storing data in the cloud. DLP solutions have expanded from email and local devices to include corporate data stored in the cloud. An organization must know how the cloud is being utilized before making decisions on a DLP solution:
- What files are being shared outside the organization?
- What files contain sensitive data?
- What abnormal events indicate threat or compromise?
 

Cloud service providers (CSPs) have introduced a variety of cloud storage services, such as Google Drive and Dropbox. These services represent new usage models for how we interact with data. For example, cloud storage enables collaboration and typically makes it possible to share data with a simple link. Cloud access security brokers (CASBs) have introduced innovative ways to gain visibility and control of these services. One of the primary use cases for a CASB is DLP for cloud applications and services such as Office 365, Salesforce, Google Suite, Dropbox, and Box.
Different DLP policies apply for different cloud services. Some are general cloud policies, such as a general policy for device access control. A specific policy for Box, for example, might focus on file sharing. Some concepts are a bit different in the cloud than on premises, such as how a file is shared (whether internally with the entire organization or externally and with whom), and whether data is shared publicly. CASBs are designed to understand these situations and provide dynamic policies to control and respond to various circumstances. As CASBs have matured and been acquired by larger security vendors, in some of the better integrations, they work as part of the enterprise DLP program and serve as another extension to other use cases solved by DLP (for example, across the endpoint, network, data center, and now cloud services).
Cloud access security brokers (CASBs) help organizations extend on-premises security solutions to the cloud. They are hardware or software solutions that act as intermediaries between users and cloud service providers (CSPs).

Encryption and Data Obfuscation
According to best practices, sensitive data should be encrypted at all times whenever possible. Data exposure can occur in applications when sensitive data—such as credit card numbers, personal health information (PHI), and authentication credentials—is not protected while it is being stored or transmitted.
When employees must use removable drives, finding a way to secure data that is taken outside a managed environment is part of doing business. Data encryption is essential. Some disk encryption products protect only the local drive and not USB devices. Other encryption products automatically encrypt data that is copied or written to removable media.

Protecting data through encryption and yet maintaining the capability for decryption can be broadly categorized into three high-level areas (similar to DLP), based on the state of the data:
- Data at rest: Data at rest is data in its stored or resting state, which is typically on some type of persistent storage such as a hard drive or tape. Symmetric encryption is used in this case.
- Data in transit: Data in transit is data moving across a network or from one system to another. Data in transit is also commonly known as data in motion. Transport layer encryption such as SSL/TLS is used in this case.
- Data in processing: Data in processing is data being processed in memory or cache. It includes the presentation of data, such as on a monitor. Homomorphic and other emerging techniques are used in this case.

The distinctions can be blurred, particularly when talking about data in processing. This is why the term data in processing is used rather than the term data in use, as it is with DLP. With DLP, data in use is specific to a user interacting with data on the endpoint, such as copying data from the file and other interactions. Data in processing, on the other hand, requires encryption techniques that can perform calculations upon encrypted data without the requirement to first decrypt the data.
Remember that DLP solutions can incorporate one or all three methods of protecting data in various states: data in use (for example, data on laptop being moved to a USB drive), data in transit (for example, data going across the network), and data at rest (for example, data sitting on a file server or database). Encryption also can protect data at rest and data in transit. Encrypting data being used is more appropriately referred to as data in processing than data in use.
Encryption of data in processing is difficult to achieve, and it is typically done only for specific situations to meet certain requirements. For example, data in processing encryption is best suited to structured data, such as fields within a database. Certainly, adhering to field size limits or maintaining the referential integrity that a database requires is not trivial, but there are methods (often involving other security or usability trade-offs) to encrypt data or protect data through a means other than encryption, particularly where encryption makes it impossible to do needed work with data or makes it difficult to analyze data while encrypted.
Encryption supports the confidentiality and integrity of data across three states: at rest, in transit, and in processing.

In situations like this and across other use cases, other methods of obscuring data besides encryption may be more suitable—or even required. The following are three methods that often accomplish the goals of confidentiality and privacy without the use of encryption:
- Tokenization: Tokenization involves assigning a random surrogate value with no mathematical relationship that can be reversed by linking the token back to the original data. Outside the system, a token has no value; it is just meaningless data. Tokenization can also preserve the format of data (such as maintaining the type or length of data), which makes it suitable for databases and card payment processing.
- Data masking: Data masking involves desensitizing or removing sensitive or personal data but enabling the data to remain usable. False data that appears real is substituted for the real data. Masking is commonly required for application development, particularly where realistic test data is required. Like tokenization, data masking can preserve the data format and referential integrity.
- Redaction: Redaction involves obscuring data by replacing all or part of the content for security or privacy purposes. Redaction in physical documents typically means blacking out some text; redaction in information systems often uses the asterisk character. For example, a travel agent might need to see only the last four digits of a credit card number, and the preceding digits may be redacted and replaced with asterisks.

The figure below provides an example of applying encryption along with tokenization, masking, and redaction to credit card information.


A comparison of different methods to obfuscate credit card data

In the figure above the encrypted values are scrambled using a cryptographic algorithm, and the size of the output is larger than the original fields. Neither type nor length is preserved, and the data is of no use without first being decrypted.
With the tokenized values, you can see that both type and length are maintained, and the tokens can be alphabetic or numeric. In addition, a tokenized value can also be alphanumeric. A token value can include a prefix such as t to assure the viewer that it is a token surrogate value. Tokens are also useful in credit card applications as the check to ensure validity of a valid card number (that is, the Luhn check) can be maintained. And while not shown in the example, non-sensitive components such as the last four digits of the credit card number can be maintained while other parts are tokenized.
The redacted values provide only the required data. For example, on a credit card receipt, you are likely to see a series of asterisks with only the last four digits of your card number. The last four digits are enough to allow the store personnel to do their jobs, and the redaction maintains your security and privacy as the four digits are not enough to reverse the data back to the original data.
Finally, the masked values generally only need to seem realistic. In this example, an application being developed using credit card information doesn’t necessarily need real data, and it certainly does not need data that has any requirement to ever be reversed. Note, however, that the masked credit card value in this example does include the first six digits of the credit card. This is a non-sensitive component known as the bank identification number (BIN), which the application may require to adequately test a related function. While the masked values look similar to token values, consider the potential differences based on the options described. Also remember that masked values cannot and should not ever have a reason to be reversed. The token value is mathematically not reversible and has no value outside this system to which it can be securely looked up or mapped back to the original number.

Rights Management
Rights managements can include digital rights management (DRM) and information rights management (IRM). Both DRM and IRM serve the purpose of protecting data from unauthorized access through encryption. DRM is primarily used for the protection of copyrighted material. An early use of DRM technology was with CDs and DVDs. When the contents of a disc are encrypted, the media cannot be copied without the decryption key, and only licensed players have that key; this process prevents such duplication. The same technology is often applied to books as well. Some textbooks from Pearson, for example, are protected by DRM. A DRM-protected book is encrypted and requires a third-party reader such as Adobe Digital Editions, which authorizes the use of the book and prevents copying. DRM protection is different from watermarking, in which a book includes an overlaid watermark that makes the book uniquely yours and discourages copying.

IRM is a technology that is mostly used in organizations to protect sensitive information from unauthorized access. IRM provides for data security while also fostering collaboration within the organization and with external parties. IRM is commonly applied to email, engineering documents, and other business-related files that often need to be distributed and shared with other parties. IRM gives the owner the ability to protect these documents using encryption and also enables the owner to control and manage access to the documents, such as what the user can do with the document (for example, preventing copying and pasting, taking screenshots, and printing). IRM can even allow an owner to revoke a user’s access even after a document has been distributed. IRM goes beyond the requirements of DRM by providing flexibility in the type of data to be protected and control mechanisms. IRM allows you to control the following:
- Who: Control who can and cannot access documents—by individual, by group, or based on email domains.
- What: Control what documents can be accessed by allowing access to specific documents or a specific set of documents based on various attributes.
- When: Control when and for how long documents can be accessed. Time limits can be set, and access can be removed on demand.
- Where: Control from where a document can be accessed. Access may be allowed based on the location of the user or based on various attributes, or access may be allowed only on the internal network.
- How: Control how users are able to interact with the document. Features within a document may be limited, if desired. A user might, for example, be unable to forward an email or might be prevented from saving or printing the document.

Hardware Security Module (HSM)
You should consider the use of a hardware security module (HSM) when data security through cryptographic functions is required and the keys used to protect the data are of high value. An HSM is a device used to protect and manage the keys required as part of an encryption or decryption operation. HSMs are special-purpose devices with tamper-preventive secure cryptoprocessors. An HSM provides the following benefits:
- Generates secure cryptographic keys
- Provides secure key storage
- Provides key management capabilities
- Performs cryptographic functions, including digital signing and encryption/decryption operations
- Offers increased performance through cryptographic acceleration

Know that an HSM is a physical security device that manages and safeguards digital keys and performs encryption and decryption for cryptographic functions. An HSM includes a cryptoprocessor that generates, stores, and manages digital keys and can perform performance-optimized cryptographic operations.

Encrypted Traffic Management
The use of encryption continues to grow within and across organizations. Specifically, transport layer encryption—through the use of Secure Sockets Layer (SSL) or Transport Layer Security (TLS)—is now used by default. It is applied to systems residing within organizational boundaries as well as to mobile and cloud applications. The world is going “dark,” to use a phrase from intelligence organizations. While this has a positive impact on data confidentiality, it is challenging for organizations that are required to monitor and ensure the safe use of their employees. Encryption can be used, for example, to hide malicious activity and malware, and it can also be used to ensure that data isn’t confidentially shared with someone with whom it shouldn’t be shared.

To overcome these blind spots and allow security administrators to enforce acceptable use policies and stop encrypted threats, organizations look to systems that provide visibility into encrypted traffic flows. SSL/TLS decryption appliances and services are used for the following reasons:
- Monitoring of application performance
- Cloud services monitoring
- Malware detection
- DLP
- Forensic analysis

Solutions to manage encrypted traffic typically provide policy-based traffic direction and can improve performance.
Decrypting SSL traffic is only part of the equation. After decryption, the data has to be forwarded to the appropriate device for inspection. Analysis of the decrypted content is a joint effort and includes devices such as IDSs/IPSs, firewalls, secure web gateways, and DLP solutions. What device the packets go to depends on the policies in place. Much like SSL/TLS acceleration, SSL/TLS decryption can be offloaded to encrypted traffic management solutions. Further, network devices or systems beyond just DLP might require access to the decrypted traffic, and decrypted traffic can be forwarded to the appropriate device based on policies.

Data Integrity
Maintaining the integrity of data is an important part of ensuring data protection. The previous sections have shown many of the ways in which confidentiality can be applied to data, but what happens where the integrity of the document is critical? For example, a military commander might want to ensure the confidentiality of a message that says “Attack at dawn!” Protecting the integrity of that message is also critical. Imagine if the message were manipulated in transit to instead read “Attack at noon!” In fact, in many use cases, only data integrity and not confidentiality may be needed.

Data integrity is provided through a cryptographic method known as hashing, which is a cryptographic checksum, or through file integrity monitoring (FIM) solutions that employ hashing. Hashing with data integrity works much as it works in protecting passwords (“Attacks, Threats, and Vulnerabilities.”) Essentially, an algorithm is applied to a file to derive a checksum, and a checksum outputs a simple block of data. If the original document is modified, even slightly, a different checksum is produced. The electronic version of this book, for example, can be hashed to produce a simple output. The following example shows how to hash this guide and the resulting output:

MW@MacBook ~ % md5 enterprise-security-concepts.docx
MD5 (enterprise-security-concepts.docx)
=8ac9675d805a2d23f473684c4254c426

As long as the hashed .docx file does not change, every time it’s hashed with the same MD5 algorithm, it will produce the same hashed output shown here (8ac9675d805a2d23f473684c4254c426). Renaming the file or even changing one letter will produce different output. In fact, now that I have added just these few lines of text, the hashed value I get changes as shown here:
=8d15e340300307be5a0c3d2f14dc6a80
You can see that hashing is instrumental to ensuring the integrity of data within an organization. It has many applications, from documents to email communication to maintaining the integrity of system files. With system files, for example, hashing would reveal if a critical system file was subverted by malware.

Data Availability
In addition to confidentiality and integrity, availability is the final core piece of data protection.
Ensuring availability starts with analysis of business impacts and strong planning. Controls are required to ensure adequate response and recovery for organizations in case of breaches and disasters. For example, it is important to provide for regular backups of key information, including user file and email storage, database stores, event logs, and security details, such as user logons, passwords, and group membership assignments. A regular backup process helps ensure that loss of data through accidents or directed attacks does not severely impair an organization. In addition, an organization needs to plan detailed system restoration procedures, particularly in complex clustered, virtualized, and hybrid environments. This planning should explain any general or specific configuration details, such as those discussed earlier in this guide, that might be required to restore access and ensure data availability.
Contingency planning to recover systems and data is needed in case of personnel loss or lack of availability. A contingency plan should address, for example, the procedures to follow when a disgruntled employee changes an administrative password before leaving. Another contingency plan might consider what to do when backups are unrecoverable.

More and more application programming interfaces (APIs) are being made available across organizations and for use with external integrations to enable data flows across disparate systems and traditional boundaries. As a result, it is important to ensure confidentiality, integrity, and availability (CIA) of these APIs:
- API confidentiality: APIs, especially those accessing sensitive data, need to be protected using strong transport layer encryption. Controls should be in place to enforce appropriate authentication and access-based controls, depending on the intended use.
- API integrity: Protections to ensure the integrity of data should be in place based on unauthorized alterations to the data via the API.
- API availability: APIs can incur downtime and suffer from performance impacts, and they should be monitored to ensure proper function and availability.

Site Resiliency
In the event of a massive disaster or emergency, it might be necessary to operate at alternate site locations. Cloud infrastructure in recent years has helped tremendously with regard to site resiliency. Cloud infrastructure service providers offer options to choose from globally available physical locations that can be remotely provisioned to establish sites for recovery. The type of recovery site an organization chooses depends on the criticality of recovery and budget allocations. Three types of recovery sites exist:
- Hot site
- Warm site
- Cold site

Hot, warm, and cold sites can provide a means for recovery in the event that an event renders the original building unusable.
A hot site is a location that is already running and available 7 days a week, 24 hours a day. Such a site enables a company to continue normal business operations, usually within a minimal period after the loss of a facility. This type of site functions like the original site and is equipped with all the necessary hardware, software, network, and Internet connectivity fully installed, configured, and operational. Data is regularly backed up or replicated to the hot site so that it can be made fully operational in a minimal amount of time if a disaster occurs at the original site. If a catastrophe occurs, people simply need to drive to the site, log on, and begin working—without significant delay. Hot sites are the most expensive to operate and are most common in businesses that operate in real time and for which any downtime might mean financial ruin.
A warm site is a scaled-down version of a hot site that is generally configured with power, phone, and network jacks. The site might have computers and other resources, but they are not configured and ready to go. In a warm site, the data is replicated elsewhere for easy retrieval. However, you still must do something to be able to access the data; this “something” might include setting up systems so that you can access the data or taking special equipment to the warm site for data retrieval. It is assumed that the organization itself will configure the devices, install applications, and activate resources or that it will contract with a third party for these services. Because a warm site is generally office space or warehouse space, such a site can serve multiple clients simultaneously. It take more time and cost to get a warm site operational than it takes to begin using a hot site.
A cold site is the weakest of the recovery plan options but also the least expensive—at least in the short term. Keep in mind that obtaining equipment for a cold site after a disaster occurs might be difficult, and the price might be high. A cold site is merely a prearranged request to use facilities, if needed. Electricity, bathrooms, and space are about the only facilities a cold site contract provides, and the organization is responsible for providing and installing all the necessary equipment. With a cold site, it takes time to secure equipment, install operating systems and applications, and contract services such as Internet connectivity.
Be familiar with the various types of sites. Understand different scenarios for which you would choose a hot, warm, or cold site solution. Remember that a hot backup site includes a full duplicate of the source data center and has the fastest recovery time and highest cost. On the other hand, a cold backup site is the opposite and has a longer recovery window with a lower cost.

Geographic Considerations
Consideration of geography is critical for recovery and response. Think about alternate site planning, for example. The site should be located far enough from the original facility that it would be unlikely for the same disaster to strike both facilities. For example, the range of a flood depends on its category and other factors, such as wind and the amount of rain that follows. A torrential flood might wash away buildings and damage property such as electrical facilities. If the hot site is within the same flood range as the main site, the hot site will be affected, too.
Cloud infrastructure service providers may be used in lieu of or as complements to physical recovery sites. In fact, cloud providers themselves have data centers all over the world and provide various regions from which infrastructure can be deployed.
Finally, legal implications such as data sovereignty laws might dictate the extent to which geographies are considered. Data sovereignty applies to data that is subject to the laws of the geography (most often a specific country) where the data resides. For example, if an organization is legally bound to specific data within its country’s borders, offshore processing or backups would not be feasible.

Deception and Disruption
The honeypot may be the original deception technology. A honeypot can be used to identify the level of aggressive attention directed at a network and may be used to study an attacker’s common methods of attack. A honeypot is a system configured to simulate one or more services in an organization’s network. It is basically a decoy that is left exposed to network access. When an attacker accesses a honeypot system, the attacker’s activities are logged and monitored by other processes so that those actions and methods can be later reviewed in detail. In the meantime, the honeypot distracts the attacker from valid network resources. A honeypot might be a simple target exposed to identify vulnerability exposure. Alternatively, a honeypot might interact with an attacker to build a better attack profile by tracking and logging the attacker’s activities. Similarly, honeyfiles serve as bait on servers; these dummy files appear attractive to an attacker but do not contain any important information.
A honeynet, which is a collection of honeypots, creates a functional-appearing network that can be used to study an attacker’s behavior. Honeynets use specialized software agents to create seemingly normal network traffic. Honeynets and honeypots can distract attackers from valid network content and help an organization obtain valuable information on attackers’ methods. They also provide early warning of attack attempts that might later be waged against more secure portions of the network.

The deception provided by honeypots has evolved to be known generally as just deception. Honeypots required a lot of manual maintenance, didn’t scale well, and often weren’t believable; modern deception technologies overcome these problems and challenges. Many endpoint solutions, like those from Symantec, now incorporate deception. Complete platforms around deception, like those from TrapX Security, are available to assist with threat detection while providing for more advanced use cases. A deception platform provides a full solution for creating and managing a deceptive environment and deploying artifacts across networks, user endpoint devices, servers, and applications. These elements or artifacts are used to attract and engage an attacker. In order of increasing deployment complexity, these artifacts include the following:
- Decoy (including bogus networks)
- Lure (including fake laptops, workstations, and servers)
- Honeytoken (including fake data, folders, files, users, and other network elements)

As attackers move across the various phases of a penetration, the idea is that that they will interact with these artifacts, starting with their reconnaissance of the environment. A huge advantage that deception technologies provide is low false positives. The artifacts typically sit still doing nothing, and no alarms are generated until an attacker does something against them. Deception involves two important considerations:
- Believability: A deception technique should be believable, or it might not entice attackers. For some organizations that don’t have the resources to monitor and respond, this deterrence may be beneficial. However, for mature organizations with strong response capabilities or those that perhaps want to develop indicators of compromise, if an item is too believable, an attacker may ignore it. Striking the right balance in regard to believability is important.
- Interaction: The level of interaction with an artifact has an impact on its cost of operation. Low-interaction artifacts are less costly and simpler to deploy and manage. They are often more ideal for basic use cases related to threat detection. While high interaction artifacts are more costly, they provide greater insight and data for threat intelligence.

Modern deception technologies improve greatly over previous types, such as honeypots, primarily through automation. Automation improves ongoing maintenance of a system and decreases the requirement for specialized skills to manually create bogus artifacts. Today’s deception technologies provide the following:
- Automated discovery of networks and resources to learn what the environment looks like
- Automated creation, deployment, and updating of decoys, lures, and honeytokens
- Automated responses and alerts for the security teams

Think of honeypots, honeyfiles, honeynets, and deception technologies as traps that make it possible to fight unauthorized system access. They distract attackers from valid network content, enable you to study and learn an attacker’s methods, and provide early warning of attack attempts that might later be waged against more secure portions of the network. Traditional honeypots are rarely used today and have been replaced by more modern deception technologies that provide high levels of automation.
Deception technologies work not only against individual human attackers but also against malware. Beyond using deception, another way to disrupt malware is by using sandboxing. Sandboxing allows malware to be detonated and run within a virtual environment, where it can cause no real harm. This way, the malware can be analyzed and tested across a number of different operating systems. A DNS sinkhole is another example of disruption. A DNS sinkhole prevents the resolution of hostnames for specified URLs and can help steer users away from malicious resources. This technique was used to diffuse the WannaCry ransomware attack in 2017.
Remember that a DNS sinkhole protects users by preventing them from connecting to known malicious websites.

Quiz:

1. You are responsible for a critical business system. In case of disaster, this system needs to be operational within a minimal period of time at another site, regardless of cost. Which of the following recovery sites is most appropriate in this scenario? A. Hot site B. Warm site C. Cold site D. Resilient site

2. You decided to implement TLS encryption between two servers to protect the data being transferred between them. Which of the following states of data best represents what you are putting in place? A. Data at rest B. Data in transit C. Data in processing D. Data in use

3. Which of the following should be part of the configuration management process? (Select three.) A. HSM B. Diagrams C. Standard naming conventions D. IP schema

4. Which of the following helps an organization extend on-premises security solutions to the cloud? A. CASB B. Honeynet C. Honeyfile D. DNS sinkhole

Answer 1: A. A hot site is a location that is already running and available 7 days a week, 24 hours a day. Such a site allows a company to continue normal business operations usually within a minimal period after the loss of a facility. Answer B is incorrect as a warm site is a scaled-down version of a hot site. Answer C is incorrect as a cold site would be the cheapest and the weakest in terms of resiliency after a disaster. Answer D is incorrect. While all sites represent site resiliency, only a hot site provides the most resiliency.
Answer 2: B. Data in transit (or motion) represents data moving across a network or from one system to another, and it is what transport layer encryption protocols like TLS protect. Answers A and C are both incorrect. Data at rest represents data in its stored or resting state, which is typically on some type of persistent storage, such as a hard drive or tape. Data in processing represents data being processed in memory or cache. Answer D is also incorrect as this is often associated with data in processing, particularly as it pertains to DLP systems.
Answer 3: B, C, and D. Diagrams, standard naming conventions, IP schema, and baseline configurations should all be part of the configuration management process. Answer A is incorrect as a hardware security module is a device used to protect and manage the keys required as part of an encryption or decryption operation.
Answer 4: A. A cloud access security broker (CASB) helps an organization extend on-premises security solutions to the cloud. It is a solution that acts as an intermediary between users and cloud service providers (CSPs). Answers B, C, and D are incorrect as they are all deception technologies.