Adobe “Hack Days”

PostsThe Archives

Within the ASSET team, we apply different techniques to keep our skills sharp. One technique we use periodically is to hold a “hack day,” which is an all-day event for the entire team. They are similar in concept to developer hack days but they are focused on security. These events are used to build security innovation and teamwork.

As in many large organizations, there are always side projects that everyone would like to work on. But they can be difficult to complete or even research when the work has to be squeezed in-between meetings and emails. The “free time” approach can be challenging depending on the state of your projects and how much they eat into the “free time.”  Therefore, we set aside one day every few months where the team is freed from all distractions and given the chance to focus on something of their choice for an entire day. That focus can generate a wealth of insight that more than compensates for the time investment. We have learned that sometimes a creative approach to security skill building is necessary for organizations that have a wide product portfolio.

There are very few rules for hack day. The general guidelines are:

  • The work has to be technical.
  • Researchers can work individually or as teams.
  • The work does not have to be focused on normally assigned duties. For instance, researchers can target any product or service within the company, regardless of whether they are the researcher assigned to it.
  • The Adobe world should be better at the end of the day. This can be a directly measurable achievement (e.g., new bugs, new tools, etc.). It can also be an indirect improvement, such as learning a new security skill set.
  • Researchers work from the same room(s) so that ideas can be exchanged in real time.
  • Lunch is provided so that people can stay together and share ideas and stories while they take a break from working.

Researchers are allowed to pick their own hack day projects. This is to encourage innovation and creative thinking. If a researcher examines someone else’s product or service, it can often provide a valuable third-party perspective. The outcomes from our hack days have included:

  • Refreshing the researcher’s experience with the existing security tools they are recommending to teams.
  • Trying out a new technique a researcher learned about at a conference but never had the chance to practically apply.
  • Allowing the team time to create a tool they have been meaning to build.
  • Allowing the team to dig into a product or service at a deeper level than just specs and obtain a broader view than what is gained by spot reviews of code. This helps the researcher give more informed advice going forward.
  • Providing an opportunity for researchers to challenge their assumptions about the product or service through empirical analysis.
  • And of course, team building.

A good example of the benefits of hack days comes from a pair of researchers who decided to perform a penetration test on an existing service. This service had already gone through multiple third-party consultant reviews and typically received a good health report. Therefore, the assumption was that it would be a difficult target because all the low-hanging fruit had already been eliminated. Nonetheless, the team was able to find several significant security vulnerabilities just from a single day’s effort.

While the individual bugs were interesting, what was more interesting was trying to identify why their assumption that the yield would be low was wrong. This led to a re-evaluation of the current process for that service. Should we rotate the consultancy?  Were the consultants focused on the wrong areas? Why did the existing internal process fail to catch the bugs? How do we fix this going forward? This kind of insight and the questions it prompted, more than justified a day of effort, and it was a rewarding find for the researchers involved.

With a mature application, experienced penetration testers often average less than one bug a day. Therefore, the hack day team may finish the day without finding any. But finding bugs is not the ultimate goal of a hack day. Rather, the goal is to allow researchers to gain a deeper understanding of the tools they recommend, the applications they work with, and the skills they want to grow. We have learned that a creative approach to security skill building is necessary for organizations, especially ones that have a wide product portfolio.

Given the outcomes we have achieved, a one-day investment is a bargain. While the team has the freedom to work on these things at any time, setting aside official days to focus solely on these projects helps accelerate innovation and research—and that’s of immense value to any organization. Hack days help our security team stay up to speed with Adobe’s complex technology stacks that vary across the company.  So if your organization feels trapped in the daily grind of tracking issues, consider a periodic hack day of your own to help your team break free of routine and innovate.

Peleus Uhley
Lead Security Strategist


Posts, The Archives

Posted on 03-24-2015