Veerbhadra Magdum, CCSP, shares his recent experience of dealing with encryption updates, what might have gone wrong and what he and his team learned, so others can avoid similar challenges.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
Considerable time and effort are spent on complying with information security policies set forward by enterprise security teams. One of the key policies, consistently monitored in recent times, is around data at rest (DAR) and data in transit (DIT). Typically, policies require the underlying data, or the passwords used, to be “threat-proof” by applying the recommended encryption methods or cipher suites.
I was recently involved in the review of a scan report of servers hosting an application, which required cipher suites to be upgraded with the latest, more secure suites. We quickly realized how risky the process of managing the cipher suites could be without complete knowledge of the applications using those cipher suites.
Doing Application Security Correctly
Policy makers insist, rightly, that their passwords are secure. Ideally, this should mean that the following critical components are included in the scanning process of any application:
- Plaintext: This is the input text for a cipher suite, which is thereby converted into a secure cipher text. (In the context of the scenario I’m going to describe, this means our application service account passwords.)
- Cipher Suite: This is the algorithm or a set of rules for performing encryption or decryption of the plaintext passed as input.
- Key: This is an additional randomized element that a cipher suite employs, in combination with the plaintext, while performing encryption or decryption.
- Ciphertext: This is the text that has been encrypted with the use of a cipher suite and a key. It requires decryption to transform it back to its original plaintext form.
- Encryption: This is the process of transforming the input plaintext to the ciphertext with the use of a cipher and a key.
- Decryption: This is the reverse process: the transforming of ciphertext back into plaintext with the use of a cipher suite and a key.
In this scenario, the application under review was three-tiered. It comprised application, web and database components, serving the application business logic, application UI and the store of structured or unstructured data, respectively. Every tier of the application had an entry point through either the operating system service account or a database account – which opened doors within to multiple internal accounts. These service accounts or database accounts are considered critical, since any breach of these can lead easily to a DAR/DIT breach, in turn rendering the entire IT infrastructure vulnerable to a more severe form of malware.
What we discovered when reviewing the reports, however, was that the scan was not configured to investigate most of these critical elements. Instead, policy and focus seemed to center only on the password component. As a result, these other components were not fully scanned or investigated, leaving a large proportion of the application effectively unreviewed:
Resolving the Issues
The initial scan report did, at least, reveal that we needed to update our cipher suites to the latest available versions. The application team was tasked with doing this – but, on investigating more deeply, we made the following discoveries about those other, unreviewed components:
- Cipher suites were listed in multiple places in the configuration files for the operating system of multiple server layers. Consequently, there was no single place or easy way to update them. This complexity required considerable efforts to fully test our resolution.
- The keys used to generate encrypted strings for the input passwords were hardcoded as clear texts in multiple places, also in the configuration files for the operating system of multiple server layers. Such poor key management could all-too-easily result in an application data breach, requiring us to resolve this too.
- The encryption/decryption programs, along with the configuration files for keys and cipher suites, all had application account permissions, instead of being restricted to execute privileges only.
- Some instances of cleartext passwords were hardcoded and didn’t use the intended encryption/decryption methods.
- The application supported symmetric encryption, which – due to the other shortcomings – could have enabled intruders to construct passwords.
Since these important observations were made outside of the initial scanning process, our first action was to suggest important improvements that needed to be made to the scanning tools. We advised that the tools should include a key management review, encryption/decryption program reviews and a privileges review of critical components. These improvements would help to secure many other applications in subsequent exercises.
There are multiple critical components to the entire process of controlling applications entry point and access of accounts, many of them crucial for secure DAR/DIT channels of communication. With the advent of advanced computing methods these critical components become more vulnerable and application security will largely depend on how all these components are securely stored, protected and managed. So, our second action was to draw up some ‘best practices’ to follow, so we wouldn’t find ourselves in a similar situation again.
Here are the points we developed:
- Scanning tools must now be configured to provide the most granular information about the vulnerabilities to help application teams in isolating the attack surface. For example, we need to know the path of operating system files or database tables where vulnerable configuration of keys, cipher suites or encryption programs exist.
- Our application teams now maintain inventory of critical components like cipher suites used, keys used and methods used to secure keys as well as passwords.
- We use a common and secure store for all these critical components, instead of repeating configuration in multiple places and tiers of applications that require usage of these components.
- We encrypt all files or tables where these critical components are configured as an additional layer of security.
- We apply very restrictive privileges to these critical components. They are managed by the super users and are inaccessible without full permissions to the application accounts, or to non-privileged accounts.
- Where possible or supported, we rely on public/private key or asymmetric methods instead of symmetric methods.
- We use the latest/strongest encryption methods that the application will support.
- We use wallets or vaults for storing these critical components if the application supports an API interface for these wallets or vaults. This approach supports automating periodic rotation of these critical components in a secure way and reduces vulnerability to attack.
Further Tightening Our Processes
Applying the lessons, we suggested to the information security team that it tighten the process for multiple other applications. Here are the process improvements we recommended, which the information security team should strive for in coordination with application teams:
- Employ a template so that multiple applications identify and implement such critical components in a homogeneous way.
- Hold peer reviews at every major milestone of the application lifecycle, so that awareness and compliance become the focus of the application teams.
- Publish periodic scans of each application’s critical components with granular details, to get feedback from the application teams for any improvements in the scanning process.
- Train application teams on the scanning processes and understand the parameters of application security posture. This softens the resistance of developers by helping them to understand that security and risk are equally challenging rather than a burden and can provide valuable learning experiences.
The entire exercise helped us build a more robust vulnerability management process and helped us realize that deeper insights by application SME's and an increased collaboration with policy makers is an efficient way of threat proofing DAR/DIT controls. This experience helped us in identifying implicit and explicit components that require controls to protect the attack surface, and we hope that others will benefit from our experience.
Veerbhadra Magdum, CCSP, is a System Manager with over 20 years of experience building applications and managing the cybersecurity posture of applications across variety of enterprise infrastructure architectures. His work focuses on application risk management, application monitoring and application security management.
