Payment Card Industry: Compliance Overview

The Payment Card Industry (PCI) has decided that organizations that transmit, store, or process credit card data, in particular, the Primary Account Number (PAN), be compliant with the PCI Data Security Standard (PCI-DSS). Once you start using payment card data, the compliance is mandatory, all encompassing, and immediate.

The mandate for PCI-DSS compliance has been agreed to by the following card brands: Visa, MasterCard, American Express, JCB International, and Discover Financial Services. Another little item is that there are other protection requirements for ancillary data in the PCI-DSS. The PCI-DSS 1.1 standard can be found at the following URL: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf.

It is important to note that if a company is not compliant, they risk losing their ability to process credit card payments and they may also be fined. It can’t be overstated that from our understanding compliance is mandatory, all encompassing, immediate, and perpetual regardless of how big or small or they type of user you are. Meaning you have to do it, it must be 100%, it starts as soon as you start using cardholder data, and it lasts until the last bit of cardholder data is no longer used. Many companies don’t seem to get how deep and lasting the claws of PCI-DSS are.

PCI requires that anyone under the PCI-DSS prove their compliance via annual assessments. There are four different levels of assessments that can be performed. Which level an organization falls under is roughly determined by how many credit card transactions a company performs coupled with the total value of these transactions as well as the type of entity (i.e., all service providers must pass a Level 1 assessment). Each card brand, not surprisingly, has its own definition for each level: however, they have been merging over time.

It should be noted that many organizations who are required to perform the Annual Self-Assessment Questionnaire often use a third party consulting firm, who specializes in these kinds of assessments, to help them perform the audit to ensure completeness . Failure to pass an assessment may result in having a companies ability to use the credit card(s) revoked.

The process to become and maintain the QSA certification is non-trivial, and arguably one of the most stringent in the industry. PCI is doing their best to ensure the organizations and people doing the assessment work are qualified and able to deliver a quality product.

2007 in ReviewBy Jonathan Gossels

Every year at this time we share with clients and selected industry leaders the key trends we’ve been seeing over the course of the year. Our conclusions are distilled from a combination of the types of projects we’ve completed and a reflection on the discussions we’ve had with clients and prospective clients about their security needs and concerns.

Overarching Trends

IT Security in the public view

IT Security awareness among the general public has never been higher. The highly visible TJX debacle is illustrative, but hardly an isolated incident. Almost every week sees the announcement that some major corporation or public entity has been breached or has lost control over private data. What is common in nearly every case is that they are woefully unprepared to handle a security incident. They typically have no real plan in place to categorize an incident (high, medium, or low business impact), manage the technical response including determining the extent of the breach, and manage the business response including notifying customers and handling investor and public relations.

Compliance, compliance, compliance and standards based assessments

2007 was a watershed for compliance. It is amazing how fast compliance requirements have come to drive security programs. Just a few years ago compliance was the tail of the dog. For many organizations, compliance now drives the security program.

Take HIPPA for example - it finally happened. Atlanta’s Piedmont Hospital became the poster child for Health Insurance Portability and Accountability Act enforcement when it was audited by Health and Human Services earlier this year. It has been clear to even casual observers that the health care industry has largely ignored the Act’s Privacy and Security Rules regarding the protection of Electronic Protected Health Information (EPHI). This long overdue action has health care providers and the organizations that service them scrambling. We’ve not seen this level of interest in HIPAA assessments since the law was first enacted.

Similarly, merchants are far more security conscious. They have to be. The contractual structure between card acquirers, banks, and the payment card companies rest much of the liability for security problems on the merchants. Smaller merchants need to complete an Annual Self Assessment Questionnaire (self assessing for most small businesses is about as practical as giving yourself an annual physical). Level one merchants need to conduct an annual PCI Data Security Standard (DSS) on site review. For this reason, SystemExperts became a Qualified Security Assessor Company (QSAC) this year and nearly all of our staff Qualified Security Assessors (QSA). If you are not familiar with the PCI Security Standards Council's QSA qualification requirements, they are exacting and detailed.

