P. 1
Handbook for Computer Security Incident Response Teams (CSIRTs)

Handbook for Computer Security Incident Response Teams (CSIRTs)

|Views: 375|Likes:
Published by epocableoils

More info:

Published by: epocableoils on Apr 09, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Doing quality assurance checks on the real-life behavior of quality parameters is not enough.
Procedures must be in place to enforce quality when it is at risk. Then, escalation procedures
can be defined in the event that standard enforcement procedures fail, or if the quality system
itself proves inadequate. Finally, penalty and liability clauses can help enforce quality and at
the same time prevent the service provider from becoming excessively vulnerable to potential
lawsuits. These procedures and clauses can best be characterized as the “balances” for quality

In the demanding environment of a CSIRT, where staff stress levels are high and resources
are generally fragile and stretched, it is important to ensure that staff members are able to
accomplish their work to a high standard of quality without overwhelming them with
unnecessary hurdles. As such, there is a need to seek the right balance between procedures,
checking, and the ability to get the job done. Correctly written procedures will ensure a buffer
for human errors; any procedure not taking (human) error into account is flawed by design
(see Section 4.2.6, “Human Error Policy”).

Also it is advisable to give customers (the constituents) some method to enforce quality,
though this will normally be an indirect process. Not only does this “sell well,” but the best
quality judgment often comes from those who actually use (or suffer) the service. One
convenient way of granting constituents influence is by implementing measures such as user
groups and/or advisory boards. Admirable though these measures are, the most effective way
is probably by implementing penalty clauses: meaning the team has to pay or refund the
customer money if it performs below the expected level of service.

Note that it can also be the customer who fails to live up to his part of the deal. If that
continues to be the case and is grave enough (e.g., as grave as non-confidentiality), then
procedures should also be in place to discontinue or reduce support for such customers.

From the CSIRT staff’s perspective, escalation procedures are usually defined and an integral
part of the overall CSIRT processes. However, operational management should be able to
swiftly and effectively notify the higher levels of management when quality is truly at risk;
waiting for the monthly or quarterly report to have its impact is not sufficient. The routine
should include a decision on whether or not to notify customers of the problem and the
estimated time to fix it. The decision will depend on the agreed service levels and the direct
disturbance caused by the problem. Escalation can also take place when the quality system
itself fails and needs to be fixed.

Defining and advertising quality (but not assuring it) will cause the CSIRT to be liable in
most countries if service parameters are not met and a constituent claims damage as a result
of this failure. However, even in normal cases where a QA system is in place, including



checks and balances, in some countries (notably the U.S.) liability claims are still to be
expected. In some cases, adding liability clauses to QA will be useful, especially when
penalty clauses are also in place. Such clauses are best handled by legal experts; simply
denying responsibility for financial damage is not enough in most countries.

The key point: If you define quality, make sure you assure it. Prioritize your assurance tools:
education and awareness building are more effective tools than increasing pressure,
especially in the long run. If a workflow management software system is in place, it is
possible and advisable to integrate the regular enforcement and escalation procedures into
this system. This saves work over time and also creates the possibility of producing reports
on the use of these procedures.

Last but not least: Procedures and policies are not made for eternity, and thus must have
owners and/or maintainers, and a well-defined life cycle. All too often procedures are created
in the project phase—and once the project is over, the change control vanishes, but the
procedures are there to stay, out of control, until somebody really stumbles over them.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->