Application Security Foundations Level 2

My notes from Application Security Foundations Level 2 by the WeHackPurple Community

Course Introduction

Prerequisites
- The System Development Life Cycle (SDLC)
- What an AppSec Program is.
- The basic toolset for AppSec Professionals
- The basic concepts of information security, such as least privilege, defense in depth, etc.
Summary from previous course
- In level 1 of this program, we covered:
- What is Application Security? What is a ‘program’? And why do you want to have an AppSec Program?
- We created basic high-level goals for a potential AppSec Program for your workplace.
- Then we learned all of the types of application security activities that exist in our industry.
- We learned about the types of application security tools that are on the market today, and even talked about tools that are coming out soon.
- Then we used all of that information to update our goals for our AppSec Program, with an action plan for you to take to work with you.
What is AppSec?
What are Metrics?
- “a method of measuring something, or the results obtained from this.”
- It’s data from all of our tools, testing, analysis, incidents, and any other data we can get our hands on, that we will use to improve our AppSec program
- Look for Trends
  - Are we getting better?
  - Are we getting worse?
  - Are we finding new issues?
What do we mean by “Advocacy”?
- Talking to people, supporting people, teaching people and getting people on board the application security bandwagon
- Finding the middle ground between security’s priorities and the developer priorities
- Changing the culture
- More Than just educating
  - Supporting the security cultural change
  - Making security top of mind
  - Repeating, so that security is not forgotten
What is Scaling?
- - As an application security professional, you will always be drastically outnumbered by software developers, operations personnel, and the rest of the IT department. Thus, to try to keep pace with them, we must scale.
Why do we need to educate Devs?
- We educate dev teams so they know what we need them to know in order to make software that meets our high standards (and this includes security)
Your Textbook: Alice and Bob Learn Application Security
- The optional textbook for all 3 of these courses that make up the Application Security Foundations program is Alice and Bob Learn Application Security.
- Reading to support the learning in this course is as follows/in this order:
  - Chapter 1 - to learn all the basics for this course. If you don’t already know security basics, read this before starting. It will make the course easier on you.
  - Chapter 9 - If you do not already follow these habits, start now. It is preferable that you read this before starting the course, if possible, so that you can benefit from having better personal digital security sooner.
  - Optional: Chapters 2, 3, 4 and 5 - you will want to cover these all of topics as part of your advocacy and developer education efforts. In fact, distributing or sharing copies of this book with your developers, with support from the AppSec team for questions and clarification, would be excellent support for your devs.
  - Chapter 6 - testing apps for security is an extremely important part of any AppSec program, you will want to learn about the different types and how to get started.
  - Optional: Chapter 8 - this information could be very helpful if your IT shop is using any of these newer types of technologies, so you can teach your devs the best practices.
  - Chapter 7 - to help you create your AppSec program
  - Chapters 10 and 11: After the course is complete

Your Goals From AppSec Foundations Level 1

Setting and Reaching Program Goals
- “SMART”
  - Specific
  - Measurable
  - Achievable
  - Realistic
  - Timely (you have stated a timeline for achieving them)
Goal Assignment
- Goal 1
  - Teach developers about your top 3 security vulnerabilities in order to reduce their prevalence in your apps by 75%.
  - Possible supportive activities: start a lunch and learn program and have one event per month, for at least 3 months.
- Goal 2
  - Stamp out XSS, completely.
  - Possible supportive activities:
    - have a deep dive lunch and learn about it
    - send emails with info
    - add a test to every pipeline
    - create unit tests using the XSS Filter Evasion Cheat Sheet from OWASP
- Goal 3
  - Improve the speed and way that Help Desk turns over security incidents.
  - Possible supportive activities: give the helpdesk team a short training on how spot an application security related incident, what to do and when they should call you.
- Goal 4
  - Get a complete picture of your apps, and general idea of your app security posture.
  - Possible supportive activities: Do an application inventory exercise and do a DAST scan of 100% of them in the next 12 months.
- Goal 5
  - Prevent secret spillage/ensure all secrets are managed as per industry best practices
  - Possible supportive activities:
    - Implement secret scanning in every single pipeline, as of 6 months from now
    - Verify all secrets are in a secret store

