Category Archives: Cybersecurity

Spring 2014 Recap

In Spring 2014, my final semester at the University of Hawaiʻi at Mānoa, I completed my undergraduate project, worked as a teaching assistant for an introductory cybersecurity course, and completed my undergraduate degree.

1. ICS Security Assistant: ICS 425, Cybersecurity and Ethics I

As a teaching assistant to Professor Barbara Endicott-Popovsky of the University of Washington, I supported the teaching of the course by posting and grading assignments, responding to student concerns, and managing student peer evaluations and weekly discussions of current events in cybersecurity. I had taken this course one year ago in the Spring 2013 semester, which prepared me well to communicate the course material to students this year.

Meetings with the professor to plot the course of the lessons, appraise my performance, and address student concerns occurred once a week, usually by phone.

This was a distance learning course, so I did not have set office hours. All discussion and communication with students occurred through email or forums managed on Laulima, a collaboration system for the University of Hawaii that is built on the Sakai platform.

2. ICS Undergraduate Project, Part 3: Spring 2014

As in the previous semester, my responsibilities as a member of the Collaborative Software Development Laboratory were to maintain the documentation for the Ubuntu, CentOS, and Vagrant installation methods, and to maintain the Vagrant provisioning script and its supporting files.

Resolving Compatibility Issues for Makahiki Dependencies

The release of pip 1.5 on New Year’s Day 2014 temporarily broke the Vagrant provisioning script (the bash shell script mentioned in previous posts). Makahiki was, and as of August 2014 still is, dependent on several external, unverified Python packages, including the libraries services for Django, PIL, NewRelic, Sphinx, and Markdown.

After changing the provisioning script to use setuptools-0.8 for compatibility with pip 1.5.x, I ran through the Ubuntu virtual machine installation process several times to determine which pip-installed packages needed to be flagged with “allow-external” or –allow-unverified” to be installed. The pull request describing the proposed changes can be seen here.

The development team decided that it was simpler to remain on the last known compatible version, pip 1.4.1, so I reverted the changes in my code and changed the documentation to install that older version instead (see GitHub pull request 592). However, the modified pip commands were needed to pass the CSDL’s Travis CI testing, which built the software using the newest version of pip (see GitHub pull request 603).

In early January, the sequence of commands used to install the Python Software Collections Library (SCL) stopped installing Python 2.7.3, and stopped installing correctly on i386-architecture CentOS virtual machines. This was the result of the maintainer of the SCL switching to Python 2.7.5 and ending support for i386 architectures.

At the time, Makahiki on CentOS required Python 2.7.3. To enforce this version requirement, I revised the installation process to compile and install Python 2.7.3 from source code after installing development packages. This was based on my previous work on the now-deprecated Python installation scripts for Ubuntu and CentOS, which had also compiled and installed Python 2.7.3 from source code. These changes were applied to Makahiki in March 2014 (see GitHub issue 586).

Towards the end of January, I was also a Smart Grid Game administrator for the 2014 Kukui Cup, a sustainability and alternative energy educational game supported by the Makahiki and WattDepot software. As an administrator, I was responsible for evaluating and scoring submissions for the activities and questions which students completed and submitted through the Makahiki Smart Grid Game module.

In late February, we were able to remove the VirtualBox version warning from the documentation after tests with Virtualbox 4.3.8 demonstrated that the bugs caused by VirtualBox 4.3.0 had been fixed (see GitHub pull request 603).

Though some work was done on the alternate configuration user interface, I spent March through May working on completing the data analysis and undergraduate thesis writeup for my Honors Upper Division project.

Conclusion of the Honors Upper Division Project

My undergraduate research was presented at the 2014 Spring Symposium, held on May 8, 2014. The undergraduate thesis was submitted to the Computer Science department and the Honors Department. Links to full versions of each document are provided below:

The main insight gained from the usability testing was that the Vagrant installation method that I had developed represented a significant time savings over the manual installation method, cutting over an hour from the average setup and configuration time. This was accomplished by using a single, default Ubuntu 12.04 LTS virtual machine as the environment for Makahiki, which enabled the installation of software packages and replacement of configuration files to be automated in Vagrant. This reduced the need for OS-specific installation steps, since all users of a Vagrant installation would be installing Makahiki onto the same virtual machine. The usability testing also helped to indicate areas of the documentation which were difficult to understand or likely to cause user error, and these areas were cleaned up after the study had been finished.

I received my B.S. in Computer Science with Honors from the University of Hawaiʻi at Mānoa, graduating on May 17.

3. The George Washington University

After a successful application to The George Washington University’s Cybersecurity in Computer Science master’s degree program, I am preparing to begin my studies at the end of this month. I was fortunate to be awarded a CyberCorps scholarship, and I am looking forward to experiencing the unique opportunities for academic and professional development that are available at the university.


Po’oihe Cyber Security Exercise

In July 2013, I attended planning meetings and contributed injects (competition exercises) for the Po’oihe Cyber Range’s first annual Cyber Security Exercise as a member of the White Team. The actual Po’oihe exercise took place from August 2-4, 2013 at the University of Hawaii at Manoa. The Blue Team played the role of the IT department for a Hawaii bank.

Po'oihe participation certificate.

Certificate of participation (click for large image).


The Cyber Security Exercise followed a structure of simulated cybersecurity exercises that divided competitors, support staff, and judges into five categories.

The Five Teams You Meet at a Cybersecurity Exercise

  • Blue Team
    A cybersecurity competition has multiple Blue Teams, each one made up of people from a specific company, school, or other organization. Pooihe had a mix of businesses, schools, and Armed Forces teams. Each team has a Team Captain and Team Co-Captain who were responsible for communicating with the White Team.
  • Red Team
    The Red Team is a team of cyber security professionals who work to disrupt the operation of the computers that the Blue Team is responsible for. Once the team gains unauthorized access to a system, they can add and delete users, deface web pages, bring down critical services, plant keyloggers and other listening tools, or whatever else is needed for the exercise. Once a Blue Team detects that the Red Team has gained access to their system, they are usually required to file an incident report with the White Team that describes the impact of the Red Team attack, the evidence for the attack, and any steps taken to mitigate the attack.
  • White Team
    The White Team serves as the judges for the event, scoring the performance of each Blue Team and enforcing the rules of the competition. At the Po’oihe exercise, the White Team also designed the exercises, or “injects” for the event.
  • Black Team
    The Black Team is in charge of setting up the competition environment (equipment, rooms, etc.) in advance of the competition.
  • Gold Team
    The Gold Team acts out the roles of the management and staff of the fictional company in all communications with the Blue Teams.


Each inject consists of a task (such as creating a security policy, setting up a web server, configuring a firewall, etc.), a time deadline, and a point value. Each inject is scored according to a separate document that defines how it will be scored. Injects are delivered to each Blue Team as printouts or by email at specific times during the competition. Each Blue Team’s total score on all injects is used to determine the overall winner of the exercise.

Injects are judged by the White Team during or after the competition. Teams will lose points for an inject if their results are incomplete, incorrect, or otherwise not sufficient to meet the criteria for the exercise. The overall score of a team for all of its submitted injects determines its ranking.

Further reading about the Po’oihe exercise