• Careers | Call Us: +1 315 215 3290

Blog

  • ^3813EA094755461A44A015B7EF0D64E5A6B205911589A99F1D^pimgpsh_fullsize_distr

    How to set-up Application Security Program

    One of the common concerns I have heard from leadership team at various Product and Enterprise companies has been that they do not know how secure their products or applications are and that they do not see any tangible (or at times even non- tangible) benefits coming out of the application security initiatives in their organization. The primary focus of application security initiatives has been to get the vulnerability assessments and pen test done at defined intervals and the remediation efforts are followed in an ad-hoc manner. This cycle keeps on going and strongly builds the perception that ensuring application security is a necessary evil and that application security initiatives are revenue black-hole.

     
    I have always recommended to my clients (of all sizes) to look at setting up application security program to ensure that the above concerns are addressed and they get greater value. Before I go further with defining the way to set-up an application security program in your organization, let’s understand the benefits of setting up such a program. They are as follows:

     

    • To apply governance and achieve the alignment of application security programs with business objectives

      Put the required Structure, Process and Procedure – Governance will include a set of metrics to indicate the health and progress of the application security program. This will ensure that the Security programs are assessed on regular intervals to ensure that it’s aligned to the Business objectives

    • To better align with compliance requirements

      Continuous validation of alignment with compliance requirements ensure that there are no surprises and application security is not just a checklist entity

    • To assess better

      Regular review of the effectiveness and efficiency of the program and thereby ensuring that there is accountability

    • To utilize your finances effectively and responsibly

      Helps to track costs and follow risk based approach to better prioritize the application security initiatives as per business objectives

    • To give better view to top management and get their support

      Gives your top management clear view of the outcomes (both tangible and non-tangible) of the program and this helps in better decision making and support. Security leaders can use application security maturity model to give a view of the current state of security and build business case for further investments

    • To setup continuous improvement process

      Application security is no more seen as one time activity but as continuous improvement process to improve the security posture of the organization

     

    Now that we understand the benefits, let’s understand that, how we go about setting up an application security program. Following is the 5 steps process to set-up your application security program:

     

     

    Step 1: Plan

     

    Following activities need to be performed as part of Planning
    • Where you stand and where you want to go:

      Assess the current and target state using a security program maturity model. Recommend to use the Open Software Assurance Maturity Model (SAMM)

    • Take a stock of how many applications you have and which are the most important applications

       

      • Create an inventory used with your organization

      • Using risk based approach (based on their business importance, compliance requirements, risk exposure etc.) rank the applications as their priority.

    • Identify the critical applications (identified from above step) to be put under the application security program

      Don’t go with “Big Bang” approach. Take a limited number of critical applications, apply application security program, show the value and then plan to expand!

    • Establish your application security policy covering policies w.r.t identity and access management, data protection, infrastructure protection, logging etc.

    • Security Tools and methodologies standardization

      Standardize the tools that will be used for the application security protection. This would involve identifying the tools in areas of SAST, DAST, WAF etc.
      Select the framework and methodologies that will be used for all applications in your organizations. These can be:
       

        • Security maturity model

        • Threat modelling

        • Verification

      • Create the security coding guidelines document that will serve as baseline for all applications in your organization. Applications having specific compliance, standards requirements may expand the baseline document as required.

         

          • Security coding guidelines that vendor is expected to follow

          • Access management policies

          • Right to audit clause.

     

    Step 2: Define

     

    Next is to define the secure SDLC process for the SDLC methodologies you are using.

    Following are the secure SDLC process for the top 2 SDLC methodologies:
     

    Secure SDLC for Water-fall Model:

    Here is how the Secure SDLC process would go.

     

    Picture1

     

    • Requirements Gathering – Time to capture what you want. This is the most important phase where security needs to be incorporated. Unfortunately, in real world, it is not the case. How can security be incorporated in any product or application when the security requirements were never documented in your Requirements document. Security is not an “implied” phenomenon but an explicit one and the same thinking need to be applied at all stages of your SDLC. Security requirements should be documented in detail in your requirement document covering not just the standard application security models but also the requirements unique to your industry. For example, an application processing credit card data will have its unique application security requirements related to PCI DSS compliance.

    • Design – Time to lay out the blue print of your expected solution. This is where you can perform a risk assessment of your application or product by performing a process called “Threat Modelling”. This can be applied even before writing a single line of code. Threat modelling helps to abstract your application functionalities to understand the top risk for your application. This is done by identifying the threats and vulnerabilities that may exists based on the nature of your application. Once the risks have been identified, the appropriate countermeasure can be identified and implemented during the implementation phase.

    • Implementation – It’s building time. Apart from the functional implementation, the security requirements captured in your requirements document and the countermeasures identified for risks will need to be implemented during this phase. This is the phase where developers should continuously be performing the source code scanning using the SAST (Static Application Security Testing) tools. These tools are typically plugged into your IDE used for development. Security code review is performed as well.

    • Testing – It’s Testing time. By this time if you have followed the above three stages properly, you will have a smooth flow. But in real world this is phase where attentions start coming in for security and this may be late if the secure SDLC processes were not applied. This is phase where testers use DAST (Dynamic Application Security Testing) tools to find the vulnerabilities in code. The vulnerabilities are reported to developers to fix them and typically these vulnerabilities number run in hundreds. This leads to phase where clients face 2 major challenges:

    – Firstly, the Client is left with the dilemma of which vulnerabilities to fix. “Fix All” may not be the option available based on the timelines and resource availability. A “risk based” approach is needed to assess and rank the vulnerabilities based on impact and probability.

    – Secondly as the pressure to close those vulnerabilities in defined timelines mounts, developers face an uphill task. One major challenge for developers arises due to lack of knowledge or capabilities to fix those security vulnerabilities. Addressing Security vulnerabilities need a good understanding of the nature of the vulnerabilities and the appropriate solution. Availability of reusable libraries and specialized application security members will help

    • Release – Time to have your application put to real use. This phase typically is handed over to the deployment team. Security is addressed mainly in ensuring that the servers on which applications are deployed are hardened. It is therefore recommended that a penetration testing is performed on application ideally during the testing phase rather than performing it after the application is live. Also, an assessment of various infrastructure components (web servers, DB, application servers, load balancers) should be done to ensure that the support infrastructure are security compliant.

     

    Secure SDLC starts from requirements phase and not from testing phase

    Below is the detailed secure SDLC transformation process covering the key activities, deliverables, tools, and phase exit norms for various phase of secure SDLC for water-fall model.

     

    Picture2

     

    Picture3

     

    SDLC for Agile Model:

    I would recommend to use the Microsoft Security Development Lifecycle for Agile Development. This lifecycle nicely puts the various security practices under three categories: Every-Sprint practices, Bucket practices, and One-Time practices

     

    Every-Sprint Practices-

    remaining

     

    Bucket Practices-

    bucket

     

    One-Time Practices-

    one time

     

    MS also provides a comprehensive developer kit for handling various security practices. This developer kit includes the best practices, checklist, training guide and approaches for performing threat modelling, secure design principles, code analysis, fixing critical vulnerabilities etc.

     

    Step 3: Execute

     

    It’s Execution time! The Secure SDLC process defined in Step No.2 needs to be applied for applications taken up for applying application security program in Step No.1

    Key points to consider during this step to ensure a successful execution are as follows:

     

    • Continuous engagement with key stakeholders associated with the program. This involves the project sponsor, project team, project manager etc. This will ensure that the right efforts are put by these various stakeholders and the team is aligned to the Secure SDLC processes

    • Provide the right tools and knowledge for your developers to ensure that Security is taken care of during the development phase. Developers already face tremendous pressure to deliver the functionalities and they may not have the motivation and time to ensure that security is addressed. What if you provide them proven reusable libraries that help you to fix those vulnerabilities? OWASP ESAPI is one such useful library to bank on

    • Continuous engagement with key stakeholders associated with the program. This involves the project sponsor, project team, project manager etc. This will ensure that the right efforts are put by these various stakeholders and the team is aligned to the Secure SDLC processes

    • Meticulously follow and track OWASP Application Security Verification Standard (ASVS) to evaluate your application security controls against well-defined verification requirements for various verification levels

     

    Step 4: Measure

     

    I would recommend two software security maturity models to measure the efficiency and effectiveness of your application security program. They are:

     

     

     

     

     

    As per OWASP “These models help in the assessment, planning and implementation of a software security initiative for the organization. These maturity models are explicitly designed for software security assurance. These models, even if are based upon empirical measurements, are feed from real data (e.g. software security surveys) hence allow to measure organizations against peers that already had implemented software security initiatives. By allowing their organization’s secure software development software practices to be measured using these models, CISOs can compare their organization secure software development capabilities against other software development organizations to determine in which software security activities the organization either leads or lags.”
     

    Step 5: Report

     

    The key concerns of top management w.r.t the application security initiatives are:
    • Lack of clarity on the effectiveness and efficiency of the application security initiatives

    • Do not have clear answer as to how secure their products or applications are

    • Do not see tangible benefits

    • Application security is considered an IT issue rather than a business issue

    • Get breached despite huge investments on application security initiatives

     

    Hence it becomes very important to ensure that the top management is given view of metrics that addresses the above concerns. Step 4 output will provide a good amount of data to feed into the report.

     

    OWASP provides a good set of metrics that can be used for reporting to top management. It’s available at:

    CISO AppSec Guide

     

    Another good resource is from SANS:

    SANS report on Using Metrics to Manage Your Application Security Program

     

    Securing your SDLC is a continuous process and not a one-time activity. Secure SDLC starts from requirements phase and not from testing phase. Let your application security be your enabler and differentiator!

     

     

    About the Author:

    Nitesh
    Nitesh carries a deep passion for the information security space. Nitesh is the Founder and CEO of Sacumen, a focused and niche Security Product engineering and Services Company. Nitesh has spent more than a decade in the Security space and carries multiple prominent security certifications such as C|CISO, CISA, CISM, CGEIT, CISSP, CSSLP, CEH, ISO 27001 LA, CCSK and HCISSP. Nitesh is on a mission to transform the perspective of IT security from a FUD (Fear, Uncertainty and Doubt) perspective to having IT security being harnessed as an enabler and differentiator.
    Follow me on linkedin-badge linkedin-badge linkedin-badge


    Sacumen specializes in developing security products and solutions, securing products and applications through application security assessments, and providing Managed security services. For more details of our application security service offering, please visit our Application Security Page.

     

    Contact Us

    Leave a comment