Structure found in process

By on
Structure found in process

As technically oriented security professionals we often don’t pursue structure in our testing. We simply use the same vulnerability scans and penetration tests we’ve been using for years — updated, of course, for the latest network nasties. Today, that simply is not enough.

Performing a simple penetration test says little or nothing about the general security health of the system. And, yet, the pen test (or "ethical hacking" — an oxymoron at best) often is the preferred way to determine the overall security of the enterprise. The answer is to develop a framework that creates a process within which you can execute appropriate methodologies. It is the process, not the methodology, that gives structure and rigor to security testing.

For example, consider a framework for testing to ISO 17799. There are 10 key areas in this standard, and if we want to do a comprehensive 17799 security evaluation of an enterprise we need to address each one. However, each key area describes a variety of different things that need to be evaluated in order to validate the key area. And, the test methodologies will be very different for each of the key areas and, perhaps, for each of the things to be tested that make up the key area.

We approach this very simply using an Excel spreadsheet. We set up the columns to represent the 10 key areas. Under each column (key area) we place the individual things in the key area that need to be tested. That means that there will be some number of cells in each column, each with some aspect of the key area. We call the columns "classes" and the cells "elements."

Now, we simply look at each element and decide what would constitute a validation of that element. If the element is, for example, "policy," how would we know that we had an appropriate policy to support the class? Once we answer that we can specify a test that answers the question.

There might be 100 elements, meaning that there might be 100 tests, but in each case we can answer two very important questions about the element we are testing: What do we expect to learn and how do we know when we’ve learned it.

The next time you need to do a security assessment, try setting up your own framework to meet your organization’s particular needs. It really is that simple.

Copyright © SC Magazine, US edition
Tags:

Most Read Articles

Log In

Username:
Password:
|  Forgot your password?