Application Security Foundations Level 3

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

Prerequisites

Ideally you would have taken Application Security Level Foundations Levels 1 & 2. But if you haven’t, fear not! To take this course you should know and understand the basics of:

  • The System Development Life Cycle (SDLC)

  • What an AppSec Program is?

  • The basic toolset for AppSec Professionals and the different types of AppSec activities that are common and less common

  • The basic concepts of information security, such as least privilege, defense in depth, etc.

  • How to run a very basic AppSec program

  • What policies, standards and guidelines are as they relate to an IT department or company

Summary from previous courses in this program

  • 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

  • In level 2 of this program, we covered:

    • Creating new goals for your AppSec Program
    • Scaling your AppSec Team and Program
    • Developer Education
    • Advocacy
    • How to give a completely amazing technical presentation and teach your audience while you connect with them
    • Which metrics to gather about your program, how to collect them, and how to use them to improve your efforts
    • We covered two case studies of improvement and using metrics for great security results
    • We updated our goals and made a much more detailed plan for our AppSec program
Definitions and FAQ
  • Modern Technologies
    • Dynamic Apps
    • Serverless
    • APIs
    • Apps on Containers
    • Least Privilege
    • Assume breach
  • Why do I need to legitimise my AppSec program? What do you mean?
    • Support from the upper management
    • Authority
  • Secure modern apps
    • Secure coding principles
    • Secure design principles
    • Reduced attack surface
  • Policies, Standards and Guidelines – What’s the difference?
    • Policies
      • Official Rules
      • Acceptable Use Policy
      • Example: Don’t run your business from your work computer
    • Standards
      • Standard way of doing something
      • Example: Use parameterized queries, encode user input/output
    • Guidelines
  • What’s a security incident?
    • When something bad happens
      • Has happened
      • Happening
    • Network, System or Data
    • IT security incident
    • Physical Security incident
    • Event vs Incident
  • What is incident response?
    • Organised response for incidents
    • Act of writing incident or post mortem reports
  • Which samples of Policies, Standards and Guidelines are included in this course?
    • Sample acceptable use of a security tool
    • Secure coding guideline
    • Web application security requirement standard
    • SSRF guideline
    • Error handling, logging and Alerting
    • Securing Azure
    • API security best practices guideline
Your Goals From AppSec Foundations Level 1 and/or 2
  • Setting and Reaching Goals
    • Goals cannot be vague and immeasurable
    • Be very specific
    • Example 1: “Prevent vulnerabilities from happening in the first place” – Excellent, how?
      • This could be more specific and then become a good goal, for instance “Prevent most vulnerabilities from happening in the first place by providing secure defaults, training and continuous verification that secure defaults are being used.”
    • Example 2: “Shift Security Left” – We are all fans of starting security earlier in the system development life cycle (SDLC), but we need to be more specific.
      • How about: implement at least one security activity in each of the phases of the SDLC by the end of the year. 3 months to decide which activities, 9 months to implement. MUCH BETTER.
    • Example 3: “I want our vulnerabilities to go down” – Down how?
      • Should we look less and then find less? Do you mean we fix them faster? Or we prevent them from happening in the first place. How can someone measure this?
