Which Access Control And IP Video Surveillance Systems/Vendors Are DIACAP Compliant?

Does anyone know of a list (or can we create a list) of DIACAP compliant Access Control and IP Video Surveillance Systems?

Access Control:



- any others?

IP Video Surveillance :

- ?

Interesting article from GSN about DIACAP Access Control Vendor



See: What IP Cameras And VMSes Are DIACAP Compliant? Panasonic and Pelco claim to be, from what I hear.

That said, we got very little response to that discussion. I am not sure how often it is a hard requirement.

It really doesn't make sense to say that a particular product is DIACAP complaint as an information assurance and accreditation program like DIACAP really applies to a specific environment in an operational context.

It's fair to say that a given product can exist in an environment that has passed a DIACAP audit. Because of this it's convenient to say that such a product is DIACAP "certified" and that's what the Authority To Operate (ATO) is all about. The ATO mentioned in the article is very specific about the product and configuration of that product that was authorized to operate within the given DIACAP certified environment. Keep in mind with most complex IT products (and I'm thinking of a VMS or PSIM for example) there are many moving parts such as the hardware it's running on, the OS and version of the OS, as well as the version of the actual VMS or PSIM software. So while one might say the product has an ATO, what it really means is the specific configuration tested has an ATO. This configuration may not be applicable forever and doesn't necessarily translate from one job to the next.

The burden on an IT product like an IP security system in the context of a DIACAP audit is to pass network scans and provide for configurations that allow it to be a reasonably secure system that can be kept up to date with patches. For example, since many VMS systems are Windows based, the burden lies mainly with Windows. Since most IP cameras are an embedded linux and act like an appliance, the burden lies on the vendor to ensure there are not obvious network vulnerabilities. But there exists less burden to provide for things like patches to the underlying OS.

Thus, many VMS/IP camera products could be capable of existing in a DIACAP compliant environment assuming they have reasonable IT security capabilities to start with. The only way to be sure a product is capable of being DIACAP certified is to put it in an environment that goes through the DIACAP accreditation process. It's really handy for the DoD if they can keep a list of vendors' products and configurations that have gone through the DIACAP process and thus will not pose any problems when they're purchased and deployed. But many vendors may not even know that their (say) IP cameras can pass through DIACAP because they may never know they were deployed into one of these environments in the first place.

All this assumes the IP security product doesn't have some role to play in the DIACAP accreditation itself. For example if DIACAP calls for physical access ecurity to the server, and the server is secured by an IP access control system.. In that case there may be some functional features that are explicit requirements of DIACAP like maybe the access control system should keep records of door access for 180 days or some such.

This doesn't mean that a vendor can't or shouldnt try to get some mileage out of the effort that went into sheparding through a product through a DIACAP accreditation. They may have learned some valuable lessons and they will have had to exhibiit a reasonable level of IT security around that product.

Anyone care to comment on this article / claim: "DoD abandons DIACAP in favor of the NIST risk management framework"

Doesn't surprise me. There were a lot of similarities between the two and I'm sure the DIACAP administration overhead was seen as wasteful.

Again, from a product perspective not much changes--individual IT components need to pass scans and be capable of being managed for security (i.e, patched).

Thank you Steve Mitchell and John Honovich.