This is the second 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. This post, which can be read in its entirety on the SPRUCE website, will present the first four of seven best practices for acquiring intellectual property.
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.
This post was also co-authored by Carol Woody.
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.
This post was also co-authored by Julia Allen.
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 is the third installment in a series of three blog posts highlighting seven recommended practices for monitoring software-intensive system acquisition (SISA) programs. 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 two posts in the series explored the challenges to monitoring SISA programs and presented the first five recommended best practices:
- Address in contracts
- Set up a dashboard
- Assign and train staff in its interpretation
- Update regularly
- Discuss in program reviews and as needed
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.