50 lines
3.3 KiB
XML
50 lines
3.3 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section>
|
|
<title>Code Audit</title>
|
|
<p>
|
|
<company_short/> will perform a code audit. During this process we will verify if the proper
|
|
security controls are present, work as intended and are implemented correctly. If
|
|
vulnerabilities are found, we determine the threat level by assessing the likelihood of
|
|
exploitation of this vulnerability and the impact on the Confidentiality, Integrity and
|
|
Availability (CIA) of the system. We will describe how an attacker would exploit the
|
|
vulnerability and suggest ways of fixing it. </p>
|
|
<p>This requires an extensive knowledge of the platform the application is running on, as well as
|
|
the extensive knowledge of the language the application in written in and patterns that have
|
|
been used. Therefore a code audit done by highly-trained specialists with a strong background in
|
|
programming. </p>
|
|
<p> During the code audit, we take the following approach: </p>
|
|
<ol>
|
|
<li><b>Thorough comprehension of functionality</b>
|
|
<br/> We try to get a thorough comprehension of how the application works and how it interacts
|
|
with the user and other systems. Having detailed documentation (manuals, flow charts, system
|
|
sequence diagrams, design documentation) at this stage is very helpful, as they aid the
|
|
understanding of the application </li>
|
|
<li><b>Comprehensive code reading</b><br/> goals of the comprehensive code reading are:
|
|
<ul><li>to get an understanding of the whole code</li>
|
|
<li>identify adversary controlled inputs and trace their paths</li>
|
|
<li>identify issues</li></ul></li>
|
|
<li><b>Static analysis</b>
|
|
<br/> Using the understanding we gained in the previous step, we will use static code analysis
|
|
to uncover any vulnerabilities. Static analysis means the specialist will analyze the code and
|
|
implementation of security controls to get an understanding of the security of the
|
|
application, rather than running the application to reach the same goal. This is primarily a
|
|
manual process, where the specialist relies on his knowledge and expertise to find the flaws
|
|
in the application. The specialist may be aided in this process by automatic analysis tools,
|
|
but his or her skills are the driving force. <br/> Depending on the type of application, we
|
|
will identify the endpoints. In this case, it means where data enters and leaves the
|
|
application. The data is then followed through the application and is leading in determining
|
|
if assessing the quality of the security measures. </li>
|
|
<li><b>Dynamic analysis</b>
|
|
<br/> Dynamic analysis can also be performed. In this case, the program is run and actively
|
|
exploited by the specialist. This is usually done to confirm a vulnerability and as such
|
|
follows the result of the static analysis. </li>
|
|
<li><b>Fuzzing</b>
|
|
<br/> Fuzz testing or Fuzzing is a software testing technique which in essence consists of
|
|
finding implementation bugs using malformed/semi-malformed data injection in an automated
|
|
fashion.</li>
|
|
<li><b>Concolic analysis</b>
|
|
<br/> If the specialist thinks it useful, additional concolic analysis may be performed on
|
|
selected subsets of the code.</li>
|
|
</ol>
|
|
</section>
|