Scaling Your Team and Your Program

Why do we scale?

Security Champions

Tag: Security Champions
Identify
Train them
Buy them books
Check in with them once a month
Repeating calendar events
Establish trust with them
Ask them
- Since we last talked, what did you work on?
- Did you have any problems?
- Do you need my help?
- What are you working on now?
- Did you have any problems?
- Do you need my help?
- What are you planning on working on this month?

Coaching

Enabling individuals and teams to achieve their full potential
What their needs and goals are?
- Support them
Set goals with them to create Secure SDLC

Partnership Model

Embedding a security professional in with the project team
Every new software project has an AppSec person assigned
- who plans security activities throughout the entire project life cycle
One place for all answers
Reports back to larger AppSec Team
Warning: do not assign more than 3 projects to the same security professional

Delegation

Some items shouldn’t be the responsibility of the AppSec team, even if you know how to do them
Checkin + Follow up
Fixing security bugs
Updating frameworks
Planning releases or upgrades
Assignment of bugs to developers
Running every scan
Implementing and/or tuning every tool
Writing unit tests

Automation

Not every task can be automated, but one way to identify which tasks are ideal for automation is to look for toil
Toil is the kind of work that tends to be:
- Manual
- Repetitive
- Can be Automated
- Tactical
- Devoid of enduring value
- Scales linearly as a service grows
- Explain your automation process and the need for it

Scaling Assignment

Developer Education

Why?
- Most Universities, Colleges and Boot Camps do not cover the topic of application security
- They do not teach their students how to ensure they are creating secure software
- On top of this, most companies do not pay for AppSec training for their devs
- Average employee doesn’t have the time, money, motivation, etc. to pay for training on their own time
Methods of Education
- Team training with on-site instructor
- Send them to a school for training
- Send them to a conference
- Online courses
- Training designed in-house
- Lunch and Learns
- University/College courses
- “Cyber Ranges” and/or CTFs
- Books and other written resources (can be digital)
- Content subscriptions for videos/blogs
- Scouring the internet for decent free content
When and Where will they learn?
- Something that teams don’t always think about before they arrange for training: when, where and how will our colleagues learn?
  - Give them time (days) off for training
  - Ask them to do it on their own time
  - Give them X amount of time per week
  - Ask them to do it at home? At their Desk? WHERE?
  - How much time do you give them?
  - Will you pause their other work?
  - Can they use their work computer? Work lab?
  - Do you expect them to skip lunch? Stay late?
  - Job Shadowing and on-the-job training
  - Mentoring
Who do you teach?
- Do you have time to train everyone?
- Budget
- All Devs/Certain teams/Java for the java teams?
- Security Champions?
- Senior Devs?
- New Devs?
- Managers/PMs?
  - Avoid in depth trainings
Topic Selection
- Your Top 3 vulnerabilities
  - XSS
  - Security Headers
- All of secure coding
- Secure Design
- Threat modelling
- Code Review
- DAST/SCA/AppSec Tooling in your org
- Your policies, guidelines and/or standards
- Your tech stack specific
- Only new tech
- ”Hacking”

Advocacy

What is Advocacy?
- Advocacy, technically, is public support for a policy or goal
- talking to people, supporting people, and getting people on board the security bandwagon
- walking that fine line between the security and development teams' priorities, and having empathy for all involved
- collaboration, cooperation and communication, with the goal of creating secure software
- Soft skills
  - Empathy
  - Listen and Understand
  - Communicate your requirements clearly
    - Make a business case
      - Cost of doing it vs Not doing it
  - Social Skills
Principals for Success
- Independence: Self-service
  - Knowledge base
  - Have images ready for people to grab
  - Provide tools/trainings
- Confidentiality: They can trust us
- Human Centric Approach
  - Care for the developers, they’re humans too
- Empowerment: Provide tools, processes, knowledge, resources
- Equal opportunity/access: Everyone has access to security
  - Training for everyone
  - Time for everyone
- Accountability: On both sides
- Accessibility: Making security possible for all
Tips for teaching adults
- Every moment is a potential learning moment. Good or bad
  - Reinforce the good, make a lesson out of the bad
