Heading 1

You can edit text on your website by double clicking on a text box on your website. Alternatively, when you select a text box a settings menu will appear. Selecting 'Edit Text' from this menu will also allow you to edit the text within this text box. Remember to keep your wording friendly, approachable and easy to understand as if you were talking to your customer

Cyber In security News

TM

December 2019
SUBSCRIBE FOR FREE
Now that lawyers have essentially become risk managers as well as legal guardians, they need to embrace the technical challenges of helping their companies secure their data.
By C. Russell H. Shearer
MY 30 YEARS WORKING WITH NUCLEAR WEAPONS AND CHEMICAL WEAPONS—two out of three for the WMD trifecta—have taught me an important lesson. Nuclear attorneys who do not understand nucleonics, environmental attorneys who do not understand chemistry, and IP lawyers who do not understand basic signal processing are unlikely to help my organization succeed, because they are unlikely to understand the basics of our business model. Their half-life is consequently very short.
     Risk managers are no different. And general counsel are often now required to manage risk as part of their portfolios. Understanding the technology of managing risk—and being able to converse intelligently with the chief information officer (CIO) or the chief information security officer (CISO), or both—is essential to understanding how to engage the issue. In some small organizations, the duties typically performed by a CIO or CISO may, by default, fall to the GC or other risk manager, even if they are not technically trained, thus making a basic technical competence imperative.
     This call for technical competence in our craft, admittedly, reflects my nuclear bias. Everyone in my industry is expected to have a basic technical understanding of the nuclear fuel cycle and the science involved. But it also reflects the best in lawyering that I have observed. The best dirt lawyers understand how to construct a building, and the best securities lawyers understand economic forces and mathematical and algorithmic formulae to guide their analysis and advice. Complexity in industry, in short, has inevitably led to the specialization in our craft that requires the technical competence I call for.

What Do Real Security Programs Require?
Security, reliability and operability. The need for security is a precedent, given the cost and potential catastrophic infrastructure damage of any breach. Reliability is the watchword to profitable operations. And an operating process is a necessity to be in business. Conversely, however, one may be completely secure if one never operates, but that approach is unlikely to drive shareholder value or accomplish the company’s mission. These elements demonstrate the need to balance risk with security, reliability (or efficiency) to maintain ongoing operations.
     Where does compliance figure in? Implementing compliance programs that live only in a three-ring binder and that are not integrated with the technical aspects of the system with which they are intended to interface is like building a chemical plant and installing worker-safety controls based on written rules (administrative controls) rather than automatic systems (engineered controls). Only by understanding the available technology can a risk manager make the correct puts and takes. And only after building those engineered controls can the manager implement a better compliance program—and understand the interface and integration of the two.
     A further challenge exists in cybersecurity today. Common terminology does not yet fully exist; consensus standards are not abundant; guidance and best-practices documents continue to evolve. The cybersecurity field strives to invent itself, sometimes even though analogous standards exist in other high-hazard or high-consequence fields that could be applicable. The attorney or risk manager in such an instance should, in my view, serve as an honest broker to bring these analogous standards to light and show their applicability. But how can the attorney or risk manager do so competently and credibly without a baseline understanding of the technical issues involved?
     The technical issues are admittedly complex and challenging, and even teasing them apart to ascertain a suitable analytical framework is difficult. The risks applicable to an online vendor, for example, may or may not be applicable to a national defense manufacturer with no traditional e-commerce website. And the critical infrastructure risks for operational technology, such as supervisory control and data acquisition systems and industrial control systems applicable to that national defense manufacturer, may or may not be applicable to that online vendor.
     Counsel and risk managers could return to school and get a degree in engineering or another technical discipline, but that could take years. So I propose instead a modest process framework for attorneys and risk managers to approach the technical issues that will allow us, in turn, to apply better risk management decision-making techniques (see the chart at the top of this page).

A Proposed Process Framework
The framework is predicated on a common quality-assurance approach: plan, do, check, apply lessons learned. It begins with an understanding of the design basis of the network. The design basis is constituted to match the performance requirements—or postulated events—that the structures, systems and components (SSCs) making up a network have been designed to withstand. This includes the essential performance characteristics of each SSC, the overall performance requirements for the network, and the development of the security measures necessary to protect against a vulnerability (like a design-basis event) or an attack. The design basis is developed during the design of a new system, or can be devised retroactively for existing systems.  
     Next, the workforce is trained to avoid and respond to both design-basis threats and those not previously contemplated. Training continues throughout the lifecycle of the SSC, and may also be introduced concurrent with implementation or at another time, depending on risk (such as for a low-risk SSC). The SSC is then made operational. Efforts to secure data as it is used follows. This includes (a) security for data in transit (such as by wireless devices or local area networks); (b) managed access (such as building or room access, data encryption during transmission, identity authentication for systems and controlling access on a need-to-know basis); and (c) information-sharing assurance (such as programs to share lessons learned and other key data across the organization).
     Anticipating and defending against threats begins the moment that the SSC is implemented, and includes (a) understanding the battlespace (such as NIST, Framework for Improving Critical Infrastructure Cybersecurity), and (b) preventing and delaying attackers from accessing the network and staying in the network (such as NIST, Risk Management Framework for Information Systems and Organizations ).
     Preparing for the future is the next step. This includes developing and maintaining trust with internal and external stakeholders, by doing things like following and integrating their guidance. It should also involve strengthening cyber-readiness through penetration testing and continuous network and threat monitoring. And it should also involve demonstrating responsiveness through plans for crisis management, continuity of operations in the event of natural phenomena or other business interruptions, and the development of event recovery plans.
     The final and most critical step is sustainment, which completes the feedback loop, evaluates learning from the implementation of the SSC, and seeks out opportunities for improvement, whether from self-evaluation, independent audits or events that result in corrective action.
     A built-in self-evaluation function interfaces with each step in the process and evaluates the potential for unreviewed security questions (USQ). The USQ process (see chart above) evaluates any instances where an event, exercise or analysis might reveal a potential vulnerability outside of the bounding analysis of the documented design basis of the network. Depending on the nature of the potential threat, operations might continue unabated, be curtailed or be completely shut down, pending the analysis necessary to resolve the USQ. Corrective actions are then developed, tracked and implemented.
     Attorneys and risk managers often write their organizations’ policies and procedures. The need for basic technical competence is now necessary for them to perform these tasks as well as to advise their companies on network cybersecurity. While the lawyer and risk manager should not substitute their own judgment for the judgment of colleagues who possess technical expertise, lawyers and risk managers who are technically competent and technically inquisitive possess excellent tools to evaluate complex issues where law and science intersect. They are not apt to be perfect, but they are likely to make important contributions to help make their companies more secure.

C. Russell H. Shearer is the chief operating officer of ISL, Inc., a technology development and manufacturing corporation specializing in intelligence, surveillance, reconnaissance, nuclear energy, space exploration and cybersecurity. Shearer was previously the company’s senior vice president, general counsel and secretary, and over the years he has occupied a host of other positions in high-hazard industries.

__________________________________________________________________________________________________________________________________


NOTE: For readers interested in further exploring the framework described above, this chart shows how the process might work to develop, implement and bin policy and procedure. It provides the next level of detail about how this process might work.
Share