1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).

Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.

In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.

If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.

With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.

IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.

There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.

Let me illustrate why compliance control policies are not the common language we need.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.

Now, consider some deeper ramifications of compliance control policy-based security.

When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.

We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

Threat scenarios consider asset values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

In our experience, building the security portfolio on threat scenarios has 2 clear benefits;

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives relate well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

Security is about reducing the impact of unpredictable attacks to a your organization.

IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling

Typically, when a company ( business unit, department or manager) needs a line of business software application, IT staffers will do a system analysis starting with business requirements and then proceed to buy or build an application and deploy it.

Similarly, when the information security group needs an anti-virus or firewall, security staffers will make some requirements, test products, and proceed to buy and deploy or subscribe and deploy the new anti-virus or firewall solution.

Things have changed – both in the IT world and in the security world.

Web 2.0 SaaS (software as a service) offerings (or  Web applications in PHP that the CEO’s niece can whip together in a week…) often replace those old structured systems development methodologies. There are of course,  good things about not having to develop a design (like not coming down with an advanced case of analysis paralysis) and iterating quickly to a better product, but the downside of not developing software according to a structured systems design methodology is buggy software.

Buggy software is insecure software. The response to buggy, insecure software is generally doing nothing or installing a product that is a security countermeasure for the vulnerability  (for example, buying a database security solution) instead of fixing the SQL injection vulnerability in the code itself.   Then there is lip-service to so called security development methodologies which despite their intrinsic value, are often too detailed for practioners to follow), that are not a replacement for a serious look at business requirements followed by a structured process of implementation.

There is a fundamental divide, a metaphorical valley of death of  mentality and skill sets between IT and security professionals.

• IT is about executing predictable business processes.
• Security is about reducing the impact of unpredictable attacks.

IT’s “best practice” security in 2011 is  firewall/IPS/AV.  Faced with unconventional threats  (for example a combination of trusted contractors exploiting defective software applications, hacktivists or competitors mounting APT attacks behind the lines), IT management  tend to seek a vendor-proposed, one-size-fits-all “solution” instead of performing a first principles threat analysis and discovering  that the problem has nothing to do with malware on the network and everything to do with software defects that may kill customers.

Threat modeling and analysis is the antithesis of installing a firewall, anti-virus or IPS.

Analyzing the impact of attacks requires hard work, hard data collection and hard analysis.  It’s not a sexy, fun to use, feel-good application like Windows Media Player.   Risk analysis  may yield results that are not career enhancing, and as  the threats  get deeper and wider  with  bigger and more complex systems – so the IT security valley of death deepens and gets more untraversable.

There is a joke about systems programmers – they have heard that there are real users out there, actually running applications on their systems – but they know it’s only an urban legend. Like any joke, it has a grain of truth. IT and security are primarily systems and procedures-oriented instead of  customer-safety oriented.

Truly – the essence of security is protecting the people who use a company’s products and services. What utility is there in running 24×7 systems that leak 4 million credit cards or developing embedded medical devices that may kill patients?

Clearly – the challenge of running a profitable company that values customer protection must be shouldered by IT and security teams alike.

Around this common challenge, I  propose that IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling - threats, vulnerabilities, attackers, entry points, assets and security countermeasures.  This may be the best or even only way for IT and security  to traverse the valley of death successfully.

How does this work?

We evaluate your healthcare software system or medical device from an attacker point of view, then from the management team point of view, and then recommend specific detailed action steps to close the gap between your product and HIPAA security and privacy requirements. We then train your product development team based on these recommendations.

Many medical devices still run on Microsoft Windows; variants of Windows XP, Windows XP embedded and Windows server systems are not uncommon.

Being a commodity operating system, primarily designed for ease of use by end-users and application development by programmers using Visual Studio, it is not uncommon to see malware attack medical devices and healthcare information systems.

If your’e a medical device or healthtech developer using Windows platforms, one of the first action steps we recommend is to setup a security ERT (emergency response team) with a clear response plan and division of responsibilities.

The security ERT will be your first responders in the case of a data leak or malware infection.

The ERT should have a clear, well-thought and debugged procedure for removing malware.  See this excellent malware removal guide for an example.

As a preface, begin with the understanding that you already have all the resources you need.

Discussions with colleagues in a large forensics accounting firm that specialize in anti-fraud investigations, money laundering and anti-terror funding (ATF), confirm what I’ve suspected for a long time. Armies of junior analysts working for the large accounting firms who have never seen or experienced a fraudulent event and are unfamiliar with the your business operation are not a reasonable replacement for careful risk analysis by the business done by people who are familiar with the business.

