https://shehackspurple.ca/blog/

All of the streams are free, and I would love to have you join us live! If you can’t make it live, you can watch them after on my YouTube Channel, or download them via at podcast app by looking for the podcast “Alice and Bob Learn” (which will be launched right after the first stream).

Ideally you will read the chapter before the corresponding live discussion, but if you don’t, that’s okay. You will still learn, and you are definitely will welcome to attend. :-D

Schedule:

All streams are in 2021, on Saturdays, starting at noon pacific time. They can last up to three hours.

March 20: Chapter 1; Security Fundamentals

April 17: Chapter 2; Security Requirements

May 15: Chapter 3; Secure Design

June 12: Chapter 4; Secure Code

July 10: Chapter 5; Common Pitfalls

August 7: Chapter 6: Testing and Deployment

September 4: Chapter 7; An AppSec Program

October 2: Chapter 8; Securing Modern Applications and Systems

October 30: Chapter 9; Good Habits

November 27: Chapter 10; Continuous Learning

December 11: Chapter 11; Closing Thoughts

When I started my quickly-failed startup in 2019, Security Sidekick, Bar Hofesh reached out to me to see if he and Gadi Bashvitz could help. I was pleasantly surprised to have several people in my industry reach out to me, and even other small companies reaching out to see how they could help me with my startup. InfoSec is full of kind and generous people, let me tell you.

When I left Microsoft, I had committed to several speaking engagements before I decided to leave, including the 2020 RSA conference, and rather than be in breach of contract with several conferences and potentially ruin my reputation, I completed all of the obligations that I had made while I worked there. But there was a catch: I had to pay for all my travel myself. Bar and Gadi knew this, so they offered me a free place to stay (in San Francisco!!!!!) which I really appreciated. It didn’t work out in the end, but we met up in person for the first time for some Starbucks, and it was awesome.

You know that feeling when you meet someone, and you like them immediately? Bar and I talked nerdy, and Gadi tolerated us. We continued to stay in touch.

Fast forward a few more months and the NeuraLegion tool NexDast was fully developed, and I had started We Hack Purple. We decided we wanted to find an excuse to work together, because we got along so well, and we all feel really passionately about security and changing our industry for the better.

We decided that we would plan a workshop together; I would teach a bunch of cool DevSecOps stuff, we would use Broken Crystals (more on this in another blog post), and demo their product. We made a GitHub action together, we made a workshop together, and of course we found lots of bugs together. It was super, duper fun and a smashing success!

Then Christmas and Hanukkah came, and Gadi called me up. He asked me if I wanted to join their Advisory Board, so we no longer had to make excuses to work together. What could I say? I said yes.

We have so many ideas of fun and awesome things we are going to work on together, to make their product even better, and to give back to the community. In addition to being great people, we also share a commitment to shifting security left and making sure application security is liberated and automated as part of the SDLC, and put in the hands of developers, not just AppSec people.

I’m honoured to be on their Advisory Board, and I feel lucky to have the chance to work with such a talented and fun team.

In the previous article, we talked about how we need to explain to our boss not only which training we want, but we must overcome any objections, if we are going to get it approved. Let’s look at the second objection in our list.

Back in the day I requested approval to take a web-app hacking course, and I recall my boss saying, “You don’t need to learn that; you just need to run the scanner.” My job was web app penetration testing, and it was clear my boss had no idea what I did all day. He seemed to think that manual security testing was unnecessary, and at the time I had no idea how to explain we needed a lot more if we wanted to ensure our apps were very secure. I ended up watching a lot of videos on the internet, playing around, and wasting a ton of time.

When I switched over into Application Security, it got even more difficult, as most of the courses only offered to teach me “the OWASP Top Ten” (which I already knew well), and then the main security controls (authentication, authorization, encryption, identity) and little else. I wanted to know how to do my job, not theory and not basic web app hacking (I already knew that). Plus, they always seemed to go really deep into encryption, but I already knew my teams would never be writing their own encryption, so I didn’t get why they felt the need to always cover it…

Anyway, if you are asking your boss to take training it must fall into one of two categories if it’s going to be approved:

