Vulnerability Assessment FAQ

Here you will find answers to some of the most frequently asked questions about Vulnerability Assessments.

 

What is a Vulnerability?

A flaw or weakness in a system that could allow an attacker to compromise the confidentiality, integrity, or availability of the system or data.

What is a Vulnerability Assessment?
  • A series of manual and automated processes and procedures used to assess and prioritize security vulnerabilities in a system (i.e. application and/or infrastructure)
  • A VA can target applications, underlying servers/infrastructure, or both
  • Conducting a VA helps to determine the security posture of the environment and the level of exposure to threats. VA will identify vulnerabilities by evaluating if the system has the proper controls in place as they were designed and meant to be implemented
When is a VA required?
  • Before a new system or application goes live
  • When a current system or application is replaced or upgraded
  • When a system or application’s remote access requirements or user base changes (e.g. system needs to be accessed from outside MUN)
  • After previously identified vulnerabilities are remediated (i.e. retest)
How do I Request a VA? What’s the Process?

A VA is requested by contacting the ITS Service Desk (help@mun.ca). Once a ticket has been created for the VA request, a member of the VA team will contact the Requester to provide VA Readiness Checklists, discuss schedule and to determine whether a pre-VA meeting is needed.

On the scheduled date, the VA team will begin scanning and testing; this can take between 1-10 days depending on the complexity of the system. Once scans are complete, the VA team will analyze the results and write a VA report. Depending on the nature of the results, the VA team may schedule a meeting with the Requester to review the report.

Figure 1: VA Process

 

 

Application Go Live - What’s the Process?

The VA is just one piece of the process to go live.

After the VA is complete, there are usually vulnerabilities identified. Any finding that can be remediated must be remediated, any finding that cannot be remediated requires sign off for the associated risk.

It is the responsibility of the Requester to coordinate remediations and to update the VA report indicating what the resolution was for each finding (e.g. vulnerability was remediated, unable to remediate because vendor won’t update code, etc.). Once each finding has been resolved, the Requester must contact the Service Desk to initiate the VA process (Figure 1) again for a retest. This loop will continue until there is nothing further to remediate.

Once the VA is complete and there is nothing further to remediate, the VA team will generate a risk letter which must be signed by the director of ITS and the Dean/director/Department head of the Requester’s Department. After the risk letter has been signed the application can go live.

Figure 2: Go Live Process

 

 
What is the Pre-VA Meeting?

This meeting provides the basis for the scope of the VA. The purpose of this meeting is to:

  • Provide stakeholders with an opportunity to understand the VA process and provide input
  • Set expectations for the VA and scope the work to be performed by the assessor
  • Discuss VA readiness
  • Discuss schedule
  • Demo of application to be VA’d (if applicable).
What prep is needed before the VA begins?

The VA will only be scheduled when the infrastructure and application environments are in their final state (i.e. no more changes are required and the system is ready for implementation into Production) and all user access (i.e. test, Production or pilot users) is frozen or disabled. If features still need to be added, bugs still need to be addressed, items still require configuration, or the system is still located in its development environment, the system is not ready.

How long does it take to conduct a VA?

VA typically consists of 1-2 weeks of scanning/testing followed by 1-2 weeks of analysis and report preparation, wait time for VA to start is typically 3-4 months. Sample timeline:

Week before VA start, Requester:
  • Confirms readiness checklists are up-to-date
  • Provides account credentials
  • Arranges for snapshot of all servers to be taken
  • Communicates that all servers and applications in VA scope are frozen (i.e. absolutely no work should be done while VA is taking place)
Week 1 - Hands-on VA testing by assessor
  • ITS communicates VA has begun
  • Infrastructure and application scans and manual tests take place
Weeks 2 & 3
  • Further scanning/testing (if required), analysis of testing results, preparation of the VA Report, delivery of VA Report to Requester and, if required, meeting held to go through results
Who is responsible for remediating issues in the VA Report?

Remediation of all items as stated in the VA Report is the responsibility of the Requester and their project team. All remediation efforts must be documented by the Requester.

What prep is needed before retest begins?
  • Remediate vulnerabilities if possible
  • Resolution table on VA report must be completed for each vulnerability regardless whether it will be remediated or not
  • Any remediations that have been implemented must be tested to ensure proper application functionality
  • Arrange for snapshot of all servers to be taken
  • Communicate that all servers and applications in VA scope are frozen - absolutely no work should be done while retest is taking place
Who approves the VA Report Response?

When remediations are complete a VA retest must be scheduled or a Risk Letter drafted to include vulnerabilities that will not be remediated for Go-Live. The Risk Letter is approved by the director of ITS and the dean/director of the department requesting the VA.