A customer case study – cloud security assessment

Faced with a steep bill for securing a new cloud application, a client asked us to help find a way to reduce their risk exposure at the lowest possible cost. By using the Business Threat Modeling methodology and PTA (Practical Threat Analysis) software, we were able to build a risk mitigation plan that mitigated 80% of the total risk exposure in dollars at half the original security budget proposed by the vendor.

This paper describes a customer case study of a risk analysis for a next generation call accounting system provided as a cloud service. A private medical school (let’s call them Campton College – some of the names have been deliberately changed for privacy reasons), needed to replace an aging call accounting system, which frequently lost call records and lacked the capability to provide unified campus-wide telephony billing features. Campton wanted to implement and operate an integrated Web based call accounting system that would service student dorms and administrative departments. The institution contracted with TACS, a call accounting solution provider, to replace the old software and provide a modern, Web-based managed application service that would be cheaper to maintain and easier to use. Prior to implementing the TACS managed call accounting services, Campton retained Software Associates in order to help them perform a risk assessment of the SaaS call accountingsolution.

The TACS managed call accounting service in a nutshell

TACS offers small to mid-sized organizations a managed software as a service application for call accounting that includes basic billing functionality and is capable of collecting and processing call detail records from variety of sources. The Web-based user interface caters to four different types of users: PBX technicians, administrators, phone users and organization managers.
Technicians – TACS technicians are responsible for installing the CDR (call detail records) buffer devices connected to the PBXs for accumulating the calls. A technician defines the parameters of the protocols used by the buffer, data collection schedule, format of call records and performs initial testing of data collection in order to validate that the calls are collected and parsed successfully by TACS data back-end data processing systems.
Administrators – Customer administrators handle ongoing management of the telephone switch resources and subscribers as follows:

• Allocate phone-extensions and other telephony resources, such as cellular phones etc.
• Set the pricing programs that calculates and attaches a price tag to each call
• Define phone users and system users
• Associate users with telephony resources and pricing programs
• Manage system access permissions

Subscribers (phone users) – Subscribers can view and print the detailed listings of their private calls and their monthly bills.
Managers – User department Managers can produce reports that summarize calls traffic and the usage of telephony resources in the organization. They also monitor the billing and payments of phone users.

System Architecture

The TACS system ASP architecture is based on Microsoft Windows Server 2003 that runs several .Net applications responsible for the call accounting processing, and a suite of web applications that interact with users via browsers (IE 5.5 and higher). The system database is managed by a stand alone MS SQL 2000 machine connected to the application server via LAN.

Database

The TACS MS SQL Server 2000 stores all types of system data, including call records, pricing programs, users, organizational structure and system configuration. The CDR tables can handle several million records per month and are indexed by a multiple fields to support rich reporting.
The SQL Server scheduler mechanism is used to schedule and dispatch the data collection activities.

Processing

The processing of CDRs has 3 stages:

• Data Collection collecting the calls from the CDR buffers. The output is blocks of raw CDR data.
• Parsing and reformatting – the output is structured call records in a uniform format invariant to origin of the calls.
• Load to database – call record are associated with the corresponding end point device, subscriber id and telecom provider and then inserted to the database.

The implementation is based on a several Windows services that use worker components to implement the required functionality. For example, the data collection service operates several different collector components to collect the call records from different data sources via the appropriate protocols. Campton College operates 3 PBXs from different vendors: Avaya, Siemens and a small Cisco VoIP switch. The operating parameters of the components are kept in the database.
The data is transferred between the 3 processing stages via MSMQ private queues that serve as non-volatile buffers for data in process.
The service processes and some of the worker components were developed using .NET technology. Other worker components are legacy Win32 components wrapped with .NET Interop layer.

Web applications

The Web Applications are implemented in ASP.NET combined with Microsoft reporting engine. Some of the applications are capable of directly viewing and editing data tables in the database via ASP.NET server side controls.
In the TACS system, all Web applications share the same infrastructure for user login and secure access to the database.

Pricing, database maintenance and data exchange

The pricing, database maintenance and data exchange tasks are implemented with a Windows service that uses worker components to perform the actual tasks, similar to the call records processing architecture. The tasks are executed in a periodical manner according to the system schedule.

Why conduct a threat analysis?

