Archive
Windows: TLS-1.3 and PQC-Readiness
The quantum computing threat landscape has intensified the urgency for robust cryptographic solutions, especially in modern TLS 1.3 implementations. As of November 2025, Windows client and server operating systems do not natively support post-quantum cryptography algorithms within TLS 1.3 handshakes. Current Windows crypto stacks continue to rely on classical elliptic curve algorithms such as NIST P-curves for key exchange operations. This design choice, while compliant with existing security standards like FIPS 140-2, creates a critical vulnerability as quantum computing capabilities advance.
The Current State of Windows TLS 1.3 and Post-Quantum Cryptography
Windows has not yet integrated native post-quantum cryptography algorithms into its TLS 1.3 stack. Instead, the operating system continues to use classical elliptic curve algorithms such as NIST P-curves for key exchange operations. This approach aligns with current compliance frameworks but leaves systems exposed to future quantum attacks. Hybrid configurations using post-quantum primitives like ML-KEM are available only through application-level libraries and manual configuration.
Microsoft and NIST: Aligning on a Path Forward
CISA recommends transitioning away from pure elliptic curve key exchanges in TLS 1.3 within 5 to 7 years, targeting the mid-2030s for full adoption of hybrid key exchanges. Microsoft has publicly committed to following these timelines for Windows Server updates, though specific rollout dates remain undisclosed beyond general feature update cycles. The alignment between Microsoft and NIST standards provides a clear roadmap for future Windows versions, but current implementations do not enforce PQC algorithms at the system level. This creates a gap between regulatory guidance and immediate operational readiness for enterprise environments.
Regulatory Landscapes and Standardization Efforts
NIST finalized its post-quantum cryptography standards in early 2024, including the FIPS 203-4 suite for algorithm validation. Microsoft Azure services can be configured to use these standards, but Windows core components have not yet adopted them as default settings. The IETF is actively working on a draft standard for hybrid TLS 1.3 key exchanges, with Microsoft aligning its internal testing to ensure future compatibility. However, no public commitment exists for Windows to integrate these standards until the IETF standard is ratified.
Real-World Testing and Validation Challenges
Independent labs such as SANS and NIST have demonstrated that hybrid TLS 1.3 configurations resist known post-quantum attacks. Microsoft has not released independent validation reports for Windows client and server OS PQC capabilities as of November 2025. This absence of internal validation data forces enterprise security teams to adopt a hybrid-first approach for critical workloads. The lack of Microsoft-provided testing reports creates uncertainty for organizations planning their PQC migration strategies.
Strategic Recommendations for Immediate Action
High-security workloads should leverage Azure-managed TLS endpoints that already support hybrid key exchange libraries for immediate compliance. Developers building .NET applications on Windows must manually integrate PQC packages and configure hybrid handshakes in their codebases. Specific Windows version numbers that will receive PQC support remain undocumented, so organizations must rely on CISA guidance and industry-standard libraries. No public beta testing program for Windows OS PQC integration exists beyond Azure infrastructure experiments, making the transition process complex.
In conclusion, Windows currently lacks native post-quantum cryptography support in TLS 1.3, creating a temporary security gap that requires strategic workarounds. Organizations should prioritize Azure-managed solutions and manual PQC integration in applications to mitigate quantum threats. Microsoft’s alignment with NIST standards provides a clear path forward, but the absence of official timelines and validation reports necessitates proactive planning. The transition to quantum-resistant cryptography is an ongoing process, and staying informed about regulatory updates will be critical for long-term security.
Mobile security and Android
Android Security: The Hidden Perils of Unofficial TV Boxes and Beyond
Mobile security for Android devices is a complex and ever-evolving field, especially when dealing with unofficial applications and devices. Many users are unaware that the widespread adoption of cheap, unverified TV boxes running open-source Android versions creates significant vulnerabilities that attackers can exploit. These devices, often purchased from e-commerce sites that promise unlimited streaming app access, become prime targets for malware campaigns that compromise user privacy and security. The consequences of such compromises extend beyond the individual device, potentially affecting entire home networks and local internet connections. Understanding these risks is crucial for anyone using Android-based systems in their daily lives. Additionally, the lack of robust security updates in these unofficial devices compared to certified Google Play editions amplifies the danger, leaving users exposed to a range of threats that could lead to data theft and financial loss.
Botnets and Unofficial Devices: The Popa Threat
Researchers have identified a massive botnet known as Popa that forces millions of unofficial consumer TV boxes to relay internet traffic for advertising fraud and data scraping. This botnet frequently emerges from malware campaigns such as Vo1d, which target devices bought from e-commerce sites that promise unlimited streaming app access. These unverified apps are the common entry point for compromise, leading to devices being hijacked for malicious activities without the user’s knowledge. The Popa botnet operates by turning these TV boxes into residential proxies, allowing attackers to use the home internet connection and local network for malicious purposes. This practice not only facilitates data scraping but also enables large-scale fraud operations that impact millions of users globally.
Hardware and Software Vulnerabilities: Beyond the Surface
Hardware-level exploits present a unique challenge for Android security, as vulnerabilities in the firmware boot chain can lead to arbitrary code execution. While the specific news covered an exploit for Apple A12/A13 chips, similar risks exist in Android devices where securing the low-level system components is critical. Additionally, OAuth breaches, as seen with the Icarus hackers targeting Klue users, can result in sensitive data such as location history or contact lists being exfiltrated if token validation is poorly implemented. These vulnerabilities highlight the importance of robust authentication mechanisms and the need for continuous monitoring of security practices. Furthermore, bugs in plugins handling APIs can lead to unauthenticated access and exposure of secrets, which can have severe implications for user privacy and data integrity.
Emerging Threats: AI, Ransomware, and Human Error
The use of AI by attackers to discover and exploit vulnerabilities in computer code has become an emerging trend, which significantly increases the rate at which zero-days are found against popular frameworks. Ransomware campaigns have shifted from being primarily Windows-centric to targeting mobile platforms, often by encrypting recent files on cloud-connected devices. Furthermore, user behavior remains a primary attack vector, with social engineering tactics such as malicious SMS links and fake app download pages frequently leading to initial compromises. Tools to “stay safe online” emphasize that human error is often the initial step before technical exploits are deployed against an Android device. Addressing these threats requires a combination of technical safeguards and user education to reduce the likelihood of successful attacks.
Data Breaches and Supply Chain Risks: The Critical Landscape
The “Have I Been Pwned” database reveals how frequently user credentials are exposed across thousands of websites, meaning a single compromised service can be leveraged to phish for mobile app tokens or session cookies via SIM swap attacks. Supply chain risks also pose a serious threat, as malicious updates or backdoors in applications distributed through third-party channels can lead to widespread breaches. Government agencies like CISA emphasize the importance of adhering to best practices, particularly for enterprises managing Android devices via Mobile Device Management solutions. These incidents underscore the need for comprehensive security strategies that cover both the technical infrastructure and the human element. Additionally, the risk of unauthorized device enrollment in botnets is a major concern for organizations that rely on mobile devices for critical operations.
In summary, the security landscape for Android devices is increasingly complex and demands a multi-layered approach. From the risks of unofficial TV boxes and residential proxies to the threats of hardware vulnerabilities and AI-assisted attacks, every aspect of the mobile ecosystem requires careful attention. Users and organizations must prioritize vigilance, regular updates, and robust security practices to mitigate the growing number of threats.
AI Code Tech Debt
The Double-Edged Sword of AI in Code Development
In the modern software development landscape, Artificial Intelligence has emerged not just as a tool for automation but as a catalyst that dramatically accelerates code generation. Tools powered by Large Language Models can now produce complex functions in seconds, seemingly solving years of work almost instantaneously. However this rapid surge in productivity brings with it an unexpected and potentially costly companion: Technical Debt specifically engineered to be far more insidious than traditional shortcuts taken by human developers.
The Mechanism Behind AI-Generated Code Debt
To understand this phenomenon, one must look at how these models actually function. Unlike human programmers who can trace their logic back through a mental sandbox or verify every condition manually LLMs are probabilistic engines predicting the next token based on patterns seen in vast datasets of existing code. This means that while AI is incredibly efficient at producing syntactically correct and contextually relevant solutions to new problems essentially writing perfect-looking spaghetti it often lacks true logical depth regarding security best practices or long-term maintainability.
The critical issue lies in the model inability to see outside its training data meaning it cannot inherently understand if a specific piece of generated code violates industry standards for secure coding. Consequently developers are often presented with solutions that work immediately but may introduce hidden vulnerabilities or inefficiencies.
The Critical Summary
AI Code Tech Debt is a critical new frontier for software architects and security professionals. It represents the accumulation of code that appears efficient but relies on patterns found in vast datasets rather than deep logical reasoning introducing latent vulnerabilities and making refactoring exponentially harder over time.
The core takeaway is clear while AI can significantly boost productivity it demands a heightened level of skepticism from developers. Organizations must implement rigorous code review processes that specifically audit for the probabilistic errors introduced by LLMs and prioritize security-by-design principles to prevent this rapidly accumulating debt.
The Path Forward
To mitigate these risks the industry is looking toward better integration of static analysis tools trained specifically on security vulnerabilities within AI workflows. The solution isn’t to reject AI technology but rather to evolve our development practices treating AI suggestions as drafts that require human validation and strict adherence to secure coding standards before deployment.
AI Security
The Double-Edged Sword of Artificial Intelligence
The future landscape of cybersecurity has been dramatically reshaped by the sudden and widespread rise of artificial intelligence, creating an entirely new frontier where our most sophisticated tools could potentially be used for both defense and offense.
AI Security is no longer just a niche sub-field emerging from the shadows; it stands now as a critical necessity that permeates every single layer of modern technology stacks. From the foundational processes we use to train massive models to protect them against adversarial manipulation, the integration has become inevitable across digital infrastructure management workflows.
An Ecosystemic Vulnerability
The core challenge within this evolving landscape lies in understanding that AI Security functions not as a single point failure but rather represents an ecosystemic vulnerability exposed across multiple vectors. Attackers actively exploit the inherent probabilistic nature of machine learning models to:
- Generate harmful outputs or compromise underlying data integrity through adversarial input manipulation.
- Execute model inversion techniques designed to leak sensitive information stored within neural network weights.
- Bypass safety filters through creative prompt engineering and jailbreaking attempts.
This reality forces developers to implement robust guardrails without sacrificing the flexibility that makes Large Language Models so powerful for legitimate enterprise applications in industries ranging from healthcare diagnostics to financial trading algorithms running at millisecond speeds.
Building Resilient Countermeasures
In response, key research initiatives and standardized frameworks have emerged. Security teams are moving toward comprehensive taxonomies like MITRE ATLAS which catalog known attack techniques specifically targeting AI systems. This enables defenders to build countermeasures based on a verified list of threats rather than guessing work in an ever-evolving arms race between automated attackers and protection algorithms augmented by generative adversarial networks capable of detecting previously unseen patterns.
To secure the digital economy moving forward, we must invest specifically in specialized talent proficient both in machine learning theory and traditional cybersecurity principles. Success hinges upon establishing resilient architectures that combine rigorous red teaming exercises designed to probe model robustness against boundary conditions while leveraging federated learning approaches where sensitive data never leaves local devices yet still contributes to global model improvements without compromising privacy rights.
Get ready to Celebrate Star Trek day!
Star Trek Day marks the first airing of Star Trek: The Original Series on NBC on September 8, 1966.
I was in my “Terrible Twos” back then and wasn’t yet memorized by the notion of space travel. Slowly, as other events of the 60’s unfolded, I began to realize that my life would embrace all things science and if I was lucky, I might experience space one day if I worked really hard.
Well, here we are celebrating another Sept 8 (59th anniversary) and I am happy to report that I have worked with computers for over half my life, due in large part to shows like Star Trek.
Join me, as we enter the world of Artificial Intelligence, and welcome the news that Paramount (CBS studios) will be adding several new Star Trek shows and movies centered around this cultural phenomenon.
Take that Star Wars, let’s see Disney try and top that 😁
Trusted Platform Modules
If you are like me and use windows (among other operating systems), you might have wondered why M$ has required you to obtain new hardware just to run Windows 11. Is this just a cash grab by a greedy vendor or is there method to the madness after all?
The truth is, the industry has learned the costs of poor security, after decades of breaches and a patch routine that seems to never end. Created to help solve the problems associated with 2 factor authentication and now expanded to replace passwords altogether (using Passkeys), WebAuthN is an API specification designed to use public key cryptography to authenticate Entities (users) to relying parties (Web Servers).
Shown below (from the Yubikey site) demonstrating external authenticators (like Smart cards or hardware) or by utilizing Trusted Platform Modules in our devices, people can authenticate with (or without) the standard username and password we have been using for decades.
The idea of using a password has been like ‘leaving your front door key under the mat’. Anyone observing your behavior or just walking up and checking ‘under the mat’, can use it for themselves. Password abuse has become a leading cause of fraud to so many users that we started to send 6-8 digit codes via mobile telephone, so that users can authenticate using a second factor (2FA). Not everyone carries a mobile phone and we have learned that receiving these codes is not very secure because they are prone to interception.
We have relied on digital communications for e-commerce sites using cryptography (TLS) with such great success. Contributors like Google, Microsoft and many others decided that it was time to apply these principles to authentication and a specification was born.
The WebAuthN API allows servers to register and authenticate users using public key cryptography instead of a password. It allows web servers to integrate with the strong authenticators (using external ones like Smart cards or YubiKeys) and devices with TPMs (like Windows Hello or Apple’s Touch ID) to hold on to private key material and prevent it from being stolen by hackers.
Instead of a password, a private-public keypair (known as a credential) is created for a website. The private key is stored securely on the user’s device; a public key and randomly generated credential ID is sent to the server for storage. The server can then use that public key to prove the user’s identity. The fact that the server no longer receives your secret (like your password) has far-reaching implications for the security of users and organizations. Databases are no longer as attractive to hackers, because the public keys aren’t useful to them.
A virtual TPM is a software-based implementation of the same hardware-based TPM found in devices today. These vTPMs can be configured to simulate hardware-based TPMs for many operating systems. The Trusted Platform Group has created a standard but it is woefully outdated. Happily, many vendors have implemented the ability to use a vTPM in the last few years that allow us to implement external KMS systems to help protect them.
The cloud providers now support virtual TPMs for use with Secure Computing and Hypervisor support using your existing KMS solutions (KMIP). Even VMWare added its own Native Key Provider.
With support for newer operating systems that can take advantage of a TPM to protect private keys (even from its owner), the idea of Public Key Authentication provides users with the ability to eliminate passwords entirely while binding the authenticators to the people who need to use them rather than the hackers who don’t!
Security IN/OF the Solution
Security IN the Solution is about the security of the control plane whereas Security OF the solution is about the data plane.
Lets take a Plaza or Strip Mall as an example. The owner of the property has thick brick walls around the perimeter of the building to provide a strong structure to hold all of the shared services. They tend to divide the property into several smaller units using softer materials like wood and gypsum board so that each tenant has some isolation. They need to provide physical access to each sub-unit that can then be controlled by each tenant and rent the space. The lower the rent, the less isolated each unit is from each other as the costs of providing security for all four walls is reduced.
In this example, you can think of the thick brick exterior as the owners attempt of Security IN the solution. They do not want any part of the sub-units to be breached and they don’t want any of the supporting infrastructure (like water, electrical power or sewage) to be compromized by outsiders so they protect them with a thick perimeter wall. They invest in fire safety and perhaps burglary equipment to protect the investment from the inside and the outside. They invest in features and services that provide security “IN” the building that they own.
Now the Landlord must provide some items for the tenants to feel safe and comfortable or they must allow tenants to modify the units for their own purposes. If you rent a commercial building, you may need to get your own electrical connected (especially if you have custom requirements) or pay for your own water and/or sewage or garbage disposal. All of these features and services are negotiable in the rental agreement and you are encouraged to read the contract carefully because not all rentals come with everything. You may need to provide some/many of the creature comforts you need to run your business. Internet, Cable, perhaps even your own burglar alarm system are all part of Security OF the solution. Your landlord must either provide some of it for you or allow you to purchase and modify the premise so it can be suitable for your use. If not, then you should consider taking your business elsewhere.
After 60 years on this planet and over 30 of them, immersed in the Information Systems industry, I have learned to apply this paradigm to anything from the design of software to the implementation of a solution. I have found that by separating these two objectives, anyone can discuss the roles and responsibilities of any solution and quickly identify ‘How much security you can afford’.
When dealing with third parties who represent warranty for functionality, ask them ‘what do they do to protect themselves?’ For anyone in the IT business, this is referred to as Third party Risk Management. You want to do business with third parties who are reputable and will continue to remain in business. They must be profitable and that means they must have good practices that allow them to operate safely and securely. This helps you choose a service provider that can demonstrate Security IN their Solutions.
Once you have determined who you would like to do business with, you should ask the question, ‘what are they doing to protect you?’ Don’t let their answers fool you, any company that boasts about what they do to protect themselves and then tells you that they use those capabilities to protect you too is mixing the two distinct worlds. What you want them to tell you is what do they do for you and how do they make it safe for you.
Can you see how the two overlap? This might be fine when you develop a relationship with your service provider (like an accountant, a lawyer or your doctor) but if you want to choose a cloud vendor that will house all of your sensitive data, with the purpose of letting them use it to apply Artificial Intelligence on it, you might want to stop and ask yourself, ‘How will they keep my data separate from their staff or any other customers?’ What about rogue employees who might abuse their privileges or what about unauthorized hackers who figure out how to circumvent their controls?
If you are in an industry that is regulated, and there are fines associated with any type of breach of your clients data, you might stand to lose much more than you save by giving your data to a vendor who cannot provide you with the level of data protection you need. This is why you want to consider how a cloud software as a service vendor can provide you with your own level of customization. You want them to show you how they designed their system to provide a distinct separation of all control duties and can provide you with the abilities to trust no one with your data!
When choosing to store data in a cloud service provider or any software as a service vendor, you should consider how they can separate your data away from their shared control plane. If your vendor does not run a Single tenant model (where their control plane is dedicated just for you), and you are forced to choose their multi-tenanted solution, consider how they can keep your data separated.
Many vendors will tell you that they will manage the encryption keys for you and keep them separate from other tenants but would you consider a landlord who required you to give them your sub-unit rentals keys? How do you know that some staff or some robber didn’t open the valet cupboard and just take your keys for a spin? The truth is, if you chose to share sensitive data with this vendor, you don’t!
Now please don’t misunderstand me, SaaS can be a terrific solution for any small or medium sized business that doesn’t have the skills or expertise to manage the complex infrastructure necessary to do something like machine learning. You may not even want the capital expense associated with running your own computer network in order to achieve this but tread lightly and consider the benefits of external key management.
You may not have the ability or the budget to run huge amounts of specialized hardware but you owe it to yourself to manage your own keys. If you don’t rekey your front door, how do you know your inventory will be safe? Remember, the vendor is responsible for Security IN the solution but you are responsible for Security OF the solution you choose.
Before there was a Security Dept.
In response to my wifes’ pleas to ‘clean up my room’, I stumbled upon some memorabilia from the early days of my security career.
Those ‘dialup days’ made IT Security pretty simple and what were CVEs (common vulnerabilities and exposures).
Anyone want my licenses?
Why your business should never accept a wildcard certificate.
When starting your web service journey, most developers will only see the benefits of using a certificate with *only* the domain name referenced (a.k.a wildcard certificate) and will disregard the risks. On the surface, creating a certificate with an infinite number of first level subdomain (host) records seems like a successful pattern to follow. It is quick and easy to create a single certificate like *.mybank.com and then use it at the load balancer or in your backend to frontend (BFF) right? That certificate is for the benefits of clients, to convince them that the public key contained in the certificate is indeed the public key of the genuine SSL server. With a Wildcard certificate, the left-most label of the domain name is replaced with an asterisk. This is the literal “wildcard” character, and it tells web clients (browsers) that the certificate is valid for every possible name at that label.
What could possibly go wrong… 🙂
Let’s start at the beginning, with a standard: RFC-2818 – HTTP over TLS.
#1 – RFC-2818, Section 3.1 (Server Identity) clearly states that, “If the hostname is available, the client MUST check it against the server’s identity as presented in the server’s Certificate message, in order to prevent man-in-the-middle attacks.
How does a client check *which* server it is connecting to if it does not receive one? Maybe it is one of the authorized endpoints behind your load balancer, but maybe it is not? You would need another method of assurance to validate that connecting and sending your data to this endpoint is safe because connecting over one way TLS, into “any endpoint” claiming to be part of the group of endpoints that *you think* you are connecting to is trivial if your attacker has control of your DNS or any network devices in between you and your connection points.
#2 – The acceleration of Phishing began when wildcard certificates became free.
In 2018, in what was soon to become the world’s largest Certificate Authority (https://www.linuxfoundation.org/resources/case-studies/lets-encrypt), Lets Encrypt began to support wildcard certificates. Hackers would eventually use wildcard certificates to their advantage to hide hostnames and make attacks like ransomware and spear-phishing more versatile.
#3 – Bypasses Certificate Transparency
The entire Web Public Key Infrastructure requires user agents (browsers) and domain owners (servers) to completely trust that Certificate Authorities are tying domains to the right domain owners. Every operating system and every browser must build (or bring) a trusted root store that contains all the public keys for all the “trusted” root certificates and, as is often the case, mistakes can be made (https://www.feistyduck.com/ssl-tls-and-pki-history/#diginotar). By leveraging logs as phishing detection systems, phishers who want to use an SSL certificate to enhance the legitimate appearance of their phishing sites are making it easier to get caught if we don’t use wildcard certs.
#4 – Creates one big broad Trust level across all systems.
Unless all of the systems in your domain have the same trust level, using a wildcard cert to cover all systems under your control is a bad idea. It is a fact that wildcards do not traverse subdomains, so although you can restrict a wildcard cert to a specific namespace (like *.cdn.mybank.com.), if you apply it more granularly, you can limit its trust. If one server or sub-domain is compromised, all sub-domains may be compromised with any number of web-based attacks (SSRF, XSS, CORS, etc.)
#5 – Private Keys must not be shared across multiple hosts.
There are risks associated with using one key for multiple uses. (Imagine if we all had the same front door key?) Some companies *can* manage the private keys for you (https://www.entrust.com/sites/default/files/documentation/solution-briefs/ssl-private-key-duplication-wp.pdf), but without TLS on each individual endpoint, the blast radius increases when they share a private key. A compromise of one using TLS, will be easier to compromise all of them. If cyber criminals gain access to a wildcard certificates’ private key, they may be able to impersonate any domain protected by that wildcard certificate. If cybercriminals trick a CA into issuing a wildcard certificate for a fictitious company, they can then use those wildcard certificates to create subdomains and establish phishing sites.
#6 – Application Layer Protocols Allowing Cross-Protocol Attack (ALPACA)
The NSA says [PDF] that “ALPACA is a complex class of exploitation techniques that can take many forms” “and will confer risk from poorly secured servers to other servers the same certificate’s scope” To exploit this, all that is needed for an attacker, is to redirect a victims’ network traffic, intended for the target web app, to the second service (likely achieved through Domain Name System (DNS) poisoning or a man-in-the-middle compromise). Mitigations for this vulnerability involve Identifying all locations where the wildcard certificates’ private key is stored and ensuring that the security posture for that location is commensurate with the requirements for all applications within the certificates’ scope. Not an easy task given you have unlimited choices!
While the jury is ‘still out’ for the decision on whether Wildcard Certificates are worth the security risks, here are some questions that you should ask yourself before taking this short cut.
– Did you fully document the security risks?
How does the app owner plan to limit the safe and secure use of any use of wildcard certificates, maybe to a specific purpose? What detection (or prevention) controls do you have in place to detect (prevent) wildcard certificates from being used in any case, for your software projects? Consider how limiting your use of wildcard certificates can help you control your security.
– Are you trying to save time or claiming efficiencies?
Does your business find it too difficult to install or too time consuming to get certificates working? Are you planning many sites hosted on a small amount of infrastructure? Are you expecting to save money by issuing less certificates? Consider the tech debt of this decision – Public certificate authorities are competing for your money by offering certificate lifecycle management tools. Cloud Providers have already started providing Private Certificate Authority Services so you can run your own CA!
Reference: https://www.rfc-editor.org/rfc/rfc2818#section-3.1
https://venafi.com/blog/wildcard-certificates-make-encryption-easier-but-less-secure
Where *can* I put my secrets then?
I have spent a large portion of my IT career, hacking others peoples software, so I thought it was time to give back to the community I work in and talk about secrets. Whether they be passwords, key material (like SSH, Asynchronous or Synchronous) or configuration elements, all elements that should be considered ‘sensitive’.
Whether you are an old timer who may still be modifying a monolithic codebase or you have modern cloud enabled shop that builds event driven microservices, the Twelve-Factor App is a great place to start. The link provided is the “12 Factor App” methodology, which outlines best practices for building modern software-as-a-service applications. When choosing to adopt this as your strategy, it can provide the basis for software development that transcends any language or shop-size, and should play a part of any Secure Software Development LifeCycle. In Section III Config, they explain the need to separate config from code but I feel this needs further clarity.
There are two schools of thought for many developers/engineers, when it comes to how to use secrets, you can load them into environment variables (as is outlined in this methodology above) or you can choose to persist them into protected files that may be loaded from any external secret manager and mounted only where they are needed. One thing is clear, you should never persist them alongside your code.
Let’s explore the most common, and arguably the easiest way to treat the risks of someone gaining unauthorized access to your secrets: Environment Variables
- Your build environment may be considered implicitly available to the process of building/deploying your code, it can be difficult, but not impossible, for an attacker to track access and how the contents may be exposed (
ps -eww <PID>). - Some applications or build platforms may grab the whole environment and print it out for debugging or error reporting. This requires will require advanced post processing as your build engine must scrub them from their infrastructure.
- Child processes will inherit any environment variables by default, which may allow for unintended access. This breaks the principle of least privilege when you call another tool/code branch to perform some action and has access to your environment.
- Crash and debug logs can/do store the environment variables in log-files. This means plain-text secrets on disk and will require bespoke post processing to scrub them.
- Putting secrets in ENV variables quickly turns into tribal knowledge. New engineers who are not aware of the sensitive nature of specific environment variables will not handle them appropriately/with care (filtering them to sub-processes, etc).
Ref: https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/
Secrets Management done right
Docker decided to to create KeyWhiz as far back as 2016 (seems abandoned now) and many vaulting tools today, make use of injectors that can dynamically populate variables OR create tmpfs mounts with files containing your secrets. When you prefer to read secrets from a temporary file, you can manage the lifecycle more effectively. Your application can call the timestamp functions to learn if/when the contents have changed and signal the running process. This allows database connectors and service connections to gracefully transition whenever key material changes.
Security should never trump convenience but don’t let Perfect be the enemy of ‘Good’. If you have sensitive data like static strings, certificates for protection or Identity or connection strings that could be misused, you need to balance the impact to you or your organization of losing them over your convenience. Learn to setup and use vaulting technology that can provide just enough security to help mitigate any of the risks associated with credential theft. Like hard work and exercise, it might hurt now, but you will thank me later!
Additionally, here are some API key gotchas (which are as dangerous as losing cash) that you should consider whenever you or your teams are building production software.
- Do not embed API keys directly in code or in your repo source tree:
- When API keys are embedded in code they may become exposed to the public, when code is cloned. Consider environment variables or files outside of your application’s source tree.
- Constrain any API keys to any IP addresses, referrer URLs, and mobile apps that need them:
- Limiting who the consumer can be, reduces the impact of a compromised API key.
- Limit specific API keys to be usable only for certain APIs:
- By making more keys, it may seem that you are increasing the impact but if you have multiple APIs enabled in your project and your API key should only be used with some of them, you can easily detect and limit abuse of any one API key.
- Manage the Lifecycle of ALL your API keys:
- To minimize your exposure to attack, delete any API keys that you no longer need.
- Rotate your API keys periodically:
- Rotate your API keys, even when they appear to be used by authorized parties. After the replacement keys are created, your applications should be designed to use the newly-generated keys and discard the old keys.
Ref: https://support.google.com/googleapi/answer/6310037?hl=en
Security Analyst - Jeff Soehner CISSP, GXPN,GPYC,GMOB,GCIH 