Showing Up

October 20, 2017

This blog is a response to a comment made on LinkedIn regarding a conference I spoke at recently, BSides Calgary 2017.  I felt strongly about it, and felt the need to post a longer response than LinkedIn allowed in their comment field.

Thank you for your time here.

My name is Shelly Giesbrecht, I’m “nerdiosity” to my friends, I’m a woman in tech, and I spoke at BSides Calgary this year.

I began this blog as a short response to the post by Ms. Smibert about the lack of representation of women in the speakers at BSides Calgary this year, but it quickly became too long to be just a comment.

To begin, I have the greatest respect for Ms. Smibert. However, I feel that her comment about BSides Calgary was, at best, misinformed, and at worst, unhelpful. Misinformed because I taught at BSides Calgary this year, and unhelpful because the InfoSec community in Calgary is still in its infancy compared to other places, and needs to be built up not torn down.

Ms. Smibert’s comment “The fact an event couldn’t find a single woman to speak (have they tried?) is the reason why I will not show up” is what I find most problematic.  BSides Calgary, as I understand it, did not receive any submissions for talks from women for this year’s conference. (Note: I chose to submit a training session, not a conference talk this year) Is this a failure on BSides Calgary’s part? Some might argue yes, and I believe that Steve and the team will likely look at ways to better encourage and promote female speakers next year.

That said, I believe this is a larger failure, so bear with me while I explain:

When I was 11…15…20…25, I honestly didn’t know that the job I do now even existed. No one, man or woman, told me that a talent for fixing things, solving puzzles, using computers and reading everything I could find would lead me to one day become the team lead of Incident Response for one of the largest security companies in the world.  I have been very lucky along the way to have some incredible mentors, both men and women. I find myself in a position in life where I feel blessed to be able to affect others in a positive way.

But when we hire, we don’t see enough resumes from women. And when I speak at conferences, there are still too few women in the audience.

So how do I choose to change this?  I show up.

I show up by submitting talks and training sessions to conferences in hopes that by seeing me speak, another woman who is passionate about her craft but nervous about trying might be inspired to try.

I show up by speaking at Career Day at my local high school so that young women can see what is possible.

I show up by blogging about work I’m doing to share my passion for what I do.

Last year, I showed up at the first BSides Calgary, alongside other highly talented and bright women, to speak. In the last year, I also spoke at the SANS DFIR Summit, I facilitated a panel at the Calgary ISC2 Congress, taught at Cisco Live, and blogged for the Cisco Security blog.

But I obviously didn’t do enough. And neither did Ms. Smibert, nor did every person that “liked’ her post.  We cannot simply say “BSides Calgary is at fault” because there are no women speakers.  We need to show up.  For every talented, bright woman who liked the comment but didn’t submit a talk, for every leader who commented positively but didn’t encourage the talented, bright women on your team to submit a talk, I challenge you to show up next year.

We can bring change to the numbers of women in tech by being visible, by letting females from 5 years old on up know what is available and possible.

Does this solve all the problems women face in tech? Absolutely not. We have much work to do, and need more allies to achieve it.

I plan to make 2018 a bigger year personally for ‘showing up’ in hopes of inspiring more women to submit talks not just to BSides Calgary, but to talk, teach or write about whatever fuels their passion.  Please join me.

Ransomware: The race you don’t want to lose

September 9, 2016

In the race to detect and contain ransomware on their networks, many organizations fail before they are out of the gate.  The reason has very little to do with technology, and more so a great deal to do with process.

“But we bought all the good tools!”, such organizations protest. Good security technologies implemented and optimized properly are certainly one piece of the puzzle, however organizations, with large or small budgets, can use good processes and procedures to narrow their attack surfaces.

As discussed in a blog written by Sean Mason of Cisco Security, organizations can be rated on their overall Threat Management Maturity by what level of capabilities they have in the categories of People, Process and Technology.  Without documented processes and procedures, IT departments frequently rely on tribal knowledge and react to incidents in an ad-hoc fashion. Time to remediation is longer due to lack of assigned roles and responsibilities, and little or no pre-written and rehearsed action plans.  In the case of ransomware, the time to remediation for some organizations can be the difference between being in business and going under.

The question then is, how best to prepare for ransomware infections that are becoming a daily occurrence for a majority of organizations? The answer is a Runbook, which is focused specifically on detecting, containing and remediating ransomware. At its simplest, a runbook is a series of steps to undertake when a specific incident occurs. This is considerably less complicated than developing a full Incident Response Plan (which doesn’t necessarily tackle the heart of the incident) and there are a number of good resources on the Internet to assist with the development of one.

To be effective, a ransomware runbook should address the following:


The ways in which a ransomware incursion could be identified on a network. For less mature organizations, this is usually an end-user notifying the helpdesk or local IT support person.  It may also include IT team members recognizing an abnormal condition on a system they are responsible for. As organizations mature, this may also include alerts produced via security technologies, or via centralized monitoring platforms (e.g.: SIEM).


Ransomware comes in a wide variety of types these days. To effectively contain a ransomware threat, it is imperative that it be identified properly. Actions in this section of the runbook would address the attributes of the suspected infection (e.g.: file extension, infection vector, files created, file owner). While time is of the essence during a hunt for patient zero in a ransomware investigation, improper identification can lead to incorrect containment steps.


This is commonly referred to as “stopping the bleeding” and involves making sure the active infection is contained or terminated so damage to network systems is halted. In the case of ransomware, ensuring the executable responsible for encrypting files is no longer able to run or communicate out are common containment steps. The runbook should consider both host-based and network containment steps.

Analysis & Remediation

