By Steve Bigelow, Features Writer
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Security risk analysis does not take place in a vacuum. Proper testing relies on the knowledge and expertise of the solution provider, but it also requires a broad array of tools to assess every attribute of the client's infrastructure. And this is just the beginning -- once data is acquired, it must be analyzed and translated into a meaningful report that explains findings and makes practical recommendations for remediation.
The first part of this Hot Spot Tutorial introduced the basic concepts of threats and risk and essential elements of a security analysis. This second installment introduces popular security assessment tools, highlights the major elements of a security risk analysis report and offers several best practices for solution providers.
Qualitative versus quantitative risk analysis
Security risk analysis may include the use of both qualitative and quantitative testing. Qualitative testing typically takes place without specific numerical results, while quantitative testing attempts to make measurements or gauge performance based on repeatable criteria. For example, a security risk analysis may reveal a qualitative vulnerability in a server where an operating system has not been patched to the required level. The same analysis may also suggest intrusion if traffic levels spike unexpectedly when compared to a previously established numerical baseline.
The one thing that qualitative and quantitative testing have in common is the practical use of software and hardware tools. There is no single securityrisk assessment tool or testing suite. In practice, testing relies on a diverse array of tools that allow a solution provider to scan, probe, log, measure and evaluate the client's organization from the perimeter firewall all the way to the individual desktops.
"In our library, we have over 350 different tools to conduct all sorts of scans," said Andrew Plato, president of Anitian Enterprise Security, a security solution provider in Beaverton, Ore. Some tools are suited for broad, general-purpose testing, while other tools may be highly targeted toward specific devices, such as Cisco routers.
Security assessment tools
There are numerous general-purpose security risk assessment tools available, including RiskPAC, CORAS, OCTAVE, Proteus, RiskOptix and RSAM. Each tool varies dramatically in scope, level of automation or intelligence and the amount of technical information that it gathers. Many of these tools are actually intended to assess risk based on regulatory compliance or other business issues. Consequently, solution providers should match the tool to the objectives of each analysis.
But solution providers often need to go further, thoroughly testing key attributes of the client's network and end users. A detailed analysis often begins with an assessment of antivirus and antispyware tools in the client's environment -- looking for current subscription status along with available engine and signature file updates.
Vulnerability scanning is often next, typically employing several different scanners to check for vulnerabilities in networks, Web systems, software and devices. These scanners include the Acunetix Web vulnerability scanner, GFI LANguard network security scanner, Nessus vulnerability scanner, Network Mapper (Nmap) and SAINT.
Solution providers like Plato also suggest going beyond scanning with exploit-level tools that can provide detailed information for solution providers performing penetration testing, IDS testing and signature development and exploit research. These tools include Metasploit and Core Impact, which replicate attacks against network servers and workstations, end-user systems and Web applications.
Forensic tools also have a place in the analyst's toolbox, allowing solution providers to investigate and learn more about incidents as they occur and study them after the fact. Network analyzers are commonly used for this kind of work and can establish baselines for other traffic-related analysis such as intrusion detection. There are also notable tools to help with forensic analysis, such as Helix, CA Network Forensics, NetDetector and even dedicated hardware appliances like NetIntercept.
It's important to point out that the security assessment tools covered here are not an all-inclusive list. There are hundreds of different products that a solution provider can use to address myriad issues. Some tools may employ formal testing frameworks around security standards like ISO17799 or focus on the security implications of specific compliance standards like PCI-DSS, SOX, GLBA or HIPAA. Your toolbox will inevitably grow as more tools are acquired to meet the unique needs of different clients and changing threats.
Preparing security risk analysis reports
Ultimately, the testing and evaluation process is used to gather data about the client and their network, people and business -- it's a means of gaining insight into the client's organization. Once qualitative and quantitative data is obtained, it must then be processed into a report for the client.
This period of analysis is really what underscores the skills and expertise of a solution provider. "A good report has to cull a lot of data together," Plato said, noting that the majority of the analysis is done after the on-site testing and evaluation are complete. "I like to tell customers that the on-site assessment portion of our work is really no more than a quarter of the actual time it takes us to do a project."
While many security risk analysis reports contain the same basic elements, solution providers normally tailor their reports for the needs of each client. Most security risk analysis reports start with an executive overview that presents an overall summary of the project. The report then details the findings for each major area of evaluation (such as vulnerabilities), along with prioritized recommendations and suggestions for remediation. Recommendations should include justification or reasoning that helps the client understand why that recommendation is being made and why it's important to the business.
It's not unusual to see reports that tie financial and compliance consequences into the recommendations and suggestions. Wade Wyant, managing partner at ITS Partners LLC, said his company will usually make time to include financial implications "because that's how you convince them to make the changes." ITS is a Symantec consultancy headquartered in Grand Rapids, Mich.
Some solution providers also provide more details about test methodologies, tool versions and configurations, test scripts, setup conditions and other details that can be used to replicate the testing process. Raw data may be included as well, though this can be voluminous and doesn't add much value to the overall report.
Insiders like Plato note that the most important element to any security risk analysis is insight -- performing the tests and taking the time to understand the client's total environment, then preparing a report that is comprehensive and meaningful. "Unfortunately there are a lot of security practitioners out there that will run a couple of Nessus scans, print out a report and call that an assessment," Plato said. "That will not give you insight into an organization and its issues."
Training your staff
Successful security risk assessment and analysis and clear reporting depend heavily on the people performing the work. Many IT professionals are event-driven -- even solution providers. IT mentality is generally "cause and effect" or "product-centric." These are beneficial mindsets for professionals that must understand equipment and infrastructure in order to respond to user requests and fix problems.
However, security testing and analysis require a more contemplative perspective that is often at odds with busy IT workloads, as well as training in proper security analysis and audit techniques. "Don't try to take a router jock and think you're going to turn them into a security analyst or auditor overnight -- it's probably not going to happen," Plato said. This is one of the key reasons why many analyst firms do not actually perform remediation work, or the remediation is performed by a different group within the firm.