Ep. #31, Evangelizing Security with Tanya Janca of Microsoft

Guy Podjarny: Hello, everybody. Welcome back to the show, thanks for tuning back in. Today we have a guest that I've long wanted to have on the show here. It's Tanya Janca. Welcome to the show, Tanya.

Tanya Janca: Thank you for having me, Guy.

Guy: You talk a lot about security, and we're going to dig into a lot of advice and sharing and what we've observed.

But before we dig into that, why don't you tell us a little bit about how you got to what you're doing today, your journey a little bit into this world of security?

Tanya: I think it's the exact opposite story of most people. I did start as a software developer, and I know a lot of people start as sysadmins and network engineers or software developers, but I didn't want to switch to security.

I met an ethical hacker and he kept telling me "You'd make a great hacker." I was not interested.

I thought nothing was better than software development. For a year and a half you wore me down, and he was in a band, and I was in a band, so of course our bands had to play together.

We're friends and you're a super awesome person, and then after a year and a half of him-- I'm like, "Fine. OK. Just show me some stuff."

Then before I knew it I was like, "Get out of my way." So I think most people instead they're very interested and they're trying really hard to find their way in, while I got dragged in kicking and screaming.

Guy: It sounds like it. You owe somebody a beer there.

Tanya: Definitely.

Guy: So, what were you doing? You were doing software development in general, or--? When you got kicked in, what was the first things to show you to get you hooked?

Tanya: I worked for the Canadian government for a very long time, and I led several different software team's giant projects to make custom software to do all the interesting things that governments do.

I was assigned a team of smart people who had not had much training for a very long time, and our training budgets had been slashed to less than the cost of one course per person, which meant I couldn't send anyone on any courses.

But I'm really good at making friends, so I just kept inviting all of my friends to come in and speak, and then those people introduced me to other people.

I have this friend named Wes McDonald, I just happened to be friends with almost all the MVPs, like Microsoft valuable professionals, just because we're a dot net shop. I'm just friends with all of them.

So Wes came in and spoke, and then he invited Joel, and then everyone just kept inviting everyone until we'd had 40-50 lessons.

Then a hacker came in and then he introduced me to another hacker, and then before I knew it, unbeknownst to me people that charged thousands of dollars to speak were speaking for me for free.

They told me later it's because I was just so excited to learn and that it was so fun, and my team the 12 of us are just on the tip of every word listening.

They said, "The more excited you got and the more specific about the things you wanted to learn, the more it was like, 'She needs to meet this guy and she needs to meet that person.'"

I ended up winning six different awards for this training program, I ended up starting to webcast it across other government departments, and we had nutrition and all sorts of--

Just anything I felt like, they just let me do it. Then they're like "Why is every talk about security now, Tanya?" I was like, "I don't know."

Then I started a formal apprenticeship program with someone, and then it all flowed out from there.

Guy: Today you just work at this, right? You're officially a security advocate, or a Dev advocate?

Tanya: I have the weirdest job, I think, ever. I was speaking about security and teaching people about security, giving back to the community that has given me so much.

And then people started inviting me to speak at conferences and I said "I can't really afford to come to Switzerland," and then they said "How about we send you a plane ticket?"

Then I kept doing that more and more, and people started paying me to show up, and then I was doing it all the time and not going to work a lot anymore.

So then Microsoft said, "What if you just did that, but you said you were from Microsoft?"And I was like, "Is there a trick here? You're going to give me money?" Like, "We'd like it if you would bash around our products a bit please." "Really?"

So it just all stemmed from that, and so I get to go and I get to write my blog and it's considered work time, which to me is "Wow." Previously I've just been like, I don't want to say punished, but it felt like punishment for doing extra curricular activities. Like, "Why are you going to another conference?" "Because I don't know enough yet. Because they're letting me in free because I'm speaking, don't you want me to come back and bring all this smartness with me?" So yeah, it's nice to be in a place where they're as excited as I am about learning.

Guy: Yeah. That's awesome. I think oftentimes when you get into these advocacy or Dev relations or whatever the title may be, it's oftentimes effectively-- It's an educator's role.

You walk around and you get to spread knowledge and learn in the process, and for a lot of people the perception is "I got to turn my side job into a full time job."

Tanya: Yeah.

Guy: That sounds like a pretty good deal as long as you enjoy doing it. Enjoy getting up on stage and doing the workshops and doing the writing.

Tanya: I love writing. I love speaking, but for opposite reasons.