Step # 1- Do not do an expensive business process mapping project.

Many consultants tell organizations that they must perform a detailed business process analysis and build data flow diagrams of data and users who process data. This is an expensive task to execute and extremely difficult to maintain that can require large quantity of billable hours. That’s why they tell you to map data flows. The added value of knowing data flows inside your organization between people doing their job is arguable. There are much better ways to protect your data without writing out a 7 digit check. Here is the first one you should try out. Select the 10 most valuable data assets that your company owns. For example – proprietary mechanical designs of machines, detailed financials of a private company being acquired, and details of competitive contracts with large accounts. In a few interviews with finance, operations, IT, sales and engineering, you can nail down those key assets. After you’ve done that, schedule a 1 hour meeting with the CFO and ask her how much each asset is worth in dollars. In general, the value of a digital, reputational, physical or operational asset to a business can be established fairly quickly by the CFO in dollar terms – in terms of replacement cost, impact on sales and operational costs.

Step #2 – Do not develop a regulatory compliance grid.

There is no point in taking a non-value-added process and spend money making it more effective.

My maternal grandmother, who spoke fluent Yiddish would yell at us – ” grosse augen” when we would pile too much food on our plates. ” Grosse augen” ( or as my folks put it); is having eyes that are bigger than your capacity. Yes, US publicly traded companies are subject to multiple regulations – if the company sells to customers and stores and processes PII (personally identifiable data) they will have to deal with PCI DSS 1.1, California State Privacy Law, Sarbanes-Oxley PCI DSS 1.1 protects one asset – payment card numer and magnetic stripe, while Sarbanes-Oxley is about accounting records. Yes, there are a few commercial software products that map business processes, databases and data elements to multiple regulations; their goal is to help streamline the work involved in multiple regulatory compliance projects – eliminating redundancy where possibility using commonality.
Looking at all the corporate governance and compliance violations; cases such as Hannaford supermarkets and AOL – it’s clear government regulation has not made America more competitive nor better managed.

Step #3 – Identify the top 5 data assets in your business and valuate them

I saw an article recently that linked regulatory compliance mandate and asset cost. Definitely not true – the value of an asset for a company is whatever operational management/CFO say it is. Asset value has nothing to do with compliance but it has everything to do with a cost effective risk control plan. For example – a company might think that whole disk encryption on all company notebook computers is a good idea – but if only 20 people have sensitive data – why spend 1 million dollars on mobile device data encryption when you can solve the problem for less than 5k?

Step #4 – Do not store PII

The absolutely worst thing you can do is a project to analyse data retention and protection regulations that govern each of the sensitive data elements that need protecting, and working with legal and compliance consultants who know the relevant regulations. VISA has it right. Don’t store credit cards and magnetic strip data. It will not help the marketing guys sell more anyway – and you can give the money you save on some fancy database encryption software to the earthquake victims in Myanmar and China.

Step #5 – Monitor your outsourcing vendors

Despite the hype on trusted insiders, most data loss is from business partners. You can write a non-disclosure agreement with an outsourcing vendor and trust them, but you must verify their compliance and prevent unauthorized data leaks.