“By retiring an aging 80’s in-house system and outsourcing to TACS we will move into the 21st Century in less than nine months; and get an easy to use service that is available to all students and generates a revenue stream,…quot; said Joan Walz, Campton campus operations manager, “but we had security concerns about using an outsourced service.”

“We knew that TACS is an experienced call accounting solution provider but we were unsure that their software and operations team had adopted a best-practices approach to information security and we asked TACS to submit to an external assessment of their systems…” said Walz.

What is Business Threat Modeling?

A Business Threat Modeling study focuses on protecting valuable assets, is sponsored by a senior manager, has 2-5 participants with relevant knowledge, is guided by an experienced security analyst with specific domain expertis (in this case telecommunications).  A typical threat modeling study lasts 2-5 days where the last day is devoted to presenting the results to management.
In a pre-kickoff planning meeting, the consultant works with the sponsor to set clearly defined goals and outcomes for the session. Since much of the work is done in small breakout groups, all stakeholders take an active part. The consultant guides the group through a fast-paced process to:

1. Identify assets
2. Identify vulnerabilities
3. Define countermeasures
4. Compose threat scenarios
5. Understand calculated risk
6. Optimize countermeasures

The data collection and risk calculation is performed using PTA Professional. PTA captures the information in a structured database and automates the  risk what-if calculation process. Analysts and stakeholders don’t need to maintain unstructured Word or Excel documents. Users can quickly create new threat scenarios and countermeasures. All issues are captured and nothing is lost. Management can ask for and quickly receive any reports they want.

PTA kickoff

At the first day kickoff session, the functional and architectural descriptions of TACS system were presented to the consultant, by Dympna O’Connell, TACS product manager. “We’re already documenting and revising our customer provisioning and configuration procedures”, said O’Connell. “We realize that these process steps are crucial to our customer’s information security and we want to make sure there are no security holes and opportunities for data manipulation”.

Step 1 of the study – Identify Assets

In the first step of the study the group mapped the system’s major assets, their financial values and the losses that may be caused when assets are damaged. The following major system assets were identified:

Asset Name	Asset Value (annual)
The accuracy and integrity of the data in system database	$2,000,000 or 90.5% of total assets
Private call details information	$150,000 or 6.8% of total assets
The availability of the system’s web application and service	$50,000 or 2.2% of total assets
The integrity of system passwords	$10,000 0.5 % of total assets

The detailed list of identified assets is part of the full threat-model database available for download from Call Accounting Case Study threat model. To view the detailed entities lists you should have PTA software installed on your computer.

Step 2 Identify Vulnerabilities

In order to identify vulnerabilities and flaws, Open Solutions analysts studied the functional and architecture documents supplied by Ms. O’Connell. “Since TACS bases its architecture on Microsoft infrastructure, we used the PTA MS-Telecom entity library as a base line checklist for picking up system common vulnerabilities” said Yuval,  risk consultant. “More then 70% of the stuff was already there. We have just had to complement the picture by diving into the CDR collection equipment and by studying Campton specific business procedures with the help of Mr. Walz.

“Identifying the relevant vulnerabilities is an iterative process bundled with the understanding of the actual threats. All in all, we came up with 15 focused vulnerabilities relevant to the specific architecture, the specific telephony infrastructure and the ASP mode of operation” said Yuval.

Step 3 – Define Countermeasures

During this step the team defined the countermeasures relevant for mitigating the identified vulnerabilities. Some of the countermeasures were well known safeguards picked up from the predefined PTA entity library such as enforcing OS patches deployment and strong passwords policy. Others were more unique e.g. the development of mechanism for managing data collection buffer passwords in an encrypted repository.

“We worked directly with Ms. O’Connell and her developers on estimating countermeasures implementation costs needed by PTA for calculating countermeasures cost-effectiveness” said Yuval.

The lists of the 22 countermeasures that were defined and the identified vulnerabilities are included in the case study database available for download from Call Accounting Case Study threat model.

Step 4 Build Threat Scenarios

“Building the threats is the peak of the process”, said Software Associates founder and CTO Mr. Danny Lieberman, “this is the point where we use our experience to compose the threat scenarios, evaluate their feasibility and estimate the probability they will actually happen”.

“The flexibility of the PTA database driven model enables us ‘what-if’ experiments and the calculative capabilities gives us immediate feedback on the severity of threats” , said Yuval.

