Changes to rules flagged as critical
AIP Core 8.3.40 implements a feature improvement that is designed to reduce the number of rules provided by CAST (whether in AIP Core or in an official extension) that are flagged as critical. Over time, as more and more rules have been created by CAST, the list of rules that are flagged as critical has also grown. This has inevitably led to a situation where there are a large number of critical rules producing violations and it is therefore difficult to know where to focus the remediation efforts.
As a result of this situation, changes will be made in AIP Core ≥ 8.3.40 to reduce the number of rules flagged as critical by ensuring only a specific set of rules (those with the tag AIP-TOP-PRIORITY which mainly concentrate on secure coding and performance) are now critical. Existing critical rules that are not tagged as AIP-TOP-PRIORITY will no longer be critical and those that were never critical will have their weight changed to 1 to reduce their importance. This means that fewer rules will be flagged as critical and it will therefore be much easier to deploy remediation efforts where they are needed most.
What exactly is changing?
- For any rule tagged as AIP-TOP-PRIORITY, the critical flag will be forced to "True" and the grade thresholds of the rule will be forced to 100,100,100,100.
- For any rule not tagged as AIP-TOP-PRIORITY and already flagged as critical, the critical flag will be forced to "False".
- For any rule not tagged as AIP-TOP-PRIORITY and not already flagged as critical, the weight will be set to 1.
What is the AIP-TOP-PRIORITY tag?
The AIP-TOP-PRIORITY tag is provided by the Quality Standards Mapping extension (this extension is installed by default in AIP Console). You can see a list of rules that have this tag by using the Technologies portal RestAPI: browse to https://technologies.castsoftware.com/default.html and enter the URI
At the current time, the list of rules with the tag AIP-TOP-PRIORITY are distributed over the following Technical Criteria:
|Secure Coding - Input Validation||94|
|Secure Coding - Weak Security Features||50|
|Secure Coding - API Abuse||38|
|Efficiency - Expensive Calls in Loops||36|
|Efficiency - SQL and Data Handling Performance||10|
|Efficiency - SQL and Data Handling Performance||5|
|Programming Practices - Unexpected Behavior||4|
|Architecture - Multi-Layers and Data Access||3|
|Programming Practices - Error and Exception Handling||2|
|Secure Coding - Time and State||2|
|Programming Practices - Structuredness||1|
|Architecture - OS and Platform Independence||1|
|Secure Coding - Encapsulation||1|
How and when will this change be implemented?
This change will be implemented when AIP Core ≥ 8.3.40 and the Quality Standards Mapping extension ≥ 4th October 2021 are installed. The process of making the change is automatic and is transparent for end users. The change is made when an Assessment Model upgrade process is actioned, for example:
- Application/schema upgrade to AIP Core ≥ 8.3.40 and Quality Standards Mapping extension≥ 4th October 2021
- The installation of an extension (whether upgrade or from scratch)
- A new Assessment Model is installed in the Management schema (new application onboarding)
Is anything excluded from this change?
The following items will be excluded from the change:
- User Community and Lab extensions are excluded (even if they contain assessment model fragments)
- Any custom rule with an ID over 2,000,000 is excluded
- Any custom rule created with Quality Rule Studio is excluded
- All "other" Assessment Models such as ISO-5055, CISQ Index, OWASP Index etc. are excluded
What are the expected impacts of this change?
The expected impacts are as follows:
- If users are using either of the Preserve options for their Assessment Model upgrades (in AIP Console or CAST Server Manager), then no impact will be seen since these options preserve existing weights, thresholds and critical flags:
- If users are choosing the upgrade/use default Assessment Model option (in AIP Console or CAST Server Manager), then impacts will be seen:
- less critical rules
- weights set to 1 for some rules
- some impacts to grades (although minor)
- If users are installing AIP Core ≥ 8.3.40 and Quality Standards Mapping extension≥ 4th October 2021 from scratch, onboarding an application and comparing the same application analyzed with a previous release of AIP Core will show differences between the two.
Ability to use a CAST Storage Service/PostgreSQL database other than the default "postgres"
Changes have been made to AIP Core 8.3.40 and related tools to allow the use of a PostgreSQL database other than the default "postgres". To be able to exploit this, if required, please see below:
The ability to connect to a database other than "postgres" is not currently possible, however, changes are being made and release 1.27 / 2.0 will have this ability built in.
CAST Dashboards RestAPI
CAST Storage Service/PostgreSQL connections are defined using JDBC URLs which specify the database "postgres":
These JDBC URLs must be modified to change the "postgres" database to the custom database name (as described in https://jdbc.postgresql.org/documentation/head/connect.html) for example:
CAST Server Manager / CAST Enlighten
The UI has not been modified, however to connect to a database other than "postgres", create a new profile and either use the Server name/IP:port field or the Connection string field, for example:
When you install a set of Application schemas with CAST Server Manager, a connection profile (PMX format) for use with CAST Management Studio will be automatically created for your target CAST Storage Service/PostgreSQL instance, including the custom database name.
CAST Management Studio/pmx files
The UI for tools using .pmx connection files (such as CAST Management Studio) has not been modified to allow a connection to a database other than "postgres", however, it is possible to build/edit your own custom cast-ms.connectionProfiles.pmx and specify your custom database name. See Using the CAST-Connection-Profile-Configuration.py file.