Page 212 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY
P. 212
Information Security and Privacy
Notes
Notes The significant point to observe here is that we always wish to exclude details like
these from our high-level behavioral models. Our intent at the high-level modeling stage
is just to note, for instance, that a specified function needs authorization before it can be
executed, without detailing how that authorization will be completed.
The issue of the privacy domain is to make sure that you view only the information that is you
are authorized to view, and that other parties do not see information they are not ordered to see.
Businesses both consume and produce large amounts of data, which is accumulated, manipulated
and passed around to assist the running of the business. We have to make sure that information
that is sensitive in nature is guarded and that we offer a method to know who is requesting or
offering information and services.
!
Caution We require to know not just which service was the requester or provider, but
which authenticated end user was a party to the transaction via that service.
There are two different intents related with the privacy domain:
1. The objective to sign a message or document (potentially by means of multiple signatures)
recognizing the end user(s) or service(s) that formed the message or document. This
intent, which depends on a number of common standards for digital signatures, is accessed
in B2B commerce, government commerce, and even more broadly in corporate e-mail
conversations. A document may have a number of signatures.
Example: A supply requisition may be signed by the originator, their manager (approver)
and ultimately the purchasing department when the order is positioned; all of these signatures
goes with the document.
2. The objective to make sure the privacy of a message, either by sending it over a protected
medium or by encrypting or else securing the content. This goal is probably the region
with the most variability in the options for execution.
Example: In considering message converting services we can take into account that the
message itself is encrypted by the sender and then sent over a protected channel, that the
message is sent as plain text over a secure transport like HTTPS or TLS (both of which actually
offer encryption as a part of the service, but outside of the sender’s control) or even that the
message includes an identifier for a document sent by some other protected means.
Another issue that is frequently cited is that of data integrity – the requirement to make sure
that the contents of a message or document cannot be modified en route among the numerous
parties to the transaction. A message or document that has data integrity is considered to be
tamperproof. The anticipation is that if a message is observed as private it should be tamperproof
also; though, it should also be possible to signify that a message is just tamperproof without
needing a privacy solution.
Finally, the implementer’s role is to offer a solution that fulfills the requirements of data privacy
in common with guidelines laid down by the business.
Example: It would not be adequate for an e-commerce Website to use a courier to
broadcast each customer’s credit card number to the bank for verification, while couriers might
be an excellent option for delivering secret government documents.
206 LOVELY PROFESSIONAL UNIVERSITY