1. It will help you do your current/new job better

2. It will help you grow within the organization so you can get a promotion someday (also known as career development)

Note: If you are a Rudy developer and you asked your boss to pay for you to take a basket weaving course, this blog article is not going to help you. That said, if you are a Ruby developer and you asked your boss to pay for a secure-coding-in-ruby course or an application security course, then this article can help.

Remember I said in the first article that you needed to read the syllabus and keep track of what’s on the course and how it relates to your job? Now is time to get that info so we can write your justification letter. Just like in the previous article, I am going to use the Application Security Foundations Program from We Hack Purple as the example, but you should be able to use whichever training you have choose.

Dear Boss,

I want to take the We Hack Purple Application Security Foundations Program for my training this year. I know you told me that it’s too ‘off topic’ for my job, but I wanted to explain to you how it will definitely help me do my job better.

Right now, our InfoSec team keeps bringing in a PenTester to test our apps right before we release them. They always find 100 things wrong, because none of my dev team knows security. We always end up with late projects and everyone freaking out, because it’s so last minute. Lots of overtime and stress.

Also, the program comes with a copy of Alice and Bob Learn Application Security. I know the one copy we have is currently constantly being used by my team for reference, so having a second copy would be really great.

If I took this course, I would know how we could do this better. The dev team could do some testing ourselves (carefully), and other stuff to make sure our apps are in better shape by the time the PenTester comes. The program has a secure coding guideline we could adopt, and even an API best practices guide. We currently have no idea how to secure our APIs, and we keep reading on the internet and we’re lost. This course would help me understand so much! And then I could be the ‘security champion’ on our dev team, the one everyone can turn to when they need help. I know you feel this is outside my job description, but someone has to do it. I want that someone to be me.

Sincerely,
Your-Name-Here

Up next we will cover Objection 3: There’s no time with your current workload for you to take training.

PS We Hack Purple launched a swag shop, just in time for Christmas! Code securely, in style!

We’ve all been there. There’s a training you really want to take, but your boss isn’t so sure. This can be because it’s out of budget, they feel it’s too ‘off topic’ from your current job, there’s no time with your current workload, they are afraid they will lose you if you have new skills, or some other reason they won’t tell you. Let’s go through all of these reasons and figure out how YOU can get you’re training approved.

Note: I run my own training company, We Hack Purple, that specializes in Application Security, Secure Coding and DevSecOps training. While I am definitely hoping this article helps our customers, I’m also hoping it helps everyone else who needs training! For our examples we will use the Application Security Foundations Program from We Hack Purple, and we will try to justify taking it to your boss.

The first thing you need to do is make sure you are selecting the *best* training for your specific job or career development. Don’t take the popular one, or ‘the cool one’ that people are talking about on Twitter. Evaluate very carefully which one will help you level up in your career and your current job.

Next, read about the content of the training you are taking. Make notes of what’s in there and keep the syllabus handy, as you will likely need to reference it as you write your justification. You also want to have some other links to other courses to compare it to; both to explain why the one you have selected is better and why it’s (hopefully) more cost-effective.

Let’s start creating our defenses for your boss’s potential objections.

Objection 1: We don’t have the budget/it’s too expensive.

This is the one that I personally have received the most often in my career. I have actually had a boss laugh in my face when I suggested one single course that would have cost my combined training budget for 5 years. I explained that cyber security courses are quite costly, and all of my bosses continued to reject my requests. I ended up selecting training from several different places that was cheaper, but nowhere near as good as what I had asked for. At the time I didn’t know how to get around this hurdle.

With a little more industry experience and a chance to see a lot more training, I realized that I needed to explain the value of what we were getting was greater than what we were spending. Let me explain using the We Hack Purple Application Security Foundations Program as the example (but this should work with whatever you have chosen, if you have chosen the best training for your situation).

Dear Boss,

I want to take the Application Security Foundations Program from We Hack Purple for my training this year. I know you feel it’s too expensive and that we might not have the budget but let me explain how I think it will save us more money than it costs.

