SEI Insights

SEI Blog

The Latest Research in Software Engineering and Cybersecurity

Writing secure C++ code is hard. C++11 and C++14 have added new facilities that change the way programmers write C++ code with the introduction of features like lambdas and concurrency. Few resources exist, however, describing how these new facilities also increase the number of ways in which security vulnerabilities can be introduced into a program or how to avoid using these facilities insecurely. Previous secure coding efforts, including the SEI CERT C Coding Standard and SEI CERT Oracle Coding Standard for Java , have proved successful in helping programmers identify possible insecure code in C and Java but do not provide sufficient information to cover C++. Other efforts, such as MISRA C++:2008 and the community-led C++ Core Guidelines, create a subset of the C++ language and do not focus on security. This blog post introduces the SEI CERT C++ Coding Standard and explores some examples of areas in C++ that can result in security vulnerabilities.

By the close of 2016, "Annual global IP traffic will pass the zettabyte ([ZB]; 1000 exabytes [EB]) threshold and will reach 2.3 ZBs per year by 2020" according to Cisco's Visual Networking Index. The report further states that in the same time frame smartphone traffic will exceed PC traffic. While capturing and evaluating network traffic enables defenders of large-scale organizational networks to generate security alerts and identify intrusions, operators of networks with even comparatively modest size struggle with building a full, comprehensive view of network activity. To make wise security decisions, operators need to understand the mission activity on their network and the threats to that activity (referred to as network situational awareness). This blog post examines two different approaches for analyzing network security using and going beyond network flow data to gain situational awareness to improve security.

A 2016 study on cybersecurity and digital trust found that 69 percent of organizations surveyed experienced an attempted or successful theft or corruption of data by insiders in the last 12 months. Despite the impact of insider threat--and continued mandates that government agencies and their contractors put insider threat programs in place--a number of organizations still have not implemented them. Moreover, the programs that have been implemented often have serious deficiencies. One impediment to organizations establishing an insider threat program is the lack of a clear business case for implementing available countermeasures.

As part of an ongoing effort to keep you informed about our latest work, this blog posting summarizes some recently published SEI technical reports, white papers, and webinars in early lifecycle cost estimation, data science, host protection strategies, blacklists, the Architectural Analysis and Design Language (AADL), architecture fault modeling and analysis, and programming and verifying distributed mixed-synchrony and mixed-critical software. These publications highlight the latest work of SEI technologists in these areas. This post includes a listing of each publication, author(s), and links where they can be accessed on the SEI website.

Software engineers increasingly recognize technical debt as a problem they care about, but they lack methods and tools to help them strategically plan, track, and pay down debt. The concept provides a vocabulary to engage researchers from a practice point of view, but they often lack an empirical basis and data science on which to validate their work on technical debt. Our recent Dagstuhl Seminar on Managing Technical Debt in Software Engineering provided a venue for assessing how far the study of technical debt has come and envisioning where we need to go to further the science and practice of managing technical debt in the software life cycle.

The (ISC)2 Global Information Security Workforce Study (GISWS) forecasts a shortfall of 1.5 million cybersecurity professionals by 2020. Government sources also project critical shortages of cybersecurity professionals. This predicted shortfall is troubling because the growing number and sophistication of cyber attacks threatens our infrastructure, which is increasingly software dependent. This blog post--derived from the paper Meeting Industry Needs for Secure Software Development, which I coauthored with Girish Seshagiri and Julie Howar--describes a collaboration involving industry, government, and academia to address this shortfall by developing a two-year degree program at a community college in secure software development.

Edward J. Schwartz, a research scientist on the vulnerability analysis team, co-authored this post.

Software engineers face a universal problem when developing software: weighing the benefit of an approach that is expedient in the short-term, but which can lead to complexity and cost over the long term. In software-intensive systems, these tradeoffs can create technical debt, which is a design or implementation construct that is expedient in the short term, but which sets up a technical context that can make future changes more costly or even impossible.

This post is co-authored by Will Hayes and Eileen Wrubel.

On July 14, 2016, the House Ways and Means Subcommittee on Social Security convened a hearing on the Social Security Administration's (SSA) information technology modernization plan. The hearing focused on the current state of the Social Security Administration's (SSA) Information Technology (IT) modernization plan and best practices for IT modernization, including oversight of agile software development. Agile development approaches, relatively new in government settings, create opportunities for rapid deployment of new capabilities but also pose challenges to traditional government oversight and management practices. A team of researchers from the SEI's Agile in Government (AIG) team were part of an expert panel brought in to testify before the members of the subcommittee. The team, comprised of me, AIG principal engineer Will Hayes, and AIG program manager Eileen Wrubel, developed written testimony that was submitted to the committee in conjunction with verbal testimony delivered by Hayes. This blog post, the first in a series, presents the written testimony as submitted to Congress, drawing upon seven years of research the SEI has conducted on the use of Agile in government settings. Specifically, this post provides a summary of challenges observed by the SEI in overseeing Agile programs in governmentsuch as progress measurements, IT transformations beyond Agile, and workforce development of government staff working in Agile settings.