Posted on Sunday August 17, 2008 by Bellanov Apilli
I had dinner with Professor Tao today and discussed the conclusion of the project, the paper. We went over how each section of the paper should be addressed, as well as the content and proper format, and plagiarism. After covering each section in detail, I have a better perspective of how research papers should be. I will be receiving slides containing a general outline of the paper-writing process. Until then, I will be summing up any ideas I come across.
Showing posts with label Policy Research. Show all posts
Showing posts with label Policy Research. Show all posts
Saturday, December 27, 2008
Bit Vector Input (cont'd)
Posted on Friday August 08, 2008 by Bellanov Apill
I have implemented the ideas JeeHyun and I discussed, deciding on "$" as the delimiting character in the output format. I kept the existing feature, which was insufficient, but have also implemented the bit vector method successfully, sending that data to a separate file. The files are denoted differently (original input as *.input & the vector as *.inputVector). I have sent the program(s) to JeeHyun and he will convert the data into the request format for testing.
I have implemented the ideas JeeHyun and I discussed, deciding on "$" as the delimiting character in the output format. I kept the existing feature, which was insufficient, but have also implemented the bit vector method successfully, sending that data to a separate file. The files are denoted differently (original input as *.input & the vector as *.inputVector). I have sent the program(s) to JeeHyun and he will convert the data into the request format for testing.
Bit Vector Input
Posted on Thursday August 07, 2008 by Bellanov Apilli
I met with JeeHyun today to address the format the bit vectors will be in, deciding on a format he could easily convert from.We decided no a format comprising of both the attribute and its type. We also discussed the so-called complex file types (true & false) and decided to implement them as individual attributes. I implemented the idea into the FireEye conversion class I wrote. The format I chose is as follows: attribute : type. I kept the spaces between to make it more readable for JeeHyun when it comes time for him to convert it. This process is complete for code A - D, conference, and pluto. The remaining two (continue a & b) will soon be finished, once I correctly ignore the irrelevant lines.
I met with JeeHyun today to address the format the bit vectors will be in, deciding on a format he could easily convert from.We decided no a format comprising of both the attribute and its type. We also discussed the so-called complex file types (true & false) and decided to implement them as individual attributes. I implemented the idea into the FireEye conversion class I wrote. The format I chose is as follows: attribute : type. I kept the spaces between to make it more readable for JeeHyun when it comes time for him to convert it. This process is complete for code A - D, conference, and pluto. The remaining two (continue a & b) will soon be finished, once I correctly ignore the irrelevant lines.
Next Step(s)
Posted on Monday August 04, 2008 by Bellanov Apill
I met with professor Tao today to discuss the necessary steps to take in order to achieve our goal, the coverage testing. As of now, my implementation is able to handle all combinations, given that one value is taken for subject, research, and action each time. Although this method may cover a significant number of requests, it will not be sufficient. It fails in covering cases where more than one of each type (subject, resource, value) were taken. The solution we came up with was similar to what we discussed the very first day, a bit vector whose length is as long as the number of attribute values. I will implement this idea as soon as I am fully complete with the current task, which is converting the FireEye output back into request format. Converting these values will enable us to test coverage, although it may be only for primitive case (one subject, resource, and action at a time). Once I am finished with implementing the conversion on the primitave cases, I will do the same for the complex (more than one subject/resource/action taken at once). In order to successfully convert the files into requests, I need to find some way to map the attributes to their other components, such as their type, id, etc, so I can keep track of their relationships.
I met with professor Tao today to discuss the necessary steps to take in order to achieve our goal, the coverage testing. As of now, my implementation is able to handle all combinations, given that one value is taken for subject, research, and action each time. Although this method may cover a significant number of requests, it will not be sufficient. It fails in covering cases where more than one of each type (subject, resource, value) were taken. The solution we came up with was similar to what we discussed the very first day, a bit vector whose length is as long as the number of attribute values. I will implement this idea as soon as I am fully complete with the current task, which is converting the FireEye output back into request format. Converting these values will enable us to test coverage, although it may be only for primitive case (one subject, resource, and action at a time). Once I am finished with implementing the conversion on the primitave cases, I will do the same for the complex (more than one subject/resource/action taken at once). In order to successfully convert the files into requests, I need to find some way to map the attributes to their other components, such as their type, id, etc, so I can keep track of their relationships.
FireEye Input Conversion
Posted on Sunday July 27, 2008 by Bellanov Apilli
I have now completed a program that extracts the attribute data from the policies, compiles them into lists, and writes the data to a text file that is compatible with FireEye. The program, thus far, works correctly for the simplest samples (codeA - codeD as well as pluto). JeeHyun has informed me that some of the policies contain complex names (such as those with numerous occurrences of the "true" attribute) and I am now trying to figure out a way to incorporate these attributes. I have some ideas and will discuss them with JeeHyun before attempting to implement them.
I have now completed a program that extracts the attribute data from the policies, compiles them into lists, and writes the data to a text file that is compatible with FireEye. The program, thus far, works correctly for the simplest samples (codeA - codeD as well as pluto). JeeHyun has informed me that some of the policies contain complex names (such as those with numerous occurrences of the "true" attribute) and I am now trying to figure out a way to incorporate these attributes. I have some ideas and will discuss them with JeeHyun before attempting to implement them.
Attributes & FireEye
Posted on Friday July 18, 2008 by Bellanov Apilli
I met with JeeHyun today to further discuss applying FireEye to the policies. He noted that he possessed a program that extracted data from the policies, compiling them into a tree structure. This tree structure is used by the classes in the project to for numerous tasks, including the creation of the requests. I believe utilizing this program would simplify the process of converting it into FireEye input. I am supposing isolating each type of attribute (subject, resource, action) into it's own respective file. After this isolation will come the compilation of each of these into appropriate FireEye input. As of now, I have been experimenting in FireEye, trying to get a feel of what the generic format of the input file will be. I've got a general idea and will implement it as soon as I receive the program from JeeHyun.
I met with JeeHyun today to further discuss applying FireEye to the policies. He noted that he possessed a program that extracted data from the policies, compiling them into a tree structure. This tree structure is used by the classes in the project to for numerous tasks, including the creation of the requests. I believe utilizing this program would simplify the process of converting it into FireEye input. I am supposing isolating each type of attribute (subject, resource, action) into it's own respective file. After this isolation will come the compilation of each of these into appropriate FireEye input. As of now, I have been experimenting in FireEye, trying to get a feel of what the generic format of the input file will be. I've got a general idea and will implement it as soon as I receive the program from JeeHyun.
NSF REU project on "Testing and Verification of Security Policies"
Posted on Sunday July 13, 2008
We recently recieved an NSF REU supplement grant for my existing NSF grant on Testing and Verification of Security Policies.
Bellanov Apilli, an undergraduate student from our NCSU CS department, has recently joined our project team to work on this REU project. Welcome!
(Sorry that my this annoucement of the project comes in later than Bellanov's first post on his progress below. Bellavnov, keep up the good work in keeping your progress posted here along the way!)
We recently recieved an NSF REU supplement grant for my existing NSF grant on Testing and Verification of Security Policies.
Bellanov Apilli, an undergraduate student from our NCSU CS department, has recently joined our project team to work on this REU project. Welcome!
(Sorry that my this annoucement of the project comes in later than Bellanov's first post on his progress below. Bellavnov, keep up the good work in keeping your progress posted here along the way!)
Subscribe to:
Posts (Atom)