Speaking is exciting and exhilarating and I love seeing people's eyes light up, and either they've had the same experience and they're really excited because I've validated their feelings, or they're learning. Or they are so excited to go off and try something new.

But then with writing, I feel like it's so calming, and I get to really think out very clearly what I want to teach people and get really deep into the weeds on one specific topic in a way I don't feel like I can do in a talk.

Guy: Do you have a favorite security blog that you've written?

Tanya: So there's one that I'm about to release where I did a threat model with a friend from work, and he was telling me "I am creating this proof of concept for this conference."

When I started telling him about, "What about this? What type of data are you collecting? You know you'll be in Europe and you're subject to GDPR," and I'm like, "What if your users get hacked because of this?"

And he said, "Can we please have a meeting about this?" So the blog post is about if you're doing a serverless app, all the different things that apply, and us dissecting layer by layer each different thing.

He's going to write up his side, "I'm a developer, holy crap, I'm talking to a hacker. Terrifying, but also I can't believe how much stuff I know now."

Guy: Yeah. Education sifts in without you noticing.

Tanya: Yeah. I don't know how to explain, but it's like crash training for my brain. I feel like it's so exciting to stretch my threat modeling muscle. I feel like I learned from him, even though he feels like he learned from me.

Guy: That's the beauty of collaboration.

Tanya: Yeah.

Guy: Let's dig into the topic. So you got pulled into this world of security, and now you talk a lot about it, and I know that a lot of the conversations in all the talks that you give revolve around this modern security or security in the DevOps world.

What's your view on that? What are the highlights of doing security right in this DevOps space?

Tanya: I'd have to say the number one thing is that we can't expect to do the old security model, if developers and operations and all of the rest of the IT are doing a completely different thing.

We can't say "We want you to stop for three weeks and have a code freeze while we do a code review." No one is ever going to do that ever again for you, or for me, or for anyone. Unless you work in a place where they don't like money.

We as security people, if everyone else is sprinting, we're sprinting.

We need to learn how to do security sprints, because it's different. The first code review I was involved in I remember the security person said "You need to do a three week code freeze."

And I was the Dev lead, I just looked at him and I was like "This is so cute. OK, so what are we actually doing?" I thought he was completely nuts. I was like, "We're not stopping for you or anyone."

I remember someone way above us telling us to stop coding for three weeks, and in the meeting I was like "Yes of course."

Then as soon as everyone left, all the developers looked at me, and they're like "Tanya, we can't-- We're not going to stop. Are you kidding?" "No, just ignore that.

Of course we're not going to stop. But here's what we're going to do, let's dig into the backlog and let's-- We're going to branch off here, and do this--" No, right?

Guy: Yeah.

Tanya: So I think that actually speaking to developers and having a conversation, which is hard, listening to someone else's point of view and what they actually need.

Like operations folk, they want stuff to not crash and fail, and developers want to create a thousand new features. Security people are like, "Could just all of that be done securely please?" Communication is hard.

Guy: Yeah. So how do you do it? Accepting the parameters, I have mine with as well, that you want to switch security work to be sprints. What does a security sprint look like?

Tanya: Definitely we need to break things into smaller pieces. Let's say you want to do static application security testing, or a code review.

So previously, it was like "Let's run this giant, really expensive scanning tool for 16 hours, and then spend three weeks investigating the hundreds of pages of results. Then there's going to be maybe two hundred results, and then we give those to the developers and the developers are annoyed."

Instead, what if we run the scammer but we only look for one bug class? Let's say we just look for injection vulnerabilities, and we managed to get through all of the code, and then we just give them that one type of bug. This one sprint.

We attach to it, "Here's how you fix it," and then we try to just obliterate the one bug class. Then in the next one we try with another one bug class. I realize that's not as thorough, but we're sprinting.

And the idea is if let's say you manage to find all the injection things in that one sprint and then you've taught developers how to fix that during that sprint, because those people made that mistake somewhere.

Then the hope is that they're not going to keep making that mistake later, because they learned it in that sprint that might not be perfect.

Another thing that I've been experimenting with is having another pipeline. You have the one main pipeline and it goes, Dev, QA, let's say UAT, Prod and then it goes out into the wild.

What if you had one that went from Dev to another different spot that's not connected, that goes nowhere. Then I get to run every test I've ever dreamed of.

But it's not publishing, and it's not slowing anyone down. It's off on another instance in the cloud, it is not bothering you and it's not ruining your Dev server. It's going to nowhere.

