• Lisa Hawke

RECAP: Day of Shecurity Keynote Presentation

October 13, 2019

Lisa Hawke at Day of Shecurity
San Francisco Day of Shecurity 2019

At this year's San Francisco Day of Shecurity, I had the honor of opening up the day with a keynote presentation on security governance, risk and compliance (GRC).


I promised several attendees that I would share the information from the presentation in a blog post, and here it is.


Please feel free to share this post if you attended Day of Shecurity (DOS) and found the presentation helpful (or, if you are reading it now for the first time)!


I really enjoyed all of the DOS talks and workshops I attended as well as the conversations with people I met throughout the day. Breaking down barriers to entry into the security field, especially gate-keeping activity, is really important to me. That is the reason I put this talk together and decided to submit it to Day of Shecurity.

The talk focused on what day-to-day life is like in a security GRC role, with a focus on traits that (I think) are indicators of both interest and likely success in this discipline of security (and privacy).

The key point being that anyone, at any level in their career, and with any type of educational or experiential background, can hone these traits and describe them on a resume.

During the first part of the talk, I shared my non-traditional path into the security and privacy world. You can read more about me here if you'd like, but in the interest of brevity, I won't describe it again in this post.


I also discussed why security GRC (and good security in general) is not all about box-checking! I've also written about this concept here, but the important takeaway is that security GRC is about a holistic approach to building a program with the ultimate goal of creating a culture of security in your organization. Culture is the end game. (Thanks to Launa Rich of CyberSN for creating the hashtag!)

In Part 2 of the talk I described what the G, R and C mean and gave some examples of what you might be doing in this type of role on a day-to-day basis. I drew a distinction between a GRC role at a startup versus a big(ger) company because it can look quite different.

  • Building v. Maintaining + Continuous Improvement: At a startup, you might be in the earlier stages of building a program, whereas at a bigger company you’re more likely to be in maintenance mode. There is always opportunity for learning and improvement, no matter how long a program has been around.

  • Generalists v. Specialists: In my experience, startups tend to have generalists in GRC where everyone does a bit of everything. In a larger company, you might have a role more specifically dedicated to an aspect of GRC, for example, security audits, awareness and training or policies and procedures. Both are valuable experiences.

  • Mo Money Mo Problems: There are certainly benefits and challenges to both opportunities. They are both great ways to develop valuable experience in the field. As companies mature (and grow) new sets of challenges will start to emerge that impact GRC, for example, regulatory scrutiny (e.g. new regulations, enforcement attention, IPO requirements, etc.).

In Part 3 of the talk, I described each of the traits I mentioned at the beginning of the post. These are in no particular order!


Risk Sentinels, AKA Meerkats

Image: HANNES LOCHNER / BARCROFT MEDIA

Risk Sentinel is my term for people who are naturally attuned to risks in situations and have thought about them in advance. It doesn't mean that you are necessarily risk averse.


Think of a group of your friends. Is there someone who always has battery pack for their phone? Or someone who downloads Google Maps to their phone before you go hiking so you don’t get lost if you end up in a dead zone?


Risk Sentinels are really good at looking at a situation and thinking 3 or 4 or 10 steps ahead to what might happen in a given scenario. This is important in security.


It's not always about a specific (or correct) answer. It is the way a person thought about the risks and outcomes and what might happen when different actions are taken.

Resume Tip: Look for ways to describe how you’ve identified an issue, analyzed potential strategies and outcomes, and then recommended or selected a path forward based on that analysis. Be able to describe how you thought through the possible outcomes and why you selected (or recommended) a specific path.

Curiosity

Image: Giphy

Curiosity is a good sign of a person who is proactive. Being proactive and curious in GRC is important for your own development (e.g. to learn system architecture and other important details about your tech stack), as well as for continuous improvement of your program.


If someone tells me that they have never done XYZ, but are learning about it by doing ABC, I think that is a great sign of someone who will be curious and proactive on the team. This is especially useful when answering security questionnaires where being curious and willing to dig around to find an answer is very useful.

