1 / 33

What makes a Security Incident different from other IT incidents?

alka
Download Presentation

What makes a Security Incident different from other IT incidents?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Seccuris is North America’spremier Information Assurance integrator. We enable organizations to achieve business goals through effective management of information risk.We are agile, innovative, flexible, and responsive. We assist your organization in managing all aspects of information risk. We specialize in end-to-end services, comprehensive solutions, and tailored programs.

  2. What makes a Security Incident different from other IT incidents?

  3. Break and Enter • Lets apply our standard IT Incident Management Methodology to a simple ‘real world’ example: • A Break and Enter into a home…

  4. Break and Enter • Preparation - Monitored House Alarm, Heavy Door, Video Surveillance, NeighbourhoodWatch • Detection - Alarm Trips, Phone call is made • Diagnosis - House has been broken into. Door was smashed, items were stolen, house was rummaged.

  5. Break and Enter • Repair- Door is fixed, clean up glass, clean house, call insurance. • Recovery - Stolen items are replaced. • Resolution - All is done, issues have been dealt with. Life is back to normal

  6. Break and Enter • What is wrong with this approach? • Has information been gathered by the thief? • What ‘intangibles’ have been stolen? • Why is this methodology not suitable for IT Security Events?

  7. Break and Enter • EVIDENCE HAS BEEN DESTROYED: • Conventional IT Incident Management processes are insufficient and sometimes even harmful to the chain of custody.

  8. Break and Enter • The goal of incident management is to restore the status quo. • However, with Information Security Incidents there's a higher likelihood of collateral damage: • the beginning of a systemic outbreak • an all-out outage • important data has left the environment

  9. Break and Enter • 5 Reasons why we shouldn’t follow the same methodology for Security Incidents as regular incidents. • At what phase is an incident identified as a Security Incident? • How do we best integrate the outcome of an incident handling effort into the change control processes? • The Future: Short-Term and Long-term Agenda:

  10. Break and Enter Most Typical Information Security Incident Outcomes are: Denial of Service Unauthorized use of IT Resources Credential/Data Theft

  11. 5 Reasons why we can't follow the same methodology for Security Incidents as regular incidents.

  12. 5 Main Reasons – Threat Agents • Reason #1 – Threat Agents • Security Incidents always have a threat agent.

  13. 5 Main Reasons – Threat Agents • Reason #1 – Threat Agents • They can be: • Non-Target Specific: viruses, worms, trojans • Employees: Staff, contractors, operational/maintenance staff • Organized Crime and Criminals: mostly looking for $ • Corporations/Government: mostly looking for competitive advantage • Human, Intentional: Insider, outsider, hacktivists,etc

  14. 5 Reasons - Containment • Reason #2 – Containment

  15. 5 Reasons – Service Levels • Reason #3 – Service Levels • Information Security events are much like a Hospital Emergency Room, where the goal is not to measure resolution

  16. 5 Reasons – Service Levels ‘exposed till we fix it’

  17. 5 Reasons – Impact not readily known • Reason #4 – Impact not readily known • In some cases there’s no visible impact at all

  18. 5 Reasons – Impact not readily known • Incidents are classified by: • Service Disruption

  19. 5 Reasons - Communication • Reason #5 – Communication • Incidents are shared on a “who can help” basis • Security Incidents are shared on a “need to know” basis

  20. 5 Reasons – Communication • Reason #5 – Communication • Who do you communicate with? (internal/external) • What do you communicate? • When do you communicate?

  21. 5 Reasons – Bottom Line • The differentiation between an incident and security incident must be clear and definite. • However, they can be mutually complementary if defined and managed properly.

  22. At what phase is an incident identified as a Security Incident? Best Case Sometimes Or not at all Too Late Most Commonly

  23. What is the most effective way to detect these Security Incidents? • People? • Systems? • Both.

  24. Our most common sources of detection: • Security Device Logs • Non-Security Device Logs • Help Desk • Users how do we know what’s important

  25. How do we best integrate the outcome of an incident handling effort into the change control processes ? • ALIGN and INTEGRATE as part of detection and analysis

  26. Key Factors for Integration: • Preparation and Detection! • Create and Maintain a Security Incident Handling Policy • Define a Security Incident Handling Team • Develop a communications plan • Educate • Establish Detection Services

  27. Key Factors for Integration: • Containment! • Determine the risk of continuing operations • Outsmart your Threat Agents • Avoid potentially compromised code • Forensic image of the system • Get help

  28. What does the future look like? • Long Term: • Security Incidents are handled by help desk analysts • All necessary information is available when an event occurs • All analysts have enough Information Security know-how to handle day-by-day events • Impact is readily known • System Forensics is automatically engaged

  29. What does the future look like? • Short Term: • Integrate Detection in Help Desk processes • Start to integrate Information Security tasks into day-to-day processes • Engage Information Security Analysts and/or Consultants to aid in Security Incidents • Begin cross-training all analysts in handling security incidents

  30. What is OneStone • Software as a Service Information Security capabilityfor comprehensive threat protection • OneStone is purpose-built by Seccuris built to easily incorporate human analysis, review, and incident handling assistance • Assisted and accelerated implementation, with a scalable, flexible architecture • Provides customers a choice of Self-Managing or Managed security services • Straight forward, easy to use dashboards provide a visibility into security issues, vulnerabilities • Security Operation Center (SOC) analysts available 24x7

  31. Current Services • Threat Management • Vulnerability Management • Log Management • Device Management • Security Incident Handling • Forensics

  32. Why OneStone? • Allows your staff to concentrate on higher value activities • Uses a combination of technology and security analysts to reduce the number of events staff needs to investigate • Improved network visibility and threat protection 24x7 • Enabling risk management through a business relevant prioritized action plan • We provide assistance on remediation or forensics from information security analysts (ISAs) who understand the current threat landscape • Relevant reporting capabilities for various business roles

  33. Q&A Ivo Wiens Manager, Security Engineering iwiens@seccuris.com Gus Burneau Information Security Sales Specialist gburneau@seccuris.com

More Related