Download PDF - Codenomicon

CODENOMICON WHITEPAPER - Proactive Cyber Security: Stay Ahead of Advanced Persistent Threats (APTs)
11
Fuzzing Best Practices
Fuzzing can be used to test all software and software components
with hardware, so you can use it to test all types
applications, services and network equipment like routers,
switches and servers, and also security software like antivirus
and firewalls [6]. The cost of not fuzzing can be high.
It can be costly, if an important network element is offline
or services unavailable, never mind the consequences of an
advanced cyber attack.
As an acceptance condition
Many vendors are in a hurry to push software onto the market,
and often times it is the user who ends up doing the
testing [12]. Actually, software products have the highest
rate of defects of product sold today [12]. By insisting on
using fuzzing as an acceptance condition, you can make
vendors claim responsibility over the quality and security of
their products [6]. A prominent US ISP already uses fuzzing
as entry criteria for its network suppliers [7]. The Codenomicon
Defensics test suites automatically collect all important
information on found vulnerabilities into a Remediation
Package, which you can send to third parties for automated
reproduction [23].
During SDL
Large software houses already include fuzzing as a part
of their secure development lifecycles: Cisco’s CSDL, Microsoft’s
SDLC and the Adobe Product lifecycles are good
examples of this. Giants like IBM and Google also promote
fuzzing [12]. The Microsoft secure development lifecycle
(SDL) model endorses the use of fuzzing in the verification
phase [24]. However, fuzzing can be used throughout the
development process from the moment the first software
components are ready to even after the release [24]. The
earlier the vulnerabilities are found, the easier and cheaper
it is to fix them [1]. Indeed, by building security into your
software you can avoid costly, critical and embarrassing
software blunders.
During production
In addition to fuzzing before development, the production
environment should also be tested, because testing elements
in isolation does not always reveal the same issues as
testing a live environment [6]. However, this may disturb the
tested system, because it is essentially simulating an attack
against it [24]. Thus, it should only be done after extensive
testing and in the presence of support personnel [24].
Augmenting parameter security defenses
During the lag time between threat discovery and signature
deployment, the IDS (intrusion detection system) is
unable to identify the threat [23]. Help your defenses block
attacks exploiting zero-day vulnerabilities by using the extensive
documentation that Defensics provides [23]. The
test cases triggering vulnerabilities in your system are described
clearly making it easy to write your own IDS rules
[23]. The rules can be based on vulnerabilities found by running
predefined Defensics tests, or testing around known
vulnerabilities downloaded from third party vulnerability
feeds [23]. You can also use Defensics to generate variations
of the original attack and to test how well IDS/IPS systems
and firewalls can detect and block both the original attack
and variations of it [23].