In this blog, we’ll discuss the issues faced while scheduling backups on CipherTrust Manager.
Error
codeDesc: NCERRInvalidParamValue
errorMessage: Specified backup key does not exist for scope (system)
Description
Let’s consider that we have 4 CipherTrust Manager nodes (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com) in a cluster. As per the procedure, we’ll have to create a system backup schedule on any of the nodes, which will further get replicated on others.
Note: Backups and backup keys are not replicated across the cluster.
Cause
The primary reason for this error is that the backups occur randomly on any one of the nodes, and if the backup key isn’t present on that particular node while it is being initiated, the backup will fail.
Solution
Let’s assume we are scheduling a backup from thales01.ec.com. To resolve this error, please follow the below-mentioned steps
On thales01.ec.com, navigate to the Backup keys under Admin settings.
First, create a new system backup key and make it as default.
Download the newly created system backup key in order to upload them on other CipherTrust Manager cluster nodes.
Enter a password for the corresponding backup key and click “Download.”
Now, follow the below-mentioned path to upload the system backup key on all the CipherTrust Manager cluster nodes.
In this blog, we’ll discuss the issues of clustering encountered during CipherTrust Manager installation and configuration.
Error
A generic connection error occurred while creating the cluster. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed
Failed self-connection check. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed
Description
Let’s consider that we have 4 CipherTrust Manager nodes (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com) to add to a cluster. As per the procedure, we’ll have to select one of the nodes to create a cluster and, after that, add all the remaining nodes to that cluster. Usually, we have two options for calling out each of the appliances.
We can either mention the hostname of the CipherTrust manager or the IP address. It is, however, recommended to use the hostname instead of the IP address from a networking standpoint. The errors mentioned above are encountered during the cluster creation process when the hostname of the CipherTrust Manager is entered.
Cause
The primary reason for these errors is that the CipherTrust Manager cannot recognize the hostname. A user might encounter this issue despite setting up a DNS and a proper hostname.
Solution
Let us assume we are creating a cluster from thales01.ec.com and adding all other nodes from this server. To resolve this error, please follow the below-mentioned steps:
On thales01.ec.com, navigate to DNS hosts under Admin settings.
First, add all 4 CipherTrust Manager hostnames.
Navigate to clustering and try creating the cluster again with the hostname of the primary node (thales01.ec.com).
After creating a cluster, we will add other nodes by using their hostname from thales01.ec.com. To complete this process successfully, we’ll first have to add the primary node (thales01.ec.com) on each of the secondary nodes (thales02.ec.com,thales03.ec.com, thales04.ec.com) and then add the secondary node itself
under Admin settings-> DNS Hosts. The concept behind adding the same is for both nodes to recognize themselves as well as each other.
Once the cluster is created, all the nodes have been added, and the testing has been completed, you can delete all the DNS hosts added on each of the CipherTrust Manager appliances and check that clustering is functioning properly.
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
SSH stands for Secure Shell or Secure Socket Shell. It is a cryptographic network protocol that allows users and sysadmins to access computers over an unsecured network such as the Internet. It is used to log in to a remote server, execute commands, and transfer data from one machine to another.
Where do we use SSH?
SSH is used to replace unprotected remote login protocols like Telnet, rlogin, rsh, and others, as well as insecure file transfer protocols like FTP. Network administrators extensively utilize its protection capabilities. We can use SSH protocol in various scenarios, such as:
Enabling secure access for users and automated processes
Performing interactive and automated file transfers
Issuing remote commands
Managing network infrastructure and other mission-critical system components
How does SSH work?
The SSH protocol works on a client-server architecture, so an SSH client establishes a secure connection to an SSH server. The SSH client drives the connection establishment process and uses public key infrastructure (PKI) to verify the authenticity of the SSH server. Once configured, the SSH protocol uses strong symmetric encryption and hashing algorithms to ensure the confidentiality and integrity of data exchanged.
What are the different types of authentication?
Key-based authentication
The most commonly used form of SSH deployment is public key authentication. It is preferred over simple passwords because of enhanced security. Key-based authentication provides unmatched cryptographic strength, which is even more than that offered by very long passwords. SSH greatly increases security through public key authentication, eliminating users’ need to remember complex passwords.
In addition to security, public key authentication improves usability. This allows the user to implement single sign-on across the SSH servers he connects to. Key-based authentication also enables automated passwordless logins, a key feature of the myriad of secure automated processes running in corporate networks worldwide.
This type of authentication generates a key pair (public and private key).
The public key is copied to the SSH server and, by default, added to the ~/.ssh/authorized_keys file. Anyone who has a copy of the public key can encrypt data that can only be read by those who have the corresponding private key.
The private key remains (only) with the user. Only a user whose private key corresponds to the server’s public key can authenticate successfully. Private keys should be stored and handled carefully, and copies of private keys should not be distributed.
Disadvantages of key-based authentication
Poor SSH key management can pose a great risk to organizations.
Misuse of SSH keys can lead to confidential or privileged information access.
Since keys are trusted permanently, it increases the chances of an attack.
Certificate-based authentication
This type of authentication does not need key approval and distribution. Instead of distributing public keys across static files, we can use certificates to bind public keys to names. A certificate contains data such as a public key, a name, and additional data such as expiration dates and permissions. This data is signed by a certification authority (CA).
To enable certificate authentication, configure clients and hosts to verify certificates using your CA’s public key (i.e., trust certificates issued by your CA).
On each host, edit /etc/ssh/sshd_config, specifying the CA public key for verifying user certificates, the host’s private key, and the host’s certificate.
On each client, add a line to ~/.ssh/known_hosts specifying the CA public key for verifying host certificates.
Advantages of certificate-based authentications
It is simple to use as a trust on first use (TOFU) warnings are not displayed because certificate authentication uses certificates to communicate public key bindings, allowing clients to authenticate at all times.
It streamlines operations by eliminating the key approval and distribution process. It also reduces the operational cost of monitoring and maintaining current infrastructure for adding, removing, synchronizing, and auditing static public key files.
It promotes good security hygiene as compared to key-based authentication. The chances of a compromised private key going unnoticed for a long time is quite likely; however, certificates, on the other hand, expire, which means in case of theft, misuse, etc., it will automatically expire, thereby making it fail-secure.
Conclusion
Certificate-based authentication has many benefits, such as improving usability, enhancing security, streamlining operations, etc. If implemented, it will help organizations reduce complexities of key approval and distribution, improper key management-related risks, and much more.
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
Certificate enrollment is the process by which a user requests a digital certificate from a Certificate Authority (CA). There are several methods for enabling certificate enrollment ranging from manual methods that are initiated by a user performing the certificate request to automatic methods where the certificate request is initiated by Group Policy or a login script. Manual enrollment is not well suited for mass certificate deployment because of the amount of time an organization must spend training personnel to use such a method. In contrast, Autoenrollment, on the other hand, lowers the cost of a PKI by reducing the time and effort required to deploy certificates.
Certificate Enrollment Methods
Certificate Services Web Enrollment Pages
Certificate Services Web Enrollment pages allow a user to request both user and computer certificates from a Web browser. Certificate Services Web Enrollment pages allow the requestor to ask for specific certificate templates from an enterprise CA, submit certificate request files from a network device or another operating system and check on pending certificate requests.
Certificate Enrollment wizard
This wizard permits a user to request certificates from an enterprise CA by selecting the enterprise CA and the certificate template and defining additional settings, such as key length and CSP. The wizard can be launched from the Certificates Microsoft Management Console (MMC) console.
Automatic Certificate Request Settings (ACRS)
This Group Policy setting allows the automatic deployment of version 1 computer certificates to computer accounts in the forest. The computer account must be in the domain or organizational unit (OU) where the Automatic Certificate Request Settings is defined. In addition, the computer account must belong to a group that is assigned the Read and Enroll permissions for the version 1 certificate template.
Autoenrollment settings
This combination of version 2 and version 3 certificate templates and Group Policy settings allows the automatic deployment of certificates to users and computers. All computers or user accounts within the domain or OU where the Autoenrollment Settings Group Policy setting is applied automatically receive any published version 2 or version 3 certificate templates to which the user or computer account is assigned Read, Enroll, and Autoenroll permissions. Autoenrollment can be used for initial certificate deployment as well as for certificate renewal.
Certreq.exe
This command-line tool allows a user to create, submit, retrieve, and accept certificate requests sent to a Windows Server CA. The requests can be sent to both standalone and enterprise CAs.
Network Device Enrollment Service (NDES)
NDES is a new Certificate Services role service that enables enrollment through Simple Certificate Enrollment Protocol (SCEP), an open-source certificate management protocol.
Registration authorities
Registration authorities allow custom workflows to be defined for certificate life-cycle management tasks. A registration authority ensures that any required data collection and approvals are collected before a certificate management task is processed.
Automatic Enrollment
Before enrolling a certificate manually, automatically, or through a scripting method, you must ensure that the certificate templates are available for enrollment at a CA.
Two methods for automatically deploying certificates to users and computers are:
Automatic Certificate Request Settings
Automatic Certificate Request Settings (ACRS) is an automated enrollment process to distribute certificates automatically, but the supported scenarios are limited:
Certificates can be distributed to computers running Windows 2000 and later that are domain members.
Only version 1 certificate templates can be distributed.
Certificates cannot be distributed to user accounts. Although limited, ACRS is useful for distributing Computer or IPsec certificates to all computers in a domain
Autoenrollment Settings
Autoenrollment Settings is a combination of Group Policy settings and version 2 or version 3 certificate templates. The combination allows the domain member client computer to automatically enroll user or computer certificates.
Enrollment over Secure Transport protocol (EST) is the evolution of SCEP and uses Transport Layer Security (TLS) for client-side device authentication.
Generally, automatic enrollment is preferred by organizations; however, if the requestor cannot communicate directly with the CA or the device does not support auto-enrollment, the manual enrollment method can be opted for.
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
Certificate revocation is the process in which a certificate’s usage is terminated before the validity period expires. The choice to revoke involves knowing the available revocation reasons, mapping the revocation reasons to your organization’s revocation policy, and then performing the revocation.
Reasons for certificate revocation
Certificates are revoked by declaring them invalid if the relying parties are not using them. There can be multiple reasons for revoking a certificate which are:
AffiliationChanged
An individual is terminated, resigns, or dies, or the computer account to which the certificate was issued is no longer in use. These revocation reasons can also be used if a person changes roles within an organization and no longer requires using the certificate associated with that person’s previous role.
For example, an employee could move from the purchasing department and no longer require a certificate to authorize purchase requests.
CACompromise
You suspect that a CA’s private key has been compromised and is in the hands of an unauthorised individual. If a CA’s private key is revoked, the CA hierarchy considers all certificates below that CA (Certificate Authority) revoked.
CertificateHold
A temporary revocation that indicates a CA will not validate a certificate at that specific time.
Note: Although CertificateHold allows a certificate to be unrevoked, using the CertificateHold reason code is not recommended because it makes determining whether a certificate was valid at a specific time difficult.
CessationOfOperation
A server or workstation is decommissioned, and all certificates issued to the server are no longer required. When decommissioning a CA, you can also use this revocation reason.
KeyCompromise
You suspect that the private key associated with a certificate is compromised.
For example, if a laptop belonging to a user in your organization is stolen, any private keys stored on the laptop may be compromised.
RemoveFromCRL
You can unrevoke a certificate that you revoked using CertificateHold. The certificate is still listed in the CRL after the unrevocation process, but it also appears in a delta CRL with the revocation code set to RemoveFromCRL. The CA removes the certificate from all forms of the CRL when the next base CRL is published. If delta CRLs are not used, the certificate is removed from the following base CRL.
Superseded
A new certificate must be issued if an issued certificate is replaced for any reason with a new updated certificate. For example, if you update a certificate template and reissue certificates, you could revoke the previous certificate with this reason code.
Unspecified
You can revoke a certificate without providing a specific revocation code. However, Unspecified is not recommended because it does not provide an audit trail identifying why a certificate was revoked.
How to perform certificate revocation?
To revoke a certificate, a user must be designated as a certificate manager. You designate a user as a certificate manager by assigning the user or a group containing the user the Issue and Manage Certificates permission at the issuing CA. The permission assignment is performed by a CA Administrator, which is a user assigned the Manage CA permissions. Perform the following steps to provide the necessary permissions:
From Administrative Tools, open the Certification Authority console.
In the console tree, right-click CAName (where CAName is the logical name of the CA) and then click Properties.
In the CAName Properties dialog box, select the Security tab to ensure that the user account or a group that the user is a member of is assigned the Issue and Manage Certificates permission.
Once you assign the necessary permissions, the following procedure revokes a certificate:
From Administrative Tools, open the Certification Authority console.
In the console tree, expand CAName and click Issued Certificates
In the details pane, find the certificate you need to revoke, right-click the certificate, point to All Tasks, and click Revoke Certificate.
Select the appropriate reason code in the Reason Code drop-down list in the Certificate Revocation dialog box, and then click Yes.
Check if the certificate revoked recently is visible in the revoked certificates section.
How to identify revoked certificates?
Public key infrastructure (PKI) provides three ways to determine if a certificate has been revoked:
Base CRL
Certificate Revocation List (CRL) contains the serial numbers of certificates revoked by the CA that are signed with the CA’s private key. If you renew a CA’s certificate with a new key pair, the CA maintains two separate CRLs—one for each key pair maintained by the CA. All versions of the Microsoft Windows operating system recognize base CRLs.
Delta CRL
This contains only the serial numbers of certificates revoked by the CA since the last base CRL publication. Again, if the CA’s certificate is renewed with a new key pair, separate delta CRLs are maintained for each CA key pair. Delta CRLs allow you to publish revocation information quicker and allow smaller updates to be downloaded by client computers.
OCSP
Online Certificate Status Protocol (OCSP) provides a responder service that can either connect directly to a CA database or inspect the base and delta CRLs published by the CA to determine the revocation status of a specific certificate.
Conclusion
We must revoke the certificates when not being used by relying on parties to prevent the attackers from impersonating themselves and causing significant damage. For more information, please get in touch with us at: info@encryptionconsulting.com
Reference: PKI and certificate security by Brian Komar
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
Retrieves enrolled certificates from the CA and forward them to the network device
Best Practices
Enable SSL for the NDES administrator site
SSL protection ensures that the enrollment challenge password is protected against inspection attacks when the network device connects to the MSCEP_Admin Web site.
Create extended validity period device certificates
The default IPsec (Offline Request) certificate template has only a one-year validity period. If you define custom signing, encryption, or general-purpose certificate templates, consider creating a version 2 certificate template with a two-year validity period. A longer validity period reduces the management overhead for requesting device certificates.
Disable the NDES service when not in use
Stopping the NDES service ensures that unauthorized certificates will not be issued. Stopping the service also ensures that all data, such as all passwords that were not used by network devices, is cleared from the service cache.
Use the Security Configuration wizard to lock down the server
The Security Configuration Wizard will recommend locking down IIS and other services installed on the NDES server.
Implement Role Separation
Various accounts involved in installing, configuring, and operating NDES:
Setup Account
Device administrators
NDES account
Network Service
Group Managed Service Account (gMSA) or
Domain user account
Recommendations based on the choice of NDES account
AES encryption is required for gMSA or Domain user accounts.
Configure login restrictions and a long password for domain user accounts
Do not use gMSA or Domain user accounts on any other computers or for any other purposes
Enable the “Account is sensitive and cannot be delegated” checkbox for Domain user accounts.
Remember to manually configure permissions on the NDES’ certificates’ private keys when using a gMSA or custom certificate template.
Ensure system hardening
Reduce the number of local admins groups to include only PKI Admins. Only members of the PKI Admins group are granted any logon user rights (interactive, remote interactive, log on as a batch job, log on as a service).
Secure the keys
The following practices should be implemented to secure the keys:
It is strongly advised to use a Hardware Security Module (HSM) to generate, store, and manage access to NDES keys. HSMs ensure that the NDES keys never reside in the operating system’s memory, provide additional operational controls, and limit exposure to the key material.
If the NDES is virtualized, it is recommended that HSM should be used to store NDES private keys as the keys can be found in an unencrypted version by Virtualization’s host admins who have access to VM, disk, and memory.
Backups must be encrypted, and access should be extremely limited in case an HSM is not being used to store private keys, as Snapshots/Checkpoints and other types of backup typically contain the NDES’ private keys
Infrastructure
The following practices should be followed with respect to infrastructure for NDES:
When allowing Internet access to NDES (for example, to enroll certificates in Intune-managed mobile devices), ensure that NDES is properly protected using a reverse proxy (such as Azure AD Application Proxy or Web Application Proxy (WAP)).
NDES should be installed on a different computer than the one hosting the CA service. Furthermore, no other services should be running on the computer that hosts NDES.
If NDES is deployed on a CA computer, configure the Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) firewall rule so that only the NDES (and OCSP) IP address can access the CA for enrollment.
Certificate Authority & Certificate templates
The certificate templates assigned by default during the configuration of NDES are:
CEP encryption: A certificate based on this template is issued to the NDES computer during the configuration of the service. It is used to apply SCEP-specific encryption to the communication with the requesting client.
Exchange Enrollment Agent (Offline request): A certificate based on this template is issued to the NDES computer during the configuration of the service. The NDES uses it to digitally re-sign the enrollment request received from the device or MDM. After that, the re-signed enrollment request is forwarded to the issuing CA.
Note: Both of the above templates are used only during the initial installation of NDES and when renewing the certificate before it expires—Un-assign these templates from the CA during normal operating times. The Setup Account needs to have Enroll permissions on this template during the configuration of NDES.
This certificate template is used for enrolling device or user certificates and is automatically assigned to the CA during NDES configuration. Most of the time, you’ll decide to replace it with a certificate template that better suits your needs. The Device administrator and NDES Service Account need to have Enroll permissions on this template.
Implement Data-in-transit encryption
TLS must be used to encrypt communication between NDES and MDM/the device requesting the certificate. This includes the following:
Enforcing TLS by disabling IIS’s HTTP listener
TLS 1.2 Compliance
Conclusion
We should implement all the above-mentioned best practices to secure NDES. It is extremely important to protect the private keys as any malicious person who gets access to it will be able to request a valid certificate for logging into the Active directory with any subject.
PKCS #12 is an archive file format used for storing multiple cryptography objects in a single file. The filename extension for PKCS #12 files is .p12 or .pfx
What is a PFX file?
A .pfx file is a bag that can hold many objects with optional password protection; however, a PKCS#12 archive usually contains a certificate and the corresponding private key. The file can also include CA chain certificates as well.
What is a PEM file?
PEM is a base64 encoded certificate placed between the headers—–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–. The following file extensions are possible for PEM certificates:*.pem, *.crt, and *.cer
How to convert PFX file to PEM format?
Scenario 1: Export private key and certificate files from PFX file
The following procedure will convert the PFX-encoded certificate file into two files in PEM format.
certconvert.pem – PEM file containing the SSL/TLS certificate for the resource.
privatekeyconvert.pem – PEM file containing the private key of the certificate with no password protection.
Prerequisites
We use an OpenSSL toolkit to convert a PFX encoded certificate to PEM format. For testing this scenario, we use a password protected PFX-encoded file – certificatepfx.pfx and a 2048-bit RSA private key.
Note: Optionally, we can also have CA certificate chain as a part of the PFX file. In order to export it from the PFX file we run the following command:
Execute the following command to convert the data in the certificatepfx.pfx file to PEM format in the convertcert.pem file. The PEM file contains all of the certificates that were in the PFX file, and each of the certificates is wrapped within headers.
The Simple Network Management Protocol (SNMP) is a networking protocol used in Internet Protocol networks to manage and monitor network-connected devices. The SNMP protocol is embedded in various devices such as routers, switches, servers, firewalls, etc., that can be accessed via their IP address. SNMP provides a standard mechanism for network devices to communicate management information within single and multi-vendor LAN or WAN environments. In the OSI model framework, it is an application layer protocol.
There are three versions of SNMP: SNMPv1, SNMPv2c, and SNMPv3. The DSM supports SNMP version 1 or 2.
Components of SNMP
The following are key components of SNMP through with it performs its basic tasks:
SNMP Agent
An SNMP agent is a software process that responds to SNMP queries to provide network node status and statistics. They are located locally and are linked to SNMP network devices from which they collect, store, and transmit monitoring data. When data is queried, it is sent to the designated SNMP manager.
SNMP Manager
It is also referred to as the SNMP server and is responsible for communicating with the SNMP agent-implemented network devices. The manager queries the agents, gets responses from them, sets variables, and acknowledges events from them.
Management information base (MIB)
This exists in the form of a text file (with extension .mib) and describes all data objects used by a specific device that can be queried or controlled using SNMP. Various managed objects within the MIB can be identified using Object Identifiers (Object ID or OID).
Object Identifier (OID)
There are two types of OIDs: Scalar and tabular. These are typically represented as a dotted list of integers. MIBs hierarchically organize every OID, which can be represented in a tree structure with individual variable identifiers for each OID.
SNMP in Vormetric DSM
The Vormetric DSM can be enabled as an SNMP agent and then monitored by SNMP servers using the available MIB objects. When the DSM receives an SNMP GET request (sent to port 7025 or 161) from an SNMP server, the DSM locates the OID entry in the MIB and returns its value to the SNMP server.
SNMP is enabled via the System > SNMP page on the Configuration tab. If the SNMP Access Control List (ACL) is empty, SNMP requests from any IP address will be acknowledged. If the
SNMP ACL is defined to allow only certain IP addresses or IP address blocks to go through; the DSM will only acknowledge requests from IP addresses specified in the SNMP ACL.
The community string is typically set to a factory default value of “public”. This string must be the same for all devices in the same group for SNMP monitoring to function. For security reasons, it is advised to change the community string from “public” to a custom value.
SNMP traps are currently not supported and cannot be configured on the DSM.
The following table represents Vormetric-specific OIDs that can be queried by an SNMP server and are present under the Vormetric MIB tab. These OIDs cannot be manually changed; however, those (sysContact and sysLocation) available under System Group MIB can be customized.
OID
Description
1.3.6.1.4.1.21513.1.0
Returns the version details of the DSM
1.3.6.1.4.1.21513.2.0
Returns the fingerprint of the current DSM deployment
1.3.6.1.4.1.21513.3.0
Returns the current date and time on the DSM
1.3.6.1.4.1.21513.5.0
Returns the agent type (FS, or Key agent), the license installation state (true or false) of each agent type, and, for each installed license, the license expiration date
1.3.6.1.4.1.21513.6.0
Returns the name of each node in a DSM HA cluster configuration.
1.3.6.1.4.1.21513.7.0
Returns disk usage information for each file system mounted on the DSM.
1.3.6.1.4.1.21513.8.0
Return DSMs process, memory, paging, I/O, and CPU usage information
Shell Script
Encryption Consulting recently developed a shell script for one of its customers leveraging the SNMP functionality of Vormetric DSM to automate the process of obtaining insights on the parameters mentioned above. It can be remotely executed from a Linux or Unix host and includes all the commands required to query the DSM using the OIDs provided.
Conclusion
Configuring SNMP in Vormetric DSM can help in its monitoring through an SNMP server. The available OIDs can enable the server to gather information about the DSM with regard to contact information, physical location, version number, fingerprint, server time, license and HA configuration, and disk and system usage information. However, the SNMP functionality must be enabled only with proper security measures, such as by using SNMP ACL to restrict access to the service
Software development lifecycle (SDLC) is a systematic process for developing software that ensures the quality and correctness of the code. It aims to produce high-quality software within the stipulated time and budget as per customers’ expectations. Each phase of SDLC has its own process and deliverables, which feed into the next phase. Some popular SDLC models include Waterfall, spiral, iterative, agile, etc.
There are only a few SDLC models which explicitly address software security in detail. However, it is necessary to incorporate secure software development practices into each SDLC model. There are various reasons why organizations should plan to implement secure software development practices, which include:
To reduce the number of vulnerabilities in released software
To minimize the potential impact of the exploitation of undetected vulnerabilities
To address the root causes of vulnerabilities to prevent recurrences
Vulnerabilities not only include bugs caused by coding flaws but also weaknesses caused by improper security configuration settings, incorrect trust assumptions, and out-of-date risk analysis.
What is SSDF?
National Institute of Standards and Technology (NIST) has developed a Secure software development Framework, also called SSDF, to strengthen software’s resistance to vulnerabilities. It doesn’t define any new terminologies but consolidates longstanding best-practice recommendations on secure software development. In SSDF, the emphasis is on identifying the best practices rather than on the tools, techniques, and mechanisms used to implement the same.
As per NIST, the SSDF’s practices fall into four major categories:
Prepare the Organization (PO)
Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will also find some PO practices to apply to subsets of their software development, like individual development groups or projects.
Protect the Software (PS)
Organizations should protect all software components from tampering and unauthorized access.
Produce Well-Secured Software (PW):
Organizations should produce well-secured software with minimal security vulnerabilities in its releases.
Respond to Vulnerabilities (RV)
Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.
Each practice definition includes the following elements:
Practice
The name of the practice and a unique identifier, followed by a brief explanation of what the practice is and why it is beneficial
Tasks
One or more actions that may be required to carry out a practice
Notional Implementation Examples
One or more notional examples of types of tools, processes, or other methods that could be used to help implement a task. No examples or combination of examples are required, and the stated examples are not the only feasible options. Some examples may not be applicable to certain organizations and situations.
References
Pointers to one or more established secure development practice documents and their mappings to a particular task. Not all references will apply to all instances of software development.
NIST recommends weighing risk against cost, feasibility, and applicability when deciding which practices to implement.
The SSDF is not a checklist; rather, it guides you to plan and implement a risk-based approach to secure software development.
Advantages of SSDF:
It can assist organizations in any sector or community, regardless of their size.
It can be applied to software developed to support information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT)
It can be integrated into any existing software development workflow and automated toolchain; however, it should not have a negative impact on the organizations that already have strong secure software development practices in place.
It makes the practices broadly applicable, rather than being specific to particular technologies, platforms, programming languages, SDLC models, development environments, operating environments, tools, etc.
Conclusion
With NIST architecting SSDF, secure software development is quickly becoming a mandated priority on a large scale. If organizations adopt SSDF, it will help them remain protected from SDLC vulnerabilities and defend their software supply chains.
References
Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
Quantum computing is a field of study that focuses on the development of computer-based technologies centered around quantum theory principles. To perform specific computational tasks, quantum computing employs a combination of bits. All of this is done at a much higher efficiency than their traditional counterparts. The development of quantum computers represents a significant advancement in computing capability, with massive performance gains for specific use cases.
Quantum bits, or qubits, can be in the state of both 1 and 0 simultaneously, which in turn provides much of the quantum computer’s processing power. Due to this, a fully functioning quantum computer could break the majority of classical encryption algorithms in days, and in some cases even hours.
Quantum-safe cryptography
Post-quantum cryptography, also known as quantum-safe cryptography, refers to research efforts aimed at identifying cryptographic primitives resistant to attacks from classical and quantum computers. The ultimate goal of these efforts is to find cryptographic algorithms that are not vulnerable to any cryptographic attacks by conventional or quantum computers, thereby allowing robust security of information assets in the post-quantum world.
It is widely known that in the absence of quantum-safe cryptography, serious security issues will arise such as transmitted information through public channels could be vulnerable to eavesdropping, and encrypted data could be stored for later decryption considering the power of a quantum computer. Threats arising from quantum computing will target various sectors such as Finance and Healthcare owing to the monetary benefits majorly which can easily be derived from cryptographic vulnerabilities.
The majority of the cryptographic hashes (such as SHA2, SHA3, BLAKE2), MAC algorithms (such as HMAC and CMAK), and key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe and are slightly affected by quantum computing. Symmetric ciphers such as AES-256 and Twofish-256 are also considered to be quantum-safe. In this case the recommended key length is 256-bits or more.
However, the widely used public-key cryptosystem which includes RSA, DSA, ECDSA, EdDSA, DHKE, ECDH, and ElGamal is quantum-broken.
The following table compares the effective key strength of some popularly used cryptographic algorithms in classical and quantum computers.
Algorithm
Key Length
Effective key strength
Classical computer
Quantum computer
RSA-1024
1024-bits
80-bits
0-bits
RSA-2048
2048-bits
112-bits
0-bits
ECC-256
256-bits
128-bits
0-bits
ECC-384
384-bits
256-bits
0-bits
AES-128
128-bits
128-bits
64-bits
AES-256
256-bits
256-bits
128-bits
Progress in Quantum-safe cryptography
The possibility of a single quantum-safe algorithm suitable for all applications is quite unlikely. Many algorithms have been proposed till date but there is a large variation observed in the performance characteristics when compared with conventional public key cryptography as quantum safe algorithms use a larger key size therefore require a higher network bandwidth.
The National Institute of Standards and Technology (NIST) has started a process to standardise quantum-safe algorithms for key agreement and digital signatures. Since 2016, the institute has been working on creating quantum-safe algorithms capable of resisting threats posed by the quantum computers. The field of candidate algorithms has been narrowed down and draft standards are expected to roll out in 2022-24.
Migration to quantum-safe cryptography
Transitioning to new cryptography is complicated and will take a significant amount of time and money. Fortunately, organisations have some time before quantum-computers are implemented on a large scale. As per NCSC, ‘Organisations that manage their own cryptographic infrastructure should factor quantum-safe transition into their long-term plans and conduct investigatory work to identify which of their systems will be high priority for transition. Priority systems could be those that process sensitive personal data, or the parts of the public-key infrastructure that have certificate expiry dates far into the future and would be hardest to replace.’Here, crypto-agility might play a key role for organisations in transiting to quantum-safe cryptography as it the ability of a security system to switch between algorithms and cryptographic primitives without impacting the rest of the infrastructure. It is important for corporate leaders to start planning now for a smooth transition to a quantum-resistant security.
Conclusion
We must recognise that quantum computing indeed poses a serious threat to conventional information security systems. Organisations are recommended to plan a robust and secure transition to quantum-safe cryptography to mitigate any quantum threats. It is advisable to follow security best practices until NIST quantum-safe standards are available.
Free Downloads
Datasheet of Encryption Consulting Services
Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all
aspects of encryption for our clients.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