ISO 17799/27002 compliance continues to grow in importance. It provides organizations with an objective measure of their security stance, enables them to easily communicate the extent and effectiveness of their overall security program, and is recognized and accepted as a high hurdle by prospective customers and business partners. Interestingly, we are finding that we often use the table of contents from the standard as a gauge of completeness even when we are not performing an ISO 17799/27002 review per se. For example, we recently completed a combined ASP/HIPAA review for a company that provides on line medical record management. At the end of several days of detailed discussion, I found myself looking over the ISO table of contents to make sure we hadn’t inadvertently omitted a critical topic.

The more compliance reviews we perform, the more confirmed we become of the fact that good security is good security. These standards are fundamentally consistent in the policies and best practices that they require.

Identity management

With the major security standards and regulations requiring close management of access controls, it is not surprising that identity management is such an important topic. Now, managing user accounts and privileges is nothing new. Every one has been dealing with it since the very beginning of the computer era. What is new - and this is where the identity management products come in – is the recognition of the importance of the management work flow. Specifically, work flow approval process that provides auditable controls over authorization, creation, review, and disablement of user accounts.

Application level vulnerabilities

In past years I’ve noted that web applications continue to be the fastest growing exploit area. That trend is only accelerating. I’m beginning to sound like a broken record on this subject. Traditional web development methodologies are failing to protect sensitive data. Many of these applications are fundamentally flawed in both their design and their implementation. We all know the old software development joke about good, fast, cheap – pick any two. It doesn’t have to apply in this case. It doesn’t take longer or cost more to design and implement an effective authentication mechanism or to make valid assumptions about session management. What is needed is security consciousness or security staff participation early in the application’s lifecycle.

Technology

Removable Media: The explosive innovation that has occurred in the area of removable media with devices like USB flash drives and iPods that can hold large amounts of unstructured data poses a real security threat to many organizations. On the one hand, the uncontrolled use of these devices puts an organization’s intellectual property at risk. Rouge employees can walk off with analytics, client lists, and trade secrets and never be detected. On the other hand, indiscriminate use of these devices violates basic system hygiene practices and might lead to the introduction of a damaging virus or worm into the environment. Many organizations have reacted (largely unsuccessfully) by adopting policies than ban their use. Others try to manage the risk by authorizing designated staff members and systems and adopting a procedure for checking the drives for malware.

Virtualization: Many organizations are exploring the use of virtualization technology (products like VMWare) and are just beginning to wrestle with security implications. Security people tend to like to see application environments physically and logically self contained so we can turn the security knobs appropriately for each one. Properly securing the future highly virtualized environments will be challenging all of us for years to come.

Security Infrastructure: In the same way that corporate and departmental web sites burst onto the scene about ten years ago, suddenly SharePoint servers to store security documents and Wikis for policies and procedures are everywhere. Simply, these are great tools for capturing institutional knowledge and reducing the time and cost of documenting key processes. The Wiki in particular directly addresses a chronic security problem; documentation never keeps pace with actual practices or policies.

Identity Theft Blog Entry By Jonathan Gossels

Where is the outrage? Security incompetence is putting millions of people at risk for identity theft and there seems to be no accountability at all.

Week after week we see major companies losing control of their customers’ and employees’ private data. This past few weeks saw AT&T notifying present and past employees (I’m aware of one notified person who hasn’t been an employee for eight years!) that a laptop containing their Social Security Numbers, compensation, and home addresses was stolen. Administaff, an HR outsourcing firm, announced virtually the same thing. These instances demonstrate how vulnerable each of us is to identity theft, even though as security professionals we take appropriate measures to safeguard our private data.

I raise these two examples because they share several common characteristics.

In both cases, the company allowed a poorly configured laptop, one that did not enforce the company’s nominal security policy of encrypting confidential data, to be used for processing a large volume of confidential personnel data..

It’s a sad fact that given their size and portability, laptops are often lost and stolen. We can’t prevent that but we can manage how we configure these systems (e.g., requiring encryption if the system handles any sensitive data) and what we prohibit as unacceptable use to reduce these inherent risks.

It is all too common for organizations to extract data sets that contain more sensitive information than is actually needed to accomplish a particular goal. Few organizations have policies and procedures in place to ensure that this unnecessary data is scrubbed before the data set is downloaded or processed. It is far easier to prevent data leakage at the source, rather than the endpoint.

