Teaching information security defense can be a hot topic. Talking about penetration testing is different than actually showing different attack methods and how they operate as well as protecting themselves. There are risks in teaching intrusion detection, and building a cyber war laboratory for the purpose of teaching penetration testing. Penetration testing is a great way to discover known vulnerabilities and exploits that are open for exploitation on a network. Creating a cyber war laboratory is very feasible and can be great.
This lab built the foundation for the rest of the semester. By performing these introductory activities we should have a very good foundation for what will need to be accomplished moving forward. There were readings focused around an introduction to penetration testing as well as building a cyber war lab, and tools used. Based on that a literature review was synthesized, a VMware based lab built, penetration testing taxonomy designed, and three specific questions answered.
Literature Review
Penetration testing is not a simple subject to grasp or understand. It is both a progressive topic in information security defense, and a taboo subject. Should people be taught to work and think like a “hacker”? And if so, what is the proper way for people to learn how to perform a live network attack in a safe and effective manner. The readings for lab one focused on the strengths and weaknesses of penetration testing, how to build a cyber war lab, and attack tools. These topics do go hand in hand and will be useful during the progression of the class.
The first paper to deal with the strengths and weaknesses of penetration testing is (Du & Mathury, 1998). Du & Mathur have suggested that performing a penetration test requires the tester have existing knowledge of the systems being penetrated (Du & Mathury, 1998). Because of this they entertain an idea that performing fault injection is a possible way to test for a secure system (Du & Mathury, 1998)). Fault injection is just one approach in vulnerability assessment and in (Coffin, 2003) Coffin suggests that unsuccessfully performing a penetration test (or fault injection) does not mean a secure system (Coffin, 2003). Coffin evaluates the advantages and disadvantages of ethical hacking in a risk based model to prove that Penetration testing can discover flaws and vulnerabilities before they occur (Coffin, 2003). The author does show a lack of objective data by using only one person as a source for his short report on the uses and limitations on ethical hacking. Enterasys has created a white paper (Gula, 2001) that would seem to agree more with Du & Mather then Coffin in that there are fourteen items overlooked in a typical penetration test (Gula, 2001). The Gula article is a vendor created white paper and reads more as a brochure to use the services provided by Enterasys to be sure and overcome the limitations often encountered when using other entities performing the same services. Coffin, like Gula does point out the potential high cost of contracting with a firm that performs penetration testing (Coffin, 2003). In (Arce & McGraw, 2004) the authors discuss how the unified opinion among progressive security practitioners is that there is no choice to properly defend a network other than to use attack-based methods (Arce & McGraw, 2004). This would agree with almost certainly with Coffin, and with Gula, but only if using services from Enterasys. (Arce & McGraw, 2004) is also the only article in this category of readings that posits the possibility of running into major road blocks when dealing with traditional information security experts who believe that teaching penetration testing topics will only lead to more cyber hooligans (Arce & McGraw, 2004).
The first paper to deal with building a cyber war lab is (Micco & Rossman, 2002).Micco & Rossman start to build on the topic of teaching cyber attack and war that was first presented by (Arce & McGraw, 2004). Using funding from the NSF they built a small simple cyber war lab to aid undergrads in the development of better cyber defense ideas and tactics (Micco & Rossman, 2002). Their ideas are sound, but seem to only scratch the surface of what a true class in cyber war should be about, but do cover very major points that most we need to keep in mind during the tech581w class (Micco & Rossman, 2002). Mink & Freiling in (Mink & Freiling, 2006) agree with Micco & Rossman that teaching attack is the correct way to handle information security instruction (Mink & Freiling, 2006). They posit that today information security is dominated by defensive means and only the most progressive academics are learning to think like “hackers” (Mink & Freiling, 2006). Mink & Freiling concern themselves with why this is case and test their question by setting up an experimental lab (Mink & Freiling, 2006). They run an empirical study around two groups of students, one group taking an offensive course and another taking a defensive course (Mink & Freiling, 2006). The authors conclude that indeed attack education is better than defense education alone (Mink & Freiling, 2006). Holland-Minkleyperform the same type of approach to building a cyber war lab as Micco & Rossman in (Holland-Minkley, 2006). The authors build upon what Micco & Rossman performed, but target their lab towards information security non-majors (Holland-Minkley, 2006). The combination of (Micco & Rossman, 2002) and (Holland-Minkley, 2006) show that a cyber war lab is very feasible for both under-grads and non-majors, which should follow that a cyber war lab is extremely possible for grad students (such as ourselves). The target of the non-majors suggests that using this research for an in-depth course in penetration testing would fall short. This group of readings focused on more than one area, including how to setup a cyber war lab (Mink & Freiling, 2006), as well as the success of the courses offered in the lab (Holland-Minkley, 2006). While Micco & Rossman were concerned both with how to setup the lab and teach the courses, they seemed to be involved more in the detail of course prep over anything else (Micco & Rossman, 2002).
The final section of the readings was on the tools used. In (Du & Mathury, 1998) the fault injection method used is one possible point of attack for the software on the systems we will be using. In the section above, Miccro & Rossman were concerned about the segregation of the labs used (Micco & Rossman, 2002). This is because the tools of penetration testing can be rather malicious, and allowing them spread on the open Internet would constitute an ethical violation, and possibly even criminal charges. In (Benzel, Braden, Kim, & Neuman, 2006) the DETER test bed was segregated from both the control network, as well as public connectivity, and sometimes even shutdown to simultaneous users depending on the perceived threat level of an experiment being run (Benzel, Braden, Kim, & Neuman, 2006). This is something we need to be concerned about as we perform the labs.Benzel, Bradn, Kim, & Meuman would directly agree with Miccro & Rossman. There were also a number of tools presented to be used in our labs. (Ray, Vemuri, & Kantubhukta, 2005) suggests that as a way to keep attack experiments documented and running more automated for the penetration tester, and XML based markup language be used to support command and control systems. (Heien, Massengale, & Wu, 2008) goes on to show how to use QEMU to run virtualized attack systems. Tool like VMware View are very beneficial in performing experimental penetration and attack testing. Finally, Miccro & Rossman, as well as Holland-Minkley & Mink suggest categories of tools that we should be looking at in depth in our labs.
Methods
There were four primary steps to completing the lab exercise. The first step was a literature review of the readings as they pertain to an introduction to penetration testing, tools, ideas, and resources. The next step was to build the penetration-testing lab we will be using for the rest of the semester. This involved adding IP addresses to four VMs that were pre-built for us to use in VMware workstation. Because our group is group 2 the IP addresses we used were 192.168.2.1 – 192.1.68.2.4 with a 24-bit subnet mask. Those IP addresses were assigned to a Windows XP SP3 VM, a debian VM, a Windows XP RTM VM, and a Windows Server 2003 VM respectively. The third step was to create a penetration taxonomy based on aligning all three-hundred of the tools in the backtrack suite with one of the layers of the OSI reference model, as well as an attack coordinate on the McCumber cube. The final step of the lab was to answer to three questions proposed in the lab. These questions are:
1.)Is there any real difference between Wireshark and Ethereal? 2.)Why almost all of the tools are going to be elated to technology versus policy and procedure or personnel? 3.)Does this suggest a substantial bias or issue for penetration testing and perhaps self-selecting attacks may not be the best strategy?
1.)There is no real difference between Wireshark and Ethereal. Ethereal is the predecessor to Wireshark. Interface and Interaction is almost completely the same. 2.)The tools of BackTrack relate better to Technology on the McCumber cube versus policy or personal because anything other than technology requires cognition for effective processing, and negates that ability to run an effective and automated attack. 3.)Yes this does suggest a bias for penetration testing. Performing a manual, self-section attack will generate limited results.
Issues
The only issue that was experienced with this lab was a wide spread misunderstanding of the task on creating the taxonomy. The lab suggested that the grid just needed to be filled in (aka 1 tool per OSI layer). However the instructor stated, late in the week, that he meant that we need to place all three hundred of the backtrack tools into the taxonomy.
Conclusions
Ethical hacking is a primary tool in information security instruction. Penetration testing can educate how defensives will hold against attacks. Knowing how an attack could and would be executed can give the defensive edge. These attacks can easily be simulated in a cyber war laboratory. Backtrack by remote exploits is a bootable OS that contains hundreds of tools that can be used in penetration testing. All the tools in backtrack are pre-configured to work within the OS. It has several tools spanning from information gathering, network mapping, penetration testing, Bluetooth hacking, and more.
Works Cited
Arce, I., & McGraw, G. (2004). Why Attacking Systems Is a Good Idea. IEEE Security & Privacy , 17-19.
Benzel, T., Braden, R., Kim, D., & Neuman, C. (2006). EXPERIENCE WITH DETER: A TESTBED FOR SECURITY RESEARCH. 2nd IEEE Conference on testbeds and Research Infrastructure (pp. 1-10).Baracelona: IEEE.
Coffin, B. (2003, July 1). It Takes a Theif: Ethical Hackers Test Your Defences. Risk Management Magazine , pp. 1-4.
Du, W., & Mathury, A. P. (1998).Vulnerability Testing of Software System Using Fault Injection. W. Lafayette: COAST Laboratory.
Gula, R. (2001). Broadening The Scope of Penetration-Testing Techniques. Rochester: Enterasys Networks, Inc.
Heien, C., Massengale, R., & Wu, N. (2008).BUILDING A NETWORK TESTBED FOR INTERNET SECURITY RESEARCH. Consortium for Computing Sciences in Colleges , 73-79.
Holland-Minkley, A. M. (2006). Cyberattacks: A Lab-Based Introduction to Computer Security. ACM , 39-45.
Micco, M., & Rossman, H. (2002).Building a Cyberwar Lab: Lessions Learned Teaching cybersecurity principles to undergraduates.ACM , 23-27.
Mink, M., & Freiling, F. C. (2006). Is Attack Better Than Defense? Teaching Information Security the Right Way.ACM , 44-48.
Ray, H. T., Vemuri, R., & Kantubhukta, H. R. (2005).Toward an Automated Attack Model for Red Teams. IEEE Security & Privacy , 18-25.
10 thoughts on “Tech 581W Computer Network Operations, Laboratory 1: Team 2”
This group’s abstract talks about how teaching penetration testing is done better in actually performing the attacks. They do state that there are risks in creating a penetration lab. They also state that creating a penetration lab is very feasible. The abstract then goes into what is involved in the first lab. The group covers all the parts of the lab very briefly in this abstract. Next the group does a literature review on the readings that are given in the lab. They go about doing a literature review a bit different than others in this lab. The group first divides the readings up in to groups according to what the readings were about. Then they compare the readings of each group to each other. They grouped the readings into: strength and weaknesses of penetration testing, building a cyber war lab, and tools used. This way of doing a literature review worked great in comparing and contrasting the readings to each other and to this lab. The only problem with this literature review is that I didn’t see any were that talked about the methodology and the research of each of the papers. The group didn’t see that many omissions or mistakes. After the literature review the group then went into the method. In the method the group explained the four primary steps in the lab. Then they did a good job in explaining what they were going to do in each step. The group explained how they were going to set up the lab that they were going to use for the remainder of the class. They included what operating systems they were going to use and that they assigned static IP addresses to each of the operating systems and what those IP addresses were. Then they explained that they were going to align a set of tools to the OSI model and the McCumber cube to create a penetration taxonomy. Last they listed the three questions that they were going to answer. Next the group created the penetration testing taxonomy. The table was not easy to follow. Each of the entries seemed to run into each other. The table should have had some kind of boarder around each group to separate the different tools and the different categories. The group did do one thing that the other groups didn’t do in this table was to put were they got each of the tools. In the table the group lacked in some of the layers of the OSI model and had an excess in other layers. Next the group answered the three questions. They did a nice, but brief, job of answering each question. The answers on the questions went along with the answers that most the other groups gave. Next the group gave an issue that all the other groups had. They mentioned that the lab didn’t make it clear on how many tools we were to use in the table and that the instructor waited until the end of the week to clarify this causing the groups to scramble to accomplish the goal of the lab. Last the group made a conclusion to the lab. They stated how it is important to educate penetration testing and how it is a tool in information security instruction. The rest of the conclusion was on how Backtrack could be used to help in the penetration testing. I think that they could have put the part on Backtrack in another part of the lab and wrote more about what the lab showed them. At the end of the lab the group listed cites they used in the lab.
It was a good idea for the group to bunch the required readings into categories. Once the categories were made, the papers were compared to each other within the group as well as the other groups. One thing I thought that the literature review was missing was examples from within the papers and cite them with page numbers. I liked the little introduction in the abstract about penetration testing, but it did contain information that was would be better in an introduction than an abstract. The literature reviews did not seem to discuss the papers as well as they should have, but the comparisons were good. In the methods section the group discusses what was setup for the virtual machines, but the steps are not spelled out, nor are there any screenshots. The questions are clearly stated in the method section. The next part of the lab report was the table with all of the tools.
I thought that this part of the lab should go into the findings answered questions because the methods were to research the tools and the results should be the findings of the research. I found that as I went down the table I found it harder and harder to determine the dimensions of the McCumber cube and what tool they went with. A table with lines would have been easier to determine their proper places. I thought that it was nice that this group put the links they used to find the tools and also the definition of the tools in the table. Not all groups put the links for the definitions of the tools into their table. I agree that the only issue they had was the confusion that existed on how many tools were needed as well as where the tools should be located. I thought there would have been some issues with determining the proper places of the tools they located. Other groups seemed to have this problem of determining where the tools can go in the table. The group did not seem to put other technology tools into the table other than the backtrack tool suite. The group did have some interesting tools for layers 0 and 8, such as lockpick. I feel that there were not enough tools for layers 0 and 8. I don’t think that the tools that they found for layer 8 were really that good of examples of people tools. Dumpster diving and social engineering are better tools. Yes it is true that these websites can be used as attacks vectors, but the group did not include any policies. Dumpster diving can be avoided as an attack if the proper policies and procedures were put into place. Although the questions were answered, I felt that they were not answered well enough. For the possible bias, the group could have gone into greater detail about why this bias exists. The SANS book about penetration testing is a good reference to different suites of tools that could fit into the OSI model.
The team did a good job with the literature review. You efficiently explained the material while relating it back to the lab assignment and critically evaluating the work. The methods portion of the lab is considerably more minimalistic. The findings table was lengthy, though some of the tools listed are questionable. I want to specifically call into question the team’s “Layer 0” tools. While these methods provide kinetic effect, they are physical attacks. As such should they not be in layer one?
I disagree with your statement about cognition not being necessary for technology-based attacks. The tool without the thought of the user is just a thing. Even if automated, cognition must exist in the automating process. With this exception the findings& answers and conclusion are concise, but could use more detail. You relate what you learned from the lab, but how can you apply it? Is it useful?
I believe there is such a thing as overciting in your literature review. Check the APA guide for in-text citation details. I enjoyed reading the literature review from a topical standpoint but didn’t see anything linking the literature read to any of the lab activities. Once, when talking about Micco and Rossman’s positions on teaching cyber war classes, our class is mentioned but nothing further is said other than they bring up some “major points that … we need to keep in mind.” It would have potentially been beneficial for the class as a whole, not just related to this lab, to know what those major points are.
The threat table is difficult to read without any grid lines but I liked the inclusion of the links next to each of the tool names which makes it easy to link to them if I want more information. One problem with the links next to each of the tool names is it reduces the amount of readable space in the table, another idea may be to hyperlink each of the tool names to the appropriate site without listing out the whole URL, something I wish I would’ve done in my own table. I found the classification of Alcohol in layer 8, particularly its McCumber cube coordinates interesting because it’s placed as affecting integrity. Does this imply that it can be used as a tool to cause individuals to incorrectly input data or alter it? A better fit may be confidentiality where an individual may be more likely to divulge confidential information under the influence. The depth of the matrix in certain areas was quite extensive, particularly in layer seven. One area that was quite visibly lacking was layer one, where there was only one item. If there was an issue identifying items for layer one it should’ve been listed in the issues section of the report.
Your answer to the Ethereal vs. Wireshark question I believe is incomplete. Yes it is the predecessor but it would have been worth noting about the use of the Ethereal name by another open source project. I agree with the conclusion of question 2 where it is stated that “anything other than technology requires cognition for effective processing, and negates that ability to run an effective and automated attack.” The first time I read this I missed the “automated” part of it but in re-reading that is the main concept of this point but automated does not necessarily equal good which is echoed in the answer to the next question of the perceived bias to testers. Good results require cognition on the part of the tester, if penetration testing was easy enough to be automated with tools, it probably wouldn’t be such a specialized field as mentioned in the literature.
In conclusion, the report was well written from the literature review perspective. The size of the table shows that a significant amount of work went in to it but the formatting issue and lack of items for layer one indicate that maybe more time was spend on filling it out rather than ensuring the readability and accuracy of the information.
I find a lot of positive points with regard to this lab write-up. I thought the literature review was a good objective synthesis of information relevant to the lab-although the “over citation” was a bit distracting. It is my understanding that in the ‘preferred’ APA format the author/year is really only necessary ‘once’ per paragraph (at the beginning, with specific page enumeration where necessary thereafter) ‘unless’ a change is made with regard to which source is being discussed within that same paragraph (sort of like a state machine: once a source is defined, it is assumed to be from this source until a specific transition is made.). The ‘state machine’ model of APA citation is something that I have found very useful; I mention it with the hope that someone else might find it useful also.
The rest of the write-up was reasonably well done. I liked the terminology used: ‘taxonomy’, good word! Nice effort on the links for the tools also. I would have to say that I thought it was apparent that real effort went into grouping the tools in a technically correct fashion (with respect to ISO), and the McCumber cube coordinates were plausible also. I find the answer the ‘why technology’ question intriguing, and worthy of full separate discussion section.
The answer to the ‘why technology’ answer is nice-a good answer, clever also. This actually caused me to stop and think for quite some time: can it really be so simply summed up? After some pondering, I must conclude that the issue is more complex than this. I would agree that effective exploitation of the ‘human’ and ‘policy/practice’ domains certainly require cognition. What I am not convinced of is that ‘technology’ is different with respect to this. I think we can agree that no ‘true’ cognitive ability exists in today’s technological devices-fuzzy logic is well, ‘very’ limited; AI development has been stalled for at least the last twenty years. What we arrive at then, is that technology is incapable of autonomous self direction: therefore it ‘must’ rely on external factors for effective directed use. I would propose that technology relies on human cognition. For instance, who wrote the automatic scanning tools: why are some more ‘clever’ than others? Where do attack scripts and definitions of exploitable resources come from? Human cognition has accomplished all of this. When we strip it all away, it is an unavoidable truth that there are ‘cognition’ factors attributable to technological devices: they are human intelligence ‘trapped’ in such forms as a script or source files. Additionally, cognition is required for effective use of technology: put a cat in front of a computer loaded with exploit tools (none running yet, of course) on a unsecured network-what is the probability of a successful attack occurring? If these counterpoints presented are true, the answer to the ‘technology’ question in this lab does not really address a significant differing factor in the McCumber tools classification. All in all, a very nice angle for the answer, though-it is truly an idea which I had never entertained before.
I must admit that I am a bit let down with the answer to question three, the “self-selecting bias” question, however. After what I thought was an excellent answer to the previous question, this answer is unsatisfying. Forgive my ignorance, but what is a “manual self-section attack?” It sounds very painful (sorry, possibly ‘unprofessional,’ but I couldn’t resist). I gathered no more from this answer than a multi-worded “yes” without any real discussion of the topic-possibly something to fix in the future. In sum, I thought this paper to be both a rather nice lab write-up and a paper which presented concepts with substantial depth to them.
Team 2’s abstract was well written and very informative. I particularly liked their discussion of penetration testing and the risks associated with teaching such topics. They also did a good job of describing the way the lab was built and how it will be used in the future. Their literature review was well organized which made it easy to read and easy to compare articles with each other. It also helped in tying back the articles tothe lab exercise. The methods section discusses the process of how the test lab was set-up. Again as in the case with the other teams there was no use of screen shots to illustrate the implementation. I really though their table was difficult to follow, perhaps it was a formatting issue or maybe using a grid or table would have been better. They did have a findings and answers section and seemed to answer the required questions. Their issues seemed to line up with the same issues the other teams were having. I agree with their conclusions. Overall their paper was good.
Within the literature review section Team 2 did a great job on the supporting data, acknowledged if the articles had any errors or omissions, and compared the theme of the articles to each other. However, the literature review did not address the research questions that the articles had, providing that they contained them, did not address the methodology that was used except for the Martin Mink and Felix C. Freiling article, and did not relate each article to the lab itself.
The group did a good job with their method section by giving a brief overview of the lab and presenting the questions that are to be addressed by completing the lab.
There were a few discrepancies discovered in the section that had the exploits table. It appeared that your table was chewed up in the conversion process; my team had conversion problems also. The table was missing the technology column, which would explain what particular technology that exploit or attack tool would effect. However, it was nice that your team listed the websites where the attack tools came from. Some of the sections such as the people layer did not contain the required number of 30 exploits. Was the Kinetic layer for exploits that used computers to physically affect another computer or a system or machine that were connected to a network such as devices connected to SCADA controllers? Wouldn’t the tools that your team listed just affect the physical layer? Shouldn’t John the Ripper be placed in the Presentation Layer as opposed to Transport layer of the OSI model?
In the section where your team answered the questions I agree with your team in question 2 about the cognitive ability required to attack people and policy, but there is also the consideration that there is no way to attack a person directly or a policy with an attack tool downloaded from the Internet.
In the issue section, I have to disagree with your team in that you thought all of the backtrack tools had to be used. Professor Liles expected 300 tools because backtrack alone contains 300 tools. There were some backtrack tools that had no bearing on the lab at all. However, I do agree that the initial directions did create much misunderstanding.
In the conclusion statement, I have to somewhat disagree with the statement “Penetration testing can educate how defensives will hold against attacks.” Penetration testing could predict how defenses will hold against current attacks, but it could not predict how the defenses will hold against zero-day exploits. However, it could show weak spots, as your team said would educate Information Technology staff members where they must tighten their defenses at.
This group started off with the abstract and defining was is going to happen within the lab. Then they go into the literature review and compare all the readings to each other and bring out the underlining topics between them. I think they did this well but one thing that can be improved is that four a the literature reviews where more related to explaining what is red teaming/ penetration testing. While the other four discussed more how is penetration testing done within the lab environments. Then they go into the actual reviews of each individual piece of literature and briefly describe what the article or paper was about and then discuss it. One thing that was not present was how it relates to the lab. The next lab just be aware how they relate to what is to be done and include that within the reviews. The next part of the lab report then goes over the methodologies and what was accomplished during this lab. Again one thing each group lacked was a visual diagram that would help the readers relate to what was setup besides just knowing about the ip addressing and what vms where used. When the meaning say a picture is worth a thousand words they mean it. Having a diagram for that content will create a better understanding for those that may not be able to visualize the lab environment in their head. The next part of the methodology goes into explaining the questions that are to be answered and then the table with hundreds of tools. When going over the table i noticed that they citations should have been put in another part of the document. They also need to know that wikipedia is not a scholarly resource and can not be used as a resource. One thing that may help your citations in the future is visiting this site that will help with the understanding of APA5 and citing resources.
( http://owl.english.purdue.edu/owl/printable/560/ ) This site has helped many in the past and usually comes up when typed into Google. After fixing the citing the table could have been refined and more easily categorized without the citations being a distraction. After the table they go into their findings and answer the questions that we presented. The first answer may have been research a little better as because wire shark is the newer version of ethereal. Yes they do basically the same thing, but ethereal is no longer being updated because wire shark took its place and continues to improve and add new abilities to be able to analyze evolving networks. ( http://www.wireshark.org/). Next they went into discussing the issues that they had. They described of having to add more tools to the table. I would not see this more as a problem but something that will help give a backup to evidence of categorizing tools into the OSI model and the Mccumber cube. I am not saying that it was not annoying but I do not feel it was an issue. After their issues they conclude the lab and describe why would someone do penetration testing but then it almost stops and does seem to fit as a proper conclusion on what they learned and how it will relate to future experiences. Overall I believe they did learn from the lab and and will be able to refine the future labs.
Over all, Team 2 created a good document. The introductory paragraphs did a good job introducing the reader to the topic and setting the stage for the rest of the document.
In the first paragraph of the literature review, the author makes a very good introduction into the topic. However in the second paragraph, the author begins to bounce from topic to topic giving what basically amounted to a list of short descriptions of the articles. I found this very hard to follow. The third paragraph seemed a bit more cohesive and described articles pertaining to building a testbed and using it to teach vulnerability testing. The fourth chapter in the literature review was on the tools used in penetration testing, but then regressed to speaking of segregating the testbed. Placing that portion in the third paragraph would have made the reading a bit smoother and easier to follow. I think a short description of what fault injection is might work well after it was suggested that it might work well in vulnerability testing. The Methods section of the document did a very good job detailing the testbed that we will be using for the rest of the semester.
In the penetration testing tools section they listed several tools. I also like that it included the URLs to the various tools. However, I’m not sure I agree with their placement in the OSI 7 layer model. Amap, for example, is a network penetration testing tool. As such I believe it should be put into the network layer rather than the application layer of the OSI model. ADM DNS Spoofing is a DNS packet spoofing tool. It operates at the network level, and therefore should be in layer 3, the network layer of the OSI model. Autoscan is also a network scanner, and therefore should be placed in the network layer rather than in the application layer. Zenmap is a graphical front end for nmap, a network scanning tool. Ironically, nmap was placed in layer 4 while zenmap was placed in layer 7. DNS tracer is actually a network scanning tool and therefore I believe should be placed in the network layer of the OSI model rather than the application layer. CLamscan isn’t actually a penetration testing tool at all but a virus scanner, and therefore doesn’t belong in this model.
Team 2 had an excellent introduction and conclusion. They also had a very good and detailed description of the lab setup. Although there are a few minor grammatical errors, admittedly those are likely due to the rushed manner with which we all completed our labs.
I think that group 2’s write-up for lab 1 is good overall. The literary review was well done. How the readings relate to the lab was specifically identified. However, some of the text was very difficult to read with a citing in almost every section. Also, the page number for the references should have been included. The setup portion of the lab describing the networking of the machines was adequate. However, the steps used to set the IPs were not discussed. What about setting the IP address in Linux? Were these steps similar to Windows? The table containing the penetration testing tools was good. Although, all the entries in layer 8 appear to be more specifically resources than tools, the group should have written why the site is considered a tool. That is just my opinion though, because layer 8 is a little fuzzy. The second half of the conclusion seemed to be more of a definition of backtrack than an actual conclusion.
This group’s abstract talks about how teaching penetration testing is done better in actually performing the attacks. They do state that there are risks in creating a penetration lab. They also state that creating a penetration lab is very feasible. The abstract then goes into what is involved in the first lab. The group covers all the parts of the lab very briefly in this abstract. Next the group does a literature review on the readings that are given in the lab. They go about doing a literature review a bit different than others in this lab. The group first divides the readings up in to groups according to what the readings were about. Then they compare the readings of each group to each other. They grouped the readings into: strength and weaknesses of penetration testing, building a cyber war lab, and tools used. This way of doing a literature review worked great in comparing and contrasting the readings to each other and to this lab. The only problem with this literature review is that I didn’t see any were that talked about the methodology and the research of each of the papers. The group didn’t see that many omissions or mistakes. After the literature review the group then went into the method. In the method the group explained the four primary steps in the lab. Then they did a good job in explaining what they were going to do in each step. The group explained how they were going to set up the lab that they were going to use for the remainder of the class. They included what operating systems they were going to use and that they assigned static IP addresses to each of the operating systems and what those IP addresses were. Then they explained that they were going to align a set of tools to the OSI model and the McCumber cube to create a penetration taxonomy. Last they listed the three questions that they were going to answer. Next the group created the penetration testing taxonomy. The table was not easy to follow. Each of the entries seemed to run into each other. The table should have had some kind of boarder around each group to separate the different tools and the different categories. The group did do one thing that the other groups didn’t do in this table was to put were they got each of the tools. In the table the group lacked in some of the layers of the OSI model and had an excess in other layers. Next the group answered the three questions. They did a nice, but brief, job of answering each question. The answers on the questions went along with the answers that most the other groups gave. Next the group gave an issue that all the other groups had. They mentioned that the lab didn’t make it clear on how many tools we were to use in the table and that the instructor waited until the end of the week to clarify this causing the groups to scramble to accomplish the goal of the lab. Last the group made a conclusion to the lab. They stated how it is important to educate penetration testing and how it is a tool in information security instruction. The rest of the conclusion was on how Backtrack could be used to help in the penetration testing. I think that they could have put the part on Backtrack in another part of the lab and wrote more about what the lab showed them. At the end of the lab the group listed cites they used in the lab.
It was a good idea for the group to bunch the required readings into categories. Once the categories were made, the papers were compared to each other within the group as well as the other groups. One thing I thought that the literature review was missing was examples from within the papers and cite them with page numbers. I liked the little introduction in the abstract about penetration testing, but it did contain information that was would be better in an introduction than an abstract. The literature reviews did not seem to discuss the papers as well as they should have, but the comparisons were good. In the methods section the group discusses what was setup for the virtual machines, but the steps are not spelled out, nor are there any screenshots. The questions are clearly stated in the method section. The next part of the lab report was the table with all of the tools.
I thought that this part of the lab should go into the findings answered questions because the methods were to research the tools and the results should be the findings of the research. I found that as I went down the table I found it harder and harder to determine the dimensions of the McCumber cube and what tool they went with. A table with lines would have been easier to determine their proper places. I thought that it was nice that this group put the links they used to find the tools and also the definition of the tools in the table. Not all groups put the links for the definitions of the tools into their table. I agree that the only issue they had was the confusion that existed on how many tools were needed as well as where the tools should be located. I thought there would have been some issues with determining the proper places of the tools they located. Other groups seemed to have this problem of determining where the tools can go in the table. The group did not seem to put other technology tools into the table other than the backtrack tool suite. The group did have some interesting tools for layers 0 and 8, such as lockpick. I feel that there were not enough tools for layers 0 and 8. I don’t think that the tools that they found for layer 8 were really that good of examples of people tools. Dumpster diving and social engineering are better tools. Yes it is true that these websites can be used as attacks vectors, but the group did not include any policies. Dumpster diving can be avoided as an attack if the proper policies and procedures were put into place. Although the questions were answered, I felt that they were not answered well enough. For the possible bias, the group could have gone into greater detail about why this bias exists. The SANS book about penetration testing is a good reference to different suites of tools that could fit into the OSI model.
The team did a good job with the literature review. You efficiently explained the material while relating it back to the lab assignment and critically evaluating the work. The methods portion of the lab is considerably more minimalistic. The findings table was lengthy, though some of the tools listed are questionable. I want to specifically call into question the team’s “Layer 0” tools. While these methods provide kinetic effect, they are physical attacks. As such should they not be in layer one?
I disagree with your statement about cognition not being necessary for technology-based attacks. The tool without the thought of the user is just a thing. Even if automated, cognition must exist in the automating process. With this exception the findings& answers and conclusion are concise, but could use more detail. You relate what you learned from the lab, but how can you apply it? Is it useful?
I believe there is such a thing as overciting in your literature review. Check the APA guide for in-text citation details. I enjoyed reading the literature review from a topical standpoint but didn’t see anything linking the literature read to any of the lab activities. Once, when talking about Micco and Rossman’s positions on teaching cyber war classes, our class is mentioned but nothing further is said other than they bring up some “major points that … we need to keep in mind.” It would have potentially been beneficial for the class as a whole, not just related to this lab, to know what those major points are.
The threat table is difficult to read without any grid lines but I liked the inclusion of the links next to each of the tool names which makes it easy to link to them if I want more information. One problem with the links next to each of the tool names is it reduces the amount of readable space in the table, another idea may be to hyperlink each of the tool names to the appropriate site without listing out the whole URL, something I wish I would’ve done in my own table. I found the classification of Alcohol in layer 8, particularly its McCumber cube coordinates interesting because it’s placed as affecting integrity. Does this imply that it can be used as a tool to cause individuals to incorrectly input data or alter it? A better fit may be confidentiality where an individual may be more likely to divulge confidential information under the influence. The depth of the matrix in certain areas was quite extensive, particularly in layer seven. One area that was quite visibly lacking was layer one, where there was only one item. If there was an issue identifying items for layer one it should’ve been listed in the issues section of the report.
Your answer to the Ethereal vs. Wireshark question I believe is incomplete. Yes it is the predecessor but it would have been worth noting about the use of the Ethereal name by another open source project. I agree with the conclusion of question 2 where it is stated that “anything other than technology requires cognition for effective processing, and negates that ability to run an effective and automated attack.” The first time I read this I missed the “automated” part of it but in re-reading that is the main concept of this point but automated does not necessarily equal good which is echoed in the answer to the next question of the perceived bias to testers. Good results require cognition on the part of the tester, if penetration testing was easy enough to be automated with tools, it probably wouldn’t be such a specialized field as mentioned in the literature.
In conclusion, the report was well written from the literature review perspective. The size of the table shows that a significant amount of work went in to it but the formatting issue and lack of items for layer one indicate that maybe more time was spend on filling it out rather than ensuring the readability and accuracy of the information.
I find a lot of positive points with regard to this lab write-up. I thought the literature review was a good objective synthesis of information relevant to the lab-although the “over citation” was a bit distracting. It is my understanding that in the ‘preferred’ APA format the author/year is really only necessary ‘once’ per paragraph (at the beginning, with specific page enumeration where necessary thereafter) ‘unless’ a change is made with regard to which source is being discussed within that same paragraph (sort of like a state machine: once a source is defined, it is assumed to be from this source until a specific transition is made.). The ‘state machine’ model of APA citation is something that I have found very useful; I mention it with the hope that someone else might find it useful also.
The rest of the write-up was reasonably well done. I liked the terminology used: ‘taxonomy’, good word! Nice effort on the links for the tools also. I would have to say that I thought it was apparent that real effort went into grouping the tools in a technically correct fashion (with respect to ISO), and the McCumber cube coordinates were plausible also. I find the answer the ‘why technology’ question intriguing, and worthy of full separate discussion section.
The answer to the ‘why technology’ answer is nice-a good answer, clever also. This actually caused me to stop and think for quite some time: can it really be so simply summed up? After some pondering, I must conclude that the issue is more complex than this. I would agree that effective exploitation of the ‘human’ and ‘policy/practice’ domains certainly require cognition. What I am not convinced of is that ‘technology’ is different with respect to this. I think we can agree that no ‘true’ cognitive ability exists in today’s technological devices-fuzzy logic is well, ‘very’ limited; AI development has been stalled for at least the last twenty years. What we arrive at then, is that technology is incapable of autonomous self direction: therefore it ‘must’ rely on external factors for effective directed use. I would propose that technology relies on human cognition. For instance, who wrote the automatic scanning tools: why are some more ‘clever’ than others? Where do attack scripts and definitions of exploitable resources come from? Human cognition has accomplished all of this. When we strip it all away, it is an unavoidable truth that there are ‘cognition’ factors attributable to technological devices: they are human intelligence ‘trapped’ in such forms as a script or source files. Additionally, cognition is required for effective use of technology: put a cat in front of a computer loaded with exploit tools (none running yet, of course) on a unsecured network-what is the probability of a successful attack occurring? If these counterpoints presented are true, the answer to the ‘technology’ question in this lab does not really address a significant differing factor in the McCumber tools classification. All in all, a very nice angle for the answer, though-it is truly an idea which I had never entertained before.
I must admit that I am a bit let down with the answer to question three, the “self-selecting bias” question, however. After what I thought was an excellent answer to the previous question, this answer is unsatisfying. Forgive my ignorance, but what is a “manual self-section attack?” It sounds very painful (sorry, possibly ‘unprofessional,’ but I couldn’t resist). I gathered no more from this answer than a multi-worded “yes” without any real discussion of the topic-possibly something to fix in the future. In sum, I thought this paper to be both a rather nice lab write-up and a paper which presented concepts with substantial depth to them.
Team 2’s abstract was well written and very informative. I particularly liked their discussion of penetration testing and the risks associated with teaching such topics. They also did a good job of describing the way the lab was built and how it will be used in the future. Their literature review was well organized which made it easy to read and easy to compare articles with each other. It also helped in tying back the articles tothe lab exercise. The methods section discusses the process of how the test lab was set-up. Again as in the case with the other teams there was no use of screen shots to illustrate the implementation. I really though their table was difficult to follow, perhaps it was a formatting issue or maybe using a grid or table would have been better. They did have a findings and answers section and seemed to answer the required questions. Their issues seemed to line up with the same issues the other teams were having. I agree with their conclusions. Overall their paper was good.
Within the literature review section Team 2 did a great job on the supporting data, acknowledged if the articles had any errors or omissions, and compared the theme of the articles to each other. However, the literature review did not address the research questions that the articles had, providing that they contained them, did not address the methodology that was used except for the Martin Mink and Felix C. Freiling article, and did not relate each article to the lab itself.
The group did a good job with their method section by giving a brief overview of the lab and presenting the questions that are to be addressed by completing the lab.
There were a few discrepancies discovered in the section that had the exploits table. It appeared that your table was chewed up in the conversion process; my team had conversion problems also. The table was missing the technology column, which would explain what particular technology that exploit or attack tool would effect. However, it was nice that your team listed the websites where the attack tools came from. Some of the sections such as the people layer did not contain the required number of 30 exploits. Was the Kinetic layer for exploits that used computers to physically affect another computer or a system or machine that were connected to a network such as devices connected to SCADA controllers? Wouldn’t the tools that your team listed just affect the physical layer? Shouldn’t John the Ripper be placed in the Presentation Layer as opposed to Transport layer of the OSI model?
In the section where your team answered the questions I agree with your team in question 2 about the cognitive ability required to attack people and policy, but there is also the consideration that there is no way to attack a person directly or a policy with an attack tool downloaded from the Internet.
In the issue section, I have to disagree with your team in that you thought all of the backtrack tools had to be used. Professor Liles expected 300 tools because backtrack alone contains 300 tools. There were some backtrack tools that had no bearing on the lab at all. However, I do agree that the initial directions did create much misunderstanding.
In the conclusion statement, I have to somewhat disagree with the statement “Penetration testing can educate how defensives will hold against attacks.” Penetration testing could predict how defenses will hold against current attacks, but it could not predict how the defenses will hold against zero-day exploits. However, it could show weak spots, as your team said would educate Information Technology staff members where they must tighten their defenses at.
This group started off with the abstract and defining was is going to happen within the lab. Then they go into the literature review and compare all the readings to each other and bring out the underlining topics between them. I think they did this well but one thing that can be improved is that four a the literature reviews where more related to explaining what is red teaming/ penetration testing. While the other four discussed more how is penetration testing done within the lab environments. Then they go into the actual reviews of each individual piece of literature and briefly describe what the article or paper was about and then discuss it. One thing that was not present was how it relates to the lab. The next lab just be aware how they relate to what is to be done and include that within the reviews. The next part of the lab report then goes over the methodologies and what was accomplished during this lab. Again one thing each group lacked was a visual diagram that would help the readers relate to what was setup besides just knowing about the ip addressing and what vms where used. When the meaning say a picture is worth a thousand words they mean it. Having a diagram for that content will create a better understanding for those that may not be able to visualize the lab environment in their head. The next part of the methodology goes into explaining the questions that are to be answered and then the table with hundreds of tools. When going over the table i noticed that they citations should have been put in another part of the document. They also need to know that wikipedia is not a scholarly resource and can not be used as a resource. One thing that may help your citations in the future is visiting this site that will help with the understanding of APA5 and citing resources.
( http://owl.english.purdue.edu/owl/printable/560/ ) This site has helped many in the past and usually comes up when typed into Google. After fixing the citing the table could have been refined and more easily categorized without the citations being a distraction. After the table they go into their findings and answer the questions that we presented. The first answer may have been research a little better as because wire shark is the newer version of ethereal. Yes they do basically the same thing, but ethereal is no longer being updated because wire shark took its place and continues to improve and add new abilities to be able to analyze evolving networks. ( http://www.wireshark.org/). Next they went into discussing the issues that they had. They described of having to add more tools to the table. I would not see this more as a problem but something that will help give a backup to evidence of categorizing tools into the OSI model and the Mccumber cube. I am not saying that it was not annoying but I do not feel it was an issue. After their issues they conclude the lab and describe why would someone do penetration testing but then it almost stops and does seem to fit as a proper conclusion on what they learned and how it will relate to future experiences. Overall I believe they did learn from the lab and and will be able to refine the future labs.
Over all, Team 2 created a good document. The introductory paragraphs did a good job introducing the reader to the topic and setting the stage for the rest of the document.
In the first paragraph of the literature review, the author makes a very good introduction into the topic. However in the second paragraph, the author begins to bounce from topic to topic giving what basically amounted to a list of short descriptions of the articles. I found this very hard to follow. The third paragraph seemed a bit more cohesive and described articles pertaining to building a testbed and using it to teach vulnerability testing. The fourth chapter in the literature review was on the tools used in penetration testing, but then regressed to speaking of segregating the testbed. Placing that portion in the third paragraph would have made the reading a bit smoother and easier to follow. I think a short description of what fault injection is might work well after it was suggested that it might work well in vulnerability testing. The Methods section of the document did a very good job detailing the testbed that we will be using for the rest of the semester.
In the penetration testing tools section they listed several tools. I also like that it included the URLs to the various tools. However, I’m not sure I agree with their placement in the OSI 7 layer model. Amap, for example, is a network penetration testing tool. As such I believe it should be put into the network layer rather than the application layer of the OSI model. ADM DNS Spoofing is a DNS packet spoofing tool. It operates at the network level, and therefore should be in layer 3, the network layer of the OSI model. Autoscan is also a network scanner, and therefore should be placed in the network layer rather than in the application layer. Zenmap is a graphical front end for nmap, a network scanning tool. Ironically, nmap was placed in layer 4 while zenmap was placed in layer 7. DNS tracer is actually a network scanning tool and therefore I believe should be placed in the network layer of the OSI model rather than the application layer. CLamscan isn’t actually a penetration testing tool at all but a virus scanner, and therefore doesn’t belong in this model.
Team 2 had an excellent introduction and conclusion. They also had a very good and detailed description of the lab setup. Although there are a few minor grammatical errors, admittedly those are likely due to the rushed manner with which we all completed our labs.
I think that group 2’s write-up for lab 1 is good overall. The literary review was well done. How the readings relate to the lab was specifically identified. However, some of the text was very difficult to read with a citing in almost every section. Also, the page number for the references should have been included. The setup portion of the lab describing the networking of the machines was adequate. However, the steps used to set the IPs were not discussed. What about setting the IP address in Linux? Were these steps similar to Windows? The table containing the penetration testing tools was good. Although, all the entries in layer 8 appear to be more specifically resources than tools, the group should have written why the site is considered a tool. That is just my opinion though, because layer 8 is a little fuzzy. The second half of the conclusion seemed to be more of a definition of backtrack than an actual conclusion.