R ESOURCE L AYER

Resources, as previously defined, are systems, applications, internal users, databases, services, printers, local area networks, operating systems, and data. Resources rep- resent what organizations feel are their core technical requirements to make money, or supporting mechanisms for the evolution of the business as a whole. Nevertheless, resources are effectively what you want to protect, control access to, and use to conduct business. In that light, not every resource demands the same level of security. It is not uncommon to have useful information destroyed with little or no impact on the business operations. On the other hand, the slightest unauthorized change or loss of a specific piece of information can be catastrophic.

Accurately determining the resources that exist at this layer is not obvious and is especially difficult for large organizations that have multiple business units with different demands on those resources. Nevertheless, identifying your resources and the value to your company’s continued success should be the primary goal of any security manger.

The fact is that resources are money—to someone—and the disruption of that fragile yet complex relationship between business and information systems can wreak havoc. Understanding the resources and their role within the scope of daily business is crucial to supporting a successful penetration test. Although seemingly obvious, this is rarely considered a requirement for a successful test. This assumption could not be more wrong. You cannot gain true value from a penetration test without knowing what your digital assets are and their value to the organization. Without information from a risk analysis there is no feasible method for translating vulner- abilities into an actionable remediation plan. With the pressures of today’s economy and the constant demand for more efficiency in business, the likelihood that money will be invested to fix a security hole that cannot be financially justified is just wishful thinking.

CONTROL

The control layer is an opportunity to identify and group systems that manage access to resources. In a perfect world all identification, authentication, and authorization to resources would be controlled by a single system. Unfortunately, we’re not quite there yet (unless you read sales collateral for some identity management product vendors). Thanks to legacy systems, different application architectures, and different approaches to applying security controls, the control layer is typically made up of many diverse products.

The result of this scenario is a fragmented security architecture with controls existing at varying degrees of intensity and rarely centralized. The term “fragmented” may seem harsh, but many organizations have several types of authentication systems from many manufacturers and few have centralized management, much less provi- sioning.

The control layer represents an enormous challenge to nearly every company no matter the variety of applications and systems. Today there are many vendors providing identity management solutions that attempt to integrate most environments

to provide a common authentication system in addition to providing access controls in multiple heterogeneous environments. Therefore, we’re seeing a trend in many firms on focusing on the control layer to meet security demands in a distributed environment.

Penetration testing at some point will run head on into the control layer. Quite frankly, a good tester will find a way around by seeking other vulnerabilities that will get them through the proverbial back door. For example, when a tester is attempting to access a router he may perform a brute force attack directly against the router, basically entering password after password until the correct one is entered. This may seem archaic but it can be productive and there are many hacker utilities out there that will perform the attack on your behalf: just point and shoot.

An example of working around the control layer is finding a hole that allows access to control layer information. Let’s say an NT system is exposed to ports 137 and 139; under certain circumstances you could use tools like DumpSec to obtain the SAM (Security Account Manager) database. Once acquired, you can use offline attack tools against the database, such as L0pht Crack, to get the usernames and passwords, essentially bypassing the control of the targeted system.

The control layer can be considered the most complex and logically structured of all the layers. Therefore, it is no easy task to clearly identify and categorize the control layer within any security architecture, but understanding the layer is essential for establishing goals of the test and establishing the foundation for interpreting and absorbing the results.

PERIMETER

Perimeter security is the most obvious layer in the security model. Basically, it’s where your network stops and someone else’s begins. It can be your connection to the Internet, the segregation of certain system types, or business units with different security needs. Suffice it to say, the perimeter is usually easily identifiable. However, through the years the actual security that can be employed has come under fire. At the time this book was written, it has become generally accepted that firewalls (the workhorse of the perimeter) are a necessary attribute defining the perimeter.

The perimeter is much more than a firewall and there are other technologies that promote secure communications between trusted and not-so-trusted networks. Intru- sion detection and, most recently, intrusion prevention systems have provided another layer of security for the perimeter.

In short, the perimeter has to be labeled as the first line of defense in a suite of protective layers of security. This seems painfully obvious to anyone trained in military tactics, but it is also well known that many companies rely solely on their perimeter for security, fully aware their plan is flawed.

