An information system at Financial Institution provides support
for point of sale systems for financial transactions. Security issues in
such system concerns both the system developer and the system user. The
remote input systems are located at Retailers sites (in the "field" outside
of the financial institution itself) and are used by the Retailers to allow
their customers to pay for their purchases. Other pertinent financial services
are provided to the Retailers that can be done through the system. The
system itself consists of a Base Station (BS) and a set of Terminals, and
a Host computer. Terminals are connected to the Base Station via a LAN,
while the Base Station in connected through a leased or dial-up line to
the host computer located at the financial institutions. A software development
contractor develops the financial transaction software that resides at
the Retailers and on the Host computer. The hardware is purchased externally
from a Manufacturer. There are two "business processes" relevant for this
example: 1. When the system is newly deployed. 2. When Terminal software
need to be updated.
Case 1: When the system is newly deployed:
The developers receive hardware from the manufacturer, and load the initial version of the software into the system. The system is then provided to the financial institution where it is validated. The financial institution then provides the system to retailers and keeps track of what software and hardware was provided to whom, and other pertinent information relevant to the Retailer (such as special configuration data). Finally, the Retailer operates the system.
Case 2: When the system is updated:
Developers provide updates to the financial institution. The Financial
institution uploads the updates to their host computer. Maintainers in
the field download the updates into the base station, from where they then
transfer it to the terminals.
ELEMENT Software
ELEMENT TerminalSoftware
ELEMENT BaseStationSoftware
ELEMENT HostComputerSoftware
The following statement defines a softgoal on the security of the software of the system:
SOFTGOAL Security OF Software
SOFTGOAL SoftwareSecured IS Security OF Software
SOFTGOAL OperationalSecurity OF Software
SOFTGOAL DevelopmentalSecurity OF Software
CONTRIBUTION
OperationalSecurityOFSoftware,
DevelopmentalSecurityOFSoftware
HAS And CONTRIBUTION-TO SecurityOFSoftware
These statements refine what "Security OF Software" means. It means security of software during operational activities, that is all activities related to the provision, updating, and regular working of the software, and it means security of software during development activities. The contribution statement also states that both ("And") are needed in order to ensure security of software. Security is not dealt with well when having stringent security for operations, while having "free" access to the source code during development.Next, we recognise that for operational security, one should distinguish between operations that take place within financial institution and the development site, and operations that take place outside of these boundaries, such as at the Retailers site. This distinction can be shown as follows:
SOFTGOAL InternalOperationalSecurity OF SoftwareSOFTGOAL ExternalOperationalSecurity OF SoftwareCONTRIBUTIONInternalOperationSecurityOFSoftware,ExternalOperationalSecurityOFSoftwareHAS And CONTRIBUTION-TO OperationalSecurityOFSoftware
We now also wish to distinguish among security that is related to the securing of the Terminal and of the Base Station and security measures related to the host computer that might be attached through activities performed externally. These considerations are expressed by the following definitions:
SOFTGOAL ExternalOperationalSecurity OF TerminalSoftware
SOFTGOAL ExternalOperationalSecurity OF BaseStationSoftware
SOFTGOAL ExternalOperationalSecurity OF HostComputerSoftware
CONTRIBUTION
ExternalOperationalSecurityOFTerminalSoftware,
ExternalOperationalSecurityOFBaseStationSoftware,
ExternalOperationalSecurityOFHostComputerSoftware
HAS And CONTRIBUTION-TO ExternalOperationalSecurityOFSoftware
We could now make another distinction between securing application related software and operating system software, if we wish to deal with them differently. Perhaps operating system software for the pieces of equipment needs at least as stringent security measures as the financial applications running on top of them. However, we will not introduce this distinction here.Let us now further focus on the TerminalSoftware and refine security into confidentiality, integrity and Availability. Confidentiality is protection against unauthorized disclosure. Integrity is protection against unauthorized update or tampering, and availability is protection against interruption of service through outside attacks. This refinement makes the meaning of security more particular in that we know what aspects of security we would further like to address. This refinement is expressed by the following definitions:
We will now focus on the operation of update, download and storage provided by the terminal software for which we wish to have confidentiality ensured. This is shown by the following statements. Note that in order to shorten the names of the softgoal we will override the internally generated name. We will use the acronym EOC standing for "ExternalOperationalConfidentiality": SOFTGOAL ExternalOperationalConfidentiality OF TerminalSoftwareSOFTGOAL ExternalOperationalIntegrity OF TerminalSoftwareSOFTGOAL ExternalOperationalAvailability OF TerminalSoftwareCONTRIBUTIONExternalOperationalConfidentialityOFTerminalSoftware,ExternalOperationalIntegrityOFTerminalSoftware,ExternalOperationalAvailabilityOFTerminalSoftwareHAS And CONTRIBUTION-TO ExternalOperationalSecurityOFTerminalSoftware
SOFTGOAL EOC_OFTerminalSoftwareForStorage IS
ExternalOperationalConfidentialityForStorage OF TerminalSoftware
SOFTGOAL EOC_OFTerminalSoftwareForDownload IS
ExternalOperationalConfidentialityForDownload OF TerminalSoftware
SOFTGOAL EOC_OFTerminalSoftwareForUpdate IS
ExternalOperationalConfidentialityForUpdate OF TerminalSoftware
CONTRIBUTION
EOC_OFTerminalSoftwareForStorage,
EOC_OFTerminalSoftwareForDownload,
EOC_OFTerminalSoftwareForUpdate
HAS And CONTRIBUTION-TO EOC_OFTerminalSoftware
TASK AccessAuthorization
TASK LimitExposure
TASK Encryption
CONTRIBUTION
AccessAuthorization,
LimitExpose,
Encryption
HAS Make CONTRIBUTION-TO EOC_OFTerminalSoftwareForDownload
GOAL Authentication
GOAL Identification
Authentication can be done by using digital signatures, biometrics, card key and card reader equipment or password protection. Let us describe those alternative uses.
TASK DigitalSignatureAuthenication
TASK BiometricsAuthenication
TASK CardkeyAuthenication
TASK PasswordAuthentication
MEANS-END FROM DigitalSignature TO Authentication
MEANS-END FROM BiometicsAuthentication TO Authentication
MEANS-END FROM CardkeyAuthentication TO Authentication
MEANS-END FROM PasswordAuthenication TO Authentication
TASK OneSidedID
TASK MutualID
MEANS-END FROM OneSidedID TO Identification
MEANS-END FROM MutualID TO Identification
Each one of the alternatives discussed is able to address the confidentiality requirements for updating the terminal software. However, each alternative has a different set of tradeoffs among other quality requirements that might be of importance. For example, using BiometricsAuthentication would provide a high-level of security, however, would be very expensive to provide. On the other hand, using a Cardkey Authentication is less expensive, but still needs some equipment and very user friendly. Finally, using password protection is the least expensive but has not the same user friendliness as the cardkey reader. We would model this kind of reasoning through correlation links to other softgoals.Finally, in order to demonstrate the Belief construct, let us add a justification for our claim that using Biometrics has very negative impact on the purchase cost of the terminal. We support the very negative impact by the belief that "Biometrics is no regular off-the-shelf technology" and thus still very expensive to provide. Since the Belief is linked to a correlation link, we override the machine-generated identifier and provide a correlation link identifier of our own. This identifier is then used in the BELIEF clause.
ELEMENT TerminalSystemSOFTGOAL PurchaseCost OF TerminalSystemELEMENT TerminalSystemUserInterfaceSOFTGOAL UserFriendliness OF TerminalSystemUserInterfaceNote that we specify here the correlation link identifier and name it BiometricAuthenticationCorrelationLink. This name is then used when declaring the Belief intentional element.This Belief link is added at the bottom of the following diagram. CORRELATION BiometricAuthenticationCorrelationLink ISBiometricsAuthenticationHAS Break CONTRIBUTION-TO PurchaseCostOFTerminalSystemCORRELATIONCardKeyAuthenticationHAS Some- CONTRIBUTION-TO PurchaseCostOFTerminalSystemCORRELATIONCardKeyAuthenticationHAS Make CONTRIBUTION-TO UserFriendlinessOFTerminalSystemUserInterfaceCORRELATIONPasswordAuthenticationHAS Make CONTRIBUTION-TO PurchaseCostOFTerminalSystemCORRELATIONPasswordAuthenticationHAS Some- CONTRIBUTION-TO UserFriendlinessOFTerminalSystemUserInterfaceThe textual description of this link is:
All the correlations described provide a basis for evaluating the alternative approaches that may be taken to ensure confidentiality, i.e., unauthorised disclosure of update and related information of the terminal software updates.BELIEF BiometricAuthenticationCorrelationLink "Biometric is no regular off-the-shelf technology".
In order to illustrate actor related features of GRL, let us consider the following diagram. We wish to show two Actors participating in the deployment process described in case 1. Both Actors are concerned about security; however, each one may make different choices, based on actor context-dependent considerations.The first diagram shows the Developer actor (i.e. the people within the development organization), and parts of the process to deploy the software system to the financial institution. During this process, first the developed software is loading onto special purpose hardware (that was supplied by the manufacturer), and then the system deliverables (both software and hardware) is provide to the financial institution.
The diagram shows that there are security concerns related to the deploying of the system. This security requirement is addressed by requiring authentication before loading of the software onto the hardware can commence. The AuthenticateLoader GOAL shows that two alternatives authentication options are considered: use Biometrics or use a Card Reader. As we have seen in the previous example each alterative has different tradeoffs. Biometrics authentication provides very good security. This is denoted by the Make contribution link from BiometricAuthentication Task to the Security Softgoal. It is, however very costly, which is denoted by the Hurt correlation link from the BiomtricAuthentication Task to the Cost Softgoal. The CardRead authentication provides good security, albeit to a lesser extent than Biometric authentication. This is denoted by the Some+ contribution link between CardReaderAuthentication Task and the Security Softgoal. Card Reader technology is, however, less expensive. This is denoted by the Some- correlation link between CardReaderAuthentication Task and the Cost Softgoal. Note that a Belief node is added to explain why Card Reader Authentication is less secure, since cards can be stolen, which introduces a concern not applicable to Biometric Authentication.
Note that contribution links are used to denote the primary reason for the choice of Tasks, while correlation links denote "side-effects" that relate to these Tasks. Finally, the diagram also adds the Belief "Card can be stolen" to support the fact that CardReaders are only providing "some+" contribution to the Security Softgoal.
This diagram illustrates that reasoning related to Softgoals may be "context dependent" and needs to be considered within the boundaries of an Actor. For the Developer Actor, we can argue that the Development organization is very concerned about Security. It may even be an important factor to being chosen a supplier of the financial institution. They would therefore rather choose Biometric Authentication than Card Readers, although it is the more expensive authentication method.
The next diagram shows the Financial institution Actor now receives the system deliverables and wishes to deploy the system further to its Retailer clients. During its deployment process the financial institution first verifies the system deliverables. This is denoted by the VerifySystem Task. Note that this task is dependent on receiving the system deliverables from the Developers. This dependency is denoted by the TheSystemDeliverable Resource dependency link between the Developer actor and the Financial Institution Actor. The next step in the financial institutions’ deployment process, is to data relate to the distribution of the system. This data involves among others handling of the systems software to be distributed. Similarly to the Developers Actor, the Financial Institution is concerned with Security, and wishes to Authenticate users who deal with the tracking system. In this example, the same alternatives for authentication are considered. However, the financial institution may argue, that since its premises are rigorously secured anyway, Biometrics would be "overkill", while a CardReader authentication system might be enough for securing the access to the software code that is uploaded for further distribution (within the tracking system). Note that if the Security Institution would already have Card Readers installed on site, then using a card reader would have a synergistic effect on the costs involved for authentication. Since such systems are already widely used anyway. This consideration was, however, omitted from the diagram, and would have involved a correlation link between the CardReaderAuthentication Task and the Cost Softgoal of some positive extent.