Securing Modern Technologies
  • Zero Trust/Assume Breach
    • Zero Trust is a design concept that can be applied:
      • Within Apps
      • Between Apps
      • Config
      • Your Network
    • Assume Breach is also a design concept, that should be applied to every aspect of IT
      • We can no longer ‘only protect the perimeter’, things have changed
      • Design everything and react as though you may been compromised
  • Serverless
    • Serverless means an application does not have a dedicated server running all the time for it, serverless apps are only available when they are called or invoked
    • When a serverless application is called it opens a container, runs its code to completion, then self-destructs, releasing it’s resources
    • You can have serverless apps that only run when certain alerts happen, every two weeks for employee payroll, or any other timing or situation that makes sense
    • Serverless Best Practices
      • Monitor and log functions
      • Use secure coding conventions for application code
      • Secure and verify data in transit(Encryption)
      • Employ API gateways as a security buffer
        • Authentication & Authorization
        • Quotas & Throttling
      • Monitor and log functions, feed them into the SIEM
      • Manage secrets in a secret store
      • Deploy functions in minimal granularity
      • Maintain isolated function perimeters
      • Good article about this from Snyk: https://snyk.io/blog/10-serverless-security-best-practices/
  • Cloud Workflow
    • Best Practices for using Cloud Workflows securely:
      • Monitor and log functions, feed them into the SIEM
      • Manage secrets in a secret store
      • Deploy functions in minimal granularity
      • Maintain isolated function perimeters
      • Use secure coding conventions for application code
      • Secure and verify data in transit(Encryption)
  • Online Storage
    • We all know “open S3 buckets” were the bane of public cloud existence for the first few years, but this sort of mistake is no longer acceptable
    • Risk is high, attackers are very ready to exploit insecurely configured online storage
    • Best Practices:
      • Locking it down by default, templates FTW!
      • Classifying & label data to ensure you use the proper precautions, know its value immediately.
      • Monitoring of access, file integrity, port sniffing, etc. WITH ALERTS. And automated response.
      • Access by service accounts only, directly from the app. Never use a human being’s account
  • Containers & Orchestration
    • Best Practices:
      • New (config) rules, New tools
      • New vulnerabilities to watch out for
        • Sign up for security newsletters
      • Protect who can create or edit containers
      • But similar in approach:
        • scan
        • check your config
        • patch regularly
        • zero trust
      • Do not run as root.
      • Limit resources (set quotas)
      • MFA on all management accounts
      • Secure your container registries
      • Don’t download/use untrusted containers
      • Alert when things go wrong
  • APIs and Microservices Architecture APIs
    • Best Practices
      • Service mesh FTW
      • Standardisation and/or templating for your org
      • Strict linting of calls to ensure it follows protocol and definition of API
      • Throttling and resource quotas
      • Authenticate THEN Authorise
      • Hide what you can, do not share any extra info
        • Don’t give verbose error messages
        • Approve HTTP verbs that you need, block the rest
  • Infrastructure as Code (IaC)
    • using scripts or configuration files to create, deploy and configure your infrastructure
    • immutable, meaning we don’t patch it, we replace it with a patched/secured version of it instead
    • Key Security Steps:
      • Scan for vulnerabilities
      • Scan for poor config choices
      • Add security config best practices
      • Make sure this code is managed and protected like the rest of your app code
        • Version control must be backed up, stored and protected
      • Changes to prod must be done only via IaC (Unless emergency)
  • Security as Code (SaC)
    • Similar to IaC, security as code means adding security to your DevOps processes, products and apps, via code
    • writing code to a pipeline to
      • verifies your security policies are applied to the latest build
      • performs security testing
      • verifies the security of your configuration
  • Platform as a Service (PaaS)
    • Platform as a Service (PaaS) is infrastructure provided by public cloud vendors that they maintain for you
    • You put your app on it
      • never have to patch it
      • rotate keys
      • worry about hardware breakdowns
    • You still need to ensure the configurations you choose are secure
    • You will want to force HTTPs and select only newer/industry standard encryption protocols (currently TLS 1.2 and 1.3)
    • You will have the ability to apply some security headers here
    • PaaS does not include app security, maintenance or any other protections
    • It is our responsibility to put a secure app on PaaS, not your cloud provider. PaaS also does not include network security, they won’t design your network, or add firewalls for you
  • Infrastructure as a Service (IaaS)**
    • Infrastructure as a Service (IaaS) means that you can click a few buttons in the public cloud and they will create infrastructure for you
    • The Cloud Provider does not maintain IaaS for you, that is our responsibility
    • To secure IaaS first read the ‘shared responsibility model’ information from your cloud provider, in order to know what they do and what you need to do
    • Follow all the same best practices for any other type of infrastructure, reduce attack surface, zero trust, least privilege, etc.
  • Continuous Integration/ Continuous Delivery/ Continuous Deployment**
    • CI/CD = Continuous Integration/Continuous Delivery, Continuous Deployment
    • CI/CD is software that builds, tests and deploys your applications and infrastructure, automagically
    • CI/CD is one of the main ingredients of every DevOps recipe – you cannot do DevOps without one. Also known as a “pipeline”
    • CI/CD is a tool that security people can use in order to verify our security policies, standards, and guidelines are followed, by adding tests to it.
    • We can also gather (security) metrics from a CI/CD, and then export it somewhere else for us to analyse
    • We can stop a new version of software or infrastructure from being released if there is a serious security issue found
    • We need to protect the pipeline just as we would protect any other extremely valuable workplace tool – the code for the pipeline should be backed up into version control, or the pipeline changes otherwise saves and (ideally) documented.
  • Public Cloud
    • Quite often when people discuss ‘cloud security’ they mean ‘cloud native security’, the new types of features, products and offerings that are only available in the cloud.
    • Companies that use public cloud are often in one of three categories:
      • They started in the cloud (often startups)
      • They are ‘lifting and shifting’ their apps
    • They are redesigning to take advantage of cloud native, then migrating
    • If you are performing a ’lift and shift’, it is important that you follow all of the same security best practices you previously followed in our own data center.
    • If you are starting in the cloud or redesigning for the cloud, you should take advantage of all of the new cloud native options available to you, especially the security features such as policy automation, automated zero trust, monitoring, logging, dashboard and so much more
    • Best security practices for public cloud:
      • Provide secure defaults for everything, and template whenever possible
      • Design for Zero Trust and Assume Breach (read chapter 2 of your textbook for more info)
      • Logging, monitoring, alerting of everything
      • Scan all that can be scanned
      • Automate every possible policy
      • Create an IAM strategy and enforce it
      • MFA is mandatory on all owner accounts