Step 5 – Understand the calculated Risk

After refining threat probabilities, the PTA software calculated the following bottom-line:

• The total yearly value of assets that might be damaged if threats materialize is $2.21M
• The risk level (the value of the financial losses that may be caused to the system due to the identified threats) is 249% of the total assets (~$5.5M). Although it is clear that the actual damage to the system assets cannot exceed their total value, the risk level does not express the actual damage. It reflects the amount of effort that has to be invested in order to mitigate the threats to the system, and since in this specific system several threats threaten the same assets, the risk level exceeds 100%.

The following bar chart presents the 5 most dangerous threats calculated and displayed by PTA (the value of risk is presented in real $):

Top Threats by Risk

ID	Name	Risk ($)
T001	Intruder accesses system application and database servers directly from the Internet	1,458,600
T011	Intruder sniffs CDR buffers passwords and then steals or corrupts calls data	1,040,247
T004	Intruder corrupts database by injecting malicious SQLs in input fields of Web pages	979,914
T013	Intruder gets control of call processing engine after hacking the Web server machine	663,000
T010	A malicious user with managerial rights manipulates calls data	528,632

Not surprising, it was found that the most dangerous threats are the ones that threaten the calls data either in the system database on the various collecting stages.

“The ranking of the threats reflects a typical heterogeneous software system. The ability to take into account non-standard threats specific to the analyzed system is one of the great strengths of PTA “, said Lieberman, “We were not limited to generic information security standards, such as ISO 27001 and indeed you can see some interesting threats that indigenous to this particular system e.g. the CDR buffers vulnerabilities. Complex systems like this often have huge risks that are hidden in the cracks of generic standards…”

Step 6 Optimize Countermeasures

It was clear that a level of 249% of risk is dangerous and that countermeasures should be applied to reduce the system risk before going into heavy-duty production operation. We asked Open Solutions to show us how to reduce the risk to an acceptable level of 60% at lowest cost, said Ms. Walz. Since our budget was constrained, we considered canceling the whole info-sec project and taking our risks by doing nothing. At that step, said Yuval, we ran the PTA optimized risk reduction plan with a target risk level of 50%. We obtained an optimized plan with the following countermeasures that should be applied:

• Install content leakage prevention system
• Install firewall
• Enforce deployment of latest security patches for OS, database and Web server
• Develop mechanism for secure managing of CDR buffers passwords
• Use CDR buffers with secure transfer and login authentication protocols
• Enforce security code review
• Enforce data access via stored procedures with formal parameters content validation
• Implement validation of input fields in web pages
• Develop secured passwords and role-based mechanism for web users
• Develop monitoring mechanism for back-end processing (system health)
• Limit access of ASP employees and technicians to system resources
• Enforce quality passwords policy for protecting each of the machines on the network
• Use Windows integrated authentication policy
• Database login accounts should be given the minimal rights that are necessary for their functionality

Implementing the recommended set of countermeasures reduces the system risk to 54.3% at a cost of 127,000 $. Only 14 countermeasures out of the 22 were selected – the proposed order of countermeasures also ensures a quickest reduction of risk per $ spent throughout the system modification process. The implementation of the following countermeasures was suspended to later stages in system life cycle:

• Create acceptable use policy for email and Internet access
• Install anti-DoS appliance
• Enforce deployment of latest security patches for OS, database and Web server
• Develop fraud detection mechanism
• Security officer should assure the personal integrity of employees
• Develop module for logging changes in data initiated by users
• Enforce employees’ liability for disclosing private calls information
• Restrict display of phone numbers and sensitive information in detailed reports

Ms. Walz of Campton College and Ms. O’Connell of TACS summarized their impressions of the study.

“We were pleased with the speed and quality of results of the PTA methodology that Open Solutions uses; with the fact that it created consensus among the stakeholders; with the effective use of senior manager time; and above all getting us the best risk reduction at the lowest cost. “

Appendix 1. Abbreviations and terminology

PBX Private Exchange telephony device; interchangeable with the term Switch

MSMQ Microsoft Middleware Queue system

CDR  Call Detail Record

Telephony buffer Intermediate buffer device for storing CDRs collected from PBX

Data Source origin of telephony calls data e.g. PBXs, IP Switches etc.

Users Individuals that have access to the university telephony resources and to TACS system e.g. students, academic staff, administration and personnel