Skip to content

Cybersecurity, safety and quality risks as code

  • ✨ For developers

    Version-controlled risk description in DSL

  • 📊 For business

    Actionable HTML/PDF risk report, diagrams, and diffs

  • 🔗 Cross-component dependencies

    Python-like import of damages, threats and attack/failure paths from other components

  • 🛡 Best practicies

    Based on ISO 27005, ISO 21434, ISO 26262, etc.

Have you run into...

  • risk spreadsheet growing out-of-date with actual implementation?
  • risk updates not propagating across several components?
  • specialized risk management tools with cumbersome UI that few people know how to use?

Discover the five steps to identify and treat your app's cybersecurity, safety and quality risks without becoming a certified expert that you can implement within one day!


Step 1. Describe business assets and assess damages

BUSINESS FUNCTION "Payment Processing"
    DATA "Customer Payment Details"
        REQUIRES confidentiality, integrity   # guide words for deriving threats
        DAMAGE THROUGH "Payment Data Breach"
            BY Cybercriminal                  # could also be hacktivists, researchers, state actors etc.
            COMPROMISES confidentiality
            WITH IMPACT                       # damage impact level is derived from impact factors
                financial: High,
                operational: 3
        ...

Step 2. Describe implementation assets

SYSTEM "Payment Gateway"
    DEPENDS_ON "AWS Cloud"                    # enables reuse of threats and steps from other components
    IMPLEMENTS "Payment Processing"           # connects 
    API "PaymentAPI"
        RECEIVES "Customer Payment Order" WITH "Customer Payment Details"
        SENDS "Payment Confirmation"
    STORAGE "TransactionStorage"
        FOR "Customer Payment Order" WITH "Customer Payment Details"

Step 3. List threats and attack/failure steps

THREAT "Payment Data Theft"
    FROM Cybercriminal
    TO PaymentAPI                               # reference to implementation asset
    ACHIEVES "Payment Data Breach"              # reference to business damage
    THROUGH "SQL Injection"

ATTACK STEP "SQL Injection"
    COMES AFTER "Discover SQL Injection Point"  # intermediate steps are assembled using AND/OR statements
            AND "Exploit SQL Injection"
            AND "Extract Data"

ATTACK STEP "Discover SQL Injection Point"
    LIKELIHOOD                                  # leaf step likelyhood is derived from likelyhood factors
        skills_required: 3,
        window_of_opportunity: 12,
        resources_required: 1,
        knowledge_required: 4

ATTACK_STEP "Exploit SQL Injection"
    LIKELIHOOD
        skills_required: 6,
        window_of_opportunity: 24,
        resources_required: 3,
        knowledge_required: 5

ATTACK_STEP "Extract Data"
    LIKELIHOOD
        skills_required: 5,
        window_of_opportunity: 8,
        resources_required: 2,
        knowledge_required: 6

Step 4. Calculate risks and produce a report

$ perilkeeper gather assets.pkspec threats.pkspec
$ perilkeeper report --format pdf
TBD: Sample report screenshot

Step 5. Take a risk treatment decision and describe mitigations

SYSTEM "Payment Gateway"
    DESIGN_GOAL "Prevent unauthorized data access"  # new design goal

MITIGATION "WAF Configuration"                      # new implementation
    REALIZES "Prevent unauthorized data access"
    ON "Payment Gateway"
    AFFECTS "Find Injection Point"
        window_of_opportunity: -10,
        skills_required: +2
    AFFECTS "Exploit SQL Injection"
        window_of_opportunity: -8,
        skills_required: +3

Learn more

Explore the DSL » Jump to a use-case walkthrough » Install PerilKeeper »