Ruminating on AI Security

Artificial intelligence has evolved from a distant vision into a transformative force reshaping industries and daily life. Yet, alongside its immense potential lies a pressing need: security. AI systems, unlike conventional applications, bring distinct vulnerabilities that require a fundamental rethink of security strategies. 

Security by Design: A Core Principle, Not a Last Step

In AI, security isn’t a feature to tack on—it’s a foundational element that must permeate every phase of the process. From initial design to development, deployment, and ongoing management, a "secure by default" mindset ensures that protection is intrinsic to the system’s DNA, not an optional extra.

• Design: Establish clear security goals upfront, identifying potential risks and weaknesses.
• Development: Prioritize secure coding, rigorous testing, and techniques to strengthen models against attacks.
• Deployment: Implement safeguarded environments, strict access controls, and real-time monitoring.
• Operations: Maintain vigilance with ongoing assessments, monitoring, and rapid-response plans.

Effective AI security hinges on threat modeling—assessing how a breached AI component could ripple across systems, users, organizations, and society. Proactively imagining these scenarios sharpens our defenses. Consider risks like data leaks, operational collapses, or AI weaponization by bad actors.Recognize the ethical stakes, as insecure AI can amplify societal harm.

AI applications face threats that traditional security frameworks aren’t built to handle. Here are some critical challenges:

• Training Data Tampering: Attackers can poison datasets, skewing models to produce biased or dangerous results, risking flawed decisions or breakdowns.
• Prompt Manipulation: In generative AI, crafted inputs can hijack outputs, leading to erratic or harmful behavior—especially in systems driven by user interactions.
• Model Theft and Reverse-Engineering: Adversaries may extract or decode models, exposing proprietary logic or sensitive data.
• Adversarial Inputs: Subtle tweaks to inputs can trick models into errors, undermining reliability.

A secure AI future demands investment in key areas:

• Developer Empowerment: Equip teams with training in secure coding, responsible AI practices, and advanced techniques like adversarial hardening and privacy preservation.
• Thorough Monitoring: Deploy robust systems to log and track AI inputs—queries, prompts, or requests—ensuring accountability, auditability, and swift action if compromised.
• Collective Expertise: Encourage collaboration among researchers, developers, and security experts to pool insights and solutions.
• Proactive Audits: Regularly evaluate AI systems to uncover and patch vulnerabilities.

Securing AI is not a one-time fix but a continuous endeavor requiring relentless innovation and alertness. By embedding security across the AI lifecycle and tackling its unique challenges head-on, we can forge a dependable AI ecosystem that safely unlocks its promise for society.

Ruminating on Clickjacking

Clickjacking is a sort of cyberattack in which people are tricked into clicking on something they did not plan to click on. This can be accomplished by superimposing a malicious frame on top of a legal website or injecting a malicious link within an apparently innocent piece of content.

When a user clicks on what appears to be a legitimate website or link, they are in fact clicking on a malicious frame or link. This can then redirect users to a bogus website or run malicious programmes on their PC.

Clickjacking attacks are sometimes difficult to detect because they frequently depend on social engineering tactics to deceive users. For example, the attacker may develop a phoney website that appears to be the actual one, or they could give the victim a link that appears to be from a valid source.

To protect yourself against clickjacking, make use of a pop-up blocker (default in Chrome and many modern browsers).  Any website that asks you to enable Flash or JavaScript should be avoided. Hover your cursor over a link before clicking on it if you are unsure whether it is authentic. If the URL of the link changes, it is most likely malicious.

If you are a developer, please check out the following links to what can be done in your code to reduce the risk of clickjacking. 

https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html

Ruminating on Differential Privacy

Differential privacy (DP) is a mathematical paradigm for protecting individuals' privacy in datasets. By allowing data to be analysed without disclosing sensitive information about any individual in the dataset, it can protects the privacy of individuals. Thus, it is a method of protecting the privacy of people in a dataset while maintaining the dataset's overall usefulness.

