Page 209 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY

Unit 14: Web Services and Privacy

notion was to present a simplified set of options to the business architects — the main stakeholders Notes
from whom the RosettaNet team gathered data and processing requirements. These business
architects were not versed in the technical details of the security issues, but they were able to
contrast data that required to be passed in a secure way from data that could be sent without
security measures.
Though, one problem with this method was that a simplified terminology was imperative. As
soon as the terms became complicated, the business stakeholder would request every obtainable
type of security, just to be secure, and that effected in sub-optimal designs. It was this behavior
on the portion of stakeholders that led the architecture group to set out easy guidelines on the
specification of such constraints in addition to descriptions that the client could understand.
Doing so gave stakeholders the insight they required to make informed cost/benefit trade-off
decisions.

Example: The RosettaNet team used examples to help the business user understand
when the cost of encrypting data was far greater than the value of the data being protected.

14.3.3 Generalization of Security Issues

There are many texts on common software security concerns, and many more on specific security
executions and technologies. Though, we would like to be able to address the underlying intent
that drives security-linked technical executions. Particularly, we would like to be able to mention
a set of descriptive primitive intents that are simple to understand, and that can be accessed to
identify specific technical executions.

Let us take a general instance: withdrawing cash from an ATM machine. Initially, when I walk
up to an ATM machine, I am asked to offer two things: my ATM card (which performs as formal
identification) and a personal identification number (PIN), which is a “shared secret” familiar to
me and my bank, but to no one else. The ATM can now take the identification information and
PIN and ask my bank if the person standing in front of it can be presumed, with an acceptable
level of confidence, to be the account holder. If the issuing bank verifies the supplied details, it
sends back to the ATM a set of security credentials that offer additional information on the
account holder. Depending on this account-particular information, the ATM then shows the list
of actions I am authorized, as the account holder, to perform — actions that might involve
“withdrawal”, “deposit,” and so on.

Notes Note that this set of choices really represents the intersection of two sets:
1. The set of all operations this particular ATM is capable of performing.
2. The set of all operations the issuing bank verifies that I am eligible to perform.

The credentials sent by the bank usually include a restriction on the amount of cash I can
withdraw in any single transaction-a limit that the ATM itself can enforce. The ATM system
architect must also offer an audit trail by logging all the information flowing to and from the
ATM.
How is this communication among bank and ATM completed? How can the bank trust the
information it obtains from the ATM and vice versa? Technical details like these, linked to
security protocols, data encryption and so on, are both significant and interesting — but these
are mainly the kind of details that are outside the level of any high-level behavioral model.

LOVELY PROFESSIONAL UNIVERSITY 203