Before You Take Off, Get Up To Speed on These Six Precursors to Incident Response

It seems most advice on setting up a Security Operations Center (SOC), or creating a Computer Security Incident Response Team (CSIRT), focuses on people, technology or processes. Unfortunately, such advice may also include doing so at full speed, from the starting line, without taking into consideration what is needed for the long haul. The truth is that with SOC and CSIRT planning, there is a lot of behind the scenes prep that must take place before your team even starts the engine. If you don’t, your SOC/CSIRT might stall or even come to a screeching halt at the very worst moment, becoming a major distraction to your team. This can eat up limited resources and delay response. So before you go the distance, we suggest you get up to speed on the six precursors to incident response that can help drive a stronger return on your team’s investment.

Systems of Record

Systems of Record are critical to driving remediation and are a necessity for effective incident response. But if you are running it from a spreadsheet, you’re probably lagging behind. Finding a system that is impacted may seem like the last step in an investigation. But in reality, it may need to be the first, especially in a large enterprise. This might include uncovering owners, services and applications as well as identifying who can introduce changes and what impact they may have on production. Unfortunately, in organizations without good, automatically updated and accurate systems of record, remediation of an impacted system may never happen because the incident responder gives up and moves on to the next issue.

Standardization

Standardization helps you quickly identify host attributes and a host owner. By standardizing platforms, applications and security controls you can better detect aberrations that might lead to riskier situations. Even though networks and their acceptable use policies can vary dramatically from organization to organization, you can still standardize some aspects to maximize your efficiency and protection:

Host standardization

• Using a standard host naming convention so light variations, mistakes or completely non-standard hostnames raise a red flag.
• Standardizing on common software versions/operating systems to reduce support needs, simplify patching and allow teams deeper understanding of exposure/risk.

Network standardization

• Using consistent network topologies and compatible systems with highly organized access control and documentation.
• Ensure consistent software versions and feature management.
• Use repeatable designs and architectures to simplify management.

Acceptable Use Policy

• Enforcement of standards should be part of your AUP and audited and corrected on a regular basis

Password/Authentication policy

• A standard for password complexity
• Multifactor authentication
• Unique passwords per application/server
• Administrator accounts get special protection
• Regular reset cadence
• Encrypted password storage

Guidelines for datacenter minimum requirements, lab, etc.

• Hardened host standard
• Proper change control and change management
• Certified compliant systems
• Backup and Disaster Recovery mandatory

Logging

Logging enables your SOC/CSIRT to successfully investigate a security incident via simple search. But you must have current, exhaustive and relevant log delivery or availability to analysts. Log data is a machine generated timeline of activities on a host, whether nefarious or not. By the way, it’s also valuable to know if log files are unexpectedly deleted (an indicator of malicious activity).

Even if your SOC is not yet up and running, you have log data. The question is, is it usable, relevant or applicable to a security investigation. You can push things in this direction by creating an authoritative logging method that is enforceable via security policy, one that makes sure:

• All hosts generate log data upon authentication of any user or system
• All log files, where available, contain a timestamp (in UTC), source address, destination address, username, error-code and system hostname.
• All internally developed applications will log to standard syslog facilities.
• All hosts add the official IT supported syslog servers to their system logging configuration.
• All logs use a common field naming structure.

Plus, your logs should also map the activity performed, who or what performed the activity, location or system used, time of activity, status (success/failure) and outcome. A lack of proper logging can also become a barrier to entry into any of your critical environments, such as data centers. Also, make sure your team extends the same logging standards to its cloud hosted environment, releasing all logs for regular analysis.

Network Taps

You should also have a design to tap network traffic. A physical tap can be expensive but it is worth the cost. This gives your team a full, raw flowing view of your network traffic and is a mandatory item for network troubleshooting or full scale network security monitoring. Tapped traffic can measure performance, outages or other traffic anomalies that require correction. Security teams can use the same feeds to extract binaries, match against known threats and indicators, replay attacks in labs to develop detection techniques or even use the forensic record to reconstruct an event.

Authority and Scope

Agreement on team authority and scope is critical for helping you get into gear, so a charter for the SOC/CSIRT should be initiated by all stakeholders before your team races off. It should clarify roles and responsibilities while addressing questions which might pop up later on, such as who has authority to take down a data-center host, under what conditions it can take place and procedures to mitigate service interruptions.

Communication

Communication is also key to getting started on all six cylinders. Consider worst case scenarios and which stakeholders would be most effective in engaging victims and the press both during and after an incident. Having a clear communication plan, especially in times of crisis, that covers all potential parties will help things go much more smoothly and help prevent unexpected conflict or misunderstanding that could severely damage your organization’s reputation. It will also free your SOC/CSIRT team to focus on the real problem and fix it. Again, this needs to be done before trouble strikes and usually requires representatives from Legal, PR/Corporate Communications, Frontline Services, IT Owners, Business Owners and/or Executive Leadership.

Now that you are up to speed on the six precursors to incident response, you can help make sure your SOC/CSIRT is ready for the long haul. By understanding and addressing these issues before trouble strikes, your team can deliver a more successful security response – no matter what the road ahead has in store for you.