April 23, 2025

10 thoughts on “TECH 581 W Computer Network Operations: Laboratory 5, Team 2

  1. This group’s abstract starts off with a very good introduction to this lab. The beginning of the abstract ties this lab into the last lab and also shows the value of this lab. The second part of the abstract was not written very well. The second part of the abstract tries to explain what is involved in this lab. The last part of the first sentence and the last sentence of the abstract do not make any sense. The group could have reworded these sentences to give a better understanding of what was entailed in this lab. The group’s literature review was almost complete. The only thing that was missing in the literature review was how the articles relate to the current lab. The literature review does mention in the end of the review how one of the articles is similar to this course, but there is no other mention to how these articles tie into the current lab. Over all the literature review was done very well. It covered what each of the articles themes were and talked about a question if the article had one. The review also examined the methodologies, research, and errors in each of the articles. Also the review did a very nice job of tying each of the articles in with each other. The group’s methodology could have been expanded on. The methodology only gives the steps given in the lab and do not explain how they are going to go about accomplishing each step. The group expands on how they will use the literature reviews to aid in accomplishing this lab, but lacks in explaining any other step. The findings section of this group’s lab was also lacking. The first part of the findings talks about leaving out a part of the NIST document that they used, that would not pertain to their system. This section of the findings could have been placed in the methodology of this lab report. The group then gives a list of samples that they used to test their vulnerabilities on. The group left out a couple parts of the lab that should have been covered. The group did not mention any findings they saw when they put the table together, like any patterns in the OSI layers of the changes or in McCumber’s cube. They did not talk at all about the section of the lab that explores security patches applied to the examined operating system. The group did not even include that section in the table or in a table by itself. A lot more could have been included in the findings for this group. In the issues section the group talks about not being able to apply tools to the exploits found in the first part of the lab. The group seems to have missed the whole section on exploring security patches. The part of the lab that the group was having troubles with pertained to finding tools that could be used against the vulnerabilities that the security patches fixed. The group did mention in the abstract that they were going to examine this section but never came back to it. In the conclusion the group mentions that they are surprised in the findings after creating the table. They say they never thought of approaching examination of vulnerabilities in this way. The conclusion could have expanded on some of the patterns they found and how that could relate to how those patterns could be examined to perform a better penetration attack on a system.

  2. The abstract reads more like an introduction to a literature review, not bad but would’ve fit better as an introductory paragraph to your literature review. The first and second paragraphs of the literature review are merely summaries of the assigned readings without any ties to the lab activities or each other for that matter. Interestingly enough, the word “lab” only appears once in the literature review. In the future, tying the literature at hand with the activities of the lab makes for a more interesting and relevant read for the reader. The summaries of the articles aren’t bad in themselves but could be taken a few steps further to tie everything together.

    The methodologies section is too brief for the task at hand. Instead of restating the requirements and that you intend to accomplish them, give some detail on how you plan on accomplishing the tasks of the lab. How will you parse the NIST document for vulnerabilities? How will you classify them? How will you select the tools to test the vulnerabilities you discover and where will you select them from? All of these questions should be answered to make the process repeatable. A mention of how the vulnerabilities discovered were going to be entered into the table for the findings would have been helpful too, the output is hard to read.

    There was some material in the findings section that could’ve been put in the methodologies section instead. Discussion on omitting the three configurations and the sampling of security checks would’ve added more detail to the methodologies section. The organization of table one for the findings was difficult to follow. Was this the order they were listed in the guide? Would it have been easier to order them by OSI layer? In the methodologies mention was made of considering large scale patching and how they affect the outcome of this lab’s exercises, the findings section doesn’t have a discussion on this, only a one line entry in the table mentioning that the patches be applied in a timely manner. Are there any vulnerabilities that arise from this process? Is patching as soon as possible always the best way to go? Some of the vulnerabilities discovered raise questions as well. One of the vulnerabilities or check list items from the document was to ensure that “Windows Server 2003, 128 bit version is installed.” Is this a typo? Is this a level of cryptography required?

    The issues section is interesting. It appears that the authors didn’t agree with testing the vulnerabilities they discovered with tools since this lab was titled “exploits without tools” so they chose simply to ignore that requirement.

  3. Team two’s submission this week is sort on analysis, misses some very important points, and has some content issues. The abstract is well written. The last sentence is unclear. Are the systems supposed to institute the recommendations in table form? Your meaning would have been clearer if you said, “fail to follow the recommendations,” or something similar.

    The literature review summarizes the articles well but fails to relate them back to the lab. Critical analysis is also rather thin. What is Wales actually advocating? Does he really even discuss tools? You say his stance is weak, but you don’t tell us why. Citing a lack of research question or methods is a cop-out. These things are present, but implied. You say that among the good points he makes, he says that an automated tool report without a security professional is useless. Is this always true? Need someone be a dedicated professional in order to be an expert? What other good points does Wales make? What is the value in what Jajodia et al. do? Are there flaws in their methodology? The group appears to have glossed over the concept of resiliency in DU & Mather’s work. Why? Do you agree with their analysis of the relationship between the application and the environment? You are very critical of Jorgensen. Did you consider that perhaps what he demonstrates is merely proof of concept? Is it applicable to other file types and applications?

    There are some problems in the methods section as well. If the literature review is standard practice, does it really need to be mentioned in the Methods section? It’s along the same lines as reporting that the lab was written and submitted via the guidelines. Oh wait you did that. Don’t. The majority of the steps listed are repeatable, however the group never explains how they will test the vulnerabilities, just that they will use the standard environment.

    The team’s findings section lacks detail, and relies on fluff to increase word count. We know you did a literature review. Stop referring to that fact in every section. It wasn’t really all that noteworthy. Your findings section relies a great deal on your included table, which does indeed appear to answer the first four questions in the lab. I question placing physical security at layer 0, especially this far into the course. No discussion of patches or roll-ups in included. I didn’t see anywhere that the results in the table were actually tested. Is that the reason for the lack of detail in the methods section on this point?

    The conclusion follows the findings, and validates the purpose of the lab in spite of the missing pieces. How did you solve the issue mentioned? It appears to be more of a complaint than issue. Why do you think it is that the lab is about exploits without tools if we discuss tools?

  4. The wording in the first paragraph leads the audience to believe that a security professional needs tools to be more productive, and somehow make more money for that. The team states then states that not only professionals have access to these tools; other people do as well and can get them without paying for them. The question in my mind that this raises is, why should the professionals be getting paid a high salary when other people can use the tools exactly the same way, and don’t need to be paid as much? In the abstract, all acronyms should be spelled out. For APA 5 format, for each new section all acronyms should be spelled out the first time. What constitutes a “typical” installation for Windows Server 2003? I would consider a patched and updated version to be a typical installation. I could see that a Windows XP installation would not be patched considering this is used at home and people might be less likely to install the updates, but one would hope that for servers, they are patched and updated. In the abstract there is some poor grammar “…and using that against those that do what it says”. I am not exactly sure what the last part of this sentence is supposed to say, but there are a lot of pronouns for such a few words.
    I would like to see page numbers for these references taken from the required readings so I can look in up myself to see how the team interpreted them. Also, including page numbers is a requirement of APA 5 citations. If you are taking a direct quote from the readings, it must be in quotations. “To that end” seems to be a favorite way to begin a lot of sentences in lab reports. I have been noticing that in the previous 4 lab reports. Titles of articles, books, and journals should be italicized. For everything that Wales talks about, it all seems to be according to other people. Did the team research into all of these others items that Wales keeps talking about? The literature reviews seems to be a string of random thoughts. All of the questions were answered, but it made the literature review less cohesive. The methods section read more like what am abstract should. It talks about what the team will be doing, not the steps down to perform the lab. I am wondering where the list is from step 5. Also step 7 should have had the team create another table. The team seems to be missing about half the lab. There should be 2 tables and a list. What about patches? The one table the team had was hard to read, and was not in order by the layer of the OSI 7 layer model. I think the idea of step 7 was to see what changes were made to protect against the tools that were researched in previous labs.

  5. This team’s literature review did a reasonable job of addressing the articles associated with the lab, including both a comparison of ideas and a critique of concepts contained within the writings. Additionally, the physical layout of the table was appealing to the eye, with concise table categories chosen for presentation. Finally, the length of the results table was appreciable, with good descriptions chosen for vulnerability listings.

    It must be said that many problems exist with this group’s treatment of the exercise, however. Noticeably, the report began on a poor footing with an awkwardly composed abstract. The discussion of the “issues with tools” leaves one wondering what point was being made. Furthermore, the phrase “using that against those that do what it says” is at the very least a poor choice of wording; some might call it an abomination. The closing sentence was a fitting end to the section, as it too proved confusing. By all measures, it must be said that this part of the write-up could stand a great deal of correction.

    While the literature review was adequate in some regards, it lacked in any specific mention of the nature in which the articles under review applied to the exercise. Perhaps this was unsurprising, as there was little contained within this team’s write-up to apply these concepts to. For instance, the ‘Methods’ section was very brief, and contained no more than a rephrasing of the exercise instruction sheet. Perhaps even more disturbing, though this team spelled out these steps exactly, it appeared to leave the last two steps uncompleted.

    The ‘Results’ section was also flawed: at the very least a substantial portion of it should have been located in ‘Methods.’ Some information of worth is presented, but much of the writing suffers from poor wording and redundant phrases. The ‘Issues’ section probably contains information which should have been included in the ‘Methods’ section, too. Amusingly, this team attempted to rationalize the last step of the exercise away, based on a trivial semantic argument. Could “exploits WITHOUT tools” possibly mean that no reconnaissance tools were to be used to determine exploits (the converse of the previous weeks exercise)? The argument presented is silly, even childish: how could ‘testing’ “be outside the outside the scope of the lab” if it was listed as a specific step? In all honestly, I believe that you did yourself a disservice by resorting to this level of excuse making. Finally, the assertion that “by definition no tool is required to exploit… [a] lack of [server] physical insecurity [sic]” was rather ridiculous. It is assumed that ‘security’ was meant; even so, as illustrated by previous exercises, the physical domain necessarily requires physical tools: the implication is that these tools do exist, just not in the form of software.

    Finally, some issues exist with the ‘Results’ chart itself. The ordering of layer classifications could have been better; we found it useful to create the tables in Microsoft Excel first: this allows for arbitrary ordering on any table category as needed. Further, this team’s table appears inconsistent in its classification of issues with respect to the OSI layers. For example, I find “LDAP Signing Requirements” listed in layer seven, and later “LDAP Client Signing” listed in layer five. An additional obvious mistake, such as “Syn Attack Protection Level,” which refers to TCP SYN attacks, was listed as OSI layer three: most certainly out of place. There are a number of other classifications I disagree with, mostly with regard to session management and Server Message Block, but it must be admitted that this is largely in the realm of opinion, as no consistent classification was found in consulting various sources.

  6. Team 2’s abstract is well written and explains what they intend to do in lab 5. In addition they do a nice job of relating back to previous labs literature and tie them into this lab. Perhaps though that part of the abstract should have been included as part of their introduction. The literature reviews appears to be just a summary of the assigned readings and does not tie back to the actual lab. The summaries themselves are good but needed to correlate back to the lab.
    The literature reviews gives a good summary of what the authors were trying to convey. All of the questions were answered; however the overall literature review was not very cohesive.
    The methodologies section is really short considering all that needed to be accomplished in this lab. Also, the methods section read more like what am abstract should.
    Detail how your team intends to meet the requirements instead just restating the requirements. There is material in the findings section that could’ve been put in the methodologies section instead.

  7. In the abstract section, team two stated “Based on all of the literature provided in previous labs, performing a penetration test is all about the tools used. Tools represent the basis for making the security professional’s life simpler, and more productive and therefore higher paying.” However, I have to somewhat disagree for the tester must know what tools that should and should not be used depending on the situation. The tools would also be of little use if the operator cannot get the tools to operate at all or get them to work properly. I noticed that the team referred to themselves as “we”, which is in violation of the APA 5 guidelines. Consider changing this to further improve the scholarship of the paper.

    In the literature review section I had to disagree with the statement “The tone of this idea as presented by Wales seems to be that in house IT staff are generally not trained well enough to perform an in depth penetration test and audit. “ Wales seemed to think that a hybrid of in house and external penetration testing was best, for external testers would not be familiar with all aspects of the network as the in house IT personnel.

    In the methodology section, the statement “Our strategy for lab five is to follow the requirements of the lab design document and course syllabus to present a complete lab report” was moot, for this was strived for by all groups. The methodology section of team two seemed to be missing how the group would identify and list exploits or threats. However, the findings section seemed to address this omission. Group two seemed to also omit coverage of patches.

    Team two’s findings section gave a thorough description of the group’s findings. I was somewhat unclear about the statement “. If that setting is disabled then any system other than domain connected Windows 2000 or greater clients can connect to an SMB share. This includes Apple machines, and Linux machines, since backtrack runs on Linux this seems like an important setting to have enabled.”If the server could be accessed by backtrack it could be used to identify weaknesses in it by penetration testers, but it could also be exploited by malicious individuals, who would use backtrack to identify vulnerabilities that could be and would be exploited. Team two summarized the content of the NIST document by stating “After reviewing a mall sampling of security checks in table one, it became overly obvious that most of these checks while over looked by most, are generally common sense to increase the security of information assets. This is apparent because the first check is server physical security. This is an obvious enhancement to system security.” I was also surprised that group did not describe any patterns that emerged from their table.

    Team two ‘s issue section contained but one issue, they did not see the significance of step seven which stated “Using your previous work take the list of issues, and find tools that will be associated with each issue. Create a table or matrix.” Their rationale was that the laboratory was not to contain tools, so the step appeared to be contradictory.

    In the conclusion section, I was not sure how team two came up with the conclusion that “The actions recommended by NIST are very rigorous, but will harden a Windows Server 2003 machine against most attacks, especially ones that use “script kiddy” level tools.”

  8. Team 2 begins by stating the purpose of this laboratory assignment; to investigate vulnerabilities without tools. They further state that value is added to the use of the tools by the professionals who analyze the results. They state that they are going to focus on the NIST documentation intended to secure Windows Server 2003.

    Team 2 proceeds with a review of the literature assigned for this week. They begin with a discussion of the need for vulnerability assessments and then discuss Vulnerability Assessment Tools (Wales, 2003). I agree with their assessment that the value of the article is questionable. They continue their literature review by discussing Topological Analysis of Network Attack Vulnerability (Jajodia, Noel & O’Berry, 2005). They state that this article discusses value added to a standard NESSUS scan by analyzing the data to determine the possibility of indirect attacks. They further state that vulnerability assessment needs to go beyond an IT audit and include a complete risk assessment, including software applications, hardware and network infrastructure (Wales, 2003). They proceed to discuss Vulnerability Testing of Software System Using Fault Injection (Du & Mather, 1998) and Testing with Hostile Data Streams (Jorgensen, 2003). Team 2 questions the ability to use steganography with files other than GIF or JPEG. (They use the term stenography, however I am assuming that they meant steganography). According to http://www.answers.com/topic/steganography , “Although steganographic messages can be hidden in any kind of digital files, image files, because they contain so much data to begin with, are usually used for digital steganography”. Jorgenson refers to steganography as “In the context of data transmitted over the Internet, data included within that transmission that serves a purpose other than the original purpose of the data transmission is steganographic data.” He refers to this definition to describe any transmission over the internet that contains hostile code within an otherwise benign file. By these definitions, the file type containing the hostile code is irrelevant. They return to their discussion of the article Vulnerability Assessment Tools (Wales, 2003). They discuss the articles statements that say that penetration testing is best left to professionals. They disagree with this statement and believe that training is the key. They cite the article Viruses 101 (Aycock & Barker, 2005) to support their discussion about becoming educated.

    In the next section, Team 2 discusses the methods used in this lab. They describe six steps used toward completion of the lab. The first step was to select an operating system security guide and to have the guide approved by the instructor. They chose the Windows 2003 Checklist V6.1.12 from NIST. Their second step was to identify what the changes were designed to accomplish, place the change in its proper location on the OSI 7-layer model and McCumber Cube, consider the changes that the large scale security patches play, and then to test the results against the live lab system.

    In the findings section, Team 2 further defines methods used in the lab. One example is the security configurations that they found in their NIST document that were not used in this lab because the configurations did not apply to their test environment. Perhaps this information should have been placed in the methods section rather than the findings section. They proceed to explain a few of the more prominent security recommendations. They further state that they found that most of the security recommendations fall into the realm of common sense.

  9. Team 2 begins with their abstract and explains what they will be doing within this lab. The also give the information that they will be using the National Institute of Standards and Technology documents for Windows Server 2003. They then go onto the literature review and start with a statement. They state that performing a vulnerability assessment is no longer just a good idea, but has become a way of life. Why does the group think that it was not always thought in this way? This statement could be made even stronger by giving this information to back it up. They then continue onto discuss risk assessment and vulnerability assessment and how they should be combined. Does the group think this would be a good standard that should be issued by an organization such as IEEE or NIST? The main thing that could have improved the literature review was that it was broken down into the different articles. There where good points that could have been discussed about from each and those points could have been discussed. Those points could have been support by the articles. Overall it was a good section and then the team moved onto the methodologies. Here the team describes what is going to occur within the lab environment and that there will be two tables made. They really did not explain how they where going to accomplish the tasks but more listed the tasks and stated they where going to use their NIST documentation within the section. They then go on to state their findings from reading the document and then give the definition of vulnerability. Within the first couple of paragraphs I found a spelling error. It was just one word that states mall in stead of small. They did a good job at creating their table but when looking at the findings I was expecting more then just a table. Then the group goes onto discuss issues that they had with the lab and stating they had issue with creating the table to meet the requirements of the lab. Then they go onto their conclusion which includes from securing the server using the document will be able to successfully stop a “script kiddie”. Yeah this is a good point but it does not really go well within the conclusion. Over all there were some issues with the lab but the table and literature review was more of the strong point for the team this lab.

  10. I think that group 2’s write-up for lab 5 was very good. The abstract for this lab was good and accurately described the laboratory. The literary review was good and adequately reviews the material. Group 2 answered all of the required questions for each reading. All of the citing for the literary review was done correctly. For this lab, the group answered all of the required questions and provided a good amount of detail about the NIST document that they used. The group also included a very extensive table that indicates many vulnerabilities found in the document and how they relate to the McCumber Cube. The group also raised an interesting point in their issues and problems section, where they chose not to include security tools in their list, because the purpose of this lab is exploits without tools. Finally, the conclusion was written well and accurately sums up the laboratory.

Comments are closed.