Security Requirements

COMP201 Lectures 2021-10-08

Security is required in computer systems as they often handle money and customer data. Having these exposed could have costly repercussions to a company.

You can break down the security requirements of a system into the following issues:

• Confidentiality
• Integrity
• Authentication & Authorisation
• Non-repudiation

Availability can also be a requirement of secure systems.

Confidentiality

There are usually two main options:

• Encryption (Hard security)
• Permissions (Soft security)

Data must be kept secure in the following circumstances:

• In storage (final or intermediary).
• On the wire or wireless link.
• For as long as reasonably possible.
  • Should depend on the circumstances.

Integrity

Messages or data must not be modifiable without knowledge of the change. There are several approaches:

• CRC checking (not good for security).
• Hash value of data (can be recomputed).
• Hash value over data + secret value.
  • Key must be distributed to the recipient.
• Hash value encrypted using asymmetric cipher.
  • Easier to manage keys.

Authentication & Authorisation

• Authentication - Identifying a user.
• Authorisation - Permissions on the system.

You can use usernames, passwords, hardware keys & bio-metrics to confirm authentication.

This if often the first point of attack.

Non-Repudiation

This is when you are sending messages but you want to prove at a later date and time, what the message was and when it was sent.

This often requires:

• A trusted broker.
  • Messages are sent to a third party server and then forwarded to the recipient.
• Funding is escrow.
  • Allows money to be stored until the transaction is complete.

This is built upon:

• Authentication
• Integrity
• Recording a time stamping.
  • Via a trusted third party server.
• Broker style services.

Availability

We specify this in the “9s” terminology:

Up-time	Max Downtime
99.9999%	31.5s per year
99.999%	5m35s per year
99.99%	52m33s per year

Most high availability systems aim for five 9s.

Precise Availability

Having a system with a certain number of nines needs to have precise specifications in order to be useful. We should specify:

• Worst case scenarios.
  • How long the system can be down at a time in the worst case.
• Worst case delay as well as down time.
• Ho the system can degrade gracefully.
  • Notice of downtime for planned maintenance.

Logs & Alerts

Security is dependent on the knowledge of activity. We could have the following types of log:

• Standard Log - Records all logins/logouts, database access requests.
• Failed Login Log - Records all failed logins.
• Unusual Activity Log - High volume of transations on account.
• Alert Log - Failed logins for top level clearance users.

Alerts can be used to track unusual activity and alert operators, suspend accounts and more.

Bell La-Padula Model

All items are given a security clearance:

1. Unclassified
2. Sensitive
3. Secret
4. Top-Secret

There are also the following restrictions:

• No Read-Up - A subject cannot read a document above their clearance level.
• No Write-Down - A document cannot be copied/included in another document with lower security clearance.
• Trusted Subjects:
  • Can write documents down.
  • Must be shown trustworthy with regard to the security policy.

Specifying Security

Ideally security policies should be kept open to allow for upgrading of algorithms and protocols.

The security policy could also include:

• Shredding Documents
• Secure Disposal
• Password Reset Protocols
• Security Training
• Security Audits

You should also bear in mind standards compliance:

• Payment Card Industry Data Security Standard - For card details

Requirements Checking

• Validity - Does the system provide the function which best support the customer’s needs?
• Consistency - Are the any requirement conflicts?
• Completeness - Are all functions required by the customer?
• Realism - Can the requirements be implemented given available budget and technology?
• Verifiability - Can the requirements be tested.?

Scenarios

These are test cases running against a given situation.

They are useful as they show the developer by example what will happen given certain conditions.

Agile Requirements - Cucumber

This is a software tool used to help write requirement which are linked directly to tests.

Cucumber uses a language called gherkin to describe features:

Feature: Login
	In order To probe who I am
	As a customer
	I want to be able to login to the system
Scenario: Login with test account1
	Given I have  entered a username of account1
	And I have entered a password of pass1234
	When I click login
	Then the result should be login successful

• The Feature: is not parted but describes a feature to a developer.
• The Scenario: is an example by also is linked to test code.

This is linked to the following test code:

public class LoginSteps {
@Given("^I have entered a username of account(\\d+)$")
public void i_have_entered_a_username_of_account(int arg1) throws Throwable {
	throw new PendingException();
}

@Given("^I have entered a password of pass(\\d+)$")
public void i_have_entered_a_password_of_pass(int arg1) throws Throwable {
throw new PendingException();
}

@When("^I click login$")
public void i_click_login() throws Throwable {
throw new PendingException();
}

@Then("^The result should be login succesful$")
public void the_result_should_be_login_succesful() throws Throwable {
throw new PendingException();
}
}

Cucumber has the following advantages:

• Gives simple and clear notation to write a specification.
• Analyst and test teams can learn Gherkin and develop feature files.
• Step files are produced by the development team.
• Test data can be change later without changing the test code.