Risk Analysis

Introduction

The objective of a security program is to mitigate risks. Mitigating risks does not mean eliminating them; it means reducing them to an acceptable level. To make sure your security controls are effectively controlling the risks in your environment, you need to anticipate what kinds of incidents may occur. You also need to identify what you are trying to protect, and from whom. That’s where risk analysis, threat definition, and vulnerability analysis come in. What is being protected? What are the threats? And where are the weaknesses that may be exploited?

Threat Definition

Evaluating threats is an important part of risk analysis. By identifying threats, you can give your security strategy focus and reduce the chance of overlooking important areas of risk that might otherwise remain unprotected. Threats can take many forms, and in order to be successful, a security strategy must be comprehensive enough to manage the most significant threats.

How do you know you’re defending against the right threats?

For example, if an software development organization were to simply purchase and install a firewall (and do nothing else) without identifying and ranking the various threats to their most important assets, would they be secure? Probably not. These statistics are from Verizon’s 2010 Data Breach Investigations Report (DBIR), the result of a collaboration between Verizon and the U.S. Secret Service. This is a breakdown of “threat agents,” which are defined in the report as “entities that cause or contribute to an incident.” 

This particular study illustrates the point that insider threats should be an important consideration in any security program. Many people that haven’t seen real-world security breaches don’t know this, so they focus exclusively on external threats.

There are numerous other studies that show different results, including later DBIR reports (because different environments experience different threats, and the threat landscape always changes) but they all point to the insider threat as a serious concern. Security professionals know that many real-world threats come from inside the organization, which is why just building a wall around your trusted interior is not good enough. Regardless of the breakdown for your particular organization, you need to make sure your security controls focus on the right threats. To avoid overlooking important threat sources, you need to consider all types of threats.

This consideration should take into account the following aspects of threats:

• Threat vectors
• Threat sources and targets
• Types of attacks
• Malicious mobile code
• Advanced Persistent Threats (APTs)
• Manual attacks

Threat Vectors

A threat vector is a term used to describe where a threat originates and the path it takes to reach a target. An example of a threat vector is an e-mail message sent from outside the software development organization to an inside employee, containing an irresistible subject line along with an executable attachment that happens to be a Trojan program, which will compromise the recipient’s computer if opened.

A good way to identify potential threat vectors is to create a table containing a list of threats you are concerned about. It is important to understand threat vectors and consider them when designing security controls, to ensure that possible routes of attack for the various threats receive appropriate scrutiny. Understanding threat vectors is also important for explaining to others, such as management, how the protective mechanisms work and why they are important.

Risk Analysis

A risk analysis needs to be a part of every security effort. It should analyze and categorize the assets that need to be protected and the risks that need to be avoided, and it should facilitate the identification and prioritization of protective elements. It can also provide a means to measure the effectiveness of the overall security architecture, by tracking those risks and their associated mitigation over time to observe trends. How formal and extensive should your risk analysis be? That really depends on the needs of your organization and the audience for the information. In a larger, well structured environment, a more detailed risk analysis may be needed. 

A quantitative approach to risk analysis will take into account actual values—the estimated probability or likelihood of a problem occurring along with the actual cost of loss or compromise of the assets in question. One commonly used approach to assigning cost to risks is annualized loss expectancy (ALE). This is the cost of an undesired event—a single loss expectancy (SLE)—multiplied by the number of times you expect that event to occur in one year—the annualized rate of occurrence (ARO).

Annualized Loss (ALE) = Single Loss (SLE) * Annualized Rate (ARO).

But there are problems with the ALE approach. How can you assign ARO to every potential loss? For example, how many times a year will your car be involved in a fender bender? In reality, many years may go by in between accidents, but occasionally you may have two or three accidents in a single year. Thus, your ARO can be highly variable. Even defining SLE can be difficult. How much will a fender-bender cost? It could be anywhere from nothing to several thousand dollars. An analytical mind might be bothered by the variability and ambiguousness of the numbers. In fact, there is a lot of guesswork involved.

Because the results of an ALE analysis are hard to defend, prove, support, and demonstrate, this approach is tending to fall out of favor. However, the basic principle of identifying threats, vulnerabilities, and risks remains valid. 

A qualitative approach to risk analysis, which may suffice in smaller environments or those with limited resources, can be just as effective. In an software development company, You can identify your assets (for example, a web server, a database containing confidential information, workstation computers, and a network). You can identify the threats to those assets (malware, hack attacks, bugs and glitches, power outages, and so forth). And you can assign a severity level to help you prioritize your remediation. If the severity is high enough, you will probably want antivirus capability on the endpoints as well as on the network, a high-quality stateful firewall, a timely patching program that includes testing, and uninterrupted power supplies (UPSs).

