, , , , , , , , , , , , , ,

I’ve spent the last week trying to get my head around the Threat Assessment Model for Electronic Payment Systems (TAME), which appears in a couple of academic papers co-authored by Stillianos Vidalis, of the University of Wales Newport. I have no idea whether TAME is applied in real-life at this point, or even if there’s any standard methodology in use in the infosec industry.

As the name suggests, it’s basically a ‘framework’ for threat assessment, and consists of four stages:
1. Assessment scope
2. Threat and vulnerability analysis
3. Scenario construction and system modelling
4. Evaluation

TAME was developed primarily for Electronic Payment Systems, but that kind of makes it well-suited for enterprise networks in general, because EPS involves interactions between many distributed entities, numerous users, developing/emerging technologies, huge databases of financial records, and secure transaction methods. Confidentiality, integrity and availability are all essential to its operation.
Any decent threat assessment relating to a network of that scale must cover everything, and must also be repeatable as conditions, technologies and threats constantly change. Most importantly, this isn’t about management or ticking the boxes – TAME emphasises the need to fully understand the network, the technology, how the organisation operates, and all conceivable ways in which the network can be targeted.

Assessment Scope
This stage examines the organisation’s goals and the processes for achieving them. In doing this, critical assets, which are assets essential to operations, are identified. The scope defines what should be covered in the assessment, and usually it extends to whatever the organisation has immediate control over. In real life, advanced threats will often compromise organisations through the supply chain, so the environment it’s operating in should also be considered. Assets have been categorised as:
* Software
* Hardware
* Data
* Comms
* Admnistrative
* HR
* Physical

Threat and Vulnerability Analysis
Since the paper was published, there have been definite changes in the threats and their characteristics, so the categories listed need amending and new ones added. All the recent ‘cyber’ fuss in mainstream sources, disregarding the background noise, has also provided useful intel to help us make generalisations on how the threats operate.
For example, we learned there are limits to the capabilities of terrorist groups. As I’ve explained in the past, ideological groups tend not to have the skills required for conducting advanced network-based attacks, but they can certainly intercept communications and use that in planning a physical attack. There are also subcategories of ‘Enhanced Small Agent’, the ones I can think of being the ‘script kiddy’ who carries out denial of service against networks and runs automated exploit stuff, and the skilled cracker.
Yet another category to add is the insider threat, because the most damaging attacks could involve employees/members of the organisation who already have access to the network, knowledge of which assets are important, and perhaps a real motive for compromising the organisation.

During the threat analysis, judgements are made about which threat agents have both the intent and capability to successfully attack the organisation’s network. Usually opportunity is given as a third factor, but it’s one I’d ignore, as security is about minimising that anyway. There are ways of matching each identified threat with identified vulnerabilities, which I’ll cover in a future post.

Scenario Construction and Modelling
Ideally this would be a detailed object-oriented or descriptive model, complete with the relationships, vulnerabilities, processes, assets and identified threats. A number of possible attack scenarios can be tested against this model.

The output here will be the relevant threats mapped to network vulnerabilities and the assets essential for operations. At the top of the list will be the most dangerous and probable threat agents, and this should determine the order in which countermeasures are deployed.