To protect privacy, the most easy option is anonymization, which removes identifying information. A person's name, for example, may be erased from a medical record. Unfortunately, anonymization is rarely enough to provide privacy because the remaining information might be uniquely identifiable. For example, given a person's gender, postal code, age, ethnicity, and height, it may be able to identify them uniquely even in a massive database.

The concept behind differential privacy is to introduce noise into the data in such a manner that it is hard to verify whether any specific individual's data was included in the dataset. This is accomplished by assigning a random value to each data point, which is chosen in such a manner that it has no effect on the overall statistics of the dataset but makes identifying individual data points more difficult.

The following paper by Apple gives a very good overview of how Apple uses Differential Privacy to gain insight into what many Apple users are doing, while helping to preserve the privacy of individual users - https://www.apple.com/privacy/docs/Differential_Privacy_Overview.pdf

Epsilon (ε) is a parameter in differential privacy that affects the amount of noise introduced to the data. A greater epsilon number adds more noise, which gives more privacy but affects the accuracy of the findings.

Here are some examples of epsilon values that might be used in different applications:

• Healthcare: Epsilon might be set to a small value, such as 0.01, to ensure that the privacy of patients is protected.
• Marketing: Epsilon might be set to a larger value, such as 1.0, to allow for more accurate results.
• Government: Epsilon might be set to a very large value, such as 100.0, to allow for the analysis of large datasets without compromising the privacy of individuals.

Thus, the epsilon value chosen represents a trade-off between privacy and accuracy. The lower the epsilon number, the more private the data will be, but the findings will be less accurate. The greater the epsilon number, the more accurate the findings will be, but the data will be less private.

A deep dive into these techniques is illustrated in this paper - https://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf

Hash Length of SHA 265

It is important to note that any hash algorithm always returns a hash of fixed length. 

SHA256 returns a hash value that is 256 bits - i.e. 32 bytes. 

These 32 bytes are typically represented as a hexademical string of 64 bytes. 

Hence to store a SHA256 hash, we just need 64 bytes (in database terms - varchar(64)).

Does Bitcoin encrypt transactions?

 *It is important to note that the core bitcoin network/ledger does not use any encryption. It is all hashing as explained here - https://www.narendranaidu.com/2022/05/ruminating-on-proof-of-work.html 

But each and every transaction is digitally signed by a user (or wallet). 

Hence a bitcoin network uses digital signatures and as we know a digital signature is nothing but an encrypted hash of the data. 

You can digitally sign any data in the following way (creating an encrypted hash of the data)

• Hash the data using SHA-256.
• Encrypt the generated hash using your private key. 
• Package this encrypted hash and your public key together. 

The public key is part of the digital signature, whereas the private key is securely stored in a digital wallet (never to be shared with anyone). 

In the bitcoin network, this digital signature is created using the Elliptic Curve Digital Signature Algorithm (ECDS). ECC encryption is not used! - Many folks get confused by this :)

Ruminating on Elliptic Curve Cryptography

When it comes to symmetric encryption, the most common standards are Data Encryption Standards (DES) and Advanced Encryption Standards (AES).

When it comes to asymmetric encryption (public key cryptography), the dominant standard is  RSA (Rivest-Shamir-Adleman). Almost all the digital certificates (HTTPS/SSL) issued used RSA as the encryption standard and SHA256 as the hashing algorithm. 

Given below is a screenshot of a digital certificate of a random HTTPs site. You can see the encryption algorithm and Hash function mentioned in the certificate. 

There is another asymmetric encryption standard called as ECC (Elliptic Curve Cryptography) that is very popular in the crypto world. 

ECC has the following advantages when compared to RSA:

• It can run on low end devices (low CPU and memory).
• It is faster - for both encryption/decryption.
• Smaller key size - 256-bit elliptic curve private key is just as secure as a 3072-bit RSA private key. Smaller keys are easier to manage and work with.

While certificate issuers have started providing ECC standard based digital certificates, it is important to note that not all browsers (mobile, desktop) still support it. Also a lot of legacy apps may not have support for ECC standard and these have to be refactored for SSL to work again. 

Ruminating on Proof of Work

