AI for Security and Securing AI: The Two Fronts Every CISO Must Lead

Artificial Intelligence is rapidly changing enterprise security - not just in how organizations defend themselves, but also in what they must defend. For CISOs, this has created two parallel priorities that can no longer operate independently:

1. Using AI to strengthen security programs
2. Securing the organization’s own AI ecosystem

Organizations that focus on only one side are discovering major gaps either inefficient security operations or uncontrolled AI risk exposure.

The future of security is no longer just “security for applications.” It is now AI-enhanced security operations combined with AI governance and AI defense.

AI for Security: Transforming Application Security Programs

Traditional application security programs have matured over the years with practices such as SAST in CI/CD pipeline, DAST, Manual Penetration Testing, Manual Secure Code Review and VDP. 

These do remain critical. However, modern development velocity and AI-assisted coding have fundamentally changed the threat landscape. Applications are now larger, faster-changing, AI-generated in parts, micro-service driven and increasingly dependent on third-party components.  

This means traditional AppSec processes alone are no longer sufficient. The next generation of AppSec requires two major AI-driven additions:

 The AppSec lifecycle is evolving from: 

“Find vulnerabilities” to “Find, validate, and understand business impact.”

2. Securing AI: The New Enterprise Security Program

While organizations are using AI to improve security, they are simultaneously deploying AI across business functions internal copilots, customer support bots, AI-enabled workflows, AI-assisted development, document intelligence systems, AI agents and RAG-based enterprise platforms and so on. This introduces an entirely new attack surface and many organizations are discovering a dangerous misconception. Out-of-the-box AI security controls are not enough.

As highlighted in the recent case study “Building an AI Security Program for a Global Investment Firm”, securing AI requires a dedicated organizational process, not simply enabling default protections. AI systems introduce different risks and require different level of customization:

The Emerging CISO Reality

The modern CISO now operates two security transformation programs simultaneously:

Organizations that mature in only one area will remain exposed in the other.

 

Blueinfy’s Approach

At Blueinfy, we are working closely with CISOs to help establish both dimensions of this transformation:

The organizations that succeed over the next few years will not simply “adopt AI.”
They will:

• Use AI to improve security effectiveness
• Secure AI systems with the same rigor as critical enterprise applications

That combination will define the next generation of cybersecurity maturity.

Article by Hemil Shah

[Case Study] Building and Running an effective Application Security Program for a global biotechnology company

Client Overview
ACME is a global biotechnology company committed to strengthening their internal IT and application security program. They partnered with Blueinfy to develop and implement a robust application security strategy that integrates seamlessly into their development lifecycle. 

Partnership with Blueinfy

Team Structure
Technical SME - Application Security

• Technical Point of contact for Application Security & Web Penetration Testing.
• Technical support in end to end application security life cycle management.
• Identify and drive continuous process improvements across security programs and services.
• Resolve roadblocks through driving trade-off decisions to move work forward.
• Provide strategic direction and subject matter expertise for wide adoption of DevSecOps automation.
• Develop and promote best practices for DevSecOps and secure CI/CD.
• Stay up-to-date on new security tools & techniques, and act as driver of innovation and process maturity.
• Perform threat modelling and design reviews to assess security implications of new code deployments.

Manager - Application Security

• Administrative Point of contact for Application Security & Web Penetration Testing
• Accountable and responsible for overflow responsibilities from senior security leadership
• Identify and drive continuous process improvements across security programs and services
• Resolve roadblocks through driving trade-off decisions to move work forward
• Deliver correct security results to the business units
• Tracking, monitoring and influencing priority of significant application security objectives and plans
• Provide strategic direction and subject matter expertise for wide adoption of DevSecOps automation.
• Develop and promote best practices for DevSecOps and secure CI/CD.

Actions Taken

• The Blueinfy team actively engaged with the development team, attending sprint cycle calls to understand their workflow and challenges.
• Created documentation and collaborated with management to integrate application security into the development cycle, ensuring security was an integral part of the process rather than a hindrance.
• Proposed a process for penetration testing and code review where discovered vulnerabilities were mapped directly to the code, facilitating clear remediation actions for developers. This approach led to a smooth buy-in from the development team, resulting in applications being deployed with no critical or high-risk vulnerabilities.

SAST Implementation
SAST SME

