Question & Answer
Question
How to Build your own query-based Vulnerability Assessment test ?
Cause
Why create a query-based test?
Answer
Most ERP systems and packaged applications control security within the application itself. – Vulnerabilities can and often do exist within the application that no amount of database security will address.
What is the query-based test builder?
Its a tool that allow users to create their own custom tests, leveraging the VA infrastructure from existing Guardium predefined tests. – Supports all the RDBMS database types that VA currently supports. – Easy to deploy; requires little programming experience. – Custom tests can be exported from one Guardium appliance to another using security assessment export
1) Navigate to Harden > Vulnerability Assessment > Assessment Builder
2) This will open the window for Security Assessment Finder Click on “Query-based Tests” after that Click on New to create a new test.
3) Click on New to create a new test.
Below are the details on the Parameters for Query-based Test Builder.
· Test Name
o Name of the test you want to use.
o Using a prefix is recommend so you can identify your test easily from Guardium tests.
· Database type
o Pick a database type from the drop-down list.
· Category
o Privileges: Check for object creation and usage rights, privilege grants to DBAs and users, and system level rights.
o Authentication: Verify password policies, default vendor accounts, no empty passwords, remote login parameters, etc.
o Configuration: Check platform-specific variables such as maximum failed logins for DBA profiles.
o Version: Verify appropriate version numbers and patch levels.
· Severity
o Pick a severity level from the drop down list that best fits your test. Note,severity can be overridden in the assessment test tuning section. You may decide that the severity level for a given test in one datasource is higher than another.
o Severity levels :-
§ Critical
§ Major
§ Minor
§ Cautionary
§ Informational
· Short description
o This is where you describe what your test does. The more descriptive the better. You can talk about scenarios that would cause your test to pass or fail.
· External Reference
o Any references you may use for this test like STIG, CIS, CVE, your company security policy benchmark, etc. This field can be left blank if you don’t have any references.
· Result text for pass
o Reason why the datasource passed this test.
· Result text for fail
o Reason why the datasource failed this test.
o Usually this means the configuration setting is not your recommended value.
o Privileges are granted to unauthorized grantees.
o Database might not be patched to some required level
· Recommendation text for pass
o Any recommendation you want to provide when a datasource passes the test. Usually there is no recommendation when a test passes.
· Recommendation text for fail
o Recommendation you are providing when a datasource fails your test. It is important to provide as much detail as you can when the test fails. You want to talk about conditions in your test that would cause a datasource to fail. Ideally, provide an example remediation syntax where possible so the end user knows what needs to be done to pass your test.
· SQL Statement
o This is the query your test will execute when connecting to a datasource. This can be a query or union of queries. You can use T-SQL or PL/SQL if your codes return a valid value that can be compared in determining the condition for the test’s passing or failing criteria.
· SQL Statement for detail
o This is the query your test will execute when connecting to a datasource. It would only execute if the condition for the test fails The purpose of this query is to provide the user detailed grants or configuration settings when a test fails so the user will know what to remediate.
· Pre test check SQL (Optional)
o Lets you write SQL that checks for a condition to determine if test should
o execute or not. This is useful when you are querying against database that
o may or may not have the tables or columns you are looking for.
o A ‘0’ return value from your SQL here would mean the test should not be executed
o and therefore the test would not get a pass or fail score.
o A ‘1’ return value from your SQL here would mean the test should continue and has
o passed the pre-test check requirement.
· Pre test fail message (Optional)
o If the “pre test check SQL” returns ‘0’, then the test would not execute. In this case, it will display the text you wrote for “pre test fail message” field.
· Loop databases & DB loop flag (Optional)
o Loop databases allow you to write SQL, indicating what databases your SQL statement should execute against. This is only supported in the following database types: Informix, SQL Server, Sybase ASE, PostgreSQL and MySQL. The looping is performed if the DB loop flag box is checked. You can use this function only when the test returns an integer value for comparison.
· Detail prefix (Optional)
o Enter a Detail prefix that will appear at the beginning of the SQL statement for string details.
· Bind output variable (Optional)
o Check the "Bind output variable" checkbox if the entered text in the SQL statement is a procedural block of code that will return a value that should be bound to an internal Guardium variable that will be used in the comparison to the "Compare to" value.
· Use Threshold (Optional)
o Check the “Use threshold" checkbox if you allow use of threshold values for your test
· Return Type, Operator and Compare to Value.
o Return type is the datatype that your SQL Statement returns. This can integer, date or string.
o Operator is the operator you want to compare your SQL statement result to the “Compare to value”. The available operators are in a drop down list like (=, <=, >=, )
o Compare to value is the value you are using to compare against your SQL Statement. If your condition is met, then the test will pass, otherwise it will fail.
· Applicable Version From and Applicable Version To (optional).
o Applicable version from and applicable version to: Use these two fields if you want to control what version of the database your test should be executed in. The format that should be use is: ##.##
4) Below is a sample Querry
Build an Assessment for the configured query
5) Navigate to Harden > Vulnerability Assessment > Assessment Builder and select your Datasource and click on Configure tests
6) Filert by “Query based” and DB type , select the Query and Add Selection.
7) It will get added to the Tests.
8) Run the test and check the status on the Guardium Job Queue.
9 ) Navigate to Harden > Vulnerability Assessment > Guardium Job Queue to check the status of the job.
10 ) View the results.
Related Information
[{"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Guardium Database Vulnerability Assessment","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"10.0;10.0.1;10.1;10.1.2;10.1.3;10.1.4","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg22013916