Tanya Janca, also known as SheHacksPurple, is the best-selling author of ‘Alice and Bob Learn Application Security’. She is also the founder of We Hack Purple, an online learning academy, community and podcast that revolves around teaching everyone to create secure software. Tanya has been coding and working in IT for over twenty years, won countless awards, and has been everywhere from startups to public service to tech giants (Microsoft, Adobe, & Nokia). She has worn many hats; startup founder, pentester, CISO, AppSec Engineer, and software developer. She is an award-winning public speaker, active blogger & streamer and has delivered hundreds of talks and trainings on 6 continents. She values diversity, inclusion and kindness, which shines through in her countless initiatives.
Advisor: Nord VPN, Cloud Defense, NeuraLegion, ICTC PAC
Founder: We Hack Purple, WoSEC International (Women of Security), OWASP DevSlop, #CyberMentoringMonday
Start by defining the focus of your program and what is expected from champions. Be realistic; you can only expect 1-4 hours maximum effort from them per week.
If someone is taking a security course, but they are not on the security team, they may make a good champion. Reach out and introduce yourself.
If the mantra of the security team is “it’s my job to help you do your job, securely”, “you’re my customer” or “I’m here to serve you”, that is very attractive. If your team is known as ‘the ministry of NO!’, you will have difficulty attracting volunteers until you turn over a new leaf.
Record every group session and save them. Create an on-boarding set of champion videos from these recordings, so you can auto-onboard new champions. Some of the videos can also be used to on-board new software developers or other IT staff.
Save all the videos so anyone who missed them can see them later. Offer up the list of videos to everyone at your organization, if appropriate.
Include a TTT (train the trainer) package so that your security champions can train their own teams as needed. For instance, if you want your champions to give training or talks to their own teams, have them follow your package. The package should contain 1) your slides, 2) demo information and instructions to set it up, 3) a video of you giving the talk/training, and, 4) a video of you explaining what you are trying to get across for each slide and the entire demo, spoken as though you are teaching someone to give the talk on your behalf. For an example of this, see mine!
PS… Feel free to give these talks yourself, at your own workplace.
Lastly, don’t stop. Don’t give up. Perseverance is the thing that will make this program work. As your program continues it will grow and the value you that you receive from it will also grow, scaling upwards over time. You and your organization can do this, all it takes is dedication and time.
Please feel free to email me with questions, or even better, tell me about yoursuccess with your own security champions program!
You may wonder, why are metrics important? The answer is twofold.
We can use data and metrics to report up to our bosses and show them we are succeeding. It’s evidence that what we are doing is working, and how well it is working. You can then use that data again to ask for more resources (staff, tools, budget), a raise, or other changes.
The second reason is so that we, ourselves, can improve. We want to improve our program, ourselves, and our results. When we measure our activities and their impacts, we can see which activities or methods produce better results. We can then use that information to change our approach, for the better.
It is important, however, that we do not become fooled by vanity metrics. Vanity metrics are numbers that make us look good, but don’t necessarily mean anything. My talk on this subject has several stories, but for now let’s just tell one.
I used to work somewhere, and we all wrote blog posts. We were measured on how many “clicks” we got. A colleague of mine got 10X the number of clicks that I did, and I asked him how he did it. He explained he got the most clicks on Reddit. I was unfamiliar with the platform but thought I would give it a try. First though, I asked for extra data: I wanted to know how long people were staying on our articles. It turned out that people were staying on my articles approximately 1.5 minutes (which means they were reading the whole thing), and on his they were staying an average of 1.5 seconds (which means almost no one was reading the article, they were just clicking the link. This is commonly known as a “bounce”.) The purpose of our jobs was to write articles to help customers know how to use our products, and this means a bounce wasn’t valuable. Armed with this new information, we started comparing different platforms, and it turned out almost all traffic from Reddit were ‘bounces’. I also noticed that my Twitter followers were significantly more likely to read the article when compared to LinkedIn, and LinkedIn got better results than Reddit. My colleague started focussing on sharing links on Twitter (he had more followers than I did), and I started trying to get more followers on the same platform. It turns out that measuring clicks was a vanity metric. The rest, as they say, is history.
Now for your security champion program metrics! Measure the following things so you can see what’s working and what is not. Don’t forget to report upwards about the ROI (return on investment) your champions program has produced!
How many new security champions you have attracted
Measuring program engagement: how many people attended an event, how many people reported issues to you, how many people asked questions,
Use the bug tracker for metrics on how many security bugs are being reported and fixed, especially if you have targeted a specific bug class. Also, count how many new instances of that type of bug appear, hopefully this number will be very low.
Instances where champions have told you about a security issue you would not have known about otherwise
If the champions report better work satisfaction and/or fewer missed days of work
Gather stories of your champs saving the day, providing help to their teammates, or anything else that makes for a good story-telling session for upper management.
Up next, I will share a few more tips that don’t fit into any of the previous categories and conclude this series. Please feel free to email me with any questions!
As mentioned in the previous article (Recognizing & Rewarding Your Security Champions), the most common reason for failure of a security champions program is the security team losing steam, and/or the champions losing interest. In this article, we will discuss a few ways to avoid this. The best way? Communication.
To start off with, pace yourself. Often when I speak to security teams who have a failed program, they tell me how they started off very strong. “We gave them 2 different trainings, 2 workshops, and 3 lunch and learns, all in the first three months. Then we were exhausted. We haven’t done anything with them in over a year.” This scenario is far too common.
To pace yourself, I suggest meeting with each champion once a month, for 30 minutes. Then hold one lunch & learn and send one email to the champions. This might not sound like much, but you must remember, they are already doing a full-time job for your organization.
Each of these questions is open-ended, with the hope that it will prompt a meaningful conversation. I usually take notes during the meeting, and then send them after to both of us, with any action items for either of us highlighted in bold. (Note: I’ve used this technique to get many of my previous bosses to do things for me. Set a reminder for a week from then, and then reply-all to that email chain and ask: “Any updates on these action items?” It works like a charm!)
In your lunch and learn (which does not need to be at lunch time, or involve food), teach them something you want them to know. Do not teach them things they do not need to know, unless they asked for that topic specifically. During this session you or a teammate can teach, or you can show them a training video you like, or even a recording of a conference talk that really hit home for you. If you show them something pre-recorded, ensure you watched it first, you don’t want to waste anyone’s time with death-by-powerpoint. The more fun you can make these sessions, the better. If you’re up for it, invite all of the developers and let everyone learn something new!
Ideas for lunch and learn topics:
The specifics on how to apply policies, standards and guidelines. This could be a secure coding workshop, or a threat modelling session.
Talks about the top vulnerabilities that you are seeing in your own products, including the risks they pose to your specific business model.
Workshops on how to use the tools that your team wants them to be responsible for. Especially how to configure them, how to validate results, and where to find information on how to fix what they find.
If they are responsible for design or architecture, give them secure design training.
Tell them about a security incident your team had, and how it could have been prevented (assuming you are allowed to share this information).
Hold a consultation on the new policy, standard, or guideline your team is considering publishing. Ask for their feedback, then adjust your documents accordingly.
Remember to take attendance (for metrics) and take notes of any questions for you to follow up.
The monthly email:
Sometimes you just don’t have time to do a lunch and learn event or hold 1:1s, but you still need to send a monthly email. The monthly email lets the security champions know what’s going on, and that they still matter to you. The program is still running, because you sent an email. If you don’t send this email, and you haven’t touched base in any other way, this leaves a space where your program may start to disappear.
The monthly email does not need to be fancy and doesn’t need to say a lot. Generally, the monthly email says:
What events are happening this month at your org (lunch and learn, all staff, any other meeting they should know about)
Any updates your team has (new policy, new tool, project updates, etc)
Anything interesting from the news that they may find valuable
Any local security events they may be interested in
Any podcasts, videos, blog posts or any other media that is relevant and you feel relates to them, about security (of course)
I live in Canada, and in Canada we are a country of immigrants. This means we have many, many different religions represented in most workplaces. In December, there’s Hannukah, Ramadan, Christmas, and more, and often people take time off for these special holidays. This means having a large meeting in December is darn-near impossible. This is the type of situation where you just send the monthly email! It could say something like the following:
Hello Security Champions!
As it is December and many of you will be off celebrating various holidays, we are not going to have any events this month. We also want to wish you happy holidays, and we hope you enjoy all the snow we got this past weekend!
In January we are going to boot the Champions program back up with a lunch and learn on XSS. As some of you are aware, we’ve found it in about 1/3 of our custom apps, and we want to stomp it out in the new year (with your help of course!) An invitation will arrive later this week.
In the meantime, please check out this XSS Deep Dive by Tanya Janca. We’re going to cover this topic a bit differently than she does, but it gives you a good idea of what we are up against.
Have a great December folks!
The Security Team
My hope from this blog post is that you remember to continue to communicate with your champions. Don’t let your program slip, it will disappear faster than you think. When in doubt, send them an email and check in. Up next, we will discuss Metrics.
If you’ve ever read the book The 5 Love Languages, or articles summarizing the 5 love languages, then you are aware that there are predictable patterns of how people respond to various acts of kindness. Someone’s “love language” is the specific type of kindness that they are most affected by. For example, someone for whom their love language is “words of affirmation” would respond very well to receiving a glowing performance review, a compliment on a new article of clothing, or accolades from their colleagues about a project they worked on.
You may be wondering at this point if you accidentally clicked on an article from a women’s fashion magazine, not a technical article from We Hack Purple. But please have a bit more faith, and read on.
The 5 love languages are:
Words of Affirmation
Spending Quality Time
Acts of Service
When we are creating a security champions program, it’s very important that we ensure they feel appreciated. We don’t want them to feel squished into doing two jobs, for only one paycheck. One of the biggest challenges that security team’s face when creating a champions program is having it fall apart after the first few months, either due to the security team losing steam, or champions losing interest. We need them to feel very aware of our gratitude, and interested in the program itself, for them to continue to want to serve the security team’s agenda.
As you likely already figured out, not all the love languages listed above are work appropriate. We can’t run around giving hugs or holding hands with other employees. That said, we can adopt most of them for work situations, so that we can show the champions they matter to us, in appropriate ways, that support our security program.
Below is a non-exhaustive list of several ideas to make your champions feel as valuable as you know they are for your program.
Stickers, posters or any other decoration that is security focused.
Tickets to a conference or training.
Words of Affirmation
Make sure to put a note in their performance review about them being a champion.
Tell their boss every time they do something that makes a big difference.
Send them an email and tell them when they did something big, let them know that YOU saw.
Recognize them in front of their peers (special virtual background, star on their name is slack, etc.)
Digital badges for signature blocks.
High Fives are the only recommended form of physical affection that you should show another employee. High fives signal success, and your approval of whatever they just did.
*** And only do this if you are confident that the employee is comfortable. Please be mindful that some religions and cultures do not allow those of the opposite sex to touch each other and be respectful if this applies. Never push physical touching at work.
Spending Quality Time
Giving them your time is a reward. When you do, give them your undivided attention (put your phone away), and turn your body towards them.
Let them see a new tool first, give them a “sneak preview” ahead of everyone else.
Let them help you make decisions. Ask for advice from them and feedback, then take it seriously.
Invite them to attend security events with you.
Whenever you meet with them, this is quality time. Ask them: What are you working on? What are you going to work on next? Do you need any help?
Acts of Service
Help them with more than just security. Are you good at design? Help them with it! Are you great at presentations? Offer to let them practice in front of you. You don’t need to do this very often, just once can make a huge impression.
Make introductions, where appropriate. “Oh yeah, Chris from QA uses that tool, I’ll introduce you so you can learn.”
Find answers they need to security questions and problems. Never leave them hanging.
When people feel appreciated and valued at work, they work harder (many studies show this to be true). Your champions already have full time jobs on other teams, they are going above and beyond for you. Let them know that you are very aware of them, by always making them aware of it with your actions, not just your words.
In the next article we will discuss communication with your champions!
When deciding to try something new, whether it be enrolling in a new course, or simply signing up for a newsletter, we search for ways to confirm in our minds that it is a good fit. Typically, we want to know that other people like us are on a similar path. Ultimately, we all want to advance in our careers. But signing up for something either too advanced or not advanced enough can hinder our growth.
Naturally, many of you have probably experienced this when looking at We Hack Purple’s offerings and maybe even asked yourself, “Is this a good fit to help me achieve my goals?”
You have heard us talk a lot about how anyone and everyone is welcome at WHP, whether you are new to Cyber or a seasoned vet. But don’t just believe us, see for yourself, and what better way to do that than to check out the demographics of our consumer base!
Years in InfoSec
As we can see, a good portion of our members are relatively new to Cyber. Even if you are unfamiliar with certain concepts, we emphasize delivering content that can be easily understood, despite your skill level! With that said, if you have been Cyber for many years, our content is not “just for people who don’t know anything.” Our wide range of topics creates opportunities for continuous learning for all levels.
Naturally, being a Canadian-based company, a large portion of members come from North America. However, this is not exclusive!
As we can see, We Hack Purple members come from a diversified list of fields within Cyber. Even industry leaders are joining the purple revolution! After all, what better way to keep up to date on a continuously changing industry than with ongoing learning!
By viewing this data, we hope you see how We Hack Purple’s content is not best suited for a narrow group of individuals. Newcomers can still understand our content and courses; however, it is not just for them! Experienced industry members want to know this stuff too. So, let us help you achieve your goals by taking advantage of our various offerings!
In the previous article, we talked about how to engage your champions. We want them interested, revved up and ready to go.
You are in a room full of brand-new security champions and they are itching to learn all about ‘cyber’, what do you do? What do you teach them? How do you impress them?
Only teach them what they need to know. Nothing more.
As someone who creates security training professionally, I have to say, I’ve seen a LOT of filler. Extra content that just does not need to be there. Software developers do not need to know the history of Diffie-Hellman, or the difference between symmetric and asymmetric encryption, unless they are building encryption software. So don’t try to teach it to them unless they have a keen interest and have asked about it.
What they really DO need to know is:
What you need, expect and want from them, as champions.
You should define the goals of your program and share them with your champions. Share your plans for them, as much as you can. Give them timelines, training information or anything else you have. You need to make clear what you are expecting, or you may not get it.
Technical topics for teaching your security champions:
Formal training on secure coding, with labs!
Secure architecture (whiteboarding)
How to fix the bugs they find
Repeat yearly as a minimum
Topics specific to your organization:
Which policies, standards and guidelines apply to them
Help them create missing guidelines
Teach them how to be compliant, help them get there
Their role during an incident
Hold consultations to let them provide input on the policies that will affect them. Trust me, their feedback will be priceless AND it will make them feel heard.
The last topic you need to ensure they learn is tooling. If you expect them to use a tool you need to show them how, what the output means, how to validate the results, how to install and configure it. It is also your job to either help them pick excellent tools or involve them when you are choosing tools for them.
In the next article we are going to discuss how to Recognize Your Champions.
In the previous article, ‘Recruiting Security Champions’, we covered several ways to find, attract and recruit people to your cause. In this article, we will talk about how to get them revved up about security once you have found them.
To occupy, attract, involve – in security activities!!!!
To participate or become involved – with your champs!!!!
If we want IT professionals to join our security champions programs, we must make it interesting and appealing to participate. We want to motivate them; to do extra work on top of their regular job, to care about security, to learn a lot of new things, to work with us. It needs to be good.
Below are a few ideas of how you can make your champions feel engaged.
If possible, bring them on a security incident that has to do with software. Teach them what it’s like to respond, the consequences, and just how much damage insecure code can cause.
Share (appropriate) secrets with your champions. If you are going to share quite sensitive info, inform them of the concept of ‘need to know, then ‘Deputize’ them onto your team for that one meeting. Being vulnerable and admitting mistakes is a great way to get buy-in, and interest.
Let your champions see everything first. New tools, documents, policies, changes, etc. And ask their opinions. First, because they will likely have great ideas, and second because it makes them feel like they matter.
Create a mailing list for your champions to tell them new security stuff. Send them links to podcasts, articles, events, or anything else that you think is relevant and they may find interesting.
Meet with them 1:1 once every month, and have a pre-set list of questions. Potential questions (thanks to my friend Ray at Hella Secure Blog): What are you working on? What are you going to be working on next? Do you need any help? These questions will spark conversation and led you down the right path. That said, when you ask questions like this brace yourself for potentially bad news so that you can play it cool if they reveal something that makes you cringe.
Hold team-building events, let them know each other. Having a friend on a team always makes it worth coming back.
Invite them to join security communities, such as OWASP or We Hack Purple Community (with of which are free to be part of!).
There are many, many ways you can make the champions feel engaged, and one of the best ones is to give them training, which is what we will talk about in the next article, ‘Teaching Security Champions’.
In the previous article, ‘Building Security Champions’, we covered what champions are, why you need them, and our plan to make an amazing program.
The #1 most important rule of recruiting security champions is that you must attract them. Do not “voluntell” someone to be a security champion. That person is not going to do their best for you, and they certainly won’t enjoy the experience. Attract the right people instead of forcing them.
How does one ‘attract’ champions?
Use lunch and learns to teach about security
Arrange security training
Anyone who asks questions or attends all the events is a potential champion
Use interesting titles for events if you can
Add a note to your email signature, saying you are looking for champions
Put a sign on the fridge in the kitchen
Talk about it at the all-staff meeting
Send an email to all of IT
Pay attention to who responds, attends events, asks questions, and who is ‘always there’. Those are the people you need.
Adjust Your Attitude
Change your team’s mantra to “I am here to serve you” and your team will attract even more candidates. Saying “you are my customers” to the rest of IT if you are a security professional, is basically the truth. Plus, you always get more bees with honey.
#2 most important rule of recruiting: ensure their manager is on board. You don’t want this person to have to fight to do work for you or feel conflicted. Ensuring their manager is comfortable.
In the next article, we will talk about how to engage your champions (which will result in you finding even more).
Most of us that work in cybersecurity are well aware that there are not enough people to fill all of the positions that we have opened. There is a severe shortage of trained and experienced people who are capable of securing the systems that we must protect. Application security engineers, DevSecOps professionals, security architects, you name it, there’s a shortage.
We will never have the staff, budget or time to do all the security work we want to do.
One of the ways that we can address this is by scaling our security teams and programs. When I say scaling, I don’t mean what you do to a fish after you catch it. I mean finding a way to do more, with less. This can involve automation, creating self-service systems, and many other potential solutions. In this series of blogs, we will discuss how you can solve this problem by building a security champions program for your organization.
What IS a security champion?
A Security Champion is a member of a team that takes on the responsibility of acting as the primary advocate for security within the team and acting as the first line of defense for security issues within the team.
Or more plainly:
The person who is most excited about security on a team. They want to read the book, fix the bug, or ask security questions. Every time.
Tell me more!
Security champions are your communicators. They deliver security messages to each dev team, teaching, sharing, and helping.
They are your point of contact, delivering messages to and from the security team, and keeping you up to date on what matters to your team.
They are your advocate. They perform security work, for their dev team, with your help.
They also advocate for security, asking questions in situations you would have been left out of. Raising concerns, you might have missed. They are a peer for everyone on their team and can influence in ways that you yourself cannot.
In the next few posts, we will cover how to build an amazing security champions program! We will follow this recipe:
If you want to learn it all right now, I have a conference talk on this topic already, which covers much of what these posts will cover. Feel free to watch it. I gave it at B-Sides Vancouver, an AMAZING community-led conference, close to where I live.
** This article is for beginners in security or other IT folk, not experts. 😀
The mandate and purpose of every IT security team is to protect the confidentiality, integrity and availability of the systems and data that the company, government or organization that they work for. That is why the security team hassles you about having administrator rights on your work machine, won’t let you plug unknown devices into the network, and all the other things that feel inconvenient; they want to ensure these three things. We call it “The CIA Triad” for short.
Let’s examine this using examples with our friends Alice and Bob. Alice has type 1 diabetes and uses a tiny device implanted in her arm to check her insulin several times a day, while Bob has a ‘smart’ pacemaker that regulates his heart, which he accessed via a mobile app on this phone.
If Alice’s insulin measuring device was unavailable due to malfunction, tampering or if it ran out of batteries, she may end up being inconvenienced. Since Alice usually checks her insulin levels several times a day, but she is able to do manual testing of her insulin if she needs to, it is somewhat important to her that this service is available.
Bob, on the other hand, has irregular heartbeats from time to time, and never knows when his arrhythmia will strike. If Bob’s pacemaker was not available when his heart is behaving erratically, this could be a life or death situation if enough time elapses. It is very important that his pacemaker is available, and that it reacts in real-time when an emergency happens. Bob works for the federal government as a clerk managing secret and top-secret documents and has for many years. He is a proud grandfather and is trying hard to live a healthy live since his pacemaker was installed.
Alice is the CEO of a large fortune 500 company, and although she is not ashamed that she is a type 1 diabetic, she does not want this information to become public. She is often interviewed by the media and does public speaking, serving as a role model for many other women in business. Alice works hard to keep her personal life private, and this includes her health condition. She believes that some people within her organization are after her job and would do anything to try to portray her as ‘weak’ in efforts to undermine her authority. If her device where to accidentally leak her information, show itself on public networks, or if her account information became part of a breach, this would be highly embarrassing for her, and potentially damaging to her career. Keeping her private life private is very important to Alice.
Bob, on the other hand, is very open about his heart condition and happy to tell anyone that he has a pacemaker. He has a great insurance plan with the federal government and is very grateful that when he retires that he can continue with his plan, despite his pre-existing condition. Confidentiality is not a priority for Bob in this respect.
Integrity in data means that the data is correct and accurate. Integrity in a computer system means that the results it gives you are precise and factual. For Bob and Alice, this may be the most important of CIA factors: if either of their systems give them incorrect treatment it could result in death. For a human being (as opposed to a company or nation-state), there does not exist a more serious repercussion than end of life. The integrity of their health systems is crucial to ensuring they both remain in good health.
The next time you IT Security team is enforcing a new policy or asking for security requirements as part of your project, I challenge you to try to figure out which of the CIA triad they might be trying to protect with their actions. Sometimes it is a combination of 2 or of the triad. More importantly, I challenge you to ask yourself when you work if you are ensuring each of these three factors of security are being protected by your actions, as the IT Security team cannot succeed alone.
The real reason companies do software inventory exercises is to have a sense of control over their application portfolio. Because you need to KNOW that everything is tested, monitored and patched. That feeling of being certain, rather than ‘fairly confident’, is the difference between knowing that you are doing a good job of securing your software and just hoping that you are.
Most enterprise-level companies have hundreds or even thousands of assets, and do not have accurate inventory of them. This happens for many reasons; developers don’t always report their work, no one is assigned to keeping track of application updates, shadow IT, people not realizing that an API or SaaS (Software as a Service) qualifies as an ‘app’, APIs being split into multiple APIs and the new one(s) not being recorded, lost excel spreadsheets, other priorities getting in the way, employee turnover, etc. There are too many reasons to list, and the cause of the problem doesn’t matter as much as what can be done about it.
Why is having an incomplete inventory of your web assets a problem? Because you can’t protect something if you don’t know you have it.
You might be saying, “All of our applications are released via our standard DevOps Pipeline.” Sure, all the ones you are aware of go through it. What about the ones that you don’t know about?
As you might have guessed by this point; I was working at a company that did application inventory when I wrote this article. Trust me dear reader, even if I don’t work there anymore inventory is still a very important issue.
Story from Tanya:
Back in the day when I was a software developer, one of the government departments that I worked for hired a consultant to do ‘application portfolio management’, his name was Sanjeev. Sanjeev was the coolest guy in our office, well-dressed, charming, always in the right meetings with the powerful people. As you can guess, Sanjeev was paid a lot more than I was. His entire project, for the whole year, was to interview my 14 team members and I about which apps we had, to get links to where they were, and gather any documentation we had about them. He was a patient guy, talking to developers all day and asking us for information that we just didn’t have. Also, none of us thought what he was doing was important, and he was sometimes treated as a pest.
Long story short, we thought we had 200 apps, but he only found evidence of 72. Knowing what I know now…. I wonder how many we really had.
In order to perform a manual application inventory you could interview members of your dev teams and ask them what apps they have. Although having good communication with the dev team is always a good idea, this would be a long and tedious process if you are at a large company. If you are reading this blog, you are likely to be looking for a more technical solution, so let’s look at how we can try to automate this.
For a DevOps shop (those using automated pipelines for releases), inventorying all of the apps and APIs released from various pipelines would be a good starting point. For example: add triggers to the git `pre-push` hook or to a Jenkins pipeline. Any that are not released via a pipeline would not be included, but ideally this would cover the majority of your newer applications.
From there you could look at this from a network angle. If you have the IP range(s) for your network and you have permission to scan them, you may run a network scanning tool such as nmap or masscan against the IP range and look for open ports on TCP port 80 (HTTP) and 443 (HTTPS). If either of these ports are open, they are likely running something web-related. From there you could use an automated tool such as EyeWitness to visit each one of the IP addresses, one at a time, and take a snapshot of the page to see what’s there. Or you could hire someone and have them visit each one manually, to find out what is there.
There are a few problems with the network scanning approach.
Web applications are not restricted to running only on port 80 or 443 (ask most developers where they test locally, and they’ll probably tell you port 8080). Web servers are capable of having several APIs and apps on them as well; they could be separated by ports or through the host name sent in the request. This means that you may not even see all the applications or APIs at a given IP address with a simple network scan.
You may not even be able to reach all your IP addresses due to firewalls, VLANS, or physical network separation.
What if your applications are hosted in the cloud? In cloud environments, IP addresses change frequently, and applications cycle rapidly (for example — serverless applications). You’re certainly not going to scan all of your cloud provider’s network hosts; you neither have the time (that’s a lot of IP addresses) nor the legal permission (remember — the “cloud” is just someone else’s computer) to do so.
Another approach could be to do an external scan of your domain name(s).If you know all of your domain names, you could use a tool like OWASP Zap or Burp Suite to crawl all the links on your domain and have it find as many pages as it can.
Again, there are issues with this method as well, mostly around visibility.
Crawling software can only see what it has access to. If there is no link on a page to an API call, it will never see that API. Are you using MFA (multi-factor authentication)? If so, the crawler won’t be able to get around that (it’s literally what MFA was designed for). Do you have authentication or authorization in your applications? If so, you probably don’t want to write evergreen login credentials into an application (this is also known as a “backdoor”) and then give those credentials to a crawler. That crawler may also hit some sensitive parts of your application (e.g. admin functionality) and wreak wanton destruction to your database, users, or critical business functions.
An external network agent will only be able to access what an external network user will be able to access. This means that it does not give a complete and accurate view of your applications.
If your domain list is incomplete, or there are subdomains you didn’t know about, again — the crawler will completely miss these too.
These approaches all come down to two main problems:
1. These actions require significant overhead to continuously update your targets and initiate scans.
2. You will never be able to get a complete view of your applications and their functionality.
I ask you to ponder the following question:
How do you create and maintain your application inventory?
In this series we are discussing how to get your technical training approved at work. This is not the first article, and you may want to go back and read it from the start.
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…
I found the entire situation infuriating. I felt like I couldn’t win.
If you are asking your boss to take training it must fall into one of two categories:
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.
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 our devs know anything about security. We always end up with late projects and everyone freaking out, because it’s so last minute. Lots of overtime and stress. I could help teach them what they need to know, so we could create more-secure software. The PenTesters will find a lot less wrong with our apps.
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.
Up next we will cover Objection 3: There’s no time with your current workload for you to take training.