What does it mean to say that an indicator is exhibiting persistent behavior? This is a question that Timur, Angela, and I have been asking each other for the past couple of months. In this blog post, we show you the analytics that we believe identify persistent behavior and how that identification can be used to identify potential threats as well as help with network profiling.
As you may have read in a previous post, the CERT/CC has been actively researching vulnerabilities in the connected vehicles. When we began our research, it became clear that in the realm of cyber-physical systems, safety is king. For regulators, manufacturers, and the consumer, we all want (and expect!) the same thing: a safe vehicle to drive. But what does safety mean in the context of security? This is the precisely the question that the National Highway Transit Safety Administration (NHTSA) asked the public in its federal register notice.
We worked with DHS US-CERT and the Department of Transportations' Volpe Center to study aftermarket on-board diagnostic (OBD-II) devices to understand their cybersecurity impact on consumers and the general public.
One of my responsibilities on the Situational Awareness Analysis team is to create analytics for various purposes. For the past few weeks, I've been working on some anomaly detection analytics for hunting in the network flow traffic of common network services. I decided to start with a very simple approach using mean and standard deviation for a historical period to create a profile that I could compare against current volumes. To do this, I planned on binning network traffic by some length of time to find time periods with anomalous volumes. The question I then had to answer was, "How should I define the historical period?" In this post, I explain the process I used to answer that question.
The CERT/CC Vulnerability Analysis team has been engaged in a number of community-based efforts surrounding Coordinated Vulnerability Disclosure lately. I've written previously about our involvement in the NTIA Multistakeholder Process for Cybersecurity Vulnerabilities. Today I'll highlight our ongoing work in the Forum for Incident Response and Security Teams (FIRST). We are currently active in two vulnerability-related working groups within the FIRST organization: the Vulnerability Coordination SIG (recently merged with the NTIA Multiparty Disclosure working group), and the Vulnerability Reporting and Data eXchange SIG (VRDX-SIG). At the CERT Vendor Meeting on February 29, I presented some of our current work within the VRDX-SIG. Given a number of developments in the intervening week I'm introducing that work to a broader audience in this post.
The CERT/CC Vulnerability Analysis team for nearly 30 years now has provided assistance for coordinated vulnerability disclosure (CVD). In a nutshell, we help security researchers communicate with software vendors to resolve security issues, and we get that information in the hands of anyone affected by the vulnerability. The CVD process can be confusing. To help researchers and vendors who are new to CVD, we're announcing a couple of simple but important additions to our CVD services.
The CERT Coordination Center (CERT/CC) has been receiving an increasing number of vulnerability reports regarding Internet of Things devices and other embedded systems. We've also been focusing more of our own vulnerability discovery work in that space. We've discovered that while many of the vulnerabilities are technically the same as in traditional IT software, the coordination process has some substantial differences that will need to be addressed as the Internet of Things grows.
MRT is a file format used in BGP; in particular, it is used when the router writes updates into a log file. There are many programs out there for parsing these files, but I'm going to talk about a new program created at the CERT Division for searching the files. The program is designed to find routes that affect a given set of CIDR blocks, and to do it quickly.