Thus, a proper risk analysis should be carried out to mitigate the risk occurring in an organization. 

Computer & Network Policies in Information Security : Part-1

Computer Policies

This group of policies applies to computers and information systems in a software development company. Authentication policies often form the largest collection of policy statements in a computer environment because authentication systems and variations are so complex and because they tend to have the greatest impact on the average computer user. Password policies are often the largest subset of authentication policies. 

• Account/Password Authentication: A unique account and password combination must authenticate all users of information systems. The account name must be used only by a single individual, and the password must be a secret known only to that individual.

• New Account Requests: The manager responsible for a new end user must request access to corporate information systems via a new account. End users may not request their own accounts. The new account request must be recorded and logged for the record. When the account is no longer needed, the account must be disabled.

• Account Changes: The manager responsible for the end user must request changes in access privileges for corporate information systems for a system account. End users may not request access-privilege changes to their own accounts. The request must be recorded and logged for the record. 

• Two-Factor Authentication: All administrators of critical information servers must be authenticated via a token card and PIN code. The individual must be uniquely identified based on possession of the token card and knowledge of a secret PIN code known only to the individual user.

• Desktop Command Access: Access to operating system components and system administration commands on end-user workstations or desktop systems is restricted to system support staff only. End users will be granted access only to commands required to perform their job functions.

• Generic User Accounts: Generic system accounts for use by people are prohibited. Each system account must be traceable to a single specific individual who is responsible and accountable for its use. Passwords may not be shared with any other person. 

• Inactive Screen Lock: Computer systems that are left unattended must be configured to lock the screen with a password-protected screensaver after a period of inactivity. This screen locking must be configured on each computer system to ensure that unattended computer systems do not become a potential means to gain unauthorized access to the network. 

• Login Message: All computer systems that connect to the network must display a message before connecting the user to the network. The intent of the login message is to remind users that information stored on the organization’s information systems belongs to the organization and should not be considered private or personal. The message must also direct users to the corporate information system usage policy for more detailed information. The message must state that by logging on, the user agrees to abide by the terms of the usage policy. Continuing to use the system indicates the user’s agreement to adhere to the policy. 

• Failed Login Account Disabling: After ten successive failed login attempts, a system account must be automatically disabled to reduce the risk of unauthorized access. Any legitimate user whose account has been disabled in this manner may have it reactivated by providing both proof of identity and management approval for reactivation. 

• Password Construction: Account names must not be used in passwords in any form. Dictionary words and proper names must not be used in passwords in any form. Numbers that are common or unique to the user must not be used in passwords in any form. Passwords shorter than eight characters are not allowed. 

• Password Expiration: Passwords may only be used for a maximum of 3 months. Upon the expiration of this period, the system must require the user to change their password. The system authentication software must enforce this policy. 

• Password Privacy: Passwords that are written down must be concealed in a way that hides the fact that the written text is a password. When written, the passwords should appear as part of a meaningless or unimportant phrase or message, or be encoded in a phrase or message that means something to the password owner but to nobody else. Passwords sent via e-mail must use the same concealment and encoding as passwords that are written down, and in addition must be encrypted using strong encryption. 

• Password Reset: In the event that a new password must be selected to replace an old one outside of the normally scheduled password change period, such as when a user has forgotten their password or when an account has been disabled and is being reactivated, the new password may only be created by the end user, to protect the privacy of the password.

• Password Reuse: When the user changes a password, the last six previously used passwords may not be reused. The system authentication software must enforce this policy. 

• Employee Account Lifetime: Permanent employee system accounts will remain valid for a period of 12 months, unless otherwise requested by the employee’s manager. The maximum limit on the requested lifetime of the account is 24 months. After the lifetime of the account has expired, it can be reactivated for the same length of time upon presentation of both proof of identity and management approval for reactivation. 

• Contractor Account Lifetime: Contractor system accounts will remain valid for a period of 12 months, unless otherwise requested by the contractor’s manager. The maximum limit on the requested lifetime of the account is 24 months. After the lifetime of the account has expired, it can be reactivated for the same length of time upon presentation of both proof of identity and management approval for reactivation. 

