Iron Man

Let me introduce you to the real Application Security from Iron Man’s perspective

Navigate using the arrows on your keyboard.

Who am I

Cássio Batista Pereira

Application Security Expert

or just the AppSec guy!

a.k.a. @cassiodeveloper

I’m a brazilian guy from São Paulo, Brazil living in Crakow, Poland


I have been over 2 decades on the road, yes since I was 15 when I started breaking computers, and I’ve been:

  • developer
  • teacher
  • cyber security (so far)

Projects to the community


  • Robotics
  • Cyber War
  • Social Engineering
  • Lockpicking
  • AI


this is more or less what we will cover in this jouney:

  • Threat Modeling
  • DevSecOps
  • Vulnerability Management
  • Application Monitoring
  • AppSec Program

for help, go one slide down ˅

Use the arrows to navigate

  • some slides might contain extra topics, go down
  • some slides might contain videos and audio
  • do you want to print?
  • press O for overview mode
  • press F for full screen mode
  • press S for presenter view
  • pree B for a break

Threat Modeling

Threat Modeling is nothing more than a methodology to identify possible situations of attack on a system or part of it.

The art of finding problems, before the software even exist.

Iron Man 1

The main threat was armed mans and the main goals were: to escape the cave and go as far as possible, take no demage and attack.

From this, we can get a few lessons: with the material he had, he did the best that he could and the Mark I would not defeat Thanos. Done is better than perfect!


Threat modeling should be used in environments where there is significant security risk.

Threat modeling can be applied at the component, application, or system level.

I recommend the most granular possible, to don’t have a hufe model that will be hard to read.

Veronica a.k.a. Hulk Buster

HULK BUSTER Veronica was completely a threat modeling job, designed to contain the HULK (a specific threat) and it almost didn’t work.


Incident Response

Another very effective way of doing Threat Modeling is to use the incidents that happened in the past, history of what and how it happened helps teams to create softwares bullet-proof at least proof against known threats.

Like the case below:

Incident Response

In Iron Man III, he went to Tennessee after being attacked, and his suit was out of energy when was needed to get out. But it was winter, he was freezing in the snow.

Iron Man III

Incident Response

And then, when he created the new Spider Man suit, well…. it was equiped with a heater! When Peter felt into a lake and was rescued by Iron Man…

Spider Man

Summary pt 1

  • Your software version 1.0.1 must be better than 1.0.0.
    • Think like Tony Stak!
    • Not only fix bugs, you must improve security.
  • There is no security, without proper SDL process and teams commitment.
  • Imagine that each release of yours is a new Mark suit that Tony built.
    • Each suit is designed to protect his life, your software can’t just bring value if the value does not protect your customer / user as well.

Back to Iron Man I

He had a freezing problem with his full silver Mark II version. In the end of the movie, with Mark III he fixed the problem, but the vilain doesn’t he was using a version based on Mark II. Wrong fork dude, wrong fork!

Vulnerability become a feature \o/

  • In Iron Man II, he took a lot of demage from the energy wiplash.
  • In The Avengers, during the fight against Thor, he was able to absove the energy from the thunder, and get less demage.
  • In Avengers Ultimato, his suit now opens, absorve the full energy of the thunder and become a powerfull weapon.

Iron Man II The Avengers Avengers Ultimato

Unbeliveable threats

Sometimes you are going to face threats that you never imagined, well, if you are not prepared for the easy ones, imagine the hard ones.

Unbeliveable threats

And you are going to need to come up with a very good solution.


A fix for each problem

He tried to create a fix for each problem in Iron Man III with the Iron Legion, but it’s impossible to scale at this point.

But still, a nice try that helped him a lot in the future versions.


Lessons learned always

He coudn’t save Rhodes when he was shot by Vision in Civil War, he didn’t have enough flight speed. Then, he created the boost that we can see later in Infinity War.

Threat Model Frameworks

Threat Modeling is about imagine the unimaginable, the bad guys has no limits when they come after you.

After The Avengers, Tony starts to freak out with threats that the earth can suffer, then comes Utron (Avengers 2) and the Iron Legion (Iron Man 3), because he knew something wrose would come.


DevSecOps is not AppSec

Clearly Tony realized that carring a luggage, or coming to the garage to get his suit was not the best way. It should be portable, pocketable, easy to mount wherever he is.

We see in Iron Man III that the prototype was able to have independent parts, the same as in Civil War when he wear a watch that had defensive and attacking capabilities.

DevSecOps is not AppSec

Potts Watch

DevSecOps is not AppSec

This also make it easy to maintain and protect, just like our software.

Think, what is best, to secure a whole monolithic system, or different microservices?

The point is, you don’t need to protect your whole house, just the room where you store the most valuable assets. or the whole house if it's the case.

Before DevSecOps - Security Teams
  • Say no to most things
  • Discover vulnerabiities in production
  • Doesn’t know how to deal with other teams


Before DevSecOps - Dev Teams
  • Does not prioritize the correction of vulnerabilities;
  • Believes that the best solution to the problem is yours;
  • Your code doesn’t crash;



  • Culture
    • To make everyone within the SDL participate
  • Process
    • To have a structured way of how-to
  • Tools
    • Otherwise, you won’t scale
  • And my personal touch - AUTOMATION
    • Automation is the key to make your AppSec / DevSecOps whatever scale and work properly

