According to Gartner, the application layer contains 90% of all vulnerabilities. However, do security experts and developers know what’s happening underneath the application layer? Organizations are aware they cannot afford to let potential system flaws or weaknesses in applications be exploited, but knowing the distinctions between these weaknesses can make all the difference in removing them successfully. During this webinar, Jim Jastrzebski of CA Veracode will discuss how to identify risk factors within your application landscape and share his approach to helping security and development teams address them efficiently. Learn about the methods and solutions attackers typically rely on to perform application vulnerability discovery and compromise, and hear how organizations rely on application security technology and services to gain visibility into their overall landscape—and act upon it in the right way.

1. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES1 © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES
Not All Flaws Are
Created Equal
The Difference Between a Flaw, a
Vulnerability and an Exploit
Jim Jastrzebski, CA Veracode Application
Security Consultant

2. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES2
A glossary of terms
Flaw: an implementation defect that can
lead to a vulnerability. Often caused by a
lack of appreciation for the risk, or
assumptions made about the anticipated
usage scenarios and risk exposure of the
code. A potential vulnerability.
Vulnerability: an exploitable
condition that allows an
attacker to… Attack.
A Vulnerability is a Flaw
“realized” during runtime.
Exploit: a procedure, or program,
intended to take advantage of a
Vulnerability, potentially by
leveraging one or more Flaws.
An Exploit is a Vulnerability
“weaponized” for a purpose.

3. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES3
One “Real World Example”
• A genetic predisposition to having
a bee-sting or peanut allergy, for
example, may be seen as a Flaw,
or “defect” in how one’s genetic
blueprint is implemented.
• A Vulnerability, in this scenario,
would be having that
predisposition manifest as an
immune system response to peanut
protein resulting in anaphylaxis.
• An Exploit would be someone
intentionally and knowingly causing
a peanut allergy sufferer to ingest
peanut protein, without their
knowledge, to cause a medical
crisis in order to derive some sort of
benefit.

4. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES4
• Using the wrong gauge wire as an electrical conduit would be a Flaw.
Definitely not "up to code", but it conducts electricity (will pass usage
test) and may serve the immediate intended purpose. There is a risk of
fire - the potential for vulnerability.
• The Vulnerability is that the conduit is not rated for the sort of voltage
and current it will experience. If it is used for any meaningful period of
time under a practical load, it will heat up, it will short, and it will cause
a fire.
• An Exploit would be to knowingly plug a space heater into this outlet
with the intended purpose of causing the fire.
Another “Real World Example”

5. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES5
• How would you prefer to learn about risk in your application?
• After a costly malicious breach, due to an Exploit?
• Upon finding a Vulnerability after deployment or in UAT?
• On finding a Vulnerability in Test/QA?
• During development, as code is still being written?
• Consider cost to address consequences of making the finding.
• Cost of reproduction and analysis of breach
• Cost of testing to find issue
• Cost of planning to implementation
• Cost of writing new code
Food for thought

6. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES6
All Flaws Are Not Created Equal
Static Analysis:
Finds Flaws and can
estimate but not prove
exploitability.
The application is not
executed during the
assessment.
Dynamic Analysis and
Manual Penetration
Testing:
Find Vulnerabilities by
interacting with a
running application.
Findings are made
based on how the
application behaves.
Software Composition
Analysis:
Aggregates and reports
publically-disclosed
Vulnerabilities in
applications of libraries.
The nature of the
Vulnerabilities is known
and Exploits may
already be available to
make attacks easy.

7. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES7
All Flaws Are Not Created Equal
The flaw can be exploited by
an attacker to bypass the
security model of the software
The scan incorrectly detects
a flaw pattern
The analysis is technically
accurate but the resulting
flaw is not security relevant
Flaw / Defect
Vulnerability
Mitigated
Externally
Mitigated
by Design
False Positive
A control outside the scope of the
software program prevents
successful exploitation of the flaw

8. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES8
“A stitch, in time, saves nine”
Exploitability is compelling.
If it is exploitable, we can
consider whether the risk is
acceptable or not, but not
whether it is present.
As a consequence,
organizations too often
dismiss Flaws as merely
“potential” Vulnerabilities.
The consequences of
exploitable Vulnerabilities
entail remediation of the
underlying Flaws.
You must put out the house
fire, and when you rebuild,
use better wire. OR You
must go to the ER, and
watch what you eat and
where you go, or else!
Not fixing the root cause
binds you to compensating
controls, that must be
vetted, tested and
maintained.
Ease of detection, provability
and remediation

9. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES9
Remediation or Mitigation =
Risk Management
•Defense-in-depth.
Remediate what you
can.
•Mitigate what you
can’t, and plan to
Remediate
•Compensating
Controls/Mitigations
are often runtime
dependencies that
require maintenance
and periodic
validation.
•It may be impractical to
remediate some Flaws.
•Compensating Controls
may suffice for a time
•security needs
•risk tolerance
•posture and threat
model
Determine Prioritize
Remediate
Mitigate
Monitor

10. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES10
Questions

11. © 2017 VERACODE INC. ACQUIRED BY CA TECHNOLOGIES11
LEARN MORE
Thank You!