by M. E. Kabay, PhD, CISSP
Director of Education,
International Computer Security Association
E-mail:
Mich_Kabay@compuserve.com
URL http://www.ncsa.com
Copyright © 1998 ICSA, Inc. All rights reserved.
In April 1998, ICSA introduced TruSecure, a coordinated suite of guidelines and tests to help organizations meet minimum information security requirements. Meeting such requirements not only protects corporate and client data but also plays an important role in meeting corporations’ fiduciary duty. In law, corporate officers must apply due care and diligence in the exercise of their responsibilities towards shareholders, clients and other stakeholders. This White Paper provides the background of the TruSecure program by explaining why ICSA introduced it, what it involves, and how it can help client organizations reduce risks by an order of magnitude.
Information Security has increased in visibility over the last decade, especially with the growth of the Internet and particularly that of the World Wide Web; for example,
The problem is that as far as security specialists can determine, most organizations have still not succeeded in implementing even the most basic protective measures required to defend their information systems . Not only do private conversations with network managers, system administrators, and corporate management in general suggest a major problem, but surveys, polls and studies confirm that in the real world, practice does not necessarily follow theory. The information technology industry knows a good deal of what corporations ought to do but collectively the technocrats are failing to make a significant difference in the commercial security posture. Those organizations which have invested in security systems often discover that these devices and programs are not always properly configured to protect their information assets – especially those exposed to access from the Internet . Some organizations which would like to improve their security lack the internal resources to make their security posture conform to their tolerance for risk. Some organizations seek independent external review of their security implementations for purposes of internal control, budget justification, or other internal needs.
How is it that advanced technologists are collectively not getting it right? They aren't getting it right because the problem is not easy to solve; on the contrary, information security in the real world is much harder than it would seem from reading academic textbooks and papers – or the promises of some vendors and marketeers .
At a fundamental level, information technologists are still at an infantile level of risk management . They don't have a thorough understanding of threats to their systems; they don't have adequate statistics on the frequency of those threats; and there are so many variables in defining computer systems that it's hard to know how to apply statistics even if they existed. Information security specialists and risk managers are supposed to perform a cost-benefit analysis for security by looking at probabilities, estimating costs for prevention and for recovery from damage, and then computing annualized cost expectancies for different kinds of problems. However, neither part of this theoretical approach is typically known in any given situation. Worse, the methodology and the data – such as they are – are largely unknown to network and system managers in the real world. Certainly such data and methodologies are almost completely unknown to desktop computer and workstation users.
In any case, users should not have to become security experts to avoid disaster any more than average automobile drivers should become mechanical and electronics engineers. Society doesn't expect drivers to be able to debug and refine their anti-lock braking system computers or to patch the microcode in their fuel-injection system microchips. Why should people focused on supporting the business needs of their users have to become security experts?
Practitioners face an enormous range of sources and types of risk , . No single product is likely to be sufficient to protect against accidents and attacks. Complex combinations of tools lead to manifold interactions and the emergence of new weaknesses. Weakness at one level of the security architecture can profoundly damage the usefulness of other components at different levels. A classic example of this kind of interaction occurs when expensive new access-control systems using state-of-the-art smart cards are defeated by employees — not through malice, but through simple politeness – when they open their locked door with their own card and let one of their friends and colleagues into a secured zone. Information security is complicated further because some of the threat comes not from inanimate forces such as fire or flood but from dishonest or malicious people who expend enormous effort to defeat the current generation of security measures. As a result, information security in today's world of intranets, extranets, and the Internet is a dynamic struggle against a tidal wave of new vulnerabilities, changes in network configuration, addition of new products, changing patterns of use by old and new users, and inevitable upgrades to software and hardware.
A bit of history will be useful in understanding how ICSA has developed the TruSecure process – and why we call it a process instead of a product. Around 1990, it became clear to Bob Bales and Paul Gates, two of the founders of the NCSA (the name of the ICSA before 1998), that the anti-virus industry was going to be in trouble unless there were some effort to meet user needs in a concerted way. Anti-virus companies were using different words to describe the same features; they were using different names to describe the same viruses; and they were competing with each other to identify the largest number of viruses without sharing information about those viruses. NCSA gathered together representatives of major anti-virus companies and got their agreement to form the first NCSA consortium: the AVPD (Anti-virus Product Developers Consortium). One of the early outcomes of the meetings was the decision to develop standards for certification of the different anti-virus products using common terminology and a "virus-zoo" built up from contributions by all the members. The initial response by technical people from the AVPD was significant in light of later developments: as soon as the first standards were defined, the technical staff laughed at the criteria, expressed incredulity at the very idea that their products could possibly fail such lame tests – and were shocked when one third of all of the products failed the first certification trials.
The same pattern developed in each of the other consortia. The firewall technicians laughed at the first firewall certification standards; it was only after several of their products failed that they realized that there is more to effective implementation of security than good design. All of these experiences were consistent with what is known about quality assurance: it is very difficult to evaluate one's own product. Independent validation is an important tool in identifying user errors that are overlooked by people who know what ought to be done. When security measures are installed by ordinary users, there is a very high likelihood that they will misinterpret specific recommendations for configuration and installation, or that they will make assumptions that the experts would not have made and therefore never considered testing.
An interesting development for ICSA was the realization that we disagreed with the kind of certification traditionally done by government bodies. It seems to us that most government certification is based on engineering principles instead of on an evaluation of risk. Government standards such as those enunciated in many of the Rainbow Series publications make the assumption that risk managers can and should build information systems from the ground up to be secure. It's been a fundamental basis for computer security for decades – but it doesn't work, or at least it doesn't work in the real world of commercial systems. Commercial clients don't have the choice of building security in from the ground up. They don't have the choice of telling Microsoft how to write its operating system – it's already there, and as the Justice Department is discovering, there's not much they can do to alter its design. They cannot tell CISCO how to build its routers. They no longer have the choice of telling people how to construct a secure Internet protocol. So they can't start by defining engineering principles and evaluating how closely products conform to those theoretical principles.
In these circumstances, security practitioners are forced to retrofit security. The kind of certification ICSA have developed, and that is required, is based on the systems customers are given and modifications they can make to it that will deal with current and foreseeable risks and changes in hardware and software. That's why product certification is the way it is for us at ICSA. It's dynamic and it's based on risk. It has to be dynamic because no one has the ability to apply fundamental principles perfectly; everyone is stuck trying to modify whatever they have now and improving it, with the hope that this pragmatic process is leading the industry to improve what it is doing.
Around 1996, the NCSA decided to apply its expertise to the problem of securing Web sites. NCSA put together a set of simple principles that would help owners and operators of Web sites significantly to reduce the risk of damage through internal errors, omissions, and attacks and more particularly from external attacks. ICSA defined certification of the client's Web site as the goal of WebCertification because it seems to fit the needs of large subsets of World Wide Web site owners – those concerned with assuring their clients of the security of those clients’ data on the corporate Web site.
These analyses and interactions with ICSA clients revealed an interesting but disturbing problem: as discussed above, many sites which ought to have been secure (given their hardware and software) were in fact not secure.
As ICSA worked with WebCertification clients, some of them asked ICSA if we could expand the kind of process leading to WebCertification to the rest of their networks. One interim solution was the ICSA Perimeter Check, which did not involve certification itself. ICSA Perimeter Check uses many of the vulnerability-scanning tools collected from above-ground and underground sources and also developed for WebCertification. With continued discussion, it gradually became clearer to ICSA staff that we could significantly improve security for many more clients. Systematizing our approach to information security assurance and applying this method to all of the clients’ networks and computer systems would be cost-effective for them and profitable for ICSA.
TruSecure is a process that identifies your current IP vulnerabilities, provides the methodology to correct the deficiencies, certifies the security of your site and then stays in contact with you to ensure that your perimeter stays secure.
TruSecure starts by identifying all of the access points in your IP perimeter. A complete electronic assessment to identify vulnerabilities is performed and analyzed. You receive a comprehensive report along with SecurePath, the ICSA methodology for minimizing exposure to information security breaches. Upon completion of SecurePath, another suite of electronic tests is performed to ensure all visible cracks have been sealed. ICSA then performs an on-site visit to thoroughly assess local issues, to present a summary of all findings and to answer your team's questions. Should you choose, your site then qualifies as ICSA certified. Throughout the next year, TruSecure clients receive twice-monthly security alerts and at least two electronic spot checks based on renewed security standards as well as other ICSA information and services.
TruSecure is a suite of information, guides and services for companies, which provides:
1. It is based on ICSA's independent standards, derived from the global community and with many layers of public and expert input, not from an organization's own, internal policies.
2. It is a continuous, dynamic process that is always kept current. The program operates throughout the year to enhance security and to work even as you change your network applications, services, topology, equipment, and so on and even as new threats and vulnerabilities surface.
3. It is specifically designed to address all five layers of vulnerability in an organization: Physical-Environmental, Network-connectivity, Platform-Operating System, Application-Service, and Human-Policy.
4. It is specifically designed to reduce the most current risk with the lowest cost and interference in productivity and to continue doing so.
5. TruSecure is the integrated process that may lead to ICSA certification of your site. Though actual certification is optional, whether you are certified or not, the process is the same.
6. ICSA has no hidden agenda. ICSA does not try to sell you consulting, security products, or system integration. ICSA provides support for you to improve your own systems by providing up-to-date knowledge and by testing your defenses so you can fix them as conditions change.
7. ICSA is an international security-assurance company building strong ties with commercial security experts and academic advisors by certifying products such as firewalls, anti-virus products, commercial cryptography products, and authentication products.
8. TruSecure establishes a relationship that can continue constructively as your organization grows and changes.
9. TruSecure is inexpensive and cost-effective mechanism to help an in-house security team bring information security to an effective level.
ICSA certification is an optional outcome of the TruSecure process. Some clients may find that certification speaks to upper management or meets the requirements of marketing departments. A more important question for many, though, is how certification can possibly be meaningful in a changing environment. ICSA believes that certification does not and should not imply perfection. Certification is a marker, a milestone in an endless process of adaptation to a changing environment. Certification is one tool in the continuing effort to improve security significantly in the real world .
ICSA TruSecure is a systematic approach to significant risk reduction in the imperfect, real world of commercial off-the-shelf systems and changing threats. The TruSecure process establishes baseline security principles that reduce important risks by at least an order of magnitude. TruSecure provides a cost-effective mechanism for security evaluation, practicable improvement, ongoing testing and dynamic response to a changing security environment.