Dr. Richard B. Neely, CISSP

Richard works with Technology Associates Colorado Springs, Colorado. He has provided technical direction over the past two years for an insider threat program for the Advanced Research and Development Activity (ARDA), and for increased security assurance analysis for a major weapon system. He has also been developing the security policy and architecture (including semiformal modeling) for those programs. Over the past 27 years he has had extensive experience in information security. His work has included development secure operating systems and networks, development of security architectures, security risk analysis, and semiformal and formal security modeling for numerous major systems, including weapon systems and modeling and simulation systems. Dr. Neely received a Ph.D. in artificial intelligence from Stanford University in 1973 and has published over 40 papers in the areas of AI and information security. He has been a Certified Information Systems Security Professional (CISSP) since 1997.

Developing an Enterprise-Level Information Security Program
An appropriate set of security controls—also termed “countermeasures”—must be established to meet specified security objectives in a given threat environment. This is true for any entity with security objectives—a product, a system, or an enterprise.
For a set of security controls to be appropriate, it must be driven by a risk analysis with a scope that is broad enough to encompass the functionality of the entity, the security objectives, and the threat environment. That observation may seem obvious, but it unfortunately is not. Security controls are often selected in an ad hoc, overly narrow way. In particular, they are often limited to technical controls addressing only a small part of the entity. For example, while the entity being protected may be an enterprise, it is sometimes only a few computer systems within the enterprise that are addressed.
It is often necessary to best to take a “big-picture” view, insisting that the entity addressed be the related enterprise. The entity so selected must be a center of command or economic responsibility. This may be a corporation, a military command, or even a development project.
The controls must address all the security objectives and all aspects of the threat environment. Such a cohesive and complete set of controls is often termed an information security program.
For a number of years, we have supported the development and maintenance of security programs for all three categories of enterprises—a major corporation, major military commands, and the production of a large modeling and simulation training system. That experience has enabled us to mature an effective approach for establishing security programs. That approach is the subject of the presentation introduced by this abstract.
The presentation will include what a security program “looks like” (and what it does not); a detailed explanation of the facets (types of security controls) of a security program; and the steps for developing and maintaining a security program.

Minimizing Perceived Complexity in Large Systems
Demonstrating security assurance, resulting in the certifiability of a system, can be frustrated by the system’s complexity. Where the design of a system is unnecessarily complex, it is essential first to reduce the complexity to a reasonable minimum. This is ideally accomplished early in the design process, where the cost of the reduction is far lower than it would be later on.
The subsequent residual complexity—that which is necessary to meet its specified requirements—may still be significant. As such, it may continue to present an impediment to certifiability. An approach we have developed for managing such complexity is to divide it into a number of “factored views.” The perceived complexity of each view can be far less than the system’s residual complexity. If this factorization is effectively documented, demonstrated, and understood, the result can facilitate certifiability. To achieve this goal, it is necessary for each factored view to closely pertain to the system and for the factor’s complexity to be limited. It is also necessary for the factorization scheme itself to be simple and to be clearly related to the system.
Any number of factorization schemes are possible, many based on defining and using a hierarchy of abstraction layers that describes an aspect of the system. For a very complex system, multiple such schemes can be used.
One kind of factorization is design decomposition. This strategy is essential in developing any system, and helpful for its understandability; but for a large system of systems, it is not sufficient. The abstraction layering approach for complexity factorization allows a great deal of versatility. In some cases, an abstraction scheme relates directly to a part of the system design. In other cases, it does not.
This presentation will describe our approach to factoring the complexity of a large system of systems using, together, three abstraction layering schemes. This approach has been effective for improving the understandability and certifiability of the system. These schemes are sufficiently general that they are applicable to a great range of systems in which complexity factoring is desirable.