In both cases, the companies failed to keep physical control over laptops that they knew contained extensive confidential information. This is a red flag for poor security awareness and training. The concentrated personal data should have been removed after its use and the laptops should have been properly locked up when not in use.

The final similarity is that both companies acknowledged that they had put employees at a substantial risk of having their identities stolen. Both chose to ameliorate employee/customer concerns about Identity Theft by providing affected people with one year of an Equifax credit monitoring service. Interestingly, the second page of both the AT&T and Administaff letter to employees and customers is identical. That raises an interesting inference; the frequency of these types of breaches is so high that Equifax has standard form letters ready to go and is making a business out of closing the barn door.

Why is this so hard?

We all know that there is a lot of pressure on companies to offer new or upgraded services over the Internet. We also know that a lot of this pressure funnels to the development groups that are tasked with quickly (usually, too quickly) releasing functionality that the masses can consume. The fact is, exploiting security vulnerabilities in web facing applications is one of the most common ways in which hackers get access to data or systems that they shouldn’t and is also one of the leading risk areas for identity theft.

A cornerstone of almost any type of web application is input: the simple act of asking the user to enter information for the web application to process. The problem is that too many web applications still fail to validate incoming data. It is one of the leading causes of web application compromise. Why is this obvious requirement routinely ignored?

There are at least three places that input validation can occur:

- at the user’s browser as part of client-side HTML code
(e.g., javascript),
- at the web server
- in the web application itself.

Each of these components has an opportunity to evaluate the data that was supplied for a particular field and then determine if it should be rejected or sent on.

From a security perspective, we would like to see input validated in all three places. In addition, we would like to see the server perform output validation before sending data back to the client. Why do we need to check in all of these components? You need to check in all places because you don’t know where corrupt or malicious data may come from.

To illustrate, you can bypass client-side validation by using a web proxy. You can bypass the server by making calls directly to the web application functions. You can even bypass the web application itself, if you have direct access to the database (or file or data store) on the server. The bottom line is there are a number of places that the data can be corrupted and performing input validation in multiple places ensures that accidental or malicious data is not processed.

Most application developers understand the characteristics of acceptable input. It should be a requirement that those characteristics are always validated for each field – that is, do not assume that you can trust the component that just handed you the data.

Should a first name field allow the “<” or “%” characters? Should a monetary number field allow alphabetic or special characters? Should a credit card or social security field allow escaped command sequences? The answer, of course, to all of these is no.

The design philosophy has to be:

- Validate input data wherever possible
- Pay as much attention to what’s going into the web application as what’s coming out of it

Input Validation; it’s not sexy. It is not an interesting technological challenge. It is just a simple best practice that makes your web environment much more secure.

New OWASP Top 10 Web Application List

The Open Web Application Security Project (OWASP) has updated their Top 10 security issues that plague (Internet) web applications. The original version came out in 2004 and through the hard efforts of many members and non members of the OWASP community, the list has been updated to be more consistent as well as more reflective of the current state of web application vulnerabilities.

Following are both the new and old lists.

New 2007 List
A1 - XSS
A2 - Injection Flaws
A3 - Malicious File Execution
(e.g., code that accepts file: PHP, XML, attach)
A4 - Insecure Direct Object References
(e.g., URL or parameter manipulation)
A5 - Cross Site Request Forgery
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage (e.g., poor cookie entropy)
A9 - Insecure Communication
A10 - Failure to Restrict URL Access

New 2007 List: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf

Old 2004 List
A1 - Unvalidated Input
A2 - Broken Access Control
A3 - Broken Authencation and Session Management
A4 - XSS
A5 - Buffer Overflows
A6 - Injection Flaws
A7 - Improper Error Handling
A8 - Insecure Storage
A9 - Denial of Service
A10 - Insecure Configuration Management

The new list is certainly better.

Personally, however, I think getting rid of both Unvalidated Input and Insecure Configuration Management is a mistake as I think they continue to be important web application issues as opposed to Cross Site Request Forgery and Insecure Cryptographic Storage. I think those issues are important, but not worthy of the Top 10.

In addition, I also think that Broken Access Control is far more prevalent and more important than Injection Flaws. I mostly believe that because most injection and XSS issues, as it turns out, can be to a large degree addressed with both input (data flowing from the client to the server) and output (data flowing from the server to the client) filtering.

Embracing PCI for no other reason than... By Pete McLaughlin

One of my least favorite terms in the business world today is that all too tenuous ‘industry best practices for security.’ What does that really mean? Does ‘industry’ mean the ‘security industry’ or does it mean, for example, the ‘financial services industry?’ So let’s say it refers to the ‘financial services industry.’ Let’s go one step beyond that, does it mean the ‘regional bank industry’ or the ‘mutual fund industry’ or the ‘on-line financial search engine industry?’

It’s business speak, it’s flagrantly overused, and I have grown to despise it. We have let it slip into our everyday vernacular without protest or guilt. And the most disgusting part of it … even though I am far from a fan of the term, I use it. What a hypocrite...

So, I embrace the momentum that the Payment Card Industry standard is gaining. It provides structure to that nebulous term ‘industry standard’ because it does two key things:

- It provides detailed information about what exactly a company needs to do to comply with the standard; and
- It clearly states which companies need to comply (any organization storing, processing, or transmitting a Primary Account Number).

So I say embrace standards such as this one, particularly one backed by competitors that have banded together to solve a problem for an enormous consumer-base. Sure, it has it weaknesses and cynics can snarf at it. But, at the end of the day, it has merit if for no other reason than VISA, American Express, Discover, and MasterCard say so. And if it provides us with something more tangible than ‘industry best practices’ to benchmark our environments against, then I say AMEN brother.

The Power of a Trusted RelationshipBy Pete McLaughlin

Many small companies have never engaged a third party to conduct a security review of any sort. The reasons for not doing so range from being too busy, to not budgeting for such an assessment, to not knowing where to start in the vendor selection process, and everything in between. However, some day and some day soon, it will become a high priority and inevitably, those organizations will look to an outside firm for help.

For those companies a rare opportunity abounds: a fresh start.

A small company’s first security assessment is an ideal opportunity to establish a trusted relationship with an outside firm. It is critical to tightly define the scope of the first review and clearly state the business objectives. Doing so will allow small companies to contract with a third party to perform a short and inexpensive engagement with clear objectives and limit the burden placed on already stretched personnel. It is comparable, on a personal level, to engaging a skilled accountant at an established firm for the first time to prepare your family’s taxes. Getting started and establishing a relationship, even at the simplest level, will pay dividends in the future when you will need to leverage the knowledge and experience of an expert or team of experts (e.g. estate planning, being audited, etc).

A security assessment (say, for example, a penetration test of a few IP addresses) may only take a day or two. But, by the end of the vendor selection process and even the shortest of engagements, you will be able to answer some key questions about the firm you selected including:

- Do they offer services catering to small companies like ours?
- Are the consultants as nimble as we are?
- Do they understand our business model and risk context?
- Are they willing to over-deliver?
- Heck – do we like them?

If you answer yes to all of these questions after your first engagement, then you are off to a good start with a new valuable relationship. Securing your environment from multiple threat vectors is critical to the success of your company. Having a trusted outside firm to help you do so as you grow your business is a powerful tool.

War Dialing: The Forgotten Security Threat

The absolute root of hacking tools, techniques, and software is something called War Dialing: that is, dialing a phone number and trying to exploit the service on the other end. In the early 90’s, a small community of people developed software that would automatically scan phone numbers and categorize the answering system types. These programs run unattended and dial phone numbers and look for recognized devices to attach to. When the program is finished, all the attacker has to do is look at the results and dial the appropriate numbers again, and attempt to gain access to the system or its services.

The goal of those initial dialing efforts was usually to get long distance phone calls for free. At this point of time over 15 years later, War Dialing is still an attractive exploit but for a different reason. Now, it is often used as one of the most successful ways to break into a network. Why? There are lots of sophisticated systems and services that live at the end of a phone line such as network printers, routers, gateways, firewalls, power systems, and desktop systems. In addition, at most companies there are no devices to detect, monitor, or log that a War Dialing effort is occurring and modem-based services are frequently not using any type of encryption, they often do not require any authentication other than dialing the number, and the actions are almost never logged. From a hackers’ point of view, the beautiful thing about War Dialing is that it usually completely bypasses every single security measure that has been put in place for the wired or wireless network.

