Page 1 of 2   next page »

In businesses throughout Europe and the United States, the segregation of IT security and system operations has become entrenched. Further confounding the rift is the pursuit of all things "compliance" (e.g., BS7799, ISO 17799, BASEL II, etc.). Industry analysts and vendors alike anticipate an extension of the compliance movement that focuses on the actual IT audit, which may further confound efforts to reunite IT operations under a common banner. As anxiety heightens over when the next "Big Problem" will hit the Internet, there are some things that systems administrator and C-level executives can do to fortify their IT business processes against that unseen storm that's looming just over the horizon.

Facing the reality that all Internet-connected systems are doorways of risk is not easy for IT administrators. But since more than 90% of all security risks exploit known system vulnerabilities according to Gartner, the controversy of "where to react" transforms into one of "failure to plan." Add to this the fact that organizations can no longer hide behind the "we didn't know what was happening" defense, and matters concerning "security risk management" become issues of "business contingency planning and accountability."

Umbrellas of Compliance
In recent years, many organizations have felt the heavy hand of standards and compliance knocking on their door - especially government agencies and the banking community. For American-based companies, much of the compliance push comes from the vague and elusive Sarbanes-Oxley (SOX) rules for security risk management and accounting. During 2005, while SOX continues to stand at the center of the compliance controversy - with its reach extending into European markets as a new potential benchmark - other frameworks and methodologies, such as ITIL and COSO/CobIT - along with ISO-based standards - are beginning to thunder through the world's business communities.

But what of the hype that surrounds all of these issues of compliance? The seasoned IT manager has heard this rumbling before - in the recent winds of the Y2K storm that passed by a half-decade ago.

Compliance standards are reaction-based initiatives. These new and often ambiguous standards further the confusion IT administrators and their bosses are forced to face as fears of penalties and possible prison time threaten to strike at will. And unfortunately, the IT security vendors are all too well-aware that buzzwords like compliance mean good business on which hundreds of IT security vendors build their marketing models.

Preparing for Foul Weather
Focusing on continued efforts to defend their expensive mission-critical infrastructures from the frequent storms of attacks and exploits, IT administrators are also frequently forced to decide which vendor's story about security makes the most sense (or cause the least amount of confusion). Determining which tools make the right sense to address security risks, while trying to maintain current operational standards of performance puts even more pressure on administrators. "Which anti-virus will best defend my system?" "Will these policy and assessment applications scale to my enterprise?" "Do these free spyware tools really work?" And "What do 'intrusion prevention' tools really prevent?" are all common questions for the bewildered sys admin.

So, which tools make the most sense? How much "security technology" do you really need? And where and when does the "prevention" actually begin?

IT administrators have raised time and again the fact that their concerns aren't necessarily about the rules themselves - rather, they are concerned with what further risks they might be facing by overlooking something while rapidly moving to meet compliance deadlines, or while reacting to specific incidents or reports of attacks.

That said, the following are three basic principles that systems administrators might find helpful when trying to break through the clouds:

1. Compliance is 90% process and 10% technology.
   Part of "process" is gaining a full understanding of what's happening "behind the scenes" before beginning to define any sort of policy, or react to any type of mandate.

   While there's a lot written about "intrusion prevention" (IPS) technology, in most cases an incident actually has to occur, or a violation of the defined policy must be recorded before tools claiming to be IPS become active. Realistically, even the "IPS" methodology is more reaction-oriented than preventive.

2. Defining an operational policy without first assessing the environment to which it is assigned is too late.
   More than 800 vendors are vying for one's IT security business. Most of them begin their security lifecycle models at the policy and move forward with varying degrees of success to defend some portion of that policy (assessment, event logging, perimeter defense, etc.). However, since these security policies are often segregated from the rest of the operational controls (i.e., a separate policy for everything else), most times the general market still looks at IT security tools as a way to react to a fraction of a bigger problem (such as a virus outbreak, the threat of denial of service, etc.).

   Administrators may find it easier to manage and enforce a policy after first learning as much as they can about their environment, its settings, and what is necessary to optimize that environment. In this case, knowledge before taking action is key in determining which decisions will have the best results. Administrators will find that gaining a better understanding of their environments will greatly simplify the need to react to a mandate or some other external control.

3. More than 90% of all the exploited vulnerabilities are based on known problems and poorly configured environments.
   In Las Vegas, those odds would make millionaires out of the homeless. When navigating through rough waters and high seas seafarers know that survival depends on maintaining a true course while ensuring watertight integrity throughout their infrastructure. Knowing that there's a nine-to-one ratio of where a problem is going to occur (and often with a three- to five-month lead time) plus the capability of gathering thousands of data points about an infrastructure's most intimate configuration settings moves the concept of "risk prevention" to the level of "security empowerment."

Page 1 of 2   next page »