Security Assessments

Go back to Tutorial

It is an explicit study to locate IT security vulnerabilities and risks. Security assessments are risk -based assessments, due to their focus on vulnerabilities and impact. Security assessments rely on three main assessment methods that are inter-related.

The goal of a security assessment (also known as a security audit, security review, or network assessment), is to ensure that necessary security controls are integrated into the design and implementation of a project. A properly completed security assessment should provide documentation outlining any security gaps between a project design and approved corporate security policies. Management can address security gaps in three ways: Management can decide to cancel the project, allocate the necessary resources to correct the security gaps, or accept the risk based on an informed risk / reward analysis.

Assessment Terms

Vulnerability – A weakness that is inherent in every network and device. This includes routers, switches, desktops, servers, and even security devices themselves.

Vulnerabilities, whether accidentally triggered or intentionally exploited, could potentially result in a security incident, such as an inappropriate use or disclosure of EPHI. Vulnerabilities may be grouped into two general categories, technical and non-technical. Non-technical vulnerabilities may include ineffective or non-existent policies, procedures, standards or guidelines. Technical vulnerabilities may include: holes, flaws or weaknesses in the development of information systems; or incorrectly implemented and/or configured information systems.

Threats — The people eager, willing, and qualified to take advantage of each security weakness, and they continually search for new exploits and weaknesses.

There are several types of threats that may occur within an information system or operating environment. Threats may be grouped into general categories such as natural, human, and environmental. Examples of common threats in each of these general categories include:

• Natural threats may include floods, earthquakes, tornadoes, and landslides.
• Human threats are enabled or caused by humans and may include intentional (e.g., network and computer based attacks, malicious software upload, and unauthorized access to EPHI) or unintentional (e.g., inadvertent data entry or deletion and inaccurate data entry) actions.
• Environmental threats may include power failures, pollution, chemicals, and liquid leakage.

Attacks — It is any attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of an asset. The threats use a variety of tools, scripts, and programs to launch attacks against networks and network devices. Typically, the network devices under attack are the end-points, such as servers and desktops.

Criticality – The criticality of the system is based on its importance or risk relative to goals and objectives of the unit, including uninterrupted operation and essential business functions. Criticality categories are used to determine the requirements for availability and integrity, as

• Category 1: Critical Functions or Mission Critical – Mission-critical business processes and functions are those that have the greatest impact on your company’s operations and potential for recovery. Almost everyone working in a company has an innate understanding of the mission-critical operations within their department.
• Category 2: Essential Functions or Vital – Some business functions may fall somewhere between mission-critical and important, so you may choose to use a middle category that we’ve labeled “vital” or “essential.” How can you distinguish between mission-critical and vital? If you can’t, you may not need to use this category.
• Category 3: Necessary Functions or Important – Important business functions and processes won’t stop the business from operating in the near-term but they usually have a longer-term impact if they’re missing or disabled. When missing, these kinds of functions and processes cause some disruption to the business. They may have some legal or financial ramifications and they may also be related to access across functional units and across business systems.
• Category 4: Desirable Functions or Minor – Minor business processes are often those that have been developed over time to deal with small, recurring issues or functions. They will not be missed in the near-term and certainly not while business operations are being recovered. They will need to be recovered over the longer-term. Some minor business processes may be lost after a significant disruption and in some cases, that’s just fine.

Risk – The ISO 31000 (2009) / ISO Guide 73:2002 definition of risk is the ‘effect of uncertainty on objectives’. In this definition, uncertainties include events (which may or may not happen) and uncertainties caused by ambiguity or a lack of information. It also includes both negative and positive impacts on objectives. Many definitions of risk exist in common usage, however this definition was developed by an international committee representing over 30 countries and is based on the input of several thousand subject matter experts.

Risk is a function of

• the likelihood of a given threat triggering or exploiting a particular vulnerability
• the resulting impact on the organization.

This means that risk is not a single factor or event, but rather it is a combination of factors or events (threats and vulnerabilities) that, if they occur, may have an adverse impact on the organization.

Various types of methods involved in assessment, are

• Reviewing Method – The reviewing method includes passive review techniques and interviews, which are generally conducted manually. They help to evaluate systems, applications, networks, policies, and procedures to discover vulnerabilities. They include the review of documentation, architecture, rule-sets, and system configurations. The reviewing method enables understanding what the critical information & systems are, and how the organization wants to focus on security.
• Examination – Examination is a hands-on technical process that looks specifically at the organization from a system/network level to identify security vulnerabilities that exist in those systems. This includes doing technical analysis of the firewalls, intrusion detection systems, and routers. It also include vulnerability scans of the customer’s networks. The reviewing assessment method provides excellent information that leads into future examinations.
• Testing – Testing, often called penetration testing, is a process whereby someone imitates an adversary looking for security vulnerabilities, which allow the break in to a system or network. Reviewing and examination methods provide excellent information that leads into future testing.

The following methodology outline is put forward as the effective means in conducting security assessment.

• Requirement Study and Situation Analysis
• Security policy creation and update
• Document Review
• Risk Identification
• Vulnerability Scan
• Data Analysis
• Report & Briefing