The best story I had in years was in a meeting with the VP internal audit at a medium sized bank in Israel. He took a sales call with me and I pitched our extrusion prevention technology from Fidelis Security Systems as a way to protect their customer data. He said – look Danny, we don’t need technology – we’ve outsourced everything to a very large bank and their data center security is world-class. Two weeks later, the big bank had a serious data breach event (a high school student hacked into the internal network of the bank from a public Windows-based kiosk and helped himself to some customer lists. Two months later, the small bank was reported to be looking to get out of their outsourcing contract. Don’t rely on contracts alone – use people and DLP technology to detect data leakage.

Step #6 – Do annual security awareness training but keep it short and sweet

Awareness is great but like Andy Grove said – “A little fear in the workplace is not necassarily a bad thing”. Have everyone read, understand and sign a 1 page procedure for information security. Forget interview projects and expensive self-assessment systems – what salesman in his right mind will take time to fill out one of those forms – if he doesn’t update his accounts on salesforce.com? Install an extrusion detection system at the network perimeter. Prosecute violators in real time. Do random spot checks on the read-and-understand procedure. Give demerits to the supervisors and managers if their employees don’t pass the spot check.

Step #7 – Calculate valuate at risk of your top 5 data assets

ISO 27001 and PCI DSS 1.1 checklists are great starting points but they focus on whether a particular technology, policy or control has been implemented, and not whether these controls are cost-effective security countermeasures against internal and external attackers. Use Practical Threat Analysis with a PTA risk library for ISO 27001 or PCI DSS 1.1 and you will be able to build a cost-effective risk mitigation plan based on asset values, threat probabilities and estimated damage levels.

Step #8 – Ask your vendors and colleagues difficult questions

After you’ve done a practical threat analysis of your risk exposure to attacks on sensitive customer data and IP you will be in better position than ever to know what policies, procedures and technologies are the most effective security controlss. You’ll be in an excellent position to ask difficult questions and negotiate terms with your favorite vendor. While the attitude of many companies is to hold data protection protections close to their chests, it is valuable to talk to your colleagues at other companies in the same market and get a sense of what they have done and how well the controls perform.

Step #9 – Resist the temptation to do a customer data integration (CDI) project.

Customer data is often stored in many applications and locations in a large organization. The knee-jerk reaction of IT is to do a big data integration project and get all the digital assets under one roof. There are three reasons why this is a terrible idea. (a) Most of these projects fail, overrun and never deliver promised value (b) If you do suceed in getting all the data in one place, it’s like waving a huge red flag to attackers – heah , come over here – we have a lot of sensitive data that is nicely documented and easily accessible. Companies with enterprise software systems such as SAP and Oracle Applications are three times more likely to be attacked. (c) Ask yourself – would Google have succeeded if with global data integration strategy?

Step #10 – Prepare a business care for data loss prevention before evaluating products

Despite claims that protecting data assets is strategic to an enterprise, and IT governance talk about busines alignment and adding value – my experience is that most organizations will not do anything until they’ve had a fraud or data security event. The first step to protecting customer data and IP in any sized business from a individual proprietership to a 10,000 person global enterprise is laying the case at the door of the company’s management. This is where executives need to take a leadership position – starting with a clear position on which data assets are important and how much they’re worth to the company.

Practical threat analysis is a great way to identify and assess threats to your business and evaluate the potential business impact in dollars and cents to your operation using best-practice risk models provided by the PTA Professional threat modeling tool.

In summary

Software Associates specializes in helping medical device and healthcare software vendors achieve HIPAA compliance and protect customer assets and provides a full range of risk management services, from stopping fraud to ensuring regulatory compliance and enhancing your ability to serve your customers.

There are resources that help you turn information into insight such as   Risk Management from LexisNexis, Identity Fraud TrueID solutions from LexisNexis that help significantly reduce fraud losses and Background Checks from LexisNexis that deliver valuable insights that lead to smarter, more informed decisions and greater security for consumers, businesses and government agencies.For consumers, its an easy way to verify personal data, screen potential renters, nannies, doctors and other professionals, and discover any negative background information that could impact your employment eligibility. For businesses and government agencies, it is the foundation of due diligence. It provides the insight you need to reduce risk and improve profitability by helping you safeguard transactions, identify trustworthy customers and partners, hire qualified employees, or locate individuals for debt collections, law enforcement or other needs.

The GRC (governance, risk and compliance) market is driven by three factors: government regulation such as Sarbanes-Oxley, industry compliance such as PCI DSS 1.2 and growing numbers of data security breaches and Internet acceptable usage violations in the workplace. $14BN a year is spent in the US alone on corporate-governance-related IT spending .

It’s a space that’s hard to ignore.

Are large internally-focused GRC systems the solution for improving risk and compliance? Or should we go outside the organization to look for risks we’ve never thought about and discover new links and interdependencies .

This article introduces a practical approach that will help the CISOs/CSOs in any sized business unit successfully improve compliance and reduce information value at risk. We call this approach “GRC 2.0” and base it on 3 principles.

1.    Adopt a standard language of GRC
2.    Learn to speak the language fluently
3.    Go green – recycle your risk and compliance

GRC 1.0

GRC (Governance, Risk and Compliance) was first coined by Michael Rasmussen.  GRC products like Oracle GRC Suite and Sword Achiever, cost in the high six figures and enable large enterprises to automate the workflow and documentation management associated with costly and complex GRC activities.

GRC – an opportunity to improve business process

GRC regulation comes in 3 flavors: government legislation, industry regulation and vendor-neutral security standards.  Government legislation such as SOX, GLBA, HIPAA and EU Privacy laws were enacted to protect the consumer by requiring better governance and a top-down risk analysis process. PCI DSS 2.0; a prominent example of Industry regulation, was written to protect the card associations by requiring merchants and processors to use a set of security controls for the credit card number with no risk analysis.  The vendor-neutral standard, ISO27001 helps protect information assets using a comprehensive set of people, process and technical controls with an audit focus.

The COSO view is that GRC is an opportunity to improve the operation:

“If the internal control system is implemented only to prevent fraud and comply with laws and regulations, then an important opportunity is missed…the same internal controls can also be used to systematically improve businesses, particularly in regard to effectiveness and efficiency.”

GRC 2.0

The COSO position makes sense, but in practice it’s difficult to attain process improvement through enterprise GRC management.

Unlike ERP, GRC lacks generally accepted principles and metrics. Where finance managers routinely use VaR (value at risk) calculations, information security managers are uncomfortable with assessing risk in financial measures. The finance department has quarterly close but information security staffers fight a battle that ebbs and flows and never ends. This creates silos – IT governance for the IT staff and consultants and a fraud committee for the finance staff and auditors.

GRC 1.0 assumes a fixed structure of systems and controls.  The problem is that, in reducing the organization to passive executives of defense rules in their procedures and firewalls, we ignore the extreme ways in which attack patterns change over time. Any control policy that is presumed optimal today is likely to be obsolete tomorrow. Learning about changes must be at the heart of day-to-day GRC management.

A fixed control model of GRC is flawed because it disregards a key feature of security and fraud attacks – namely that both attackers and defenders have imperfect knowledge in making their decisions. Recognizing that our knowledge is imperfect is the key to solving this problem. The goal of the CSO/CISO should be to develop a more insightful approach to GRC management.

The first step is to get everyone speaking the same language.

Adopt a standard language of GRC – the threat analysis base class

We formalize this language using a threat analysis base class which (like any other class), has attributes and methods. Attributes have two sub-types – threat entities and people entities.

Threat entities

Assets have value, fixed or variable in Dollar, Euro, and Rupee etc.  Examples of assets are employees and intellectual property contained in an office.

Vulnerabilities are weaknesses or a lacking in the business. For example – a wood office building with a weak foundation built in an earthquake zone.

Threats exploit vulnerabilities to cause damage to assets. For example – an earthquake is a threat to the employees and intellectual property stored on servers in the building.

Countermeasures have a cost, fixed are variable and mitigate the vulnerability. For example – relocating the building and using a private cloud service to store the IP.

People entities

Business decision makers encounter vulnerabilities and threats that damage company assets in their business unit. In a process of continuous interaction and discovery, risk is part of the cost of doing business.

Attackers create threats and exploit vulnerabilities to damage the business unit. Some do it for the notoriety, some for the money and some do it for the sales channel.

Consultants assess risk and recommend countermeasures. It’s all about the billable hours.

Vendors provide security countermeasures. The effectiveness of vendor technologies is poorly understood and often masked with marketing rhetoric and pseudo-science.

Methods

The threat analysis base class prescribes 4 methods:

• SetThreatProbability -estimated annual rate of occurrence of the threat
• SetThreatDamageToAsset – estimated damage to asset value in a percentage
• SetCountermeasureEffectiveness – estimated effectiveness of the countermeasure in a percentage.
• GetValueAtRisk

Speak the language fluently

A language with 8 words is not hard to learn, it’s easily accepted by CFO, CIO and CISO since these are familiar business terms.

The application of our 8 word language is also straightforward.

Instances of the threat analysis base class are “threat models” – and can be used in the entire gamut of GRC activities:  Sarbanes-Oxley, which requires a top down risk analysis of controls, ISO27001 – controls are countermeasures that map nicely to vulnerabilities and threats (you bring the assets) and PCI DSS 1.2 – the PAN is an asset, the threats are criminals who collude with employees to steal cards and the countermeasures are specified by the standard.

You can document the threat models in your GRC system (if you have one and it supports the 8 attributes). If you don’t have a GRC system, there is an excellent free piece of software to do threat modeling – available at http://www.ptatechnologies.com

Go green – recycle your threat models

Leading up to the Al Qaida attack on the US in 9/11, the FBI investigated, the CIA analyzed but no one bothered to discuss the impact of Saudis learning to fly but not land airplanes.

This sort of GRC disconnect in organizations is easily resolved between silos, by the common, politically neutral language of the threat analysis base class.

Summary

Effective GRC management requires neither better mathematical models nor complex enterprise software.  It does require us to explore new threat models and go outside the organization to look for risks we’ve never thought about and discover new links and interdependencies that may threaten our business.  If you follow the Tao of GRC 2.0 - it will be more than a fulfillment exercise.

Get  PTA ( Practical Threat Analysis) Professional software from our colleagues at Practical Threat Analysis Technologies totally free for one year. After the year is up, just drop them an email, and you’ll get a free license renewal.

When you perform risk assessment with the popular PTA (Practical Threat Analysis) modeling tool, you’re not only joining  thousands of security analysts all over the world who use PTA Professional in their risk and compliance practice, you all also get great software and valuable benefits.

You can perform an unlimited number of quantitative risk assessments for an unlimited number of clients  with their business assets and their  threat scenarios. Download the  free risk assessment software and while you’re at it –  download  the Software Associates Practical Threat Analysis library for ISO 27001 

• It’s quantitative: enables business decision makers to state asset values, risk profile and controls in familiar monetary values. This takes security decisions out of the realm of qualitative risk discussion and into the realm of business justification.
• It’s robust: enables analysts to preserve data integrity of complex multi-dimensional risk models versus Excel spreadsheets that tend to be unwieldy, unstable and difficult to maintain.
• It’s versatile: enables organizations to reuse existing threat libraries in new business situations and perform continuous risk assessment and what-if analysis on control scenarios without jeopardizing the integrity of the data.
• It’s effective: helps determine the most effective security countermeasures and their order of implementation, saving you money.
• It’s databased: based on a robust threat data model with the 4 dimensions of threats, assets, vulnerabilities and countermeasures
• It’s management level: with a few clicks, you can product VaR reports and be a peer in the boardroom instead of staffer waiting in the hall.

We performed a Sarbanes-Oxley IT top down security assessment for a NASDAQ-traded advanced technology company. The objectives for the study were to evaluate the internal and external threats that impact the company’s information assets. Using the Business threat modeling ^(BTM) methodology, a practical threat analysis PTA threat model was constructed and a number of threat scenarios were analyzed. Data was collected using structured interviews and network surveillance (with a Fidelis XPS appliance). Assets were valuated by the CFO and the IT security operations and technologies were valuated by the CIO. The output of the study was a cost-effective, prioritized program of security controls.This program was presented and approved by the management board of the company- leading to an immediate cost savings of over $120,000/year in the information security budget.

The detailed threat model was provided to the client and is currently used to perform what-if analysis and track the data security implementation. 

Download the data security case study and download the data security report to the management.

Conclusions

1. The bulk of the security budget is currently spent on sustaining network perimeter security and system availability. Not surprisingly, these countermeasures are not particularly effective in mitigating insider threats such as lost or stolen hardware and information leakage, which now dominate the company’s risk profile.

2. In corporate IT Security operations: The two major data security systems that were purchased in 2007, Imperva and Fidelis XPS Extrusion Prevention System have not yet been fully implemented and do not provide the expected benefit. To be specific, Imperva needs to be able to produce real-time alerts on violations based on logical combinations of OS user, DB application and DB user. Fidelis needs to be deployed in the subsidiaries. Monitoring from both systems needs to become a daily operational tool for the security officer.

3. In the Asia Pacific region: Loss of notebooks to the tune of 2-3 / quarter is a major vulnerability although content abuse of the corporate network is assessed as negligible due to cultural factors.

4. In general: Publicly facing FTP servers must be monitored carefully for violations of the company acceptable usage policy. In the course of the risk assessment, we discovered strategic plans and proprietary source codes that were stored on publicly accessible FTP servers.

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:

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

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

By using a small number of intuitive, building blocks (threats, assets, vulnerabilities and countermeasures),  clients are up and running in hours, understanding their risks and working towards compliance.

The objectives of threat modeling

The objective of the threat modeling process is to understand where are the security issues, how much they can impact the organization – and the most cost-effective way of mitigating the threats; whether they are threats from viruses and phishing attacks, disclosure of trade secrets in social media or theft of sensitive information that impacts the national security.

Why  is threat modeling relevant for HIPAA compliance?

Putting it simply – if you have 1 dollar to spend on compliance you have to spend it in the right way. That means identifying the top threats in the physical, software and operational areas and implementing the most cost-effective controls for HIPAA compliance.

Threat modeling excels in analyzing complex operational, software and hardware systems that integrate disparate infrastructures and technologies – an integrated system of Windows client operating systems, Java GUI, message queuing, Linux servers and open source databases such as MySQL is not an unusual example.

Threat analysis is valuable in identifying systems integration vulnerabilities, for example when  integrating your product with hospital EHR (electronic healthcare record) systems.

In new medical device development, from a software security and compliance perspective, threat analysis is best used throughout the entire SDLC (Software development life cycle) starting with the design – which typically accounts for 50% of the security vulnerabilities.

The problem – can you afford do do it on the cheap?

The cost of implementing security countermeasures in working code or integrated systems is high. There is often a temptation to look for DIY or bolt-on patches, leaving design and implementation defects in place. HIPAA requires a top-down risk analysis; threat analysis enables us to pinpoint the “hot” areas of risk and implement the most cost-effective security countermeasures. And yes – you may have to change platform and rewrite code.

The solution – keep it simple

With business threat analysis, application domain experts can quickly build and analyze threat models and policies without endangering the project schedule and deliverables. Knowledge is retained, shared and maintained within the group and program management has total transparency to system risk without the need for additional resources.

A security audit / risk assessment can be performed in days by a small team instead of weeks by large forces of outside consultants using pre-built checklists.

What are your alternatives?

Word and Excel

The analyst has the freedom to describe threats and vulnerabilities and express her analytical qualification in a free format with no restrictions dictated by the tool. However, the overhead of the data management and the calculation tasks is very high because of the lack of a built-in ability to represent the interrelations between entities and to dynamically alter the threat model. In reality the data model required for threat modeling is far beyond the capabilities of spreadsheet programs. In addition, most of these solutions also lack the necessary reporting functionality.

Checklists

There are predefined sets of HIPAA security recommendations available on the Internet or from a compliance consultant. This approach may work for standard applications where all possible security issues are known in advance. The odds of that happening are rather low.   You are better off flipping a coin.

Using Business Threat Analysis for HIPAA compliance

The Software Associates 6 step process for business threat analysis uses the Practical Threat Analysis (PTA) data model and quantitative risk assessment methods. The process provides an easy way to maintain dynamic threat models that are capable of reacting to changes in regulation, environment and product.

The threat modeling software automatically recalculates threats and countermeasures priorities and provides decision makers with updated action item lists that reflect the changes in threat realities. Countermeasure priorities are expressed as a function of system’s assets values, degrees of damage, threat probabilities and degrees of mitigation provided by countermeasures to the threats.

We recommend that  software development teams adopt threat modeling practices from day one of design and throughout the system development life cycle.  The threat model provides intuitive and easy ways for iterative interaction between threat analysts and developers. It supports a collaborative process of evaluating threats risks and ranking the cost-effectiveness of proposed countermeasures. The team’s “threat analyst” can be the program/product manager, system architect or development lead who can start being productive with the CASE tool within hours.

How does PTA specifically relate to HIPAA and ISO 27001?

HIPAA requires a top-down risk analysis and mandates adopting the right controls to minimize unauthorized disclosure of PHI assets. The ISO 27001 standard prescribe a set of countermeasures (or controls) without delving into the underlying vulnerabilities or considering asset value.

Defining a common terminology and process for threat modeling and analysis

In this section, we define a number of fundamental concepts in order to help the reader to easily understand the threat modeling and quantitative risk calculations.

Vulnerability is a weakness, limitation or a defect in one or more of the system’s elements that can be exploited to disrupt the normal functionality of the system. The weakness or defect may be either in specific areas of the system, its layout, its users, operators, and/or in its associated regulations, operational and business procedures.

Countermeasure is a procedure, action or mean for mitigating a specific vulnerability. A specific countermeasure may mitigate several different vulnerabilities. In some standards documentation, countermeasures are called “controls” or “safeguards”.

Asset is information, capability, an advantage, a feature, a financial or a technical resource that may be damaged lost or disrupted. The damage to an asset may affect the normal functionality of the system as well as of the individuals and/or organizations involved with the system.

Threat is a specific scenario of a sequence of actions that exploits a set of vulnerabilities and may cause damage to one or more of the system’s assets.

Asset’s Value is the financial value of an asset that is destroyed of stolen. Assets may be digital (software source, physical (a server) or commercial (a corporate brand).

Threat’s Damage to Asset - financial value of damage caused by a specific threat to a specific asset.

Threat’s Probability is the likelihood that the threat scenario will materialize. In some documentation the threat’s probability is characterized by the term “Annual Occurrence Rate” (AOR).

Threat’s Risk is a quantified measure of the likelihood of loss and/or damage that may be caused to one or more of the system’s assets due to the specific threat. In some documentation the threat’s risk is called “Annual Loss Expectancy” (ALE).

Threat’s Recommended Countermeasures is a set of all the possible countermeasures that reduce the threat’s risk. This set is based on the countermeasures that mitigate the threat’s vulnerabilities.

Threat’s Actual Countermeasures (AKA Threat’s Mitigation Plan) is a subset of threat’s recommended countermeasures that is assumed to be the most effective for mitigating a specific threat. The decision which of the recommended countermeasures will be included in the Threat’s Mitigation Plan is made by the analyst, who uses his expertise to decide which countermeasures are most effective when applied together.

Countermeasure’s Cost is the financial value that is associated with the implementation of a specific countermeasure.

Countermeasure Cost-Effectiveness is the degree of mitigation introduced by a specific countermeasure to the overall risk in the system in relation with the cost of implementing this specific countermeasure.

Additional Terms

Attacker is a person (or group of persons) that may perform the steps of a specific threat scenario.

Attacker Types are the various classes of attackers that are differentiated according to their motivation, qualification, available attack tools and their accessibility to the attacked system’s resources.

Entry Points are the “doors”, either in the system itself or in the human operation associated with it, that are used by attackers to penetrate the system, e.g. Web site, IVR service, SMS server, CRM representatives called by customers over the phone etc.

Area Tags are descriptive tags that are relevant to assets, threats, vulnerabilities and countermeasures. Classifying the various security entities in the threat model according to their areas improves the readability of complex threat models.

HIPAA Compliance project steps

1. Before starting HIPAA compliance project

As mentioned previously, the threat analyst identifies system vulnerabilities, predicts even the most hypothetical threat scenarios and evaluates threat probability and risk to enable prioritizing the corresponding countermeasures.

Before starting out, the analyst should learn the system functionality and architecture. The in-depth understanding of the system is of crucial importance for the correct identification of system vulnerabilities and the building of possible threat scenarios. The following documentation is needed.

• Functional description of the system including all typical use cases
• Architectural diagram of the system
• Documentation for various system modules

These documents must be detailed enough to be used as reference for the decisions regarding the applicability of various threat scenarios to the analyzed system.

2. Preparing a List of System Area Tags

It is a good idea to prepare a list of relevant system’ area tags that will help the analyst in mapping the various entities according to a variety of properties e.g. define area tags for each of the systems components that will enable the association of vulnerabilities with system’s architecture areas

3. Identifying System’s Assets

The correct mapping of assets, their financial value and the evaluation of financial loss to the system owner when these assets are damaged or stolen, is one of the most critical tasks in the threat analysis process. The assets value is used as the basis for calculating threat risks and countermeasures priorities.

An analyst may at times hear claims like “everything we have is important”. While this could be true for some systems, we believe it is not the typical case. It is more likely that assets need to be clearly prioritized. Consider, for example the following partial list of a financial institution assets:

• Office equipment such as printers
• Confidential information about institution’s clients
• Clients’ money
• Private keys used for authentication of transactions
• Master key used for generating private keys

The accurate assessment of the financial value of the damage that may be caused by losing each of the above assets will enable the correct classification of assets according to their importance to the institution and help avoid a situation where the institution invests resources in protecting printers while leaving the master key unprotected.

In some cases the value of assets is less intuitive especially when they are intangible. For example, the confidence of the public in an electronic trading system may be damaged by the appearance of non-relevant texts on the system’s Web site. No money is lost, no information is disclosed, all technical resources are still functioning but the site reputation and the trust of the shoppers are shaken. An indirect financial loss should be set for this type of damage.

Due to the importance of asset mapping, we recommend that the asset list and corresponding values be periodically checked by non IT personnel e.g. the company’s CFO, marketing officers and legal consultants. An analysts can quickly do “what-if” analysis by modifying asset values and obtain insight as o the model’s accuracy and completeness.

In practice, it is often easier for the analyst to identify system assets via the process of analyzing specific threats (as described in step 8). It is a fact of human nature that we don’t realize how valuable things are until we lose them. This implies an iterative approach of mapping assets and threats.

4. Identifying System’s Vulnerabilities – the real ones

Identifying vulnerabilities requires the analyst to be intimate with the system’s functionality, architecture, implementation and deployment details. The analyst should also be familiar with business and operational procedures and the types of users and other parties that are involved in system operation.

An analyst can use Google to find generally known vulnerabilities as published by software vendors and security consultants. Most of the items in these check lists are, in many cases, irrelevant to the specific system or may be easily solved by a simple comprehensive routine such as “always install most updated vendor’s security patches”. The thing that should concern us here is that such a list will draw the attention of the analyst away from the real vulnerabilities that are specific to the system that is being analyzed.

Therefore we highly recommend that the analyst should investigate the system architecture and implementation details and collaborate with architects, developers, installers and support engineers as well as with the business managers of the system to discover the real vulnerabilities that are unique to the system and that probably may not be identified without this intimate knowledge. From experience – the most severe vulnerabilities reside in the interfaces, junctures and stitches between the various elements in complex systems and rarely appear in the standard lists.

As mentioned before, the identification of the relevant vulnerabilities is a continuous iterative task that is associated with the step of identifying threats (step 8 below) – sophisticated vulnerabilities may be identified when building threat scenarios.

5. Identifying Countermeasures

Identifying countermeasures has two outputs:

• A list of countermeasures that protect vulnerabilities. The list includes the implementation cost of each countermeasure and the countermeasure’s relevant area tags. If the countermeasure is already applied it should be marked as ‘already implemented’ to enable producing updated statistics of the total risk level in the system.
• A map of the relationships between countermeasures and vulnerabilities. This map shows which vulnerability may be mitigated by a specific countermeasure. Sometimes a countermeasure is introduced as a solution to a specific vulnerability, but after additional consideration it turns out that it may help in mitigating other vulnerabilities too.

The accurate identification of countermeasures and their relations with vulnerabilities is the basis for building risk mitigation plans as described in the next steps.

6. Classification of Potential Attacker Types

Classification of the relevant attacker types may be helpful in focusing the analysis on practical realities. The classification of attackers is useful when we can clearly relate each of the threats with one or more of the attacker types.

Attacker type’s data includes the understanding of his motivation as well as his qualification, available attack tools and his accessibility to the system’s resources. Special care should be given to classification of ‘insiders’ attacker types since their activity may be very dangerous.

A good starting point may be to define an attacker type for each of the user roles that appear in the system use cases and reserve few more attacker types to hackers and other types of bandits.

7. Identifying System’s Entry Points

The best tactic for this step is to review the list of attacker types and document every possible way the potential attackers could access the system. List of entry points may be revisited and clarified while analyzing threats.

8. Building Threat Scenarios and Mitigation Plans

This is the most important step of the threat analysis process. The outcomes are:

A list of system’s threats

• A map of the relationships between threats and area tags, assets, attacker types, entry points and vulnerabilities
• An evaluation of the total damage and risk parameters for each of the threats
• Mitigation plans and residual system’s risk data

Since threats are the most complex entities in the model, the process of identifying and constructing threat’s elements and parameters has a ‘decomposition’ flavor. During this process the analyst will have to return to previous analysis steps in order to create missing entities, such as assets and vulnerabilities that are referenced by the threat that is constructed. In the following we describe the sub-steps of building a threat scenario and a mitigation plan for a single threat.

9. The output of the HIPAA compliance process

The HIPAA risk analysis process provides a number of reports and management level information

• List of system’s threats sorted by their risk
• List of system’s threats sorted by the financial damage they cause
• List of individual countermeasures sorted by their overall risk mitigation effect
• List of countermeasures sorted by their cost effectiveness (mitigation divided by implementation cost)
• Maximal financial risk caused to each asset by existing threats
• Maximal financial risk caused to each asset by existing threats after all mitigation plans are implemented
• Maximal financial risk caused to each asset by existing threats after partial implementation of mitigation plans (use the ‘already implemented’ flag in countermeasures)
• Total financial risk including all assets
• Total financial risk after all mitigation plans are implemented
• Total financial risk after partial implementation of mitigation plans

Reviewing these results with the client management helps refine the threat model. Using the threat model, enables the client to run “what-if” scenarios without changing hardware/software/operational procedures and deepen management understanding of the company’s risk profile.

Our consulting engagements are usually completed within 1 to 3 months for a data security and compliance project and 6-12 months if the software needs to re-factored with appropriate security countermeasures. We team with client management to focus on reducing system risk with practical methods and technology in the best possible schedule. Our capability to properly evaluate risk comes from our 6 step systems approach  and rich experience in developing entire systems: front-end GUI, back end processing, data modeling, systems integration, server engineering, information security, billing, network management, IT applications integration and secure transaction using rich Web 2.0 applications.