DevSecOps Culture


  • Knowing how to say yes responsibly;
  • Disseminate security concerns;


  • Wanting to participate in all decisions;
  • Practice security by obscurity;

DevSecOps Process


  • Start with simple processes;
  • Always generate metrics;


  • Bypass processes for quick deployments;
  • Wanting to automate everything;

DevSecOps Tools


  • Adopt Open Source solutions;
  • See how other companies do it;


  • Not wanting to spend $$$ on tools;
  • Wanting to use all available;

DevSecOps world

DevSecOps World

DevSecOps conclusion

DevSecOps is part of AppSec, that means DSO is another area that require attention. Is not only security tools integrated in the pipeline, is further more…

  • These tools are proper configured?
  • The SAST has a proper rate of false positives?
  • The SCA is resolvind the dependencies properly?
  • Does the pipelines steps has proper access management?
  • ETC

Vulnerability Management

Vulnerability Management

I’d dare to say that Vulnerability Management is where most companies fail implementing an AppSec program. This is just a regular process and, still, companies neglect it.

Vulnerability Management

I think that at this point it’s pretty clear that Tony manages his shit. Not by mistake every new suit, or Mark, has an improvement. Either to the defense power or attack power, sometimes even both.

How about your software? Do you have a bug list? How about a vulnerability list? And a security improvement list? Security requirements maybe?

Ok no worries…

Vulnerability Management process

First you do a Preparation, that is composed by

  • Determine scope;
  • Define roles and responsibilities;
  • Select assessment tools;
  • Define policies;
  • Identify assets;


Vulnerability Management process

VM Process

Vulnerability Management tools

You can use any bug management system, task system etc that will work the same, the secret here is to centralize your vulnerabilities in one place.

But, one nice tool to use is Defect Dojo from OWASP.

Or you can still use:

  • Jira
  • Excel
  • Github Issues
  • Notepad! (Just kidding, or not)

Application Monitoring

Application Monitoring

Application Monitoring

Did you see that he didn’t ask Jarvis to help? Jarvis decided what to do, and did it by himself.

  • How dows your application behaves under attack?
  • It just fall?
  • Do you have any logs?
  • Alerts?
  • Do you even know that you are under attack?


Do you know what is the normal behavior of your applications?

Iron Man View

Real time!

Remember this scene? At real time Jarvis define a route of flight to out run the drones, even making some of them to crash.

Iron Man Scape

Real time!

It is a perfect example of application monitoring, you must have information in order to know what is happening and decide what to do, specially if you under attack.

Information is the key

Information is EVERYTHING for the correct decision making.

Tony is connected to several data sources, JARVIS knows everything to keep him informed, few things Jarvis “HAS DOUBT“.

Information is the key

See how fast sometimes we need information in order to make a hard decision?


In computing, data log is an expression used to describe the process of recording relevant events in a computer system. This record can be used to restore a system to its original state or to let someone know its behavior in the past.



Knowing the behavior of your software is essential for adequate protection, only with continuous monitoring is it possible to know the behavior of your software.

Log cycle

Log cycle

Log Architecture

Log Architecture

An example of how to collect, centralize, correlate and view your logs using the Elastic stack.

Application Security Program

AppSec Program - Points to consider

  • Define critical projects;
  • Communicate the teams;
  • Conduct training;
  • Appoint the Security Owner;
  • Define baselines;
  • Define acceptance levels;
  • Define CI/CD strategy;
  • Generate metrics & KPIs;
  • Gamification?

AppSec Program


Usually this is the mindset of the Security team, and it’s wrong. Everyone is responsible for security.

AppSec Program

Tony improvises when is needed, even without his suit he was able to dismiss a real and hard threat.


“Gods, aliens, other dimensions…I’m just a man in a can.”

Stark, Tony - Iron Man 3


“Crackers, cyber criminals, cyber war…We are just na ordinary company.”

An ordinary company

Why, well…

How about Power Plant hacking?


Why, well…

How about Critical Infrastructure hacking?


Why, well…

How about Car hacking?

Car hacking

Why, conclusion

  • Everything is controlled by software;
    • Our lifes depends on it.
  • Better society;
    • Our lifes depends on it.
  • More individual protection;
      • Our lifes depends on it.

Why, conclusion

Maybe your company is not critical infrastructure, but, what impact would bring to the society (peoples life) if you have an incident right now? Think about it next time you code!

  • Some people loose money?
  • Some people won’t be able to pay for somethig?
  • You company employees loose their jobs?
  • What else?


Bonus 1


They had close access to Thanos to try to get the gounlet, but they failed.

Bonus 1


The new nanotech suit was able to switch materials.

Bonus 2


In Iron Man I Tony was kidnaped.

Bonus 2


He then, was able to get his suit (part of it) anywhere, in Iron Man III he was kidnaped again!

Bonus 2


And he could carry any time a small attack / defense device.

Bonus 2


Iron Spider suit also had a tracking system.

The End

We are the Avengers, not the prevengers?