Essay: Phase 2 in octave

Security Management (IV 2022)

Phase 2 in OCTAVE

Vulnerability Assessment

Background

After completion of Phase 1 of OCTAVE, all critical assets and their corresponding threat profiles should have already been defined by the analysis team. The next step is to find the possible vulnerabilities in these critical assets that can be potentially exploited and lead to unauthorized access.

Overview

A vulnerability assessment is composed of technologically intensive activities. It is the essence of Phase 2 of the OCTAVE approach. There are generally 2 processes:

• Process 5 – Where the Infrastructure Components of critical IT Systems are Identified;
• Process 6 – Where the systems and their components are actually examined for the Vulnerabilities.

In a vulnerability assessment the focus is on the organization’s technology infrastructure and technology related vulnerabilities.

The procedure for carrying out a Vulnerability Assessment

A vulnerability assessment involves evaluating the computing and technological infrastructure in terms of weaknesses that can be exploited by malicious agents. Generally, not all the of the IT Systems of an organization are evaluated. Only the key components responsible for processing the critical assets (which can be determined from Phase 1 of the OCTAVE method) will undergo the evaluation.

In order to complete this task successfully, the analysis team should have participants who have a deep understanding of the organization’s business environment and how the IT systems support these operations. They will also have to be well versed with the IT environment and the organization’s network topology. Knowledge of common information system vulnerabilities and systems analysis tools that can be used to identify these vulnerabilities is also desirable. Thus, the core analysis team may need to add some supplemental personnel.

The general structure of a vulnerability assessment, as outlined in this document, is that there are 2 processes each with their own individual step-by-step activities that culminate in the actual identification and documentation of vulnerabilities within the targeted critical systems.

The processes involved in a vulnerability assessment and their activities are outlined below:

Process 5: Identifying Key Class Components:

This process is divided into two activities: identifying key classes of components and identifying infrastructure components to examine.[6,sec 7-7.3]

Activity 1: Identify Key Classes of Components.

a. Identifying the System of Interest

The analysis team will define the systems that each critical asset (defined in Phase 1 of the OCTAVE) depends on. The system which grants access to the critical assets in question is usually chosen as the first point of analysis.

To guide this process the IT department personnel will have to provide the analysis team with a means to map out the infrastructure of the system. This could be a network topology map that can show the location and sub-components of the infrastructure. They can also use network mapping utilities which can scan the network infrastructure and display information concerning connectivity and components. System architecture and development related documentation could also help in that they could contain a description of the entire infrastructure and its components. Such information is important in analyzing the organization’s infrastructure by showing how the information flows within the network where are the access points to the organization which can be used as a launching point for an attack.

Another method that can be important in this exercise is the use of threat trees. A threat tree is a diagrammatic layout of possible threats to the critical assets. Depending on the asset, the diagram will map out how the asset can be accessed, the actor who would access it, the motive and the outcome of their access to the critical asset.

The system of interest may be the asset itself or information linked to the asset or where and how it is stored or processed. The software application that stores, processes and transmits information related to the critical asset could be a system of interest.

After the systems of interest are identified the analysis team defines the key classes of components belonging to this system.

b. Identifying key classes of components

After Identifying the System of interest, the analysis team will identify how an attacker may access the system through its key components. These may be servers, office workstations, mobile devices, laptops or even workstations accessing the network from remote location.

Questions that can be asked to aid this process are what are the points of entry to the system of interest? Which key components could be compromised by an attacker? Again at this point, infrastructural design information like the network topology can be used as a guidance to find out what are the components of the system of interest and to answer the various questions regarding its access.[6,sec7-7.3]

Activity 2: Identify Infrastructure Components to examine.

The analysis team will choose the components to evaluate based on Activity 1. Then they will choose an appropriate evaluation approach and the tools that are to be used during the vulnerability evaluation.

i) Select Specific Components

Based on the various key components identified from the systems of interest in Activity 1, the analysis team will now choose specific components to perform the vulnerability evaluation on. This is sort of drilling down to more specific areas of concern within the critical systems.

The analysis team will document the determined components, the tools used to evaluate them, and the rationale for choosing the components. When selecting the components, the following issues must be taken into consideration:

• How critical is the component to business activities of the organization?
• Will the evaluation of the component interrupt the daily business activities?
• Must some permissions be granted before evaluating the component?

Who is the owner of the component? (i.e. there might be a case where a home machine can connect to the network remotely) [6,p.151].

Examine network access paths in the context of threat scenarios and identify the important class of components for critical assets.