It doesn't publish, or it does to like this one area that's like the security area. I run my 18-hour static code analysis on it, but only I receive those results and developers don't see those.

And I can fool around with them for three weeks if I want to and then I come back with "OK. I found a bunch of memory leaks, and here's where they are, and maybe half of them don't exist anymore because the code is changed. But I've had enough time to deep dive into that and not stopped everyone and made them wait for me."

Guy: This is like asynchronous testing.

Tanya: Yes, exactly.

Guy: The first one is more about the large units that break it up.

Tanya: Yeah.

Guy: This is more about, "Can you take a bunch of these testing be out of band?"

Tanya: Like parallel security pipeline, asynchronous pipeline. Another idea could be, for instance, I worked at a bunch places where we paid a small fortune for a pen test. Then we get the results and we go through and we're fixing them, and I'm like "This is a shopping list.

Those developers create all of our other apps, and I'd like you to take this shopping list and go shopping with all of our other apps please."

"Are we using RC4 on these servers from whoever provided them to us? Because we were using a third party infrastructure team that did not work for us directly."

Like, "Hello. I would like you to go check all of our servers." "You mean for this app?" I'm like, "No. 100% of them." Because it shocks me, we had RC2 on three out of hundreds of servers.

I was like "This is no!" So I used those pen test results to look for all sorts of other things, but someone recently was telling me that they took those pen test results and they turned them into unit tests.

So once the thing was fixed, they're like "OK. So we have unit tests on some of this code, great.

I'm going to copy the hard work of this developer, I'm going to copy their unit test and then I'm going to add in this payload that they created as part of the pen test.

I'm going to add it to that so when they run their unit tests they're going to run these extra couple of tests to make sure that we don't regress back to that and make that same mistake by accident somehow."

Unit tests are really fast, so if we add 10% more tests it's still really fast.

As long as we keep up the maintenance on them or work with developers so they're not like "You just added 10% more work to my backlog, I don't like you."

If we could partner on that, which means security teams that understand how to write tests, which is not always the case.

Guy: OK. Cool. Some good short stint with some concrete advice here.

So one, take up your tasks. Take these security actions and try to break them up into something you can actually complete in a couple of weeks, which is the same as you do in development.

Two, maybe create an asynchronous pipeline so that you can tap into maybe the automation a bit, and not everything can be run in the pace of the build. So you could run them on the side but still tap a little bit into the automated workflow.

Tanya: Yeah.

Guy: Then maybe try to embed or automate some of those results, or the unit tests into those components.

Which I guess is, at this point you're collaborating with the Dev team, or maybe you built up some Dev skills within the security team.

In between it's frankly just a good idea, even above and beyond DevOps is to say "OK, if you've bothered doing the effort or the cost of doing a pent test in one app, to share and bring that across to different teams.

Because it's likely that there's some practices here, or maybe even some shared code components, so these same vulnerabilities exist there."

Tanya: Definitely.

Guy: What do you think about who owns the results? For instance, like you described a whole bunch of things around, "I ran this analysis and some miraculous AppSec person ran through those results and went through and gave them to Dev to fix."

I always have some challenge a little bit with-- It's like, on one hand "Yes. For sure. Minimal disruption to the Dev team, or maybe less effort. But is that the right way to do it in your mind?"

Do you need to scale the AppSec team accordingly, or do you think it's more about rolling a lot of these into Dev? How do you see that?

Tanya: I think it depends on the team and their capacity and their knowledge. I know some AppSec teams where if it's one or two lines of code, they just go and fix it and create a pull request.

They're like "I'm right there. I'm verifying the bug. I see it with my eyes, and I'm just going to do it because it's faster." Then bigger things they check into the backlog.

I think a lot of it depends on speaking with the developer team and the business people sometimes, because I have definitely had business people tell me "We're going to do all of that after we launch the product in 1.1, not 1.0."

Some things can wait for sure, and as a security person I'm wicked biased, I want it to be perfect from a security standpoint.

I'm lucky because I know I'm super biased, and so I try to remind myself "Tanya, you are super biased. You want 100% of things fixed." But often the businesses think, "I don't need any of them fixed."

So it's a negotiation as to which things need to be fixed and which things don't. Also, I've checked a lot of things in the backlog before and then caught my lead developer marking them as fixed behind my back, and I walked to his desk-- It's so funny because I use--

