This post will be some points in the first section, around the incident handling process and the preparation phase.
- What is incident handling
- an action plan for dealing with the misuse of computer systems and networks
- generally a set of written policies and procedures that outline what to do when an incident occurs
- Pre-planning of response parameters/controls/scope
- An incident refers to an adverse event in an information system or network
- implies harm or the attempt to do harm
- contrast to an event, which is any observable occurrence in a system or network
- Ultimately, the definition of which events are classified as an incident is up to the handler and the company
- Think of incident handling as first aid
- incident handlers need a easy method to follow under pressure to resolve issues
- Core Stages: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned
- Preparation Phase
- The WHY: You need to enable the enterprise, both technically and from a people perspective, to respond to incidents.
- People
- Focus on training (sometimes reoccurring training)
- Test user and the team often
- fake incidents
- social engineering attacks
- Establish communication mechanisms (easy to use) for end users to report suspicious activities (TSA: See something, say something policy)
- Coordinate with helpdesk staff (they are often the first line of defense against this)
- establish training plans
- Policy
- Policy should be established
- in general
- consequences of insider actions
- share information with authorities (or not)
- peer notification
- understand breach laws
- Warning banners allow for lawful recording of actions (also serves to remind users, like airline safety training)
- Get management buy-in and delegation of authority to the incident response teams
- Notes
- maintain excellent notes, preferably in written form on notebooks
- understand the chain of custody requirements and follow procedures
- Management Support
- work to achieve management buy-in
- show quarterly reports on incidents
- Building A Team
- aim for a multi-disciplinary team
- technical domains (server, network, storage, forensics, etc)
- Non-technical domains (marketing, law, public affairs, etc)
- Establish roles if no specific members exist and assign the responsibility to someone
- Conduct routing training and testing with the team
- many online resources (counterhack challenges)
- conduct sessions on log reading, etc
- Establish appropriate compensation plans (work times, etc)
- Establish response times, response locations
- Might need a command post (secure location to sore files and hold meetings)
- Remote people may be required to be the "techie on site"
- Establish a budget for the team ahead of time (no need to seek approvals to spend during an incident)
- Checklists
- Have a firm understanding on how to rebuild systems from known good backups or from scratch
- Emergency communication Plan
- Create a call list, test this call list
- identify requirements for secured communication channels (ahead of time)
- Granting access
- have an access strategy in place for incident response team members to access critical systems and data
- Jump Bag
- thing about the things you will need in an incident
- Tailor this to your environment
- Technology: Gold images, rootkit checkers, debugging tools, forensic tools
- People: clothing, medications, food, etc
- Other things: cd/usb/media, jumpers, extra harddrives, taps, laptop with multiple OS, call list, cell phones with extra batteries
No comments:
Post a Comment