torehandy.blogg.se - Risk engine application

The following is a sample security questionnaire for the reader’s reference, however it is not exhaustive. There will be many questions that we’ll have an answer for – from a security analyst’s perspective. Once we have the information regarding the application recorded, we’ll have a better idea of application’s risk posture. Evaluations of the same can help us in categorizing Security Risks applicable to these products or applications. We can create a questionnaire to record the risk posture applications. Next, we’ll categorize applications based on Security Risk. 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. The above categorization is an example and should not be treated as the final one. It can be an irritant for the company but not something which can lead to a major loss.

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.

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.

These applications do not have direct correlation with organization’s finance, however, if compromised, these applications can indirectly hit the organization’s bottom line.

These applications, if compromised can have a impact on organization’s finance in few days.

These applications, if compromised can have immediate impact on organization’s finances.

The following is a sample categorization of applications for ready reference to users: 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. Hence, for this organization, maintaining a secure website is as good as being in business. 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. This does not mean that payroll data is not important.

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. If an application is generating millions of dollars every month for the organization, it is obvious that we secure this application first. It is crucial to understand what is important forbusiness. 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. 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. The idea here is to have a complete list of applications for ready reference. Anexample could bea dedicated portal for tracking all applications, such as existing, upcoming, and in development applications.

An inventory could be as simple as an excel sheet or a word document alternativelyit can be as complex as an organization desires. However, this is a critical step in our process towards achieving the end goal (securing our application’s in a phased manner). 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:īuilding an inventory is not as complex as it sounds. In order forus to prioritize our existing applications, the first thing we need is an inventory of 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. 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. 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. There may be other factors based on which we can prioritize securing these 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.