Question

Prepare A RFP for an organization to upgrade anti-virus in it.And please include System acquistion processes in it

Answer 1

The first step is to get down to a short list: those vendors you are willing to evaluate further by inviting them to respond to your RFPs. For this round, you don’t need to provide detailed requirements. Instead, start with a statement of purpose that incorporates a high-level summary of each requirement category in “Out with the Old, In with the New: Replacing Traditional Antivirus” product features/capabilities, operational requirements and business requirements.

First, perform a systematic search to identify potential products and vendor contacts. Sources of information can include trade shows (RSA), background research via the Web, and conversations with other colleagues and clients. Next, winnow down the list, sending your statement of purpose to the contact for each selected vendor. You might also consider a short set of questions that address key concerns, such as how the vendors support their customers and how compatible the product may be with your infrastructure. Ask for written responses and product literature. For the most promising vendors, you may want to request a product demonstration, preferably conducted over the Internet. The outcomes from this step are twofold: 1. You will have identified a short list of vendors, preferably two to three, to participate in the more in-depth RFP process. 2. You will use the product and vendor information gathered to inform and refine your detailed requirements in each category.

Step 2: Create a Detailed Request for Proposal
In-depth evaluation and analysis of responses from this short list of vendors should include the means and methods to review: • Product features and capabilities, assessing the product’s durability against modern-day attacks • Operational requirements, focusing on how your end users and administrators will interact with the NGAV solution • Business requirements, identifying those factors that directly affect what the product will cost to deploy and its potential to accrue benefits • Vendor background and pricing information, addressing how stable the vendor is, what services it offers and its product pricing These areas are all covered in a template SANS has developed as an RFP form for NGAV evaluation (see Appendix A for a copy). The RFP form, which includes instructions for customization and directing vendor responses, is based on the “Out with the Old, In with the New: Replacing Traditional Antivirus,” aligned with the evaluation approach outlined in Step 3, “Evaluating Responses.” As you move forward, be sure to download the “NGAV RFP Evaluation Master Template,” an Excel spreadsheet you can use for vendor scoring, calculating ratings and comparing vendor,

Step 3: Evaluate Responses The next step is to develop an evaluation plan. The RFP template in Appendix A contains mandatory pass/fail requirements, requirements that can be scored, desirable requirements and pricing options. The evaluation plan includes a comprehensive evaluation of the qualifications of the vendors, the business solution being offered and the solution cost.

When well-executed, a POC is a win-win for all involved, ensuring that you set the right expectations at the beginning of the client-vendor relationship, which is critically important to the long-term success of any technology initiative. The POC should include a well-developed plan of action, similar to an actual test plan, that identifies 1) the design of the test environment (i.e., a lab that will provide a scaleddown version of the production environment); 2) the approach to evaluation (e.g., testing); 3) roles and responsibilities (yours and the vendor’s) needed to conduct the POC; and 4) how to document all outcomes, issues and problems for further consideration during implementation.

POC Step 1: Prepare Before you develop your POC plan of action, go back to the scenarios the vendor provided with its proposal. Work with the vendor to: • Confirm that the scenario addresses all the requirements during the POC or understand the limitations that will prevent all requirements being addressed. Many organizations have issues involving infrastructure restrictions, malware/ sample acquisition, inability to simulate advanced multistage attacks or limitations related to involving multiple parties (e.g., IT, security operations center [SOC], red and blue teams). Will these limitations affect implementation and if so, how? • Discuss the details of all key processes, what effort will be required, and what portions are or could be particularly challenging, especially those details that cannot be fully addressed in the POC. • Gain insight into how the vendor will affect your organizational change management process, especially from the perspective of resources and associated costs. What might happen if the requirements should change, as they most likely will, during an actual implementation? The vendor should be prepared to test a variety of “what-if” scenarios, representing typical changes that end users might request. This provides both you and the vendor with insight into the effort and additional costs associated with change requests that might occur during the implementation project.

Next, develop your POC plan of action and obtain approval, from both your organization and your vendor. A POC is considered a pass/fail test that is extremely important for your vendor to pass. Your plan should document the pass/fail criteria—similar to a product test plan—and provide clarity on what is considered a pass versus a fail.

POC Step 2: Execute The POC needs to address three broad evaluation categories with proper testing: • Functionality, answering the question: “Does the product do what it says it will do?” • Compatibility (i.e., integration) • Usability.

Functionality Build functional tests that will evaluate the product against the requirements in the RFP sections and evaluation matrix related to product features and capabilities. The test environment can be fairly simple; you may want to use some of the tools provided by independent test labs to evaluate features and capabilities. However, also consider how the NGAV solution handles unanticipated situations, such as unknown malware variants or zero-day threats. Consider techniques such as these: • Run a known sample of malware and verify that the antivirus application is able to detect and prevent the sample successfully. Then, encode the same sample of malware using freely available packing software; this creates an “unknown” sample. Run this new sample and verify that the antivirus application is able to detect and prevent it successfully. • Introduce any external media device with a file embedded with a virus, then verify that the antivirus application is able to detect the virus successfully. • Introduce any external media device with a file embedded with more than one virus, then confirm that the antivirus application is able to detect all of the viruses successfully. • Introduce a file without any virus and confirm that the message “No error detected” is displayed on the screen.

Perform a compatibility evaluation. Learn what impact the NGAV would have on your production environment. This evaluation is essentially akin to the system integration testing phase during the software development life cycle, where you would document and prioritize any issues with system or applications performance in a test environment that simulates the production environment.

Evaluate Usability Usability evaluation is a bit more subjective. You are evaluating whether the end users and administrators will like how the product works. You should develop usability tests that mirror the typical workflows of your end users and administrators, as well as any managers to whom you may need to present results.

Consider using user acceptance testing (UAT), which consists of a set of tests that verify whether a solution not only meets your specific functional and technical requirements, but can work for your users as well. Your selected NGAV product may meet all your functional requirements, but if it has a negative impact on user productivity, it won’t be a win for your organization. Conduct a formal UAT after you validate functionality and after, or in concert with, compatibility testing.

System acquistion processes

Security risks and events occur throughout a system’s lifetime. This is true whether the system is developed internally or purchased for on premise hosting or cloud implementation. Security should be embedded throughout all phases of the system development life cycle, assessed during system acquisition processes, and monitored during system maintenance, including disposal.

Investigate and review how your institution acquires new software. Understand the procurement processes in place when selecting vendors; particularly for cloud services.

Determine whether processes encourage proper assessment of vendor relationships and cloud environments before contracting. For example, Northwestern University has a clearly defined process for assessing vendors–Service Provider Security Assessment.

Verify that processes include acceptance criteria which will give assurances that security requirements are met.

Review and evaluate previous vendor contractual agreements for security protections. Helpful documents:

Data Protection Contractual Language contains sample contractual language for contracts.

Legal and Quasi-Legal Issues in Cloud Computing Contracts contains information that may be useful in specifying security requirements.

Develop a plan, if needed, for improving the contracting process with campus procurement and/or other stakeholders.

See Supplier Relationships for more information on supplier relationships and security controls.