Open source software security

SEI Advanced Incident Handling - Day 4

30 November -0001

The Software Engineering Institute, part of Carnegie Mellon University, and the organization that comprises CERT, offers an Advanced Incident Handling (AIH) course that I am currently attending. The course is offered in several locations, I'm taking it in Pittsburgh at SIE. The class is being offered in the SIE building, which is right between CMU and University of Pittsburgh's campuses.

Day4 of the Advanced Incident Handling class followed the same breakneck pace. I would again emphasize the quality and diversity of the other participants in the class. There are 11 students in the class who include folks from Allegheny Digital, CERT, the Japanese Army and Navy, the FBI training center in Quantico, VA, the British Ministry of Defense, and others. It's a very high quality group of peers, which helps the class flow and provides some very interesting sidebar discussions.

Advanced Incident Handling Day 4 continued with artifact analysis. We covered various code obfuscation techniques as well as identification of shellcode. Then we moved to an artifact example, to look at a potentially recoverable piece of code.

Next the class covered strategies for artifact analysis. This included identifying consistent procedures for collection and recording of artifacts, defining a cataloguing scheme for artifacts, defining a common analysis template, a priority for analysis and finally a system for storage of artifacts. Again, the class pointed out that not every facility is equipped to do a full artifact analysis.

We then did another exercise, this one was an escalating scenario from our previous exercises. In this exercise we went though an artifact analysis, including identifying and analyzing evidence of a compromise.

The next module on day for was the fundamental causes of vulnerabilities. This was a wide ranging module and although we covered a lot of material, much of the coverage was shallow - designed to familiarize participants with concepts rather than make them subject matter experts.

We spent a significant amount of time on definitions of lexical terms associated with incident handling. We defined vulnerability, risk, threat, and exploit, and how all these terms interact and tie together. We discussed the difference between security flaws and vulnerabilities as well. This discussion was extremely helpful in framing discussion and the rest of the module content.

We discussed various types of vulnerabilities and injection paths for the introduction of vulnerabilities. These included scenarios where vulnerabilities could be introduced in the specifications, design, implementation, testing or maintenance phases. A case study of the Ariane 5 rocket disaster was examined to demonstrate these concepts.

We also examined various classes of vulnerabilities. These including timing windows (race conditions), improper use of algorithms, buffer overflows and strings vulnerabilities and trusting untrustworthy information (input validation). We then quickly went through a few examples of each of these vulnerabilities.

A significant period of time was spent on buffer overflows, although the coverage was superfluous it was designed to enhance familiarity. This was another example of how the course is designed to train people to recognize concepts and the skills necessary in a CSIRT team in order to respond to various responsibilities. The idea wasn't necessarily to make participants proficient in buffer overflow detection and/or exploitation, but to train participants to recognize the skills they need to have in people on a CSIRT team in order to handle buffer overflows.

The end of day 4 was pretty exhausting. We spent the entire day in exercises or in fairly intense modules. There was a lot of information that had to be absorbed fairly quickly.