Peers Discuss ‘Hacking Inward,’ Cyber War Games at RSA Conference 2016

Posted on by RSAC Contributor

By Itzhak Kotler, Co-Founder and CTO, SafeBreach

During the recent RSA conference in San Francisco, I moderated a Peer2Peer session called “Hacking Inward—Implementing Effective Cyber War Games.”

hackerPeer2Peer group discussions center around specific security topics, where participants get the chance to really dig deeply into a topic. One of the reasons this particular topic is important is because validating your security in a continuous way is good security practice. It helps you identify your weaknesses, ensure your security strategies are sound, and exposes issues in time to be remedied. Companies don’t need to understand adversaries as much as they need to understand how adversaries view them.

By hacking inward and implementing effective war games, you can:


  • Unearth people, process and technology issues.
  • Answer the question of “Are we secure?” and “Can a breach happen to us?”
  • Practice and refine proper process/procedure for when a breach does happen.


We divided our discussion into three parts—people, process and technology.


End-users are typically the weakest part of an organization’s security strategy. This first set of discussion was on the potential for human error, mistakes and occasional stupidity by end users. The key focus for many organizations in the session was on education.

Reducing business risk and improving security starts with making sure employees realize that security is everyone’s problem. Similar to how you may report to authorities when you see an unattended bag at airports, the same type of vigilant employee base with a high level of imprinted situational awareness in action is required when it comes to cybersecurity.

Participants shared a variety of educational tactics. They ranged from “security” fairs to phishing campaigns that test the effectiveness of user education. Another participant shared how USB flash drives were dropped in the parking lot and common areas to see how many users would pick them up. One unusual tactic I found interesting was sharing information on attacks launched on the organization with employees. Instead of just explaining to employees the appropriate security best practices, this internal information sharing approach helps provide real examples of how attackers are specifically targeting their organization.


Most of the discussion on processes was around validation of third party processes especially payment processes, which seems appropriate in light of the recent Bangladesh bank heist, where a $20 million bank transfer was stopped because of a typo. The participants shared their specific process validation. In one example, the payment process for vendors triggers an alert if the invoice is above a certain threshold. Others shared that human intervention was necessary, and that specific employees were required to review certain transactions before they were approved.


We agreed that technologies that validate and prove that the security systems are functioning correctly are an essential part of a robust cybersecurity strategy. The typical organization in this session uses a combination of technologies and “specialized” humans to try to address this challenge. 

Participants discussed using a myriad of tools from patch management/vulnerability assessment tools to application security platforms. In addition, many also hire external pen testing teams for third-party validation. Most security leaders in the room were interested in building an internal security red team because of the benefits of an internal team that understands the business and can execute relevant breach scenarios. 

An internal red team can play true war games that give more complete answers across people, process and technology. But red teams tend to be limited to larger organizations with a fairly sizable security team and robust security framework. Participants who had internal red teams wanted to increase the frequency of security validation performed.

In general, participants felt that the existing security validating approaches are flawed. Dependency on specialized humans isn’t scalable, and the frequency of validation (annual/bi-annual) by external consultants do not accurately reflect true security risks. The majority of audience felt that a new way of automating and continuously validating our security controls was needed—an “automated red team” on a platform.  An automated platform not only helps addresses risks in dynamic environments, but also extends security validation to both internal and external attacks. This approach called “continuous security validation” or “attack simulation” is emerging technology that is available today, but we ran out of time for more in-depth discussions.

I want to thank everyone who participated in the Peer2Peer session. As a former red team leader, I believe in cyberwar games as an effective way to identify key issues that need to be remediated. Effective cyberwar games starts with understanding your business and security objectives, and testing the framework that you’ve put in place. By hacking inward on a continuous basis, you can test people, process and technology, and stay ahead of the attacker.

Itzik Kotler is CTO and Co-Founder of SafeBreach. Kotler has more than a decade of experience researching and working in the computer security space. He is a recognized industry speaker, having spoken at DEFCON, Black Hat USA, Hack In The Box, RSA Europe, CCC and H2HC. Prior to founding SafeBreach, Itzik served as CTO at Security-Art, an information security consulting firm, and before that he was SOC Team Leader at Radware (NASDQ: RDWR). Follow him on Twitter at @itzikkotler.

RSAC Contributor

, RSA Conference

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs