0
0
437
There is an emerging recognition in the regulatory analysis of cybersecurity that metrics or benchmarks representing best practices are crucial for creating flexible, enforceable, and effective regulations. Several recent initiatives, such as the US Cyber Security Framework (or CSF) moved in the direction of creating a framework that facilitates and streamlines the ratification and deployment of best practices. The model for defining such frameworks is clear: the stakeholders (government, academia, civil society organizations, and industry) need to collaborate in order to build a broadly applicable approach. This is one of the multidisciplinary areas where practical considerations need to be applied in concert with innovative ideas and regulatory requirements.
But the science of risk engineering is still in its infancy, making it difficult to incorporate lessons learned in one effort to a different class of use cases. The emerging field of “risk engineering” is attempting to build the foundations that could make frameworks like the CSF reusable for novel environments and make them more responsive as the technology environment evolves.
Risk engineering can be defined as “incorporation of integrated risk analysis into system design and engineering processes.” In this regard, risk engineering is conceptually similar to designed-in security as it focuses on techniques that could be used to evaluate and assess risks during the technology lifecycle, from development to replacement.
Although risk engineering methodologies have not yet been defined, it is clear that such methodologies could only be successful if they deal with an integrated picture of risks, including, at a minimum, the domains of security, privacy, safety, reliability, and resilience. It is also clear that several obstacles will need to be overcome in order to create a solid foundation for future work. One of these early challenges is a semantic framework that is necessary to enable a consistent terminology and ability to reason about the environment based on a shared view. A multi-domain ontology is needed to accommodate this requirement. Today, even the most elementary terms, such as “incident,” have different definitions within different risk communities. In the area of safety, “incident” denotes an event that doesn’t have safety-critical consequences, whereas for the security community, an “incident” is a serious breach.
Another obstacle is a consistent approach to metrics that could lead to objective measurements of risk, a serious problem when an integrated risk model is considered. For example, probabilities in the risk domain of safety are extremely small, with tiny probabilities of failure. On the other hand, probabilities of a breach in security and privacy, where diverse and evolving attacks need to be taken into consideration, are much larger. Thus, an integrated view on risk metrics is necessary to ensure success in risk engineering.
Yet another area that will need to be addressed is risk composition, the ability to measure integrated risks that compose, in a meaningful way, risk parameters in multiple domains.
Finally, a methodology defining the role of integrated risk considerations during the product and technology development process needs to be defined. Such a methodology will need to support risk revisions associated with the environmental changes and new technology introduction as well as deployment use cases.
Although the challenges associated with the development of a consistent risk engineering paradigm are significant, the benefits, for the technologists, and in the future, the regulators, outweigh the need for a significant development effort. We believe that the risk engineering approach is set to become an integral part of the technology development and technical policy space.
But the science of risk engineering is still in its infancy, making it difficult to incorporate lessons learned in one effort to a different class of use cases. The emerging field of “risk engineering” is attempting to build the foundations that could make frameworks like the CSF reusable for novel environments and make them more responsive as the technology environment evolves.
Risk engineering can be defined as “incorporation of integrated risk analysis into system design and engineering processes.” In this regard, risk engineering is conceptually similar to designed-in security as it focuses on techniques that could be used to evaluate and assess risks during the technology lifecycle, from development to replacement.
Although risk engineering methodologies have not yet been defined, it is clear that such methodologies could only be successful if they deal with an integrated picture of risks, including, at a minimum, the domains of security, privacy, safety, reliability, and resilience. It is also clear that several obstacles will need to be overcome in order to create a solid foundation for future work. One of these early challenges is a semantic framework that is necessary to enable a consistent terminology and ability to reason about the environment based on a shared view. A multi-domain ontology is needed to accommodate this requirement. Today, even the most elementary terms, such as “incident,” have different definitions within different risk communities. In the area of safety, “incident” denotes an event that doesn’t have safety-critical consequences, whereas for the security community, an “incident” is a serious breach.
Another obstacle is a consistent approach to metrics that could lead to objective measurements of risk, a serious problem when an integrated risk model is considered. For example, probabilities in the risk domain of safety are extremely small, with tiny probabilities of failure. On the other hand, probabilities of a breach in security and privacy, where diverse and evolving attacks need to be taken into consideration, are much larger. Thus, an integrated view on risk metrics is necessary to ensure success in risk engineering.
Yet another area that will need to be addressed is risk composition, the ability to measure integrated risks that compose, in a meaningful way, risk parameters in multiple domains.
Finally, a methodology defining the role of integrated risk considerations during the product and technology development process needs to be defined. Such a methodology will need to support risk revisions associated with the environmental changes and new technology introduction as well as deployment use cases.
Although the challenges associated with the development of a consistent risk engineering paradigm are significant, the benefits, for the technologists, and in the future, the regulators, outweigh the need for a significant development effort. We believe that the risk engineering approach is set to become an integral part of the technology development and technical policy space.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.