Securing the Ecosystem

Securing the Ecosystem

A Holistic Systems Engineering Approach

The recent devastating and destructive cyber-attacks on U.S. businesses, systems, and supply chains have once again demonstrated the need for a holistic, multidimensional protection strategy grounded in systems security engineering [1]. We can no longer attempt to protect our critical national assets—from cutting-edge research and development programs producing innovative technologies to defense, energy, healthcare, transportation, finance and other critical infrastructures—with siloed security solutions. We are fighting a 21st century war in contested cyberspace against formidable adversaries with 20th century strategies and tactics [2]. Today’s systems are too complex to fully understand and multi-tier supply chains lack the transparency to give consumers the trust they need—especially when the systems are at the heart of the critical missions and business operations in both the public and private sectors.

Bridges and Airplanes

No alt text provided for this image

The next time you cross a bridge or fly in an airplane, ask yourself, why do I trust those things? If you are like me, I trust bridges and airplanes for the same reasons. I trust the bridges and airplanes I use routinely during my travels are well-designed, well-built, and well-maintained—that is, they are developed and maintained by a group of skilled individuals using sound systems engineering practices and quality materials. My trust is bolstered because safety is a top priority in the construction of bridges and airplanes. In fact, if we view an airplane as a system, airworthiness, or the measure of an aircraft's suitability for safe flight, is a primary design objective. Similarly, bridges must be designed to carry different kinds of loads, including cars, trains, and people. Structural engineers consider all possible factors related to the bridge’s superstructure and substructure, such as static and dynamic loads, tension and compression, and resonance (vibrations). It’s physics, mathematics, and engineering—so, when I cross a bridge or fly in an airplane, I don’t give it a second thought. I have an expectation the bridge and airplane builders have exercised due diligence throughout the system development process. I do have to admit, however, that my risk management DNA does cause an occasional negative thought. I am aware that on rare occasions, bridges do collapse, and planes do crash—but the operative word in this situation is “rare” and the overarching risk of using these transportation systems is very, very low. When failures do occur, science and engineering principles, concepts, and practices facilitate the conduct of the investigation including forensic and other types of analyses. We figure out what went wrong, we fix the problem, and we move on.

The Foundation for Achieving Trust

Given the data points for bridges and airplanes, how can we achieve that same level of trust in computing systems that include hundreds of thousands of hardware, software, and firmware components and ubiquitous network connectivity with other systems around the world? The answer may require a different mindset and a change in focus from the traditional ways in which we deal with system security issues. What if, instead of viewing system security as an isolated “niche” activity and something we do for risk management and compliance purposes, we focused on system reliability and system resilience with quality and trustworthiness as key metrics for success? Reliability and resilience, like safety, are system properties that can be achieved through systems engineering processes. The intended behaviors, interactions, and outcomes that a system should exhibit are key metrics that can be assured using various factors and verification processes including establishing control actions to keep a system within its design parameters [3].

Security is also a system property that can be achieved through the same systems engineering processes and can directly support system reliability and resilience. Reliability engineering and systems security engineering are sub-disciplines of systems engineering. Reliability and resilience can become the primary design objectives for all systems development efforts and can be tightly coupled to organizational missions and business needs. In essence, we can employ the security concepts and principles in the systems security engineering process described in Figure 1 below to help achieve system reliability and resilience. If systems are more secure and resilient, they will be more reliable—and if systems are more reliable, we can place more trust in them. This is especially true with the emergence of cyber-physical systems where reliability and resilience are paramount and the assurance and trust in the software and firmware driving those systems essential.

No alt text provided for this image

Figure 1:  Security Engineering Process: NIST Special Publication 800-160, Volume 1

Reliability and Resiliency

In 2016, the National Institute of Standards and Technology (NIST) published its first systems security engineering guidance to address the growing problem of complexity and the need to develop trustworthy, secure, and resilient systems [4]. Recognizing that systems engineering is the primary focal point for any system security engineering initiative, the NIST guidance started with a joint ISO/IEC/IEEE Systems and Software Engineering Standard [5] and subsequently developed security extensions for each of the system life cycle processes contained in the standard. The “security extensions” and flexible nature of the international standard provided a disciplined and structured approach for building security into systems and system components from day zero—not after the system is up, operational, and not protected, but starting at day zero [6]. The standard also provided an excellent foundation to address the myriad of system development life cycle engineering processes such as mission and business analysis, stakeholder needs, system requirements, system architecture, system design, integration, verification, validation, operations, maintenance, supply chain relationships, and risk management.