Your own administrators and vendor support staff often use modems to remotely manage or monitor important services and this type of remote servicing has become increasingly prevalent in this era of outsourcing of IT services.

The bottom line is that most organizations do not perform telephony assessments as part of the security or auditing programs and they should since there are usually many important systems and services that are available at the end of a phone line.

Web Application Identity Theft

Almost every company has some type of Web presence - ranging from simple brochure sites to sophisticated transaction-oriented applications - and therefore has some type of conduit from the general Internet to company resources and or company data.

The fact is that identity theft and access to confidential or private information through Web applications is one of the fastest-growing exploits on the Internet. The reason is that most Web applications have not been developed with a keen eye toward the hostile Internet environment and are not using appropriately secure methods of authentication and authorization.

Everybody allows a variety of Web protocols and programs directly through their firewalls and routers. Because you cannot stop this traffic from coming through your barrier systems, you have to do an outstanding job of creating an environment that detects malicious attempts that you cannot prevent and prevents as many different types of exploits as possible.

To do this, several areas need to be addressed, each in its own way!

• The host that the Web services run on.
  
• The supporting Web server infrastructure.
  
• The Web application itself.
  

It is important to understand that these components are independent of each other and that effective Web security depends on getting each of them right. Failure of one part could may mean failure of the system as a whole.

For example, a company may have done a good job deploying a minimally configured and well-hardened host and have a well-configured Web server, but if it has a Web application designed using poor assumptions about authentication, authorization or session management, the system as a whole is vulnerable.

To achieve a robust Web presence, you need to look at each of these three areas and perform the testing and remediation measures each requires. Either that, or let some determined intruder or hacker do it for you!

ISO 2700X: A Cornerstone of Security By Jonathan G. Gossels

For years, organizations have been searching for an objective benchmark to measure the security of potential business partners and to distinguish the security-quality of their own services. While not perfect, ISO 17799 emerged as the standard of choice because it overcame many of the critical deficiencies of SAS 70. Specifically, it provided a comprehensive set of security-related topics and an objective means of measuring compliance.

Building on that success and following the same approach it used with the ISO 900X Quality Assurance standards and ISO 1400X Environmental Management standards, the International Organization for Standardization (ISO) has reserved the 27000 numbering range for a series Information Security Standards. The initial standards are:

- ISO 27000 contains technical definitions used throughout the 2700X series.
- ISO 27001 is a specification for an Information Security Management System (ISMS). ISO 27001:2005 is a re-labeling of BS 7799 part 2. This is the formal standard used for certifying Information Security Management Systems. Its focus is evaluation process rather than content
- ISO 27002 is a re-labeling of ISO 17799, which was originally BS 7799 part 1. This standard contains a Code of Practice consisting of a comprehensive set of information security control objectives and a menu of best-practice security controls.
- ISO 27004 is the number reserved for a future standard covering information security management measurement and metrics.
- ISO 27005 is the number reserved for a future standard covering information security risk management.

To achieve certification, an organization's ISMS must be audited by an assessor who works for a Certification Body. A Certification Body must have been accredited by the National Accreditation Body for the relevant geography. The certification process requires clear segregation of duties in that the organization performing the certification must not have been involved in providing either con-sulting or training.

History has shown that far more organizations used ISO 17799 as a framework for conducting comprehensive security assessments aimed at improving the security and controls of their IT infrastructure rather than for the specific purpose of certification. It is impor-tant to recognize that these standards have value well beyond certification.

Unless there is a clear business reason -- such as customers or partners demanding certification to do business – most or-ganizations would be better served thinking in terms of compliance with ISO 27002 rather than certification to ISO 27001.

Because of the expense, without a clear business driver, there is little incremental value in spending those formal certification dollars. In most cases, having a reputable security firm attest that an organization is “substantially compliant” is more than sufficient.

Just as with ISO 9000, the marketplace is not homogenous. Certain vertical markets such as aerospace or certain supply chains may latch on the ISO 27001 certification as a required fact of life.