We're friends, my friend Ahmed. I'm like, "Ahmed. I saw you." Then he turns bright red, and I'm like "Negotiation time."

So he's like, "These two are going to take forever and this one doesn't seem like a big deal." Then we would discuss and then I would put one back in, and then two were for the following sprint, etc.

Or, "Maybe we can knock one off and accept the risk," but I'm like, "This is not a decision for you, buster" and he's like "Our last lead would never notice this."

So, definitely you need to communicate, but know that security bugs are bugs and usually developers fix bugs, but we have to be realistic.

Just because I found a low level bug does not mean that it's an emergency.

Guy: Yeah. I like the product analogy a little bit, like product management manages the backlog of priorities of capabilities per the needs.

In a perfect world security capabilities would just be a part of that backlog and there would be a full appreciation of security there.

Maybe in the runner-up perfect world there is an allocated security investment that is being made, and the security person manages that backlog.

Then in the reality is none of that is defined. There is implied-- You have somebody who's good at making friends like yourself, who convinces the Dev teams to do it.

Does that make sense to you? How does that align--? Is it the product analogy, or is it more the Dev QA that if you find a two line--?

Because you wouldn't really find a product manager saying "This is just a small feature, I'll build it." That doesn't happen.

Tanya: No.

Guy: Do you think it's more the product analogy, or is it more almost outsource development a little bit with expertise? Are all of these analogies flawed?

Tanya: I think every single Dev shop is different, and I also think that I've had friends and colleagues say this before that there's a Tanya factor. Sometimes I give advice and people are like, "That only works for you, Tanya."

So I'll get a table at a restaurant really fast because I smile and I'm really friendly and outgoing and I will get better service, and I'll say to my friends "You just go and you just do this."

"No, that's the Tanya factor. Your big smile and you're charming and flirty all the time, you never turn it off so you get these things other people don't get."

So that Dev team listening to me, while I was the boss of the Dev team. Or when I switched to security I had previously been the boss of the Dev team, so again, they're my friends.

I've made them cute little stickers that are all at their desks, so I had a different relationship with them and it's not as friendly at every office.

Eventually I started trying to attract developers into becoming security champions, and those people would champion those things for me on the team.

As I went to larger and larger Dev centers because the place where I started doing security was so small compared to places I worked later, where I was outnumbered exponentially.

If you're working where there's 50 developers and you, it's not the same as 400 or 2,000.

When I went to the place that was 400 I looked at all the metrics, "OK everyone here is allergic to security headers, and people are huge fans of writing cross-site scripting into every app. OK, great."

So I wanted to try to eliminate those bug classes as quickly as possible, just to have a really big fast win, because I'd just arrived. "Aren't you glad you hired me?" "Yes."

So I helped luncheon lines with deep dives into these topics, and dared them to go run the tests on their legacy apps, and dared them to go do things.

Then people started becoming my champions for me, and then it's not Tanya convincing them, it's their own lead of their own team convincing them.

That is a person they trust, so I have to convince these four people that these four people go out and convince the other 25 people. It slowly was growing like that, and that is the thing that isn't me-specific.

It's about the right person identifying themselves. I find security advocates self-identify if you're paying enough attention.

Guy: Yeah. OK. That is also like a scale element, like you can scale through automation through writing the unit at it's element.

You can scale through hiring more AppSec people and then those AppSec people maybe can take on some security responsibility and build tests, or fix minor bugs into the team, or you can scale through security champions.

Whether it's a program or it's the Tanya factor, you make people around be champions and figure out the gap that you need to close to get them to that point. That sound about right?

Tanya: Yeah. It's also a great way to recruit to the AppSec team, because that's how they got me. This really cool guy named Eric said "There's this security incident, you want to come check it out?"

I did and then I asked if I could sit in on another one, and before you knew it I was managing incidents. I told him "I don't know how to manage an incident. "

He's like, "You've seen me manage a bunch. I'll be right here, I'm going to assist you." Then before I knew it he wasn't even in the room anymore.

"Oh my gosh, I'm managing incidents." So he turned me into the security champion. It took me a while to realize he did that.

Guy: Is your guess that he did it intentionally, fully intentionally?

Tanya: Yeah. He is a smart man. He's a smart, smart man.

Guy: This could be another episode about social engineering.

Tanya: Right?

Guy: Security people are good at social engineering. Why didn't you social engineer more people into security and solve the security talent shortage?