Taking a systems engineering approach and incorporating security concepts early and throughout the life cycle creates an opportunity to employ a multidimensional protection strategy that includes penetration-resistant architectures, damage-limiting operations, and designs to achieve system resiliency and survivability. This provides a true defense-in-depth strategy that attempts to: (1) stop system incursions, if possible; (2) detect the incursions when they happen; (3) limit the damage to systems if the incursions are successful; and (4) allow systems to continue to operate while the incursions are in progress, even in a degraded or debilitated state. The end result—higher quality and more trustworthy systems that are more reliable and resilient.

A Notional Framework for Securing the Ecosystem

Given the need to manage and reduce system complexity, develop quality systems that are more reliable and resilient, and provide greater levels of trust to consumers, how can we create a consistent and unifying framework for securing the ecosystem—an ecosystem that is driven by BizOps, DevOps, and supply chain communities of interest? One potential solution worth exploring is using a systems engineering model as the foundation for infusing security into each of these disparate yet related entities—and fostering a consistent “security view” that would facilitate communication among all entities in the ecosystem, produce higher quality and trustworthy systems and system components, and promote system reliability and resilience. Figure 2 illustrates such a conceptual framework.

No alt text provided for this image

                  Figure 2:  Conceptual Framework for Securing the Ecosystem

The overarching objective of the framework is to use systems security engineering processes to guide and inform security decisions and solutions across all elements of the ecosystem. Other supporting objectives of the framework include:

  • Applying system security engineering concepts to agile, BizOps, DevOps, and supply chain activities and processes  
  • Expanding DevSecOps software-focused development approaches to include systems and the integration of system components 
  • Incorporating security into product and system development, implementation, operations, and sustainment
  • Developing a holistic risk management approach for systems and organizations
  • Using BizOps to drive technology and security solutions for organizations
  • Implementing a multidimensional protection strategy to create reliable and resilient systems that are part of an ecosystem
  • Increasing system and component assurance by maximizing verification processes throughout the life cycle
  • Improving supply chain security by establishing and continuously updating the provenance of system components

Standards of Due Diligence for the Ecosystem

We have defined the needs of the ecosystem based on security, reliability, resiliency, quality, and trustworthiness. The other essential component to make it all work is accountability. In the world of bridges and airplanes, there are well-established and often strict safety standards that are applied when it comes to building those entities. Safety becomes a design objective for the bridge and airplane developers—and a “system property” achieved through the execution of a disciplined and structured engineering process. These standards may be viewed as requiring a certain level of “due diligence” when developing products, systems, or services for consumers, especially when system failures can cause adverse consequences such as severe injury or loss of life. Standards of due diligence are paramount to protect consumers, manage risk, enforce compliance, and establish liability when things go wrong. We have such standards in almost every mature profession and industry.

While the development of bridges and airplanes rely on sound engineering principles and concepts, they also have the luxury of extended planning cycles. The structures are typically planned well in advance with sufficient time to ensure everything goes right. The benefits of time are not the same for systems and software engineering because most systems support a business response to competitive pressures as described in Porter’s Five Forces Model. These forces drive businesses to rapidly deploy the systems on which their business operations depend. The rush to market can cause sound systems engineering processes to break down, and that is largely the situation we face today. In a highly competitive landscape, everyone is doing the same things that lead to the same weaknesses that produce the same problems. Perhaps establishing standards of due diligence in the development of systems to ensure the systems are reliable, resilient, and trustworthy is going to be the most valuable approach because it focuses more on “doing the right thing because it is the right thing to do. Over time, building this focus on systems security engineering practices into industry will solve many of the current challenges we face today in protecting our critical infrastructure.

Who’s Accountable When Things Go South?

