5 Questions with Tom Byrnes, CEO and Founder, ThreatSTOP

1. Why did you found ThreatSTOP? What was the primary security problem you were trying to solve?

I’ve been working in communications and Internet security my entire life. I got into the security aspect while doing tactical networking in the Army. I then had the good fortune to be part of two successful startups, Ipivot and Netsift, and, as a result, I found myself able to work on projects I found interesting, including a project to put all the tax returns for private foundations online, where they could be searched by grant seekers. Unlike large public foundations, private foundations tend to be local and focused on a particular issue or place that is important to their high net worth founders. It’s important to know the private foundation’s size since the grant amount and grant recipient is highly dependent on that information. In collaboration with the IRS, we took the TIFFs of the various private foundations’ returns (form 990PF) and scanned them to get the total assets, locations, and other relevant text from the return, and then put it online in a searchable database. We then converted the pages of the returns, which were single page TIFF files, into a single PDF per return that could be downloaded from the site.

While all of this indexing and obfuscation work was done entirely offline, on systems that were not connected to any network, and nothing containing PII or signatures was ever on any Internet connected system, the project was a constant target of hackers who were trying to find information that wasn’t available on the website.

Since this was a charitable endeavor, we worked with mostly donated equipment, and didn’t have a large budget for information security. I was the sole (part-time) system administrator. During my time in the Army, I had been involved with The Internet Storm Center, which was founded by Marc Sachs, former Director for Communication Infrastructure Protection, National Security Council, who I knew from “Digitizing the Dirt”; and Dr. Johannes Ullrich, SANS Fellow and director of the GIAC Gold program. To protect the site from the constant onslaught of cracking attempts, we used data from DShield, a project funded by the NSF called Cyber-TA, and several other sources of what is now called “Threat Intelligence” to actively protect the site from known hacking IPs. This was very effective at cutting down on the attack volume, but due to the dynamic nature of this data, it needed to be updated daily. Needless to say, it wasn’t fun work either, and doing it manually was error prone.

I tried multiple different tools to automate the process, but they all tended to break down in unpredictable ways, were typically limited in what platforms they supported and didn’t have the ability to easily take in new inputs. I hit on the idea of using a DNS lookup to populate the ACLs, and it worked. This allowed me to have a standard data format for all the entries I wanted in a block list that was universally supported by devices and hosts, since anything that uses the Internet has to have a functioning DNS resolver. I implemented some simple parsers to take the data to use for blocking and turn it into DNS lookups, put those DNS records on my personal DNS server (which was, and still is, in what would be the third garage of my house, which I converted into an office), and then used those DNS lookups to update the rules. The result turned what had been taking 10-15 hours a week into a matter of checking that the zone generation worked. This gave me back 2 hours a day, at least, and worked better than the manual process.

I showed this to Marc Sachs and Paul Mockapetris (the inventor of DNS), and they encouraged me to turn it into a service. With Johannes Ullrich’s approval, I sent a survey to the DShield mailing list asking if anyone was interested in the service, and over 300 replied in the affirmative. As a result, I started an open source project that ultimately became ThreatSTOP -- taking arbitrary Threat Intelligence and delivering it to any network element, DNS server, or host, where it can be enforced, and in time to prevent, rather than merely report on, attacks.

2. What are the top three cybersecurity threats facing organizations today?

Ignorance, Apathy, and Snake Oil. While that may sound trite, it is true IMO. The biggest one is Snake Oil. The reality is that most products and solutions being sold don’t actually address a security problem. If they did, we wouldn’t have constant breaches. The vendors, by and large, sell complex, hard-to-implement systems that cost a lot of money and require significant expertise to maintain. Due to historical aversion to impacting user experience, they report on incidents after-the-fact and work incident response instead of prevention. That is born of ignorance, IMO. The cost of a false negative resulting in something like ransomware is far greater than some transient inconvenience caused by a false positive that can easily be rectified with whitelisting. Tool sprawl and the drumbeat of alerts lead to fatigue. The sense that no matter what you do you can’t win leads many to just shake their heads and do “check the box” security which allows them to point to their compliance with regulations and best practices, and avoid responsibility and accountability. Which leads us to . . .

3. Today the assumption in the security industry is that most organizations have already been hacked. If that is the case, does this make cybersecurity “prevention” obsolete?

