Re: FPT_SEP in an Application TOE

["YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>]

Thanks Dirk-Jan

I'll continue ....

The threat:
An attacker at an ATM machine withdraws money from the account of an account
holder through that ATM machine.

Although this threat does not mention the bankcard, I understand this threat
is written specifically for leading to the measures of the TOE ( i.e.
bankcard ).

If not, if the threat means more broadly, then we may need to consider the
following measures.

An ATM must be sited within 500m from a police station.
An ATM site must be prepared with an emergency call button.
Each ATM operation must be captured by the video camera.
...
Or, alternatively and more generally, we might say, an ATM must be placed in
a secure site.

Those measures could be led from either environment assumptions or threats.
The justification of measures of the TOE may need a bit more statements
considering those assumptions (i.e. removing some threats).

I think, the environment assumptions are not a matter what developers
elaboralte for the completeness.
It is largely a matter what consumers and system integraters do elaborate.

I feel, though not sure, customer and integrator would be happy and find
values in the ST when the ST is focused and demonstrates what specific
threats are countered by the TOE, rahter than it demonstrates that the TOE
and environment can together solve all of problems on the assets to be
protected.

In that way, I feel the ST could be more friendly to consumers, developers
and evaluators.


----- Original Message ----- 
From: "Dirk-Jan Out" <out@itsef.com>
To: "Multiple recipients of list" <cc-cmt@nist.gov>
Sent: Wednesday, October 27, 2004 5:24 PM
Subject: Re: FPT_SEP in an Application TOE


>
> >
> >
> >
> >I admit that those threats I mentioned were not good examples to
demonstrate
> >the level of abstruction.
> >
> >I agree that some extent of abstruction is positively allowed by the CC.
> >When I said "specific detailness", I meant to describe the threats in the
> >level of abstruction as the evaluators can determine the sufficienty of
the
> >mesures to counter the threats.
> >
> >In this meaning, sometimes, even threats agent could be ommitted or be
too
> >general (e.g. someone ) in the statement.
> >
> >On the other hand, if you describe the threat as like "an attacker may
> >violate the security of the TOE", any list and any kind of measures could
> >not be able to counter it sufficiently, except for such useless measures
as
> >"the TOE shall be protected from the security violation form an
attacker".
> >
> Dear Yokota,
>
> The last threat cited above exactly misses the point that v2.4 is trying
> to make.
>
> A typical threat for a bank card (in v2.4) is: An attacker at an ATM
> machine withdraws money from the account of an account holder through
> that ATM machine.
>
> Note that this threat does not mention the bankcard at all. It only
> mentions the assets that the bank card is protecting (the money in the
> bank account).
>
> And in essence these v2.4 threats ARE saying "The assets shall be
> protected from violation by an attacker" but the point of a threat
> statement in v2.4 is listing:
> - which assets are you protecting (money in bank account)
> - which violation ( integrity in this case)
> - in which operational environment (at the ATM machine interface), not
> e.g. at the bank itself
>
> Dirk-Jan
>
> -- 
> -------------------------------------------
> TNO ITSEF BV
> Delftechpark 1          tel +31 15 269 2525
> 2628 XJ Delft           fax +31 15 269 2555
> The Netherlands         www.itsef.com
>
>
>
>
>
>