Top Stories
Using Packet-based NPMD Tools to Prepare for GDPR Breach Reporting
Published by Gbaf News
Posted on May 14, 2018
17 min readLast updated: January 21, 2026
Global Banking and Finance Review
Company
Published by Gbaf News
Posted on May 14, 2018
17 min readLast updated: January 21, 2026
The new GDPR regulations present a number of challenges to the IT and security teams of any enterprise doing business in the EU. One challenge that will be particularly difficult to meet is the need to quickly notify regulatory authorities of a data breach. The language of Article 33 states that companies must inform the authorities “without undue delay and, where feasible, not later than 72 hours after becoming aware of it.” This is made even more challenging since the accompanying report must provide very specific information about who and what was affected, specifying:
The GDPR regulations recognize that not all breaches cause the same amount of damage, so they only require notification of authorities “when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons.” This turns out not to significantly limit the reporting requirement, however, because of its very broad definition of personal data. Other landmark personal data protection laws—suchas California’s Data Protection Act of 2003—specified the kinds of data that would lead to identity theft, i.e. a driver license, social security number, mother’s maiden name, etc. However, GDPR includes any information that results in risks to “rights and freedoms” which includes risk of embarrassment, harassment, and physical threats, so breaches of data types such as email, images, geo-location, social media or chat apps must be included.
Breach Detection and Remediation
The 72-hour breach reporting requirement mentioned above is at odds with the current reality of cyber-forensic investigations. A SANS report (Cleaning Up After a Breach) revealed that 75 percent of breaches take anywhere from several weeks to over a year to remediate, far longer than the 72 hours required under GDPR.
The good news is that the reason most breach remediations take so long is that organizations focus almost exclusively on preventing intrusions and are almost wholly unprepared to investigate a breach should one occur. Some view breach preparation as admission that their prevention strategy is inadequate, a nonsensical argument at best. Compounding the issue is the belief by many organizations that they retain sufficient data for effective investigations, and by the time they learn differently, it is too late.
So why is this lack of preparation good news? Because effective preparation for rapid breach investigations is entirely possible and can be addressed with current technology and practices. It is worth noting that some of this preparation is most effectively undertaken with tools designed for Network Performance Management and Diagnostics (NPMD). These products are designed to capture network traffic in a manner that makes possible rapid forensic investigations into elusive network performance issues. The data the NPMD tools capture and the analytics they apply can be a vital component of forensic investigations into breaches.
Forensic Investigations into Breaches
In a large percentage of breaches, the attacker is still active in the breached systems. Once breached, a high priority is determining whether there is unwanted activity right now. Although tools that can assist in making this determination are outside the scope of this paper, it is another area where NPMD monitoring tools have a vital role to play.
Simultaneous with the determination of current activity and often extended long after it has been completed, a forensic investigation is undertaken to determine what was affected and how it happened. This forensic investigation, which not incidentally also produces the information required by a GDPR breach report, will likely require information from four different domains: the network traffic information, the activity logs of each computer, server, and router on the network, the behaviors of users in the organization, and lastly some information about what is stored in the memory (RAM, Flash, etc.) of each computer.
If any of these four types of information is missing, it must be recreated, if it can be; a lengthy and expensive process. Even if it is available in a general way, it must be specifically available for the period under investigation. This “investigation window” varies by type of information.
One of the most important, and certainly the most definitive source of information, is packet-level network traffic data. While much of the compromised personal data itself might be found in backups of the relevant databases, packet-level network traffic data contains the transaction information revealing how data was entered or deleted, which programs or individuals could access it, which other hosts on the network or in the broader internet could view or copy the information, and how the intrusion was conveyed and disguised.
There really is no substitute. Many breached organizations have found out only too late, to their chagrin, that the first thing malware authors do is cover their tracks by changing log data, eliminating transaction records, and generally making metadata less or not at all useful to forensic investigations. Packet-level network traffic is generally stored in a write-once-then-overwrite manner not susceptible to this kind of manipulation.
It is in this packet-level network traffic that malware is conveyed, and breached data exfiltrated. This traffic contains the fingerprints of source and origin in a manner that is difficult to disguise or manipulate. It provides the cloak under which the cybercriminal hides their malicious software.Having ready access to stored packet-level network traffic, together with the appropriate tools, processes, and personnel provides an opportunity for rapid and effective network investigations.
Retaining Packet-level Network Traffic Data
Retaining packet-level network traffic data negates the need to start recording network traffic as soon as awareness of a breach occurs. The purpose of capturing network traffic is to have original information: exact duplicates of the packets that conveyed the original intrusion, the installation, migration, and management of the malware, and the exfiltration of the company data. If these activities occur during the retention window for network traffic, then all that is required is forensic analysis software. If not, the insights that would have resulted from the missing data must be inferred, if they even can be, from other data sources.
There are many NPMD tools on the market for capturing and storing packet-level network traffic data. The challenge is that files of these transactions can become very large and are often only retained for a fairly short period, sometimes just hours or days. There are ways to reduce the amount of packet-level traffic to be stored for any given time period, but there is always a danger that the cybercriminal, in a bid to disguise their malware, will make it appear innocuous, just the kind of traffic most likely to be filtered out.
Determining the desired retention window is an important first step. NPMD vendors are, of course, happy to help you determine how to meet your requirements. Then you must determine how you will use the network traffic you’ve started to store.
Other Preparations for Breach Investigations
GDPR’s rapid breach reporting requirement implies more than just storing more data and better forensic analysis tools. In order to use these tools and information, the organization must have the trained personnel and operational procedures in place to provide these rapid answers. Today, many organizations rely upon external, skilled contract investigators to perform forensic investigations when required, often on an ad-hoc basis. While this is currently the most cost-effective way to deal with what are, hopefully, rare occurrences, the data required for the breach investigations must already be available for the investigation to be effective and definitive.
After the Breach
In the event of a breach, information from each of the four domains—if available—will need to be assembled and cross-correlated to build up a complete picture of the attack. Once all the pieces of the cyber puzzle are assembled, it will become easier to assess the damage in terms of compromised personal information as well as the steps necessary to correct the deficiencies that enabled the attack.
As the dust settles and the full extent of each breach is determined, the final actions and next steps need to be assessed without ambiguity. “Does the extent of the breach require that we notify our customers?” “Where was the vulnerability in our network and what are we doing to correct it?” “What expenses are we going to incur through possible litigation or other remediation going forward?” While GDPR provides a framework of requirements intended to protect the private information of consumers, simply adhering to its prescriptions is not enough. Once a breach occurs, an organization’s most important goal is to protect its relationship with the customer. While the penalties outlined in GDPR are intended to be punitive, they will pale beside the damage to a company abandoned by its customers.
Conclusion
Every organization must have an already-established response plan to meet the stringent time requirements of GDPR. The significant financial penalties levied on organizations that do not comply with these reporting requirements make this a C-suite issue.
Effective breach preparation requires storing the information required for forensic investigations, and this means packet-level network traffic, not just log data. Without information about what packets were flowing through the network, what applications were manipulating and storing information, and what users had been doing with that information, it will be impossible for investigators to answer even the most basic questions about the extent or impact of the breach at all, much less within a 72-hour window.
Meeting the requirements of GDPR can reduce corporate risk in the event of a data breach, and NPMD products can help meet those requirements. Every organization should include preparation for breach remediation in their cybersecurity strategy.
The new GDPR regulations present a number of challenges to the IT and security teams of any enterprise doing business in the EU. One challenge that will be particularly difficult to meet is the need to quickly notify regulatory authorities of a data breach. The language of Article 33 states that companies must inform the authorities “without undue delay and, where feasible, not later than 72 hours after becoming aware of it.” This is made even more challenging since the accompanying report must provide very specific information about who and what was affected, specifying:
The GDPR regulations recognize that not all breaches cause the same amount of damage, so they only require notification of authorities “when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons.” This turns out not to significantly limit the reporting requirement, however, because of its very broad definition of personal data. Other landmark personal data protection laws—suchas California’s Data Protection Act of 2003—specified the kinds of data that would lead to identity theft, i.e. a driver license, social security number, mother’s maiden name, etc. However, GDPR includes any information that results in risks to “rights and freedoms” which includes risk of embarrassment, harassment, and physical threats, so breaches of data types such as email, images, geo-location, social media or chat apps must be included.
Breach Detection and Remediation
The 72-hour breach reporting requirement mentioned above is at odds with the current reality of cyber-forensic investigations. A SANS report (Cleaning Up After a Breach) revealed that 75 percent of breaches take anywhere from several weeks to over a year to remediate, far longer than the 72 hours required under GDPR.
The good news is that the reason most breach remediations take so long is that organizations focus almost exclusively on preventing intrusions and are almost wholly unprepared to investigate a breach should one occur. Some view breach preparation as admission that their prevention strategy is inadequate, a nonsensical argument at best. Compounding the issue is the belief by many organizations that they retain sufficient data for effective investigations, and by the time they learn differently, it is too late.
So why is this lack of preparation good news? Because effective preparation for rapid breach investigations is entirely possible and can be addressed with current technology and practices. It is worth noting that some of this preparation is most effectively undertaken with tools designed for Network Performance Management and Diagnostics (NPMD). These products are designed to capture network traffic in a manner that makes possible rapid forensic investigations into elusive network performance issues. The data the NPMD tools capture and the analytics they apply can be a vital component of forensic investigations into breaches.
Forensic Investigations into Breaches
In a large percentage of breaches, the attacker is still active in the breached systems. Once breached, a high priority is determining whether there is unwanted activity right now. Although tools that can assist in making this determination are outside the scope of this paper, it is another area where NPMD monitoring tools have a vital role to play.
Simultaneous with the determination of current activity and often extended long after it has been completed, a forensic investigation is undertaken to determine what was affected and how it happened. This forensic investigation, which not incidentally also produces the information required by a GDPR breach report, will likely require information from four different domains: the network traffic information, the activity logs of each computer, server, and router on the network, the behaviors of users in the organization, and lastly some information about what is stored in the memory (RAM, Flash, etc.) of each computer.
If any of these four types of information is missing, it must be recreated, if it can be; a lengthy and expensive process. Even if it is available in a general way, it must be specifically available for the period under investigation. This “investigation window” varies by type of information.
One of the most important, and certainly the most definitive source of information, is packet-level network traffic data. While much of the compromised personal data itself might be found in backups of the relevant databases, packet-level network traffic data contains the transaction information revealing how data was entered or deleted, which programs or individuals could access it, which other hosts on the network or in the broader internet could view or copy the information, and how the intrusion was conveyed and disguised.
There really is no substitute. Many breached organizations have found out only too late, to their chagrin, that the first thing malware authors do is cover their tracks by changing log data, eliminating transaction records, and generally making metadata less or not at all useful to forensic investigations. Packet-level network traffic is generally stored in a write-once-then-overwrite manner not susceptible to this kind of manipulation.
It is in this packet-level network traffic that malware is conveyed, and breached data exfiltrated. This traffic contains the fingerprints of source and origin in a manner that is difficult to disguise or manipulate. It provides the cloak under which the cybercriminal hides their malicious software.Having ready access to stored packet-level network traffic, together with the appropriate tools, processes, and personnel provides an opportunity for rapid and effective network investigations.
Retaining Packet-level Network Traffic Data
Retaining packet-level network traffic data negates the need to start recording network traffic as soon as awareness of a breach occurs. The purpose of capturing network traffic is to have original information: exact duplicates of the packets that conveyed the original intrusion, the installation, migration, and management of the malware, and the exfiltration of the company data. If these activities occur during the retention window for network traffic, then all that is required is forensic analysis software. If not, the insights that would have resulted from the missing data must be inferred, if they even can be, from other data sources.
There are many NPMD tools on the market for capturing and storing packet-level network traffic data. The challenge is that files of these transactions can become very large and are often only retained for a fairly short period, sometimes just hours or days. There are ways to reduce the amount of packet-level traffic to be stored for any given time period, but there is always a danger that the cybercriminal, in a bid to disguise their malware, will make it appear innocuous, just the kind of traffic most likely to be filtered out.
Determining the desired retention window is an important first step. NPMD vendors are, of course, happy to help you determine how to meet your requirements. Then you must determine how you will use the network traffic you’ve started to store.
Other Preparations for Breach Investigations
GDPR’s rapid breach reporting requirement implies more than just storing more data and better forensic analysis tools. In order to use these tools and information, the organization must have the trained personnel and operational procedures in place to provide these rapid answers. Today, many organizations rely upon external, skilled contract investigators to perform forensic investigations when required, often on an ad-hoc basis. While this is currently the most cost-effective way to deal with what are, hopefully, rare occurrences, the data required for the breach investigations must already be available for the investigation to be effective and definitive.
After the Breach
In the event of a breach, information from each of the four domains—if available—will need to be assembled and cross-correlated to build up a complete picture of the attack. Once all the pieces of the cyber puzzle are assembled, it will become easier to assess the damage in terms of compromised personal information as well as the steps necessary to correct the deficiencies that enabled the attack.
As the dust settles and the full extent of each breach is determined, the final actions and next steps need to be assessed without ambiguity. “Does the extent of the breach require that we notify our customers?” “Where was the vulnerability in our network and what are we doing to correct it?” “What expenses are we going to incur through possible litigation or other remediation going forward?” While GDPR provides a framework of requirements intended to protect the private information of consumers, simply adhering to its prescriptions is not enough. Once a breach occurs, an organization’s most important goal is to protect its relationship with the customer. While the penalties outlined in GDPR are intended to be punitive, they will pale beside the damage to a company abandoned by its customers.
Conclusion
Every organization must have an already-established response plan to meet the stringent time requirements of GDPR. The significant financial penalties levied on organizations that do not comply with these reporting requirements make this a C-suite issue.
Effective breach preparation requires storing the information required for forensic investigations, and this means packet-level network traffic, not just log data. Without information about what packets were flowing through the network, what applications were manipulating and storing information, and what users had been doing with that information, it will be impossible for investigators to answer even the most basic questions about the extent or impact of the breach at all, much less within a 72-hour window.
Meeting the requirements of GDPR can reduce corporate risk in the event of a data breach, and NPMD products can help meet those requirements. Every organization should include preparation for breach remediation in their cybersecurity strategy.
Explore more articles in the Top Stories category
