One of the biggest advantages and disadvantages of the cloud is the Shared Responsibility Model for managing cloud security. Put simply, it spells out the security responsibilities of both the cloud provider and the cloud customer – security of the cloud vs. security in the cloud. The upside is that cloud providers ensure that their physical infrastructure – which includes software, hardware, networking, and facilities – is secure, so the customer doesn’t have to. The downside is the customer still has a significant amount of responsibility to ensure their application infrastructure, networks, and data are secured within the cloud.
To aid customers, cloud providers provide a multitude of security tools and controls to help customers improve their security in the cloud. However, most of these controls have major flaw… they are built upon a central implicit model, which is the notion that system operators (Cloud Admin, DB Admin, Sys Admin, etc.) have full privilege to access and manage the information being processed in order to perform their work. This poses a major problem for customers, especially when considering the risk of a supply-chain attack (the cloud provider is compromised), insider threats (authorized, privileged users abuse their access), and if the customer’s environment is compromised and admin credentials are stolen and misused.
Cloud data encryption controls are a classic example. All the major cloud services providers offer native at-rest data encryption solutions to help protect their customers’ data against breach. These services generate the encryption keys, encrypt data, and securely store the keys for the customer.
While native, cloud provider encryption controls may be convenient, they’re all built around the same flawed, central implicit trust model. Once an adversary gets a hold of the appropriate admin credentials, they have unfettered access to your systems and data.
Under this model, the operator of a system or owner of a user account has full access to all data stored on that system or in that account. This is the model used by full-disk encryption (FDE), transparent disk encryption (TDE), and the majority of modern database and data warehouse solutions as well, which use a single key to encrypt all data on the system. Once a user authenticates to the system, the key is unlocked, and all data is accessible to them.
In the cloud, the use of generic encryption controls provided by a cloud or Software as a Service (SaaS) provider restrict access to the company’s data to legitimate users and the cloud or SaaS provider. This model creates several security risks for an organization, including:
Data encryption is an essential component of a cloud security and breach prevention strategy. However, while generic at-rest encryption solutions are better than nothing, they provide little or no protection against the biggest threats to corporate data security.
The generic data encryption solutions offered by cloud services providers do not meet the needs of many organization’s data security policies and regulatory requirements. Achieving the necessary level of protection requires a bring your own encryption (BYOE) approach.
One approach to more effectively protect your data in the cloud, while enabling you full control of your encryption, is application-layer encryption (ALE), in which data is encrypted at the application level before ever leaving the application and ultimately reaching storage.
This also enables each application to encrypt and decrypt its own data with its own keys, an organization can take advantage of multiple benefits compared to centralized at-rest encryption models, including:
In addition to these benefits, application-layer encryption addresses several prominent threats that companies face, including:
Cloud adoption is growing rapidly, and cloud security is a major concern to many organizations. Data stored unprotected or inappropriately protected in cloud environments puts organizations at risk of a data breach.
Data encryption is a powerful tool for data security but only if implemented and used correctly. Bring your own encryption - implemented using application-layer encryption - allows an organization to take control of its own data security in the cloud and eliminate the risks associated with the generic at-rest data encryption solutions offered by cloud providers.
To find out more about how Ubiq can help with your Bring Your Own Encryption needs, visit https://www.ubiqsecurity.com/use-cases/bring-your-own-encryption-keys/
Block cipher modes of operation are designed to allow encryption of data that is too long to fit in a single block of a block cipher. While a variety of block ciphers exist, this article will explore the pros and cons of the ECB and CBC block cipher modes of operation.
Cryptographic algorithms come in a few different forms. The major breakdown is between symmetric and asymmetric cryptography. Symmetric encryption uses the same secret key for both encryption and decryption, while asymmetric cryptography (also known as public key cryptography) uses a pair of related public and private keys.
Within the symmetric encryption category are block and stream ciphers. Block ciphers encrypt data in fixed-size blocks, while stream ciphers generate a stream of bits that are exclusive-ored with the plaintext to produce the ciphertext.
Block ciphers are designed to encrypt a single fixed-size chunk of data, which presents issues for plaintexts that are not exactly the correct length. Padding helps to solve the issue of undersized plaintexts, while block cipher modes of operation handle ones that span multiple blocks.
A block cipher mode of operation defines how the different blocks of a multi-block plaintext should be encrypted and decrypted. By agreeing on a block cipher mode of operation (like ECB or CBC mode), the sender and recipient of a message ensure that they do things the same way and that the data decrypts correctly.
ECB mode is the simplest block cipher mode of operation in existence. Its approach to multi-block plaintexts is to treat each block of the plaintext separately.
The image above shows how ECB mode works. Note that encryption/decryption of one block has no effect on the encryption/decryption of any other. While ECB is the simplest block cipher mode of operation to implement, it also has its issues.
The image above shows the ciphertext resulting from the encryption of Tux, the Linux penguin, using ECB mode. Notice that the penguin is still visible even though the colors are distorted.
The reason that this happens is that, with ECB mode, encrypting identical plaintext blocks produces identical ciphertext blocks. In this case, each pixel is an independent block of plaintext containing the color of that pixel. Since, in this image, many of the pixels have the same color, those identical blocks encrypt to identical ciphertext blocks. As a result, Tux is still visible in the ciphertext.
While this is an extreme example, it demonstrates the limitations of ECB mode for data encryption. While ECB mode is faster, easier, and more parallelizable to implement, it leaks data about the underlying message being encrypted. Simply by observing the ciphertexts (which are public information), an eavesdropper can identify identical blocks and make guesses about the original plaintext.
ECB mode’s issues arise from the fact that each block of the plaintext is encrypted completely independently. CBC mode eliminates this problem by carrying information from the encryption or decryption of one block to the next.
The image above shows how CBC mode works. For the encryption of the initial block, an IV is generated. This IV should be an unpredictable, unique value that is openly transmitted to the recipient. It is not a secret.
This IV is XORed with the plaintext before passing it to the encryption algorithm. The resulting ciphertext is then used to carry information to the encryption of the next block and so on.
This relationship between blocks helps to protect against identical plaintext blocks producing identical ciphertext blocks. Since each block of the plaintext is XORed with a different IV before encryption, it produces a unique ciphertext. This means that an attacker observing the string of ciphertexts can’t learn anything from the fact that two ciphertext blocks are identical.
A major advantage of CBC mode is that, while encryption must be performed sequentially, decryption can be parallelized. The first IV is a public value and all other blocks use a ciphertext as an IV, which are public. This can make decryption faster than other block cipher modes of operation.
ECB and CBC are two of several different block cipher modes of operation. Each of these modes has its own pros and cons and selecting the right one depends on the needs of the project. For example, ECB and CBC mode provide confidentiality, while other modes, such as Galois Counter Mode (GCM), provide both confidentiality and integrity protection.
Between ECB and CBC mode, it is always better to choose CBC mode. As discussed above, ECB mode leaks information about the plaintext because identical plaintext blocks produce identical ciphertext blocks. A ciphertext should never leak any information about the plaintext used to create it, so ECB mode is insecure and should never be used.
CBC mode, on the other hand, is one of the most commonly used block cipher modes of operation due to its ease of implementation and support for parallelized decryption. However, when using CBC mode, it is essential that it be implemented correctly. Improperly implemented padding of ciphertexts can leave the system vulnerable to attacks like POODLE.
While CBC mode is better than ECB, GCM is better than both. In addition to providing strong confidentiality protections without the security issues known to exist in ECB and CBC mode, it also protects the integrity of the encrypted data by generating a message authentication code (MAC) as part of the encryption algorithm.
For this reason, the Ubiq platform uses the GCM block cipher mode of operation. For more information about painlessly integrating strong cryptography into your applications, check out the Ubiq cryptography libraries.
Ransomware is not a new threat or attack but it is becoming increasingly dangerous and rising in frequency, threatening more organizations than ever before. Schools, healthcare facilities, and government agencies have seen the brunt of these attacks. According to Checkpoint, ransomware attacks have risen 93% in just the last 6 months, fueled by new attack techniques.
The pandemic has also fueled a major rise in ransomware attacks, with one cyber-insurance firm, Coalition, reporting a 260% increase in ransomware incidents among its clients in 2020. And they haven’t let up in 2021, with ransomware attacks severely impacting organizations such as Colonial Pipeline, Brenntag, and Apple supplier Quanta. In the case of Colonial Pipeline, the impact was crippling, impacting the oil and gasoline supply of nearly the entire mid-Atlantic region of the United States.
This sharp rise in attacks can be attributed to several new developments that are leading to an increased attack frequency, more successful compromises, and more industries and companies finding themselves at risk.
There are a number of different factors leading to the rise of ransomware attacks:
We’ll break down each factor here.
With traditional ransomware attacks, the data is encrypted, usually on a victim’s device and/or servers that house high value data. This locks the victim out of their own data and can prevent an organization from fulfilling its responsibilities. To decrypt the data, the attacker demands a ransom in exchange for the decryption keys. Once it’s paid, the organization, theoretically, can recover the data and run their business as before.
However, attackers have evolved their ransomware attacks and now exfiltrate the impacted data, which is standard operating procedure for most data theft attacks, but a new trend for ransomware operators. This has led to the rise of double extortion ransomware attacks — because the attackers now have the data, they can also threaten to leak it online or sell it to the highest bidder unless another ransom payment is made. This can be especially troubling for any organization who deals with extremely sensitive information, their customers’ data, or just wants to ensure their IP doesn’t get into the hands of their competitors.
This attack has impacted police departments and third-party suppliers; in Quanta’s instance (Quanta is an Apple supplier), a ransomware hacker group threatened to release files and pictures of upcoming Apple products.
Triple extortion attacks, where another threat layer is added to the traditional encryption and exfiltration/exposure attack, are also on the rise. In this scenario, if a company is still not willing to pay the ransom, the attackers will launch a DDoS (Distributed Denial of Service) attack that will further hinder the organization from carrying out its business responsibilities.
Industries most at risk for ransomware attacks
As mentioned, ransomware attacks are on the rise but certain industries are seeing higher attack volumes as groups refine their targeting. Zscaler found that manufacturing, services, and transportation companies were the top three industries most targeted with double-extortion ransomware attacks.
However, hospitals, healthcare services, and schools are also seeing a significant increase in ransomware attacks, with the latter averaging a $50,000 ransom cost. According to a recent report published by the U.S. Department of Health and Human Services (HHS), there were 48 successful ransomware attacks targeting the Healthcare and Public Health (HPH) sector from Jan 2021 to May 2021, with over 70% resulting in data exposure.
These organizations are being targeted because they can't afford to negotiate with the attackers, develop a decryption method, or respond with third-party help in hopes of recovering their data. In the case of healthcare facilities, it's literally the difference between life or death. For power grid companies, it's the difference between thousands, if not millions of people having electricity. And as we saw unfold with the Colonial Pipeline attack, it meant millions of people losing easy access to gasoline.
Attackers also know that many local government agencies or departments aren’t likely to have the most robust cybersecurity defense, but do have the budget (whether city or state) to pay the ransom.
The same technological advantages that have transformed the business world over the last decade have also benefited attackers and hacker groups in very similar ways. The affordability of cloud infrastructure tools, faster computing power, and better communication (hacker groups were the original remote teams) methods have given hackers better resources and assets to find vulnerabilities, develop exploits, and more successfully target companies.
Ransomware attacks have also evolved from infecting an organization via malware (which is the case with the WannaCry worm) to having parties successfully make their way into a network and deploy the ransomware to increase the odds of success.
This has led to the emergence of the Ransomware as a Service business model. Ransomware hacker groups offer their ransomware services to attackers looking to bring down a specific company. Once the attacker successfully infiltrates an organization, the RaaS team comes in, deploys the payload and handles most communication and processes. The attacker, if successful, receives the ransom and the RaaS group receives a percentage of the ransom for carrying out the attack.
This lucrative model leverages two parties' most successful assets - compromising a company, often via network infiltration, and deploying ransomware. It’s proven successful over the last few years, with more RaaS options popping up and more attackers leveraging this new service, putting many more organizations at risk.
It’s a generally accepted rule and point of guidance among the cybersecurity industry to never pay the ransom if a company is affected by a ransomware attack. NIST’s most updated guidance on preventing and dealing with ransomware attacks does not even mention paying a ransom and the FBI states that they do not support paying a ransom.
The logic is sound — even if the ransom is paid, there’s no guarantee that an organization will recover their files. If the company didn’t do their due diligence or a sufficient enough investigation, they may also not know how an attacker might have infiltrated their network or whether a backdoor was installed. Ultimately, it means that the company may be attacked again and fall prey to another ransomware attack. Research from Cybereason shows that 80% of ransomware victims are repeat victims if they pay the ransom.
Paying ransoms also encourages more ransomware attacks because of their success. The high-profile Colonial Pipeline attack led to a ransom payment of $4.4M and in 2020, companies paid over $350M in ransoms, a 300%+ increase compared to the year before. The previously mentioned HHS department report also noted that the average ransomware payment paid by HPH companies was $131,000.
While it’s highly discouraged to pay ransoms, companies don’t always have the time or resources to combat a ransomware attack or try to recover from one. Third-party investigators and response teams can be costly and can’t guarantee files will be recovered.
It’s clear that ransomware attacks are incredibly attractive from a financial perspective and even if the cost is split among parties, attackers can always increase the ransom, knowing there’s still a high likelihood that it’s paid.
Ultimately, current circumstances benefit hacker groups and attackers in an extremely significant way. This may lead to organizations feeling helpless and powerless against these attacks, crossing their fingers that employees don't click on the wrong link and that they fly under the radar of some of these attackers. However, there are effective methods to fight against ransomware, prevent a compromise, and reduce the amount of harm that ransomware can do.
The good news is that fundamental and foundational cybersecurity can still present a strong defense against ransomware attacks and prevent attempts from compromising your organization.
Organizations should ensure they have a robust network and endpoint security in place and stay on top of CVE (critical vulnerability and exposure) publications. Coupled with ongoing patch management and asset management, this should reduce an organization's risk of having easy attack vectors in the form of out of date or vulnerable software.
Engaging in regular security awareness training can also be a strong cybersecurity investment that will protect against various types of attacks. With the right training, employees will know what to do if they face a social engineering or phishing attack which can either deliver a ransomware payload or be the precursor to a targeted ransomware attack.
Organizations should also invest in tools, processes, and solutions that will reduce the amount of damage a ransomware can inflict on an organization in case they are compromised by a successful attack. Leveraging admin and network permissions, employing a principle of least privilege can help in minimizing the scope of a ransomware attack if it comes via an unsuspecting employee.
Network segregation and segmentation will also limit how much of your organization will be exposed to ransomware and can prevent your most sensitive and necessary data from being inaccessible and potentially leaked. To aid in recovery and response efforts, you should have robust and routinely tested data backup processes, backups of your data, and an incident response plan so you can recover as quickly as possible and aren’t wasting time trying to figure out what you can do if you’re hit with ransomware.
To reduce the risk of a multifaceted attack, it’s important to invest in data and storage (at rest) encryption that aren’t designed around a flawed central implicit trust model, which can be easily disabled by hackers with compromised admin credentials, so that any data that is exfiltrated is encrypted and inaccessible to hackers. This will remove the threat of data exposure or leak because the data is already encrypted on your network (and you hold the keys to decryption).
The best way to invest in this solution is to use an encryption provider (building your own encryption is often difficult, costly, and brings its own vulnerabilities) that enables you to integrate data encryption directly into the application layer, so data is encrypted by the application before it ever hits the network or reaches storage. This ensures that even if network or system admin credentials are compromised, your data remains safely encrypted.
While it may seem like ransomware attacks are inevitable, it’s important that companies adopt the right kind of security hygiene and prepare for the worst-case scenarios. Investing in a well-documented plan, strategies, and new tools designed to fight these evolved attacks, is an important start.
Click here to find out how Ubiq can help to defend your data from ransomware theft.
We love our team at Ubiq - so we wanted to give you a bit more insight about who they are, what makes them tick and of course, what their favorite pizza topping is.
You won't be able to find most of this information on their LinkedIn Profile!
Bonus question: Cat or dog person? Cat.
To find out more about all things Ubiq (including getting access to 1 million FREE API encrypts every month), check out our プラットホーム.
Many organizations have adopted DevOps practices to streamline and optimize their development and release processes. By leveraging automation and agile development methodologies, they eliminate unnecessary manual work and increase the speed and frequency of releases.
One issue with DevOps as initially conceived is that it does not make any changes to security activities, resulting in an outdated approach to security. Often, security is not addressed and security testing was not performed until just before release, which is a major driver of the thousands of new vulnerabilities discovered each year.
To address this issue, many organizations are making a move towards adopting DevSecOps, which weaves security into every stage of the continuous DevOps lifecycle. However, most developers lack a security background, which can make implementing the security aspects of DevSecOps more challenging. When it comes to encryption of data at rest, this is where Ubiq can help.
Ubiq is an encryption platform designed to make it easy for developers to secure their data. Effective encryption is essential for protecting against data breaches and achieving compliance with data protection regulations. With Ubiq, developers can easily meet requirements and more intuitively integrate security and encryption into their development and operations processes.
The diagram above shows the stages of the Continuous DevOps Cycle. For each stage, the callouts outline the required steps to effectively integrate security to form a DevSecOps cycle. The areas where Ubiq can help with improving security and strength of data protection are indicated with bold text across the various stages of the DevSecOps process.
For most systems, all stages of the DevSecOps cycle will be occurring simultaneously, with older, production code in the Ops stages and newer, development code in the Dev stages.
The Plan stage of the DevOps process covers everything before development begins. This includes gathering requirements and designing a system that is capable of meeting them.
In the modern development world, data security and regulatory compliance are major concerns driving security requirements. If software processes sensitive data or data protected under data privacy laws like the General Data Protection Regulation (GDPR) or the Payment Card Industry Data Security Standard (PCI DSS), then that data needs to be appropriately and strongly protected.
With Ubiq’s Platform, developers have easy access to encryption and key management functions that meet the requirements of all data protection laws.
Using the plan from the previous phase, the development team will be writing code to implement features and satisfy requirements. At this point, the developers need access to cryptographic functions that meet the regulatory and security requirements identified in the planning stage.
Ubiq’s API includes support for all major programming languages. By importing the appropriate Ubiq library, developers gain access to easy-to-use encryption functions that can be painlessly integrated into their code.
The code sample above shows a sample encryption function in Python. Once credentials have been loaded from a secure location, encrypting data only requires the developer to make a call to ubiq.encrypt. Behind the scenes, Ubiq configures the encryption algorithm with any necessary parameters and performs the encryption. When access to the data is needed, a call to ubiq.decrypt produces the original plaintext.
After the software has been written, tested, released, and deployed, it enters the Operate stage of the DevSecOps cycle. From a security perspective, this stage covers several aspects. Ubiq can help with two of them:
The Monitor stage of the DevSecOps lifecycle focuses on identifying and responding to events in the system. This includes security events that no company wants to experience (but most of them will). With Ubiq, management of major security events is simplified and streamlined.
Two examples of how Ubiq helps with DevSecOps monitoring include:
Moving from DevOps to DevSecOps will provide a number of advantages to an organization. It can also be a major effort for developers who need solutions that simplify and automate the process of integrating security into development pipelines.
Ubiq’s encryption platform provides a simple and intuitive capability for adding stored data encryption to applications, which is a vital part of data security and regulatory compliance. Try out the Ubiq Platform for yourself to see just how easy it is to implement cryptography correctly and secure any form of application data.
Data encryption is a vital part of data security and many organizations have adopted it. However, data breaches are still a common occurrence. Why is this still happening? Are the methods we’ve relied on still dependable against today’s modern adversaries?
The two most commonly used types of data encryption are at-rest encryption and in-transit encryption. At-rest encryption (such as full disk encryption) encrypts data while it is being stored and is not in use, making it possible to protect stored data against physical threats, but provide full access to data to applications or users as needed. In-transit encryption (like that used in HTTPS) creates an encrypted channel between a network or two computers for them to communicate over; however, it only protects data in transit, not data on the computers or networks themselves.
While these encryption methods are effective at protecting against physical threats (e.g., someone stealing your laptop) and eavesdropping, they do not protect against compromised accounts or privilege misuse. In many cases, malicious attackers simply gain system access and turn them off. What encryption method should we adopt instead?
Like at-rest encryption, application-layer encryption is designed to protect data at rest. However, unlike at-rest encryption, it encrypts data based upon the application that owns it rather than for the storage medium or disk where the data is stored.
With application-layer encryption, data encryption and decryption is performed at the end application. When data is stored or transferred over the network, it remains encrypted until it reaches the destination application that holds the encryption keys. Since keys are only issued to applications on a need-to-know basis, someone with legitimate access to a particular user account does not have full access to all the data stored in that account, only the data relevant to that particular application.
At-rest encryption and in-transit encryption are effective at the very basic task of encryption, but they leave gaps in an organization’s data protection. More specifically, at-rest encryption is in many situations ineffective against modern, network-based attacks. Application-layer encryption enables more comprehensive and robust data protection and can defend a wide range of threats to data security. These include the following:
With at-rest encryption, any account with permissions to access the storage medium will have the data automatically decrypted for them. This creates numerous opportunities for misuse of the permissions associated with an account. Additionally, if an account is compromised by an attacker, that attacker gains access to all data accessible to the account.
With application-layer encryption, having access to the underlying operating system or storage does not provide a malicious actor the ability to decrypt and access the data. Data can only be accessed through the appropriate application, making it possible to enforce appropriate access controls and monitor data use.
High-level encryption solutions, like disk-level encryption, treat all data the same. Sensitive customer information is protected at the same level as a shopping list on a computer. This can mean that most data is over-protected and some may be under-protected.
With application-layer encryption, the application that owns the data is the one that encrypts it. This allows it to tune the protections to the sensitivity of the data or even to specific users and groups. This reduces wasted resources while ensuring that sensitive data is properly protected.
Data protection regulations are becoming more numerous and stringent. A common requirement of these laws is that an organization be able to prove that they restrict access to the data protected under the regulation.
With at-rest level encryption solutions, it can be difficult to determine and prove if a compromised account was used to gain access to data that it has access to.
With application-layer encryption, the granularity of encryption is at the application level. This makes it easy to maintain and demonstrate regulatory compliance because it reduces the ways in which an attacker could gain access to the protected information.
With most at-rest encryption solutions, encryption key management is performed by the encryption software. Often, this means that the encryption key is stored encrypted on the drive while protected by a key derived from the user’s password. While in use, the decryption key is stored in memory, where it may be inappropriately accessed.
With application-layer encryption, the application has control over its own key management. This enables it to use solutions that appropriately protect decryption keys and are compliant with applicable regulations.
Historically, many organizations have used a very permissive and perimeter-based security model. Anyone with legitimate access to a network or system is considered “trusted”, and the security is designed and deployed to protect against external threats.
This security model has its limitations, and the zero-trust security model was designed to address these. Under this model, access to resources is granted on a case-by-case basis determined by access controls. This provides a much higher level of protection, control, and granularity of access controls, which helps to reduce the vulnerability and impact of data breaches. For example, the Capital One breach could not have occurred under a zero-trust security strategy.
Application-layer encryption is necessary for implementing zero-trust security. Alternative encryption methods control access at the storage or disk level, rather than to an individual applications’ data, which makes it difficult to enforce the access controls required in a zero-trust security model.
Application-layer encryption has a number of benefits for the security and performance of an application, and it is not difficult to implement. Ubiq offers libraries for many different programming languages that help developers to integrate encryption into their code and securely and easily provision and manage their encryption keys.
We are often asked about how the Ubiq Platform compares to Key Management System (KMS) or Hardware Security Module (HSM) solutions. In short, an HSM solves a very specific problem, secure key storage, and you can build a KMS using an HSM as a base to provide centralized key storage with policy enforcement. KMS and HSM solutions typically designed for encryption and/or managed by security experts and power users.
Alternatively, the Ubiq platform is a developer-friendly, API-first platform designed to reduce the complexity of encryption and key management to a few lines of code in whatever language you're already using. It requires no security, cryptography, or encryption expertise whatsoever. The platform is built on a KMS and HSM and provides the benefits of KMS and HSM, plus centralized policy management, metrics, and easy-to-use APIs without the boilerplate associated with an HSM or KMS.
Now let’s dive a little deeper into each one so you can see how each works.
A hardware security module is device designed to solve a very specific problem: how can you protect your cryptographic keys from being stolen, even if an attacker gets highly privileged (or even physical) access to your server? The answer is to build an entirely separate computer attached to your main one that can only be used to store and operate on cryptographic keys. That device is designed to be as hardened against attack as possible – it runs a minimal embedded operating system and (hopefully) is heavily tested for correctness bugs that might allow a compromised PC to attack the HSM. It presents a simple interface to the computer that allows for key generation, and import, and allows the PC to request that it sign, encrypt, or decrypt some data. More importantly than the features it offers is a feature it doesn't offer: cleartext key export.
The HSM will allow you to export keys for archival or storage (in fact you probably will have to, since they typically don't have much in the way of nonvolatile storage), but the exported package will itself be encrypted with a key only known to the HSM. The encrypted key blob can be loaded back into the HSM, but is useless without it, so an attacker that gets access to it doesn't get anything useful. Thus, even an attacker that obtains complete control of your PC or server cannot export your keys --- they can still use the keys if they maintain persistent access, but they can't export them, greatly increasing their chance of detection.
So where do you typically find HSMs? They're typically at the root of cryptographic trust chains, holding certificate authority private keys or acting as the main cryptographic key stores for Key Management Systems, which we'll discuss next.
HSM’s seem pretty cool, but they aren't a universal solution to the complex problem of encryption and key management. First of all, you probably have more than one server, and HSMs are expensive, and somewhat complicated to manage at scale. Second, they don't cover all your bases when it comes to enterprise data security or application layer encryption; you still need to handle key rotation, access controls, and other policy-related problems like what encryption parameters to use. The solution to those problems is to wrap your HSM in a Key Management System (KMS), which can be thought of as providing an HSM-as-a-Service.
A KMS will allow you to centrally store your key material, and then set access controls (principal x can encrypt data with this key but not decrypt; principal y can decrypt using these keys but not those ones) - this is important as a defense-in-depth measure, since it means that you can prevent an attacker that compromises a single server from asking the KMS to decrypt all of your data. You can also set policies like which ciphers can be used and combine these primitives into a complex set of policies like handling key rotation and archival or collect metrics about which keys are being used for what operations. However, a KMS is not the whole story for enterprise data encryption or application-layer encryption.
This brings us to the Ubiq Platform. You might be thinking to yourself "Gee, this KMS thing sounds pretty good, maybe I need one of those," and you might even be right. But handling enterprise data security properly isn't as simple as just using an off-the-shelf KMS to interface your servers with your HSM. Using a basic KMS product to implement, enforce, and monitor enterprise-scale encryption is difficult and fraught with subtle mistakes. Actually encoding your enterprise access and key lifecycle policies into KMS access controls is hard and typically involves a lot of boilerplate code to handle key archival and rotation. The same can be said for actually using the KMS to encrypt large amounts of data: a KMS can typically only encrypt small payloads, so you have to handle the “last mile” of encrypting bigger payloads yourself… which is what most application developers need the most help with in the first place!
This is where the Ubiq Platform can help. Ubiq’s end-to-end application-layer data encryption solution abstracts the complexities of policy, encryption, and access controls behind a dead-simple API that also makes it as easy as possible for developers to actually get stuff done. You get automatic key rotation, enterprise-wide encryption policy enforcement, and simple access controls all under a single service that also provides easily understood metrics and a transparent billing process. All it takes is a few clicks and you'll be encrypting data in minutes, backed by the same strong key protection described above, without having to deal with the headaches of actually implementing a full enterprise data encryption solution.
Ubiq never sees your actual data, so it remains private and secure both against attackers and against the platform itself. And Ubiq's client libraries, including the data storage format, are open source, so you don't have to worry about being locked into a proprietary system. Your data remains yours, period.
Quick case in point: A SaaS-based logistics platform company was in the process of implementing encryption to secure structured and unstructured data stored in both Microsoft Azure and AWS clouds across a multitude of different storage types – S3, Blob Storage, SQL databases, Apache Hadoop, to name a few. Before encountering Ubiq, the company spent well over 500 hours of R&D and at least $500,000 on 5 disparate encryption tools and solutions to solve their data security and protection problem. With Ubiq, the customer was able to integrate native encryption controls directly into the application in a matter of 3.5 weeks, providing them a single, consistent solution for encryption and key management across their multi-cloud infrastructure and diverse storage and data types.
|HSM||Secure key storage + operations||Unsuitable. Keys are by design stored only in a single location, which makes application layer encryption impossible without huge effort.|
|KMS||Centralized key management||Suitable with effort. App-layer encryption requires building a large amount of boilerplate client-side code, managing encryption policy manually, and dealing with vendor-specific data formats and complex access controls.|
|Ubiq Platform||End-to-end app layer encryption||Turnkey suitable. Ubiq handles app-layer encryption end-to-end, from access controls to data storage to client libraries and encryption policy.|
|Hardware-backed secure key storage||✓||✓||✓|
|Network encryption key management and provisioning||✓||✓|
|Automatic and one click on-demand key rotation||✓||✓|
|Automatic key archival and retrieval||✓||✓|
|Simple encryption policy management and enforcement||✓|
|Dead-simple client libraries||✓|
|Usable with no prior encryption skills||✓|
|Simple, affordable, scalable billing||✓|
|Turn-key ready for application layer encryption||✓|
I’m not going to sugarcoat it; the security industry has fallen way behind the broader tech industry in the last decade in a really fundamental way. While much of the tech industry has started to pivot away from hardware and software-based solutions – which dominated the 90s and early 2000s – and towards the use of API-first SaaS services, most of the security industry has not.
Now, this reluctance to embrace a new way of delivering security outcomes means that customers are overburdened with acquiring, deploying, and managing security tools in a legacy model. A painful, not to mention expensive, way to defend against threats.
It’s time for the security industry to wake up and deliver security via APIs.
Around a decade ago, we saw the emergence of the “API economy” giving birth to (what are now) massively valuable tech companies. Stripe simplified the complex and painful world of payment processing. Twilio did the same for messaging and communications. Both simplified what would’ve taken customers and developers literally months of effort, cost, and tons of trial and error to build, down to a set of API calls and a few hours of integration work.
Yet, despite the emergence of so many API-first tech companies, the security space has yet to get into the game in a material way, with a few minor exceptions – kudos to Auth0 for being one of the first to do so. The (security) industry as a whole seems to be sticking with the hardware/software model and, to a certain extent, it’s working.
Customers are generating and storing more and more sensitive data and cyberattacks are on the rise, so they’re left with no other option but to continue to buy security software, which means stock prices continue to rise and shareholders are smiling. Meanwhile, (most) security vendors are heads down, working hard to adapt to evolving threats and haven’t lifted their heads to consider the larger shift in how customers want to consume technology.
If security vendors shifted from delivering outcomes via appliances and/or software, to delivering those same security outcomes via APIs, I believe we’d have happier customers and less effective adversaries.
Laggards being the exception, most customers don’t want to buy traditional security “tools” anymore. With network perimeters mostly eliminated and data residing in a multitude of systems and locations, the focus should be on providing customers with security outcomes in the most efficient and flexible way. And I believe that is security via API. By allowing customers to enable higher-quality, more secure experiences and controls faster, we eliminate all the pain, effort, and expense of acquiring, installing, and managing archaic hardware-based solutions. It would also potentially help close the cybersecurity skills gap (which I’ve addressed in this separate post).
Under the current software/hardware model, security experts are spread too thin trying to manage security software across the entire organization while detecting and responding to threats. But by delivering security via APIs, developers can quickly and easily build security functions directly into applications, freeing up the security team’s time to focus on higher-level strategy. By shifting security left and building it directly into the applications, it would also make applications inherently more secure.
Though we haven’t seen a massive shift in the security industry towards delivering via APIs, there are a few companies who embraced the model early on. Auth0 (which was acquired by Okta for $6.5B), is probably the best, most recent example of a truly API-first security vendor. However, there are definitely a number of big players like Cisco, FireEye, and CrowdStrike who have started to dip their toes into the API waters.
Auth0 is a fantastic example of a security company that delivered an Identity and Access Management outcome to its customers via API from day one. They recognized very early on that identity verification was an incredibly arduous and painful process, and something to get right.
“Since our inception, we’ve always believed in a single platform to solve all Identity and Access Management (IAM) requirements. We take a very different approach compared to what traditionally has been done in this industry. Developers, the "makers" of this new world, appreciate building blocks that are simple to integrate but that can adapt to different situations,” said Matias Woloski, CTO and Co-founder – Auth0.
Globally, Auth0 now authenticates and secures more than 2.5 billion logins per month for its 7,000 customers. How’s that for proof in the pudding?
Making the shift from the software/hardware model to security via API would no doubt bring a whole slew of new challenges. But it would help security practitioners (and developers) integrate critical security capabilities and controls into their applications and infrastructure more quickly and broadly, while enabling the security industry to catch up to the broader tech community.
I’d love to hear your thoughts on the security industry embracing the use of APIs. Do you think this shift will happen in the near future? Have you seen other API-first companies emerging to drive this change? Let's chat.
For the last 5-10 years, we’ve all heard a lot of talk about the global shortage of cybersecurity talent. It’s an issue that’s plagued the industry for years, and according to (ISC)², a nonprofit for information security leaders, the security industry would need more than 3 million skilled professionals to close the skills gap. That’s a whole lotta people.
The shortage is due to a variety of factors, ranging from a lack of advanced skills to a limited number of professionals entering the field in the first place. And the expanding threat landscape only exacerbates the problem. Qualified security professionals are spread too thin, and turnover is high at companies across the board from tech start-ups to corporations to government agencies. Also, most security teams spend more time managing security tools than actually hunting and eradicating adversaries, which is caused by the archaic way security vendors continue to deliver security outcomes (via hardware and software), which I’ve covered in this post: [insert title and link]
Before we address the question, it’s important to walk through why variations of (really) the same two training-oriented solutions the industry continues to push, aren’t working.
These low-and-slow solutions have major flaws – they take too long and we’re simply “training” more people to become defenders. I think there is a far more efficient and effective way to slow down the attackers and reduce the need for millions of new cybersecurity resources.
A few obvious points I’d like to make. Today, most security vendors sell hardware and software-based solutions, which are then operated by a company’s security or network team team or a third-party managed service. At the end of the day, these solutions are used to detect, prevent, (or whatever other buzzword is trending) hackers from doing nefarious things. “Nefarious things,” in most cases, involves exploiting software vulnerabilities.
Call me crazy, but if most adversaries are exploiting software vulnerabilities, wouldn’t it make sense for us (the security industry) to focus more of our time and attention on improving and enabling the security of the applications?
And wait…while there are only (roughly) 3.5 million cybersecurity professionals worldwide, there are exponentially more software developers – approximately 86 million on just Github and Gitlab alone, as of the writing of this article. I think it’s safe to assume software developers also have a vested interest in protecting the software they’ve built.
So rather than trying to recruit and train millions of new cybersecurity experts, what if we also enable the existing population of software developers to build security controls directly into their products via APIs, without having to become security experts?
For the most part, the tech world has embraced the use of APIs. Look no farther than Stripe and Twilio for shining examples of that. But the security industry is lagging way, way behind. If security vendors start building API-based security tools for developers rather than purely for security professionals, it would eliminate some of the responsibilities from overworked security teams and shifts security left to the massive population of developers who are already familiar with APIs. This would free up security teams to work on higher-level strategy and (bonus) it would result in more secure applications.
I’m by no means suggesting that we shouldn’t develop more security talent – we should. I’m simply suggesting that the security industry deliver solutions that can be integrated directly into applications, enabling customers – and tens of millions of developers around the world – to integrate security directly into their products.
Yes, this would require a massive mindset shift and more API-first security solutions, but I believe it will curb the impossible-to-fulfill demand for security professionals, by enabling a far larger population of software developers to join the fight against evil and build more secure applications.