[
Lists Home |
Date Index |
Thread Index
]
Ah!
This is why you have ebXML CPA - collobration protocol agreements and
asynchronous exchanges.
I agree - webservices are especially prone to this kinda creative "mining" of
information, or abuse of access priveledges to resources. We first
encountered this problem in real-time EDI. Same sales pitch - same outcomes.
So the CPA delimits what exchanges you can initiate - and they are part of a
perscribed business process - so it is most difficult to turn this into an open
ended fishing expedition!
Now this kind of layering to the problem *does* make sense! Which is why I
mentioned I get al kinda cranky on people who insist on 'just define the schema
for me' as the solution path. First start with the business needs, and then
work top down to the actual information exchange - which coincidently happens
to be the *last* thing you end up creating - not the first!
Cheers, DW.
==================================================================
Quoting "Bullard, Claude L (Len)" <len.bullard@intergraph.com>:
> That used to be called the 'mosaic problem' in
> security circles years ago. Enough 'no's outline
> the shape of the thing. If you need to protect
> the thing, you have to return an answer of
> "I cannot confirm or deny.." and then they
> know something is important but not exactly what.
> Meanwhile, the repeated attempts and negative
> answers emit a pattern of behavior that can
> be detected which is why we have time/node
> stamps on queries and all of that metadata
> is sucking up cycles. So yeah, hardware indeed.
>
> Sigh... so much spy vs spy work.
>
> len
>
>
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
>
> It's got nothing to do with content, rather it's the problem that
> privacy rules (business rules) can be violated by negative responses.
> To work around that requires that you understand the context of the
> query and the results in combination with each other. This is one of
> those areas, where if you have to solve the problem, you can likely
> justify throwing non-trivial amounts of hardware at it...
>
|
