Every January on the SEI Blog, we present the 10 most-visited posts of the previous year. This year's list of top 10 is presented in reverse order--culminating in the most-visited post--and features posts published between January 1, 2020 and December 31, 2020.

10. Vulnonym - Stop the Naming Madness

9. Security Automation Begins at the Source Code

8. 8 Steps for Migrating Existing Applications to Microservices

7. Comments on NIST IR 8269: A Taxonomy and Terminology of Adversarial Machine Learning

6. Beyond NIST SP 800-171: 20 Additional Practices in CMMC

5. COVID-19 and Supply-Chain Risk

4. Snake Ransomware Analysis Updates

3. Three Risks in Building Machine Learning Systems

2. An Introduction to the Cybersecurity Maturity Model Certification (CMMC)

1. Programmer Moneyball: Challenging the Myth of Individual Programmer Productivity

10. Vulnonym - Stop the Naming Madness

by Leigh Metcalf

Spectre. Meltdown. Dirty Cow. Heartbleed. All of these are vulnerabilities that were named by humans, sometimes for maximum impact factor or marketing. Sensational names are often the tool of the discoverers to create more visibility for their work, but not every named vulnerability is a severe vulnerability, despite what some researchers want you to think. This naming madness is an area of concern for the CERT Coordination Center as we attempt to reduce any fear, uncertainty, and doubt for vendors, researchers, and the general public. The CERT/CC decided that if we can come up with a solution to this problem, we can help with discussions about vulnerabilities as well as mitigate the fear that can be spread by a vulnerability with a scary name.

Read the entire post.

9. Security Automation Begins at the Source Code

by Vijay Sarvepalli

On what seemed like a normal day at our vulnerability coordination center, one of my colleagues asked me to look into a vulnerability report for pppd, which is an open-source protocol. At first glance, this vulnerability appeared to have the potential to affect multiple vendors throughout the world. These widespread coordination cases usually have a prolonged coordination timeline. They typically involve multiple vendors on the one end and a security researcher (or "Finder" in the language of the CERT Guide to Coordinated Vulnerability Disclosure) on the other end, each with competing expectations and priorities. In this blog post, we present a case study of how the CERT Coordination Center participates in the vulnerability-coordination process.

Read the entire post.

8. 8 Steps for Migrating Existing Applications to Microservices

by Brent Frye

A 2018 survey found that 63 percent of enterprises were adopting microservice architectures. This widespread adoption is driven by the promise of improvements in resilience, scalability, time to market, and maintenance, among other reasons. In this blog post, I describe a plan for how organizations that wish to migrate existing applications to microservices can do so safely and effectively.

Read the entire post.

7. Comments on NIST IR 8269: A Taxonomy and Terminology of Adversarial Machine Learning

by Jonathan Spring

The U.S. National Institute of Standards and Technology (NIST) recently held a public-comment period on their draft report on proposed taxonomy and terminology of adversarial machine learning (AML). AML sits at the intersection of many specialties of the SEI. Resilient engineering of machine learning (ML) systems requires good data science, good software engineering, and good cybersecurity. Our colleagues have suggested 11 foundational practices of AI engineering. In applications of ML to cybersecurity, we have suggested seven questions decision makers should ask. A solid understanding of AML is a key element for decision makers in both situations. NIST IR 8269 is an important effort to improve that understanding and build a community around it that includes academic ML as well as other areas of academia, government, and industry. To support that broad community building, my colleagues April Galyardt, Nathan VanHoudnos, and I collaborated to provide feedback to NIST. The remainder of this post contains those comments, reformatted to better fit your screen.

Read the entire post.

6. Beyond NIST SP 800-171: 20 Additional Practices in CMMC

by Andrew Hoover

In November 2020, defense contractors will be required to meet new security practices outlined in the Cybersecurity Maturity Model Certification (CMMC). As this post details, while the primary source of security practices in the CMMC is NIST Special Publication 800-171, the CMMC also includes 20 additional practices beyond 800-171 at levels 1-3. These 20 practices are intended to make DoD contractors more security conscious. In this post, we take a deeper dive into the 20 practices that go beyond NIST SP 800-171.