But let's talk a little bit about that, about pulling people into security. You seem to be paying it forward, or maybe looking to do unto others.

Pull some others hopefully a little bit less kicking and screaming into the world of security, and you do a whole bunch about this.

But I think maybe we start with Mentoring Monday. Do you want to tell us a little bit about it?

Tanya: Yes. I joined security because I had a mentor, and quickly I found new even more amazing mentors, and I am really lucky that people seem to see possibilities and potential in me.

Then I have noticed that if I pay my attention to someone else and show them the things that I know, that they can blossom in ways I never even dreamed or they never even dreamed.

So people start asking me to be their mentors, and I said "I already mentor four women." I honestly, I feel like I don't even give them enough of my time, and I still haven't figured out how to make a cloning machine.

So until then, I thought "I'll just find you a mentor." I started introducing people to each other one on one, which took a lot of time.

Then one day I just tweeted this hashtag Mentoring Monday, like "Are you looking for a mentor? Are you willing to share what you know with someone new to you?"

Then people started matching themselves, and people started searching the hashtag each week so people that are maybe less public about their offerings, they'll see someone's call for a mentor and then they're messaging them directly.

They're having private conversations and branching off, and several people have written me the most wonderful messages about how "I now have these two people in my corner who are giving me advice.

One's giving me career advice and one of them is giving me technical, things like 'Read this book,' or 'You should ask for a raise,' or 'Have you tried applying here?'"

All these people that are senior in our industry who didn't even realize--

If you've done your job two or three years you know enough to teach someone else. Because otherwise you'd be fired, right? If you still have this job it's probably because you're good at it.

So a lot of people who thought "I don't know enough to be a mentor," I was like "Do you know enough to do your job?

Because there's someone who wishes that they could have a job like yours. There's someone who wishes that they knew when they looked at the sim, what all of that stuff means.

There's so many people who are interested in pen testing, and then a lot of them end up learning like I did, that they actually want to work in AppSec, or they actually want to build cool tools to help people do testing."

The more people you have in your corner that are willing to give you just even an hour of advice one on one, it's so valuable. Just so many senior people have told me that is so rewarding to see the person they're mentoring break through every goal that they had.

I have to say the people I'm mentoring, it shocks me how they're like "I would never speak," and then they're speaking all over Europe.

Or one of my mentees is coming with me and we're speaking at AppSec Europe together. She said, "I will never ever speak, Tanya." She now hosts a streaming show, she started her own company.

It's like, "Wow." She just keeps setting bigger goals and then destroying each one of them. Sometimes it is just having someone that introduces her to the right person.

Guy: Give us some examples, to inspire the listeners a little bit. Maybe some examples of topics that people reached out to mentor on, or to be menteed on.

Tanya: A lot of people are interested in learning about forensics. Like, "How do you break into that?" Or people want their very first AppSec job.

A lot of people who used to work in networking, they want to work on a sim. They want to be an information security analyst, and they just have no idea where to start.

They've got a demo of a sim and they're like, "What does that mean?" Or a lot of people come to me and they're like, "I want to be a bad ass hacker," and I'm like "You probably shouldn't ask me because I'm a Care Bear hugging AppSec person."

But when they learn just how to run a scan for the first time, I'm like "OK. Now what do these results mean?" They look at me with these wide doe eyes, and I'm like "Go. Go off and try to figure them out. I want you try to fix above," or a lot of people are interested--

They're security people, and they're like "I want to learn about DevOps. There's like 5 million books, which one do I read?" I'm like, "OK. Read this book, then watch this talk, then read this book, then follow this guy."

The things that have helped me the absolute most can give someone a more direct path.

Like, I met Troy Hunt in Australia and I told him I'm receiving 500 or more messages a week and I don't understand how to answer them all.

He's a billion times more famous and well known, and probably receiving many more messages, so he gave me a lot of really helpful advice about how to prioritize my time so I could help the most people.

It's not helpful for me to write a one hour message to each person. Instead, he's like "Write a blog post about that and share it to everyone. Because if one person had the guts to write you and ask you, a lot of people want to know."

So asking someone that has success in the areas you're interested in, and I was just so happy he spent 45 minutes talking to me. He's like, "If you have more questions just write me, it's cool." "Thanks."

Guy: I think you never finish the need to learn, or there's always good advice to receive. It's always an experience that you have that is a good idea for you to share.

So this is if people want to engage in this, this is on Monday I imagine?

