cybersecurity

Cultivating Infosec Knowledge

Posted on by jra

I often get asked through both work and social media channels how and where do I obtain all of the Information Security knowledge that I routinely share. So I though I would share my own personal workflow for how I cultivate Infosec knowledge and others can use what I’ll describe in this blog post as a framework to build their own. I should point out that my workflow is dependent upon using a Linux distro that supports specific packages such as Weechat. If you are primarily a Windows user, you may need to make some adjustments

I often get asked through both work and social media channels how and where do I obtain all of the Information Security knowledge that I routinely share. So I though I would share my own personal workflow for how I cultivate Infosec knowledge and others can use what I’ll describe in this blog post as a framework to build their own. I should point out that my workflow is dependent upon using a Linux distro that supports specific packages such as Weechat. If you are primarily a Windows user, you may need to make some adjustments such as start using Ubuntu.

Step 1: Twitter

By far the best source for cultivating knowledge is Twitter. First there are tons of Information Security professionals from pretty much every domain of knowledge within Infosec. This involves of course obtaining an account(make sure you leverage 2FA) and following users who specialize in the area that your interested in. Another great feature are ‘Lists’. These are groups of Twitter users for a specific area. This one is a good start: https://twitter.com/DanielMiessler/lists/infosec. So got get yourself an account if don’t have one and start searching using hashtags such as #cybersecurity or #infosec.

Step 2: IRC Client That Logs Locally

You may be asking what is IRC and why do I need an IRC client to cultivate Infosec knowledge? This will become obvious as this post progresses, but IRC was an Internet standard draft created 20+ years ago to create a real-time chat network. The reason you want a modern IRC client that supports logging locally is that there is an IRC gateway called Bitlbee that enables you to integrate with Twitter and the like into the IRC client, which enables you to log all of that content for later reference and searching.

I personally use Weechat due to all of the plugins available for it and being able to leave it running 24X7 in a Tmux session. Think of Tmux as a means of running persistent terminal sessions.

Step 3: Bitlbee

As mentioned earlier Bitlbee is an IRC gateway that acts as a relay between your IRC client and the platforms it supports such as Twitter and Facebook. For my purposes the Twitter integration is key, because it basically turns your IRC client into a Twitter client and most importantly your Twitter timeline is logged locally as long as you have it running. This is where Tmux comes in so even if you log out your sessions are still running. This becomes advantageous when you want to pull out a bunch of links or content, all you have to do is grep through your Bitlbee Twitter logs.

Step 4: Slack & WeeSlack

Slack is a modern attempt to displace IRC utilizing web based API’s and pretty looking integrations such as emoji’s and integrations with a large number of automation technologies such as Splunk and devops apps. There is one Slack channel that has LOTS of Infosec peeps on it and it’s called Brakesec and is run by Bryan Brake. Follow him and send him a Tweet asking for access.

I use a very cool Weechat plugin called, WeeSlack that integrates with WeeChat and gives you the same great benefits that Bitlbee does with Twitter. WeeChat is turned into a full blown Slack client with logging.

Conclusion

With this setup I have a perpetual feedback loop that stores everything locally for referencing when ever you need to and with the content in plain text files you can query and extract it however you want.

The Necessity of Security Standards

Posted on by jra

Having been working in the Information Security industry for almost two decades, I’ve seen what has and has not worked well for organizations approach to Security. One of the biggest pitfalls I’ve seen is a type of insanity in repeating the same mantras over and over again to supporting groups and stakeholders and then wondering why this incessant repetition keeps returning full circle. Guidance that is provided tends to be slightly different each iteration enough to make each case sound like it’s unique, but it isn’t.  

One project manager approaches someone on the security team and asks, “Hey, our vendor says they can only support DES encryption, is that OK?” Few hours later another PM from a different project approaches a different security team member and asks, “What encryption algorithms does our vendor need to use?” To which the security analyst replies, “We cannot use anything weaker than AES-128.” In this short, but all too common scenario we have two distinct answers to the same question one of which could have serious repercussions in that DES has been broken since 1976!

This is where the need for adopting organizationally sanctioned security standards come into play. The the earlier could have been solved by having an established Cryptography standard that would mandate the approved encryption algorithms to be used in the organization. Thus, when Larry the project manager swings by the Information Security area to ask what are acceptable encryption algorithms you just point them to the Cryptography security standard that documents those requirements. When Joe the other project manager stops by asking the same question for a different project the same guidance is given and then you have a consistent standard from which the entire organization works from. 

Over the years I’ve found that there is a minimal list of security domains that you should have security standards for to formalize security standards across the organization:

  • Access Control 
  • Asset Inventory
  • Authentication
  • Cryptography
  • Certificate Management
  • Data Protection 
  • Incident Management
  • Logging
  • Malicious Software
  • Monitoring
  • Network
  • Operating System – You should have a standard for each OS deployed. 
  • Remote Access
  • Virtualization
  • Vulnerability Management

Your mileage will vary depending upon the organization your working for and how they are leveraging the security domains outlined, but the important first step is getting them drafted and ensuring senior management supports not only their content, but their enforcement across the organization or they will end up becoming suggestions instead of requirements. Security standards are just one component of the overall Information Security ecosystem; you still need to have security policies to drive them and security architectures to ensure they are being adhered to. 

Cybersecurity Podcasts

Posted on by jra

I was recently asked to give recommendations for Cybersecurity Podcasts to students in college that are majoring in Security. The usual problem with security podcasts (and podcasts in general) is that they frequently become static and in some cases a year or more goes by before they are updated.

There are actually a large number more of Cybersecurity related podcasts than what I have listed here, but these should keep your mind update enough without getting overloaded.

Here are some of the main ones that I know that are kept up to date.

Threatpost Security Podcast

Breaking Security Podcast

White Rabbit Podcast

Security Weekly

Defensive Security Podcast

OWasp 24/7 Podcast

Risky Business Podcast