The federal government is facing a shortage of cybersecurity professionals that puts our national security at risk, according to recent research. "As cyber attacks have increased and there is increased awareness of vulnerabilities, there is more demand for the professionals who can stop such attacks. But educating, recruiting, training and hiring these cybersecurity professionals takes time," the research states. Recognizing these realities, the U. S. Department of Homeland Security (DHS) National Cyber Security Division (NCSD) enlisted the resources of the to develop a curriculum for a Master of Software Assurance degree program and define transition strategies for implementing it. This blog post presents an overview of the Master of Software Assurance curriculum project, including its history, student prerequisites and outcomes, a core body of knowledge, and a curriculum architecture from which to create such a degree program.
Malicious attackers and penetration testers can use some of the same tools. Attackers use them to cause harm while penetration testers use them to bring value to organizations. In this blog post, I've partnered with colleagues Jason Frank and Will Schroeder from The Veris Group's Adaptive Threat Division to describe some of the common penetration testing tools and techniques that can greatly benefit network defenders. While this blog post cannot cover all the techniques and shortcuts we use in the field, we do describe a set of 10 tactics that provide very little network disruption, are easy to use, and freely available.
It's the holiday season, a traditionally busy time for many data centers as online shopping surges and many of the staff take vacations. When you see abnormal traffic patterns and overall volume starts to rise, what is the best way to determine the cause? People could be drawn to your business, and you will soon need to add surge capacity, or maybe you are in the beginnings of a denial-of-service attack and need to contact your service provider. This blog post highlights recent work by CERT researchers to help organizations gain cyber situational awareness, which is based on network flow, and provides a tool to gain invaluable insights into ways your network is being used. More importantly, it helps you decide how to respond to changes in the online environment.
At an open architecture summit in November 2014, Katrina G. McFarland, assistant secretary of defense for acquisition said that 75 percent of all Defense Department acquisition strategies implement open systems architecture across all services and agencies. "This department is seriously engaged in trying to understand how to help our program managers and our department and our industry look at open architecture and its benefits," McFarland said, "and understand truly what our objectives are related to intellectual property and making sure that we're doing it based on the best interest of national security relative to a business case." Open systems architecture (OSA) integrates business and technical practices to create systems with interoperable and reusable components. OSA offers outstanding potential for creating resilient and adaptable systems and is therefore a priority for the DoD. The challenges with OSA, however, make it one of the most ambitious endeavors in software architecture today. A group of researchers at the SEI recently held an informal roundtable with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems, to discuss OSA-based approaches and how best to help the DoD achieve them. This blog post presents highlights of the discussion with Sharp on OSA approaches and how they can best be integrated in DoD system development.
Many systems and platforms, from unmanned aerial vehicles to minivans and smartphones, are realizing the promise of Open Systems Architecture (OSA). A core tenet of OSA is the broad availability of standards and designs, the sharing of information between developers, and in some cases downloadable tool kits. In return for openness, a broader community of potential developers and applications emerges, which in turn increases adoption and use. Consequently, there is a trade-off. Openness is a two way street, allowing devious opportunities for cyber intrusion and attack and less-than-ideal code to enter the system (because of the mechanisms of OSA). This blog post briefly examines the potentials, good and bad, of OSA and reviews four best practices for open source ecosystems.
According to the National Institute of Standards and Technology (NIST), Information Security Continuous Monitoring (ISCM) is a process for continuously analyzing, reporting, and responding to risks to operational resilience (in an automated manner, whenever possible). Compared to the traditional method of collecting and assessing risks at longer intervals--for instance, monthly or annually--ISCM promises to provide near-real-time situational awareness of an organization's risk profile. ISCM creates challenges as well as benefits, however, because the velocity of information gathered using ISCM is drastically increased. Development, operation, and maintenance processes built for a more leisurely pace can thus be overwhelmed. This blog post explores how organizations can leverage Agile methods to keep pace with the increased velocity of ISCM risk information, while ensuring that changes to systems are conducted in a controlled manner.
In my preceding blog posts, I promised to provide more examples highlighting the importance of software sustainment in the U.S. Department of Defense (DoD). My focus is on sustaining legacy weapons systems that are no longer in production, but are expected to remain a key component of our defense capability for decades to come. Despite the fact that these legacy systems are no longer in the acquisition phase, software upgrade cycles are needed to refresh their capabilities every 18 to 24 months. In addition, significant modernization can often be made by more extensive, focused software upgrades with relatively modest hardware changes. This third blog post describes effective sustainment engineering efforts in the Army, using examples from across its software engineering centers. These examples are tied to SEI research on capability maturity models, agility, and the Architecture Analysis and Design Language (AADL) modeling notation.
This is the first post in a three-part series.
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.
In an effort to offer our assessment of recommended techniques in these areas, SEI built researchers built upon an existing collaborative online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment), hosted on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. From June 2013 to June 2014, the SEI assembled guidance on a variety of topics based on relevance, maturity of the practices described, and the timeliness with respect to current events. For example, shortly after the Target security breach of late 2013, we selected Managing Operational Resilience as a topic.
Ultimately, SEI curated recommended practices on five software topics: Agile at Scale, Safety-Critical Systems, Monitoring Software-Intensive System Acquisition Programs, Managing Intellectual Property in the Acquisition of Software-Intensive Systems, and Managing Operational Resilience. In addition to a recently published paper on SEI efforts and individual posts on the SPRUCE site, these recommended practices will be published in a series of posts on the SEI blog. This post, the first in a three-part series by Robert Ferguson, first explores the challenges to Monitoring Software-Intensive System Acquisition (SISA) programs and presents the first two recommended best practices as detailed in the SPRUCE post. The second post in this series will present the next three best practices. The final post will present the final two recommendations as well as conditions that will allow organizations to derive the most benefit from these practices.