Methodology for selecting Components:

Review the organization network topology diagrams. Identify the main access points to a critical asset. A threat tree diagram for human actors using Network access can be used for this activity

Identify the specific components in each key class to evaluate for threats and vulnerabilities.

c. Select Evaluation Approach

In this step, decisions concerning the actual vulnerability evaluation on the components are made. These decisions include:

• Who will perform the evaluation
• The type of tools that will be used
• The approach that will taken
• A schedule of when, how many and which components the evaluation will take place
• The means of interpretation of results, and notification to senior management about what will be taking place.

The type of tools that may be used include, but are not limited to, automated tools like Nessus, Qualys or Core Impact, for web applications they can employ tools like WebInspect, WebScarab, Fuzzing, Nikito. Other tools that can be used are OS Scanners, Network scanners, checklists, scripts, among others. These tools are used to examine weaknesses and find common known vulnerabilities within systems.

The analysis team has to be carefully when choosing these tools as they may have limitations as to what exactly can be identified. Things like amount of control a user has, user security practices cannot be fully determined by the tools and is something that must be established through aggregation of information.

Methodology for selecting best Approach:

• First look across the critical assets and selected important components for duplication overlaps
• Select an approach for evaluation each infrastructure components.
• Select the person who will perform the evaluation
• Selection of tool is very important .There are specific tools for specific vulnerabilities, so it is very important to select the right tool during evaluation.

Approval for Automated Tools:

Automated tools can affect the operation of the organization; therefore, all personnel who may be affected should be notified in advance. Gain approval from all concerned persons whose areas of concerned are involved during testing. The best approach is to conduct prior tests with these tools to determine the side effects of the testing.

Process 6: Examine Systems and Components for technological weaknesses

Activity 1: Evaluating Selected Components

i) Run Vulnerability Evaluation Tools

In this process the vulnerability evaluations approach, previously agreed upon, is executed on the key components, as identified in Process 5. It is vital that before starting the actual testing, the tools that are to be used are updated and the versions are checked to be correct. The necessary approvals from senior management for conducting the evaluation tests should also be obtained. All relevant personnel who regularly use the system should also be notified of the testing, where necessary, as the systems might be affected during the tests and may not work as expected.[6,sec8-8.3]

As the evaluation is carried out relevant data is collected and documented. This data can be used in Phase 3 of the OCTAVE for analysis purposes.

When running the Vulnerability tests a comprehensive catalog of known vulnerabilities can be used, for example the Common Vulnerabilities and Exposures (CVE) listing at mitre.org.

Upon completion the findings will be documented and presented to the analysis team and IT department during the workshop.

ii) Prepare Preliminary Vulnerability Summary

From the tools combined with the necessary application of knowledge, skill and experience, the data is collected and documented appropriately. Information concerning the vulnerabilities identified, where they are found, how severe they are and how to mitigate them should be noted. This information will be gathered and compiled into a summary. A good approach is to categorize the vulnerabilities according to a ranking based on severity, that is, high, medium and low.[6,sec 8.3]

Another categorization that could be used is as described below :

• Design vulnerabilities: These are “inherent in the design or specification of hardware or software whereby even a perfect implementation will result in a vulnerability”.
• Implementation vulnerabilities: Those resulting from “errors made in implementing software or hardware of a satisfactory design”.
• Configuration vulnerabilities: These result from “errors in configuration or administration of a system or component”.

Activity 2: Review Technology Vulnerabilities and Summarize Results

This activity will gather the knowledge from the evaluation that will be used in the risk analysis activities of Phase 3.[6,sec 8-8.3]

i) Review and Refine the Preliminary Summary

In this step, the entire analysis team discusses the vulnerabilities found and various implications around them. The most important things to discuss are the type of vulnerabilities found, the severity of the impact of these vulnerabilities to the critical assets, potential methods of mitigation and when they should be effected. During this discussion various parameters can be modified to fit the organization’s needs, or as per the discretion of the analysts based on knowledge and experience. It is important to note the modifications made.[6,sec8-8.3]

a. Identify Actions and Recommendations

Towards the end of the previous step the potential mitigation methods are noted. More detailed and comprehensive actions plans should also be devised and described together with the recommendation. Information that should be noted includes the specific method of mitigation chosen, the rationale, the role responsible for implementing in as well as tentative timelines. [6,sec8-8.3]

b. Perform a Gap Analysis