- Training doesn’t need to be in only one format, do what works!
  - Micro-lessons, lunch and learns, computer-based training, whatever people respond to, do that
- Whenever possible, provide metrics-based training
  - You can design lessons around issues you’ve had happen over and over again, to stop their re-occurrence
- Create learning calendar blocks, for self-training, for yourself or your teams
  - Get approvals, from the teams and their boss
- Job shadowing, mentoring, on-the-job learning is an excellent way to transfer skills!

Tips for Teaching Adults

TIPS 1 - Tell them what you are going to tell them
- tell them what you are going to tell them (explain what you will cover)
- tell them (the presentation)
- then tell them what you told them (summarise key points)
- If you want to ensure they learn a new concept that is abstract, complex or just place difficult, make sure you explain it 3 times, in 3 different ways
- Make use of pictures
TIPS 2 - The Why
- Whenever possible, explain the ‘why’ behind every lesson, statement or idea
- Explain they must always perform authentication before authorization
  - Then explain “We do this because we need to know who we are dealing with before we ever let them inside our system. If we gave someone access (authZ) before we figured out who they were (authN), it would be a disaster if that person was a malicious actor
- When the audience understands why a security rule exists, they are not only more likely to obey it, they will enjoy the presentation more AND remember it better
TIPS 3 - Too much on one slide
- Don’t put too much on one slide
- Also, if possible, put it on the screen the audience will see it on, run to the back of the room, and make sure everyone can read it. If not, make it bigger
- In summary: don’t put too much on one slide. Slides are free, just make more
TIPS 4 - Practice your Talk
- Practice and Get feedback
- Respect the audience’s time
- Practice helps get comfortable
- Ensure to get it right
- Respect your audience
- Respect yourself
TIPS 5 - Telling Stories
- People LOVE stories, and it helps them relate to you and the lesson you are giving
- If you are teaching a lesson about a security policy, if you are allowed, tell a story about someone breaking that policy and the giant mess it made
- If you are explaining what a certain vulnerability is, either tell of a publicly known breach, or of a security incident you had with that vulnerability
- Important: never tell a story that makes one of your colleagues look bad
  - You can be self-deprecating if you want to, but never throw someone under the bus that you work with to get a laugh
  - If someone looks bad in a story, never name them and make sure the audience won’t know who you are talking about
TIPS 6 - Reading Slides
- If you put words on a screen, the audience will read them. And they will not be listening to you while they do it
- Either start with a picture, or just a title, and tell them what you want to say
TIPS 7 - Say thank you
TIPS 8 - Provide Links
- If you are presenting not in your office, always give people a way to reach you
- Always provide links where people can read more, learn more, or anything that you mentioned during your presentation that might interest them. Even if you didn’t write it. You are providing links to benefit your audience, not yourself
- You can also provide links that you want people to visit; there is no shame in self-promotion!
TIPS 9 - Making Mistakes
- If you make a mistake or miss something in your presentation, NEWS FLASH, your audience has no idea
  - If you just act cool, they will never know. If you point it out and fret about it, you will look bad and that will make the audience uncomfortable
  - They want you to succeed, and they do not want to see you fail
  - Just continue as though everything is fine, and there’s a 99.9% chance it will be fine. Just be cool.
TIPS 10 - Overloading your audience
- Take pauses
- Drink Water
- Use relevant jokes, only if you’re good at it
- If your audience’s eyes are half closed, they are likely to be overwhelmed, not sleepy. It does NOT mean you are boring.
TIPS 11 - People taking photos
- If someone puts up a phone to take an image of your slide, pause and let them do it
- You can even say “This is a summary slide, does anyone want a pic? Now’s your chance”
TIPS 12 - People on their phones
- If people are playing with their phones, unless they are live tweeting you/your presentation, this might be a bad sign
- The point is: ignore them.
  - Who cares what they are doing? Concentrate on what you are doing, delivering the rest of the audience the absolute best presentation they’ve ever seen
