May 22

All I Need to Know About Security Programs I Learned from the Pawn

By David Stern

We often focus our discussions on the pervasive inadequacies of information security programs in business, government, and education. Detracting factors include ignorance, lack of budget, and misplaced priorities of management. In this article, I would like to observe the other end of the spectrum.

Information security has become ubiquitous enough that many organizations now struggle with making security work for them. Organizations finally have hard-won elements of headcount, tools, process, and compliance drivers, but they continue to struggle with making it work. Trying to align best practices with internal business processes can sometimes become a greater problem for information security management than the vulnerabilities that they are trying to defend against.

For example, I have seen security organizations fight hard for, and win management support to put a vulnerability management program in place. The overall goal is to integrate a scanning tool with an internal remediation process to find and clean up security vulnerabilities. It can start off innocent, but soon the project is off track, developing hardening standards and risk matrices that map to ISO17799 and display on a custom-built web dashboard. While these are fantastic ideas, they keep the most basic goals from being achieved.

The challenge is simple; how do we strike a balance between growing a mature information security program and making security work day to day? To gain some perspective, I suggest that we look to chess. Ted Phelps used the same analogy in a wonderful 3-Part article in November 2006 (http://securitycatalyst.com/2006/11/16/guest-blogger-information-security-practice-as-a-game-of-chess-part-1-of-3/).

The foundation of the game is the chess board. The board can be compared to the business itself, with alternating colored boxes, some black and some white representing elements and challenges of the business. Rows and columns can be divisions or groups as well as levels of management and project silos. The capabilities of the pieces contrast nicely with the personality types found in management. Rooks can move straight up a vertical, taking a bottom up or a top down approach. Bishops can move diagonally across silos, touching upon varying verticals and management levels. Knights are the often coveted consultants, jumping between silos and levels in an attempt to address everyone and everything. Finally, King and Queen are two great examples of security leadership. The King is all-powerful, but chooses to stay within his local area, while the Queen moves all around.

These positions address the bigger picture. However, when an information security group with limited resources spends too much time building top heavy organizations, insecure applications and weak architectures slip through the cracks. It has been my experience that the pawn’s gradual, forward movement is what makes security work in the trenches. Assessment frameworks and complicated review processes work great, but sometimes, it is the basic approach that needs to be developed first. I have developed a simple, four step process that I use every day to manage the tidal wave of security decisions that flood my inbox.

Look at the Big Picture Literally. Do you have a diagram that shows the servers, network connections, ports, application flows, and host names of the system that you are trying to assess? You cannot make an informed risk assessment without understanding the moving parts. This step should be a show-stopper.

Architecture: Every organization has policies and rules (even if they are unwritten) that describe how systems or applications need to interact with the Enterprise architecture. If a DMZ exists, then an externally facing system must be placed there. If there are core functions such as Active Directory, LDAP, TACACS, or RADIUS, a system should not use an internal, proprietary database for credential storage. If the system is being developed outside of common design practices, the business drivers must be clearly articulated and signed off by management.

Data Sensitivity: If the system interacts with or stores any personally identifiable information (PII) or personal health information (PHI), then all intersystem communications must be encrypted. Period. Modern application delivery platforms support SSL encapsulation, which makes implementation of this requirement a no-brainer.

Vulnerability Scans: While vulnerability scanners cannot provide in-depth views of system security, they are capable of expediently uncovering the most common security issues. An application with verified HIGH or MEDIUM severity issues cannot move into production. If an organization has application security scanning tools such as Appscan from Watchfire, this should also be included as a prerequisite.

Developing a successful information security program is like learning to ride a bike. Every kid starts out with training wheels. They keep the bike standing, while the child learns the basic functions. Most importantly, they let the child go places and gain their confidence. At some point a parent removes the training wheels and starts the more complicated ordeal of learning balance. Without the training wheels, there wouldn’t be many riders. Similarly, developing a comprehensive security program is the ultimate goal for any security practitioner, but during the course of this development, day to day security decisions must still be made.


Tags


You may also like

Are you using frameworks properly?

Leadership and communication are actually layers, not levels

Comments are closed.
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!