Upcoming Standards – SCAP ARF Support

The Assessment Results Format (ARF) language is a general Security Content Automation Protocol (SCAP) results reporting language developed by the US Department of Defense (DoD) in conjunction with NIST and members of the SCAP vendor community. If you are unfamiliar with it, it provides a structured language for exchanging and exporting detailed, per-device assessment data between network assessment tools. ARF is intended to be used by vulnerability scanners, eXtensible Configuration Checklist Description Format (XCCDF) scanners, and other tools that collect detailed configuration data about IP enabled devices.

Simply, Asset Reporting Format (ARF) is a data model to express information about assets, and the relationships between assets and how to generate reports from the data. The standardized data model facilitates the reporting, correlating, and interoperability of asset information throughout environments and toolsets. ARF is a vendor neutral technology and one of the emerging standards for SCAP support. 

So why is this so important ? Consider the following use cases:

1. Report the results of an assessment using SCAP content using a data stream defined by NIST 800-126. This provides a vehicle for SCAP scans to report data regardless of technology used to perform the assessment or configuration audit.
2. Report the results of any device in a standard format by platform, configuration, patches, and/or vulnerabilities when no SCAP content is available. This provides a standardized reporting output from any tool, vulnerability assessment scanner  or even an asset inventory tool in the same format.
3. Report the operational context metadata for any IT assets. This provides clarity into the assets operational runtime parameters and software in the same format.
4. Collect all asset data in a central location and provide situational awareness reports based on any context.

The primary intent is to allow tools to become “best of breed” but allow the output to be generated in a single format such that data warehousing, reporting, and information integration can be achieved without supporting custom connectors and various proprietary data feeds. 

eEye’s Retina Network Security Scanner has already taken the first step to achieving this vision. Version 5.12.0 and higher now supports the ability to export SCAP content in ARF. When the draft specification of ARF 1.1 becomes certified eEye looks to incorporate the other use cases into the product and allow transparency for all exported data regardless of scan type. 

ARF is an emerging data standard that will enhance third party integrations and allow collaborative results to be shared and reported on between tools and vendors. eEye looks forward to this emerging data standard and our initial support of the draft specification. For more information on eEye and our support for SCAP or ARF, please click here.

Generic Third Party Integration

There is an inherent value to vulnerability assessment and attack data beyond the security team. Making relevant data available to other solutions, departments, and team members can streamline the vulnerability management process and ensure the workflow is seamless between departments and management. In addition, having tight data integration makes it easier to document workflow processes required by most regulatory compliance initiatives. Take for example this simple diagram for Retina CS and a generic integration into the Windows Application Log.

Critical events can be filtered as they entered into the management console and forwarded to the Application Log. Any third party event log watcher can trigger from these events to perform addition actions or notify appropriate individuals. This simple process can be documented as follows:

This type of generic integration can be used to tie virtually any system to eEye’s solutions and raise the value of the data being collected without the need for any custom code. In addition, eEye supports the following generic integration points into each of our solutions.

Based on these, a client can do everything from custom control of the scan engine to direct access of the data warehouse and integrated alerting functions. Some custom integrations that have been performed by our clients include:

To that end, eEye has embarked on an aggressive third party integration program (with our partners) the following out of the box integrations that go far beyond basic event log scraping.

These solutions work seamlessly with eEye to raise the awareness of vulnerability assessment data and provide a streamlined workflow for your business requirements. For more information regarding eEye and our third party integrations, please click here.

Better Security Management with a Consolidated View of AV and Vulnerabilities

We expect our smart phones to handle all of our business needs: phone calls, voicemail, email, and calendar functionality, at the very least. Why not expect the same consolidated approach with your security products? Take for example the relationship between vulnerabilities and malware. Most of the malware, trojans, worms, etc., get into a system by exploiting vulnerabilities in applications such as Adobe, IE, Firefox, etc. Vulnerabilities and malware really have a strong correlation and so should the products that manage each one. 