The information gathered when developing threat trees during process 5 is compared to the results actually found by the evaluation. Simply put, the potential threats that were identified are now compared to the actual vulnerabilities found. This gap analysis will reveal whether the newly found vulnerabilities change previously defined threat profiles or add new threat profiles. This is done to ensure that there are no inconsistencies and that all the vulnerabilities related to the critical assets’ key components have been successfully identified.[6,sec8-8.3]

After this process is complete Vattenfall can now perform a risk analysis (Phase 3 of the OCTAVE method) based on all the information gathered thus far.

In undertaking an assessment to evaluate the technological security of an organizations system’s one could generally adopt one of 2 approaches: A passive approach or an active approach.

The passive approach would involve simply analyzing information gathered about the infrastructure and it’s components and inferring possible vulnerabilities that could exist within the technological environment. The aim is not to exploit the vulnerabilities, but to prove that they exist using information gathered as well as knowledge and experienced. Tools may also be used, but generally they are used in the information gathering process. This is more or less what is carried out in Phase 2 in its most basic form of the OCTAVE method.

The active approach involves all the procedures of gathering information and using one’s knowledge and experience to identify vulnerabilities, but it goes slightly further. It involves actually exploiting the vulnerabilities or areas where there seem to be potential vulnerabilities. Tools are also used here, but they are more oriented towards orchestrating attacks. This is the essence of a Penetration test.

A penetration test may be included as part of a generic vulnerability assessment simply to prove that the vulnerabilities do exist and they can be exploited, causing the organization harm. The following section describes how a penetration test could be carried out.

Penetration Tests

Introduction

Background information

Penetration testing is one of the means of assessing the current state of information security within an information system which is usually running in its normal production environment. It gives a very pragmatic view of the state of things and has very tangible results as opposed to vulnerability assessments and information security audits through interviews with assistance of some analysis tools.

It usually involves simulating various attacks based on information gathered on the targeted systems. It aims at exploiting any form of vulnerabilities in any part of the system, ranging from hardware, software, networks, processes and even sometimes people.

Forms of penetration testing

Penetration testing has various forms that it can be packaged in. The form that is used different systems varies according to a number of factors, some of which include: the environment, industrial regulations, business constraints or managerial decisions. These factors must be taken into consideration before beginning the testing.

The first thing that should be known when determining the form of testing is the nature of the target and its environment (whether it is networked, standalone, a website or some other form of system). The purported amount of knowledge of the systems internals to the attacker should also be determined so as to know whether the approach of a black box (where the system internals are not known), white box (where information about the system internals is clearly elaborated) or Grey box (testing which involves a mix if the two) is being taken. The principal source of attacks should be defined, that is whether it is internal or external; the aim should also be ascertained – whether the testing is to be destructive or non-destructive.

Knowing whether people are going to be part of the targeted system is also crucial and must be established. This lies in the realms of whether social engineering will be used as part of the penetration test.

The Methodology

Meeting and planning

Soon after the proposal for the rendering of penetration testing services is accepted, the first step is to get to know the specific needs of the client, to understand their expectations of the outcomes, to delineate timelines and ensure necessary support from the management in concern.

The forms that the penetration testing shall take should be discussed along with their relative merits and demerits. The business environment, industrial regulations of compliance and managerial needs should be taken into consideration so as to establish the best form of penetration testing that would suit the case. The management should also be sufficiently informed of the effects of a penetration test on a system in the production environment and an explicit and documented go ahead on the specifics of the project should be obtained.

The scope of the project should also be discussed as well as the deliverables and criteria for determining the successful completion of the project.

After this is done, planning on the consultant’s side needs to be finalized in order to determine how many hours and resources shall be designated to this project at any given time during its duration. Milestones and tentative deadlines should also be defined.

Key client contacts should be made and confirmation of management support ensured at this point.

Information Gathering

Information gathering is the next phase in the penetration testing life-cycle, and the activities carried out in this phase vary depending on the decisions taken in the previous phase (meeting & planning). If only a black box penetration testing is allowed to be performed, then the amount of work needed to be done in this phase can be vast since the penetration tester has to gather much more information about the systems of interest. We can divide this phase into two categories as active and passive information gathering. In passive information gathering the systems of interest are not interacted directly. There are some different methods in this category that can be used to gather information about the IT infrastructure of the company. “Dumpster diving” is one of those in which the physical trash of the company is searched for some valuable information such as network diagrams, equipment purchase receipts, etc…[1, p.221] Internet search engines, newsgroups, Internet service registration (WHOIS), domain name servers, on-line analysis websites are places where interesting information about the system of interest can be found. There are even some tools which automate the whole passive information gathering process such as Maltego, Maltegoofil. Sniffing tools can also be used if the network uses Hubs instead of switches.

