Skip to main content
edited tags
Link
AviD
  • 73.6k
  • 24
  • 141
  • 222
added 916 characters in body
Source Link
David Stubley
  • 2.9k
  • 1
  • 20
  • 29

What evaluation criteria would you use to select the right Oracle scanning tool?

Context:

To deploy an automated scanning tool (nessus / SQuirreL etc) for use by both development teams and security teams.

One tool to be used by both teams during the build stage, ongoing management (patching, changes to DB structure) and for assurance related activity (such as internal audit or security review).

One example for this would be:

Ability to restrict password cracking. While this may have value for the security team, I would not want the development team to be able to crack passwords.

So at the risk of now providing my own answer (still keen to have more thoughts on this!). I have come up with the following:

  • Does the tool provide compliance reports generated against own internal standard

This would be useful for the Dev team to ensure build meets required level.

  • Does the tool produce Compliance reports generated against external standard

Such as CIS or NIST, as this would be for the Security team to compare the delta between the approved build and industry best practice.

  • Ability to conduct a Vulnerability Scan

Does the build actually provide enough protection? Using a vulnerability scanning / analysis approach to test the build for security exposure.

  • Dose the tool produce a report on missing patches?

  • Can I restrict scanning to specific assets / user groups?

Any others that would be useful?

What evaluation criteria would you use to select the right Oracle scanning tool?

Context:

To deploy an automated scanning tool (nessus / SQuirreL etc) for use by both development teams and security teams.

One tool to be used by both teams during the build stage, ongoing management (patching, changes to DB structure) and for assurance related activity (such as internal audit or security review).

One example for this would be:

Ability to restrict password cracking. While this may have value for the security team, I would not want the development team to be able to crack passwords.

What evaluation criteria would you use to select the right Oracle scanning tool?

Context:

To deploy an automated scanning tool (nessus / SQuirreL etc) for use by both development teams and security teams.

One tool to be used by both teams during the build stage, ongoing management (patching, changes to DB structure) and for assurance related activity (such as internal audit or security review).

One example for this would be:

Ability to restrict password cracking. While this may have value for the security team, I would not want the development team to be able to crack passwords.

So at the risk of now providing my own answer (still keen to have more thoughts on this!). I have come up with the following:

  • Does the tool provide compliance reports generated against own internal standard

This would be useful for the Dev team to ensure build meets required level.

  • Does the tool produce Compliance reports generated against external standard

Such as CIS or NIST, as this would be for the Security team to compare the delta between the approved build and industry best practice.

  • Ability to conduct a Vulnerability Scan

Does the build actually provide enough protection? Using a vulnerability scanning / analysis approach to test the build for security exposure.

  • Dose the tool produce a report on missing patches?

  • Can I restrict scanning to specific assets / user groups?

Any others that would be useful?

Tweeted twitter.com/#!/StackSecurity/status/75659086389194752
Source Link
David Stubley
  • 2.9k
  • 1
  • 20
  • 29

What evaluation criteria would you use for an Oracle scanning tool?

What evaluation criteria would you use to select the right Oracle scanning tool?

Context:

To deploy an automated scanning tool (nessus / SQuirreL etc) for use by both development teams and security teams.

One tool to be used by both teams during the build stage, ongoing management (patching, changes to DB structure) and for assurance related activity (such as internal audit or security review).

One example for this would be:

Ability to restrict password cracking. While this may have value for the security team, I would not want the development team to be able to crack passwords.