We keep hiring consultants to help us with our AppSec Program, and that is very expensive. And we haven’t been getting the results we want, they show up and write one policy or one guideline, then leave. This program will provide some starter policies, standards and guidelines, so we don’t need to pay that consultant anymore. After taking the training I will know what to do and have tools to start with so I can hit the ground running.

We also keep changing our strategy, because we haven’t been getting the results we want, and the dev teams don’t seem to be ‘on board’ with what we have been doing. This program will not only help me build and plan an entire AppSec program throughout the three courses, in Level 2 of the program there’s an entire module to teach me how to support our culture change (advocacy), how to build a security champions program, AND how to make presentations that aren’t the death-by-PowerPoint that we are used to giving. They even show us how to measure the effectiveness of our program, so we know if the strategy we are using is actually *working*, so we can know when we need to change or stay the course. Right now, we are just guessing at what to do to make sure our software is secure, but with this program, I would know.

I realize that $999 USD is a lot, and we are a small company. But this is the only training I could find like this on the internet, one that will teach me how to build and launch an AppSec program. That’s what the company needs me to do. Please approve this training so I can get started.

Sincerely,

Your-Name-Here

Up next we will explore Objection #2: They feel the training you have selected is too ‘off topic’ from your current job.

PS We just launched a swag shop, just in time for Christmas! Code securely, in style!

All of the books listed are available in audiobook; my preferred reading format.

