Open Close

Using 80/20 rule in Application Security Management

FacebookGoogle+LinkedInDiggEmailRedditStumbleUponPinterestDeliciousShare/Save

80/20 rule (also known as Pareto Principle) is one of the most beautiful rules which helped me to achieve as well as fail. In most of the cases where I went wrong it finally turned out to be figuring out the “right few”. This is probably one of the most elusive rules. It is easy to understand but extremely difficult to practice.

#1: Know yourself before your enemy does.

I remember in a recent conference the speaker asked the audience (mostly large enterprise security heads): How many of you know the exact number of Applications you have in your organization? Only one hand went up. Very few of the large organization security teams know the number of Application they have and the respective Application owners. So the first most vital thing is to know the following:

  • How many Applications do you have?
  • Who are the respective Application owners?

(Read More:  Beyond Secure Software Development Life Cycle (SDLC) : Moving Towards Secure Dev-Ops)

The next most important thing is to classify the applications based on business criticality. Though the classification of applications can differ business to business, the following could be the approach which would work for most of the organizations.

  • High Criticality: If such applications are down/compromised, will cause direct loss of business (or may cost your job)
  • Medium Criticality: May cause embarrassment but not significant business loss
  • Low Criticality: Will neither cause embarrassment nor loss of business

#2:  Create a regular Testing Strategy

I strongly believe that Application Security Testing is the first most critical element towards securing our Applications.  Prevention strategies have been adopted quite late by the industry. So even though the wise says “Prevention is better than Cure”, we first need to cover the past mistakes.

The first step towards this is to define the type of tests you want to conduct. We can define the type of testing into 3 classes:

  • Basic i.e. Low Quality Testing (Automated): It is basic testing with very high False Positive (Vulnerabilities reported but not true) as well as very high False Negatives (Missed Vulnerability)
  • Standard i.e. Medium Quality Testing (Automated+ Minimal Manual Validation):  Low False Positive but High False Negatives
  • Premium i.e. High Quality Testing (Automated + Extensive manual Validation):  Low False Positive and Low False Negatives

Free Download:  Business Logic Vulnerabilities Checklist

You can check out the above definition in a very interesting model which we developed.

The next step is to create your security testing strategy for the applications of the following type:

  • High Criticality: Premium Testing during every release
  • Medium Criticality: Standard testing during every release and Premium Testing once a year
  • Low Criticality: Basic Testing every quarter/6 months

#3: Create an effective Patching/Remediation Process

Patching is more important than finding vulnerabilities. In our experience of conducting tests for more than 300 organizations, we found that this is an area which is widely misses out in effectiveness. It is quite a big pain to convince the developers why something is a vulnerability.

Depending on your team size you need to outsource (whichever elements possible) so that your team can focus on effective remediation. Testing is easy to outsource. Code fixing is not, unless you have already outsourced the entire development.

Creating an effective program to detect vulnerabilities, assign them for fixing, tracking them until they are closed is probably the most vital element.

#4: Implement Web Application Firewall for Applications of “High Criticality”

It takes time to detect and fix vulnerabilities. Having a Web Application Firewall is very essential for applications which are classified as “High Criticality”. You can also think beyond and implement Security Incident Management (SIM).

#5:  Implement Secure SDLC (Software Development Life cycle)

Prevention is better than cure. You need to have a secure SDLC (Software Development Life Cycle). Having the big bang approach is quite tough. You may think of having a complete transformation. However, there is no harm in starting small. Just start with a minimal coding guideline and a minimal testing (at least automated) during every release.

(Read More:  SAST vs DAST: What should you choose?)

Top steps towards securing SDLC

  • Phase 1:Create a minimal coding and designing guideline

- Implement,Monitor and Measure

  • Phase 2:Create a more advanced coding and design guideline
  • People are resistant towards change and there is adoption overhead.Do not try everything in one go.
  • Select the top 20% of guidelines which will help you the most in Phase 1
  • Consider Phase 2 as your goal.Phase 1 is your step towards achieving the goal.

Advertisement:

application security management

Leave a comment

All fields marked (*) are required