What it is.
Seguro! is a system that allows you to manage the execution of Web application security tests without any exchange of documents related to any vulnerabilities detected.
With Seguro! it is possible to define and apply a clear and immutable process for test management, identifying the responsibilities of individual actors and keeping track of each event that occurred, so that it is always possible to understand who did (or did not do) what.
All information about the applications remains within the system; notification messages sent to users do not reveal the outcome of the attacks and do not contain either the name of the application or the vulnerable URL, only identification codes.
The system does not perform automatic scans but can capture log files from products such as Burp or AppScan so that any vulnerabilities can be detected more quickly.
System features.
Seguro! is a Web-based application written in the PHP language.
It has an intuitive and consistent user interface that makes it easy to use even for non-technical personnel.
Dialogue with the mySQL database is by means of stored-procedures that make the system more secure and reliable.
User access can take place either with local users or with LDAP users.
Authentication can be either with username and password or with a system-generated digital certificate and password.
The system has a dual system of event logs, which are saved both in the system database and on an external file, so that feedback is available in case of random or intentional alterations.
Risks associated with security testing.
Web application security tests, whether vulnerability assessment, DAST or pen-test, include at least the following steps:
-
System survey: collection of information needed to perform the test, such as URL, login credentials, architecture, functions, etc.
-
Test execution: the system is tested, recording the outcome of each test performed.
-
Test outcome notification: the test results are notified to the development team.
-
Vulnerability correction: the development group corrects the code or modifies the configuration of the system so as to remediate the detected vulnerabilities.
-
Testing of corrections: the test is repeated, to verify that the corrections made have healed the vulnerabilities.
Each of these steps involves an exchange of highly confidential information about the system; in particular, it necessarily requires the testing group to report to the development group the vulnerabilities found.
The reports are transmitted (usually) securely, by means of encrypted documents, but the large number of recipients of the information - system owners, project leaders, developers, etc. - means that the information is present in the clear on multiple workstations (or cell phones), making the process insecure.
If the computer of one of the actors is compromised, or if an inexperienced programmer prints out the report and leaves it on his desk, the security of the system is at risk.
Benefits of Seguro!
All of these problems are solved by Seguro! by keeping within the system any information that might allow an attack.
The reports produced by Seguro!, whether they are reports on the outcome of a test session or messages about an individual vulnerability never contain information about vulnerable URLs, only the alphanumeric codes that identify them within the system.
In this way, even if a malicious user were to come into possession of the results of a test, he or she would have only a generic list of the application’s vulnerabilities, but no useful data for exploiting them.
An additional benefit of Secure! is that it imposes a well-defined and immutable process on each actor, preventing deviations from good behavior practices.
Authentication with digital certificates (not mandatory, but highly recommended) also ensures non-repudiation of actions taken by users.
Summary tables on each user’s home-page allow those responsible for the various functions to keep a constant eye on the progress of the tests pertaining to them.
Users and user groups.
Seguro! has a very granular division of user roles; this allows the minimum possible privileges to be granted to each user at all times.
Users with management roles, on the other hand, can “demote” themselves and take on an executive role to independently complete certain process steps even when absent due to illness or during vacation periods.
Users are divided into three groups:
- operation: responsible for operating the systems;
- security: users in charge of systems security;
- development: users in charge of application development of the systems.
For a complete description of the users and roles, see the Presentation document.
Program flow.
The program flow can be divided into three stages:
- execution of security tests;
- correction of vulnerabilities:
- verification of fixes;
Security Testing
- the Testing Manager creates a new module and releases it for testing;
- the Security Group Manager starts testing the module;
- the members of the Security Group test the various URLs of the form and report the outcome of the attacks into the system;
- the security group manager closes the tests with OK or KO outcome;
- the Web Manager reviews the test outcomes and decides whether to release it or send it back to the Development Group for correction.
Correction.
If the module is vulnerable, it is submitted to the Development Group for appropriate corrections:
- the members of the Development Group correct the detected errors;
- the Development Manager closes the correction phase and the form returns to the Security Group for the phase of fix checking.
Fix checking
When the form returns to the Security Group to check the fixes:
-
members of the Security Group verify that successful attacks in the previous phase are no longer possible;
-
the Security Group manager verifies the outcomes of the checks made, repeats or deepens them if necessary, and when all detected vulnerabilities have been checked, closes the test with OK or KO, depending on the outcome of the checks;
-
the Web Manager reviews the results of the verification and, again, decides whether to send it into operation or send it back to the Development Group for correction.
For a description of the testing and correction process, see the Presentation.