Defense in Depth is cool, and you should attend on October 3rd

For five years now, Red Hat and Intel have hosted a small, but very cool security conference called “Defense in Depth (DiD)” in Tyson’s Corner, VA. Its popularity has been increasing, and this year is a sort of watershed event in the show’s history. DiD has, in the past, been very focused on the security of Red Hat’s products; this year we’re casting a wider net around the security of many open source communities.

We even have an infosec A-lister keynoting — none other than David Kennedy of DerbyCon. In case you haven’t been watching CNN, Fox News, or other high-profile media outlets’ reporting on infosec, Dave’s kind of a big deal. His security roots run deep, and I’m super pumped to hear his keynote, “The Changing Tactics of Hackers,” which will talk about how only the first T in TTP tends to change, which can be handy for developing a counter-strategy.

The whole agenda looks cool, but here are some of the talks for which I am particularly stoked:

There are still conference passes available, so if you get geeked on open source security, register here.

Introducing the Fedora Red Team

Last week my colleagues and I started a new Special Interest Group under the Fedora Project: the Fedora Red Team.

The Fedora Red Team’s goal is to become Red Hat’s upstream cybersecurity community. But what does that actually mean?

“Cyber” is a fascinating term with a colorful history. I’ve written about it before, but the punchline is that we owe its ubiquity to William Gibson’s Neuromancer and an obscure US Government paper from the late 90s, referred to as The Marsh Report.

The context of The Marsh Report seems to have stuck — cyber has come to refer to the high-stakes interplay of offensive and defensive infosec, often at nation-state scale. If you want to get ontological, you could say “cyber” includes the three sub-domains of Computer Network Operations (CNO) — Computer Network Defense, Computer Network Exploitation, and Computer Network Attack.

So why a Fedora Red Team? My colleagues and I needed a place to work on offensive tooling, exploit curation, standards, and reference architectures — but we wanted to do it “the open source way.” A Fedora SIG gives us a community place to fail-fast these projects, a few of which I’ll mention here.

The Enterprise Linux Exploit Mapper (ELEM): as Mike Bursell wrote in his blog, many system administrators find themselves unable to patch. The CVE scoring system helps admins decide when to really push for patching, but many CVE descriptions contain language like “this vulnerability may allow an attacker to execute arbitrary code.” And there’s a reason for that — many vulnerabilities don’t have workable POCs. But what about the ones that do? ELEM makes it easy to map vulnerabilities on a local system to known exploits out in the wild. From a defensive perspective it creates a sort of super-criticality for admins so they can say to their management, “somebody can download this exploit and root our box right this minute.” A tool like this has good offensive value as well, and could save pentesters time doing these mappings manually.

The Fedora Cyber Test Lab (FCTL): I’ve written before about the Cyber-ITL and how important it is to the future of infosec. My only complaint is that their TTPs are not open source, and are not repeatable. So let’s fix that. This project will be an open source, automated, fully repeatable project for quantifying risk at a per-binary level. It will focus at first on RHEL, CentOS, and Fedora, but we’d love help from the community with adding other OS targets. I have a rudimentary first version ready to push to GitHub, which I’ll be blogging about in the coming days.

Penetration Testing Execution Standard (PTES): I’ve written before about how much I love PTES. In my mind, it’s a really important component of the art of pentesting. How can you tell a client that you’ve tested their security according to industry best practices without a yardstick by which to measure those practices? Without such a standard, pentesting relies too much on personal bona fides and flashy marketing. A standard like PTES can fix that. The only problem is that it hasn’t really been updated since 2014. Last summer, I rejiggered the wiki markup into ReStructured Text and put it on Read the Docs, which makes it easier to build community participation. The project is ready to be resurrected, and I hope that we’ll be able to work with the original team. But worst-case, we can fork it and go from there. This isn’t necessarily bad, and the PTES founders may have their reasons for wanting to let the project stay as it is. The Red Team SIG should know by early October which direction we’ll be taking.

I’m excited about this SIG, and will be haunting #fedora-security on Freenode IRC, as well as the security@lists.fedoraproject.org list. Every first Friday of the month we’ll be having meetings in IRC at 1400 UTC. Please join the conversation, or send us your pull requests for our GitHub projects.

Also, if you’re in Northern Virginia on 3 October 2017, we’ll be presenting ELEM at Defense in Depth. Register here and geek it up with us face-to-face!

Disclaimer: while I am talking about work stuff, this is my personal blog, and these views are my own and not my employer’s.

GitHub two factor authentication with IntelliJ

I’m a big fan of the IntelliJ products and derivatives, particularly Pycharm and Android Studio.

I also use two factor authentication (2fa) on every site that supports it. GitHub, no stranger to awesomeness, supports 2fa like a boss!

The easiest way to make your IntelliJ IDE jive with your 2fa-enabled GitHub account is to use personal API tokens. You have to be careful with these, because they’re a form of single-factor authentication, but since they’re long, random, and typically used for one purpose (i.e., you’re IDE), I think their overall impact to your account’s security is acceptable.

After you’ve created your personal API token (I used the default settings), open your settings dialog in your IntelliJ IDE. pycharm_github_settings

For “Auth Type” pick “Token.” Insert your token into the field, click “Test” to see if it worked, and you’re good to go!