As we have done each year since the blog's inception in 2011, this blog post presents the10 most-visited posts in 2016 in descending order ending with the most popular post. While the majority of our most popular posts were published in the last 12 months, a few, such as Don Firesmith's 2013 posts about software testing, continue to be popular with readers.
Software with timers and clocks (STACs) exchange clock values to set timers and perform computation. STACs are key elements of safety-critical systems that make up the infrastructure of our daily lives. They are particularly used to control systems that interact (and must be synchronized) with the physical world. Examples include avionics systems, medical devices, cars, cell phones, and other devices that rely on software not only to produce the right output, but also to produce it at the correct time. An airbag, for example, must deploy as intended, but just as importantly, it must deploy at the right time. Thus, when STACs fail to operate as intended in the safety-critical systems that rely on them, the result can be significant harm or loss of life. Within the Department of Defense (DoD), STACs are used widely, ranging from real-time thread schedulers to controllers for missiles, fighter planes, and aircraft carriers. This blog post presents exploratory research to formally verify safety properties of sequential and concurrent STACs at the source-code level.
The growth and change in the field of robotics in the last 15 years is tremendous, due in large part to improvements in sensors and computational power. These sensors give robots an awareness of their environment, including various conditions such as light, touch, navigation, location, distance, proximity, sound, temperature, and humidity. The increasing ability of robots to sense their environments makes them an invaluable resource in a growing number of situations, from underwater explorations to hospital and airport assistants to space walks. One challenge, however, is that uncertainty persists among users about what the robot senses; what it predicts about its state and the states of other objects and people in the environment; and what it believes its outcomes will be from the actions it takes. In this blog post, I describe research that aims to help robots explain their behaviors in plain English and offer greater insights into their decision making.
DDoS attacks can be extremely disruptive, and they are on the rise. The Verisign Distributed Denial of Service Trends Report states that DDoS attack activity increased 85 percent in each of the last two years with 32 percent of those attacks in the fourth quarter of 2015 targeting IT services, cloud computing, and software-as-a-service companies. In this blog post, I provide an overview of DDoS attacks and best practices for mitigating and responding to them based on cumulative experience in this field.
Cyber threat modeling, the creation of an abstraction of a system to identify possible threats, is a required activity for DoD acquisition. Identifying potential threats to a system, cyber or otherwise, is increasingly important in today's environment. The number of information security incidents reported by federal agencies to the U.S. Computer Emergency Readiness Team (US-CERT) has increased by 1,121 percent from 5,503 in fiscal year 2006 to 67,168 in fiscal year 2014, according to a 2015 Government Accountability Office report. Yet, our experience has been that it is often conducted informally with few standards. Consequently, important threat scenarios are often overlooked.
Given the dynamic cyber threat environment in which DoD systems operate, we have embarked on research work aimed at making cyber threat modeling more rigorous, routine, and automated. This blog post evaluates three popular methods of cyber threat modeling and discusses how this evaluation will help develop a model that fuses the best qualities of each.
Over the past six months, we have developed new security-focused modeling tools that capture vulnerabilities and their propagation paths in an architecture. Recent reports (such as the remote attack surface analysis of automotive systems) show that security is no longer only a matter of code and is tightly related to the software architecture. These new tools are our contribution toward improving system and software analysis. We hope they will move forward other work on security modeling and analysis and be useful to security researchers and analysts. This post explains the motivation of our work, the available tools, and how to use them.
The exponential increase in cybercrime is a perfect example of how rapidly change is happening in cyberspace and why operational security is a critical need. In the 1990s, computer crime was usually nothing more than simple trespass. Twenty-five years later, computer crime has become a vast criminal enterprise with profits estimated at $1 trillion annually. One of the primary contributors to this astonishing success is the vulnerability of software to exploitation through defects. How pervasive is the problem of vulnerability? The average cost of a data breach is $4 million, up 29 percent since 2013, according to Ponemon Institute and IBM data. Ponemon also concluded that there's a 26-percent probability that an enterprise will be hit by one or more data breaches of 10,000 records over the next 2 years. Increased system complexity, pervasive interconnectivity, and widely distributed access have increased the challenges for building and acquiring operationally secure capabilities. This blog post introduces a set of seven principles that address the challenges of acquiring, building, deploying, and sustaining software systems to achieve a desired level of confidence for software assurance.
As part of an ongoing effort to keep you informed about our latest work, this blog post summarizes some recently published SEI technical reports, white papers, and webinars in resilience, effective cyber workforce development, secure coding, data science, insider threat, and scheduling. 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.
In 2011, the U.S. Government maintained a fleet of approximately 8,000 unmanned aerial systems (UAS), commonly referred to as "drones," a number that continues to grow. "No weapon system has had a more profound impact on the United States' ability to provide persistence on the battlefield than the UAVs," according to a report from the 2012 Defense Science Board. Making sure government and privately owned drones share international air space safely and effectively is a top priority for government officials. Distributed Adaptive Real-Time (DART) systems are key to many areas of Department of Defense (DoD) capability, including the safe execution of autonomous, multi-UAS missions having civilian benefits. DART systems promise to revolutionize several such areas of mutual civilian-DoD interest, such as robotics, transportation, energy, and health care. To fully realize the potential of DART systems, however, the software controlling them must be engineered for high-assurance and certified to operate safely and effectively. In short, these systems must satisfy guaranteed and highly-critical safety requirements (e.g., collision avoidance) while adapting smartly to achieve application requirements, such as protection coverage, while operating in dynamic and uncertain environments. This blog post describes our architecture and approach to engineering high-assurance software for DART systems.
Network flow plays a vital role in the future of network security and analysis. With more devices connecting to the Internet, networks are larger and faster than ever before. Therefore, capturing and analyzing packet capture data (pcap) on a large network is often prohibitively expensive. Cisco developed NetFlow 20 years ago to reduce the amount of information collected from a communication by aggregating packets with the same IP addresses, transport ports, and protocol (also known as the 5-tuple) into a compact record. This blog post explains why NetFlow is still important in an age in which the common wisdom is that more data is always better. Moreover, NetFlow will become even more important in the next few years as communications become more opaque with the development of new protocols that encrypt payloads by default.
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.
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.
There are several risks specific to big data system development. Software architects developing any system--big data or otherwise--must address risks associated with cost, schedule, and quality. All of these risks are amplified in the context of big data. Architecting big data systems is challenging because the technology landscape is new and rapidly changing, and the quality attribute challenges, particularly for performance, are substantial. Some software architects manage these risks with architecture analysis, while others use prototyping. This blog post, which was largely derived from a paper I co-authored with Hong-Mei Chen and Serge Haziyev, Strategic Prototyping for Developing Big Data Systems, presents the Risk-Based Architecture-Centric Strategic Prototyping (RASP) model, which was developed to provide cost-effective systematic risk management in agile big data system development.
Safety-critical software must be analyzed and checked carefully. Each potential error, failure, or defect must be considered and evaluated before you release a new product. For example, if you are producing a quadcopter drone, you would like to know the probability of engine failure to evaluate the system's reliability. Safety analysis is hard. Standards such as ARP4761 mandate several analyses, such as Functional Hazard Assessment (FHA) and Failure Mode and Effect Analysis (FMEA). One popular type of safety analysis is Fault Tree Analysis (FTA), which provides a graphical representation of all contributors to a failure (e.g., error events and propagations). In this blog post, I present the concepts of the FTA and introduce a new tool to design and analyze fault trees.
To deliver enhanced, integrated warfighting capability at lower cost, the DoD must move away from stove-piped solutions and embrace open systems architecture (OSA) approaches that integrate business and technical practices to create systems with interoperable and reusable components. In November, the SEI launched a series of blog posts that highlight the perspectives of DoD stakeholders--including contractor and government employees--on OSA-based approaches and how they can best be integrated in DoD software (and hardware) development. The first post in this series highlighted our discussion with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems. This post highlights a discussion with Nickolas H. Guertin, in the Office of the Deputy Assistant Secretary of the Navy for Research, Development, Test, and Evaluation.
Guertin has a long history with open systems, both for U.S. Navy OSA initiatives and broader DoD initiatives. Based on his experiences over the past several decades, he discussed with the SEI how OSA offers developers the ability to create more resilient and adaptable systems. He noted that Under Secretary of Defense for Acquisition, Technology and Logistics Frank Kendall, in his Better Buying Power 3.0, highlights how the acquisition community can address that demand signal. Together, they have established that we are behind in technology innovation and need to use OSA as a method to bridge that divide. This new direction is helping the DoD introduce new technologies more quickly and less expensively to the warfighter. Throughout this post, we will present excerpts from our conversation (Editor's note: These excerpts have been edited to improve readability).
The crop of Top 10 SEI blog posts published in the first half of 2016 (judged by the number of visits by our readers) represents a cross section of the type of cutting-edge work that we do at the SEI: at-risk emerging technologies, cyber intelligence, big data, vehicle cybersecurity, and what ant colonies can teach us about securing the internet. In all, readers visited the SEI blog more than 52,000 times for the first six months of 2016. We appreciate your readership and invite you to submit ideas for future posts in the comments section below. In this post, we will list the Top 10 posts in descending order (#10 to #1) and then provide an excerpt from each post, as well as links to where readers can go for more information about the topics covered in the SEI blog.
What is technical debt? Why identify technical debt? Shouldn't it be captured as defects and bugs? Concretely communicating technical debt and its consequences is of interest to both researchers and software engineers. Without validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices, most commonly using issue trackers or backlog-management practices to capture and track technical debt. We examined 1,264 issues from four issue trackers used in open-source industry and government projects and identified 109 examples of technical debt. Our study, documented in the paper Got Technical Debt? Surfacing Elusive Technical Debt in Issue Trackers, revealed that technical debt has entered the vernacular of developers as they discuss development tasks through issue trackers. Even when developers did not explicitly label issues as technical debt, it was possible to identify technical debt items in these issue trackers using a classification method we developed. We use our results to motivate an improved definition of technical debt and an approach to explicitly report it in issue trackers. In this blog post, we describe our classification method and some implications of tracking debt for both practice and research.
This blog post was co-authored by Nancy Mead, SEI Fellow.
To ensure software will function as intended and is free of vulnerabilities (aka software assurance), software engineers must consider security early in the lifecycle, when the system is being designed and architected. Recent research on vulnerabilities supports this claim: Nearly half the weaknesses identified in the Common Weakness Enumeration (CWE) repository have been identified as design weaknesses. These weaknesses are introduced early in the lifecycle and cannot be patched away in later phases. They result from poor (or incomplete) security requirements, system designs, and architecture choices for which security has not been given appropriate priority. Effective use of metrics and methods that apply systematic consideration for security risk can highlight gaps earlier in the lifecycle before the impact is felt and when the cost of addressing these gaps is less. This blog post explores the connection between measurement, methods for software assurance, and security. Specifically, we focus on three early lifecycle methods that have shown promise: the Software Assurance Framework (SAF), Security Quality Requirements Engineering (SQUARE) Methodology, and Security Engineering Risk Analysis (SERA) Framework.
The mix of program-scale Agile and technical baseline ownership drives cheaper, better, and faster deployment of software-intensive systems. Although these practices aren't new, the SEI has seen how their combination can have dramatic effects. The Air Force Distributed Common Ground System (AF DCGS)--the Air Force's primary weapon system for intelligence, surveillance, reconnaissance, planning, direction, collection, processing, exploitation, analysis, and dissemination--employs a global communications architecture that connects multiple intelligence platforms and sensors. The AF DCGS challenge is to bring new sensors and processing applications online quickly and efficiently. Other large government software-intensive systems face similar challenges. The SEI has found that Agile cultural transformation--along with strong technical baseline ownership--is critical for programs like DCGS to deliver new capability faster and with greater confidence. These strategies working together can help create incremental and iterative approaches to deliver more frequent and more manageable technical capability. In this blog, I present the SEI's experiences in helping large Department of Defense (DoD) programs, such as AF DCGS, use concepts like owning the technical baseline and Agile software development techniques to deliver new capability on a regular basis.
In 2015, the National Vulnerability Database (NVD) recorded 6,488 new software vulnerabilities, and the NVD documents a total of 74,885 software vulnerabilities discovered between 1988-2016. Static analysis tools examine code for flaws, including those that could lead to software security vulnerabilities, and produce diagnostic messages ("alerts") indicating the location of the purported flaw in the source code, the nature of the flaw, and often additional contextual information. A human auditor then evaluates the validity of the purported code flaws. The effort required to manually audit all alerts and repair all confirmed code flaws is often too much for a project's budget and schedule. Auditors therefore need tools that allow them to triage alerts, strategically prioritizing the alerts for examination. This blog post describes research we are conducting that uses classification models to help analysts and coders prioritize which alerts to address.
As part of an ongoing effort to keep you informed about our latest work, I would like to let you know about some recently published SEI technical reports, white papers, webinars, and podcasts. These publications highlight the latest work of SEI technologists in military situational analysis, software architecture, insider threat, honeynets, and threat modeling. This post includes a listing of each publication, author(s), and links where they can be accessed on the SEI website.
Automobiles are often referred to as "computers on wheels" with newer models containing more than 100 million lines of code. All this code provides features such as forward collision warning systems and automatic emergency braking to keep drivers safe. This code offers other benefits such as traffic detection, smartphone integration, and enhanced navigation. These features also introduce an increased risk of compromise, as demonstrated by researchers Chris Valasek and Charlie Miller (who work for Uber's Advanced Technology Center in Pittsburgh) in a July 2015 story for Wired, where they hacked into a Jeep Cherokee with a zero-day exploit. The Jeep Hack, as it has come to be known, highlighted an underlying issue for all vehicles: when automobiles are built, manufacturers focus on a threat model of potential risks that rely on physical defects, but do not include vulnerabilities that make a vehicle susceptible to intrusion and remote compromise. This blog post highlights the first phase of our research on making connected vehicles more secure by testing devices that connect into the vehicle itself.
Recent research has demonstrated that in large scale software systems, bugs seldom exist in isolation. As detailed in a previous post in this series, bugs are often architecturally connected. These architectural connections are design flaws. Static analysis tools cannot find many of these flaws, so they are typically not addressed early in the software development lifecycle. Such flaws, if they are detected at all, are found after the software has been in use; at this point they are far more costly and time-consuming to address.
In our first post in this series, we presented a tool that supports a new architecture model that can identify structures in the design (based on an analysis of a project's code base) that have a high likelihood of containing bugs. Typically, investment in refactoring to remove such design flaws has been difficult for architects to justify or quantify to their managers. The costs of refactoring are immediate and up-front. The benefits have, in the past, been vague and long-term. And so managers typically refuse to invest in refactoring.
In this post, which was excerpted from a recently published paper that I coauthored with Yuanfang Cai, Ran Mo, Qiong Feng, Lu Xiao, Serge Haziyev, Volodymyr Fedak, and Andriy Shapochka, we present a case study of our approach with SoftServe Inc., a leading software outsourcing company. In this case study we show how we can represent architectural technical debt (hereinafter, architectural debt) concretely, in terms of its cost and schedule implications (issues of importance that are easily understood by project managers). In doing so, we can create business cases to justify refactoring to remove root causes of the architectural debt.
In today's increasingly interconnected world, the information security community must be prepared to address vulnerabilities that may arise from new technologies. Understanding trends in emerging technologies can help information security professionals, leaders of organizations, and others interested in information security identify areas for further study. Researchers in the SEI's CERT Division recently examined the security of a large swath of technology domains being developed in industry and maturing over the next five years. Our team of analysts--Dan Klinedinst, Todd Lewellen, Garret Wassermann, and I--focused on identifying domains that not only impacted cybersecurity, but finance, personal health, and safety, as well. This blog post highlights the findings of our report prepared for the Department of Homeland Security United States Computer Emergency Readiness Team (US-CERT) and provides a snapshot of our current understanding of future technologies.
Organizations and federal agencies seeking to adopt Agile often struggle because they do not understand the adoption risks involved when contemplating the use of Agile approaches. This ongoing series on Readiness and Fit Analysis (RFA) focuses on helping federal agencies, such as the Department of Defense, the Internal Revenue Service, the Food and Drug Administration, and other organizations in regulated settings, understand the risks involved when contemplating or embarking on a new approach to developing or acquiring software. This blog post, the seventh in a series, explores issues related to the technology environment that organizations should consider when adopting Agile approaches.
Much of the malware that we analyze includes some type of remote access capability. Malware analysts broadly refer to this type of malware as a remote access tool (RAT). RAT-like capabilities are possessed by many well-known malware families, such as DarkComet. As described in this series of posts, CERT researchers are exploring ways to automate common malware analysis activities. In a previous post, I discussed the Pharos Binary Analysis Framework and tools to support reverse engineering object-oriented code. In this post, I will explain how to statically characterize program behavior using application programming interface (API) calls and then discuss how we automated this reasoning with a malware analysis tool that we call ApiAnalyzer.
This is the third installment in a series of three blog posts highlighting seven recommended practices for acquiring intellectual property. This content was originally published on the Cyber Security & Information Analysis Center's website online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment. The first post in the series explored the challenges to acquiring intellectual property. The second post in the series presented the first four of seven practices for acquiring intellectual property. This post will present the final three of seven practices for acquiring intellectual property as well as conditions under which organizations will derive the most benefit from recommended practices for acquiring intellectual property.
When I was a chief architect working in industry, I was repeatedly asked the same questions: What makes an architect successful? What skills does a developer need to become a successful architect? There are no easy answers to these questions. For example, in my experience, architects are most successful when their skills and capabilities match a project's specific needs. Too often, in answering the question of what skills make a successful architect, the focus is on skills such as communication and leadership. While these are important, an architect must have strong technical skills to design, model, and analyze the architecture. As this post will explain, as a software system moves through its lifecycle, each phase calls for the architect to use a different mix of skills. This post also identifies three failure patterns that I have observed working with industry and government software projects.
Software and acquisition professionals often have questions about recommended practices related to modern software development methods, techniques, and tools, such as how to apply Agile methods in government acquisition frameworks, systematic verification and validation of safety-critical systems, and operational risk management. In the Department of Defense (DoD), these techniques are just a few of the options available to face the myriad challenges in producing large, secure software-reliant systems on schedule and within budget.
Increasingly, software development organizations are finding that a large number of their vulnerabilities stem from design weaknesses and not coding vulnerabilities. Recent statistics indicate that research should focus on identifying design weaknesses to alleviate software bug volume. In 2011, for example when MITRE released its list of the 25 most dangerous software errors, approximately 75 percent of those errors represented design weaknesses. Viewed through another lens, more than one third of the current 940 known common weakness enumerations (CWEs) are design weaknesses. Static analysis tools cannot find these weaknesses, so they are currently not addressed prior to implementation and typically are detected after the software has been executed when vulnerabilities are much more costly and time-consuming to address. In this blog post, the first in a series, we present a tool that supports a new architecture model that can identify structures in the design and code base that have a high likelihood of containing bugs, hidden dependencies in code bases, and structural design flaws.
Most organizations, no matter the size or operational environment (government or industry), employ a senior leader responsible for information security and cybersecurity. In many organizations, this role is known as chief information security officer (CISO) or director of information security. CISOs and others in this position increasingly find that traditional information security strategies and functions are no longer adequate when dealing with today's expanding and dynamic cyber-risk environment. Publications abound with opinions and research expressing a wide range of functions that a CISO organization should govern, manage, and perform. Making sense of all this and deciding on an approach that is appropriate for your specific organization's business, mission, and objectives can prove challenging. In this blog post, we present recent research on this topic, including a CISO framework for a large, diverse, U.S. national organization. This framework is the product of interviews with CISOs and an examination of policies, frameworks, maturity models, standards, codes of practice, and lessons learned from cybersecurity incidents.
In June, representatives of organizations in the government, military, and industry sectors--including American Express and PNC--traveled to Pittsburgh to participate in a crisis simulation the SEI conducted. The crisis simulation--a collaborative effort involving experts from the SEI's Emerging Technology Center (ETC) and CERT Division--involved a scenario that asked members to sift through and identify Internet Protocol (IP) locations of different servers, as well as netflow data. Participants also sorted through social media accounts from simulated intelligence agencies, as well as fabricated phone logs and human intelligence. Our aim with this exercise was to help cyber intelligence analysts from various agencies learn to think critically about the information they were digesting and make decisions that will protect their organizations in the event of a cyber attack or incident and increase resilience against future incidents. This blog post, the second in a series highlighting cyber intelligence work from the ETC, highlights the importance of critical thinking in cyber intelligence, as well as a three-step approach to taking a more holistic view of cyber threats.
A recent IDC forecast predicts that the big data technology and services market will realize "a 26.4 percent compound annual growth rate to $41.5 billion through 2018, or about six times the growth rate of the overall information technology market." In previous posts highlighting the SEI's research in big data, we explored some of the challenges related to the rapidly growing field, which include the need to make technology selections early in the architecture design process. We introduced an approach to help the Department of Defense (DoD) and other enterprises develop and evolve systems to manage big data. The approach, known as Lightweight Evaluation and Architecture Prototyping for Big Data (LEAP4BD) helps organizations reduce risk and streamline selection and acquisition of big data technologies. In this blog post, we describe how we used LEAP4BD to help the Interagency Project Office achieve their mission to integrate the IT systems of the Military Health System and the Veterans Health Administration.
As our world becomes increasingly software-reliant, reports of security issues in the interconnected devices that we use throughout our day (i.e., the Internet of Things) are also increasing. This blog post discusses how to capture security requirements in architecture models, use them to build secure systems, and reduce potential security defects. This post also provides an overview of our ongoing research agenda on using architecture models for the design, analysis, and implementation of secure cyber-physical systems and to specify, validate, and implement secure systems.
This post, which can be read in its entirety on the SPRUCE website, will present the final two recommendations, as well as conditions that will allow organizations to derive the most benefit from these practices.
Today's computer systems often contain millions of lines of code and are constructed by integrating components, many of which are authored by various third parties. Application Programming Interfaces (APIs) are the glue that connects these software components. While the SEI and others have placed significant emphasis on developing secure coding practices, there has not been an equal emphasis placed on APIs. This blog post describes our recent research that aims to provide specific guidance to API designers to help them deal with the security issues regarding development of APIs.
In 2015, the SEI blog launched a redesigned platform to make browsing easier, and our content areas more accessible and easier to navigate. The SEI Blog audience also continued to grow with an ever-increasing number of visitors learning more about our research in technical debt, shift-left testing, graph analytics, DevOps, secure coding, and malware analysis. In 2015 (from January 1 through December 15), the SEI blog logged 159,604 visits and sessions (we also switched analytics platforms mid-year), a 26 percent increase in traffic from the previous year. This blog post highlights the top 10 posts published in 2015. As we did with our mid-year review, we will include links to additional related resources that readers might find of interest. We also will present the posts in descending order beginning with the 10th most popular post of 2015 and counting down to number one.
Awareness and adoption of DevOps continues to grow. A 2016 DevOps trends report found that DevOps adoption increased from 66 percent in 2015 to 74 percent in 2016 In 2016, visitors to the SEI DevOps Blog were drawn to posts...