Slashdot Mirror


Do We Need Regular IT Security Fire Drills?

An anonymous reader writes: This article argues that organizations need to move beyond focusing purely on the prevention of security incidents, and start to concentrate on what they will do when an incident occurs. IT security "fire drills," supported by executive management should be conducted regularly in organizations, in order to understand the appropriate course of action in advance of a security breach. This includes recovering evidence, identifying and resolving the root cause of the incident (not just the symptoms), and undertaking a forensic investigation.

3 of 124 comments (clear)

  1. Nope by sexconker · · Score: 4, Interesting

    Just like real fire drills, they're pretty pointless and no one takes them seriously because there's no fire.
    So you either have a fruitless exercise that costs money because of all the interruptions, or you have a semi-fruitful exercise that costs a lot of money because of the extended interruptions caused by trying to simulate a real event.

    The latter will marginally improve the response to an actual incident. Neither will fly, because they cost money and aren't mandated by law.

  2. Re:Pro- vs Re- by epyT-R · · Score: 3, Interesting

    I've seen several departments that made reactive approaches a policy. Proactive employees were criticized and repeat offenders let go. I don't get it at all. It costs more money and makes more work and stress. Who wants to keep patching the same problem over and over?

  3. These are simply audits by cwills · · Score: 3, Interesting

    What you described is nothing more then a full security / disaster recovery audit. If your data center (and management) is really serious about it the company will need to invest both time and money to protect itself.

    • Create your security policies. This has to be directed from a management level that can put teeth into it, as well as people who understand what the real risks to the business are. Company lawyers and people with business continuity experience might be involved depending on the consequences of what a data breach or disaster might do to the business.
      • determine what risks your business has
      • determine what needs to be done to mitigate the identified risks
      • determine what needs to be logged in order to allow forensic analysis (assume that the compromised system(s) logs themselves may have been corrupted as part of the breach)
    • Make sure that the policies do not break the business. Also realize that security policies may require some processes to change.
    • Understand that implementing security polices can be expensive.
    • Employee education is a necessary step. Make sure employees understand what is being asked of them, and make sure that they understand what the policies are.
    • Ensure that you have a designated security focal point.
    • You will probably need an exception process. Make sure that any exceptions are documented with management, what is being done to mitigate any risks the exception have exposed and how long the exception needs to be in place.

    Once you have your policies in place and everyone has "signed off" that they are in compliance, you can start with the auditing.

    • Have some level of auditing where it's a "friendly" review of the systems.
    • Audits should not instill fear, however there may need to be real consequences for negligent audit failures (depending on the business and type of data).
    • Depending on the business, you may want to have an independent auditing group come in and review your systems and policies
    • During an audit, system or process owners should only be held accountable to what is in the security policies. If the audit finds issues that are outside the policies, then management and the policy owner needs to respond.

    One additional comment, depending on the size of the organization, there may be a security group. If there is one, then it should be the responsibility of this group to perform any security monitoring or testing. Individuals outside the group should not be performing their own security or intrusion testing of systems that they are not directly responsible for. If a vulnerability is uncovered, it should be documented and reported to the security focal point and management.