Read the entire post.

5. COVID-19 and Supply-Chain Risk

by Nathaniel Richmond

Managing supply-chain risks from the new coronavirus outbreak is personally important to me. While my first concern--like everyone else's--is mitigating the direct public-health risk of the COVID-19 pandemic, I have a salient concern about the health-related risks that could be introduced if the global manufacturing supply chain for medical devices is disrupted: I'm a Type I diabetic who relies on a continuous glucose monitor (CGM) device to monitor my blood sugar and an insulin pump for insulin injections. In this blog post, I explore risk-management strategies that vendors can use to prepare and account for disruptions to hardware and software supply chains--disruptions that could affect devices that end users rely on.

Read the entire post.

4. Snake Ransomware Analysis Updates

by Kyle O'Meara

In January 2020, Sentinel Labs published two reports on Snake (also known as Ekans) ransomware. The Snake ransomware gained attention due to its ability to terminate specific industrial control system (ICS) processes. After reading the reports, I wanted to expand the corpus of knowledge and provide OT and IT network defenders with increased defense capabilities against Snake. The key takeaways from the Sentinel Labs' reports for additional analysis were the hash of the ransomware and the string decoder script from sysopfb. Two questions I pursued, which I discuss in this post, were

• Can I find more samples of the Snake ransomware?
• If yes, do these samples use the same string-decoding process?

Read the entire post.

3. Three Risks in Building Machine Learning Systems

by Benjamin Cohen

Machine learning (ML) systems promise disruptive capabilities in multiple industries. Building ML systems can be complicated and challenging, however, especially since best practices in the nascent field of engineering AI systems are still coalescing. Consequently, a surprising fraction of ML projects fail or underwhelm. Behind the hype, there are three essential risks to analyze when building an ML system: (1) poor problem-solution alignment, (2) excessive time or monetary cost, and (3) unexpected behavior once deployed. In this post, I'll discuss each risk and provide a way of thinking about risk analysis in ML systems.

Read the entire post.

2. An Introduction to the Cybersecurity Maturity Model Certification (CMMC)

by Katie Stewart

A recent study predicted that business losses due to cybercrime will exceed $5 trillion by 2024. The threat to the Defense Industrial Base (DIB)--the network of more than 300,000 businesses, organizations, and universities that research, engineer, develop, acquire, design, produce, deliver, sustain, and operate military weapons systems--is especially alarming due to current cyberwarfare activities by cybercriminals and state-sponsored actors. A cyberattack within the DIB supply chain could result in devastating losses of intellectual property and controlled unclassified information (CUI). To bolster cybersecurity posture within the DIB supply chain, SEI researchers have spent the last year helping the federal government develop the Cybersecurity Maturity Model Certification (CMMC). This post details the development of the model and its role in securing the DIB.

Read the entire post.

1. Programmer Moneyball: Challenging the Myth of Individual Programmer Productivity

by Bill Nichols

A pervasive belief in the field of software engineering is that some programmers are much, much better than others (the times-10, or x10, programmer), and that the skills, abilities, and talents of these programmers exert an outsized influence on that organization's success or failure. In the field of baseball research (sabermetrics), researchers who challenged widely held--but erroneous--notions were able to exploit market inefficiencies to their advantage, a development vividly described in Moneyball by Michael Lewis. Similarly, astute software managers can benefit by challenging commonly accepted wisdom. In this blog post, I examine the veracity and relevance of the widely held notion of the x10 programmer. Using data from a study we conducted at the SEI, I found evidence that challenges the idea that some programmers are inherently far more skilled or productive than others.

Read the entire post.

Looking Ahead in 2020

In the coming months, look for posts highlighting our work in model-based systems engineering, metrics for DevSecOps, and building a cybersecurity strategy. We publish a new post on the SEI Blog every Monday morning and appreciate your comments and feedback on these posts.