Input Needed for New (ISC)2 PDI Course Offering on Incident Management

[StacyMantzaris]

We are in the process of developing a new immersive training course on incident management as part of our PDI catalog of offerings and would like help identifying possible/realistic security incidents that we can incorporate in the course.  What incidents (not actual data breaches) are you aware of, were involved in or can imagine occurring?  If you can, please share your thoughts, ideas, and comments below. Need some inspiration on what to add?  Here’s some information to get you started:

• A brief description
• Roles involved (i.e. departments/teams, key positions like CISO, etc.)
• Applicable technology
• Lessons learned  
• Anything else you think will help us better understand the magnitude of the incident. 

If you prefer please send me a private message and our team will contact you to learn more about the potential/actual incident. Please note, we may also reach out via private message to get more information or discuss your comments further.

Thank you in advance for sharing your experiences with us.  Your contribution to helping create a realistic and relevant course with applicable examples is very much appreciated. 

[Steve-Wilme]

Unknown variant of Ransomware

Organisation detects signs that appear to be the behaviour of ransomware (not possible to open files on shared storage) and oddly named file extentions appended.  Initial investigation suggests it is ransomware encrypting part of a file system.  It was CTB Locker.

vCSIRT (comprising Sec Manager, Support Managers and Server and Storage Engineers convened)  

Note composition of vCSIRT depends on the playbook.  CISO informed.  Gov CERT duty handler informed.

Technology

Windows 2012, Citrix XenApp 6.5, 3PAR SAN, Symantec dedupe disk backup and the offending Adobe Flash Plugin!  Note XenApp servers are rebuilt from offline images every night.

Lessons Learned

1. Have an upto date backup that will restor within your RTO/RPO.

2. Patch your estate continually (every week).  Patch delay time was exploited; the time between release and install, which was formerly 30 days.

3. Pay your incident response team and don't rely on good will alone.

Magnitude

Low; architecture meant we could delete to infected servers and selectively restore data within 6 hours.

Additional more frequent patching did increase costs to a small degree; again architecture meant only 1 image patched for 4K users. 

[JoePete]

---

@StacyMantzaris wrote:

What incidents (not actual data breaches) are you aware of, were involved in or can imagine occurring?

---

Curious about the distinction of "not actual data breaches." In this day and age, a huge part of incident response is addressing the actual breach or the potential breach. Is it just a matter of not wanting something that may be an actual incident and carry certain legal ramifications if it were written up as a case study?

[Steve-Wilme]

If you look at it from a safety perspective the majority of security incidents aren't breaches.  So in order of severity you have a serious breach, major incident (which could of course be availability related), incident, minor incident (such as, single desktop missing upto date AV) and then the near misses from which you can learn a lot.  And finally you have the security weaknesses and poor practices which need addressing, which you'd prefer everyone report do you're aware they exist.

[JoePete]

---

@Steve-Wilme wrote:

If you look at it from a safety perspective the majority of security incidents aren't breaches.

---

I might want to qualify that as "apparent breaches," but point taken, perhaps the idea is to speak of the building block incidents that often precede something major. In some ways, however, I think it is worth taking those major incidents and showing how simple the error really was; supposedly the DNC attack was a matter of someone accidentally forgetting the "not" in front of "legitimate" advice given to John Podesta. A lot is a matter of awareness more than technical control.

Here is a case in point:

Lost/stolen Android cellphone belonging to a senior-level employee. The phone did have a passcode, however, it also had stored credentials for accessing corporate resources and an unlocked SIM card. Employee did not report it missing for three weeks. Employee did report to his provider approximately 72 hours after losing it. 

The company security officer (basically IT manager who wears multiple hats) served as lead. Once reported, reset credentials and attempted to monitor for untoward activity. Given the lengthy delay a third party was called in to assist with the review. An inventory of all data accessible via the device taken. However, the phone number connected with device also was used in certain two-step authentication systems.

The lessons learned were multiple. 1) Policy was lacking, most relevant connecting security behavior to HR and embraced by board/senior management. Simply the senior employee didn't feel compelled to deal with the issue or recognize a corporate impact to his missing cellphone 2) While there was annual security awareness training, clearly it wasn't doing its job. 3) Technical controls like mobile device management were absent so too a policy on approved devices and related employee procedures (i.e. immediate reporting). 4) The employee specifically indicated that he didn't want to deal with the "hassle" - this also speaks to a cultural issue where response teams or security officers aren't always that approachable.

