[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] - Enhancing Security Posture of a Product with Multiple Versions and Deployment Models

Background
ACME Inc., one of the data analytics company, offers a robust product providing flexibility of customization. The product is designed to provide multi-tenant support, ensuring seamless deployment in the cloud environment. To cater to the specific needs of its customers, ACME also offers the product under an on-premise deployment model. The company supports feature customization and custom feature development to meet the unique requirements of its customers.

The customization offered by ACME for their product help them gain a high level of customer retention. However, this flexibility comes with a cost of maintaining multiple versions and builds of the same product. ACME faces significant challenges in maintaining the security posture of its product deployments. A scenario where different customers use different build versions with different features and third-party integrations, makes it difficult to ensure consistent security across the board.

Challenges Presented to Blueinfy

1. Maintaining Security Posture: Ensuring the security of every version/deployment of the product due to the nature and architecture of the product (to add the problem, there is no real good documentation of the deployed features which is expected for any product company).
2. Vulnerability Management: Identifying and managing vulnerabilities in the core engine and specific build versions during secure code reviews because different versions have mutually exclusive features and use different third-party libraries.
3. Customer Impact Identification: Identifying which customers are impacted by specific vulnerabilities and sharing patches/upgrades with them.
4. Prioritizing Development Efforts: Determining the most vulnerable components and prioritizing the development team's efforts to fix higher-risk areas of the product.

Solution by Blueinfy

ACME Inc. engaged Blueinfy to address these challenges. Blueinfy implemented a comprehensive strategy leveraging their security expertise and advanced tools.

1.  Automated Code Scanning

• Used a Static Application Security Testing (SAST) tool to scan the code of each version of the product
• Execute Software Composition Analysis (SCA) to scan third-party dependencies for security vulnerabilities

2.  Result Management and Comparison with Custom Automation Script

• SAST tools traditionally manage and triage vulnerabilities of individual scans and some provide facilities to compare results of multiple scans
• In this specific scenario, result comparison and analysis were required to be drilled down to the product’s specific version and source code component level
• Blueinfy team developed custom scripts to automate the process of running code scans, extracting results, managing version and component-specific scan results, and aggregating scan results to generate pivotal metrics

3.  Unique Vulnerability Extraction and Risk Rating

• Leveraging their security expertise and programming knowledge, Blueinfy team automated the process to extract unique vulnerabilities
• Developed a system to risk-rate product versions based on the identified vulnerabilities and their number of occurrences, aiding in setting priorities

4.  Vulnerability Data Analysis

• Performed data analysis to segregate vulnerabilities based on CVE/CWE, product components, libraries, and severity
• Integrated the CISA Known Exploited Vulnerabilities (KEV) catalog with the data analysis script to identify product dependencies with known exploited vulnerabilities and prioritize dependency upgrades

5.  Statistical Metrics to Support Decision Making

• Generated various metrics to showcase the most common vulnerabilities, product components with critical and high severity vulnerabilities, most vulnerable dependencies, clients at risk with product versions having severe vulnerabilities, and more such pivotal matrices
• Provided visual and data-driven insights to make decision-making easier for the ACME team

Impact and Results
The comprehensive approach adopted by Blueinfy yielded significant results for ACME Inc.:

1. Risk Rating and Strategic Decisions: The company was able to risk rate their product versions effectively. This risk rating facilitated strategic decisions regarding time and cost investment across different product versions.
2. Focused Development Efforts: By identifying the most vulnerable components and prioritizing them, the ACME team could allocate development resources more effectively, addressing higher-risk areas promptly.
3. Enhanced Security Posture: Improved the identification and management of vulnerabilities, enhancing the overall security posture of all product versions.
4. Improved Customer Impact Management: With a clearer understanding of which customers were impacted by specific vulnerabilities, ACME company was able to share patches and upgrades more efficiently, leading to increased customer trust and satisfaction.

The engagement with Blueinfy enabled ACME Inc. to overcome significant challenges in maintaining the security posture of their product. The automated processes, comprehensive analysis, and strategic insights provided by Blueinfy not only improved security management but also facilitated better decision-making and resource allocation. This case study highlights the importance of working experience with advance tools and expertise in managing security for product environments with multiple versions.

Article by Maunik Shah & 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

Authentication and Authorization Security Controls – Code Analysis

Authentication

Applications are running on the server and usually serving browsers. Application authentication is form based and done over HTTP. There are several layers involved in the authentication process and each layer should have their own security protections. There are several different authentication mechanism available on application like NTLM, Basic, Digest, HTML Form based, LDAP, Certificate based etc. Authentication is has two aspects in web based application one is authenticating user and second is making a tunnel or channel for authenticated user since HTTP itself is stateless protocol. Various different authentication controls help in protecting application and if any of the control is missing or poorly written then it opens up severe vulnerability in application. Here is a list of possible issues or vulnerabilities

