Auerbach Publications
© 1998 CRC Press LLC 02/98
DATA SECURITY MANAGEMENT
S
ECURITY
T
ESTING
I
S
N
OT
A
LL
T
HE
S
AME
: A
R
EFERENCE
T
AXONOMY
Jim Kates
I N S I D E
To Test or Not to Test, Who Does the Testing?, Choosing the Right Tests, Penetration Teams, Tiger Teams, Vulnerability Assessment, Security Review, Forensic Investigations, Audits
INTRODUCTION
Testing the efficacy of security systems and networks has become a thriv-ing business for many companies today. The reasons for implementthriv-ing a security-testing program are varied, and no two organizations will find exactly the same rationale applicable to them. These include:
• Customer Confidence • Legal Protection
• New Product/System Testing • Fiduciary Responsibility • Privacy Laws
• Insurance Requirements • Government Regulations • International Cooperation • Trade Secret Protection
As the need for increased protec-tion heats up, a flurry of terminology is being thrown around in an effort to impress clients, but it generally ends up just confusing them. Most customers do not know or under-stand the significant differences be-tween the various security-testing
P A Y O F F I D E A
Security managers are always being offered new methods to test the security of their systems. Un-familiarity with the terminology and types of test-ing can result in the manager not getttest-ing the ser-vices he or she is seeking. This article presents a taxonomy of terms in order to classify the differ-ent types of services available, and explain how each technique evaluates security controls in real-world settings.
methods, and too many vendors rely upon that ignorance to sell their wares and services.
Consultancies and audit firms, many of whom are quite new to the world of security, offer to perform “penetration tests” or “security re-views” within a client’s computing environment. On the surface, these services may resemble EDP audits that have been performed in the past; however, that is not always the case. Requesting an EDP audit instead of one of several security testing alternatives may be a huge and costly mis-take. Without clear guidance of what these services are and how they benefit an organization, executives are often confused about which is an appropriate approach.
This article attempts to clarify these confusions by explaining the im-portant differences in the way computer security controls are evaluated and tested in real-world environments.
TO TEST OR NOT TO TEST: SECURITY-WISE
One question that looms large in a company’s decision about how to proceed is: “Should we test a computing system’s controls and security now, or should we wait until unauthorized persons, like hackers, try to exploit us?”
Many companies face this question today, especially those who are pursuing electronic commerce endeavors. Even though the answer ap-pears easy, testing of security is often perceived as a cost without real benefit. After all, the adage goes, “If a security system [policy, staff] works well, you will see nothing.” So, why spend money for something that may never occur? Furthermore, the internal development group often as-sures management that their new products, applications, or systems are secure so why should it be required that controls and security features be evaluated? This apparent arrogance, though, breeds trouble and addi-tional vulnerabilities. Integrators and developers are not security special-ists, no more than a security specialist should develop custom database applications without help.
If an executive was to buy that logic, why stop there? Why not fail to require a budget, expense reductions, or other key financial controls? Testing the system’s controls is a necessary sanity check to ensure that the system works as expected and to identify risks before they are exploited. The identification of exposures before they are exploited means re-duced losses and less embarrassment. Thus, when executives understand the business reasoning for testing a system control’s effectiveness, it makes the decision easier. Bottom line: it is a whole lot cheaper to build and test security controls in from the beginning, rather than treat them as an afterthought. However, two fundamental questions still have to be an-swered before proceeding:
Is it better to use a hacker, a security consultancy or an employee to test security and process controls? and, What type of security tests should be performed on which systems?
WHO DOES THE TESTING?
Using a hacker to try to compromise a computing system may be more of a risk than trying to solve the original problem. The unethical and criminal nature of many hackers does not stem exclusively from their lack of character or personal disregard for the law. It often merely arises from their lack of corporate work or real-life experience, which teaches the proper use and misuse of computing systems.
Using a hacker who does not understand how a business organization functions is like asking a baseball fan to replace the starting pitcher in a game. Besides all of the negative reasons, most general-purpose hackers do not understand security concepts and organizational rules, and they are usually limited in their skill sets. Lastly, if for whatever reason an or-ganization chooses to use a hacker, determine if they have ever been ar-rested or convicted of anything. Caveat Emptor.
The preferred manner, though, is to contract a security expert as a consultant, but this too, poses several issues to the executive. First is the cost. Good security consultants are not cheap. Cost is almost always the reason for going to one of the other two options: hackers or nothing at all. Budget accordingly; experienced security experts charge more than less experienced, and their work product usually reflects it. The second concern is the worry of confidentiality exposure, but that is easily han-dled as with other contractors or consultants: through confidentiality agreements.
Real security mechanisms are rarely built into new applications or sys-tem costs. Thus, every time a security issue comes up, it appears to be an added expense. However, for the well run organization, security expens-es (like penetration texpens-ests or security reviews) are an ongoing operation that are budgeted into the overall costs of running a business.
Employees are by far the most appropriate persons to perform ongo-ing security tests in conjunction with the consultancy. They are experi-enced with the systems, they will be around longer than the consultants will and they have a vested interest in keeping the systems secure. How-ever, many organizations do not have the luxury of hiring their own se-curity experts to test their system controls. Most of their sese-curity employees are busy implementing the controls. One concern that does arise is whether the organization is creating its own Frankenstein; e.g., an employee trained to break into any corporate system they own. Howev-er, as with security consultants, that risk is mitigated with strong ethical
consideration of the employees and no-nonsense legal clauses stating what happens when persons extend their legal authority in a system.
CHOOSING THE RIGHT TESTS
Choosing which tests to perform is sometimes more difficult than picking whom to use for the testing. Some tests are mandated, such as corporate audits. Some are performed as a normal part of the system or the security department’s work product. The right test depends on what is desired, needed, or mandated. So why is it difficult to make an informed decision on which testing methodology to implement? Because too many consult-ants and audit firms indiscriminately throw around techno-babble and security terms loosely and incorrectly, thereby making it difficult to un-derstand exactly what they mean or what is being offered. Different groups may use the same terms to describe different services or different confusing terms to describe the same techniques.
The following sections explain the different ways security controls are typically evaluated. They vary in scope and objectives. Often they vary in who contracts for and receives the end report. The main differences are the depth and extent of the work and how important it is to find the root cause of discovered vulnerabilities.
As should be expected, the costs and time vary significantly. However, the largest cost difference is whether the process is reactive or proactive. Reactive costs are greater, since more resources are usually used to ex-pedite the report and solutions. In a world of the educated consumer, a better understanding of what is wanted and what will be delivered as an end product can help reduce the overall costs. So, planning ahead saves a ton of money.
Once an organization has decided to proceed with security testing, which approach or approaches will need to be taken? The following tax-onomy of security testing will examine five distinct and separate ways of evaluating controls within a computing environment. Which approach is best suited to an organization’s individual needs is a decision that should be determined with a consultant. This article does not favor or highlight one service over another, but merely does what many consultant firms have a difficult time doing: it explains the differences in the services in a way senior management will readily understand.
Penetration Tests
This overused and misunderstood term has created a lot of hype. It has become a buzz word thrown around to describe everything from a five-minute evaluation to a several-month-long consultant assignment. “Pen-etration testing” or “pen“Pen-etration analysis” is nothing more than a phrase
to describe a legitimate attempt to compromise the expected controls of a process.
Often, the process of being “penetrated” is automated, like a comput-ing system or network. The attempt is to identify, by the system owner, if the appropriate controls are being maintained properly and work as expected. The test tries to establish whether control mechanisms can be sidestepped or manipulated in a way that would allow a greater degree of access than is expected.
The results do not focus on whether or not organizational rules are be-ing followed, such as the frequency of password changes. Durbe-ing a pen-etration test it is not relevant how good certain controls are, or how good of a job the system administrator is doing protecting the system overall. That is because the singular objective of a penetration test is the success-ful compromise of controls under evaluation. It is these controls which are evaluated and the basis of the report is focused. Typical types of pen-etration tests are:
• External source penetration • Internal source penetration • Targeted system penetration
Be clear, though, that limitless assaults against the organization’s tems present a new set of risks, including the danger of accidental sys-temic collapse or other denial of service events. So, whether for penetration tests or other security testing, establish the so-called “rules of engagement” before commencing the tests.
Tiger Teams
Tiger Teaming is another one of those misused terms that needs clarifi-cation. A Tiger Team is a group of individuals who legitimately (that is, with permission) attempt to compromise a set of physical or logical controls.
Tiger Teams are similar to penetration tests; however, they permit more varied styles of attacks, specifically physical ones. They go beyond the bounds of penetration teams and may revert to disguises or other rus-es to accomplish their objectivrus-es. Tiger Teams might choose to break and enter into a facility to gain access to the network resources, or pretend to be an employee, contractor, or just the water or pizza man. In any case, he gets into the facility.
In some cases, the testing of the physical controls themselves may be the goal, and therefore, physical Tiger Team assaults are the only re-course. Most commercial companies shy away from this type of dedicat-ed attack.
Tiger Teams generally have very specific objectives in mind, where the Penetration Test is more generalized. Their goal may be to compro-mise the physical protection of a key resource, or, to obtain specific trade secret information — be it in electronic or physical form. Tiger Teams also may be testing an organization’s rules or expected behavior in oper-ational security areas such as:
• Incoming and outgoing physical inspections from the facility (think diskettes and CDs)
• Remote keyless entry systems
• Alarms, sensors, and response mechanisms
• Testing efficacy of specific departments, job functions, or personnel in the performance of their duties
• Physical external perimeter testing • Computing facilities test
• Special logical application tests
Vulnerability Assessment
Vulnerability assessments are expanded penetration tests with a specific scope and objectives. Their objective is not only to identify what prob-lems may exist within the targeted systems, but also how these probprob-lems relate to other systems or applications.
Their scope is much greater than penetration tests, which merely try to compromise the controls. The goal of these assessments is to under-stand the complexity of the control and determine under which circum-stance these controls could be compromised, even though they may be adequately protected at the present time. (The nuclear weapons labs per-form expansive, hypothetical testing continuously, as technological capa-bility proliferates.)
Vulnerability assessment goes beyond the mere technical and includes personnel functions that oversee technical process such as:
• Excessive authorities given to, or assumed by individuals • Separation of duties and dual controls
• Lack of management involvement within security process
The focus of the assessment is not only on the identified weaknesses themselves, but on what really caused and is the source of the problem. Typical vulnerability assessments include:
• Intrusion monitoring and reaction capabilities • Interenterprise connectivity
• Competitive intelligence risks • Remote access programs
• Internet connectivity • Electronic commerce
Once the root causes have been determined, whether the customer takes any proactive corrective measures is another issue. The better se-curity experts will make strong cases for additional defensive postures and policy and procedures changes.
Security Review
A security review is a formal analysis of the controls within an environ-ment that are necessary to meet good business sense and organizational requirements. Going beyond the penetration test and vulnerability study, the security review focuses on the Big Picture, not just the bits and bytes. It delves into areas to discover which factors within the environment are not meeting expected standards. It mimics a formal audit without the for-mal reporting mechanisms. The review process usually allows the man-agement chain involved to correct the violations found without escalation of the findings to higher regulatory authorities.
The security review may include penetration tests, tiger teams, or a vulnerability study as part of the review process. It is this extended scope or coverage that separates it from the other processes. It may include documentation reviews, audit trail examinations, and other details that may not be within the scope of other examinations. Typical security re-views are:
• Pre-audit preparations to ensure a clean bill of health under a rigidly controlled audit
• New business applications to regulatory agencies • Migration to other platforms or networks
Forensic Investigations
Forensic investigations usually occur after a crime has been committed, if a company believes a crime if being committed, or after a serious se-curity violation. Forensic investigations are very structured and the scope is strictly defined. During a forensic investigation, great care is taken to preserve all of the evidence that might be useful later in any legal pro-ceedings, and to protect the specific physical and electronic environ-ment from corruption from accidental modification because of investigative efforts.
The forensic process is extremely laborious and time consuming. It re-quires highly specialized skills and tools, and a strong understanding of the process. Forensic investigations are most likely driven from outside the organizational group it is reviewing, e.g., legal. One of the most
dif-ficult questions this investigation faces is, “whom do you trust?” The in-vestigator does not know who is involved in the situation, from management on down, or the full extent of their efforts to help thwart the investigation. Typical forensic investigations include:
• Fraud investigations • Criminal investigations
• Electronic intrusion investigations • Post-merger investigations
Audits
Audits are a necessary part of the business process; however, they are not often appreciated by those subject to them. Audits are a control mechanism within themselves, which oversee other control mechanisms. The audit process is not conducted to find out which staff people are wrong, but to determine which process may be weak or need improving. The audit is very similar to a security review, except that the handling of findings and the reporting process is much more formal and rigid.
The defined scope of the audit dictates what processes are reviewed and which are included in the formal report. However, audits are not only used to find mistakes or problems. They can be used to generate logic or reasoning to justify adding manpower or technical resources that management is often reticent to provide.
Audits can explain why additional security resources are needed and the reports of those findings are sent to the appropriate management. The audit is a conventional business process found in many organiza-tions where none of the other security tests may ever be performed. In many organizations, it is the audit group who initially starts the other process or works with the information systems area to help define the re-quirements. Typical audits include:
• Internal audits (internal folks) • External audits (external auditors)
• Specialty audits (applications, pre-merger, special tasks)
CONCLUSION
Evaluating security controls is a necessary component of any effective in-formation security program and an essential business process. Choosing from a very specific set of options just how these controls will be evalu-ated is key to the results one will receive. Keep in mind that each of these approaches has distinct methods, goals, and processes, and not ev-ery one is required for evev-ery situation.
Part of the process in deciding which approach is right for any orga-nization is based upon the status of its internal programs and business applications:
• Are the controls already implemented?
• Are they in the process of being implemented? • Are they still in the planning stages?
There is no right answer for every business, and a wide range of cri-teria must be taken into consideration:
• The depth of the review desired • The budgetary constraints • Insurance and legal implications
• Internal skills available to the organization.
• Executive commitment to isolating security vulnerabilities in a proac-tive manner
When testing the efficacy of an organization’s security system, take the time to do so through a quality decision-making process. By evaluating and understanding the options, an organization can make decisions more effectively.
Jim Kates is the chief technology officer of the Security Experts, Inc., an international security consulting firm, based in Largo, FL. He can be reached at [email protected].