Here at eEye, we have taken this consolidated approach for years, first with the introduction of the REM management console and most recently with Retina CS. These consoles, at their core, allow an IT professional to easily manage endpoint protection agents as wells as vulnerability assessment data from a single location.

eEye’s unified approach comes with many benefits:

Unfortunately, I have seen many environments where there is a disconnect between vulnerability management and endpoint protection. In some cases, vulnerability assessment is not part of the picture at all! These environments also tend to rely just on an anti-virus application for protection. This is equivalent to saying, “Let the vulnerabilities I don’t know of be exploited and let the malware be delivered. I only want to be protected against known threats and I want this protection to occur once the malware is on my system and has subsequently triggered a signature.”  I’m not saying that you should not have an anti-virus, but rather that your endpoint protection agent should combine an AV layer with other layers of protection.  These other layers should not be signature-based and should provide Zero-Day protection.  Blink, eEye’s endpoint protection solution, is a clear example of this. Blink takes a multi-layered approach to security and combines vulnerability assessment as part of its package. 

Want a consolidated view of your environment? See an On-demand Demo of Retina CS.

Role-Based Access for Your Teams

Regulatory controls all require the access restriction of sensitive data to the individuals that need to know. Many corporate policies also segregate users to access devices by geographical location or by platform and function. Vulnerability data is sensitive information. In the wrong hands, it provides a blueprint on how to potentially access systems without proper permissions and provisioning.  Many discussions have occurred regarding how to safeguard this data internally and how trusting you should be of a SaaS solution to house this data. Regardless of the vulnerability management solution implementation, restricting improper access to assessment data has traditionally been IP address based. That is a list of IP addresses or host names which governs who has access to what vulnerability assessment data and assets. People generally refer to these as “Sites” or “Policies”.  Within eEye we refer to them as “Smart Groups”.

In many organizations, IP addresses are not allocated per business function. Subnets can have a mix of printers, desktops, and occasionally servers. Subnets are generally allocated for the raised floor, DMZ, and other supporting infrastructure but the user space and supporting infrastructure is generally all over the board and not standardized. Many companies still do not even use standardized naming conventions for hosts and this represents another challenge for asset identification. So, how do you build role based access for a Desktop Administrator when they may have a dynamic IP list to manage; especially in consideration of DHCP? How would you delegate VA data to the infrastructure team for let’s say for only Cisco devices? Do you even have a list of all the devices that can be imported and is it maintained regularly for corrected assessment and ultimately proper role based access?

In a previous blog, I discussed advanced targeting techniques with Retina CS and how a Smart Group can be constructed on any OS, software installed, patterns in the host name, etc. Consider this technique also applies to the Role Based Access Model within Retina CS. Various Smart Groups can be constructed for only Desktop Operating Systems, Windows Servers, Red Hat Linux, or even only Cisco Devices completely independent of the IP addresses assigned to them. Retina CS will maintain the group automatically with each subsequent scan of the target and keep them up to date regardless of host name or any other traditional “Site” based techniques. The User Based Security Model within Retina CS allows you then to assign User Groups to the Smart Groups and control access based on business function rather than just traditional IP space. If users are uncomfortable with that model, Smart Groups can be built from Address Groups and Active Directory just like any other traditional VA solution or even better, a combination of both! Users can be restricted to a certain platform or device type and the IP range it may be present in. For an enterprise environment, this is priceless. A remote office can have VA data solely for a Desktop Admin in the building he/she works in regardless of DHCP and device type; workstation or laptop.

Consider that role based access for your vulnerability assessment data means so much more in the proper hands rather than in the wrong hands. It can improve your overall security posture and make sure individual teams are response for their security patches and not just the security team providing reports on how to fix the problem. Role based access is a fundamental part of Retina CS and will help you change the way you manage vulnerability data within your environment; secure, role based, and business function delegated. For more information on Retina CS, please click here.