We have been doing system security for over five decades and have come a long way. But to this day, our society has not established any consensus-based standards of due diligence for the development of secure systems. We do not routinely “engineer” our systems to address security as a fundamental systems property in the same manner we address safety when we build bridges and airplanes [7]. Moreover, there is no requirement to address security during the systems development process. Today, with a growing number of commercial information technology products being deployed into critical systems and high value assets, what is the acceptable standard of due diligence for developers of the technology? What are society’s expectations for securing the ecosystem? Can such a standard be crafted with any consensus addressing issues such as the effect on innovation, competitiveness of U.S. industry, and cost to consumers? Who is held accountable when disaster strikes and what are the liabilities for failure to exercise due diligence? These are legitimate concerns that must be balanced by the risk to consumers and society at large if standards are not established and enforced. It is also possible that different standards of due diligence might be needed to address technologies employed in the critical infrastructure and national security arena versus those technologies targeted for general consumer use. Stricter standards may be appropriate for those products and systems having greater potential adverse impacts on the economic and national security interests of the country. So until we get moving in the right direction, it might be time to hit the pause button and thoughtfully consider where the balance point ought to be. Caveat emptor may no longer be acceptable.

[1]  R. Ross, “The Adversaries Live in the Cracks

[2]  R. Ross, “Right Strategy, Wrong Century

[3]  M. Winstead, “Systems Security Engineering” presentation, January 27, 2021

[4]  R. Ross, M. McEvilley, J. Oren,  NIST Special Publication 800-160, Volume 1, “Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems”

[5]  ISO/IEC/IEEE 15288:2015, “Systems and software engineering — System life cycle processes”

[6]  R. Ross, “Rethinking Our View of System Security

[7]  R. Ross, “The Mysterious Disappearance of Systems Security Engineering

A special note of thanks to Greg Touhill, Mark Winstead, Malcolm Harkins, Keyaan Williams, Tony Cole, and Victoria Pillitteri, long-time SSE and cybersecurity colleagues, who graciously reviewed and provided sage advice for this article.

Great Article...I'm hearing echoes in the back of my head from the sage, Peter G Neumann. Are we finally waking up and now have the will? Thanks Ron for picking up the sword!

Samuel Visner

Tech Fellow at Aerospace Corporation; Chair, Board of Directors, Space ISAC; Board Member, ORAU

3 年

We need to extend systems engineering for cybersecurity to systems engineering for distributed, enterprise systems PLUS cybersecurity, handling both together.

回复
Dr. Tomás Pe?a

Tech Fellow at L3Harris Space & Airborne Systems | Lt Col, USAF (Ret) | CISSP * CSEP * GREM

3 年

Great discussion on Cyber Resiliency.? Engineering for cyber resiliency is much more complicated than physical bridges and airplanes since associated parties are generally motivated to keep them functioning.? Continuing the analogy, imagine a lot people with easy access to explosives, million dollar rewards, and a multitude of ways to avoid accountability then add in governmental jurisdiction and policy issues and we would have less confidence driving and flying.? Achieving cyber resiliency facing active cyber adversaries requires a whole new level of engineering flexibility and adversarial testing never before seen.? NIST SP 800-160 Volume 2 wasn't specifically referenced in the article, but of course also has a great discussion.? #mcpa?Military Cyber Professionals Association

Patrick Simon

President and Manager at Beehive Technology Solutions LLC Service-Disabled Veteran Owned Business (SDVOB) Federal and State Small Certified Business; Microsoft Partner Risk Digital Services

3 年

MITRE published Deliver Uncompromised:?Securing Critical Software Supply Chain here on LinkedIn and clarifies that "harmonization" and "updating" are missing to NIST 800-53 Rev 5. NIST Publication 800-161 Supply Chain Risk MGT Practices uses the term "Enterprise Architecture" 70 (seventy times) throughout the pub and makes it very "systems clear" that systems are "tightly coupled" to enterprise architecture as part of systems engineering.?The word "ecosystem" is only used 4 (four) times to (ICT).?The first artifact you look at in DODAF is an OV1, TOGAF, Zachman, all the same.?If you are a federal agency, FEA ver 2 maps you to the "Consolidated Framework," and all of these are enterprise architecture approaches, not "ecosystem" processes.?Enterprise Architecture (Step "0") NIST 800-53 Rev 5 and NIST 600-37 RMF 2.0 to ISO/IEC/IEEE Systems Engineering to Cyber-Physical Systems Engineering to decompose to achieve cyber risk sigma. If we are really serious about protecting America's critical infrastructure, let us use common vocabulary, standards, and frameworks, current consolidated/digitally converged references; our goal is robustness, but we can "live" with resilience.?The point is it is an "enterprise architecture" approach.

回复
Ryan Hilger

Running with scissors through the white space on the org chart.

3 年

YES! I made the decision to go back to school for my doctorate (starting to apply now) for this exact thing. So much work to be done here!

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了