CSE870 Advanced Software Engineering
Security Policy and UML Diagrams
First, we need to create a security policy for BECS system. We can do that by first identifying possible
threats to the system.
List of Possible Threats
1.
2.
3.
4.
The communication between remote user and the system can be wiretapped. Information,
such as credit card numbers, can be stolen this way.
User might be able to perform unauthorized access, such as customer logging in using
manager’s account.
Information provided by the user, such as credit card number, might not be valid.
Data, such as sale logs or inventory information, can be lost.
(Note that we do not consider some physical threats, such as breaking into the site, here since they are
beyond the scope of Software Engineering)
Then we create a policy to handle these threats.
Security Policy
1.
2.
3.
4.
5.
Access control
a. Manager has complete access to and all privileges for changing the inventory and
accounting system. These privileges includes add/remove/update items from inventory
and accounts from accounting system. The manager can also add/remove/update
promotion information.
b. Customer can register, browse inventory and promotional information, and make a
purchase. Customer cannot modify inventory, accounting system, nor sale log system
directly.
Authentication
a. Password
i. For customer, password must be at least 6 characters in length and not include
dictionary words.
ii. For manager, password must be at least 8 characters in length with the following
constraints:
1. At least two of the characters must be numeric.
2. At least two of the characters must be alphabetic.
iii. For manager, IP address will also be checked. If the IP address is not part of the
BECS domain, then the access is denied (only local access for manager).
Backup policy
a. Sale log and inventory will be backed up hourly. If the current object is lost, then these
“snapshots” can be loaded into the system.
Secure Transaction
a. Important communications between remote user and BECS will be encrypted using the
RSA scheme. These communications are:
i. Login (username and password)
ii. Credit Card Numbers.
Data validation.
a. Credit card numbers provided by the user will be validated before approval.
b. Only then credit card number will be stored, encrypted, in the system. Validation
information, such as expiration date and cardholder’s name, will be provided by the
customer for every transaction.
After we have a policy we need to modify our UML diagrams to capture the policy:
1.
The class diagram should contain new classes (such as encrypters and decrypters) and new
relationships that arise in the security policy. (only relevant classes will be shown here for
readability)
a.
First, there will be threes classes added; Encrypters, Decrypters and Credit Card
Verifier.
Encrypters and Decrypters
Class:


Decrypter
System-side decrypter that decrypts login information and credit card number
Attributes:
o int privateKey
:
RSA private key of the decrypter.
o int publicKey
:
RSA public key of the decrypter.
Operations:
o void genKey
 Purpose: To generate a pair of private key and public key.
 Parameters:
N/A
o int getKey
 Purpose: To give public key for client-side encrypter to use.
 Parameters:
N/A
 Return:
Integer value of decrypter’s public key.
o String decrypt
 Purpose: To decrypt given message using decrypter’s own private key.
 Parameters:
 Message (String) encrypted message to be decrypted.


Class:




 Return:
Decrypted message.
Relationships: It is used by account manager (for decrypting login information) and shopping
cart (for decrypting credit card number).
Uses Cases:
Login and Purchase Items
Encrypter
Customer-side encrypter used to encrypt login information and credit card number.
Attributes:
o int targetKey
:
Public key of BECS-side decrypter.
Operations:
o String encrypt
 Purpose:
To encrypt the given message using targetKey.
 Parameters:
 Message (String):
Message to be encrypted.
 Return:
Encrypted message.
o void setKey
 Purpose:
To set the value of targetKey. This method will be called
when encrypter is created.
 Parameters:
 New_Key (int): New public key.
Relationships: It is used by manager (for encrypting login information) and customer (for
encrypting login information and credit card number).
Uses Cases:
Login and Purchase Items
Credit Card Verifier
Class:




CreditCardVerifier
Object from this class is used to verify credit card number provided by the user.
Attributes:
N/A
Operations:
o boolean verify
 Purpose:
To verify a credit card number.
 Parameters:
 CCN(String)
: String of 16 digits representing a credit card
number.
 Cardholder_Name(String) : Name of the cardholder.
 Expire_Date(String)
: String of 4 digits representing expiration
date (MMYY).
 Return:
true if CCN is valid and supplement information is correct,
false otherwise.
Relationships: It is used to verify credit card number by Shopping Cart in checkout().
Uses Cases:
Purchase Items.
Note that old classes will also be modified. For example, the method checkout() of the class Shopping Cart
now has return type of boolean in case the credit card number is invalid.
Also, some changes from security policy, such as password restriction, cannot be adequately represented in
class diagram. You should present those changes in data dictionary, or notes in class diagram. Behavioral
changes should also be presented in sequence and state diagrams.
2.
The sequence diagrams should reflect the flows of information depicted in the policy.
Example customer login
3.
The state diagram of a class should show the class’s behavior conforming to the policy.
Example Account Manager (login control system).