Introduction to application risk rating & assessment

February 26, 2013 by

arD3n7

Understanding today's threat landscape and looking at the pace with which organizations are adopting secure development practices, there seems to be a huge gap and it will take a longtime for organizations to catch up. It doesn't make any sense for an organization to address every issue simultaneously and achieve nothing at the end of the day. So what is the way forward? How does an organization protect its applications from security threats but at the same time have a strategic way forward? There can be many such questions encountered by management when they take up the burning issue of securing applications.

A single word answer to all our problems is "prioritization."We need to have a clear understanding of the risk profile of our existing applications. There may be other factors based on which we can prioritize securing these applications. We'll limit our scope of discussion only to applications in this article.However, from an organization's perspective, applications are just one set of assets it possess, and there are other such assets which needs to secured as well.

Objective

The aim of this article is to introduce users to a methodical approach to securing an organization's existing applications or products keeping in mind future requirements that a security team will encounter(i.e. securing upcoming set applications). The focus will be on categorization of applications and segregating them into high, medium and low risk applications based on the overall risk rating we'll derive through ahybrid approach discussedin this article.

Approach

In order forus to prioritize our existing applications, the first thing we need is an inventory of applications. Before we jump directly into inventory building, we'll first understand the overall approach that we'll follow throughout this article in order to reach our objective.The following picture outlines the approach that we will follow throughout this article:

Building inventory

Building an inventory is not as complex as it sounds. However, this is a critical step in our process towards achieving the end goal (securing our application's in a phased manner). An inventory could be as simple as an excel sheet or a word document; alternativelyit can be as complex as an organization desires. Anexample could bea dedicated portal for tracking all applications, such as existing, upcoming, and in development applications.

The idea here is to have a complete list of applications for ready reference. If it is maintained as a document, it should be a living document & if it is maintained via a centralized website or portal, the database should be kept up to date with the latest applications being recorded into the DB as soon asthey are identified.

Business criticality

This one is of the most important factors we will consider when choosing which applications to secure first and which one's to prioritize for a later point in time. It is crucial to understand what is important forbusiness. If an application is generating millions of dollars every month for the organization, it is obvious that we secure this application first.

Example

Let's consider the example of an aviation firm: selling tickets online is crucial for their business when compared to securing another internal website for tracking employee payroll data. This does not mean that payroll data is not important. However, if the main website through which the organization is selling tickets is unavailable or compromised, it takes a huge toll on organization's income. Hence, for this organization, maintaining a secure website is as good as being in business.

So what should be done? The first thing we need to do is to have a discussion with Senior Management and categorize the entire inventory based on business impact. The following is a sample categorization of applications for ready reference to users:

• Critical Applications
  • These applications, if compromised can have immediate impact on organization's finances.
• Important Applications
  • These applications, if compromised can have a impact on organization's finance in few days
• Strategic Applications
  • These applications do not have direct correlation with organization's finance, however, if compromised, these applications can indirectly hit the organization's bottom line. For example, defacement of company's website will make a perfect example for bad press and can take a toll on organization's stock eventually resulting in financial hit to the business.
• Internal Support Applications
  • This category covers Intranet facing applications used for a smooth functioning of the organization.Compromises of these applications do not have a direct impact on organization'srevenue; however,they still are important for the organization to function properly. It can be an irritant for the company but not something which can lead to a major loss.

The above categorization is an example and should not be treated as the final one. One may find categorization changes from organization to organization and there is no rule of thumb as to what it should be called, however irrespective of the naming convention in use, the concept remains the same.

Analyze securityrisk posture

Next, we'll categorize applications based on Security Risk. We can create a questionnaire to record the risk posture applications. Evaluations of the same can help us in categorizing Security Risks applicable to these products or applications.

Once we have the information regarding the application recorded, we'll have a better idea of application's risk posture. There will be many questions that we'll have an answer for – from a security analyst's perspective. The following is a sample security questionnaire for the reader's reference, however it is not exhaustive. More questions can be added by organizations on a need to need basis, taking into consideration factors like the industry to which the organization belongs, commercial interest that an attacker may have in compromising their products or applications, etc…

It should be noted that above is a sample questionnaire and does not cover all the information that an organization might want to record; however, it can be used as a basic questionnaire and can be extended over a period of time.

Overall risk categorization of applications

We'll follow a hybrid approach for arriving at an overall risk rating of our inventory. We'll address applications which falls as important for both business and security team and place them at the top of the queue. We'll secure them first and then move on to rest. However, for us to achieve this, we need to utilize the intelligence gathered so far and apply it to the existing inventory. This way we can address business expectations and at the same time walk the tight rope of addressing applications carrying high security risk.

We now have a good understanding of the business criticality as well as Risk Posture of the applications; we will apply this intelligence filter to our application inventory and derive the overall risk category it falls in. This process may not always be objectively in nature and many times a subjective approach needs to be taken.

It should be noted as well that the end result obtained via this process may have to go through this process for multiple iterations. We should get this categorization reviewed by management and check if it meets them expectations. There may be changes based on business expectations.

As shown in above figure, once we apply the intelligence gathered so far, we will have a list of applications categorized in either one of the following categories:

• High Risk
• Medium Risk
• Low Risk

The following table summarizes samples for High, Medium and Low Risk Applications:

Strategic planning for securing these applications

Once we have all the required information, we need to put to gather a plan for securing our applications. Create a project plan with proper timelines based on which security assessment of these applications could be carried out.

If an organization has programs like Secure Software Development in place, this plan can be integrated into the overall program's goal to contribute to the common cause.

What next?

The applications bearing high risk should undergo a security assessment on a priority basis followed by Medium and Low Risk Applications. Based on the available manpower and resources, issues found during the security assessment should be fixed to improve the security posture of these applications.

Security teams have multiple strategies for the security assessment of applications. There is a complete methodology which is utilized for the same. Some security teams rely on automated scanners and focus on covering more applications using these tools – which reduces time and increases the coverage, while some of them rely of manual security assessment, that way coverage is less but at the same time there are few false positives and therefore abetter quality output.

Some security teams believe in having best of both worlds. They utilize both automated security scanners and also perform manual security assessment thus achieving quality throughput from the security assessment exercise and at the same time also increases coverage. This method may be a little slower compared to first approach of going with only an automated scanning.However, it is a recommended method of performing security assessment.

Again, the approach we take can be influenced by management based on the budget availability and need of the hour. So it's okay to start with either approach and align ourselves to industry-best practices at a later point in time.