1.) Authentication disclosing sensitive information
2.) Not having auditing on the authentication
3.) No user lockdown policy in place
4.) Authentication bypass (SQL / LDAP interface)
5.) Password strength is poor
6.) No deployment of CAPTCHA or similar identification product
7.) Credential are not securely transmitted
8.) Credential are stored on client side which can be retrieved
9.) Authentication token or cookies are not well crafted
10.) Single Sign On (SSO) can be abused
11.) Deliberated backdoors are created
12.) Hidden fields and information exposure

Authentication controls are part of application code and it is imperative to analyze full mechanism in detail. This layer of code can help in identifying possible loopholes. Authentication is very critical for sensitive and transaction based sites like banking, trading or mailing system. An attacker can bypass authentication and can take hold of full session, it gets opportunity to advance hacking from there. Over years we have seen popular attack vectors as below

1.) Brutefocing
2.) Cookie theft and replay
3.) Authentication injections with SQL/LDAP
4.) Network eavesdropping and malicious codes
5.) Dictionary attacks
6.) Exploiting backdoors
7.) Hidden data manipulation
8.) Local store and information theft

Above attack vectors can help in exploiting the application and these attacks are easy to carry out using different frameworks. Source code can be written in the most secure fashion to protect against above attacks.

Authorization

Once user gets authenticated next thing is to maintain authorization through out the application. Authorization on the application get maintained using proper access control lists (ACLs). Application runs on HTTP and being a stateless protocol, session tokens are required to maintain authorization. There are several issues which can make entire application weak with authorization perspective and that can lead to exploitable security vulnerability. Here is possible weak area in the application for authorization,

1.) Session tokens are insecure
2.) Weak authorization mechanism
3.) Client side tampering and manipulation possible
4.) Possible data and SQL injections
5.) Access to system level bypass
6.) Single place authorization bypass
7.) URL forcing and manipulation
8.) Guessable resources and access
9.) Role-based bypass exploitation and weakness

Above weakness opens up several different set of vulnerabilities. These vulnerabilities can give access to various resources and opens up larger attack surface. Attacker or hacker can launch various attacks and exploits against target application. Here are list of popular attack vectors,

1.) Elevation of privilege
2.) Confidential data leakage
3.) Data tampering
4.) Session hijacking
5.) Session token exploitation
6.) Authorization injections
7.) URL bruteforcing
8.) Clients side reverse engineering and exploits

Above attacks are very popular against applications with respect to authorization. One needs to analyze logic in detail to detect authorization based vulnerabilities.

Validations and Error Handling – Security Controls

Input Validations

Almost 90% of vulnerabilities arise out of having poor or no input validations at the entry point of the application. There are countless different vulnerabilities of input validation type out there and applications are exploited by attackers. Essentially when developers are not treating each input as evil then it gets consumed directly into the application and exposing business logic with severe payload. These injections can force application to go into vulnerable state. Here are possible set of vulnerabilities arising out of poor input validation in the code.

1.) Various injection vectors (SQL, LDAP, XPATH etc.)
2.) Cross Site Scripting (XSS)
3.) Cross Site Request Forgery (CSRF)
4.) Buffer overflows
5.) Integer and logical boundary overrun
6.) Canonicalization issues
7.) Validation bypass (Client side)
8.) Serialization attacks
9.) Information leakage

Input validation is very easy to detect since application usually breaks and send abnormal response back to client. This response contains some signature which helps in detecting type of vulnerability. Attacker or tester usually does fuzzing to determine state of validation. This is one of the most important domains for application security.

Data Validations

Application needs place to store and access data from the system. Application may be using various data sources like database, file system, third part application, cross domain calls/APIs, browser memory etc. All these sources can be manipulated by attacker and it can help in stealing information or manipulating behavior of the application. In era of Web 2.0 applications are not running in isolation with single domain, applications are interlinked and share information seamlessly in-between. Application data is no longer restricted to database and dataset, we are seeing data get exchanged in XML, RSS feed, JSON etc. Application need to validate this data before consuming. Here is a list of weak area in the application which can lead to possible vulnerabilities,

1.) Proxy injections from third party stream
2.) XSS injection with RSS feeds
3.) Client side logic bypass
4.) Upload/download stream injections
5.) Remote command/code injection and execution
6.) Callback manipulation in JavaScript

Data validation is becoming equally important like input validation, it is imperative to validate any stream before consuming either on server or client side. We are seeing new ways of hacking and attacking in this area once code is not developed securely.

Error Handling

Error and exception handling is very important aspect of the development process. Many applications are written without having strong and central error handling routine in place. If error is not handled properly then it can lead to information leakage, Denial of Services (DoS) etc. Here is the list of possible security vulnerabilities arising due to poor error handling,

