Octave allegro risk assessment template

ISE 510 Security Risk Analysis & Plan

Security Breach Analysis and Recommendations

Milestone 2: Test Plan

Due

Submitted on

If late let me know why:

=====================================

Delete these instructions in blue font before submission:

Change file name to MS#2_LAST_FIRST

A few comments up front:

Assume you and your team are hired by Limetree as an IT Security consultant to analyze the breach, determine the vulnerabilities, and make recommendations for an extensive security program to include policies, controls, enforcement of controls, and continuous monitoring, all for the purpose of reducing information system risk to an acceptable level.

You will need to look up ONE of the Risk Methodologies listed in the Reference section. Some are easier than others! So look at a few and then decide which one you like. If you want to use another one, just let me know.

If you have any questions, please let me know as soon as possible.

Introduction

a) Introduce your company (Limetree) and state its capabilities.

It’s good business communication practice to double-check assumptions and verbal correspondence. I would copy the background section from final project scenario and make changes as needed.

b) State your goal for the security breach analysis project.

Whatever you write as the goal should be connected to the scope below. Remember, we are in a Risk Assessment and Planning class – so you should include how ‘risk’ fits into the goal(s).

Scope

a) Define the scope of the project.

From a Project Management perspective, the scope is the boundary of the project and specifies what aspects will be included and which aspects are not included. From a cybersecurity perspective, we’re interested in IT systems, facilities, people, cybersecurity procedures and policies; threats and vulnerabilities as mentioned in the Surefire Game or THE BREACH supplemental document.

Here are some ideas:

Answer these questions in essay format:

a) What is the primary reason Limetree is performing this activity?

b) What will the Security Breach Analysis and Recommendations report going to produce? (look back at goals)

c) What were the major threats and vulnerabilities described in the Agent Surefire Game?

d) What were the major threats and vulnerabilities described in THE BREACH supplemental document?

e) Any limitations or constraints?

f) How long will it take? (should be less than a month – you can answer this after you complete ‘Timeline and Benchmarks’ below)

g) About how much will it cost? (you can answer this after you complete ‘Timeline and Benchmarks’ below)

Remember that the title of the Final Project is "Security Breach Analysis and Recommendations" so, keep the discussion to that.

Hardware and Software:

a) Create a list of hardware and software present.

Just list the hardware and software found throughout the Final Project Scenario and the Breach description.

Resources:

a) Determine resources required with brief explanation of why each is required (e.g., internet access, computers, additional personnel).

These are the resources needed to complete the Security Breach Analysis and Recommendations Report (i.e. our Final Project). Here are the main three types of resources (you can add more if you want):

List the Job titles of the team members and what skill-level – team members and their skills, certifications, and experience. How much does each member cost per hour.

List the Hardware & Software – What special hardware or software; any licenses or subscriptions required; like a penetration test suite.

List the Special tools –forensic hard drive duplicators; wireless detection scanners etc.

Hint: A team of 5 would be too large, and a team of 1 is too small.

Timeline and Benchmarks:

a) Discuss your timeline for the project (how long it will take and why).

This can be a bulleted list of the major tasks to be completed (No more than 6 major tasks); under each bullet give a short description. You can list out the tasks and their description like a Project Manager would.

Also, on each bullet, estimate the number of man-hours required to complete each major task. Example: 3 people working 5 days at 40 hours per week is 3 x 40 = 120 man-hours.

EXAMPLE: 1. KICK-OFF Meeting.

The kick-off meeting serves as an opportunity to discuss the organizational structure, introduction of the team to senior leaders and IT staff, reviews the facts of the breach, and defines the scope of the project. Approximately 3 team members, for 2 hours is 6 man-hours.

b) Discuss what regulatory benchmark you will be using to make vulnerability determination.

Here is an example of what this question is looking for:

The regulatory benchmark that will be used in the vulnerability determination is the OCTAVE Allegro methodology (Caralli, Stevens, Young, & Wilson, 2007). The original OCTAVE methodology was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in 1999. Since then several versions have been developed, and in June 2007, SEI introduced the OCTAVE Allegro methodology.

Any of the risk methods listed in the References (at the end of this document) will be acceptable! Or, if you have a risk method you’d like to use, just let me know.

Approach:

a) State your approach

Here is an example of what this question is looking for:

The OCTAVE Allegro methodology uses an 8-step process for conducting a risk assessment. These are 1) establish risk measurement criteria; 2) Develop an Information Asset Profile; 3) Identify Information Asset Containers 4) Identify Areas of Concern; 5) Identify Threat Scenarios; 6) Identify Risks; 7) Analyze Risks; and 8) Select Mitigation Approach.

OCTAVE Allegro methodology uses questionnaires, worksheets, checklists, and templates to guide the risk assessor through the 8-step process.

b) Define how you will categorize your findings (Example: low, medium, high)

Here is an example of what this question is looking for:

The OCTAVE Allegro methodology uses three categories to evaluate the probability of a threat exploiting a vulnerability – High, Medium, and Low.

The final risk score is determined by a relative risk score, which considers a qualitative risk probability (high, medium, low) combined with a prioritized impact level, taking into consideration the organizations’ criteria.

References

Add your reference here

Have at least 3 or more references. Delete those references that you did not use.

Caralli, R. A., Stevens, J. F., Young, L. R., & Wilson, W. R. (2007). Introducing octave allegro: Improving the information security risk assessment process (No. CMU/SEI-2007-TR-012). Carnegie-Mellon Univ Pittsburgh Software Engineering Institute. Retrieved from http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA470450

CORAS, (2015). The CORAS Method. Retrieved from http://coras.sourceforge.net/

NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach. Retrieved from http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

NIST SP 800-39 (2011). Managing Information Security Risk: Organization, Mission, and Information System View. Retrieved from http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf

Stoneburner, G., Goguen, A. Y., & Feringa, A. (2002). NIST SP 800-30: Risk management guide for information technology systems. Retrieved from http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

5