In active information gathering, there is a direct interaction between the system and the penetration tester. The following methods can be used to gather information actively: Ping Sweep (an old and common technique to reveal the live hosts in the network), connecting to port 25 (SMTP server port) to get the banner information or other relevant information to reveal the version of the SMTP server [1. P.232], sending crafted packets to reveal the open ports, Operation System version and other interesting information. This whole process can also be automated by using tools such as Nmap or Superscan among others. If switches are being used instead of hubs in the network, sniffing can still be possible by using ARP Poisoning method in which the hardware address tables are maliciously laced with invalid data results so as to redirect the entire network’s traffic to pass through penetration tester’s computer. Social engineering can also be considered as active information gathering in which the human beings are manipulated to reveal some classified information that they should not give out.

Vulnerability scanning

After enough information is gathered about the systems of interest both actively and passively, the next step is to associate the gathered information with the known vulnerabilities which can be further exploited.

To illustrate, you may have found that one port is open and responding to requests in a system but you are not sure how this fact can be exploited, this step will reveal whether the open ports can be matched with the known vulnerabilities [1, p.248].

Internet is again the valuable source which penetration testers can find the disclosed vulnerabilities of the systems or software. CVE [3], SecurityFocus [2], mailing lists, forums and newsgroups (especially black hat oriented) are some of those sources where the common and latest disclosed vulnerabilities can be found.

Associating the gathered information and the known vulnerabilities can be a very difficult task when it is carried out manually. The automated tools such as Nmap, Nessus, Qualys, Core Impact, Netsparker and WebScarab are some of those that can be used to discover the vulnerabilities. These tools should be used cautiously and in the hands of experts since lots of requests are sent to the system of interest to scan all the known vulnerabilities which results in consuming the system resources (i.e. bandwidth, CPU power, etc…) and can be interpreted as a Denial of Service Attack (DOS) by the system. A dedicated line for vulnerability scanning should be used in order not to interrupt the daily business activities of the company.

Exploitation

The next step in penetration testing life-cycle is to exploit the vulnerabilities you have identified in the previous step. The proof of concept may be sufficient for some companies to acknowledge the vulnerability but it is better to demonstrate the impact of the exploitable vulnerability in order the company to realize the risks they are under. Another reason to take one step further after identifying vulnerabilities is that some overlooked vulnerabilities may have devastating effects such as unauthorized access to or damaging the company’s critical assets depending on the context of the network. The contrary situation (of) may also hold for systems which do not have user interfaces or interaction and are completely isolated deep within the network. A critical vulnerability in a remote but critical system may not have a devastating impact on the assets. For both cases, “it depends on the type of access permitted to the system or application.” [1, p.256]

In order to demonstrate how much risk the company undertakes, after exploiting the vulnerability the penetration tester tries to escalate obtained privileges, maintain access and clean up all the logs which can be traced back. A sample scenario than can be performed to demonstrate all these steps could be installing a password cracker software to the vulnerable system of interest by using tools such as Metasploit or Core Impact to steal the credentials of valid privileged users and with the help of the obtained valid credentials the penetration tester can install a Rootkit [4] (which gives remote connection ability to the pen-tester) and delete logs or disable auditing with the escalated privileges. Installing and using a rootkit software will both give an idea of whether they can be installed and if that is the case whether they can be detected after they are installed. [1, p.268]

Denial of Service (DoS) Attacks are special types of attacks in which the attacks consume the resources(CPU power, network bandwidth or storage) of the systems of interest dramatically resulting in the system not to be able to perform its functionalities to remaining users. There are some tools which automate DoS attacks like smurf, fraggle, syn flood and ping of death. These are powerful tools and should be used with caution. Necessary approvals from senior management must be obtained beforehand since there is a high risk of interrupting daily business activities of the company.

Analysis of results

Once the vulnerabilities have been identified and exploited sufficiently for the goals of the penetration testing project to be attained, the technical phase of the assessment is over. The next task is to analyze the results.

The general idea is to place the vulnerabilities found within the entire business environment, linking all parts of the business systems that were determined to be compromised and extrapolating what the series of consequences or impact could have been realized in a fully fledged attack, when the control of the targeted system is totally relinquished

The analysis involves taking the attacker’s perspective and seeing how they could use the vulnerabilities to perform unauthorized actions, while calculating the impact factor of such actions to the entire organization [5].

