Experience shows that most software contains code flaws that can lead to vulnerabilities. Static analysis tools used to identify potential vulnerabilities in source code produce a large number of alerts with high false-positive rates that an engineer must painstakingly examine to find legitimate flaws. As described in this blog post, we in the SEI's CERT Division have developed the SCALe (Source Code Analysis Laboratory) tool, as we have researched and prototyped methods to help analysts be more efficient and effective at auditing static analysis alerts. In August 2018 we released a version of SCALe to the public (open-source via Github).
In the first post in this series, I introduced the concept of the Minimum Viable Capability (MVC). While the intent of the Minimum Viable Product (MVP) strategy is to focus on rapidly developing and validating only essential product features, MVC adapts this strategy to systems that are too large, too complex, or too critical for MVP.
MVC is a scalable approach to validating a system of capabilities, each at the earliest possible time. Capability scope is limited (minimum) so that it may be produced as soon as possible. For MVP, as soon as possible is often a just a few weeks. But what does as soon as possible mean for an MVC? This post explores how technical dependencies and testability determine that, and what this implies for a system roadmap. Let's start with the pattern of MVC activities to produce a major release.
At the 2018 World Economic Forum, global leaders voiced concerns about the growing trend of cyberattacks targeting critical infrastructure and strategic industrial sectors, citing fears of a worst-case scenario that could lead to a breakdown of the systems that keep societies functioning. A painful example was the May 2017 WannaCry ransomware attack in which a worm rapidly spread through a number of computer networks, affecting more than 150 countries and more than 400,000 endpoints.
One of the largest victims of the WannaCry attack was the National Health Service in England and Scotland, where up to 70,000 computers, MRI scanners, and blood-storage refrigerators may have been affected. In this global threat environment, the need for Computer Security Incident Response Teams (CSIRTs) has become ever more critical. CSIRTs are expert teams that use their specialized knowledge and skills to detect and respond to computer security incidents. In the broader internet community, these teams form a "global network" from a diverse group of organizations and sectors, such as critical infrastructure, government, industry, and academia. In this blog post, the first in a series on CSIRTS, I talk about the work of CSIRTs and their importance in the global threat landscape.
Billions of dollars in venture capital, industry investments, and government investments are going into the technology known as blockchain. It is being investigated in domains as diverse as finance, healthcare, defense, and communications. As blockchain technology has become more popular, programming-language security issues have emerged that pose a risk to the adoption of cryptocurrencies and other blockchain applications. In this post, I describe a new programming language, Obsidian, which we at the SEI are developing in partnership with Carnegie Mellon University (CMU) writing secure smart contracts in blockchain platforms.
The CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University recently released the Cyobstract Python library as an open source tool. You can use it to quickly and efficiently extract artifacts from free text in a single report, from a collection of incident reports, from threat assessment summaries, or any other textual source.