While I understood how bitcoin mining worked, there were still a few strings loose in my mind on why exactly was the 'Proof-of-Work' algorithm created that way? (i.e. finding a nonce that results in a hash lower than the target value)

The following video from Khan Academy gives an excellent understanding of PoW is very simple terms - https://www.khanacademy.org/economics-finance-domain/core-finance/money-and-banking/bitcoin/v/bitcoin-proof-of-work

Also the following snippets from Investopedia: https://www.investopedia.com/terms/n/nonce.asp would give a better idea on the challenge (finding the right nonce) that all bitcoin miners are trying to solve. 

"A nonce is an abbreviation for "number only used once," which, in the context of cryptocurrency mining, is a number added to a hashed—or encrypted—block in a blockchain that, when rehashed, meets the difficulty level restrictions. The nonce is the number that blockchain miners are solving for. When the solution is found, the blockchain miners are offered cryptocurrency in exchange.

A target hash is a numeric value that a hashed block header (which is used to identify individual blocks in a blockchain) must be less than or equal to in order for a new block to be awarded to a miner.

The Bitcoin network adjusts the difficulty of mining by raising or lowering the target hash in order to preserve an average 10-minute interval between new blocks.

The block header contains the block version number, a timestamp, the hash used in the previous block, the hash of the Merkle Root, the nonce, and the target hash. The block is generated by taking the hash of the block contents, adding a random string of numbers (the nonce), and hashing the block again.

Determining which string to use as the nonce requires a significant amount of trial-and-error, as it is a random string. A miner must guess a nonce, append it to the hash of the current header, rehash the value, and compare this to the target hash. If the resulting hash value meets the requirements (golden nonce), the miner has created a solution and is awarded the block.

It is highly unlikely that a miner will successfully guess the nonce on the first try, meaning that the miner may potentially test a large number of nonce options before getting it right. The greater the difficulty—a measure of how hard it is to create a hash that is less than the target—the longer it is likely to take to generate a solution."

Ultimately it is all about guessing a nonce and calculating the hash and comparing it. Hence the capacity of a bitcoin mining farm is calculated in terms of hash rate - i.e. number of hashes that can be computed per second. The term 'Bitcoin mining' is actually misleading as what the miners are actually doing is finding a hash that satisfies the challenge and this also validates the transactions in the block (and the block gets added to the chain). 

But as many miners jump on the bandwagon, there is lot of wastage of compute cycles and this is a controversial topic for many people.  

Numeric value of a hash

In the bitcoin network, miners have to compare the hash value during the 'Proof-of-Work' process.

The target hash value is stored in the header and is expressed as a 67-digit number. Miners must find a new hash of the transaction block  that is below the given target. 

To solve the hash puzzle, miners will try to calculate the hash of a block by adding a nonce to the block header repeatedly until the hash value yielded is less than the target.

But how is the value of the hash calculated? In the bitcoin network, the value of a hash is calculated as follows:

• Hashes are typically represented as a hexadecimal string. Convert the hexadecimal value to decimal value. 
• Get the base-2 log of the decimal value. 

This is the value that is compared against the target in the block header. 

Ruminating on Automation (RPA) Security Risks

 Intelligent automation & RPA can drive operational efficiencies at organizations and help boost the productivity of enterprise resources. But there is also a risk of cyber-attacks as bots introduce a new attack surface for hackers. 

Without proper measures, enterprises may face increased risk exposure due to bots. The following recommendations would enable organizations to mitigate the risk of such security attacks.

1. Secure Vault: All credentials required by the bot to execute tasks on applications should be securely stored in a Vault (e.g. CyberArk or HashiCorp Vault). This ensures that the target application credentials are not stored by the bot and only accessed at runtime by the bot from the vault. 

2. Least Privilege Access: bots should not be given a blanket access to perform all operations, but should be given only appropriate access as required for the automation usecases - e.g. many automation usecases would entail 'read-only' access to databases/applications. 

3. Selecting appropriate Automation use-cases: While down-selecting automation usecases, it would be good to have 'Security Risk' as an parameter for assessment. If a bot needs admin access across multiple applications to perform critical business functions, then the organization can decide to NOT automate this usecase and handover the case to a knowledge worker. The bot can enable this smooth transition to humans (via a workflow or case management tool).