The decision to certify or comply is more than one of cost; the two standards measure different things. ISO 27001 assesses whether an organization follows a coarse-grained set of processes that are integral to maintaining the security of an enterprise. Certification assumes that if these processes are in place that effective security automatically follows.

In contrast, 27002 describes a comprehensive set of concrete and fine-grained practices with which an enterprise can be compared.

Bare in mind that both of these standards need to be interpreted within a specific business context taking into account the organiza-tion’s technology, its attractiveness as a target, and its bushiness risk.

The ISO 27001 and ISO 27002 standards are gaining attention for being practical mechanisms for both assessing and asserting good security practices.

Securing Service Oriented Architecture:Ready, Shoot, AimBy Jonathan G. Gossels

It is almost impossible to pick up an IT technical publication these days without seeing articles touting the virtues of Service Oriented Architecture (SOA). SOA offers the promise of reduced development cost and faster time to market primarily through code reuse. The critical topic that is lost in all of this is security – and securing a SOA environment is challenging.

The term Service Oriented Architecture is frequently bandied about, but it is not broadly understood. A recent survey noted that approximately 50% of IT professionals professed to have some familiarity with the term. Yet, those same respondents overwhelmingly failed to associate the defining attribute, code reuse, with the term. Those findings simply underline that we are in the very early stages of a major technological change.

Now is the time for security professionals to step up and lead their organizations in finding creative solutions to a wide range of problems including:

- The size of applications shrinks in proportion to the number of services available. In order to accomplish the maximum code reuse, services must be designed to be as general as possible. This pressure to produce general purpose services conflicts with application-specific security requirements.

- There is a well established body of best practices for maintaining a secure processing environment. Formal change control procedures are used when new software or systems are added. Only specifically authorized personnel are allowed to implement changes. The opposite is the norm (and vision) for many SOAs.

- In many implementations of SOAs using SOAP and MQ Series, by default, no authentication is performed. However, even if a developer enables Web Services Security, determining what authentication means in the loosely coupled SOA environment is still required.

- One of the problems organizations face with SOAs is that they provide no end-to-end security. In larger SOAs, software infrastructure is used to create a bus processing model that aids in dynamically connecting, mediating and controlling services and their interactions. The beauty (and danger) of this model is that each of the components in the chain is (relatively) unaware of the processing that occurs in the other components; there is no concept of end-to-end control over a SOA processing path.

- It is not uncommon for organizations deploying SOAs to begin by selecting popular infrastructure products. While this approach maximizes application integration, it eliminates business requirements and information security requirements from the selection process – this is a mistake. Often, these requirements cannot reasonably be retrofitted into the environment.

Service Oriented Architectures are a new ballgame and require creative solutions to a wide range of problems. The most important of these solutions are architectural in nature – common infrastructure or replicated infrastructures by security level, how to accomplish mutual authentication, how to manage keys, how components are added to the environment, and who controls data. Our challenge over the next several years is to develop practical solutions to the inherent security problems of SOAs to enable our organizations to reap the benefits of code reuse, shorter time to market, and any-to-any processing interaction. As security professionals, we need to provide leadership now.

Hacking Insight

Mentioning the word hacker usually elicits a strong response, no matter who you talk to. The Chief Security Officer and virtually anybody on the street will each have something specific to say. The problem with this word is that it detracts from the real issue of making Internet resources more secure because of the emotional baggage tied to that term.

In the real world, it doesn’t matter where an attack is coming from or who is performing it. It might be some teenage misfit with nothing better to do than wreaking havoc on your systems as a way of proving their skills to the world – a common hacker profile. It’s becoming increasingly common, however, that the source of your problems is well funded (such as organized crime or a hostile foreign government), is staffed with security professionals, and is willing to take their time.

What you don’t know could hurt you:

• Most of the work required to successfully hack into your systems does not require actually touching the target systems

• Most of the education you need to successful hack into your systems only requires simple Internet searching

It is best to get past the emotional aspects of the label of the attacker and use a more appropriate term: a determined intruder. Breaking into your systems and services is a project that requires the same methodical approach as any other important business project you take on. Let’s take a look at how a determined intruder takes on the task of getting inappropriate access to your Internet based resources.

