KIT715 Cyber Security and Ethical Hacking Assignment

Specification

This assignment has two parts. In this part (part 1) you will be inventing and describing an SME (Small-to-Medium Enterprise) business and its ICT infrastructure that's consistent with some constraints that are obtained from a script which is detailed below. Your SME business description from this part of the assignment will then in effect form a case study that you will then use in part 2 of the assignment (part 2 will require you, acting as an independent security consultant, to propose a plan for a vulnerability assessment exercise to the fictitious SME).

Part 2 of this assignment is detailed in a separate document

The case study you create for your SME business in this part is called the Business Details document. This document will be due first, and you’ll be given feedback on your submission so you can then improve and revise it before submitting it as part of the final submissions required for part 2 of the assignment. The initial submission of the Business Details document will not be given a score.

In preparing for this assignment, please refer to slide 18 of the week 2 Lectorial. This slide (and the slides that follow) documents the stages involved in an approach to full penetration testing, which is in many ways a super-set of vulnerability assessment. Please note however in this assignment you will not be considering nor proposing penetration testing (stages 4 onwards).

The following stages are NOT included in this assignment:

The Business Details Document

Preparation for a vulnerability assessment, which we could call the discovery process, would normally require you to potentially talk to the business client to determine as much as possible about them that you can – this must occur well before you start planning the actual vulnerability assessment itself. During discovery, questions to ask the SME might have included:

• what is the size of the business,
• how many offices they have,
• how many staff they have,
• what are the key staff roles (e.g. a staff hierarchy chart)
• what sorts of customers they serve,
• how geographically distributed they are,
• how many devices (computers, servers, mobile devices, etc.) they have,
• what sort of software and services they run,
• how broad or how focussed they want the assessment to be,
• whether they’ve had assessments or penetration tests done in the past, and so on.

Since the company you are preparing the vulnerability assessment for is not real, real discovery information isn't available – it must be invented! A case study is usually supplied (or developed as part of exercises like this) to provide as much of this background discovery information as possible, and in this part of the assignment, you're creating the case study.

Your business details parameters

To make things more interesting, and to provide each student in the class with an individualized scenario, we will use a pseudo-random process that generates some basic parameters to define aspects of the SME business client. The SME parameter data generated will be repeatable (but unique) for each student, and you will then take that data and expand on it to create a cohesive “backstory” for the business that documents as much as you can, including the business' systems and infrastructure, what they want assessed, and so on.

To generate your individualized starting parameters:

1. log in to the cyber account in an ICT Networks lab, or via LabShare
2. open the Macintosh terminal program, and enter the command:
3. ./cyber-params username studentid
   where:
   • username is your (short) UTas username (the same one you use to authenticate on the cyber account in a lab, not your full email address)
   • studentid is your UTas student ID number, with leading zeros omitted – for example, if your student number is 002754, you would enter 2754.

   This command runs a script that outputs a series of parameters that define some aspects of your SME that you will refer to when creating the vulnerability assessment proposal in part 2 of the assignment. These values are pseudo-random (i.e. no student will get exactly the same data), but you will get the same results every time for your unique combination of username and student ID (so the person marking your assignment can generate the same list of parameters to check that you have stayed within the constraints produced by the command).

   An example of the script’s output might look as follows (yours will differ):

   Last login: Sun Mar 5 10:14:26 on console
   C02XQ09QJ1GC:~ kit304$ ./cyber-params jcitizen 000004

   Cyber Security Assignment Parameters for your SME - username: jcitizen studentid: 000004

   Employees: 20
   Office locations: 4
   Operating scale: country
   Intrusion detection system installed? no
   Firewall type: statefull inspection
   Extranet used? no
   Network DMZ used? yes
   Wireless network (in addition to wired LANs)? no
   Cloud provider: IBM Cloud
   Web site hosting server location: DMZ
   Other business servers location: cloud provider
   Type of web presence: standard web site
   Customers (approximate): 1,000
   Customer type: other businesses
   Has the SME used vulnerability assessment (VA) before? yes
   Has the SME used full pen-testing (PT) before? yes
   Did past full PT recommend significant changes? yes
   Does SME have security policies in place? no
   Does SME deal with PII? yes
   Does SME deal with PHI? no
   Does SME have incident response team? no
   Does SME have dedicated network security staff? No

   You may find some apparent inconsistencies in the script output – for example, the organisation may have conducted assessments in the past, but does not have a formal security policy in place (which would have been a natural recommendation of an assessment). These things can happen in the real world, and you’ll need to consider them in your business description (with justification).

   NOTE -

   You need to copy the cyber-params script's output and include it in your Business Details document.

   Extra details?

   In addition to what is generated by the script, you are free and highly encouraged to invent as much about the SME and their requirements as you need to develop your business description – this will give you more to think about when creating the vulnerability assessment proposal in part 2 (if you lack sufficient details in your business description in part 1, it's very difficult to discuss what you propose to assess later in part 2 as you won't know what can be assessed!). You must document everything together with any assumptions you have made in the Business Details document. For example, you must consider:

   Your own assumptions must be reasonably based on the parameters generated by the cyber-params script. For example, if the parameters for your SME state that it has no intrusion detection system, your vulnerability assessment proposal in part 2 should not include testing it, as there isn’t one! Or if your business' operating scale is city then it would not be providing products and services to other countries (or even states). Furthermore, you can’t require that the SME install additional infrastructure not already in place just to make it fit in with your later proposal plan.

   You should think about every parameter in the script output, and your business description should not include simple (and obvious) statements like "the business does not have a DMZ, the business does not have a wireless network", but more considered and careful observations and descriptions.

   Explanation of technological terms?

   Your Business Details document is the case study you are constructing to be used as the source for part 2. Do not provide explanations or the theory of technological terms (like DMZ, extranets, NG firewalls etc) in this document as the explanations are not relevant to describe the SME's infrastructure – you're not sending this document to anyone but the marker! You will of course have to personally research terminology you don't understand so you know what they mean however, to be able to later accurately determine what will be included in the vulnerability assessment proposal.

   Remember that the Business Details document exists so that the marker:

   After you have received feedback on your first Business Details document submission, you’re free to modify the document in any way you want. Only the second submission of this document will be assessed in part 2.

   Remember that the Business Details document doesn’t actually exist within the pretend world of the SME – much of the information it contains would be the discovery information found during an initial meeting with the business. This means you wouldn't be giving this document to the client, nor would you refer to it directly in the Vulnerability Assessment Proposal in part 2.

   • the name of the business and "what they do" (e.g. manufacturing, online services, etc.),
   • the number of systems used in the organisation, including servers, desktops and mobile devices, and their roles (development, production, administration, etc),
   • the types (and versions) of operating systems, applications and services that are in use,
   • whether the business has a defensive strategy already in place,
   • what the assessment profile will be (e.g black-box, white-box)
   • how long the vulnerability tests would last, and so on.
   • can provide feedback on your assumptions and parameters before you undertake the larger process of producing the proposal plan itself in part 2,
   • has a reference to use while marking your vulnerability assessment proposal.