Tanya: Every Monday. Yeah. Just either you can respond to my tweet to Mentoring Monday, or just tweet your own with the hashtag-- You have to use the hashtag.

A lot of people are responding to my tweet and they don't use the hashtag. What that means is if a less attention seeking or more likely just a shy person, rather than them tweeting or they don't want to be overwhelmed--

Some people told me they've had 25 people answer their tweets. So, use the hashtag so that they can search and find you, and if you are a person who is more senior, respond to tweets or search the hashtag and look for someone that's looking for what you want.

If there isn't anyone, just offer. People will be over the moon to respond to you. If too many people respond to you, have coffee with each one and choose the right one or two or three that you feel, and then set the others free.

If you don't have time, it's okay to say no, and then send them back to me and I will keep sharing and matching people until they find someone.

Guy: Cool. That's a great mentoring matchmaking. I think the other activity you do around inclusiveness and security is around women in security.

Let's dig into that one a bit. You started a group, the Women of Security?

Tanya: We're pronouncing it "Wo-Sec." I know, it's hard.

Guy: Yeah, pronunciation is hard. Try tweeting, "How do you pronounce Snyk?"

Tanya: I tell people it's called Snyk, and they're like "Really?" I have a couple really cool friends there in security that are women in Ottawa. I'm selfish, I wanted to make more cool friends.

So I have 500 male friends, and then three female friends that worked in security.

And in Israel there's this cyber ladies thing and they all got to me all sorts of cool women that they're friends with now that work in security.

Then there's networking opportunities and all of that, so my friend Don and I decided we would start our own thing in Ottawa, and we made a little meet up.

Then we're thinking "Hopefully Nancy shows up and the three of us can have branch." Then 25 women showed up, and we were astounded. So we're reaching 1 year old this month. I know.

We have 250 members in little teeny tiny Ottawa, and they're all women, and we have 10-20-30-40 women that show up every month to brunch, so we call it Brunch and Bitch.

Then we started crashing boy meet ups, so a while ago I wanted to go to Capture the Flag. So I had tweeted and put on LinkedIn, "I want to start a Capture the Flag team but I don't want to be the only woman there."

I ended up having so many women respond we made two teams, and actually there were so many women there and we dressed up and looked cute, because women like doing that sometimes.

I wore this cute polka dot dress and we ended up making the news twice because so many women crashed this event. We started this thing where we'll crash an event together, so we sign up and we follow the rules and the code of conduct and everything, but we go as this big group so it's not scary.

We crashed RSA this year and we had our own little thing where we all got to meet each other, and then we could attend talks together, and you have like new friends and you don't feel intimidated going into a room with 200 men because you have three women with you that are your friends.

At RSA we had a woman breastfeeding at our meetup, it was so amazing that we made such a safe space that she felt comfortable to just do that openly.

Then we also have women only safe spaces for learning where we have workshops or talks where it's just women only. I've given a cloud security workshop, we had another woman do a web app hacking workshop, and women just started writing me.

My friend Doha wrote me from Vancouver, we didn't know each other and she said "What you're doing is cool and I want to do it. How do I do it?"

So she started a meetup, and then this woman Judy from Nairobi wrote me and she's like "What you and Doha are doing is cool. I want to do it. How do I do it?" So now we have 15 chapters and we're just opening up two more today.

Guy: Nice.

Tanya: One in Victoria, Canada and one in Milwaukee. We just opened up another one in Johannesburg, we have Paris, Zurich, Boise, Dallas, San Francisco.

It's so wild to me, like Montreal where they meet in French, in Switzerland they meet in French.

So I started this little Twitter account because I just like tweeting happy stuff about women, and I figured out that no people follow me, @shehackspurple, because they wanted security content.

If I just tweet cool stuff at women constantly, that's a different crowd. So I started this other handle just for my meetup where I just follow tons of women in InfoSec. They aren't even involved, and I'm just like "Congratulations on your new job."

They only have 46 followers, but I'll retweet their cool accomplishment and congratulate them, and invite people to come brunch like badasses with us.

We're crashing Microsoft Build next week, and I convinced them into giving us this huge boardroom that's right after the keynote where we can all meet each other and have friends to go do everything together.

My hope is that people will make friends that last for a long time, because now I have so many female friends in Ottawa and it has resulted in so many things.

Like two women from my chapter started a business together, there was a woman in a very difficult situation which I won't reveal here.

But because I have enough connections in the community I ended up talking to the person's boss's boss's boss's boss, and then he was dismissed for wildly inappropriate behavior in four hours because it came from me.