• Business Partner Account Lifetime: Business partner system accounts will remain valid for a period of 3 months, unless otherwise requested by the manager responsible for the business relationship with the business partner. The maximum limit on the requested lifetime of the account is 12 months. After the lifetime of the account has expired, it can be reactivated for the same length of time upon presentation of both proof of identity and management approval for reactivation. 

• Same Passwords: On separate computer systems, the same password may be used. Any password that is used on more than one system must adhere to the policy on password construction. 

• Generic Application Accounts: Generic system accounts for use by applications, databases, or operating systems are allowed when there is a business requirement for software to authenticate with other software. Extra precautions must be taken to protect the password for any generic account. Whenever any person no longer needs to know the password, it must be changed immediately. If the software is no longer in use, the account must be disabled. 

• Inactive Accounts: System accounts that have not been used for a period of 90 days will be automatically disabled to reduce the risk of unused accounts being exploited by unauthorized parties. Any legitimate user whose account has been disabled in this manner may have it reactivated by providing both proof of identity and management approval for reactivation. 

• Unattended Session Logoff: Login sessions that are left unattended must be automatically logged off after a period of inactivity. This automatic logoff must be configured on each server system to ensure that idle sessions do not become a potential means to gain unauthorized access to the network. 

• User-Constructed Passwords: Only the individual owner of each account may create passwords, to help ensure the privacy of each password. No support staff member, colleague, or computer program may generate passwords.

• User Separation: Each individual user must be blocked by the system architecture from accessing other users’ data. This separation must be enforced by all systems that store or access electronic information. Each user must have a well-defined set of information that can be located in a private area of the data storage system. 

• Multiple Simultaneous Logins: More than one login session at a time on any server is prohibited, with the exception of support staff. User accounts must be set up to automatically disallow multiple login sessions by default for all users. When exceptions are made for support staff, the accounts must be manually modified to allow multiple sessions.

All the software companies take into account the above mentioned points for the Computer Policies to ensure the Information Security in an organization or a firm for mitigating the risk against the unauthorized entity.

Author Signature - Venu Majmudar

Incident Management process in IT Organizations

Security incident means any harmful activity which can lead to negative impact to company’s tangible or intangible assets. It is a compromise or violation of an organization’s security eg. it can be a software development company. An incident can range from anything outage such as a power or hardware failure to the incidents such as a violation of organizational policy by disgruntled employees or being hacked.

Incident management  is the activities of an IT organization to identify, analyse, and correct hazards to prevent a future re-occurrence of it. Incidents within an organization are normally dealt with by either an Incident Response Team (IRT), or an Incident Management Team (IMT). These team work to restore normal functions of the company.

When any incident occurs IRT take some basic steps and those steps are preplanned. They are;

1. Preparation

This phase  deals with the pro-actively preparing a team to be ready to handle an incident. The following should be performed :

• Response Plan/Strategy
• Communication
• Documentation
• Access Control
• Training

2. Identification

This phase deals with the detection and determination of whether there is a deviation from normal operations within an organization, and its scope assuming that the deviation is indeed an incident. This step includes one to gather events from various sources such as past reports, error messages, log files, and other resources, such intrusion detection systems and firewalls. That may produce evidence as to determine whether an event is an incident. If a particular event is determine to be an incident then it should be reported immediately in order to allow the team enough time to collect evidence and prepare for the preceding steps.

3. Containment

The purpose of this phase is to limit the damage happened and prevent any further damage from happening. Basically the focus of this step is to limit the damage as soon as possible and take actions which are corrective.

4.  Eradication

This phase deals with the removal and restoration of affected systems. Antivirus and other corrective software will be used.

5. Recovery

The purpose of this phase is to bring affected systems back into the production environment carefully ensuring that it will not lead another incident. The system is  tested, monitored, and validated that are being put back into production to verify that they are not being re-infected by malware or compromised by some other means.

It is not necessary in every incident there will be a disciplinary action which should be taken. It depends on what kind of breaches happened after the incident took place. How incident impacted the CIA of the information asset of the organization, and what is the criticality of incident, depending on that disciplinary actions should be taken.

Information security incident management process:

1) Corrective Action of the incident

2) Identification and reporting of the incident.

3) Classify the incident i.e critical, moderate, high or low

4) Identification of stakeholder who all should be involved for managing the incident

5) Root Cause Analysis of the incident

6) Preventive action of the incident to stop or minimize the re-occurrence of the incident

7) Learning communicated to either whole organization or to the stakeholders only

Thus, incident management is significant aspect for every organization including custom software development. Every organization should have proper planning to handle incidents.