Policy
  • What are policies?
    • Policies are usually difficult to read documents that you base your standards and guidelines on
    • Serve as a set of rules for your org, and if people do not comply there are (usually) consequences
    • In the cloud, some policies can be automated and enforced
      • Examples:
        • All users that have owner permissions, should have MFA enabled
        • Password reset after an interval of time
  • What policies do we need for AppSec?
    • Acceptable Use: Using a network in a certain manner
    • Access Control: Least privilege
    • Information Security
    • Change Management
    • Remote Access
    • Incident Response
    • Password Management
    • BYOD
    • Network Security
    • Server/Platform Security
    • Encryption
    • Disaster Recovery (DR)
    • Business Continuity Plan (BCP)
  • Policies we create, and policies we want to influence
    • Policies We Create
      • The following is a list of potential policies that we would want to create to support and legitimise our Application Security Program.
        • Application Security policy (Secure SDLC)
          • Threat Modelling
          • Security Requirements
          • Other security activities for each stage
        • Application Testing policy (scope & rules of engagement)
        • Secure Code Policy
        • Security Tool Usage Policy
          • Use them on the right apps
          • Never point outside the network
  • Policies We Want to Influence
    • Server/Platform Security <- DevOps
    • Information Security <- data in our apps
    • Change Management <- of our apps
    • Remote Access <- if admin is done remote
    • Incident Response <- AppSec incidents
    • Password Management <- in our apps
    • Disaster Recovery (DR) <- of our apps
    • Business Continuity Plan (BCP) <- our apps
  • Application Security Program Policy (Secure SDLC)
    • Defines the security activities that are required as part of your system development life cycle
    • Security Requirements as per document X must be included in all new web apps
    • All Designs must have threat modelling performed
    • All Designs must be white boarded with a member of the AppSec Team/SecChamps
    • All applications must follow the secure coding guideline
    • Secure Code review on all pull requests
    • Security Assessment or App Pentest performed on all apps before first public release, and for major version updates
    • SAST must be performed before first public release and on major version updates
    • All repos must have an SCA scan once per week, with Medium and up resolved
  • Security Tool Usage Policy
    • Only usage of approved security tools on work devices and network
    • Only after completed training with security team
    • Only in sandbox environment
    • Only against systems hosting test data
    • Only during off hours
    • Must inform SOC in advance of testing, plus start and finish times
    • Security Testing Policy sample from SANS
    • Security Policy Templates
Standards and Guidelines
  • What are standards and guidelines?
    • Standards are levels of service or quality that you must follow
    • Guidelines are information to help you achieve specific levels of service or quality
    • Suggestion: start with guidelines but aim for standards
    • Allow a grace period
    • Help teams become compliant
    • Start lenient, become strict
    • Low-level, detail oriented
  • Standards that WE (the AppSec Team) create
    • If they need guidance, you should write a doc for it
    • Secure Coding
    • Secure Design
    • Project Security Requirements
    • Pipeline Tooling Guideline
    • Bug Fixing SLAs
    • Incident SLAs
    • Serverless standards
    • API standards
    • Cloud Security requirements/standards
    • Online Storage guidelines
Samples of Standards and Guidelines
  • Secure Coding Guideline
  • Project Security Requirements
  • SSRF Defences and Mitigations
  • Error Handling and Logging
  • Azure Hardening and Best Practices
  • API Security Best Practices