• Work as SAST SME
• Develop and implement SAST strategies and methodologies tailored to Genmab's needs.
• Lead the selection, implementation, and customization of SAST tools and technologies.
• Conduct thorough static code analysis to identify security vulnerabilities, coding flaws, and quality issues.
• Collaborate with development teams to integrate SAST into CI/CD pipelines and development processes.
• Provide guidance and support to developers on secure coding practices and remediation of identified issues.
• Perform code reviews and audits to ensure compliance with security policies, standards, and regulatory requirements.
• Stay updated on emerging threats, vulnerabilities, and industry trends related to application security.
• Create and maintain documentation, including SAST procedures, guidelines, and best practices.
• Work closely with cross-functional teams, including security, engineering, and IT operations, to drive security initiatives and improvements.
• Act as a trusted advisor to management and stakeholders on SAST-related matters.

SAST Tool Selection

• A comprehensive list of requirements was created and shared with stakeholders, including development and infrastructure teams.
• Evaluated SAST products based on required features, scoring each product to determine the best fit.
• Selected and purchased the most suitable SAST tool based on evaluation results.
• Integrated the tool into the CI/CD pipeline, ensuring early detection of vulnerabilities and removal of false positives.

Outcome
With the comprehensive application security program, including SAST, penetration testing, and code reviews, ACME successfully secured all their applications before they went into production. This proactive approach ensured that vulnerabilities were addressed early in the development cycle, enhancing the overall security posture of ACME's applications.

Article by Hemil Shah

[Case Study] - Ensuring Effective Security Scanning in Outsourced Development for ACME Company

Background

ACME Company outsourced a significant portion of its software development to an external vendor. As mandated in the Statement of Work (SoW), a Static Application Security Testing (SAST) scan must be performed before any code is delivered. However, when ACME conducted a penetration test on the delivered code, they discovered numerous security vulnerabilities, raising concerns about the effectiveness of the SAST process at the development company.

Objective
To ensure that the SAST process at the development company is effective and aligns with ACME Company's security standards.

Steps Taken

1. Engagement to Review SAST Process
ACME engaged Blueinfy to review the SAST process at the development company. The goal was to understand why the SAST scans had failed to identify vulnerabilities that were later found during penetration testing.

2. Questionnaire Development and Submission
A comprehensive questionnaire was developed, covering various aspects of the SAST process. At a high level, following categories were covered in questionnaire
•    Application details
•    SAST tool/product
•    Scan profile
•    Rules and their updates
•    Reporting
•    Execution method
•    Scan strategy
•    Integration with code repository
•    Frequency of scans
•    Team responsibility (RACI)
•    Finding tracking
•    Process for handling false positives/negatives

The main intention here was to gather information about the SAST process, tools used, configurations, and practices followed by the development company. The questionnaire was submitted to the development company, requesting comprehensive responses.

3. Interviews for Clarification
After receiving the answers, a detailed analysis was performed and follow-up interviews were conducted to clarify responses and delve deeper into the specifics of the SAST process.

4. Findings and Diagnosis
Improper Configuration: The review process revealed that the SAST scanner was not properly configured, leading to the scans missing vulnerabilities. This misconfiguration resulted in SAST scans showing no significant findings.

Old Rules: The server where the SAST tool was configured could not connect to the internet. This measure was implemented to ensure that the source code did not get transmitted over the internet. Consequently, the SAST tool failed to connect to the server to retrieve the latest rules.

5. Initial Adjustments
Scan Profile Change: The scan profile was adjusted to ensure it was comprehensive and aligned with industry best practices. This reconfiguration aimed to improve the scanner's ability to detect relevant security issues.

The firewall rule was updated to allow the server to connect to the vendor's server and retrieve the latest updates for the rules.

6. Handling False Positives
Increased False Positives: Following the initial changes, the SAST scanner began generating results, but there was a significant increase in false positives. This overwhelmed the development team and made it challenging to identify actual security threats.
Further Refinements: To address the issue of false positives, the scan profile was refined further. The focus was shifted to report only a few high-priority categories with high accuracy, ensuring that the identified issues were both relevant and critical.

Outcome
The refined scan profile started producing actionable results, significantly reducing false positives and highlighting genuine vulnerabilities that needed to be addressed.
By thoroughly reviewing and adjusting the SAST process, ACME Company ensured that the development company could effectively use SAST scans to identify and mitigate security vulnerabilities. This enhanced approach not only improved the security posture of the delivered code but also built a stronger collaborative relationship between ACME and its development partner.

Recommendations
1. Regular Audits
Conduct regular audits of the SAST configuration and process to ensure ongoing effectiveness and rule updation.

