Who Defines the SRA Project?

Not all security risk assessments are created equal. Security risk assessments can vary greatly from one to another based on the project variables. The specification of these variables is an important element of ensuring that both the customer and the security risk assessment team have the same vision for the appropriate engagement. Consider the following project variables:

■ ?? Project Scope - The SOW should further describe the scope of the security risk assessment by clearly stating if administrative, physical, and technical controls are included in this assessment. Physical boundaries are typically defined by building address. Administrative boundaries are typically defined by a description of the policies and procedures covered by the assessment. Technical boundaries are defined as the systems, communication devices, and networks that are to be assessed. These boundaries are typically defined by system and network names.

■ ?? Deliverables - The deliverables for a security risk assessment always include the security risk assessment report. Other deliverables may be various drafts of the report, risk calculation worksheets, interview notes, etc. An SOW can go to great lengths to describe a security risk assessment report, but it simply contains four major elements. To be valuable to the customer, security risk assessment reports should clearly document the security risk assessment process, results, recommendations, and evidence.

■ ?? Security Risk Assessment Method - There is a vast difference between a security risk assessment performed by an experienced team utilizing a strong security risk assessment method and an inexperienced team utilizing a weak method. The strength of the security risk assessment method is imperative if the resultant security risk assessment report is to be used as a management tool. The specification of the method employed to execute the assessment is a very important element of specifying the project.

■ ?? Level of Rigor - Any team of security engineers could spend as little as a week or as much as six months assessing the ability of the organization’s security controls to protect its assets. A quick assessment that lasted only a single week would be forced to review the security controls with less rigor, while a security risk assessment scheduled for six months could afford to perform a more in-depth review of the existing security controls.

Typically, the customer should decide on the appropriate “values” for these project variables for their needs. The customer does have a perceived need for the security risk assessment and should what they want from the executed project. Therefore, the customer should certainly specify the project scope (logical and physical boundary) and the deliverables (e.g., executive summary, main report, presentation).

However, the security risk assessment method and the level of rigor, it is a bit more difficult to specify, or perhaps the customer should not specify at all and let prospective service providers describe that for them given a fixed budget.