4. Change Bot passwords/secure keys: As a security best practice, change the passwords and secure keys for the bots (and machines where bots run) regularly (e.g. once a month). 

5. Security Testing of Bots: Ultimately bots are also software components and we need to make sure that the bots undergo both static code security analysis and runtime security testing. 

6. Audit Trail & Proactive Monitoring: The automation framework should provide a detailed audit log of all bot activities. Each and every step executed by the bot should be available for forensic audit if required. Proactive monitoring of this audit log can also be automated to quickly alert users of any anomaly pattern or security breach. 

7. Governance Framework - Last but not the least, it is important to setup a proper governance framework for bot lifecycle management. The governance framework should clearly define the roles and responsibilities and the proper process to be followed for the entire bot lifecycle. 

Ruminating on Mutual Authentication

In mutual authentication, both the server as well as the client have digital certificates and authenticate each other. If both the server and client are using CA signed certificates, then everything would work OOTB and there would be no need to import any certificates. This is because, both the server and client default trust stores would have the root certificates of most CAs.

But during testing and in lower environments, teams often use self-signed certificates. To enable mutual authentication using self-signed certificates, we have 2 options. 

• Peer-2-Peer: Create a client certificate for each agent. Import this cert into the trust store of the server. 
• Root cert derived client certifications:  Create a client root certificate and using this root certificate, create/derive client certs for each agent. Then you just have to import the client root certificate into the server trust store ( and not of all the agents).    

 The following links are a good read for implementing the above. 

https://docs.oracle.com/cd/E19879-01/819-3669/bnbyi/index.html

https://gist.github.com/granella/01ba0944865d99227cf080e97f4b3cb6

https://sites.google.com/site/ddmwsst/create-your-own-certificate-and-ca

https://docs.couchbase.com/server/current/manage/manage-security/configure-client-certificates.html

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff650751(v=pandp.10)?redirectedfrom=MSDN

Blockchain in Healthcare

The usage of blockchain in healthcare is gaining traction. Any information that can be privately and securely shared between payers and providers is a good case for blockchain. Jotting down some of the blockchain use-cases that are being explored today -

1) Improving Provider Data Accuracy: Every year, Payers spend millions of dollars in maintaining an up-to-date record of their providers. Provider data management is crucial for maintaining an accurate provider directory. Accurate provider data is critical for connecting patients with appropriate network care providers.

But each Payer has an independent provider directory and repeats the process of collecting and validating provider credentials.
Having a secure blockchain backed provider directory makes sense; as all Payers can collaborate and share provider information.  The Synaptic alliance was setup for this exact purpose. The Alliance views blockchain technology as a means to a critical end: ensuring that provider data is accurate and
sharable for reliable use across the healthcare ecosystem. More information about this alliance can be found in this whitepaper here.


2) Clinical Member Profile: Payers often need longitudinal clinical records of a member from different providers to manage the care better. Instead of spending time and effort in setting up brittle interfaces with hospital systems, payers and providers can use a private blockchain system to share clinical member records.
 All data in the blockchain would be encrypted and immutable. A private blockchain can also help in regulatory compliance because they establish a trusted audit trail.

HIPAA compliant blockchain HER platforms are already present in the market: 

https://patientory.com/

https://timicoin.io/

Caveat: Today large volumes of unstructured data (e.g. DICOM images, PDF files) are not cost effective to be stored on a blockchain. It is recommended to store the ‘link references’ to these resources in the blockchain.

Adding custom filters to Spring Security

One of my teams was looking for an option for adding filters on the Spring Security OAuth Server.

As we know, the Spring Security OAuth2 Server is a complex mesh of filters that get the job done in implementing all the grant types of the OAuth specification - https://docs.spring.io/spring-security/site/docs/current/reference/html/security-filter-chain.html#filter-ordering

The team wanted to add additional filters to this pipeline of Security filters. There are many ways of achieving this:

Option 1: Create a custom filter by extending the Spring GenericFilterBean class. You can set the order by using the @Order annotation.