2. Continuous Improvement
Implement a continuous improvement cycle where feedback from penetration testing and other security assessments informs ongoing adjustments to the SAST process.

3. Defense in Depth
It is important to have multiple programs in place. Relying solely on SAST/DAST or penetration testing is not sufficient for mission-critical applications. A combination of all these programs is essential. Insights gained from one program should be used to enhance and train other programs and tools.

4. Training and Awareness
Provide training to the development company on the importance of proper SAST configuration and how to manage false positives effectively.

Conclusion
Through a comprehensive review and iterative adjustments of the SAST process, ACME Company ensured that their outsourced development partner could deliver secure code that meets ACME's security standards. This proactive approach not only mitigated potential security risks but also strengthened the partnership with the development company.

Article by Hemil Shah

Unveiling the Vulnerabilities: Hacking Cloud Native Apps and Discovering the Silver Lining

 

The security of cloud storage services, such as S3/GCP Buckets, the implementation of Cognito/SSO OAuth, and the protection of API endpoints have become paramount for web applications. As cloud integration becomes more accessible, comprehensive assessments of these components before deployment are crucial. Cloud infrastructure offers technological advancements, resource availability, and cost savings compared to traditional setups. However, cloud-native applications bring unique challenges. This talk addresses risks associated with user authentication using OAuth providers like Google, Slack, or AWS Cognito, where insecure implementations can lead to complete user account takeovers. It delves into security concerns regarding cloud storage services like AWS S3/GCP Buckets, which expose sensitive user data to unauthorized access. Additionally, vulnerabilities introduced by API-based micro-services employing Serverless lambda functions are explored. Attendees will gain insights into identifying, exploiting, and mitigating these cloud-native vulnerabilities through manual penetration testing and automated tools, as well as practical mitigation techniques.

Here for more detail on this talk.

Speakers

Amish Shah

Co-CEO and Director, Blueinfy Solutions Pvt. Ltd

Amish Shah, Co-CEO and Director at Blueinfy, an esteemed technical expert in the field. With a wealth of experience spanning over 20 years, Amish brings a unique blend of skills in secure product development, application security assessment, and red team exploitation. As the technical... Read More →

Lambda functions and CORS implications

CORS (Cross-Origin Resource Sharing) is a web browser security mechanism that restricts web pages from making cross-origin requests, adhering to the Same Origin Policy (SOP). When a web page from one origin requests a resource from another origin, the browser blocks the request unless the server hosting the requested resource explicitly allows it.

In the context of AWS Lambda functions, CORS security is crucial when developing serverless applications that interact with APIs hosted on different domains. Here are some important considerations to keep in mind while working with CORS and Lambda functions:

Set CORS headers properly: When your Lambda function returns a response, it should include the appropriate CORS headers to indicate which origins are allowed to access the resource. This is typically done using the Access-Control-Allow-Origin header, which specifies the domain(s) that are allowed to make requests.

Validate all inputs: To prevent malicious requests from bypassing CORS restrictions, it is important to validate all inputs to your Lambda function. This includes checking for invalid characters, input length limits, and other security checks.

Leverage API Gateway: API Gateway offers built-in support for CORS, allowing you to specify which origins are allowed to access your API. You can configure CORS settings at the API level or at the method level. 

Restrict access: You should limit access to your Lambda function to only the necessary resources and methods. This can be done using IAM (Identity and Access Management) policies to restrict access to specific resources or API methods. 

Having HTTPS: To prevent man-in-the-middle attacks, it is recommended to use HTTPS when making requests to your Lambda function. This will also help ensure that your CORS headers are not tampered with by an attacker.

By following these best practices, you can ensure that your Lambda function is secure and not vulnerable to CORS attacks.

Top Security issues with Lambda functions

AWS Lambda functions are a fundamental element of serverless computing across networks. In serverless architecture, the cloud provider manages the underlying infrastructure, including servers and scaling, while application developers focus on writing code for specific functions or tasks. Lambda functions are small code segments that can be executed in response to events such as data changes, user requests, or scheduled tasks. One of the primary advantages of using Lambda functions is that developers only pay for the time their code runs, which is more cost-effective than paying for a dedicated server or virtual machine. Additionally, the automatic scaling of Lambda functions makes it easier to handle unpredictable or fluctuating workloads. Lambda functions can be integrated with other AWS services such as Amazon S3, Amazon DynamoDB, and Amazon API Gateway to create complex and scalable applications. They can also be used to build microservices, which are small, independent components of an application that can be developed, deployed, and scaled independently. However, Lambda functions are also susceptible to security vulnerabilities. Here are ten critical issues that we have observed lately during our pen-testing:

• Injection Attacks: Malicious inputs can be used to inject arbitrary code into Lambda functions.
• Broken Access Controls: Weak or improper access controls can lead to unauthorized access to resources or data.
• Insecure Storage of Secrets: Sensitive data or credentials stored insecurely within Lambda functions could be accessed by attackers.
• Insecure Dependencies: Insecure or outdated dependencies can introduce vulnerabilities in Lambda functions.
• Inadequate Authentication and Authorization: Weak authentication and authorization mechanisms can lead to unauthorized access to Lambda functions.
• Improper Error Handling: Improper handling of errors in Lambda functions could leak sensitive information that could be exploited by attackers.
• Insufficient Encryption: Lack of encryption can make data transmitted to or stored within Lambda functions vulnerable to interception and theft.
• Lack of Monitoring and Logging: Without proper monitoring and logging, it can be difficult to detect and respond to security incidents.
• Denial of Service Attacks: Malicious actors can use Lambda functions to perform Distributed Denial of Service (DDoS) attacks.
• Insider Threats: Malicious actors with legitimate access to Lambda functions can exploit vulnerabilities to steal data or perform unauthorized actions.

[Case Study] Enhancing DAST Security Scans for ACME News Company

Background
ACME, a prominent news-based company, operates hundreds of websites accessible over the internet. These sites, primarily content-focused, share a uniform technology stack. The company's admin applications, however, remain inaccessible from the internet. Given the minimal input and largely static nature of these websites, traditional penetration testing seemed unnecessary. However, the potential brand damage from a compromised site was a significant concern.

Challenge
ACME sought to ensure the security of its numerous websites through automated Dynamic Application Security Testing (DAST) scans on a monthly basis. The challenge lay in the sheer volume of links across these sites, coupled with their minimal functionality, which resulted in prolonged scanning durations. Each scan took days to complete, delaying the identification of potential vulnerabilities.

Solution
Blueinfy, leveraging its extensive experience in DAST scanners and a deep understanding of ACME's specific technology, developed an innovative approach to optimize the scanning process. Instead of a traditional, exhaustive scan of every link, Blueinfy devised a methodology where each unique functionality was tested only once. This streamlined approach significantly reduced the scanning time while maintaining accuracy of the results.

Furthermore, Blueinfy tailored the DAST scanner to align with ACME's specific technology stack, ensuring the scans were relevant and focused on the most critical vulnerabilities. To facilitate seamless integration into ACME's GRC platform, the scan results were converted into a specific CSV format, enabling easy import and efficient use of the data.

Outcome
With Blueinfy's tailored approach, ACME successfully implemented a more efficient and effective security scanning process. The new methodology allowed for timely and accurate scans, enabling ACME to promptly address vulnerabilities and protect its brand. The customization of the DAST scanner and the provision of results in CSV format ensured that the data was not only actionable but also easily integrated into ACME's existing systems.

Blueinfy's expertise in configuring DAST scanners to align with ACME's technology stack proved invaluable, offering a solution that was both time-efficient and highly accurate. This partnership underscored the importance of leveraging specialized knowledge to overcome unique challenges in cybersecurity.

Article by Hemil Shah

Deep Lambda Inspection by age-old LD_PRELOAD Trickery

Lambda function uses AWS Fargate as an underlying platform and it is being leveraged by Firecracker. Firecracker is a Micro-VM, which is used to run lambda functions. As shown in the below figure, it runs in a guest OS and inherits the environment before executing the lambda code. At this time, one can leverage age-old preload trick.

Leveraging LD_PRELOAD:

Lambda function runs under a Linux based environment and it is possible to leverage preloading mechanism as shown in the above figure. If we look at “LD_PRELOAD” usage in the man page –

“A list of additional, user-specified, ELF shared objects to be loaded before all others.  The items of the list can be separated by spaces or colons, and there is no support for escaping either separator.  This can be used to selectively override functions in other shared objects.”

Hence, LD_PRELOAD is an environmental variable that contains paths to shared libraries and objects; which the loader will load before any other shared library including the C runtime library. This is the way preloading would work within lambda function as well.

It allows us to load and override various functions, which are important, and we would like to review these functions from a security perspective. For example:

1.    Underlying OS calls – we can load/override all remote command execution calls, made by lambda function. Hence, when the lambda function makes these calls, we can monitor them to discover vulnerabilities.