Resume Tip: Think of a self-directed project where you researched or dug in to a topic and be able to describe what the research was, why you did it, and the product of that work. The self-directed aspect of this is key, show that curiosity!

Puzzlers

Image: Giphy via http://workshop.liz-meyer.com/post/62835085431/figure-it-out

Security (and privacy) GRC frameworks can be difficult to work with and interpret. Have you ever read a control in NIST SP 800-53 and thought, what does that mean to my cloud environment?


Puzzlers like to take messy things and put them in order. Security policy and control frameworks important to a GRC program can be like a puzzle. How do you make the policies, procedures and controls work together?


If you are working with a framework for the first time (e.g. ISO 27001 or SOC 2), it will feel like putting a puzzle together as you review the controls and determine how they apply or fit in to your organization, product and environment.

Resume Tip: Think of a project you worked on (work, school, or other) that had a lot of stakeholders, parts or moving pieces. Describe how you worked to make those pieces fit together and your thought process throughout the project.

CAS = Collector, Analyzer, Synthesizer

Image: https://dribbble.com/shots/3445360-Collect-Analyze-Synthesize

These are folks who like to Google things, read them, break them into understandable pieces, and then are able to communicate the information in an easily consumable way.


In GRC, this is important to engaging with all of the other teams in security and in the business. Especially if the GRC team is also responsible for awareness and training.


In security GRC, it is very common to have responsibility for creating layperson descriptions of your security posture for the commercial teams. If you are at a startup, you may also be reading developing security or privacy rules and regulations that apply to your business, and explaining why and how they apply to the product or company.

Resume Tip: Describe a project or issue you worked on that required collecting a lot of information, analyzing it, then condensing it into an understandable product or communication. Be able to describe the end result! (This could tie into the Puzzler example.)

Service-Minded

Image: Giphy

At the end of the day, GRC is a function. We are there to help the company carry out its mission in an ethical and secure way, and a big part of our day is answering questions from team members and helping them do their jobs.


So, if you are someone who sincerely enjoys helping others and thrives in shared success, you probably fit the bill as service-minded.

Resume Tip: A good way to think about this for your resume is finding a way to describe how you’ve worked with other teams (or people) before and be able to give a specific example of an experience where your success relied on interacting with or supporting someone else.

Finally, you love a fist bump: Collaboration

Image: Giphy

As I mentioned earlier, the ultimate goal of a GRC program is a culture of security in your organization. Without a culture of security, you can have the best program in the world, but it will not be effective.


So, collaboration is really important. This doesn’t mean that you don’t get your quiet time to dig in and do work, but GRC as a whole requires a lot of collaboration with other teams to be effective.


For example, the GRC team will likely be working on understanding what control or compliance frameworks apply to the product or business, but when it comes to aspects of implementation you will have to win support and help from your engineering team, your product team and others!

Resume Tip: Look for ways to highlight your experience collaborating with other teams on specific initiatives or projects and be able to describe the results and the outcome. (This can tie into the service-minded experience.)

I hope you enjoyed this recap! I'm looking forward to the next Day of Shecurity.


Follow me on Twitter @ldhawke


Sources and further reading:


Governance

Guidance on Effective Programs (substitute “compliance” for “security/privacy” in this document): https://www.justice.gov/criminal-fraud/page/file/937501/download


More:

https://www.humintconsulting.com/post/how-and-why-to-apply-federal-compliance-guidance-to-security-and-privacy-programs


Frameworks

Secure Controls Framework (FREE!) Covers SOC 2, ISO 27001, GDPR, etc. and maps controls

https://www.securecontrolsframework.com/

https://www.securecontrolsframework.com/faq


Community

Risk Salon: https://risksalon.org/about


SCCE: https://www.corporatecompliance.org/


Women in Security and Privacy: https://www.wisporg.com/


Women of Security: https://wearetechwomen.com/wosec-women-of-security/


Women's Society of Cyberjutsu: https://womenscyberjutsu.org/


Women in CyberSecurity: https://www.wicys.org/



189 views0 comments