So what does this mean to a hacker—or a penetration tester? Many years ago when firewalls were fresh and changing dramatically to deal with the increasing volume and complexity of Internet threats, there was a practice called firewalking. People would spend their entire hacking or professional careers trying to get through firewalls for the simple purpose of proving it can be done. As each new bypass was discovered the vendors would come up with a solution, then a new bypass was

found, and so on. Ultimately, the dedication died off because the sophistication of hackers moved on to bigger and better attacks with greater potential for success and less for being detected. But the practice has become fundamental in attacks; everyone has a firewall (or should), and getting past a firewall is an essential skill. Now we’re seeing much of the same evolution in IDS with attackers using techniques to go undetected through the firewall and onto a network.

Many firewalls and IDSs are being tuned more regularly to thwart sophisticated attacks and as a tester and customer of a penetration test this has to be considered for effectiveness. In addition to the entire perimeter architecture and its inherent complexities discussed above, the act of the test can help greatly in establishing the elusive baseline for what should be categorized as an attack and which of those attacks demands attention. It is not uncommon for companies to invest in IDS and get inundated with alarms and start backing off on the sensitivity of the system, usually rendering IDS ineffective. Having a penetration test performed is a unique opportunity to tune perimeter security technology in ways not possible with any other method. This raises the question of why would a firm seeking a test not want the consultant performing the test to know IDS was present? Of course there may be circumstances where not knowing details would be desired, but that’s what this book is about—making those decisions logically and understanding the benefits and losses.

EXTENDED

The extended layer is how corporate security is projected out into the ether. The most basic example is customers going to Web sites that have a security policy defining how information collected from online transactions is used. VPNs for roaming users are another example of how corporate security influences information protection beyond the perimeter. Organizations are concerned with the security of their intellectual property, brand name, and various information assets that are accessed and shared in many ways with varying types of users.

Methods for sharing information beyond the perimeter include e-mail, PDAs, wireless messaging (cell phones, Blackberries), and direct access, such as VPNs and dial-up, all with their own forms of insecurity. For example, VPNs are widely considered to be secure and this is true when is comes to the transportation of information, exactly what VPNs were designed to accomplish, although the exposure of digital assets at the termination point outside the perimeter is under question. If a user, say the CFO, downloads the financial spreadsheets of the company onto her laptop while on the road using hotel high-speed access in the room, what is the implied security of that data? The layers of security realized at the corporate head- quarters are exponentially more secure than a lowly laptop.

Of course, extranets can fall within the extended layer of security as can remote users and customers. Communications with business partners and even comparators require a different application of security controls. Beyond technical solutions asso- ciated with extended security, organizations have to address legal issues, regulatory requirements, and Service Level Agreements (SLAs). In addition, the ability to identify users and systems of partners on both sides of the network plays a major

role in ensuring security measures are enacted in accordance with what is expected and agreed upon.

Extended networks, for many organizations, represent an enormous challenge with regard to security controls. Different partners have unique access requirements, want specific security policies in place, and have varying SLAs and legal obligations, all leading to security mayhem. Not only is this a challenge for organizations that have many partner or customer network communications, but a tester performing a penetration test is exposed to a wide range of imposed borders that are not clearly marked. The result is a virtual line that a hacker is not forced to acknowledge. The line is a thin border between the customer’s network and the partner’s, representing a potential to accidentally stumble into a system that was not within the scope of the engagement. This plays clearly into the hackers’ world: they don’t care about legal requirements, agreements, or the scope of some test; whatever meets their needs will be exploited.

There are occasions where the partner networks and communications are included in the scope of a penetration test, but the ramifications are immense. Without proper agreements to protect all parties involved the result could be disastrous.

So, the risks associated with extended networks are severalfold—security in the form of technology, access management, legal agreements, support issues, and so on—not to mention the complexities with which the tester is faced. Therefore, having detailed documentation about the architecture and environment is instrumental in the planning of a sound security model and provides the foundation for making decisions on the scope and scale of a penetration test.

5

Information