2.    Underlying file operations – we can load/override all file operations and monitor them at runtime. We can see if function is making any calls which are vulnerable or the file path it is using. This would aid in identifying path traversal and other file system related vulnerabilities.

3.    Underlying network operations – we can load/override networking functions and observe how lambda function is making calls to external entities. By monitoring third party outgoing calls, vulnerabilities like SSRF or any other network related abuses can be identified.

Let’s look at a simple implementation to observe networking calls. Through the below snippet, we are injecting code to capture socket, connect and send calls in the shared object. We dump the content into “/tmp/lammon.txt” file and can retrieve this content via function or write it to CloudWatch logs.

// Overriding socket call…
int socket(int domain, int type, int protocol)
{
    int (*new_socket)(int domain, int type, int protocol);
    new_socket = dlsym(RTLD_NEXT, "socket");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "socket function called Process %d:%d:%d:%d\n",
getpid(), domain, type, protocol);
    fclose(logfile);
    return new_socket(domain, type, protocol);  

}

// Overriding connect call…
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
    int (*new_connect) (int sockfd, const struct sockaddr *addr,
socklen_t addrlen);
    new_connect = dlsym(RTLD_NEXT, "connect");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "connect function called Process %d:%d:%d:%s\n",
getpid(), sockfd, (int)addr->sa_family, addr->sa_data);
    fclose(logfile);
    return new_connect(sockfd, addr, addrlen);
}

//Capturing send call…
ssize_t send(int sockfd, const void *buf, size_t len, int flags)
{
    ssize_t (*new_send)(int sockfd, const void *buf, size_t len, int flags);
    new_send = dlsym(RTLD_NEXT, "send");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "send function called Process %d:%d:%s\n",
getpid(), sockfd, (buf == NULL ? " " : (char *)buf));
    fclose(logfile);
    return new_send(sockfd, buf, len, flags);      
}

We compile the code and build a shared object. Now, we can put this into lambda layers so it can be used into any lambda functions in a shared way as shown below: -




 Now, let’s add to the lambda function as shown below: -

 

Once it is set, all functions will be intercepted by our code and actual outgoing sniffing can be seen as shown in the below figure: -





As shown above, we were able to sniff or see actual calls being made to other hosts by lambda function.

Integrating into assessment methodology:

This type of object can help in assessing lambda functions for vulnerabilities. We can load the shared object, which can gather critical information while lambda function, is invoked. It is getting logged into file or CloudWatch logs. We can invoke functions with different payloads and monitor the behaviour. It allows us to identify various sets of vulnerabilities. It ends up being a similar approach to IAST along with DAST by leveraging this simple trick.

Can it help in protection?

Yes, one can build shared object in such a way that when anything objectionable is found at runtime then it can stop execution of that call.

Conclusion:

“LD_PRELOAD” trick seems interesting for lambda function assessment. One can leverage it by adding a small code and loading it before the start of execution. It can intercept all calls and log important information. This information can help in validating and identifying vulnerabilities like – remote command execution, SSRF, third party calls, path traversal, information leakage and other architecture layer issues. This approach can be expanded to defend a lambda function as well. One can disallow all remote execution calls, block out going traffic, disallow file system access etc. We would like to focus more into vulnerability detection while performing pen-testing or automated scanning. This module can be integrated to any other methodology by common logs with timestamps.

Article by Amish Shah & Shreeraj Shah

lambdaScanner - Scan and Secure serverless lambda functions

'lambdaScanner' is a toolkit which has a combination of scripts for performing penetration testing of lambda functions. The scripts available in the toolkit help assessing the lambda functions from a security standpoint. It helps the tester to discover vulnerabilities in deployment as well as code. It aids in checking vulnerabilities like improper permissions, SQL injections, command executions etc. to name a few. This is not an automated scanner, but a toolkit that helps pen-testers to perform the testing of functions, so it needs to be used wisely by crafting customized requests and payloads. The lambda functions are invoked through various events encompassing AWS like S3, DynamoDB, SQS etc. so the scripts in the toolkit are very helpful in evaluating functions as well as directly testing with various sets of payloads. All these scripts are written in python by using boto3 APIs. The toolkit also has a package called 'lambdaProtect' which can be integrated with an existing lambda function to guard both incoming event stream as well as outgoing response.

This toolkit is "in progress/prototype" and would be enhanced with time by an addition of various functionalities.

Here is a diagram, which describes 'lambdaScanner': -

 

For more detail please visit - here

URL - http://blog.blueinfy.com/p/blog-page.html