Incident Response
  • What is incident response?
    • It is an organised approach to addressing and managing the aftermath of a security breach or IT incident
    • The goal is to handle the situation in a way that limits damage and reduces recovery time and costs.
    • How can you tell if it’s a security event or an incident?
      • A security event is when something strange has happened, or you suspect something is wrong.
      • A security incident is when you are certain something bad has or is happening
  • Create an Incident Response Process
  • Inventory
    • Having an update to date and accurate inventory of all of your web and software assets will make much better for your incident response team
      • Who is in charge of apps?
      • Contact information?
      • What team?
      • Where is the code stored?
      • Dev Environment?
      • Safe place to test?
      • What does it interact with?
      • Does it integrate with other apps?
      • Tech stack?
      • Which frameworks and versions?
      • Document all of this
  • Patch Management
  • Third Party Components and Code
  • IR And Forensic Training
  • Scanning**
    • Scan all that can be scanned. Then fix what you find
  • Threat Feeds**
    • There are many different places that you can subscribe to in order to hear about potential threats to your systems, frameworks and more
  • Virtual Patching
    • You can use a Web App Firewall (WAF) or Runtime Application Security Protection (RASP) tool in order to deploy a virtual patch, if there is a security issue you need to defend against but cannot apply a proper patch against
    • Write your own signature on WAF or RASP do block a 0-day which does not have a patch/update
    • OWASP ModSecurity
  • Backups And Rollbacks
    • Your backups aren’t worth anything if you cannot roll back to them in a reasonable amount of time
  • Tooling
    • Log viewer
    • VA scanning tool
    • DAST with ability of in-depth control (Burp pro)
    • Metasploit
    • Test it in a safe place
  • Access
    • We do not want to find out that we do not have access to key systems after everyone else has gone home for the day
    • Ensure your team has access to everything they need to before a security incident happens, and verify regularly that the access still works
  • Training For Other Teams
    • Providing basic training to other teams about what you need in time of incident can mean the difference between a smooth handover and a mess you spend weeks cleaning up
  • Incident Simulations
    • We do a dress rehearsal before a play, just like we should practice before we handle real incidents
    • Backdoor and breaches card game
  • Logs
    • Without logs there is very little to investigate
    • Ensure you have access to your applications' logs, log viewing software, and that your logs are properly protected against deletion and tampering
  • Disaster Recovery and Business Continuity Planning
  • During An Incident (The Process)
    • The steps to incident response are as follows:
      • Preparation/Triage
      • Identification
      • Containment
        • Short Term
        • Long Term
      • Eradication
      • Recovery
      • Postmortem
      • Everything must be documented in an incident report
      • No Blaming
  • Post Mortem
    • Once everything is cleaned up, but things are still fresh in your mind, meet to discuss what happened.
    • Make sure you’ve documented all events and details, using an incident report
    • Then hold a postmortem event, and write a report
    • The event and report must both be blameless
    • It needs to be an open discussion if you hope to improve your processes.
    • If you get stuck, use “The 5 Whys”
    • Use of post mortem:
      • Don’t want to repeat our mistakes
      • Don’t point fingers or blame
      • What we did well, not so well and what we can prevent next time
      • Action the results
  • Incident Preparation Assignment
    • Review the IR report document
    • Review the post mortem report
  • Postmortem Report**
    • Remember when answering this it is important not to blame others, or even ourselves. Pointing fingers won’t help us prevent another incident, and it discourages the openness required to find the true root cause
    • Sample Postmortem Report attached contains the following info:
    • Incident summary, including timeline:
    • Cause of incident (root cause): Missing safeguards? Untrained team members? Using “The 5 Whys” might help here.
    • Impact/damage/cost
    • Time to detection, if available, and how was it detection:
    • Response activities & results of response/resolution:
    • Recovery Activity(s):
    • Has this type of incident happened before? If so, how did it happen again? If not, investigate if it has happened, but gone unnoticed. Y/N + explanation
    • Lessons Learned/Opportunities for Improvement:
    • What went well?
    • What did not go well?
    • Action Items:
    • (Items approved for action, with name of person assigned)
  • Incident Report
    • Sample Incident Report attached contains the following info:
      • Describe the incident, what happened?
      • Incident timeline:
      • Contact info for every person involved:
      • If sensitive information involved, do notifications need to be sent? If so, have they been sent?
      • How was the situation detected?
      • What steps were taken to contain the issue or reduce the damage?
      • What evidence was collected and where is it stored?
      • Steps taken to eradicate the issue (if applicable)?
      • Steps taken to recover? Are systems fully recovered?
      • Steps taken to prevent future similar events?
