implemented advanced snippet selection for quotes/offertes, better denomination selection throughout document suite
This commit is contained in:
skyanth
@@ -23,10 +23,26 @@
|
||||
<translation xml:lang="nl">basis-securityscandiensten</translation>
|
||||
<translation xml:lang="en">basic security scan services</translation>
|
||||
</string>
|
||||
<string id="coverpage_service_basic-scan">
|
||||
<string id="coverpage_service_basic-scan_short">
|
||||
<translation xml:lang="nl">basis-securityscan</translation>
|
||||
<translation xml:lang="en">basic scan</translation>
|
||||
</string>
|
||||
<string id="coverpage_service_code-audit">
|
||||
<translation xml:lang="nl">code-auditing-diensten</translation>
|
||||
<translation xml:lang="en">code auditing services</translation>
|
||||
</string>
|
||||
<string id="coverpage_service_code-audit_short">
|
||||
<translation xml:lang="nl">code audit</translation>
|
||||
<translation xml:lang="en">code audit</translation>
|
||||
</string>
|
||||
<string id="coverpage_service_load-test">
|
||||
<translation xml:lang="nl">loadtest-diensten</translation>
|
||||
<translation xml:lang="en">load testing services</translation>
|
||||
</string>
|
||||
<string id="coverpage_service_load-test_short">
|
||||
<translation xml:lang="nl">load test</translation>
|
||||
<translation xml:lang="en">load test</translation>
|
||||
</string>
|
||||
<string id="coverpage_for">
|
||||
<translation xml:lang="nl">VOOR</translation>
|
||||
<translation xml:lang="en">FOR</translation>
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
intelligence agencies, or anything of the sort. If a job is even remotely
|
||||
morally questionable, we simply won't do it.</li>
|
||||
<li><b>Open-Source</b><br/>
|
||||
Releasing ALL tools and frameworks, we build as open-source on our website.</li>
|
||||
Releasing ALL tools and frameworks we build as open source.</li>
|
||||
<li><b>Teach to fish</b><br/>
|
||||
During engagements, we will not only share our results with your company,
|
||||
but also provide a step-by-step description of how to perform the same
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section>
|
||||
<title>Code Audit</title>
|
||||
<p>
|
||||
<company_short/> will perform a code audit to aid pentesting. During a
|
||||
code audit, we manually examine the code of an application to ensure there
|
||||
are no security vulnerabilities and use our understanding of the code to
|
||||
guide our pentesting. If vulnerabilities are found, we document those and
|
||||
suggest ways to fix them. This is done by highly-trained penetration testers
|
||||
who can both review the raw code as well as interpret the findings of the
|
||||
automated scans, putting them into context.
|
||||
</p>
|
||||
<p>
|
||||
During the code audit portion of penetration tests, we take the following
|
||||
criteria into account:
|
||||
</p>
|
||||
<ol>
|
||||
<li>Risk Assessment and "Threat Modeling"<br/>
|
||||
In this step, we analyze the risks of a particular application or system.
|
||||
Threat Modeling is a specific, structured approach to risk analysis that
|
||||
enables us to identify, qualify, and address the security risks, thus
|
||||
dovetailing with the Code Review process. For example, user data is
|
||||
sacred. We focus on encrypted storage, discover if <client_short/> employees
|
||||
have a backdoor into data, and cut loose stolen devices by wiping them
|
||||
remotely and revoking accounts.
|
||||
</li>
|
||||
<li>Purpose and Context<br/>
|
||||
Here we focus on risks, especially in the quick and easy sharing of
|
||||
internal documents and itineraries. Account details aren't so secret
|
||||
when we know who will be in meetings, but what's being discussed is secret.
|
||||
</li>
|
||||
<li>Complexity<br/>
|
||||
The complexity of the system is in the frameworks that support the web
|
||||
application. We'd ignore those and focus only on the custom code and
|
||||
backend code. We would also
|
||||
focus on implementation mistakes and known flaws in the systems. For
|
||||
example, we'd ensure you're using the latest versions of software,
|
||||
but we wouldn't delve into the framework itself. Since we assume the
|
||||
code is written by a team, it should be clearly-written code. If you have
|
||||
several full-release versions, there will undoubtedly be several revisions
|
||||
and audits on that code.
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
For more information, please refer to this link:
|
||||
<a href="https://www.owasp.org/index.php/OWASP_Code_Review_V2_Table_of_Contents">
|
||||
https://www.owasp.org/index.php/OWASP_Code_Review_V2_Table_of_Contents</a>
|
||||
</p>
|
||||
</section>
|
||||
@@ -1,40 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section>
|
||||
<title>Code Audit</title>
|
||||
<p><company_short/> will perform a code audit to aid pentesting. During a
|
||||
code audit, we manually examine the code of an application to ensure there
|
||||
are no security vulnerabilities and use our understanding of the code to
|
||||
guide our pentesting. If vulnerabilities are found, we document those and
|
||||
suggest ways to fix them. This is done by highly-trained penetration testers
|
||||
who can both review the raw code as well as interpret the findings of the
|
||||
automated scans, putting them into context.</p>
|
||||
<p>During the code audit portion of penetration tests, we take the following
|
||||
criteria into account:</p>
|
||||
<ol>
|
||||
<li>Risk Assessment and "Threat Modeling"<br/>
|
||||
In this step, we analyze the risks of a particular application or system.
|
||||
Threat Modeling is a specific, structured approach to risk analysis that
|
||||
enables us to identify, qualify, and address the security risks, thus
|
||||
dovetailing with the Code Review process. For example, user data is
|
||||
sacred. We focus on encrypted storage, discover if <client_short/> employees
|
||||
have a backdoor into data, and cut loose stolen devices by wiping them
|
||||
remotely and revoking accounts.</li>
|
||||
<li>Purpose and Context<br/>
|
||||
Here we focus on risks, especially in the quick and easy sharing of
|
||||
internal documents and itineraries. Account details aren't so secret
|
||||
when we know who will be in meetings, but what's being discussed is secret.</li>
|
||||
<li>Complexity<br/>
|
||||
The complexity of the system is in the frameworks that support the web
|
||||
application. We'd ignore those and focus only on the custom code and
|
||||
backend code. We would also
|
||||
focus on implementation mistakes and known flaws in the systems. For
|
||||
example, we'd ensure you're using the latest versions of software,
|
||||
but we wouldn't delve into the framework itself. Since we assume the
|
||||
code is written by a team, it should be clearly-written code. If you have
|
||||
several full-release versions, there will undoubtedly be several revisions
|
||||
and audits on that code.</li>
|
||||
</ol>
|
||||
<p>For more information, please refer to this link:
|
||||
<a href="https://www.owasp.org/index.php/OWASP_Code_Review_V2_Table_of_Contents">https://www.owasp.org/index.php/OWASP_Code_Review_V2_Table_of_Contents</a></p>
|
||||
|
||||
</section>
|
||||
@@ -0,0 +1,27 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section>
|
||||
<title>Terms and Conditions</title>
|
||||
<p>
|
||||
<company_short/> will only perform the <company_svc_short/>
|
||||
if it has obtained the permission from <generate_permission_parties/>
|
||||
as set out in the waiver, attached as <b>Annex 2</b>,
|
||||
or provided in a separate document.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<company_short/> performs this assignment on the basis of its general
|
||||
terms and conditions, which are attached to this offer as Annex 1.
|
||||
<company_short/> rejects any general terms and conditions used by
|
||||
<client_short/>.
|
||||
</p>
|
||||
<p>
|
||||
In order to agree to this offer, please sign this letter in duplicate
|
||||
and return it to:
|
||||
</p>
|
||||
<contact>
|
||||
<name><company_legal_rep/></name>
|
||||
<address><company_long/><br/>Overdiemerweg 28<br/>1111 PP Diemen</address>
|
||||
<email>melanie@radicallyopensecurity.com</email>
|
||||
</contact>
|
||||
<generate_offer_signature_box/>
|
||||
</section>
|
||||
@@ -0,0 +1,22 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<section>
|
||||
<title>Disclaimer</title>
|
||||
<p>
|
||||
It is important to understand the limits of <company_short/>'s services.
|
||||
<company_short/> does not (and cannot) give guarantees that something is
|
||||
secure. <company_short/>, instead, has an obligation to make reasonable
|
||||
efforts (in Dutch: “<i>inspanningsverplichting</i>”) to perform the
|
||||
agreed services.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
<company_short/> and <client_short/> agree to take reasonable measures to
|
||||
maintain the confidentiality of information and any personal data they gain
|
||||
access to in the course of performing the code audit. Both parties will use the
|
||||
information and data they receive or access only for the purposes outlined
|
||||
in this agreement.
|
||||
<company_short/> warrants that all core-team members, external freelancers,
|
||||
and volunteers it engages to perform the code audit have signed a
|
||||
non-disclosure agreement (NDA).
|
||||
</p>
|
||||
</section>
|
||||
@@ -0,0 +1,45 @@
|
||||
<?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.<br/>
|
||||
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>Thorough comprehension of functionality<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>Static analysis<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>Dynamic analysis<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>
|
||||
</ol>
|
||||
</section>
|
||||
@@ -1,15 +1,118 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<snippet_selection>
|
||||
<!-- QUOTES -->
|
||||
<!-- [NOTE: when creating a new offerte subtype, please make sure you have at least one snippet_group with @set="group1"] -->
|
||||
<document type="offerte">
|
||||
<selection subtype="pentest">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet_group set="group1">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet>prerequisites</snippet>
|
||||
<snippet>disclaimer</snippet>
|
||||
<snippet>methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="additionalcodeaudit">
|
||||
<!-- isolated since it is subject to logic (unlike some people) -->
|
||||
<snippet>additional-code-audit_methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="group2">
|
||||
<snippet>teamandreporting</snippet>
|
||||
<snippet>planningandpayment</snippet>
|
||||
<snippet>aboutus</snippet>
|
||||
<snippet>conditions</snippet>
|
||||
<snippet>generaltermsandconditions</snippet>
|
||||
<snippet>waiver</snippet>
|
||||
</snippet_group>
|
||||
</selection>
|
||||
|
||||
<selection subtype="basic-scan">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet_group set="group1">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet>prerequisites</snippet>
|
||||
<snippet>disclaimer</snippet>
|
||||
<snippet>methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="additionalcodeaudit">
|
||||
<!-- isolated since it is subject to logic -->
|
||||
<snippet>additional-code-audit_methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="group2">
|
||||
<snippet>teamandreporting</snippet>
|
||||
<snippet>planningandpayment</snippet>
|
||||
<snippet>aboutus</snippet>
|
||||
<snippet>conditions</snippet>
|
||||
<snippet>generaltermsandconditions</snippet>
|
||||
<snippet>waiver</snippet>
|
||||
</snippet_group>
|
||||
</selection>
|
||||
|
||||
<selection subtype="load-test">
|
||||
<snippet_group set="group1">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet>prerequisites</snippet>
|
||||
<snippet>disclaimer</snippet>
|
||||
<snippet>methodology_load-test</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="additionalcodeaudit">
|
||||
<!-- isolated since it is subject to logic -->
|
||||
<snippet>additional-code-audit_methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="group2">
|
||||
<snippet>teamandreporting</snippet>
|
||||
<snippet>planningandpayment</snippet>
|
||||
<snippet>aboutus</snippet>
|
||||
<snippet>conditions</snippet>
|
||||
<snippet>generaltermsandconditions</snippet>
|
||||
<snippet>waiver</snippet>
|
||||
</snippet_group>
|
||||
</selection>
|
||||
|
||||
<selection subtype="code-audit">
|
||||
<!-- no additional code audit presumed :) -->
|
||||
<snippet_group set="group1">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet>prerequisites</snippet>
|
||||
<snippet>disclaimer_code-audit</snippet>
|
||||
<snippet>methodology_code-audit</snippet>
|
||||
<snippet>teamandreporting</snippet>
|
||||
<snippet>planningandpayment</snippet>
|
||||
<snippet>aboutus</snippet>
|
||||
<snippet>conditions_code-audit</snippet>
|
||||
<snippet>generaltermsandconditions</snippet>
|
||||
<snippet>waiver</snippet>
|
||||
</snippet_group>
|
||||
</selection>
|
||||
<selection subtype="other">
|
||||
<!-- standard -->
|
||||
<snippet_group set="group1">
|
||||
<snippet>introandscope</snippet>
|
||||
<snippet>projectoverview</snippet>
|
||||
<snippet>prerequisites</snippet>
|
||||
<snippet>disclaimer</snippet>
|
||||
<snippet>methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="additionalcodeaudit">
|
||||
<!-- isolated since it is subject to logic -->
|
||||
<snippet>additional-code-audit_methodology</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="group2">
|
||||
<snippet>teamandreporting</snippet>
|
||||
<snippet>planningandpayment</snippet>
|
||||
<snippet>aboutus</snippet>
|
||||
<snippet>conditions</snippet>
|
||||
<snippet>generaltermsandconditions</snippet>
|
||||
<snippet>waiver</snippet>
|
||||
</snippet_group>
|
||||
</selection>
|
||||
</document>
|
||||
|
||||
|
||||
<!-- CONTRACTS -->
|
||||
<!-- [NOTE: when creating a new contract subtype, please make sure you have at least one snippet_group with @set="agree1"] -->
|
||||
|
||||
<document type="contract">
|
||||
<selection subtype="single_engagement">
|
||||
<snippet_group set="parties">
|
||||
@@ -23,7 +126,7 @@
|
||||
<snippet>wa_contractorcan</snippet>
|
||||
<snippet>wa_noemploymentintention</snippet>
|
||||
</snippet_group>
|
||||
<snippet_group set="agree">
|
||||
<snippet_group set="agree1">
|
||||
<!-- define agreement -->
|
||||
<snippet>ag_noemployment</snippet>
|
||||
<snippet>ag_companyinstructs</snippet>
|
||||
|
||||
Reference in New Issue
Block a user