1.) Information leakage
2.) Logic bypass
3.) Internal logic and routine disclosure
4.) Denial of Services (DoS)
5.) Stack trace enumeration

There are several best practices need to be followed in source code for error and exception handling and some of the popular attack vectors to exploit error handling routines are as follows.

1.) Fuzzing and fault code injections
2.) Denial of Services injections

Automated scanners and engines detect vulnerabilities based on error signatures and this information proves very useful for them. Error handling is responsible for over 90% of information leakage.

Business Logic, Session and Crypto – Security Controls

Business Logic Handling

Business logic is core of any application; if any loophole in business logic is identified by an attacker then it can lead to sever set of vulnerabilities. Logical handling with input validation can prove a dangerous cocktail. Business logic vulnerabilities are hard to identify and needs good understanding of source code. Logical decision making blocks are usually suspects for this range of vulnerabilities. Some common logical issues in the source are as follows

1.) Data type bypass
2.) ACLs manipulation
3.) Read/Write access
4.) Privilege escalation on application layer
5.) API abuse
6.) Cross Domain Call and API manipulation
7.) Client Side Logic reverse engineering

We have seen as lower hanging fruits (LHF) are getting exhausted on the application, hackers move on to find something else and logical vulnerabilities is one of the crucial domain they would like to hack in. Lot of secure coding measures is required to protect the application with respect to business logic bugs and vulnerabilities.

Session and Identity Handling

Session management and unique identity handling are very important aspect of web applications. Web applications runs on HTTP protocol and one of the fundamental limitations of this protocol is its non-statefulness. HTTP can not maintain state of network and over period several different mechanisms are developed like URL rewriting or cookie based access. If there is a loophole in session management then it can lead to key vulnerability which can be exploited to gain unauthorized access on the system. Here is a list of possible issues

1.) Session hijacking by eavesdropping
2.) Man in the middle attack
3.) Poor session identifier generation
4.) Browser hacks like XSS to gain cookies
5.) Predictable session identifier
6.) Session bypass and access
7.) Cookie scope and time abuse
8.) Abusing URL rewriting
9.) Local session storing access

Session handling is closely linked to both authentication and authorization layer as well. It can be complex in nature as well when comes to deployment. It is becoming increasingly interesting with Web 2.0 applications and lot of session management required for various different streams as well.

Crypto and secret handling

Cryptographic usage is another important aspect of modern day’s applications. Application needs to keep certain data and information very secret. Many times application data get used by internal users as well and it should not be accessible in clear text either. Application’s crypto usage need to be evaluated thoroughly as well and some of the vulnerabilities or weak area are as follows in this particular domain,

1.) Poor key generation
2.) Database fields are not well encrypted (password, social security number etc.)
3.) Poor encryption (customized)
4.) Checksum spoofing
5.) Some secrets in source code itself
6.) Configuration file containing secrets
7.) Secret getting revealed in error message or some other means

Source code assessment can help in identifying any weak area in crypto and managing secret. This domain is another very critical area of application.

Input validation – First line of defense

Input validation is one of the most critical parts of application with security perspective. Most of the common issues like SQL injection or XSS come into existence with not having proper validation at the input layer. We have seen there are several entry points to the application over HTTP and each of these entry points need proper validation before consuming the value into the business logic. By having strong input validation can help in reducing severe threats and protect logic as well.

An attacker tries to induce faults in the application by doing fuzzing on HTTP inputs and if validations are not in place then application breaks giving vital clue and information out. There are several different types of validations required and based on the validation application works. Here is a list of popular validations

1.) Size and length validation
2.) Data type validation
3.) Meta character validation
4.) File type validation
5.) Data ranges

HTTP protocol is all string and there are no bifurcations for type of data. Hence, it is up to developer to validate the content before consuming in the application. If at design level central validation control is not designed then developer would take input and process in the business logic. Not having right input validation can lead to logical bypass and several other issues and vulnerabilities get injected. Input validation is one of the most fundamental requirements for the application and it acts as first line of defense in the source code.

There is range of different possible injections which can help in disrupting the logic.

1.) SQL injection
2.) File system access injection
3.) Remote command execution
4.) XML poisoning
5.) Source code injection
6.) LDAP etc.

Here are the characters which can cause this type of injections in the application if code is not validating it.

