Over the last several months I’ve discussed various aspects of privacy as it relates to network engineers, starting with why privacy is important, working through what Personally Identifiable Information (PII) is, and then looking at kinds of information network engineers collect and manage that might have privacy implications. While these posts haven’t covered every aspect of privacy, they should serve as a good introduction to the topic, and help readers figure out what questions to ask, and where to look for answers.
For the final post in this series, I’ll address two topics: the privacy implications of Domain Name System (DNS) queries, and the absolute necessity of having a plan for how to respond to a breach. Let’s start with DNS.
Privacy And DNS
DNS queries can, if not properly handled, leak private information. From an organizational perspective, the frequency and kind of DNS resolutions requested can disclose a good deal of information about business operations. Improperly formed DNS queries can reveal information about internal infrastructure. DNS queries can include too much information at the authoritative, top level domain, and root level, exposing private information.
Even DNS query patterns, including the frequency and kinds of resolution requests, can expose information about mergers, acquisitions, and organizational partnerships that organizations would often rather not expose. Further, DNS queries are often logged (internally or externally), allowing this kind of private information to be mined over time.
Network operators should control the scope of DNS queries and pay attention to the privacy policies of any public DNS services they rely on. For locally managed DNS services, query logs should be deidentified over time using the same kinds of best practices discussed in relation to packet and IP address logging.
Have A Breach Plan
Believing your organization will never be breached is just sticking your head in the sand. If you think your security is so strong you can never be breached, you are wrong. Even large-scale, security focused organizations like cloud providers and law enforcement agencies have been breached.
If you think you’re too small for anyone to care, you are wrong. The two largest myths in cyber-security are “I’m just not all that interesting,” and “If you’ve done nothing wrong, you have nothing to fear.” Every network operator should banish from their thinking these excuses—and that’s what they are, excuses—for failing to properly secure their data.
It’s not a matter of if your organization will suffer a breach of some kind. It’s a matter of when.
And when your organization is breached, you need to have a solid plan in place. While I cannot give you a complete breach plan for your organization, I can give you several steps.
First, you need to know that you’ve been breached. Not every intrusion is going to come with a ransom note; a stealthy exfiltration attack can be just as devastating as ransomware. Network operators should proactively search the Internet for data they maintain. You can engage a service in this area where needed.
Second, you should have a plan for collecting and preserving evidence of the breach. Such evidence will be helpful (and perhaps necessary) when working with law enforcement, regulators, insurance companies, and lawyers. The same evidence will also be useful in your remediation phase. Have your collection and preservation plans in place ahead of time instead of trying to figure them out when everyone’s hair is on fire.
Third, you need to discover how the attacker breached your systems, how long they had access to your information, and what needs to be done to close the hole or holes.
Fourth, you should assess the material the attacker has gained access to. Does this information contain PII? Confidential company information? Was the data encrypted, deidentified, or otherwise managed in a privacy-friendly way? How likely is it the attacker will recover actionable information?
Fifth, you need to calculate the likely material damage of the information the attacker has gained access to. Consider organizational damage, such as reputation and finances, but also potential users inside and outside of your organization.
Sixth, once you have a good assessment of what has happened, you will likely need to report the breach to relevant authorities, and potentially to internal and external users. Legal reporting requirements vary among jurisdictions; you need to investigate what they are right now, understand them, and put them into your breach plan. Don’t be caught looking for this kind of information in the middle of a breach.
Some jurisdictions don’t require reporting breaches if the attacker only gained access to encrypted data, or if the data has been deidentified in a way that makes it useless. Doing the right thing with data during normal operations can significantly reduce your risk.
Seventh, once all of this is done, you can start thinking about how to remediate. How did the attacker get into the system? Is more training needed? Should your organization mandate the use of a password manager (some are starting to do this)? Do you need to pay more attention to software defects with security implications in your network gear?
The bottom line on privacy is this: Take it seriously. It’s not just a matter of providing legal cover, but of treating your internal and external users with respect.