Systematically, the vulnerabilities determined are analyzed in the following steps [6, p. 165-168]:

i. Integration of results

The results of penetration testing could be largely varied as they are determined using a large variety of tools and techniques. These results are integrated together to form unified evidence-based abuse cases based on groupings from different sets of vulnerabilities.

ii. Business impact reconciliation

From the integrated abuse cases, the results further refined according to their impact on critical assets and the business as a whole so as to ensure that the management involved can make clear conclusions on how the specific vulnerabilities can cause detriment to the entire business.

iii. Mitigation

The next task is to describe certain countermeasures to mitigate exploitation of these vulnerabilities. Specific actions and recommendations are designed in order to deal with technological, process or human vulnerabilities. The aim of this is to suggest the way forward and to provide visible value to the stakeholders from the outcome of the testing.

Documentation

This is the one of the most important steps in penetration testing. Documentation at every stage is very helpful, but it is even more critical that there is a final document to present to the key stakeholders after having performed the tests. Presenting a tangible deliverable in the form of a document is the only sure way of proving that the work has been done and that a pay cheque is in order.

Step-by-step documentation while performing tests helps in putting order. It also comes in handy when tests need modification or improvement due to new found knowledge. They also aid in preventing unnecessary repetition of work.

Some of the content that should be included in the documentation includes a description of the target area and all its components, the attack methods implemented, the tools used, the vulnerabilities discovered, the impact of the vulnerabilities on the organization, the recommended actions and any areas that could be vulnerable or were not tested due to unforeseen circumstances.

Very important in the documentation is the clearly explain the vulnerabilities, their risk to the organization and the suggested mitigation plans of action. This is where the attention of management is squarely focused on. Due to the possibility of an enormous amount of vulnerabilities, some form of prioritization must be implemented. Using the risk level (or impact) as a form of classification, one can attain this. The categorizations can be roughly described as follows [5]:

• High Risks: These are unacceptable risks that can result in very costly negative consequences, thus they must be mitigated as soon as possible.
• Medium Risks: These are undesirable risks that would not cost the organization so much as to cripple it entirely, but would cause a substantial amount of noticeable damage. They should be mitigated after high risks.
• Low Risk: These are acceptable after minor improvements. This means that even if the related vulnerabilities are exploited the damage realized is not of too much concern, but can lead to further unwanted consequences.
• Negligible Risk: These are acceptable without any modification. They are usually already known and are usually related to some cost-benefit trade-off where the benefit realized is greater than the negative effects.

Delivery and presentation

The final stage of performing a penetration testing engagement is to ensure that the customer understand the findings. This is done in the form of delivering a report that can be easily understood by management as well as by technical staff.

If a presentation of the report is required then it must be tailored towards the needs of the audience. For a technical audience more technical details may be included, while for a more business oriented audience, the risks related to the vulnerabilities should be emphasized. The aim is to meet a compromise where all parties understand the content.

Questions may arise from this stage and they need to be addressed properly such that the customer is satisfied. Any feedback from the stakeholders should be taken into consideration and noted in the documentation if necessary.

At this point the penetration testing project is concluded.

Conclusion:

A vulnerability assessment using the OCTAVE approach is a comprehensive way to evaluate vulnerabilities and threats to an organization’s identified critical assets, whereas penetration testing exploits the organization’s IT infrastructure to find out the impact of the vulnerabilities to the organization’s systems. Results obtained from both methods can give upper management a clear picture of where the organization stands in terms of information security. Upper management can use these results to perform a risk analysis and create clear strategies to deal with these vulnerabilities and threats. It is up to the organization to decided whether to implement one over the other or to choose both, based on company resources, policies and objectives.

REFERENCES

Tiller James S., The ethical hack : a framework for business value penetration testing / James S. Tiller, Auerbach Publications, 2005

Symantec Connect, “A technical community for Symantec Customers, end users, developer, and partners”, http://www.securityfocus.com, last retrieved on April 29, 2010

Common Vulnerabilities and Exposures, The standard of Information Security Vulnerability Names, http://cve.mitre.org , last retrieved on April 29, 2010

Wikipedia, the Free Encyclopedia, http://en.wikipedia.org/wiki/Rootkit, last retrieved on April 29, 2010

Kerem Kokaer, Penetration testing, bitsec, 14-04-10

Alberts C., Dorofee A., Managing Information Security Risks, The OCTAVE Approach, Addison Wesley, 2003