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.
On September 29, Art Manion and I attended the first meeting of the Multistakeholder Process for Cybersecurity Vulnerabilities initiated by the National Telecommunications and Information Administration (NTIA), part of the United States Department of Commerce. There has been ample coverage of the meeting in blogs (e.g., by Dr. Neal Krawetz and by Cris Thomas), mailing lists, and media reports, so I won't attempt to duplicate that information.
During the course of the meeting, I became increasingly aware that no one had actually specified who the "stakeholders" are. The name of the process implies there are more than one, but nowhere in the accompanying materials was there a comprehensive list of who is perceived to hold a stake in this process. In this post, you'll find my take on who those stakeholders are and how the set of players has changed over the past decade.