Kaseya US Sales, LLC Virtual System Administrator Cryptographic Module Software Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.0 Prepared for: Prepared by: Kaseya US Sales, LLC Corsec Security, Inc. 901 N. Glebe Road, Suite 1010 13135 Lee Jackson Memorial Hwy, Suite 220 Arlington, VA 22203 Fairfax, VA 22033 United States of America United States of America Phone: +1 (415) 694-5700 Phone: +1 (703) 267-6050 http://www.kaseya.com http://www.corsec.com Security Policy, Version 1.0 December 3, 2012 Table of Contents 1 INTRODUCTION ................................................................................................................... 4 1.1 PURPOSE ................................................................................................................................................................ 4 1.2 REFERENCES .......................................................................................................................................................... 4 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 4 2 KASEYA VSACM ..................................................................................................................... 5 2.1 OVERVIEW ............................................................................................................................................................. 5 2.1.1 Virtual System Administrator Server ................................................................................................................5 2.1.2 Virtual System Administrator Agent..................................................................................................................6 2.2 SECURITY ............................................................................................................................................................... 6 2.2.1 VSA Server Security................................................................................................................................................6 2.2.2 Agent Security ..........................................................................................................................................................7 2.3 MODULE SPECIFICATION ..................................................................................................................................... 9 2.4 MODULE INTERFACES .......................................................................................................................................... 9 2.5 ROLES, SERVICES, AND AUTHENTICATION .....................................................................................................10 2.5.1 Crypto Officer Role ............................................................................................................................................. 10 2.5.2 User Role ................................................................................................................................................................ 11 2.6 PHYSICAL SECURITY ...........................................................................................................................................13 2.7 OPERATIONAL ENVIRONMENT.........................................................................................................................13 2.8 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................13 2.9 EMI/EMC ............................................................................................................................................................15 2.10 SELF-TESTS ..........................................................................................................................................................15 2.11 DESIGN ASSURANCE ..........................................................................................................................................16 2.12 MITIGATION OF OTHER ATTACKS ..................................................................................................................16 3 SECURE OPERATION ......................................................................................................... 17 3.1 INITIAL SETUP......................................................................................................................................................17 3.2 CRYPTO OFFICER GUIDANCE ..........................................................................................................................17 3.2.1 Initialization ........................................................................................................................................................... 17 3.2.2 Management ........................................................................................................................................................ 17 3.2.3 Non-Approved Mode of Operation................................................................................................................ 17 3.3 USER GUIDANCE ................................................................................................................................................18 4 ACRONYMS .......................................................................................................................... 19 Table of Figures FIGURE 1 – KASEYA VIRTUAL SYSTEM ADMINISTRATOR SYSTEM OVERVIEW ....................................................................7 FIGURE 2 – LOGICAL BLOCK DIAGRAM .................................................................................................................................8 FIGURE 3 – GPC BLOCK DIAGRAM ........................................................................................................................................9 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................8 TABLE 2 – FIPS 140-2 LOGICAL INTERFACES ..................................................................................................................... 10 TABLE 3 – MAPPING OF CRYPTO OFFICER ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS (CRITICAL SECURITY PARAMETER), AND TYPE OF ACCESS .......................................................................................................................... 10 TABLE 4 – MAPPING OF USER ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ...................... 11 TABLE 5 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .......................................................................................... 13 TABLE 6 – LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS ................................. 14 TABLE 7 – POWER-UP TESTS AND DESCRIPTIONS ............................................................................................................ 15 TABLE 8 – CONDITIONAL TESTS AND DESCRIPTIONS ...................................................................................................... 15 TABLE 9 – CRITICAL FUNCTION TESTS AND DESCRIPTIONS ........................................................................................... 15 Virtual System Administrator Cryptographic Module Page 2 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 TABLE 10 – ACRONYMS ........................................................................................................................................................ 19 Virtual System Administrator Cryptographic Module Page 3 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Virtual System Administrator Cryptographic Module from Kaseya US Sales, LLC. This Security Policy describes how the Virtual System Administrator Cryptographic Module meets the security requirements of FIPS (Federal Information Processing Standards) 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 – Security Requirements for Cryptographic Modules) details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the Cryptographic Module Validation Program (CMVP) website, which is maintained by National Institute of Standards and Technology (NIST) and Communication Security Establishment Canada (CSEC): http://csrc.nist.gov/groups/STM/index.html. The Virtual System Administrator Cryptographic Module (VSACM) is referred to in this document as the Kaseya VSACM, crypto module, or the module. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: • The Kaseya website http://www.kaseya.com contains information on the full line of products from Kaseya. • The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/index.html) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package provided to the Cryptographic Module Testing Laboratory. In addition to this document, the Submission Package contains: • Vendor Evidence document • Finite State Model • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Kaseya. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Kaseya and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Kaseya. Kaseya Virtual System Administrator Cryptographic Module Page 4 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 2 Kaseya VSACM 2.1 Overview Kaseya was founded with the goal of simplifying and automating Information Technology (IT) management, providing a single congruent and highly integrated solution which covers an ever-expanding set of IT management tasks. The Kaseya Virtual System Administrator (VSA) product is intended to satisfy this goal, providing automated, secure remote monitoring, management, and protection of IT resources. The Kaseya Virtual System Administrator provides an IT automation framework allowing IT managers to proactively monitor, manage, maintain, and protect distributed IT resources using a single, integrated web- based interface. The services offered by Kaseya Virtual System Administrator are ever-broadening; as IT management services needs increase, so do the tools and services provided by the framework. In addition, the number of managed endpoints, which in this context are individual machines (laptops, desktops, servers, etc.), is also rapidly expanding. The current number of managed endpoints supported is approximately 20,000; however, Kaseya is moving quickly towards the ability to manage an unlimited number of endpoints. 2.1.1 Virtual System Administrator Server The VSA Server is the central management component of the Kaseya Virtual System Administrator. As shown in Figure 1, the VSA Server includes the following components: • KServer, which is the main Kaseya management application • Microsoft IIS1 • ASP2 framework • Microsoft SQL3 server, which communicates with a database through OLEDB (Object Linking and Embedding Database) and ODBC (Open Database Connectivity) • Administrator authentication functionality implemented in JavaScript The primary VSA Server administrative interface is provided via a web-based application, allowing remote access to the majority of administrative services. The web pages for the web-based Graphical User Interface (GUI) are served to administrator workstations via HTTP4 or HTTPS5. In addition, the VSA also provides an API6, allowing third-party application integration. The API exposes the majority of the actions and functionality available from the web GUI. The KServer component contains the core set of VSA Server functionality, providing policy configuration and deployment to the Agents, who then use the policies to automatically manage their host endpoint. By using the management interfaces provided by the KServer component the following Kaseya Virtual System Administrator management services are realized: • Endpoint policy creation and deployment • Endpoint monitoring and auditing • Automatic Agent deployment for new endpoints • Endpoint antivirus and malware management • Endpoint patch management 1 Internet Information Services 2 Active Server Pages 3 Structured Query Language 4 Hypertext Transfer Protocol 5 Hypertext Transfer Protocol Secure 6 Application Programming Interface Kaseya Virtual System Administrator Cryptographic Module Page 5 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 • Endpoint performance management The KServer component also allows an operator to perform real-time audits, virus scans, and management actions such as manually setting up tasks for individual Agents. 2.1.2 Virtual System Administrator Agent The Kaseya Virtual System Administrator Agents are software applications installed on the managed endpoints (Macintosh, Windows, or Linux-based General Purpose Computer (GPC)) and servers. Agents are the components which enact the endpoint management activities driven by VSA Server activities. The Agent management activities driven by the VSA Server typically include the following: • Automated software patching • Automated network policy enforcement • Automated antivirus scans and definition updates • Automated data backup and recovery • Automated system inventory, monitoring, and reporting • Remote control services All Agent activities are driven by policies or requested tasks generated on the Virtual System Administrator Server; however, the Agent must first connect to the VSA Server. The VSA Server component acts solely as a server and will never initiate a connection to the Agent. 2.2 Security The Kaseya Virtual System Administrator includes security functionality which provides both confidentiality and data authentication techniques to securely manage endpoints. This security functionality is described at a high-level in the following two sections. 2.2.1 VSA Server Security The VSA Server uses security functionality over two different interfaces: (1) a TCP/IP7 connection to securely communicate with and authenticate to the Agents and (2) the administrator HTTP/HTTPS interface which requires authentication: • Agent-to-VSA Server communication: All data sent between the VSA Server and Agents is sent via Transmission Control Protocol (TCP). Before the data is sent, Agents are first authenticated to the VSA Server using a proprietary shared secret-based authentication mechanism which incorporates Secure Hashing Algorithm (SHA-256). Authenticated data is sent encrypted using the Advanced Encryption Standard (AES) block cipher within the VSA Server or Agent host computer and then sent over the TCP connection. In general, the data will consist of Agent control input, IT management policies, and Agent reporting data. • Administrator Authentication: Services on the VSA Server can be accessed either locally or remotely. In order to securely authenticate an operator, the VSA Server uses a proprietary authentication mechanism incorporating the SHA-256. Within this mechanism, passwords entered on the Administrator PC (Personal Computer) are SHA-256 hashed before they are output. This ensures that the passwords are never output; only secure hashes of the passwords are output. 7 Transmission Control Protocol/Internet Protocol Kaseya Virtual System Administrator Cryptographic Module Page 6 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 2.2.2 Agent Security Agents communicate securely with the VSA Server over a TCP/IP port (default TCP port is 5721). The security provided over this interface is provided by a Kaseya-proprietary protocol which utilizes AES to provide confidentiality and authentication of the Agents to the VSA Server. • Authentication: Authentication is provided via a proprietary shared secret-based authentication mechanism which incorporates SHA-256. • Confidential Communication: All communications provided between the Agent and VSA Server are encrypted using AES, which is implemented by the Kaseya VSA Cryptographic Module. Figure 1 provides an overview of the VSA system components and configuration, while Figure 2 below provides a logical diagram of the VSACM. Note that the cryptographic boundary is depicted in each figure with a red dotted line. Administrator PC Web browser Workstation w/ Agent VSA Server GPC Operating Kserver Agent System HTTP/HTTPS TCP (Kaseya proprietary protocol) Kaseya VSA Kaseya VSA Cryptographic Module Cryptographic Module Operating System ASP framework Microsoft SQL Server Database Microsoft IIS Microsoft SQL OLEDB/ODBC Server Microsoft Windows Microsoft Windows Operating System Operating System Figure 1 – Kaseya Virtual System Administrator System Overview Kaseya Virtual System Administrator Cryptographic Module Page 7 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 Cryptographic Boundary Kaseya HMAC Value File Kaseya VSA Kaseya Application Cryptographic Wrapper Library Library Figure 2 – Logical Block Diagram The Virtual System Administrator Cryptographic Module is validated at the following FIPS 140-2 Section levels: Table 1 – Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security N/A 6 Operational Environment 1 7 Cryptographic Key Management 1 EMI/EMC8 8 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 8 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility Kaseya Virtual System Administrator Cryptographic Module Page 8 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 2.3 Module Specification The Virtual System Administrator Cryptographic Module is a software-only module that meets overall level 1 FIPS 140-2 requirements. The logical cryptographic boundary of the Virtual System Administrator Cryptographic Module is defined as the following per operating platform: Windows 7: Kaseya VSA Cryptographic Library (libkacm.dll, libkacm_ksrv.dll), Windows 2008: Kaseya VSA Cryptographi Library Server Edition (libkacm.dll, libkacm_ksrv.dll) Mac OS X: Kaseya VSA Cryptographic Library (libkacm.dylib) Linux RHEL9 5.5: Kaseya VSA Cryptographic Library (libkacm.so.1) 2.4 Module Interfaces The module supports the physical interfaces of a GPC, including the integrated circuits of the system board, the CPU (Central Processing Unit), network adapters, RAM (Random Access Memory), hard disk, device case, power supply, and fans. Other devices may be attached to the GPC, such as a display monitor, keyboard, mouse, printer, or storage media. See Figure 3 for a standard GPC block diagram. Figure 3 – GPC Block Diagram 9 RHEL – Red Hat Enterprise Linux Kaseya Virtual System Administrator Cryptographic Module Page 9 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 The modules interfaces are provided by the logical API supported by Kaseya Cryptographic Library, which provides the data input, data output, control input, and status output logical interfaces defined by FIPS 140- 2. These logical interfaces are shown in Figure 3 above. The mapping of logical interfaces to the physical ports of the GPC is provided in Table 2 below Table 2 – FIPS 140-2 Logical Interfaces FIPS 140-2 Logical Physical Interface Logical Interface Description Interface Data Input USB ports (keyboard, mouse, data), Arguments for library functions that specify plaintext network ports, serial ports, SCSI/SATA data, ciphertext, digital signatures, cryptographic ports, DVD drive keys (plaintext or encrypted), initialization vectors, and passwords that are to be input to and processed by the cryptographic module. Data Output Monitor, USB ports, network ports, Arguments for library functions that receive serial ports, SCSI/SATA ports, audio plaintext data, ciphertext data, digital signatures, ports, DVD drive cryptographic keys (plaintext or encrypted), and initialization vectors from the cryptographic module. Control Input USB ports (keyboard, mouse), network Arguments for library functions that initiate and ports, serial ports, power switch control the operation of the module, such as arguments that specify commands and control data (e.g., algorithms, algorithm modes, digest type, or module settings). Status Output Monitor, network ports, serial ports, Function return codes, error codes, or output Audio arguments that receive status information used to indicate the status of the cryptographic module. 2.5 Roles, Services, and Authentication The module does not support authentication; all roles are implicitly assumed. There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer role and a User role. 2.5.1 Crypto Officer Role The Crypto Officer role has the ability to initialize and terminate the module. Descriptions of the services available to the Crypto Officer role are provided in the table below. Table 3 – Mapping of Crypto Officer Role’s Services to Inputs, Outputs, CSPs (Critical Security Parameter), and Type of Access Service Description Input Output CSP and Type of Access Crypto Enable Initiates Power-on API Status None Self-Tests. All other Command functions will not execute until this service has been invoked and successfully returns. Kaseya Virtual System Administrator Cryptographic Module Page 10 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 Service Description Input Output CSP and Type of Access Crypto Disable Disables the crypto API Status None services; “Crypto Command Enable” will need to be invoked to re-enable them. 2.5.2 User Role The User role has the ability to perform basic cryptographic operations such as encrypt, decrypt, generate random, and hash. Descriptions of the services available to the User role are provided in the table below. Table 4 – Mapping of User Role’s Services to Inputs, Outputs, CSPs, and Type of Access Service Description Input Output CSP and Type of Access Generate Random Create a random Size Random Read DRBG Seed, ‘V’, and ‘key’ number of a specified bit length. Zeroize Overwrites a CSP that Memory None Write All CSPs was sent into the Address crypto module by a previous call. Zeroes will be written in the memory location that held the CSP and then the memory is freed. Encrypt File Encrypts the specified Plaintext Encrypted Read AES Key file using AES 256-bit File, Key File in CTR (Counter) mode and writes the encrypted data into an output file. Decrypt File Decrypts the specified Encrypted Plaintext Read AES Key file and writes the File, Key File plaintext data into an output file. Encrypt Buffer Encrypts an input Buffer, Encrypted Read AES Key buffer of data using Key Buffer AES 256-bit CTR mode and writes the encrypted data into an output buffer. Decrypt Buffer Decrypts an input Encrypted Plaintext Read AES Key buffer of data and Buffer, Buffer writes the decrypted Key data into an output buffer. Kaseya Virtual System Administrator Cryptographic Module Page 11 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 Service Description Input Output CSP and Type of Access Hash File Hashes the specified File Hash None file using SHA-256 and returns the hash result in an output file. Hash Buffer Hashes an input buffer Buffer Hash None using SHA-256 and returns the hash result in an output buffer. Key Wrap Encrypts a specified Key Encrypted Read AES Key key in accordance with Encryption Key Read, Execute AES KEK the AES Key Wrap Key, Key specification. Key Unwrap Decrypts a specified Key Key Read AES Key key in accordance with Encryption Read, Execute AES KEK the AES Key Wrap Key, specification. Encrypted Key HMAC File Create an HMAC hash HMAC Hash Read HMAC Key for a specified file using key, file HMAC SHA-256. HMAC SHA-256 Set stream buffer using Data Buffer data, Read HMAC Key Buffer HMAC SHA-256 Status Error Provide error API Status None notifications. Command Data Parameter Verify the provided Data Status None Validation parameters for a given Parameter function are valid. Crypto Module Verify the software HMAC, Status Read HMAC Key Integrity Check integrity of the crypto HMAC module. Key Get File Descriptors Opens the given file File File None name and returns their Descriptors associated file descriptors Initialize Cipher Initialize AES Stream Data Status, Read AES Key Context Cipher Ciphertext Clean Up Cipher Finalize AES Stream Data Status None Context Cipher Stream Based Stream cipher Data Status, Read AES Key Encryption encryption Ciphertext Stream Based Stream cipher Data Status, Read AES Key Decryption decryption Plaintext Data Kaseya Virtual System Administrator Cryptographic Module Page 12 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 In addition to the above services, the Show Status and Self-tests services are also available to both roles; neither service has any access to any CSPs. 2.5.3 Non-Approved Services When the module is operating in the non-Approved mode of operation (described in Section 3.2.3), the following additional service is available to the operator of the module, which uses the non-Approved AES- CBC mode. This service is only available in the non-Approved mode of operation. • Encrypt and Decrypt with AES-CBC Mode 2.6 Physical Security Virtual System Administrator Cryptographic Module is a software-only module. For the purposes of FIPS 140-2, the module is defined as a multiple-chip standalone cryptographic module, which is reflective of the GPC on which the module is installed. As a result, physical security is not applicable. 2.7 Operational Environment The Virtual System Administrator Cryptographic Module was tested and found to be compliant with FIPS 140-2 requirements on the following platforms: • MAC OS X v10.6.8, • Windows 7 (32-bit and 64-bit), • Windows Server 2008, and • Red Hat Enterprise Linux 5.5 (32-bit and 64-bit) Kaseya affirms that the module also executes in its FIPS-Approved manner (as described in this Security Policy) on other Operating Systems that are binary-compatible to those on which the module was tested; however no assurance can be made as to the correct operation of the module under these operational environments: • Microsoft Windows NT, 2000, XP, XP Pro, 2003, 2003 R2, Vista, 2008, 2008 R2, 7 • Apple Mac OS X version 10.3.9 or above • SuSE Linux Enterprise 10 and 11, Red Hat Enterprise Linux 5.4/5.5, Ubuntu 8.04-10.4, and OpenSuSE 2.8 Cryptographic Key Management The module implements the FIPS-Approved algorithms listed in Table 5 below. Table 5 – FIPS-Approved Algorithm Implementations Algorithm Certificate Number 10 11 AES ECB , CTR modes; 256-bit keys (DRBG Implementation) 1989 AES ECB, CTR modes; 256-bit keys (VSACM Implementation) 1988 SHA-256 1744 HMAC-SHA-256 1202 10 Electronic Code Book 11 Counter Kaseya Virtual System Administrator Cryptographic Module Page 13 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 SP 800-90A CTR_DRBG 185 The module provides the following non-FIPS-Approved algorithm, which is not allowed for use in a FIPS- Approved mode of operation: • AES-CBC (non-compliant) Additionally, the following algorithm is allowed in the FIPS-Approved mode for key wrapping: • AES (Cert. #1989, key wrapping) The module supports the critical security parameters listed in Table 6 below. Table 6 – List of Cryptographic Keys, Cryptographic Key Components, and CSPs Generation / Key Type Output Storage Zeroization Use Input AES Key Generated Within Wrapped via Plaintext in volatile By calling the Data AES KEK12 the Physical memory Zeroize confidentiality Boundary; Input function in Electronically in the API Plaintext via API Call AES KEK Generated Within N/A Plaintext in volatile By calling the Wrapping AES the Physical memory Zeroize Keys Boundary; Input function in Electronically in the API Plaintext via API Call HMAC Key Generated Within N/A Plaintext in volatile By calling the Keyed hashing the Physical memory Zeroize Boundary; Input function in Electronically in the API Plaintext via API Call DRBG Generated Within Never Plaintext in volatile Zeroize Generate Seed the Physical memory function; random values Boundary; Input Module reset Electronically DRBG ‘V’ Generated Within Never Plaintext in volatile Zeroize Used for SP Value the Physical memory function; 800-90 Boundary; Input Module reset CTR_DRBG Electronically DRBG ‘key’ Generated Within Never Plaintext in volatile Zeroize Used for SP Value the Physical memory function; 800-90 Boundary; Input Module reset CTR_DRBG Electronically 12 KEK – Key Encryption Key Kaseya Virtual System Administrator Cryptographic Module Page 14 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 2.9 EMI/EMC The test platforms used to perform operational testing comply with the EMI/EMC requirements of the FIPS 140-2 standard. 2.10 Self-Tests The Virtual System Administrator Cryptographic Module performs all self-tests required by FIPS 140-2 requirements at power-up. If the module encounters an error during a power-up or conditional self-test, the module will write the appropriate error message to an error log and then continue to unload itself from memory. In order to restart the module, the host system or calling application should be restarted. Should this operation fail to bring the module to an operational state, the module must be reinstalled following the directions in Section 3 of this Security Policy. See Table 7 for a description of all self-tests performed at power-up. Table 7 – Power-Up Tests and Descriptions Power-Up Test Description 13 AES KAT (VSACM Individual Known Answer Tests for VSACM AES implementation Implementation) AES KAT (DRBG Implementation) Individual Known Answer Tests for DRBG AES implementation SHA-256 KAT Known Answer Test for SHA-256 HMAC-SHA-256 KAT Known Answer Test for HMAC-SHA-256 SP 800-90A CTR_DRBG KAT Known Answer Test for SP 800-90A CTR_DRBG Software Integrity Test HMAC SHA-256 verifications of the crypto module The Virtual System Administrator Cryptographic Module performs all conditional self-tests required by FIPS 140-2. See Table 8 for a description of all conditional tests. Table 8 – Conditional Tests and Descriptions Conditional Test Description Continuous DRBG Test Continuous test performed to ensure no two consecutively generated values are the same, which would indicate a DRBG failure The Kaseya VSACM implements the SP 800-90 CTR_DRBG as its random number generator. This DRBG employs two critical functions which must also be tested on a regular basis to ensure the security of the SP 800-90 DRBG. Therefore, the critical function tests listed in Table 9 are also implemented by the crypto module. Table 9 – Critical Function Tests and Descriptions Critical Function Test Description DRBG Instantiate Test Test performed prior to instantiating a new DRBG. DRBG Reseed Test Test performed prior to instantiating a new DRBG 13 KAT – Known Answer Test Kaseya Virtual System Administrator Cryptographic Module Page 15 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 or before reseeding an existing DRBG. If any of the above self-tests fail, the module will enter into an error state and no cryptographic services will be available. 2.11 Design Assurance A combination of Subversion (SVN), version 1.6.5, and Author-it Enterprise Authoring Platform (EAP) version 5.4 are used to provide configuration management for the Virtual System Administrator Cryptographic Module and related documentation. These software solutions provide access control, versioning, and logging. 2.12 Mitigation of Other Attacks The module has not been designed to mitigate any attacks beyond the scope of FIPS 140-2 requirements. Kaseya Virtual System Administrator Cryptographic Module Page 16 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 3 Secure Operation The Virtual System Administrator Cryptographic Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-approved mode of operation. 3.1 Initial Setup The Virtual System Administrator Cryptographic Module does not require any additional configuration once it has been properly installed and initialized per the guidance provided in Section 3.2 below. 3.2 Crypto Officer Guidance The Virtual System Administrator Cryptographic Module is provided in the installation package of the Virtual System Administrator Server and Virtual System Administrator Agent. The module is installed onto a system during the installation of these products. The Crypto Officer is required to install the dynamic library components of the VSACM and their HMAC signature counter-parts in the same directory. 3.2.1 Initialization To place the module into FIPS mode, the calling application must invoke “__kacm_crypto_enable” upon startup to initialize the VSACM. If being called through the Kaseya wrapper library, then “kacm_start” must be called upon startup. After FIPS mode has been enabled, the CO shall ensure that AES CBC mode is not used during operation. Use of this algorithm will cause the module to operate in a Non-Approved mode. See Section 3.2.3 for further details. 3.2.2 Management The module is a cryptographic library and as such, the single-user of the module is the calling application. The application itself may service multiple operators, but the module itself will only provide services to the associated loading application. When providing service to a server, the server application makes the calls to the cryptographic module. Therefore, the server application is the single user of the cryptographic module, even when the server application is serving multiple clients. The operating system itself prevents operators from circumventing the single-user enforcement mechanism, as the module runs in separate instances. 3.2.3 Non-Approved Mode of Operation The Virtual System Administrator Cryptographic Module contains both an Approved and Non-Approved mode of operation. Instructions on how to place the module into an Approved mode of operation are available in Section 3.2.1. To take the module out of an Approved mode of operation, the CO can call “_kacm_crypto_disable”. To operate the module in a Non-Approved mode of operation, the CO must do the following: 1. Call “register_cipher()” to register the AES-256 cipher 2. Call “register_hash()” to register the SHA-256 hash 3. Set two global variables pointing the chosen cipher and hash algorithms When operating in a Non-Approved mode, the module provides all cryptographic algorithms listed in Table 5 in a non-compliant form, with the addition of AES in CBC mode. Additionally, the services listed in Table 3 and Table 4 are available to the user of the module and can be run in a non-Approved form. Section 2.5.3 presents an additional service, which is available to the operator of the module only in the non-Approved mode. AES can be used in CBC mode for encrypt and decrypt operations of files and buffers, in the non-Approved mode. While operating in the non-Approved mode, all module services are available to all operators with access to the module. Kaseya Virtual System Administrator Cryptographic Module Page 17 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 3.3 User Guidance No additional guidance is required for the User. Kaseya Virtual System Administrator Cryptographic Module Page 18 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 4 Acronyms Table 10 lists the acronyms used throughout this document. Table 10 – Acronyms Acronym Definition API Application Programming Interface ASP Active Server Pages BIOS Basic Input/Output System CMVP Cryptographic Module Validation Program CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter CTR Counter DSA Digital Signature Algorithm DRBG Deterministic Random Bit Generator DVD Digital Video Disc EAP Enterprise Authoring Platform ECB Electronic Code Book EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standards GPC General Purpose Computer GUI Graphical User Interface HDD Hard Disk Drive HMAC (Keyed-) Hash Message Authentication Code HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IIS Internet Information Services IP Internet Protocol IT Information Technology KAT Known Answer Test MAC Macintosh NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program ODBC Open Database Connectivity Kaseya Virtual System Administrator Cryptographic Module Page 19 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 3, 2012 Acronym Definition OLEDB Object Linking and Embedding Database OS Operating System PC Personal Computer PCI Peripheral Component Interconnect PCIe Peripheral Component Interconnect Express RAM Random Access Memory RHEL Red Hat Enterprise Linux RSA Rivest Shamir and Adleman SATA Serial Advanced Technology Attachment SCSI Small Computer System Interface SHA Secure Hash Algorithm SQL Structured Query Language SVN SubVersion TCP Transmission Control Protocol TDES Triple Data Encryption Standard USB Universal Serial Bus VSA Virtual System Administrator VSACM Virtual System Administrator Cryptographic Module VSS Visual Source Safe Kaseya Virtual System Administrator Cryptographic Module Page 20 of 21 © 2012 Kaseya US Sales, LLC This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13135 Lee Jackson Memorial Hwy, Suite 220 Fairfax, VA 22033 United States of America Phone: (703) 267-6050 Email: info@corsec.com http://www.corsec.com