Option 2: Register the filter manually in the WebSecurityConfigurerAdapter class using the addFilterAfter/addFilterBefore methods.

Option 3: Set the property "security.filter-order=5" in your application.properties. Now you can add upto 4 custom filters and set the order as either 1,2,3,4.
Another option is to manually set the order (without annotations) using FilterRegistrationBean in any @Configuration

The following 2 blogs helped us explore all options and use the appropriate one.
https://mtyurt.net/post/spring-how-to-insert-a-filter-before-springsecurityfilterchain.html
http://anilkc.me/understanding-spring-security-filter-chain/

Encrypting sensitive data in Spring application.properties file

If you want to encrypt passwords, keys and other sensitive information in your application.properties file, then you have a nifty solution from an open source encryption library called as Jasypt.

We begin by adding the maven dependency of jasypt-spring-boot-starter to our Spring Boot application. The steps involved in integrating Jasypt into your Spring Boot application is as follows:

1. First using Jasypy and a secret password, created encrypted tokens of all sensitive information.

2. Put this encrypted token in your properties file with the value enclosed with string 'ENC' - e.g. password=ENC(encrypted-token)

3. Retrieve your properties in Spring classes the same old way - e.g. using the @Value annotation or env.getProperty() method.

A good example explaining this is here - https://www.ricston.com/blog/encrypting-properties-in-spring-boot-with-jasypt-spring-boot/  with source code available here.

Changing the hashing algorithm for passwords

Recently, one of my teams wanted to update their password hashing algorithm that was in use for more than 2 years. As discussed here, passwords should always be hashed in the database.

If we directly employ the new hashing algorithm, then all users would lose the ability to login with their old passwords and would be forced to change their password.

Hence, we need to follow the following approach:

1. Add a new column to the user table that stores the hashing algorithm name (or version).
2. Set this version to 1 for all old passwords.
3. When the user logs in, first check the hash using the old algorithm. If it is correct, then hash the password using the new algorithm and save the hash.
4. Update the version column to 2.  

Generating secure keys for encryption

Very often, we need to create secure keys that can be used in digital signatures or for signing a JWT.
It is very important to create a secure key so that the encryption is strong. A good post about this is here - https://docs.oracle.com/cd/E19424-01/820-4811/aakfw/index.html

Jotting down some snippets from the article:

The strength of encryption is related to the difficulty of discovering the key, which in turn depends on both the cipher used and the length of the key. 

Encryption strength is often described in terms of the size of the keys used to perform the encryption: in general, longer keys provide stronger encryption. Key length is measured in bits.

Different ciphers may require different key lengths to achieve the same level of encryption strength

------------------------------------------------------------------------
A key is nothing but a byte array that is passed to the encryption algorithm.  Hence if you are storing the key in a properties file, please makes sure that you have stored it in Base64 format.

Spring provides very simple methods for generating secure keys as shown below.

API keys providing a false sense of security !

We have seen so many API implementations wherein an API key is the only thing used to secure APIs. API keys are typically long alphanumeric strings that give a false sense of security.

The entire onus of protecting that key and making only SSL requests lies with the API consumer. This is a very concerning, since this rarely happens. We have decompiled Android APKs and found API keys stored in config files. We have seen API keys checked-into source control systems such as GitHub :)

Kristopher Sandoval has written an excellent blog post on the prevalent usage of using API keys to secure your APIs.

We must not rely solely on API keys to secure our APIs, but rather use open standards such as OAuth 2, OpenID Connect, etc. to secure access to our APIs. Many developers use insecure methods of storing API keys in mobile apps or pushing the API key to Github.