[Steve-Wilme]

Behaviour/Culture related problems are always more difficult to handle.  It's why some HR departments become part of the problem with their disciplinarian attitude.  Punishing staff for clicking on a phishing link or having their laptop stolen doesn't foster a culture in which staff report errors or accidents.  If you make reporting near misses and incidents to be something they can do without fear of adverse personal consequences then you get earlier visibility when things have gone wrong and can act to contain the incident.  It also helps to have prepared; so encrypt your mobile devices, lock down use of removable media, install antimalware, keep your machines patched and appropriately securely configured and have measure in place to locate or remote wipe them.  It all has to be part of the overall Deming cycle.

[rslade]

> StacyMantzaris ((ISC)² Team) posted a new topic in Welcome on 07-16-2019 08:36

> We are in the process of developing a new immersive training course on incident
> management as part of our PDI catalog of offerings and would like help
> identifying possible/realistic security incidents that we can incorporate in the
> course.

In my incident response/management/planning seminars, I have a slide that
mentions "bad weather," and is illustrated with a picture of bright sunshine. I
explain that, when I was working on one version of the seminar I happened to
encounter someone talking about ice-fall climbing, and noting the danger of
sunshine in that situation.

The point being that an "incident" is going to be enterprise-specific, and that you
don't need to address a canned list of "incidents" and leave it at that ...

====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
I'd be content if my children grew up to think decorating
consists mostly of building enough bookshelves. - Anna Quindlen
victoria.tc.ca/techrev/rms.htm http://twitter.com/rslade
http://blogs.securiteam.com/index.php/archives/author/p1/
https://is.gd/RotlWB

[dcontesti]

Incidents are industry/company specific.  Depending on the size of an organization, a virus incursion on one desktop could be and is an incident in a small shop however in a large shop, it would be an annoyance.  

There are many things that comprise an incident and simply broken down could be:

- something happens

- folks are pulled together

- a resolution is found and incident remedied.

- lessons learned are documented 

What you might want to consider is some of the aftermath that occurs with incidents (actually during and after).  

I see Self-care playing a part of this.  Folks during an incident are concerned that they may be fired or that the company will go bankrupt (I know extreme) but emotions do run high.  After the event, there is relief (sometimes) and then there is usually "the hunt for the innocent.....that is someone to blame".

To me, a Crisis manager has to wear multiple hats, they have to weather the ire from senior managers who  ask multiple questions, they have to keep folks motivated to find a solution, they also in some ways need to be psychologist.

My two cents

d

PS: I have sent an incident in via private mail but for all the wrong reasons cannot discuss it publicly.

[Steve-Wilme]

And for some companies it could be a simple as founder has heart attack and is unable to work.  Company begins to unravel in their absence, incidents occur, bugs don't get fixed and services get turned off by customers contain potential breaches.  And yep, seen that happen.

[AppDefects]

---

@StacyMantzaris wrote:

Your contribution to helping create a realistic and relevant course with applicable examples is very much appreciated. 

---

I would recommend the following detailed "textbook case studies". These investigative reports have lots of details:

• The Equifax Data Breach, U.S. House of Representatives Committee on Oversight and Government Reform
  https://republicans-oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf 
• GAO Report to Congressional Requesters, DATA PROTECTION Actions Taken by Equifax and Federal Agencies in Response to the 2017 Breach https://www.gao.gov/assets/700/694158.pdf
• The OPM Data Breach: How the Government Jeopardized Our National Security for More than a Generation Committee on Oversight and Government Reform U.S. House of Representatives 114th Congress https://ia801206.us.archive.org/15/items/ReportFromTheCommitteeOnOversightAndGovernmentReformOnTheOP...
• And don't forget about Sony - that was the start of the proliferation of ransomware, which is a whole other branch of incident management that deserves its own course... Here is a John Hopkins University report. https://www.jhuapl.edu/Content/documents/SonyNightmareBeforeChristmas.pdf