When developing and delivering data backup solutions for the private sector, we must operate within the rules and regulations of the respective country. The public sector, in comparison, has differing rules that are far more difficult to achieve. In the public sector world, there are many more rules and regulations, and compliance checks that need to be followed, along with a relatively higher order of approvals, thereby making the development and delivery of public sector data backup solutions a more complicated process.
There are three key factors that will help make a backup solution for the public sector successful - expertise, patience, and product compliance. Firstly, it is important to understand the sector’s concepts, policies, rules and regulations. This will help with the first step of setting up a dialogue with the organization. Public sector engagements are typically lengthy and detailed which means it is important to keep patience and track progress. Finally, providing the end-user with compliant product and product tools will help ensure that we are able to achieve the desired goal.
This blog attempts to delineate the requirements for a backup product to achieve public sector compliance. The public sector requirements may seem imposing, however, the best approach to address the following minimum set of requirements is to at least wet your feet and then make incremental changes to fulfill additional requirements.
DoD Security requirements
Commercial-Off-The-Shelf (COTS) software products using or requiring the use of Public-Key cryptography are typically tested to ensure interoperability with the appropriate DoD Public Key Infrastructure (PKI) and verified against security requirements specified in what is called a Reference document prior to procurement. COTS products not passing interoperability testing will not be procured unless interoperable alternatives providing the requisite functionality are unavailable.
A good starting point would then be to approach a public sector organization and obtain such a reference document. The document itself is a kind of questionnaire categorized in a high, medium, and low set of requirements. Answering the questionnaire and getting it ratified both internally and with the organization will provide the initial look at the product’s compliance status. Critical requirements that are not in compliance will need to be addressed either by providing alternate workarounds or by making changes to the product.
FIPS 140-2
Federal Information Processing Standard (FIPS) 140-2 specifies the security requirements for cryptographic modules that protect sensitive information. The standard ensures that a product uses sound security practices, such as approved, strong encryption algorithms and methods. It also specifies how individuals or other processes must be authorized in order to utilize the product, and how modules or components must be designed to securely interact with other systems. The requirement also covers both in-flight and data-at-rest encryption.
Products can achieve FIPS 140-2 compliance by following the Secure Development Life Cycle (SLDC). By reviewing threat models of all product components, doing code reviews, and running security scans, it is important to list down all cryptographic usage within the product. The product must then be self-tested and validated against only approved crypto algorithms. A product can initially be FIPS compliant where only certain aspects of the product is tested and approved. But the ultimate goal should be to have the product FIPS-approved where the entire product is tested and approved. It is recommended to always integrate third-party FIPS-certified modules within the product to achieve the highest level of compliance.
Public Key Access Card Private Identify Verification Infrastructure/Common
This requirement talks of the ability of the product to perform Multi-Factor authentication (MFA) whenever the public sector employee needs to access a resource. Multi-factor authentication using user X.509 digital certificates forms one of the common methods employed in the public sector. Users can present their digital certificates in many ways such as Smart Card and Biometrics. User certificates are then validated against a certificate authority. The process of authentication using user certificates comprises of two levels of authentication. The first is what the user possesses such as the smart card and the second is what the user knows usually a PIN or token that the user will also have to enter.
Products could either implement MFA using either PKI proxy method or the native PKI method. Under PKI proxy, the product essentially leverages the MFA already performed by the underlying OS and validates the user digital certificate with the OS directory services. On the other hand, the native PKI method is where the product invokes the PKI infrastructure to prompt the user for the PIN and extract the certificate and use that to complete the authentication.
IPV6
The IPv6 requirement is to ensure that all ports and protocols used by the product support native IPv6 and dual-stack communications.
As a first step, an extensive self-testing effort can be carried out to test the product operations in the various IPV6, IPV4, and dual-stack configurations so that any gaps identified can be addressed. As a next step, the product team can approach an external vendor such as the University of New Hampshire (UNH) Interoperability Laboratory (IOL) who offer service of IPV6 testing including the IPV6 Ready logo which could boost product marketability.
Platform Hardening/DISA STIGs
Another important metric is the DISA STIG that refers to an organization (DISA — Defense Information Systems Agency) that provides technical guides (STIG — Security Technical Implementation Guide). STIG provides technical guidance to secure information systems/software that might otherwise be vulnerable. The DoD regularly updates STIGs to ensure that developers are able to:
- Configure hardware and software properly.
- Implement security protocols.
- Organize training processes.
There are a number of commercial tools available that can perform STIG scans to list and identify potential weaknesses in your code.
Trade Agreement Act (TAA)
The Trade Agreement Act (TAA) for the U.S. is important to meet so products can sell into the U.S. Goverment space. The critical part of TAA is to describe the transformation of the End Product. There are three categories that are evaluated:
- 100% developed in a TAA country
- 100% developed in a Non-TAA country
- "Mixed development" in multiple TAA and Non-TAA countries. Where "mixed" development occurs, the "build" phases are reviewed to define transformation (i.e. the conversion of source code to object code).
TAA requires the TAA form to be completed and reviewed for compliance.
Achieving all the above for a backup product will allow the public sector sales professional to approach the public sector organizations with confidence.
Backup Exec
Backup Exec product has been able to achieve full public sector compliance as shown in the table below.
The public sector compliance in Backup Exec allows us to move a step forward towards achieving growth among our public sector customers. It does this by way of continuous review, follow-ups, updates to the product and with some patience.
Finally, it represents our continued commitment to quickly bring incremental improvements to new features and security enhancements that we release based on feedback from our customers.
If you are not a current Backup Exec customer, we invite you to learn more about the solution at the following link: www.backupexec.com