Snippets from the article (http://nordicapis.com/why-api-keys-are-not-enough/) -

"Most developers utilize API Keys as a method of authentication or authorization, but the API Key was only ever meant to serve as identification.
API Keys are best for two things: identification and analytics (API metrics).

If an API is limited specifically in functionality where “read” is the only possible command, an API Key can be an adequate solution. Without the need to edit, modify, or delete, security is a lower concern."

Another great article by NordicAPIs is on the core concepts of Authentication, Authorization, Federation and Delegation - http://nordicapis.com/api-security-the-4-defenses-of-the-api-stronghold/
The next article demonstrates how these 4 core concepts can be implemented using OAuth and OpenID Connect protocols - http://nordicapis.com/api-security-oauth-openid-connect-depth/

HTTP proxy tools for capturing network traffic

In the past, we had used tools such as Fiddler and Wireshark to analyse the network traffic between clients and servers. But these tools need to be installed on the machine and within corporate networks, this would entail taking proper Infosec approvals.

If you are looking for a nifty network traffic capture tool that does not need installation - then 'TcpCatcher' is a good option. This is a simple jar file that can run on any m/c having Java.

Whenever we are using such proxy tools, we have two options -
1. Change the client to point to the IP of the tool, instead of the server. The tool would then forward the request to the server. (Explicit man in the middle)
2.  Configure the tool IP as a proxy in your browser.  (Implicit man in the middle)

Update: 25May2016
The TcpCatcher jar tool started behaving strangely today with an alert stating - "This version of TcpCatcher has expired. Please download the latest version". We had the latest version, but looks like this is a bug in the system.

We moved on to use Burp Suite free edition. This tool is also available as jar file and can run on any machine having Java. There is an excellent article by Oleg Nikiforov that explains how to setup burp proxy and use it to intercept all http requests. You can also download their root certificate and install it in your machine or mobile phone to log all HTTPS traffic.
We could setup Burp in under 20 mins to monitor all HTTPS traffic between our mobile apps and APIs.

Utilizing Azure AD for B2C mobile apps

We had successfully utilized Azure Active Directory for authentication of enterprise mobile apps. But can Azure AD be used for B2C apps? The answer is YES - Microsoft has released a preview version of Azure AD B2C that can be used for all customer-facing apps.

In Azure AD tenant, each user has to sign in with a long userID-email - e.g. {name}@{tenant}.onmicrosoft.com. This is not feasible for B2C apps, hence in Azure AD B2C, it is possible to log in with any email address, even plain usernames are supported. These accounts are called as Local Accounts in Azure AD B2C. Social Identity logins are also supported - e.g. Facebook, Google+, LinkedIn, and Amazon.

For more details on Azure AD B2C please refer to the following links:

https://azure.microsoft.com/en-in/documentation/articles/active-directory-b2c-faqs/

https://azure.microsoft.com/en-in/services/active-directory-b2c/

Ruminating on JWT

JWT (JSON Web Token) has gained a lot of traction in the past couple of years and is slowly becoming the standard choice for all authentication and authorization communication.

The best way to learn about JWT is to head straight to their site - https://jwt.io/introduction/
I was impressed with the quality of the documentation. Core concepts were explained in a simple and lucid language. It took me days to understand SAML, whereas I could grasp even the complex concepts of JWT in minutes :)
Also we can store all authorization claims in the JWT payload, reducing the need to make another database call for checking authorization access levels.

But it is important to note that JWT specification does not talk about encrypting the payload - that is out of scope in the specification. You can encrypt the payload if you want it, but you would need to control the client/server code - i.e. JWT decoding libraries.

Since the JWT payload is not encrypted, it is of utmost important that JWTs are passed over TLS (HTTPS). Eran Hammer has written a good blog post on the perils of using a bearer token without TLS. A bearer token is called so because the 'bearer' - i.e. whoever holds the token is given all rights that the token would specify. A good analogy would be 'cash' - whoever has the cash can spend it, irrespective of who the rightful owner of that cash was.

Ruminating on Biometric security

Fingerprint scanners are becoming ubiquitous in many smartphones. There are also a few other pure software biometric solutions that are gaining traction in the market. Jotting down a few references.

http://www.eyeverify.com/  - EyeVerify maps the unique veins (blood vessels) and other micro-features in and around your eyes to create a digital key (eye-print) equal to a 50-character complex password. They claim that they are more than 99.99% accurate. It can work on any existing 1+ MP (megapixel) smart device camera !

Nuance Vocal Password: A user's voice is analyzed for hundreds of unique characteristics that are then compared to the voiceprint on file.