Representative End User Clients
Representative Automation Clients
Representative Software Clients
Guidance is available, but are people actually using it?
The challenge of improving and ensuring the security of information and automation systems has garnered considerable focus and attention for many years. This is particularly true in the case of systems and technology used in critical infrastructure sectors. This attention has in turn led to the development of a large body of information that provides guidance on how to define, development, and implement effective cybersecurity programs.
Government departments and agencies have produced a significant portion of this information. In the United States, the Department of Homeland Security (DHS) and the National Institute of Standards and Technology (NIST) have been particularly active in developing such guidance. Notable examples include the NIST Cybersecurity Framework and various NIST Special Publications, such as SP800-53 and SP800-82. The DHS Industrial Control Systems Cyber Emergency Response team (ICS-CERT) has also assembled a significant collection of recommended practices.
Other sources of guidance include security product and service suppliers, trade associations, standards bodies, and training organizations. One could say that the problem is not the lack of useful information, but the difficulty in selecting and applying what is most suitable for a given situation. There are several reasons for this.
Several of these primary source documents are long, detailed, and complex. As just one example, the SP800-82 document is over 240 pages long. This presents a challenge for many asset owners who may not have the time or expertise to fully understand and apply such detailed information. In the case of international standards, the emphasis is on communicating what has to be achieved in great detail, but not on how to approach the problem.
A significant body of more focused guidance is also available. For example, the NIST Cybersecurity Framework seems to reached a relatively high level of acceptance and adoption, aided by several companion documents, such as the one titled “Small Business Information Security: The Fundamentals.” While this guide still weighs in at 54 pages, it provides practical and direct advice on how to apply the Framework in a particular situation. No doubt, other guides are still to be developed to focus on specific classes of users.
End users and asset owners need more “how to” guidance of this type, not only for the Framework, but also for other standards and practices, whether from the public or private sector. There have been anecdotal reports that several such documents have been successfully employed in the private sector, but little in the way of objective evidence or assessments of effectiveness.
Case studies would be an effective vehicle for collecting this information. If properly structured they could help describe the needs and drivers, as well as the results achieved. Although most would agree that such documents would be useful, there has been a marked reluctance to create and share such information. Reasons for this reluctance have ranged from shortage of resources to the inability to share confidential information.
We could address the concern about the effort required by using a structure or template that limits the resulting document to a few pages. The template would also obfuscate or remove identifying information, without compromising its value. For example, rather than identifying a specific location or company, all that is required is to describe the nature of the process or industry.
Previous attempts to use a similar method to collect and share incident information have met with limited success. This may be a result of the increased sensitivity associated with describing incidents and the resulting impact.
Perhaps we’d have a greater chance of success here with case studies generated using a template a approach. Do you think this is a good idea? Please share your thoughts with the author at [email protected] .