IT Services Testing Team - How we can help
The IT Services Testing Team can assist with specialised testing needs including Security, Performance and Accessibility Testing
Penetration tests are simulated attacks carried out by trained security testers. They employ the same techniques that attackers use to reveal if your systems or applications can withstand hostile attacks and whether discovered vulnerabilities can lead to further intrusion and exploitation.
The IT Services Testing Team have been helping to arrange Security & Penetration Testing for programmes, projects and services for over eight years – this compliments the Vulnerability Scanning service offered by OxCERT and may be used where more focused testing is required. This may be on a new or upgraded service, or as part of a regular security review. We currently have agreements in place with external suppliers and we can supply consultative support to help guide a cost-effective engagement.
We offer a risk-based approach to testing focusing on the principal attack vectors of your system or application. More than one penetration test may be required if the number of vulnerabilities detected is high.
To speak to the Testing Team, or to find out more about how we can help with you testing requirements, please visit OSM and raise a Test Team Engagement service request.
After initial contact with OxCERT and/or the Testing Team, and establishing the requirements for security testing, we follow a two-stage process for conducting this testing. The first stage is engagement with OxCERT, and an internal vulnerability scan
where appropriate.
Stage 1
OxCERT Vulnerability Scan Requirement
Initial contact with OxCERT - determine requirement/need to perform initial vulnerability scan.
weeks
Run OxCERT Vulnerability Scan
Scan performed against target system.
OxCERT Provide Vulnerability Report for Review
Report made available - any issues flagged as a result to be assessed and resolved as required.
Stage 2
If after the initial stage of engagement, there is further need for more targeted or in depth testing, we are able to assist and the outline for this stage is detailed in the following timeline.
Security & Penetration Test Requirements
High Level set of requirements about the system/application under test and any specific exclusions.
week
Scoping
Call/meeting with testing provider to explore detailed requirements of what is to be tested (including access levels), exclusions, timescales and deliverables.
Statement of Work
Proposal produced by the testing provider to detail the work to be undertaken, costs, and deliverables. To be reviewed by University representatives to ensure it covers the requirements appropriately.
Raise Purchase Order
When the Statement of Work has been agreed, a Purchase Order should be raised through Oracle Financials for the provider.
Plan & Authorise
The testers will need information to be provided about the system under test, and potentially work may be required to provide credentials/target system/access as required. A test authorisation form will need to be completed.
weeks
Execute Test
At the planned time, testing will take place – this may require support to be available in case of issues; having a short kick off meeting may be prudent.
weeks
Vulnerability Report
After testing is completed, and findings are validated, a report detailing any issues discovered will be issued to relevant parties (as defined in the scoping). Note that for severe issues, these are often notified during the test phase itself
as well.
Debrief
Meeting/call held to go through the findings from the report. Tasks, responsibilities and timings should be assigned to ensure any relevant fixes/corrections are made as required. Plan for retesting fixes as needed should be agreed to.
Fix & Re-test
Fixes are made as detailed in the Debrief, and retesting is completed as required (re-testing my be done internally, or by the provider).
Here is a (non-exhaustive!) list of things to consider when planning for a Security/Penetration Test:
- Who needs to be involved in the discussions?
- Do you have relevant up to date technical documentation that can be shared?
- Why are you requesting a test - what are the risks?
- What are the potential attack vectors?
- What is the scope of the test?
- What budget is available for the test?
- What are the timescales for this activity?
- Do you need support running this activity?
- Approval and impact on other services?
- Do you have appropriate safeguards in place if the testing has an adverse impact on the system? (eg backups, support available, at-risk periods, etc)
Security/Penetration Testing (S&P Testing) – this is a formal authorised testing activity that attempts to identify flaws or security issues in a computer system, application or network.
Attack Vector – A method that an attacker may exploit to breach or infiltrate a system or target a user. This could be the result of (eg) a defect, a misconfiguration or design flaw.
Vulnerability - A weakness that can be exploited by an Attacker to gain unauthorised access to a computer system.
Cyber attack - An attempt to expose, alter, disable, destroy, steal or gain information through unauthorised access to, or make unauthorised use of an asset.
Vulnerability assessment – An automated testing assessment provides your system with non-intrusive, automated and regular tests to identify security loopholes in your systems and networks, rather than specific attack scenarios.
Security Posture - refers to an organisation's overall state of cybersecurity readiness.
Primary Security Concern – reasons why we would want to run the test
Black Box Security Testing – Refers to a method of Security Testing in which the target system is evaluated with no prior knowledge of the system under test. While this is potentially the most realistic method, it may be more costly than other approaches
White Box Security Testing – Refers to a method of Security Testing in which the tester has full access to information about the system under test, including (eg) network and system information, credentials, and potentially source code. This method may be the most cost effective method of testing as it allows for a targeted approach to the test.
Grey Box Security Testing – A commonly used approach that combines white and black box approaches, striking a balance between efficiency and authenticity, in some ways reflecting a real life scenario where an attacker may perform reconnaissance prior to an attack.
OWASP - Open Web Application Security Project. The Open Web Application Security Project (OWASP) is a non-profit foundation dedicated to improving the security of software and helps to provide Tools, Resources and Training to enable organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.
OWASP Top 10 - Top 10 Web Application Security Risks – A standard awareness document produced by OWASP representing a broad consensus about the most critical security risks to web applications.
Security Standards
Information Security is a constantly changing field – technology moves on, and new threats are discovered regularly. When choosing a testing provider, we recommend seeking providers with the following certifications – both providers used by the IT Services Test Team have these accreditations.
ISO 27001 (formally known as ISO/IEC 27001:2005) is a specification for an information security management system (ISMS). An ISMS is a framework of policies and procedures that includes all legal, physical and technical controls involved in an organisation's information risk management processes.
CREST - Council of Registered Ethical Security Testers. CREST provides internationally recognised accreditations for organisations and professional level certifications for individuals providing penetration testing, cyber incident response, threat intelligence and Security Operations Centre (SOC) services.
The IT Services Testing Team has more than 10 years experience in arranging and/or conducting load and performance testing for services used by the University.
The aim of testing includes:
- Assurance that a component or system can perform as required under anticipated user loads
- Assurance that a component or system can support the anticipated total or maximum number of concurrent users
- Attempting to identify potential bottlenecks before reaching them in production, in order to allow remediation to take place where required
We use both internal resource and a third-party supplier to perform load and performance testing.
To speak to the Testing Team, or to find out more about how we can help with your testing requirements, please visit OSM and raise a Test Team Engagement service request.
Consideration for the performance of a system needs to be made early in the software delivery lifecycle. The technologies used, environment sizing, data and query structure, and the ability to scale (either, or both horizontally and vertically) can all influence the final performance of a system. To allow testing of the performance of a system, non-functional requirements, including performance requirements, are required – these should aim to quantify the likely load on a system.
These requirements should detail metrics such as:
- Requests/transactions per second for given processes
- The total number of users/visitors
- Peak concurrency (eg number of active users)
- Volumes of data to be transferred/processed
- Required timings for processes/response times (these may be specified in terms of mean, centile responses or distributions of timings)
Load and Performance testing is often approached as a risk-based exercise – it is generally impossible to cover all areas. Additionally, while the aim in running a test is to make it as realistic as possible, there always has to be a degree of compromise between the complexity of the scripts (the “user journeys” in use and the data required to run them), and the time it takes to create, debug and run the scripts themselves. Examples of higher risk items may include:
- Commonly used areas/functions
- User journeys that may experience “peaks” in usage (eg deadlines)
In addition to considerations around the test scripts, the environment used for the test should be as similar as possible to production as possible to give meaningful results – while some degree of extrapolation of results is possible, this is not always useful or accurate.
Load Testing – a test activity that evaluates the speed, responsiveness and stability of a computer, network, software program or device under a workload
Stress Testing – a test activity that is used to attempt to evaluate the upper limits of capacity in a system.
Soak Testing – a test activity that places prolonged load upon a system to establish if there is performance degradation over time under sustained use. During this process, memory utilization is often monitored to attempt to detect memory leaks (the incorrect management of memory allocation whereby memory that is no longer needed is not released for use again).
Throughput – A measure of how much activity is taking place on a system/component in a given interval. This may be measured in in transactions, page requests, or user journeys through a business process.
Concurrency – This is a figure detailing the number of active users on a system at a given moment. It is important in determining the required capacity of a system and used in conjunction with expected throughput to formulate requirements and plan tests appropriately.
User Journey – A defined path through software that a test script will replay
Virtual User – Performance test tools simulate multiple users when running the test – each one appears to the system under test. Each individual thread is termed a virtual user (see also concurrency).
Get support
If you cannot find the solution you need here then we have other ways to get IT support
