The System Shall Be Secure
20+ years after starting my career focused on information security and issues of risk acceptance, assurance, and implementation of appropriate controls within organizations, I’m still seeing the statement “the system shall be secure” as the single indication of security requirements for a given system being proposed for development. I recently had occasion to ask the senior development executive for a leading provider of software to pharmaceuticals firms to define the aspects or elements of his system that supported information security. What I got back in return was a hastily drafted statement complete with typographical errors that contained several hand waving mentions of information security jargon but amounted to essentially nothing in the way of a substantial statement of information security. I got the distinct impression that this company had never been asked for a definitive statement on information security before.
Generally speaking, information security requirements fall into four main categories:
- requirements imposed by regulation,
- requirements imposed by organization policy or architecture,
- requirements suggested by “best practices,” and
- requirements levied by the business.
Within each of these categories can be found a lengthy and diverse array of subcategories that — if used thoughtfully — could do a really great job of defining required information security within a system. One could ask a question “why don’t more organizations require detailed statements of information security requirements for projects?” The answer to that question might be interesting. One answer is of course that in the sausage making that describes systems development inside most large organizations it is often true that there is a general lack of insight about information security. Also, with well defined and well funded information security organizations, it is all too easy to say that security is someone else’s job. Whatever the reason, it is often downright disruptive to ask this question especially at project conceptualization time when funding is being sought. Let’s explore each of these four categories briefly to get a feeling for how easy it would be to dramatically increase an organization’s readiness to answer the question “is this system secure?”
Requirements Imposed by Regulation.
In this category I am including industry self-regulation as well as clear regulations imposed by statute or governmental policy making. For example, the PCI — DSS set of requirements is an industry defined set of security requirements that has a lot of visibility and respect. Simply stating that the system must be PCI compliant says volumes about the types of controls that must be in place for that system and those data types. Other controls such as those imposed by GLBA, 21 CFR Part 11, HIPAA and the Federal Trade Commission are also clear and relatively easy to include as a requirements base during project definition.
Requirements Imposed by Policy or Architecture.
Many organizations have defined detailed sets of security requirements for the technical infrastructure, configuration, and data types in use in their businesses. Such things as required Windows hardening steps are good examples of these. If an organization operates a centralized directory for identity management, new systems are expected to use that facility and not implement an independently maintained facility for authentication and sometimes for authorization. This actually illustrates one important feature of a security architecture. The primary place where a security architecture earns its value for an organization is in communicating in a detailed way to the organization’s developers, implementers, and system managers how the organization expects security to be attained when the various detailed aspects of security are independently operated across a diverse spectrum of controls.
Requirements Imposed by “Best Practices”.
In the absence of regulations or defined policies or architecture, it is useful to cite best practices as the origin for information security requirements. This can be most helpful in a case where the data types in use are different than those typically dealt with by this particular organization for example, after a merger in which a new business line is acquired by the company, it may very well be that there are new data types involved in the acquisition about which the company has never encountered the need to define architectural componentry. It may be possible in such a situation to look for best practices or standards-based guidance — such as ISO/IEC 27002 — as an excellent starting point for stating the types of security requirements that must be built into a new system or major system modification.
Requirements Imposed by the Business.
This is the only “required” statement of requirements that cannot be deleted from the project statement. The absence of a statement of business requirements implies that there are no requirements. You could very well identify a situation where there were no regulatory, policy, or best practices requirements to be found but the business still had defined requirements for security. Typically, these come from customers or the businesses’ own internal perception of the competitive environment. For example, a petroleum exploration company might want to keep the preliminary results of seismological tests secret until such time as appropriate drilling investments could be analyzed. No law requires them to protect this data but not to do so might put the company at a competitive disadvantage.
Of course, every requirement statement raises the possibility that a corresponding test could be performed to ascertain whether the requirement has been fulfilled prior to project implementation. Keeping this in mind will greatly improve the quality of requirement statements in the project definition documents. There is no substitute for the thorough review of the tests and the results of the tests obtained during acceptance testing of the system prior to implementation in building the level of assurance among managers that appropriate security has in fact been attained.
The information security profession needs to open up the black box and expose its contents to the light of day. I’m always amused by those who sniff at certain security controls with the comment, “that’s just security by obscurity.” But in actual point of fact almost all security is security through obscurity. We select controls that range all along the continuum from opaque to transparent. In theory, encryption is the most transparent of information security controls. After all, algorithms are published and often times the susceptibility to brute force attack is very well understood in mathematical terms. However, such aspects of a cryptographic implementation such as key management are not always so transparent. Security by obscurity? Maybe so. Many security controls, however, are too opaque. For example, a company with whom I maintained an online account recently modified its password standards to increase the length of the password at the same time that it eliminated the permissible use of special characters. I’m one who believes that use of special characters dramatically increases the hardness of a particular password system. When I asked about this seeming degradation in password security, all I got was mumbling because in fact no one at this company was prepared to discuss the trade-offs between password security and programming convenience. Thus security by obscurity retains its time-honored exalted place in the pantheon of street-level security controls — not due to any inherent weakness in the controls so much as the inability of the security people to discuss the operational effectiveness of those controls.
In an ideal world, the definition of security requirements for projects would consist of detailed boilerplate statements where each included security requirement would adhere to the standard that one or more test cases be run to verify the presence of effective realization of this requirement. I say boilerplate because if project managers and designers can see well ahead of time what security requirements they’ll have to attain, most of the conflict over whether or not the security requirements are fair and appropriate can be avoided. Only with a somewhat formulaic approach to the definition of security requirements can organizations be expected to develop excellence in “building in” security into their mission-critical applications.