Advanced Activities
  • DevSecOps
    • The Goals of DevOps
      • Improved Deployment Frequency
      • Lower Failure Rates
      • Faster Time to Market
    • The Three Ways of DevOps
      • Emphasise the speed and efficiency of the entire system
      • Fast Feedback
      • Continuous Learning
    • DevSecOps: AppSec, adjusted for a DevOps environment
      • Learn to sprint
      • Create Processes that work
        • That are fast
        • Efficient
        • Effective
        • Become guardrails instead of gatekeeper
    • Security feedback to devs and ops in DevOps
      • Shorten + amplify feedback loops
        • Faster
        • Cheaper
        • Easier
      • Automate ticket creation
      • Help Dev and Ops understand the results
      • Tune our tools
        • False positive suppression
      • Fail fast
      • Provide trainings to devs, create documentations
  • Automate Everything
    • Automate anything you can for your team, ops and dev. This can mean mitigation, defenses, visibility, etc. The sky is the limit.
    • Automated Responses:
      • Cloud Workflows can be programmed to trigger on different activities in our cloud instance, to respond to threats
    • Automated Scans:
      • SAST/DAST/Secret/SCA and other scanning can be scheduled, added to your CI/CD, and automated in other ways. With results going into a bug tracker or VM tool.
    • Automated Releases:
      • We already know DevOps teams are automating releases using CI/CD, why not join in with them by automating your security approvals?
    • Automated Visibility:
      • Not only can we automate our scan results going into a VM tool, there are even newer tools that create automated visibility for senior management!
    • Automated Threat Modelling:
      • Create a “mini” threat model by creating a file for each app that details it’s risk, then changes the strictness of your CI/CD pass/fail based on the file.Sample Mini Threat Model File:
        • Sensitive info? No.
        • Public Facing? Yes.
        • Applicable legislature? Yes, HIPA/PCI
        • Mission Critical App: No.
      • The fail rate would be different, based on the answers. The answers are 0/1, binary.
      • Be creative. Think outside the box. Enable your teams.
  • Self Service
    • The best AppSec people work as hard as they can, to put themselves out of a job
      • The best way we can do this is self-service
    • Tools
      • Create a portal where devs can access security tools. Provide training, and a safe place to do it
    • IDE
      • Help them integrate tools into their IDEs, so they don’t have to depend on you at all
    • Answers
      • Create a knowledge-base/documentations, so every time something is learned, it’s shared widely. It must be searchable by all devs
    • Deployment
      • Add testing to CI/CD or any other form of security testing automation, so devs don’t have to wait to deploy
    • Templates
      • Create templates for CI/CD configurations so that they can easily implement your security tools into their workflows
      • Create unit test examples for devs to copy from
      • Basically, make templates of anything useful and share
    • Don’t ever stop trying to enable those around you to perform security as part of their daily work
  • Secure Defaults
    • Create defaults that are secure, then enable and teach the devs to use them
      • Repo Kid from Netflix
      • Libraries to call secret stores/managers
    • Every possible security concept and/or control that you can create a secure default for is a GIANT win
      • Think: AuthN, AuthZ, input validation, security headers, etc
    • Search for anti-patterns (anyone NOT using your secure defaults)
      • They should be a LOT easier to spot once most of your devs are on board
Final Project
  • Refresher On Goals
    • Specific
    • Measurable
    • Achievable
    • Realistic
    • Timely
  • The Final Project
    • Who will be involved for this goal?
      • Who on your team?
      • Other teams?
      • Whose buy in do you need?
      • Who’s time?
    • What are you going to accomplish? Be extremely specific
    • Which application(s), systems or networks? Name them
    • When will you aim to achieve this goal?
      • Are there steps you can list or a timeline you can provide?
    • Why did you select this goal?
      • What value will it bring to your org?
    • How will you measure this goal?
      • Which tools will you use for metrics?
      • How can you tell if you’ve achieved it?
      • How can you track your progress?
    • What resources do you need to accomplish this goal?
      • Resource, Budget, tools, approvals, access, time (for you or others), list anything you will need
    • Are you being realistic?
      • Is the cost of this goal going to provide significantly more value to your org Management will really want to know the answer to this, be ready
    • What AppSec activities will help you achieve this goal?
    • What Tools will you use to help you achieve this goal?
    • Which policies, standards or guidelines does this goal support?
    • Do you need to adjust or add to your incident response process with this new goal?
    • Will you be able to use scaling tactics to help you achieve this goal?
      • How do you plan to leverage your scaling?
      • Refer scaling chapter in appsec foundations level 2
    • Will you need to educate developers or other staff in order to achieve this goal?
      • how do you plan to do this?