{{announcement.body}}
{{announcement.title}}

How to Develop a Secure Application

DZone 's Guide to

How to Develop a Secure Application

A step by step approach for an IT leader to build a secure application by integrating Application Security Testing into each phase of the software development life cycle.

· Security Zone ·
Free Resource

What Is the Cost of a Data Breach?

As per the 2019 Cost of a Data Breach Report by Ponemon Institute, sponsored by IBM Security the average total cost of a data breach is USD 3.9 million and it can go as high as USD 8.19 million.  The average size of a data breach is 25,575 records and the cost per record to USD 150. It may take up to 279 days to identify and contain the breach.

Regulators like PCI-DSS, HIPPA have stringent security compliance requirements and Organisations face penalties for non-compliance. This adds a financial burden to the organizations. Apart from financial loss, security breach also results in brand and reputation damage.  

Out of 26 factors studied by Ponemon Institute, Extensive use of encryption, data loss prevention, threat intelligence sharing, and integrating security into the software development process were the key mitigators, which helped organizations to minimize the impact.

This paper provides strategies and best practices to build secure applications to protect organizations from potential threats.

Strategy to Build a Secure Application

The best strategy to develop a secure application is to integrate and automate Application Security Testing (AST) into each stage of the software development life cycle (SDLC). 

Gartner identifies four main AST technologies.

  1. Static Application Security Testing (SAST) technology that analyses an application’s source, bytecode, or binary code for security vulnerabilities.
  2. Dynamic Application Security Testing (DAST) technology that analyses applications in their running state. It simulates attacks against an application (typically web-enabled applications and services and APIs), analyzes the application’s reactions, and determines whether it is vulnerable.
  3. Interactive Application Security Testing (IAST) technology that combines elements of DAST simultaneously with instrumentation of the application under test. The instrumentation agent observes operation or attacks and identifies vulnerabilities.
  4. Software composition analysis (SCA) technology used to identify open-source and third-party components used in an application, their known security vulnerabilities, and license restrictions.

Integrate Application Security Testing (AST) into SDLC

Here are the guidelines to integrate application security into each phase of the Software Development Life Cycle (SDLC).


Requirement

In the requirement phase, the development team gathers customer needs, analyze, validate, and prioritize them. It is important to receive business stakeholder’s approval before moving to the next phase.

Security Considerations:

  • Train the entire team on secure architecture, secure design, secure coding, application threat modeling, and AST vendor tool chosen for the organization. Identifying security flaws at a later stage of the development may delay releases, results in unplanned work, or may result in an insecure application in production.
  • The organization can leverage multiple training platforms provided by the AST tool vendors such as Web-based training, Instructed led training, hands-on playgrounds. 
  • Buy additional AST licenses for your application testing and enable access to the AST tools and reporting system for your team. 

Design

In the design phase, the team defines a high-level solution to meet customer stated (functional) and unstated needs (non-functional). The team evaluates and identifies the right solution from design alternatives to meet the business needs. In complex projects, conduct detailed design and validate it by a prototype before starting the development to avoid any re-work.

Security Considerations:

  • Conduct Application Threat Modelling. This helps to build secure design and Identify security test scenarios/security test cases.
  • Key questions to ask during application threat modeling are:
    • What are we building?
    • What can go wrong?
    • How to handle it?
  • Discuss with the enterprise security team and define the security rules for your application in the AST tool.
  • Evaluate and check if the coding language of your choice supported by the AST tool. In case the language not supported, discuss and take the guidance from your enterprise security team.
  • Please check with the AST tool for the supported IDE and Build server before finalizing the tools for your application development. 

Code

In the code phase, developers implement the features as per the requirements and design guidelines. 

Security Considerations:

  • Install and use the IDE plugin provided by the AST vendor. The IDE plugin scans the code, conducts Static Application Security Testing (SAST) for the created/ modified file, and provides instant feedback to the developer.
  • IDE plugin also identifies severity, flaw type, the line of code where the flaw is located and may suggest remediation steps thus helping the developer to fix the security flaw even before the code is committed.

Build

In the build phase, application source files are bundled together to create a deployable binary file. Modern application development teams leverage CI & CD tools to continuously integrate, build, validate, and deploy applications in different environments.

Security Considerations:

  • IDE plugin scans only the file modified by the developer to provide instant feedback. The recommendation is to run full SAST and SCA for the entire application at the earlier stage.
  • Install and activate the AST plugin on your build server and enable full SAST and SCA as part of the CI pipeline. Build should fail if the application does not pass the SAST and SCA.
  • Developer to analyze, fix the security flaw, commit the code to initiate, and successfully build the application. This helps to eliminate the security flaw even before the application released for QA. 
  • Conducting SAST for your deployable binary file may take from few minutes to hours depending on the size of the binary file. Choose to enable SAST in your CI pipeline only if the binary file is small and it can scan in a few minutes, else it may delay the build and affect the overall productivity.

Test

In the Test phase, the testing team executes test cases to validate if the software built meets both functional and non-functional requirements.

Security Considerations:

  • If you have a large binary file and could not run full SAST and SCA in the build phase, run it in the test phase. Automate the steps to avoid any manual errors and for consistent reporting.
  • Once the application deployed on the QA region, Conduct Dynamic Application Security Testing (DAST) by running security attack test cases against an application.
  • In DAST, only a limited number of test cases executed against the application to simulate the attack and it may not cover all scenarios. To improve the coverage and identify any potential threats conduct Interactive Application Security Testing (IAST).
  • IAST requires the installation of an instrument agent on the application running under test. The IAST agent continuously monitors all your code including your libraries and identifies vulnerabilities. 
  • Developer to analyze, fix the security flaw. This helps to identify potential threats and address them before moving the application to production.
  • Since IAST requires instrumentation of your code, it may degrade application performance. As a best practice, do not conduct IAST on performance or production environments to avoid any performance degradation and potential impact on user experience.

Deploy and Monitor

In this phase, a certified application deployed to production after necessary approvals. Deployed application continuously monitored to ensure it works as expected. 

Security Considerations:

  • Development team to monitor application in production continuously and evaluate that the code fix to remediate security flaws are not degrading the application performance or usability.

Conclusion

Since new security vulnerabilities discovered every day, it is the responsibility of the developer to ensure the application runs optimally and protected from all potential security threats. Even if you do not add any new features to the application, you still need to conduct application security testing regularly and address any new flaws. It is best practice to include security testing and remediation in your maintenance phase.

Apart from incorporating the security best practices in code, one should enable additional controls in place to protect the application in production, particularly for internet-facing applications. Some of the additional controls to consider are – Identity Management, Web Application Firewalls (WAF), Geo-blocking, IP Whitelisting, Transport level security, encryption, etc...

As the saying goes “PREVENTION IS BETTER THAN CURE”, it is better to identify, remediate potential threats and avoid the security breach proactively instead of dealing with financial and reputation loss later. 

Topics:
application security, application security testing, development strategy, devsecops, owasp, secure coding

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}