The baseline or reference point for any security assessment should be corporate security policies. In order for security assessments to be consistent and credible, the assessment must be based on security policy that is approved and published. Security policy must be deployed so that it’s known and accepted by employees, project managers, and management throughout the corporation.

A security assessment policy should be part of the policy “suite”. An established policy requiring a security assessment for certain types of projects is imperative. Without it, a security assessment will rarely be included in any corporate or business unit project planning activity.

All the steps of assessment process, can be summarized as

Assess information and infrastructure scope – In this first step, you are identifying the scope of the information systems along with the hardware and software resources and the data that makes up your environment. When looking at the infrastructure, it is important to focus on the critical systems (billing, CRM, HR, legal, knowledge repository, etc). When looking at the data, focus on the “data of concern,” including personally identifiable information, HR data, intellectual property, etc.

Understand threats and vulnerabilities – Review the threats that face your organization. (These may vary based on your geographical location and your industry.) A threat is the potential for a particular threat-source to successfully exploit a particular vulnerability. List the hardware and software vulnerabilities that exist within your environment. Consider both intentional and unintentional threats. For example, an unintentional threat may be incorrect data entry, while an intentional threat may be a targeted attack via the network or a malicious software upload. The result of this step should be a list of threats with an understanding of their associated vulnerabilities.

Estimate the impact – During this step, forecast the adverse impact that could result if each potential threat actually occurred. The adverse effects of a security event can be described in terms of loss or degradation, or a combination of the following three security goals:

• Integrity
• Availability
• Confidentiality

With these goals in mind, classify the magnitude of the impact. One way to do this is to use a high, medium or low classification, where high has an immediate, critical business impact and low has a relatively limited impact.

Determine the risk – Determine the risk for a particular threat/vulnerability in terms of:

• The likelihood of a threat source successfully exploiting a vulnerability
• The magnitude of the impact of a threat source successfully exploiting a vulnerability
• The adequacy of existing security controls for reducing, mitigating or eliminating the risk

During this stage, you should create a risk-level matrix of the risks and the effects (that you classified in step 3.) Again, you can use a high, medium or low classification. A simple starting point is a 3×3 matrix examining threat risks and threat impacts.

Plan the controls – During this final step, outline the possible controls that could mitigate or eliminate the identified risks. The goal of the recommended controls is to reduce the level of risk to the IT environment to an acceptable level. These controls can range from people, policy and procedure changes, to new configurations, procurements or the implementation of new technology.

With these five steps, you will have completed a basic IT security risk assessment process. Be sure to share your results with the key decision makers in your organization. They can assist in making an informed business decision about prioritizing your planned controls to reduce risk to an acceptable level.

Security Assessment Categories

• Network Security – If a new device is being added to the network, are the appropriate controls and protections in place (Firewalls, Intrusion Detection Systems, etc.)? Who owns and manages access to the network device? Are procedures in place for monitoring and maintaining the network device? Are production and development environments appropriately separated?
• System Security – Who owns and has access to the system? How can the system be accessed (network, modem, wireless, etc.)? How are IDs and passwords managed and controlled? Are root and admin passwords changed and managed appropriately? Are system logging and audit functions active? What are the procedures for monitoring system logs? Does the OS configuration conform to corporate policy and requirements? What are the procedures for applying security patches, virus updates, etc?
• Application Security – Who owns and is responsible for the application? What application security mechanisms (access controls) are in place? What data does the application use? What information does the application create? Is this information appropriately classified and protected? How is the application integrated into other security components (such as using NT authorization, external access controls, and centralized logging/monitoring)?
• Data Security and Classification – What data is being incorporated into the project? What is the sensitivity (classification) of the data? Are data protection mechanisms set commensurate with the sensitivity of the data? Who will have access to the data? What access controls are in place? According to policy, what are the encryption requirements for the data (in storage, in transit, etc.)?
• Business Resumption – What are the procedures for system and file back-ups? What are the procedures for managing system outages and system recovery?

The assessment process should facilitate and enable business objectives, not hinder or prevent innovation. Designing security into a project can enable business strategies that would otherwise be too risky or technically infeasible. Security should strive to be a partner with the project team in identifying security solutions to make the project successful. Finally, integrate the assessment process into your security policies and into existing corporate project planning and project management processes. In this way, security will always be at the forefront of project planning, management and implementation.

Attack Surface Analysis

The attack surface of a software environment is the sum of the different points (the “attack vectors”) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment. Examples of attack vectors include user input fields, protocols, interfaces, and services.

The basic strategies of attack surface reduction are to reduce the amount of code running, reduce entry points available to untrusted users, and eliminate services requested by relatively few users. One approach to improving information security is to reduce the attack surface of a system or software. By turning off unnecessary functionality, there are fewer security risks. By having less code available to unauthorized actors, there will tend to be fewer failures. Although attack surface reduction helps prevent security failures, it does not mitigate the amount of damage an attacker could inflict once a vulnerability is found.

Go back to Tutorial