6.5.1—Injection flaws, particularly SQL injection; also consider Lightweight Directory Access Protocol (LDAP) and Xpath injection flaws as well as other injection flaws

The SAKA servlet does not use Structured Query Language (SQL) to communicate with its internal database (IDB)—it uses Enterprise Java Beans (EJB), which in turn use Java Persistence API (JPA) to interact with the IDB. As a result, SQL injection attacks do not work on the SAKA messaging protocol.

6.5.2—Buffer overflows

Buffer overflows are a characteristic of programming languages that do not automatically check the size of data being written to the address of a variable. SAKA is written in 100% Java, which was designed with strong typing and protection from buffer overflows in the Java Virtual Machine (JVM). As a result, SAKA does not succumb to buffer overflow attacks; any attempt to write data larger than the size of the type allocated for a variable results in an Exception from the JVM, thus protecting the application.

6.5.3—Insecure cryptographic storage

The SAKA appliance uses either a FIPS 140-2 Level 3 certified, or a CC EAL4+ certified cryptographic hardware module to store the root key of the SAKA key hierarchy. All keys under the root key are encrypted when stored on the hard disk of the appliance.

6.5.4—Insecure communications

The SAKA appliances generates its own Transport Layer Security (TLS) certificates for secure communication with clients. Not only does this provide message confidentiality and integrity on the network, but it has the added benefit that computers that do not know of the SAKA's TLS certificate will receive error messages when communicating with the appliance.

Furthermore, the SAKA can be equipped to use TLS client authentication so that client systems must also possess an X509 digital certificate when communicating with SAKA. However, the client and appliance's TLS certificates must come from a Public Key Infrastructure (PKI) to enable this level of security.

6.5.5—Improper Error Handling

The SAKA appliance logs all application level errors with a unique Error ID (EID) and message. Additionally, errors received at the operating system, database, and/or application server are logged by each component individually, thus allowing customer sites to tailor their Security Incident Event Management (SIEM) tools to handle errors appropriately.

6.5.6—All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1, above)

SAKA protects from such vulnerabilities by updating components used in the appliance software when vulnerabilities are discovered and/or made public by their manufacturers. It is noteworthy to mention that SAKA has strong controls by default. The built-in SAKA firewall restricts access to the web service port only for internal IP addresses on which authorized applications call for cryptographic services. The SAKA servers neither require, nor are enabled by StrongKey customers to have internet access.

6.5.7—Cross-site scripting (XSS)

SAKA does not use Representational State Transfer (REST)-based messages or HTML (typically used to carry out cross-site scripting attacks) between client applications and the appliance; it only uses Simple Object Access Protocol (SOAP)-based messages, and accepts and returns only XML. As such, the SAKA appliance is, in theory, immune to XSS attacks.

6.5.8—Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions)

The SAKA appliance does not return any internal object references. The design of the appliance's key management software forces a separation of the web tier (servicing web service requests) from the EJB tier which processes the request. All objects passed/returned between the web and EJB tiers are passed by value—not as references.

SAKA uses a single URL to provide all services from the appliance. The URL only accepts SOAP messages and neither redirects the calling application to any other URL nor displays any HTML. As such, the use of any other URL on the SAKA appliance results in an error message to the caller.

6.5.9—Cross-site request forgery (CSRF)

Just as SAKA avoids falling prey to XSS attacks through the use of SOAP-based calls and XML objects (as opposed to REST-based calls and HTML), it similarly avoids falling prey to CSRF attacks.

6.5.10—Broken authentication and session management

The SAKA appliance does not maintain sessions. All requests to the appliance must specify authentication credentials, and each request is authenticated independent of another.