Page tree
Skip to end of metadata
Go to start of metadata
Purpose

This page gives information about some of the quality rules which are present under the Security health factor and why exactly they are included. The aspects which are considered while including them under some Technical criterion when mapped under the Security Health Factor is also explained.

Below is a screenshot which shows one of the Quality Rule named: "Avoid empty catch blocks" that has been mapped to a Technical Criteria that comes under the Security.

Applicable in CAST Version

 

Release
Yes/No
8.3.x(tick)
8.2.x(tick)
8.1.x(tick)
8.0.x(tick)
7.3.x(tick)
7.2.x(tick)
7.0.x(tick)
Applicable RDBMS
RDBMS
Yes/No
Oracle Server(tick)
Microsoft SQL Server(tick)
CSS2(tick)
CSS1(tick)
Details

The fact that a rule contributes to the security Health Factor does not mean it is by itself a security flaw. There are various Quality Rules that are mentioned under the Security Health Factor, but they don't state that there is a security flaw. Some of these rules are mentioned below:

  1. Avoid double checked locking.
  2. Avoid Struts 2 Action Fields without Validation
  3. Avoid to use this within Constructor in multi-thread environment
  4. Action Artefacts should not directly use database objects
  5. Avoid cyclical calls and inheritances between packages
  6. Avoid empty catch blocks
  7. Avoid using Fields (non static final) from other Classes

The reason for this is that the Assessment model is structured as follows : Quality Rules are mapped to a Technical Criteria, which is then mapped to a Heath Factor. And as you can see in the above screenshot, the Quality Rule "Avoid empty catch blocks" is under the Technical Criteria "Programming Practices - Error and Exception Handling" and this Technical Criteria is mapped to the Security Health Factor.

This means that the Technical Criteria is calculated based on the results of Quality Rules and we assess the application on these Technical Aspects (for instance, how well architecture is the way the app accesses its data). Then based on this, we calculate the Security score on a global aspect.

In short, the security flaw is not the individual rule which is getting violated, but it is the fact that the architecture is bad for the application, or that error management's best practices are not followed which contributes to the Security Health Factor.

AIP does implement rules which correspond to standard security practices. You can refer to the page below for more information on the Security aspects that are considered while implementing these rules in CAST AIP: CMS Assessment Model - Information - Security Standards                 

Notes/comments


Related Pages




  • No labels