Operating Systems Vulnerabilities (Windows and Linux)

ere are some thoughts on how Project 2 can be approached.

Again, watch the video and read the transcript to understand the scenario and work your Project with the scenario in mind. The objective is to essentially provide two things; (1)A Security Assessment Report or SAR on the state of the Microsoft and Linux operating systems within the fictitious organization in the scenario, and (2)create a non-technical narrated presentation. There is no executive summary. So your narration can either be audio on your slides or simply written speakers notes in the note area. The audience for the presentation is the executive level and for the SAR it is the leadership who are both technical and non-technical.

Going through the Steps you will see that you the SAR have the following:

1. A brief definition and explanation of OSs and information systems. See Step 1, Items 1-4. Note that although there may be specific questions in each step, you are not necessarily just answering these. You cover those aspects in your writing (in the OS overview in this case).

2. Continue with a brief overview of the advantages, disadvantages, known vulnerabilities or security issues for each OS. Again see Items 1-6 in Step 2.

3. You will be scanning the two OSs. So the next thing you include in your SAR is what you are going to do, how you will do it, what tools you will use, any pros and cons of each tool, what information the tools will provide and why this data will be important. The Step gives examples of the data (password strength, Internet Information Services or IIS administrative vulnerabilities, etc.) which you can talk about. Talk means why they are important. What types of issues could they have? What impact could those issues have on the business? Etc.

4. Include your OS scan results in an Appendix, but from those results prepare professional tables, charts, graphs, etc. which convey the issues. Some people like to divide the results into extremely important, lesser importance and those in the middle. You can create dashboard summaries for your presentation too.

5. Along with the tables you will discuss the findings, how the two tools might have found different issues, any disagreements between tools, etc. and also conclude which tool you recommend be routinely used (or neither or both) and why.

6. Your final recommendations will be what issues should be addressed, in what order, and why (roadmap). Convincing reasons are quantitative impact on the business vs. perhaps how costly it would be to take action. Include how. (See Step 6, Items 1-2.)

Check Step 7 for information in the non-technical presentation to upper-management/executives. There are a few key statements about the purpose of the presentation.

1. Upper-management is interested in the bottom line.  Help them understand the technical vulnerabilities you found by giving them the business consequences.

2. Help them understand that having these issues is normal for an organization and they just need to address them.

3. Help them clearly see their required actions and/or approvals.

4. Remember the options are to do nothing and accept the risk, to take all, or some, of the recommended actions. Also remember that there are often multiple actions that can be taken for a given vulnerability. Help them understand which to settle on. You can make the suggested steps clear to them at the very end.

A sample outline for the SAR is attached.