Private corporate batches, live online cohorts and 1-on-1 mentoring in structured analysis of a system's design — decomposition, STRIDE, risk rating and mitigations that become real controls — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches threat modeling as a repeatable engineering activity rather than a workshop format: decomposing a real architecture, drawing trust boundaries that mean something, eliciting threats with STRIDE against each boundary crossing, rating them so priority is defensible, and converting the result into backlog items with owners. Sessions model the attendees' own systems wherever possible, and spend deliberate time on the hard parts — scoping, keeping models current as the design changes, and stopping the exercise from producing a document nobody reads.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Threat Modeling that means a trainer who has run it in production — structured analysis of a system's design — decomposition, STRIDE, risk rating and mitigations that become real controls — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Threat Modeling batchThreat Modeling is the practice of analysing a system's design to work out what can go wrong before it is built, and deciding what to do about each answer. It is a structured conversation with an output: a picture of the system, a list of the ways an attacker could abuse it, a judgement about which of those matter, and a set of mitigations that become tickets, tests or architectural changes rather than observations in a document.
The method is consistent even when the notation varies. You decompose the system into its processes, data stores, data flows and external entities; you draw the trust boundaries those flows cross, because a boundary crossing is where most interesting things happen; you elicit threats systematically using a mnemonic such as STRIDE or a privacy equivalent such as LINDDUN, rather than by brainstorming until people run out of ideas; you rate what you found so that scarce engineering time goes to the right places; and you assign each accepted threat a mitigation with an owner. Attack trees, abuse cases and ATT&CK technique mapping extend the same skeleton when a threat needs to be reasoned about in depth.
Threat modeling earns its place because it is the only security activity that operates on the design. A scanner can tell you a dependency is vulnerable; it cannot tell you that a service trusts a header it should not, that a tenant identifier is taken from a client-supplied field, or that a queue crossing an availability boundary has no authentication. Those are design defects, they are expensive to fix late, and they are found by people asking structured questions early.
Architectures got more distributed exactly as release cadence got faster. A system that used to be one application and one database is now a set of services, queues, managed cloud components, third-party APIs and an identity provider — which means far more trust boundaries, far more places where an assumption is made implicitly, and far less time in which anyone reviews them.
The compliance environment has caught up too. Secure-by-design expectations now appear in regulatory guidance, customer security questionnaires and procurement reviews, and several standards ask directly for evidence that design-level risk analysis takes place. That has turned threat modeling from a specialist workshop into something teams are asked to demonstrate, repeatedly, per significant change.
What organisations struggle with is not the concept but the practice. The common failure is a heavyweight model produced once by a security team, agreed by nobody, never updated, and never converted into work. Running it lightweight enough that a delivery team will actually do it, with a scope that fits a sprint and an output that lands in the backlog, is the skill that makes the difference between a real programme and an artefact in a wiki.
The four questions the practice exists to answer, the point in delivery where it pays for itself, and how it differs from a penetration test, an architecture review and a compliance assessment. Scoping is covered first because an unscoped model is the most common reason the exercise fails.
Topics: The four questions: what are we building, what can go wrong, what will we do, did we do a good job · Where design defects come from and why scanners cannot find them · Threat modeling versus penetration testing versus architecture review · Scoping: system, feature, change and data-flow scope · Who is in the room and what each person contributes · Timeboxing and right-sizing for a delivery team · Outputs that survive: what a finished model must contain
Getting the picture right, because everything downstream is derived from it. Data flow diagrams at the right level of abstraction, identifying processes, stores, flows and external entities, and drawing trust boundaries where authority actually changes rather than where the network diagram has a line.
Topics: Data flow diagrams: elements, levels and how deep to go · Processes, data stores, data flows and external entities · Identifying trust boundaries and what makes a boundary real · Assets, crown jewels and what an attacker is actually after · Assumptions, dependencies and out-of-scope declarations · Modelling cloud and managed services you do not control · Diagram tooling: Threat Dragon, draw.io and diagrams as code
The core technique. Spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege applied per element and per interaction, with the discipline that makes elicitation repeatable — and the checklists and question sets that stop a session from stalling.
Topics: STRIDE per element versus STRIDE per interaction · Applying each category to processes, stores, flows and entities · Question sets and prompts that keep a session moving · Recognising duplicate, out-of-scope and non-threats · Recording a threat so it is actionable months later · Common threat patterns in APIs, queues, identity flows and multi-tenancy · Knowing when elicitation is complete enough to stop
Going deeper on the threats that matter. Decomposing an attacker goal into an attack tree, writing abuse cases alongside user stories so the analysis reaches the backlog, and mapping threats to MITRE ATT&CK techniques so detection engineering can be driven from the same model.
Topics: Attack trees: goals, subgoals, leaf conditions and cost annotation · Abuse cases and misuse cases beside user stories · Kill chains and attack path reasoning across services · Mapping threats to MITRE ATT&CK techniques · Using the mapping to drive detection and logging requirements · Threat libraries and reusable patterns · Where deeper analysis stops paying for itself
Security threat modeling misses an entire class of problem: systems that behave exactly as designed and still harm the people whose data they hold. LINDDUN as the privacy counterpart to STRIDE, data classification and flow mapping, and where a privacy impact assessment becomes the required output.
Topics: LINDDUN categories and how they differ from STRIDE · Linkability, identifiability and inference threats · Data classification and mapping regulated data through the system · Retention, minimisation and purpose limitation as design constraints · Cross-border transfer and residency as modelled flows · When a privacy impact assessment is required and what it contains · Coordinating security and privacy findings in one backlog
Turning a long list into a short plan. Risk rating methods and their honest limitations, prioritisation that survives challenge from a delivery lead, and the mitigation step where each accepted threat becomes a specific control — with the four standard responses and the evidence that a chosen response was implemented.
Topics: Risk rating options: qualitative scales, OWASP Risk Rating, CVSS and DREAD critiques · Likelihood and impact in a context you can defend · Mitigate, eliminate, transfer, accept — and documenting acceptance properly · Mapping threats to concrete controls rather than to intentions · Security requirements derived from the model · Writing a test or detection that proves a mitigation exists · Handling disagreement between security and delivery
Making it repeatable. Machine-readable models with pytm or Threagile, version control alongside the system, generation in CI, and the process design that decides which changes trigger a model update. Then measurement: coverage, findings per model, and whether mitigations actually closed.
Topics: Threat modeling as code with pytm and Threagile · Threat Dragon and the Microsoft Threat Modeling Tool compared · Storing models beside the code and reviewing them in pull requests · Regenerating diagrams and reports in CI · Triggers: which design changes require a model update · Integrating findings with the issue tracker and the security backlog · Measuring the programme: coverage, closure rate and recurring themes
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a levelled data flow diagram for a live multi-service architecture, mark every trust boundary, and defend each boundary against challenge from the group.
Run STRIDE per interaction across the full diagram, record each threat in an actionable form, then deduplicate and scope the resulting list.
Take a single attacker objective against a crown-jewel asset, build the attack tree, annotate cost and detectability, and identify the cheapest path.
Classify data flows by sensitivity, run privacy threat elicitation over a feature handling personal data, and decide what belongs in an impact assessment.
Rate a full threat list with a stated method, assign mitigations with owners, and write a test or detection that proves each mitigation is present.
Express a threat model as code, regenerate it from CI on design change, and file its unresolved findings straight into the issue tracker.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.