TIPS 13 - Jargon and Acronyms
- If you say a product name or AppSec jargon, say it carefully and clearly, so the audience hears it
- Never assume they will know
- Always explain AppSec jargon or new terms
- Spell out acronyms the first time you use them.
TIPS 14 - Clapping
- Always give the audience a chance to clap
  - Don’t just jump to questions, always pause
- Leave time for questions. Questions are great!
- If you receive the same question(s) over and over again, write a blog post or add information to your office wiki/intranet site
TIPS 15 - Large Text
- Make sure everyone can see your text and that it is large enough
  - Especially if you are doing a technical demo or showing code
- No one in your audience should ever be squinting,if so, pause and make it larger (if you can)
TIPS 16 - Drink water
- Take a breath or drink of water in-between major points
  - To let the info sink in
  - To breathe
  - Don’t forget to breathe
  - You can do this
TIPS 17 - History Lesson
- Do not give the history of whatever you are talking about unless it’s relevant, or very interesting
- Teach the thing you came to teach, don’t pad your time
TIPS 18 - Diagrams and Other Imagery
- If possible, use imagery or diagrams
- Put an image on every single slide if you can
TIPS 19 - Never be condescending. Ever
- Always treat your audience with the respect they deserve,and the respect that you would want in return
- Never talk condescendingly to your audience or patronize them
  - They are super-smart, or they wouldn’t be there. Be super careful not to do this

Metrics

Metrics, Improvement and Data
- We measure so that we can improve and report
- In order to improve we must base our decisions off data that matters, not vanity metrics.
Metrics vs Reporting
- Reports are for bosses; metrics are for us.
- Reporting helps us get budget for tools, other resources and staff
- Reporting is sometimes part of compliance/audit.
- Reporting makes our bosses happy and is a box we need to check.
- But what we need metrics for is improvement
Measurement
- We must use the same measurement for all things. We cannot have apples and oranges
- Validate and Eliminate False positives
- Options:
  - In-house risk measuring system
  - CVE/CWE
  - High/Med/Low that automated tools produce
Calculating In-House Risk
- Often larger organisations create their own in-house risk score
- Below are some ideas on what to base your scores on:
  - Ease of exploit
  - public/internal
  - privilege gained
  - how long the vulnerability has been known
  - specific risks to your business
  - data classification
  - CIA affected
Metrics that Matter
- Vanity Metrics
  - Look good, but not helping in improving
- Time to detection
- Time to remediation and/or patch
- Baseline security posture, how close are you to your goals? How much closer 3, 6, 12 months later?
- Are you meeting your SLAs with developers and ops?
- Average number of vulnerabilities per system or app, and does this go down over time?
- Detecting the same types of vulnerabilities? Reduction in #s?
- Are you now able to detect new types of vulnerabilities? Are there less of them now? (Reduction in #s? => Are there less of them now?)
- After education on specific topics do vulnerabilities instances decline?
- After targeting specific vulnerabilities do they decline?
Incident Metrics that Matter
- Post mortem report and Security Incident report
- Security incidents are the most expensive, time consuming and humiliating way to deal with a vulnerability for the first time
- Time to resolve
- Time to detect
- Time to diagnose as incident or just event (triage)
- Types/categories of incidents
- Process is/is not followed
- Cost & damage
- Types repeated, or new types found
- Other teams understand what to do/cooperative
- Post-mortem performed every single time?
- Quarterly review of incident stats
- Time between incidents (if there’s no recovery time that’s an issue) – Note on resting your staff
- Access and tooling were/were not available
Tools for Measurement
- Microsoft Excel
- Email or documents in folders (bad idea)
- Thread Fix, Defect Dojo and other Vulnerability Management tools
- Checking several different security tool dashboards (not great)
- Other tooling dashboards not meant for Vulnerability Management, such as Power BI and other Business Data tools
- Your cloud dashboard if it accepts external info
- Saving it all to a DB and querying it yourself
- Always: Automate as much as humanly possible

Improvement

Using Metrics for Improvement
- Education on your top 3
- Bug type eradication
- Compliance (regs + your policies & standards)
- Are you meeting your SLAs? Bug Fixing SLAs?
- Are you repeating incidents? Finding new kinds?