We are covering this topic for several reasons, but the one that makes it relevant to this membership is that when Tanya, the founder of this company, used her social media accounts to share her support for those fighting oppression and system violence and racism in America (using the #BlackLivesMatter hashtag), all online sales at shehackspurple.dev stopped.

ALL sales stopped. For TWO WEEKS.

There are usually a handful of sales per day at SheHacksPurple.dev, but it took almost 3 weeks for our first after-Tanya-tweeted-about-BlackLivesMatters-sale to happen, and over 4 weeks for sales to go back to normal. There could be several reasons for this, such as people spending their time demonstrating and protesting instead of buying AppSec training. It could be that we did less less tweeting about our products and membership during that time, to give voice to more important things. The economy could have slowed down to covid… But… It’s hard to shake the feeling that the two were related.

As a company, we felt supporting those who suffer systemic oppression and violence was worth losing out on a couple thousand dollars in sales.

With this in mind, we are going to review books that cover how technology can be trained to be biased, and how algorithms and systems can have bias designed directly into them. We are also going to discuss a book that discusses how to change public policy in order to reverse and/or stop bias within governmental processes, laws and systems that harm marginalized groups.

Book #1 Technically Wrong

Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech

Written by: Sara Wachter-Boettcher

This book is an excellent introduction to the idea that data can be biased and that algorithms can reinforce racist, sexist, homophobic and other societal discriminations. As someone who already considers herself somewhat aware of these problems, has attended several lectures on how to abuse AI/ML, and has a long history in the tech industry creating technical solutions and systems, this was not news to me. That said, the author covers several different ways that bias can sneak itself into these systems and makes it extremely clear to the reader how this can happen by accident, or by negligence. There are several stories of real people who are affected by these issues, and also quite a lot of statistical information proving that the issues are widespread. I found the book extremely easy to listen to and almost ‘light’ in the way it is written, despite the fact that it is about a very serious topic. For someone who is not already well versed in this topic, this is an excellent introduction. If you are like Tanya and have already read other books on this topic, you may want to start with the second book (below) in this review. However, if you are recommending a book to someone who doesn’t know anything about this problem with tech, or who you are trying to convince that there is indeed a problem, this book is perfect.

Book 2: Algorithms of Oppression

How Search Engines Reinforce Racism
Written by: Safiya Umoja Noble

This book is written a bit like a PhD or a master’s dissertation; it is highly technical, with many, many references to other people’s work. The narrator speaks a tiny bit like a robot, but if you can get past that, this book is enlightening. This is not a light read; this is not only due to it being quite technical in nature, but also due to the very serious subject matter. As someone who is interested in this topic, I found this book illuminating. The author covered several instances that I had never previously seen in conference talks or articles, as well as provided numerous references, quotations, studies, and other statistical information as supporting evidence for each point she made in the book. That said, this topic is tough. I was unable to listen to the entire chapter on revenge porn, as I found it too distressing. Both authors, from the book above and this book, call for the recruitment of experts in black studies, women studies, Jewish studies, LGBT studies, etc. to large high-tech companies, in order to ensure that these types of issues are not overlooked when designing the systems that so many of us use on a daily basis. The author points out that expecting someone with only an engineering or software development background to understand the complexities of ensuring that software is not biased is going to continue to lead to our current disappointing results in the many examples she illustrates throughout the book. I feel that she proved her point, over and over and over, and made me feel that the situation is urgent (it is). She also suggested solutions that are actually achievable without that much effort (when compared to the changes the next book suggests), and that I hope tech giants implement in the near future.

If you design technology systems, or design or train machine learning algorithms, you need to read this book.

Book 3: How to Be an Antiracist

Written and Narrated by: Ibram X. Kendi

This book reminds me of Invisible Man, Got the Whole World Watching, by Mychal Denzel Smith. In both books, the author explains how he became aware of how his own biases affected others via personal stories of his life. However, in How to be an Anti-Racist, the author also explains how various policies, systems, processes, laws, and other structures of society, can be and are racist, sexist, or otherwise discriminating. The stories he shares are deeply personal, vulnerable, and telling. He breaks up his intimate narratives of self-actualization with explanations of various policies, court rulings, cultural situations from the United States, and systems that harm black lives. He also provides ideas for solutions, improvement and harm reduction which are a breath of fresh air. This book is touching, thought provoking, and it may cause you to question some of your previous decisions, ideas, and more-private thoughts. I strongly recommend this book, for anyone.

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

The Second Way of DevOps is fast feedback. In security, when we see this we should all be thinking the same thing: Pushing Left. We want to start security at the beginning of the system development life cycle (SDLC) and ensure we are there (providing feedback) the whole way through!

The previous post in this series is here.

Fast feedback loops means getting important information to the right people, quickly and regularly. One of the main reasons that Waterfall projects failed in the past was the lack of timely feedback; no one wants to find out twelve months after they made a mistake, then they can’t fix it.

The goal of security activities in a DevOps environment must be to shorten and amplify feedback loops so security flaws (design issues) and bugs (code issues) are fixed as early as possible, when it’s faster, cheaper and easier to do a better job. These DevOps people are really onto something!

Let’s go over several ideas of how to achieve this.

Activities to create fast feedback loops.

• Automate as much as humanly possible. Inside or outside the pipeline, automation is key.
• Whenever possible integrate your tools to the Dev and Ops team’s tools. For instance, so that the issues found by your IAST tool are turned into tickets in the developer’s bug tracking system.
• When you have a Pentest done check all your other apps for things in the report, then add create unit tests to look for these things
• Rename insecure functions or libraries as “insecure” with a wrapper, so programmers see immediately that there is an issue.
• Add security sprints to your project schedule (to fix all security bugs in backlog)
• Asking the Dev and Ops what they are concerned about (in relation to security), so you can fix any problems the security team might be causing them
• Add important security tests that are quick to the pipeline. For instance, scan for secrets in the code that is being checked in. That is an important test!
• If an important security tests fail in the pipeline, the continuous integration server must break the build. Just like quality tests. This is loud feedback.
• Create a second pipeline that doesn’t release any code, but runs all the long and slow security tests, then have the security team review the results after and turn the important things into tickets for the Devs.
• Tune all security tools as much as possible and validate all results so that the feedback you are giving is *accurate*. There is no point of sending lots of feedback if half of it is wrong.
• Work with developers to create negative unit tests (sometimes known as abuse tests). Create copies of regular unit tests, rename them with “Abuse” at the end, then add malicious payloads and ensure that your app fails gracefully and handles bad input well.
• Have reports from your security tools automatically send their results to a vulnerability management tool such as Defect Dojo or Thread Fix to keep metrics and use them to improve all of your work. You need feedback too.
• Be creative. Any way that you can get feedback faster to other teams is a huge win for your team too!

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

Security is Everybody’s Job — Part 6 — The Second Way was originally published in DevOps Dudes on Medium, where people are continuing the conversation by highlighting and responding to this story.

The previous article in this series is here. If you are lost reading this article, read the whole series from the start. :-D This is a long post, sit tight!

The first “Way” of DevOps is emphasizing the efficiency of the entire system. Many of us tend to focus only on our part of a giant system, and get bogged down improving only our own contributions to the larger process. It’s rare that we stand back, look at the entire thing, and realize that if we helped another team or if changed something small within our part, that it could improve other areas for the better. The first way of DevOps is about looking at the entire system, and making sure the entire thing is as efficient as possible. #speed

When we worked in Waterfall development environments security often acted as a gate. You had to jump through their hoops, then you were let through, and you could push your code to prod. Awesome, right? Not really. It was slow. Security activities took FOREVER. And things got missed. It was rigid and unpleasant and didn’t result in reliably secure software.

It may seem obvious to new developers that security should not slow down the SDLC, but I assure you, this concept is very, very new. When I was a software developer I referred to the security team as “Those who say no”, and I found almost all of my interactions with them left me frustrated and without helpful answers.

When we (security practitioners) think about The First Way, we must figure out how to get our work done, without slowing down all the other teams. They won’t wait for us, we can’t set up gates, we have to learn to work the way they do. FAST.

Below I will offer several suggestions for how we can work together with the dev and ops teams to ensure we get our mandate done, within the DevOps workflows and processes.

First of all, we need to use modern tooling that is made for DevOps pipelines if we are going to put anything into the CI/CD pipeline. Never take an old tool and toss it in there; no DevOps team is going to wait 5 hours for your SAST tool to run. Tune your tools and ensure you select tools that are made for pipelines if that is how you are going to use them. Whenever possible, only run your tools on the ‘delta’ (the code changed in that release, not the entire code base).

When selecting tools, remember that not every tool needs to be put in the pipeline. In fact, having tools that are out-of-band, but located on the ‘left’, can offer even more value and save time. Examples:

• package management tools that only serve packages that are not known to be insecure (pre-approved by a security research team)
• adding security tests to your unit tests, which are often run before the code arrives in the pipeline (for instance, write input validation tests that ensures your code properly handles input taken from the XSS Filter Evasion Cheat Sheet)
• adding security tooling to the check-in process, such as secret scans (don’t even let them check it in if it looks like there’s a secret in the code)
• scanning your code repository for known-insecure components. It’s just sitting there, why not use it?

This also means that security bugs should be placed in the same bug tracker or ticketing system that the developers and ops teams are using. They shouldn’t check two systems, that is not efficient.

If at all possible, we should be providing and/or approving tools that assist in finding vulnerabilities in written code (both the code your team wrote, and the code from dependencies) and running code. This could be SAST + SCA + DAST, or it could be SCA + IAST (run during unit testing, QA and in prod). It could also mean manual secure code review plus a PenTest the week before going live (this is the least-efficient of the three options presented here).

If it makes sense, create templates and provide secure code samples, there’s no need to reinvent the wheel. Also, enable the developers and ops teams to scan their own code by providing tools for them (and training on how to use them safely and effectively).

Think Outside The Box

We (security) can no longer be a bottleneck, we must work to enable them to get their jobs done securely, in anyway we can. Examine your processes to ensure they are efficient; create a second asynchronous (which does not release to prod) pipeline to automate your longer tests; write your own tools if you absolutely have to. The sky is the limit.

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

Security is Everybody’s Job — Part 5 — The First Way was originally published in DevOps Dudes on Medium, where people are continuing the conversation by highlighting and responding to this story.

The previous article in this series is here.

In this post we will explore The 3 Ways of DevOps. But first, a definition.

DevSecOps is Application Security, adjusted for a DevOps environment.

-Imran A Mohammed

DevSecOps is the security activities that application security professionals perform, in order to ensure the systems created by DevOps practices are secure. It’s the same thing we (AppSec professionals) have always done, with a new twist. Thanks Imran!

Refresher on The Three Ways:

1. Emphasize the efficiency of the entire system, not just your part.
2. Fast feedback loops.
3. Continuous learning, risk taking and experimentation (failing fast)

Let’s dig in, shall we?

1. Emphasize the efficiency of the entire system, not just one part.

This means that Security CANNOT slow down or stop the entire pipeline (break the build/block a release), unless it’s a true emergency. This means Security learning to sprint, just like Ops and Dev are doing. It means focusing on improving ALL value streams, and sharing how securing the final product offers value to all the other steams. It means fitting security activities into the Dev and Ops processes, and making sure we are fast.

2. Fast feedback loops.

Fast feedback loops = “Pushing Left” (in application security)

Pushing or shifting “left” means starting security earlier in the System Development Life Cycle (SDLC). We want security activities to happen sooner in order to provide feedback earlier, which means this goal is 100% inline with that we want. The goal of security activities must be to shorten and amplify feedback loops so security flaws (design/architecture issues) and bugs (code/implementation issues) are fixed as early as possible, when it’s faster, cheaper and easier to do a better job.

3. Continuous learning, risk taking and experimentation

For most security teams this means serious culture change; my favourite thing. InfoSec really needs some culture change. In fact, all of IT does (including Dev and Ops) if we want to make security everybody’s job.

Part of The Third Way:

•Allocating time for the improvement of daily work

•Creating rituals that reward the team for taking risks: celebrate successes

•Introducing faults into the system to increase resilience: red team exercises

We are going to delve deep into each of the three ways over the next several articles, exploring several ways that we can weave security through the DevOps processes to ensure we are creating more secure software, without breaking the flow.

If you are itching for more, but can’t wait until the next post, watch this video by Tanya Janca. She will explain this and much more in her talk Security Learns To Sprint.

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

The previous article in this series is here. was originally published in DevOps Dudes on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are many definitions of DevOps

Link to the previous post in this series.

There are many definitions of DevOps, too many, some might say. Some people say it’s “People, Processes, and Products”, and that sounds great, but I don’t know what I’m supposed to do with that. When I did waterfall I also had people, processes, and products, and that was not great. I thought DevOps was supposed to be a huge improvement?

I’ve heard other people say that it’s paying one person to do two jobs (Dev and Ops), which can’t be right… Can it? I’ve also been told once by a CEO that their product was “made out of DevOps”, as though it was a substance. I decided not to work there, but that’s another story. Let’s look at some better sources.

Wikipedia says:

DevOps is a set of practices that combines software development and information-technology operations which aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

But what are the practices? Why are we aiming to shorten the SDLC? Are we making smaller software? ‘What is continuous delivery’?

I decided to read The DevOps Handbook. Then I knew what DevOps was, and I knew how to do it. And I discovered that I LOVED DevOps.

According to the DevOps Handbook, DevOps had three goals.

Improved deployment frequency; Shortened lead time between fixes;

Awesome! This means if a security bug is found it can be fixed extremely quickly. I like this.

Lower failure rate of new releases and faster recovery time;

Meaning better availability, which is a key security concern with any application (CIA). Lower failures mean things are available more often (the ‘A’ in CIA), and that’s definitely in the security wheelhouse. So far, so good.

Faster time to market; meaning the business gets what they want.

Sometimes we forget that the entire purpose of every security team is to enable the business to get the job done securely. And if we are doing DevSecOps, getting them products that are more secure, faster, is a win for everyone. Again, a big checkmark for security.

Great, so now I think the DevOps people want the same things I, as a security person, want. Excellent. How do I *DO* DevOps?

That is where The Three Ways of DevOps comes in.

1. Emphasize the efficiency of the entire system, not just one part.
2. Fast feedback loops.
3. Continuous learning, risk-taking and experimentation (failing fast)

In the next post we will talk more in detail about The 3 Ways (and how security fits in perfectly).

For this and more, check out my book, Alice and Bob Learn Application Security and my online training academy, We Hack Purple!

Security is Everybody’s Job — Part 3 — What IS DevOps? was originally published in DevOps Dudes on Medium, where people are continuing the conversation by highlighting and responding to this story.