Attack vector	Possible characters or string
XML poisoning	Recursive same pattern as part of attacks
Parameter tampering (Characters)	double quotes (“), single quote (‘), ampersand (&), percentage (%)
Parameter tampering (Data type)	Data type mismatch.
Parameter tampering (Abnormal values)	Large or negative value causing EOF/BOF
SQL injection	single quote (‘), double quotes (“), hyphen (-) , “or 1=1”.
XPATH injection	slash (/), double slash (//), dot(.), double dot (..), @, =, <, >, *, “’ or 1=1 or ”=’” as attack strings
LDAP injection	bracket (“(“) and *
Directory traversal and File system access	Dot dot slash (../), “../../../etc/passwd”, ../../../autoexec.bat.
Operating System command execution	Pipe (|)
Brute forcing	Multiple requests from the same IP address
Buffer overflow	Large-sized buffer injection.

All above characters can help an attacker to bypass the logic and craft an exploit. Successful injection can be damaging for the application and an attacker can gain rights and access to confidential information to full system as well.

Solution to protect application

There are two broad approaches to protect application against this sort of attack vector.

1.) Applying validation across application – each parameter needs to be validated before consuming into application layer. Set of checks like length, data type, character filters etc. needs to be made before using inside the application. One needs to identify each and every entry point to the application and then apply secure coding across it.

2.) Another approach is putting a module in the application at HTTP layer for validation and it is also known as web application firewall. We are interested in filtering capabilities of it to protect our inputs. This has overhead to the application but getting some momentum in the industry in last few years.

One of the best approaches is to provide protection at the source code level itself so no dependent on any external checks and lock down.

For example here is a simple way of adding rule on .NET framework using built in form capability.

<%@ language="C#" %>

<form id="form1" runat="server"> <asp:TextBox ID="txtName" runat="server"/> <asp:Button ID="btnSubmit" runat="server" Text="Submit" /> <asp:RegularExpressionValidator ID="regexpName" runat="server" ErrorMessage="Valication failed." ControlToValidate="txtName" ValidationExpression="^[a-zA-Z'.\s]{1,40}$" /> </form>

Above code will compare against regular expression shown below.

 ^[a-zA-Z'.\s]{1,40}$

It will take values from a to z and A to Z with maximum length of 40. This way full protection can be applied to the parameter “txtName”.

Similar result can be achieved by applying at source code execution and code is shown below.

 Regex reg = new Regex(@"^[a-zA-Z'.]{1,40}$"); Response.Write(reg.IsMatch(txtName.Text));

 if (!Regex.IsMatch(txtName.Text, @"^[a-zA-Z'.]{1,40}$")) { // Validation failed }

Hence, there are various different ways validation can be achieved at application layer. Objective is not to allow certain values to the application layer.

Software Development Life Cycle (SDLC) for Application Security

Web application software has its own development life cycle and it can be divided into six broad sections like Requirement gathering, architecture, design, implementation, deployment and testing as shown in figure.

Software Development Life Cycle (SDLC) and Security

To protect final application corporate needs to have its own Application Security Cycle (ASC). While application development is going on, the corporate can define certain tasks in parallel to improve quality of end product with respect to security. One of the obvious means to achieve this is proper dissemination of application security knowledge at all levels by means of trainings and related literatures. We are focusing on other aspects of ASC and try to map with SDLC. Let’s see some of the phases of cycle and related security tasks along with tools:

Requirement – Application requirement and higher level goals can be created by corporate with respect to objective, at the same time one can define security policies and controls required to be followed by all during the process.

Tools – Policy documents, Threat and Risk frameworks, corporate guideline

Architecture – Application architecture consists of various different components like web and application server, database, third-party components etc. Application architecture can be laid down on paper along with key information. Once architecture of application is ready one can do its full review with respect to security and their integration points. Many times during this phase some vulnerability can be observed and defense can be put right into architecture layer to have secure application.

Tools – Threat Modeling Tool and Framework

Design – Application design phase contains much more granular interactions and class layout. This is the ideal time to perform full threat model for application for all possible use cases and branches of interactions. This helps in building proper attack profile and respective security controls for application. It also defines future path for developers in the form of remediation guideline and QA team for analysis approaches.

Tools – Threat Modeling Tool and Framework

Implementation – Developers can have best practices and secure coding guideline for application development. These guideline along with threat model helps in making implementation much more secure and countermeasure for all described threats. It is also possible to have security libraries for specific tasks like using AntiXSS for XSS defense and so forth.

Tools – Secure Coding Libraries and best secure coding practices

Deployment – Once application is about to deploy or initial testing is going on at QA one can start doing secure code review on it. Source code can be reviewed by static analysis tools, Instrumentation or related principals. This helps in verifying implementation of policies, controls and countermeasures defined in threat model.

Tools – Source Analysis and Instrumentation Tools

Testing – Security testing of application can be done by using zero knowledge approach if needed to verify on top of source code assessment. It is possible to run various different test cases for testing at protocol layer to determine strength of security along with fuzzing techniques.

Tools – Scanners

During Application Security Cycle (ASC) corporate needs various tools and knowledge base. Stronger cycle leads to better security and can have significant impact on overall architecture, design and implementation.