Malware in your network or having a compromised system, in and of itself, does not mean you can’t prevent actual damage. While it’s true that just about everyone has compromised systems or active malware of some kind (from the inception of ThreatSTOP we have only found one network we have been installed on that did not have active malware that had bypassed their existing controls), that malware still needs to be able to communicate with its masters to execute their commands and exfiltrate the data. So, while you may be “hacked,” you are not completely cracked, as long as you can identify and interdict the data exfiltration and command and control.

This is where the Domain Name System (DNS) is the natural enforcement point. A criminal or spy in cyberspace has the same weakness as ones in the real world. They need a “safe house”, “deadletter drop”, “fence” or “chop shop” -- resources they control and can trust to send their goods. While they can change resources easily, and are not bound by distance, in the Internet, these bad actors still can only use a limited portion of the available infrastructure. Communications on the Internet almost always start with a DNS query to discover the actual IP address to connect to. Out of necessity, that information has to be public and reachable from anywhere. Identifying the domain names, and the underlying infrastructure serving the domain names, used by malware enables a very effective, cross platform, way to interdict that communication. Most importantly, it doesn’t require touching every device, or routing all traffic through inspection devices or cloud proxies. It can work anywhere, and with any device.

4. Can you explain ThreatSTOP NOD and how it benefits today’s organizations?

ThreatSTOP NOD takes the Newly Observed Domains (NOD) data provided by Farsight and makes domain names that have been newly observed in the last 24 hours and/or 5 days available to customers to use for filtering in their DNS servers and other network security elements. The data is updated every 15 minutes, and is available in Response Policy Zone format (for systems that support that, including BIND and its derivatives), as Microsoft DNS Policies (for Active Directory 2016 and later), and as STIX/TAXII, CSV, TSV, SNORT and Suricata formatted files (for IDS/IPS and SIEM).

Most newly observed domains are not associated with regular traffic. If a legitimate entity registers and starts to use a domain, they usually spend some time setting up the resources needed to service the domain, and testing it, before putting it into actual use. Criminals and nation-state attackers, on the other hand, are constantly trying to change their infrastructure as soon as it gets identified, so they will register a domain and start using it immediately as a destination for phishing, DNS tunneling, or other ways to get information or control systems. Not talking to a domain that is less than a day old has a very low risk of a false positive and will block a lot of what is bad. In the rare cases where the domain is legitimate, the ThreatSTOP system has a very simple way to whitelist in the GUI directly from reporting, and the next update will clear the block. The reason we also offer a five-day dataset is that it is the length of time within which ICANN allows someone to abandon a registration without the registrar having to send ICANN the fee. Often, criminals will “taste” a domain by registering it and seeing what traffic goes there (typosquatting, for example), but not complete the registration. In general, unless you have a large organization, the five-day set will provide significant reduction in criminal and other wasted network traffic.

5. In addition to implementing ThreatSTOP NOD, what other steps can organizations take to reduce the risk of phishing and other cyberthreats associated with new domains?

It has been said again and again, but most of the compromises we hear about would have been prevented by following basic network hygiene:

Patch regularly and timely. Don’t forget to update your network devices in addition to your servers, pcs, laptops and phones. Printers, DVRs and the like are frequently vectors of compromise.
Use a proper network firewall and limit traffic to those places that are needed for your mission. Resist the temptation to allow something just because someone wants access. Do they need this to do their job?
Segment your network by security profile and severely limit connections to and from IoT devices. There is no reason for your printers to be contacting hosts outside your network except by exception (when updating firmware). BYOD should be on a separate and much less trusted network.
Use both Endpoint and Network security, and monitor them: yes, you need reporting and alerting for your network and security events.
Apply Threat Intelligence both to interdict the known bad stuff and prioritize event triage.
When using the cloud, realize you are still responsible for security, and that it isn’t free.
Educate your users about phishing -- and then phish them, applying learning, not shaming, to the ones who get caught.
Use at least 2-Factor Authentication for access, and 2FA with a physical token for any sensitive information.

There are many more, but if the organizations that made headline-making data breaches (take your pick of Target, Experian, Capital One etc.) followed these steps, over 90% of incidents reported in the past two years simply would not have happened.