Why bother with policy and procedure?

Policies and procedures are important tools in the information security toolbox and they are most important when they apply to the IT department.

Policies and procedures are important tools in the information security toolbox and they are most important when they apply to the IT department. A major role of the information security department is to evaluate the vulnerabilities out in the wild, assess their threat level to the business and calculate an impact. This whole process is made quicker and easier with solid procedures in the IT department.

A good example is the practice, or lack of it in some cases, of changing the default passwords of network devices. Every network administrator will say they know to do it and will say they always do it, so why do information security audits still find devices with default passwords? One of the reasons is that the IT team lacks a network device configuration procedure, or if it does have one it's missing an important part, the log section.

A good procedure should meet the three goals of the acronym RRA. They should be repeatable, reportable and auditable.

A procedure that is repeatable should ensure two people with the same skill level produce the same results. In the case of default passwords they should both produce secure network devices. A repeatable procedure gives a lot of confidence to an audit team as it means that every product of a procedure is identical.

A reportable procedure requires a logging process. As the procedure is stepped through, a record of each action is kept, ideally electronically. This could be as simple as a Y to indicate the step was done, but could also be a more complex result, such as the result of a command or the name of a device.

This logging process gives the IS department its first level of threat analysis and answers questions such as how many, when and who. If a vulnerability alert comes into the department for a system configured in a particular way, they can quickly run a report that shows the number of devices threatened and scale their response.

The final goal, auditable, is the most important, especially when responding to an imminent threat. This goal takes the fact that the procedure is repeatable and reportable and assumes that verification and forecasting can be done using the logs.

Using the example of default passwords, if the IS department feels that some network devices have been badly configured, they can run a report that shows them how many devices of that type are on the network. If they check a random sample of these devices and find they are configured correctly, the assumption is that the others are.

If they find some with default passwords then an analysis of the procedure logs could reveal a pattern, a particular supplier, purchase date or network administrator.

There are tools that monitor the configuration of devices and security of software, but they should not be a replacement for solid procedures - even these tools need installing and configuring.

Procedures that meet the RRA goals are also of benefit to IT departments. They allow cross-skilling of team members, reduce fix times, as assumptions can be made about how system configuration, and improve installations times as the wheel does not need re-inventing every time.●

Read more on IT risk management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.