Then she was in such a trusting relationship with someone else in our group, and then that person trusted me that she would open up about what had happened, and the company was just like "Oh my god, thank you. That's not acceptable and we wouldn't have known."

So we've been having these magical things happen because of trust relationships, and people meeting in person, and we've been helping people find their first job in InfoSec, or find a co-op, or find someone--

Like later today another woman that's in WoSEC, she's like "You're a great public speaker. Will you watch my talk? I'm doing my first talk ever tomorrow," so I'm going to do one on one with her to try to make sure her talk is extra good.

Guy: Because that ties back into that mentoring, just for that specific audience to help it grow.

Tanya: Yeah. So I'm helping women, but then all those other women are helping other women, and it's like passed down and down.

Between someone just sharing their hotel room with another woman so she can afford to go to a conference for the first time, like each one of these things multiplies in positivity.

I'm shocked at how many amazing human beings are like "I want to participate," and they're making it a thousand times better than I ever could on my own.

Oh my gosh, WoSEC is the most happy thing I've ever done. It's brought me so much joy.

Guy: It sounds amazing and like it's making a real impact. So it's WoSEC--?

Tanya: Women of Security. If you just look us up on meet up, or WoSEC Tweets because we tweet.

Guy: Yeah.

Tanya: That's our account on Twitter, and if you want to get involved just message us. Everything's free. That's part of our rules is it's free.

Guy: One of the questions I always have, I'm a big fan of helping make security more inclusive, and frankly the world of tech and security is in a little bit worse shape than others.

One of the questions as a white dude, how can men in the industry help support something like WoSEC?

Tanya: You could offer to host our meetup, you could offer to sponsor a meetup by paying the meetup fees which are $130 dollars a year. You could offer to teach something.

In Nairobi they have men teach and women teach because they want to learn. Judy who leads that is so amazing, she's having lessons every two weeks, intense workshops every two weeks.

She has men, women, anyone teaching. Just offering to teach would be amazing, like a man amplifying a thing that a woman says sometimes will let other men want to see it more, if that makes sense.

If I amplify a thing that a woman says, lots of women will listen and a lot of men will listen. But if a man retweets a thing or comments positively on a thing that a woman does, sometimes that means more to other people, to men and to women.

Just doing that little thing, or partnering with a woman on things. This year I've made a huge personal goal to try to collaborate more with other people, so I've been collaborating with other women and other men.

I'm doing like a lot of joint talk submissions, even though I'm like obsessive and I'm a control freak and I know this. It's really hard for me, because I'm like "I'll just write the entire talk, OK?" And they're like, "No. We're collaborating."

So I'm trying really hard to get outside my comfort zone and do that, and then that shares my spotlight with another person.

If you give a talk with a woman and you could do it on your own, you totally could, but doing it together means you share the spotlight together and also they'll have all these different amazing ideas to add to your talk.

If you are willing to listen, which is hard for me, and I know that. But that's OK. That's another way that you could do things.

I've had a lot of men offer to collaborate with me, and I'm like, "No. Don't collaborate with me, offer to collaborate with someone that no one's heard of but you've seen cool things they're doing."

Don't just pick some random woman that's not doing anything.

Guy: So I try, not nearly enough. One of the challenges that sometimes happens is just finding, because especially if those are people that are a little bit more timid or more shy to know, or they haven't built the renown yet.

Do you have any recommendations for lists of Twitter accounts to follow, or places to find these great women that do security work?

Tanya: WoSEC Tweets follows 2,500 InfoSec ladies who are doing lots of cool things. What we did is we just asked, "Are you doing cool things and InfoSec and want us to start retweeting you? Because we will follow you. Just please self-identify."

Then over two thousand women did, which was cool. Also Irena Damsky has a list just on her Twitter, and I think it's called "Cool InfoSec hacker women," something like that.

So if you just go to Irena Damsky she has a long list of maybe 4-500 really cool women that she's met that she knows are good speakers.

I have a private list that I give if someone invites me to speak and I can't make it, I suggest "Here's 15 other women who I have seen speak who I respect greatly, and I'd like you to consider choosing one of them instead of me."

I'm trying to encourage all the other women in WoSEC who speak to create a list of two or three other women that can speak if they can't make it. I get a lot of invites, as you might imagine.

Guy: Yes.