The inclusion and level of analysis in a runbook will largely depend on the level of capability an organization has. While full forensic analysis on a host is possible for some organizations, many do not have the skill set or time to engage in this level of investigation. Once containment has been validated, analysis may be as simple as running additional anti-virus or anti-malware scans on a host. Indeed, analysis may not even occur and the remediation step may simply be a re-image of the affected host.  A runbook should also include host and network remediation steps that address the initial infection vector, as well as how the malware was able to run on the host in the first place.

A ransomware runbook, like any other runbook written to address a specific and known threat, should be written with the organization’s actual capabilities in mind. It should also be reviewed frequently and updated based on new tactics, techniques and procedures that attacker may use as ransomware continues to evolve. A runbook will not stop all ransomware attacks, however it will enhance an organization’s ability to respond and remediate faster and more efficiently.

The following is a list of prevention, mitigation and safeguards that organizations can take to reduce their impact to Ransomware based threats and incorporate into existing process, procedures and architecture.

Ransomware Prevention, Mitigation and Safeguards

  • LAYERED HOST AND NETWORK-BASED SECURITY DEFENSES – Each system should be protected with DNS layer protections to prevent devices from connecting to sites hosting ransomware and endpoint protection for detecting and preventing the latest ransomware variants. At an organizational level, strong email and web threat protections in addition to network security (Intrusion Prevention Systems and Next-Generation Firewalls) should be utilized in also detecting and preventing the latest ransomware variants.
  • PATCHING LIFE CYCLE– A patching level cycle should be utilize to deploy updates to all systems for known Common Vulnerabilities and Exposures (CVE) in commonly used software such as but not limited to: Adobe Flash, Adobe Acrobat, Microsoft Silverlight, Oracle Java, Microsoft Internet Explorer, and Microsoft Office; where exploits can take advantage of programmatic errors and unsecure code.
  • REMEDIATION/UPGRADE PLAN FOR UNSUPPORTED OS (Operating Systems)- Develop a remediation/upgrade plan for unsupported and unpatched OS, such as: Windows XP, Windows 2000 and 2003 systems or consider the use of application white listing.
  • BACKUPS/CONTINGENCY PLANNING- A backup policy/contingency plan, procedure, and technology for systems should be developed and utilized in the event that the loss of data on a system occurs


This blog post was originally written for the Cisco Security Blog and was co-authored by Aaron Varrone.

I’m a project manager?

February 2, 2016

I recently passed the GCPM (GIAC Certified Project Manager) exam. It’s part of the core curriculum for the SANS Technology Institute’s MSISE program of which I am a second year student. Now, I want to point out that I don’t intend to be a project manager. That said, as an incident responder who frequently has a few people working with me, every client issue we respond to is, at its base, a project by definition. It is temporary (has a beginning and an end), goes through dedicated phases (including planning, execution, monitoring and closing), and requires a detailed plan if you have any hopes of being successful.

Magically, without even meaning to be, I’m a project manager. Huh…

Delegation 101

January 14, 2016

I was promoted last quarter to Manager. This was exciting and daunting all at the same time as part of me felt I was ready, and part of me suffers from Imposter Syndrome. One thing that has become patently clear since my promotion is that I have a lot more on my plate from the perspective of planning, teaching, organizing and leading. This is in addition to all the actual “doing” of client work. I am lucky that I work with very smart and dedicated people who are as passionate about what we do as I am. We are very busy, and frequently have to call on each other to assist when new work or additional tasks occur. That leads me to my dilemma. I am a terrible, horrible, no-good, very bad delegator. Not because I am smarter than everyone else is, and not because my team can’t do it (they are amazing…), but because I am bad at saying no and asking for help.

While this will be a continuing journey for me, I thought I would share some new things I’m learning about the benefits of delegation in hopes they may ring true for someone in a similar situation.

Firstly, delegating a task to someone else means I have more time to do other things. This is probably the most intuitive of my observations, (You’re all saying, “Thanks Captain Obvious!” right about now.) but if it was that easy, I’d have done it long ago. Delegation means a loss of immediate control over that piece of work. It could mean the work may be done by someone less experienced, or by someone who has a different method. Both of which could lead to different results. Right about there, my brain starts to shudder a bit and I think, “It won’t be done exactly the way I want it!” Immediately after this thought, I tell myself to get over myself, and realize, as the old saying goes, “There is more than one way to skin a cat”**

This leads me to the second benefit of delegating, making my team better. When I delegate a task to a less experienced team member, I more than likely will need to spend time with them the first time this happens teaching them my methodology, and then QA’ing their deliverable. Upfront, this means more work for me, but at the end of the day, three miraculous things happens:

1) I am now better at this task because if I can teach it, I must really understand it;

2) Someone else on my team now knows how to do what I can do. Next time, delegation will be less work and time saved for me;

3) The person who now knows how to do what I can do may then figure out a way to do that task better. Now, I am a leader of innovators!

The third benefit gained by delegating is that as a result of delegating to someone else on my team, I may learn something new. A new set of eyes on a task can bring new methods, new ideas, and new, possibly better, results.

Lastly, the net benefit of having more time for other things, leading innovators with deep skillsets, and learning new ways of completing tasks from experienced colleagues is that I may end up becoming the confident, experienced leader and manager I know I can. Delegation feels like losing control, but at the end of the day, I have learned to trust myself more to lead by example, teach to inspire innovation, and let go a little to continue to learn.

** Creepy fact from my days as a Biology major: There is, in fact, only one good way to skin a cat.

SANS DFIR Summit 2014 Slides

June 12, 2014

Here is a pdf of the deck I presented at the SANS DFIR Summit 2014 in Austin last week.

Check out all the great presentations from the Summit here.