Cybersecurity from a continuity point of view

Post on 05-Apr-2017

6 views 0 download

transcript

Cybersecurity from a continuity point of view

Planning and Preparation

Five Pillars

Preparation Detection Response Recovery Review

PreparationPreparation Detection Response Recovery Review

Of Genies, Imps, and Magic Blue Smoke

Blinded by technology• Does the solution have to

be technological?

• Pen and Paper• Sneaker-net• Honesty box

Beware of IT that isn’t IT• HVAC• Facilities Management• Building Access Control• CCTV• Telephony• Machinery CAD/CAM

Preparation

• Understand systems• Understand stakeholders and criticalities• Understand threats vulnerabilities and impacts• Understand countermeasures• Agree response and recovery plans and objectives

Preparation Detection Response Recovery Review

DetectionPreparation Detection Response Recovery Review

Who reads the logs?

Typical Phases of an AttackRecon

• Identify Target (GHDB, Google Advanced Search, Linkedin)• Look for vulnerabilities (Metasploit, Acunetix, Nmap, Builtwith)

Attack Target • Exploit vulnerabilities (GHDB, Kali Linux)• Defeat remaining controls

Achieve Objective• Disruption of Systems• Extraction (e.g. money, IPR or data)• Manipulation (e.g. adding, changing or deleting key data)

Countermeasures

• Monitoring (and logging)• Situational awareness• Collaboration

• Solid architectural design• Standard Controls• Penetration testing

• Cybersecurity Incident Response• Business Continuity Plans• Cybersecurity Insurance

Severity Impact Assessment• What is the business impact?• What are the trigger points?• Who triggers the response plans?

• Consider barriers to triggering• Autopilot• Worried about blame• Worried about loss of control

Whose plan is it anyway?• IT helpdesk BAU• Cyber incident response• Disaster recovery• Business continuity

Detection

• Logging and Monitoring• Log intelligence• Alerting• Triggering the plan

PreparationDetection Response Recovery Review

ResponsePreparation

Detection

Response

Recovery Review

Stop, Look, Listen!• Automatic pre-planned

responses buy you time to gather information• Temptations to avoid• Rushing into solutions before

the problem is defined• Trying to run a serious incident

using BAU processes

Objectives – First Aid• Call for help!• Preserve evidence• Prevent further loss• Promote continuity of service

The Domino Effect

Dependencies• Services that must or will be stopped

• Often for health and safety or regulatory reasons• Pool cannot be used without lifeguard cover• Online banking cannot be used without anti-fraud

systems • Services that can freewheel

• Underlying service is not critical or can catch up later• Information-only websites• Support services such as facilities management, HR.

• Services that must be supported• Switch over to alternate systems

• paper-based recording• backup generators

Virtualisation

Identify StakeholdersExternal

Strategic

Tactical

Operational

Communicate• Server sorry or error pages• Service status websites• Social media• Traditional channels

• Promise updates at reasonable intervals …• … and deliver on those promises!

Regulation and Investigation• Is this a notifiable incident?• Has a crime occurred?

• PCI-DSS• Information Commissioner• Industry Regulators• Police and Crime Agencies• Mandatory Subject Notification

Hallmarks of a good IMP• Brief – put details in the appendices• Available• Tested• Based on business operational units, not IT functions.• Understands dependency• Concentrates on the response, not the nature of the incident• Defines WHO to inform and WHAT information to give• Covers incidents from single service disruption to full black start

Response

• Identify Objectives• Prevent further loss• Preserve evidence• Isolate compromised systems• Communicate with stakeholders

PreparationDetecti

onResponse

Recovery Review

RecoveryPreparation

Detection

Response

Recovery Review

Before You Start• Are remaining

systems/processes stable?• Last known good state

established?• Affected systems isolated

and evidence preserved?

Step by Step• The recovery order is

determined by:• Recovery time objectives• Dependencies• Time required to acquire

hardware• Time required to

recover/rework data

Handing Back• How will data from interim

processes be back-filled?• Will there be a backlog

requiring additional resources?• Will there be additional

demand caused by the outage?

Investigation and Reporting• The incident is not over

when all systems are back up and running

Recovery

• Restore data (backups, manual re-entry)• Restore user services• Investigate incident and report to stakeholders

PreparationDetecti

onRespon

seRecovery Review

Review

• What happened?• How could it be prevented?• What could be done better?• Update plans, controls and processes

PreparationDetecti

onRespon

seRecove

ryReview

Thank youTom Crellin MBCS CITP CBCI

www.tomcrellin.co.uk