Tanya: So if I can't make it, I try to recommend those. Also of course, you should interview all the women that are part of the OWASP Dev slop project. I feel like recommendations really help.

For instance, you've had me on your show, and you can recommend me to someone else. Your recommendation-- Because you do lots of cool stuff, Guy.

Your recommendation is worth a lot. You could use your recommendation a bit more liberally.

Guy: I think in general, Tanya, this is an excellent list of very concrete things that you can do that frankly don't require that much effort as much as intent.

If you follow the right voices, so you make that effort, and then all you do is pay attention and amplify. Whether it's a retweet or it's an email, or it's a recommendation or a tip.

It's probably even from a confidence perspective, just a reply with a strengthening statement. That goes a long way.

Tanya: Yeah.

Guy: I think all of those are very concrete, very immediate, and really great tips for everybody. But specifically, including white, bearded dudes like myself to help participate without being overbearing.

Tanya: Thank you for asking. I really appreciate that you asked, instead of telling. Thank you. You're awesome.

Guy: I appreciate that. So, a lot here. A lot of great tips. We've gone-- I do feel like to an extent there's this theme of inclusiveness throughout the element.

We started with a little bit things that might not fall under that title, around the Dev Ops tips and splitting tasks into work, and I really love this conversation around inclusion both from a mentoring perspective and from women in tech.

It's probably worth saying that we talked about the Women in Security initiative here, but there's other similar wants around, like underrepresented minorities.

We could probably do another episode, there's a whole ton of stuff to talk about.

Before I let you off the hook here, I like to ask every guest that that comes on the show if you had one tip or if you have a pet peeve or something like that you want to get off your chest, to a team looking to level up their security game. What would that be?

Tanya: OK. Some security people are going to get really defensive and angry when I say this, but I don't feel that it is ever acceptable to respond to a developer who has asked for help with a specific question-- So they're asking specific advice about something, to never reply with "Read this book."

I mean if someone's like, "What book should I read?" Of course, read that. But I was asking someone for help specifically with advice for GDPR for a serverless app and it was really specific advice.

And he wrote back, "Read this book." I said, "Clearly you don't have time or don't want to help me. Could you please recommend someone who actually will?

Because clearly I'm not going to read an entire book in the next week, because that's how much time I have to make these changes. Do you have someone who wants to help me?"

He got really defensive, and yes that was a really rude response on my half, but I wanted to send back something that was way less rude that I won't repeat on air, because to me that's offensive.

To me that's saying, "I don't want to help you. Go away." To me that says, "Go away. I don't have time for you."

If you don't have time, then recommend someone that does have time, or if you don't have time, tell your boss "This is an important thing that I don't have time to address because my workload is incorrect and we need another person."

But telling me to go read the legislation on GDPR, to me that like-- You just gave me the middle finger. That's what you did.

I was asking on behalf of a developer on my team, I'm like "I am not GDPR literate. I know the basics, but I cannot give good advice on this, so I'm asking you and I was told you're the expert. If you don't want to help, don't send me a link to the legislation. I know how to use Google."

Guy: Yeah, it's a very good tip. The information that is out there is not equivalent.

Tanya: Yes. Software developers already know how to use Google, thanks. But I want the genius that's in your brain.

Guy: Yeah.

Tanya: That's what I asked for, and you just said "No." I've just seen so many people send like a link to NIST or something else like that, and it's just the developer that gets that is like "I guess I'll just guess, and also I'll never write you again because you don't want to help me."

So, please stop doing this. Please.

Guy: Yeah, excellent advice. I don't know if it falls under a pet peeve or advice, but in both of those cases it would work very well.

Tanya: It's both.

Guy: So, this was really excellent. Tanya, if somebody wants to-- You mentioned a little bit, but if someone wants to find you on the Twittersphere or the likes and ask you further questions, how can they find you?

Tanya: I am @shehackspurple on Twitter, and also I have a blog that is SheHacksPurple on Dev.to and Medium. If you just look up "She hacks purple," you're going to find a whole lot of Tanya.

I have a YouTube channel now too, it's just YouTube.com/SheHacksPurple. I'm trying to be that thing. I'm going to make a website someday. Anyway, it has to be the world's most secure website, right? I feel the pressure is really on.

Guy: Static websites for the win.

Tanya: Thank you so much for having me, Guy. I really appreciate you and all the work you're doing in our community,

Guy: Thanks a lot Tanya, for the great advice and for your work as a whole. Thanks everybody for tuning in, and I hope you join us for the next one.