In most cases, building is not a precursor for breaking, nor are learners directed to cheat, but Rahul Chatterjee and Matthew Berland are trying a new approach. “Build-it Break-it Fix-it” (BiBiFi) is a type of computer security competition developed by the University of Maryland (UMD), in which participants do just that.
“You build your own system, then you attack someone else’s,” says Chatterjee, an assistant professor of computer sciences. “The last part that the people at UMD brought in is ‘fix-it,’ which is very interesting because now you learn — by breaking someone else’s system — what you can change to improve the security and safety of your own.”
“We find lots of people actually are already informally learning security stuff through these games, these competitions that are really very fun,” adds Berland, a professor of curriculum and instruction in the School of Education.
Chatterjee’s empirical-analytical approach to research and Berland’s aptitude for designing student-centric curricula make for a dynamic duo. They created “Learning Threat Perception through Build-Break-Fix Assignments,” a research project funded by the National Science Foundation (NSF) to investigate the promising BiBiFi framework as a means of exposing students to security problems in low level computer sciences courses.
“We graduate about 700 students per year in computer sciences, but unfortunately, less than 100 actually take security courses in their tenure. And that’s not because security is unexciting!” Chatterjee emphasizes. “It’s just that the computer sciences curriculum is so crowded, some don’t have an opportunity to take security, even if they want to, before they graduate.”
For most people, cybersecurity means locking personal devices, keeping passwords private or, begrudgingly, adding that “special character.” It might entail some exasperation for the duo-authentication interloper, or worse, the classic “new password must be different from old password.”
Well, up-and-coming computer scientists are under the same impression: It’s inconvenient.
“They know they need to have what’s called ‘good code hygiene’ for classes, but it sometimes just adds time and mess to what they’re doing, and they don’t understand why they’re doing it,” says Berland. “In the current system, only one out of every nine get that level of understanding about what things will become security problems when they’re writing code.”
This problem is not unique to UW–Madison. Across the country, computer sciences departments are looking for research-backed, validated activities for courses. This new approach explains what to do and how to do it, so that students gain awareness. Because of this, Chatterjee and Berland’s research could have a nationwide impact.
“Threat perception is essentially thinking about a potential threat, a potential attack in some capacity,” says Michelle Jensen, a graduate student and project assistant in Chatterjee’s lab who meets with individual participants over two one-hour Zoom sessions. “And then secure design is coming up with things you do in your code to prevent those attacks. Those are the big things we’re looking for, but we want to see what they do naturally, with very minimal scaffolding.”
The idea is to build threat perception by gamifying the process. For example, the session’s “build-it” scenario ends with a tip-off.
“You are on a team that is creating a game called ‘Epic Escapades: A Textual Odyssey,’” explains Jensen, who also works in MADS&P, a computer security and privacy research group, and the Complex Play Lab (CPL). “Your job is to help implement the code that is responsible for keeping track of the game state and the passcode system. You and your team are aware that players will try to cheat in the game when it is released.”
The passcode system is an old-school method of saving game progress. Coders create a series of passcodes that correspond to specific milestones, giving players a way to return to the point they’ve reached and continue their journey.
“A passcode that isn’t very well hidden could look something like …” Jensen says, pulling out a pink iPad and writing out:
“[The level name], [health upgrades], [current health items], [required item to progress]”
“All the information is here for them to read. So, someone who’s seeing this would just be able to plug-in the name of a later level and skip ahead,” she explains. “That’s implementing the passcode system without taking a cheating player into account. You’re assuming that your user always has good intention and won’t ever make a mistake that causes havoc.”
Participants must build with anticipation of an attack, because, in session two, they become the attacker. From the user-end, they try to “break” (find a way to exploit) someone else’s Odyssean implementation. Oftentimes this means defying the constraints of the game state, which pertains to situational details like current level, inventory, health, etc. If the maximum health is 10, players shouldn’t be able to devise a way to get to 13.
Or, to use a real-world example, if someone has $100 in the bank, they shouldn’t be able to take out $130.
“These students are going to go out, and they’re going to build our whole societal infrastructure, which now relies on tech in some way or another,” says Chatterjee. “They need to know how security and threats can evolve in practice.”
It’s not lost on Chatterjee and Berland that the NSF funding that fuels their efforts remains at risk at the federal level.
“Without the NSF funding research like this, classes are worse, people learn less, and the next generation of code is insecure,” says Berland.