For a determined intruder, the four parts of the attack process are as follows:

Part 1: Reconnaissance: Send packets to the target systems and learn how they are setup and what they are running

Part 2: Catalogue & Prioritize: Take the reconnaissance data and determine what is worth researching in more depth

Part 3: Research: Review available documentation, reports, release notes, configuration descriptions, specifications and do online research on who else has dealt with the specific component including known exploits or vulnerabilities

Part 4: Test & Validate: Use the data, techniques, and tools discovered during the research and try to an actual attack or to learn more about the profile of the site

One of the interesting observations about the above methodology is that only the first and fourth steps require sending data to the target site. The second and third steps are “offline” in the sense that the work is done mostly over the Internet (e.g., Google searches and follow-up), but does not include sending data to the target site. What is especially interesting is that historical evidence shows that most of the work in an attack is indeed in these second and third steps. To state what is obvious and yet many people do not appreciate, most of the work performed in a successful attack can not be detected, thwarted, or stopped by you because it is being done on systems that you do not own!

Probably the other most underappreciated fact about attacks is that there is a wealth of information available to anybody willing to invest a little time browsing the Internet. The information is readily available, compelling, and often provides incredibly detailed information that is useful in an attack.

Whether you do it yourself or hire reputable security professionals, all organizations should assume that their Internet resources will at some point become the target of a determined intruder. There are many different types of projects that can assess risk (architectural reviews, security audits or assessments, code reviews) but certainly one of the obvious methods is to simply to proactively do the same thing that a determined intruder would do and profile and test your own systems. It is important to get past the emotional baggage of the word hacker, and focus more methodically on the process of decreasing the risk of your key assets.

Public Domain Tools

There are literally thousands of tools available to help you evaluate, analyze, or manipulate resources in your IT environment. Some do protocol manipulation or are protocol analyzers (to look at or "sniff" traffic on the network) and some focus on your critical network servers like the name service or the Web server. Some of the tools check the integrity of the files on your systems and some check the integrity of a particular database or special operating system file (like the Windows Registry). Some tools are security- specific like deciphering passwords, encrypting or decrypting files, and doing vulnerability assessments. Also, there are a plethora of tools for all varieties of intrusion detection activities.

Some of these tools are for Windows environments, some for various flavors of UNIX, and some are for both. Some are for your wired environment and others are for your wireless infrastructure.

There are many variables to consider when looking at tools, but often, the most important characteristic is cost; some require license fees and others are free. Most of the free tools are part of what is called the Public Domain (also Shareware and Freeware) and are available from a large number of places on the Internet.

Many organizations don't allow the use Public Domain tools because unlike a commercial product, professional support services are not available and the tools don't have predictable upgrades for problems or new features. However, the overarching reason that most organizations don't allow the use of Public Domain tools is because they don't trust them. They fear that these unvetted tools may create or inject more problems than they purport to solve.

This is a huge problem because while there are many helpful and useful commercial products, a significant number of the vital programs that should be a part of every IT staff's toolkit are indeed free, Public Domain tools. In addition, historically, the Public Domain tool writers tend to be much quicker to respond to new technologies and have also been the leaders in new network and security ideas. If the hackers and determined intruders are using them and therefore one step ahead on everybody else, why shouldn't legitimate security professionals use them as well?

What's needed is some organization or consortium to step up and take responsibility for offering clean, vetted, and signed copies of these programs at a nominal cost so they can be used with confidence and without breaking internal security policy.

Security Skill Certificates

The Internet community needs to have security skill certifications that are meaningful. Right now, there are a hodgepodge of organizations that offer certifications in a wide variety of areas. Last year there were at least 150 vendor-neutral information security certifications and 20 vendor-sponsored or vendor-specific security certifications.

The fact is, most of these certifications are for entry level skills or are product specific. Don’t get me wrong - we certainly need credentials that demonstrate that someone is competent for the same reason that we hire licensed plumbers or electricians.

What we’re missing is a uniform EXPERT level credential akin to the MD for physicians. And just like in medicine, there should be specialist security certifications to designate significant knowledge beyond the baseline MD-equivalent.

In the security industry right now, there is no way to tell if you're getting a real expert or not.