Ingress and Egress Monitoring

Ingress monitoring refers to surveillance and assessment of all inbound communications traffic and access attempts.

• Firewalls
• Gateways
• Remote authentication servers
• IDS/IPS tools
• SIEM solutions
• Anti-malware solutions

As with all security tools, solutions used for ingress monitoring must be maintained, patched, and updated as necessary for signature libraries and configuration changes. Also, the overhead cost in terms of both maintenance of these tools and impact to productivity must be considered.

Egress monitoring is used to regulate data leaving the organization's IT environment.

The term currently used in conjunction with this effort is "DLP"; a marketing descriptor without standard definition, it is often referred to as "data leak protection" or "data loss protection," or some combination of those words.

For purposes of addressing this topic, the term DLP will be used synonymously with egress monitoring.

DLP tools function by comparing data leaving the control of the organization against a rule set to determine whether that action is allowed. The DLP rule set can be defined by the following:

Signature

Particular types of data might conform to certain strings that are readily identifiable and can, therefore, be recognized by the tool. For instance, a DLP set to prevent the egress of credit card information might be taught to search for and sequester any 15 to 20 string of numeric characters.

Pattern Matching

The DLP might be conditioned to look for two-word strings where each word starts with one uppercase character and the rest are lowercase; in this way, the DLP might restrict the export of individual names. This might also be done for the frequency of a given word/ words in the context of a page or throughout a document to prevent the egress of proprietary or confidential information.

Labeling

Sensitive assets within the environment might be tagged with specific labels that will be recognized by the DLP tool. For instance, an organization trying to protect proprietary information might embed labels such as "copyright," "proprietary," or "confidential" in data assets that should not be shared outside the organization.

For DLP solutions to function properly, they usually need to be deployed in conjunction with and as part of an overall data protection effort within the organization. Deployment is often construed as having the following three facets:

• Data at rest is placement of DLP agents in data storage locations (both physical and logical), such as databases and archives.
• Data in motion is DLP software that inspects outbound communications traffic.
• Data in use is DLP agents installed on endpoint devices. (This is especially important in bring your own device (BYOD) environments and cloud deployments, where users process the organization's data on devices owned by the user.)

The overall data protection effort needed to support DLP includes the following:

The DLP solution should be deployed such that it can inspect all forms of data leaving the organization, including:

• Email (content and attachments)
• Copy to portable media
• File Transfer Protocol (FTP)
• Posting to web pages/sites
• Application/application programming interface (API)

Data discovery, classification, categorization

To know what to protect, the organization needs to know what it owns; the candidate should recall this point from the earlier discussion of asset inventories. DLP tools are often equipped with discovery tools to aid in initial data recognition, and they can also be used to categorize and or classify the organization's data assets.

Enforcement

The DLP enforcement settings should reflect the ideal response suited to the organization's risk/benefit appetite and level of scrutiny. Examples of different organizational intent for DLP might include the following:

• Training: The DLP tool might identify a user's attempt to distribute sensitive information and merely remind the user of the organization's policy and the sensitivity of the material the user is distributing.
• Attribution/assigning responsibility: The DLP tool might ask for the user to confirm intent to distribute sensitive information; the confirmation acts as the user's indication of accepting responsibility for distributing that information.
• Stringency/prevention: The DLP tool might halt the transaction upon identifying sensitive information, lock the user's account, and inform management/security of the attempt.

DLP tools can serve many functions, depending on how they are deployed and what settings the organization applies. These functions can include the following:

• Compliance
• Security
• Training and awareness
• Due diligence
• Asset management

One of the current challenges that DLP and ISCM systems approaches need to cope with is the growing need to implement them within a zero-trust architecture and not just at its perimeters.