The Necessity of Security Standards

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. 

Stop Referrering to TLS as SSL!

Having worked in the Information Security field for close to 20 years now, one of my biggest pet peeves is when Security professionals use technical terms that no longer comport to current realities. So as a word of warning this blog post is going to be a rant.

It is first important to understand some basic history around the progression of the protocol from SSL to TLS. As is the case with most security protocols each new version is created to address security defects in the previous version.

SSL/TLS Implementation Timeline – SSL First Introducted in 1993-1994 by Netscape – SSL 1.0 was never released due to serious security flaws – SSL 2.0 released in 1995 to address the security flaws found in SSL 1.0 – SSL 3.0 released in 1996 as a pretty much rewrite of the protocol to address defects found in SSL 2.0 – TLS 1.0 released in 1999 to address some “minor” issues identified in SSL 3.0 – TLS 1.1 released in 2006 to provide additional security enhancements – TLS 1.2 released in 2008 to provide enhancements around SHA-256 along with support of additional authenticated encryption ciphers.

SSL/TLS Vulnerability Timeline – 2011 – SSL 3.0 and TLS 1.0 found to be vulnerable to BEAST attack – 2014 – SSL 3.0 found to be vulnerable to the POODLE attack

As can be deduced from the above timelines, no one should be using “SSL” as defined in the RFC’s since 1999, but absolutly not since 2011 due to BEAST. Information Security professionals certainly should not be referring to TLS as SSL as I’ve observed time and time again over the last decade.

What is the big deal you may ask? Certainly everyone knows what you are talking about when you tell a client or a customer, “Just secure the HR website with SSL and you’ll be fine.”. Your client or customer then does a proverbial Google search and they find that anyone securing their site with SSL is without doubt a psychotic. They then call you and ask you why you would configure their highly sensitive HR website with a protocol that has been exploitable for the past 7+ years. To which you respond, “Oh no, we would never configure your site with SSL as the security best practice is to only enable it with TLS 1.1 or above.”.

You have know learned why terminology that reflects actual reality matters.

References

  1. Transport Layer Security(TLS)
  2. TLS/SSL Explained – Examples of a TLS Vulnerability and Attack, Final Part

Cybersecurity Podcasts

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

Building Metasploitable 3 on Ubuntu/Debian

Recently I attempted to build the new Rapid 7 Metasploitable 3 VM for use in my pentest lab on Ubuntu 16.10. Followed the instructions on their Github page to the letter, but failed in variety of areas. The good news is that I was able to hack my way through all them to get it built. This blog entry is going the steps you need to take to successfully build the VM on a Ubuntu/Debian based system. I’m assuming you may run into similar issues on a Fedora-type system, but your mileage may vary.

 

Packer

No issues with Packer, beyond just installing it with: sudo apt-get install packer

Vagrant

First you to need to install Vagrant: sudo apt-get install vagrant

Second, you before you can build the vagrant-reload plugin, you need to install the ruby-dev package with:

sudo apt-get install ruby-dev

Now you can install the plugin with: vagrant plugin install vagrant-reload

Due to the dependency upon WinRM and with the Vagrant version in the Ubuntu/Debian repo you will need to install:

vagrant plugin install winrm --plugin-version 1.8.1
vagrant plugin install winrm-fs

The 1.8.1 version is key in order for the build to complete successfully.

Metasploitable 3 Build Script

The Metasploitable 3 build script has some checks that fail due to the latest version of Virtualbox that’s in the Ubuntu/Debian repo. The main reason is they are checking for a specific version of Virtualbox and since with Ubuntu/Debian your running a newer version than what the build script requires, it fails.

Since we know we already have the necessary dependencies built, we can just run the build commands manually:

TMPDIR=/home/tmp packer build windows_2008_r2.json

The TMPDIR directive was another gotcha as I only had 1GB of space allocated to my /tmp filesystem and the process ran out of space. Point the TMPDIR variable to a path where you have enough space.

Now we can create the Vagrant box with:

vagrant box add windows_2008_r2_virtualbox.box --name metasploitable3

And then start it up with just: vagrant up and your good to go.

Happy Hacking!

Security Links for March 2016

SecureCode_product offering Here are some new security-related (for the most part ;) links from the month of March 2016

Bitcoin Wisdom – Trading-type Terminal for Bitcoin – https://bitcoinwisdom.com/

Zone Transfer Tutorial – https://digi.ninja/projects/zonetransferme.php

Debian Hardening Wiki – https://wiki.debian.org/Hardening

Standard Password Manager for UNIX – https://www.passwordstore.org/

Is your Browser safe against tracking? – https://panopticlick.eff.org

Have I been Pwned? – https://haveibeenpwned.com/

CryptoPals -Cool CTF for Crypto – http://cryptopals.com/

Nice Tool to Tell What CMS A Site is Running – https://whatcms.org/

A simple SSL/TLS proxy with mutual authentication for securing non-TLS services – https://github.com/square/ghostunnel

Find out if a site is down globally – http://www.downforeveryoneorjustme.com/

DNS Zone Transfer Tool – https://github.com/stryngs/axfr-tools

Nice Coding Guide for N00bs – http://download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

Ransomware seems to be popular these days. Here’s a site that tracks the variants – https://ransomwaretracker.abuse.ch/tracker/

Need I say more? – http://www.routerpwn.com/

Security Links for February 2016

SecureCode_product offeringMade a blunder on the droplet that runs this blog on Digital Ocean and lost the previous two security link blogs. Luckily had a backup from August that I was able to restore from. Anyways, here’s the security links for February 2016.

Application Security Learning Resources – https://github.com/paragonie/awesome-appsec#application-security-learning-resources

A Dead Simple TCP Intercepting Proxy Tool Set – https://www.praetorian.com/blog/trudy-a-dead-simple-tcp-intercepting-proxy-mitm-vm

Let’s Encrypt Audit – https://community.letsencrypt.org/t/independent-audits-of-lets-encrypt-finished/6518

Introducing the Keybase filesystem – Sounds like a sane approach to encrypting data at rest – https://keybase.io/docs/kbfs

Securely Hash Passwords – https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords

An Interesting Online Scanner – https://www.censys.io/

Another Attempt at Creating a Secure Linux Distro – https://www.parabola.nu/

An open-source network simulator/emulator hybrid (Tor & Bitcoin) – https://shadow.github.io/
For Encrypting/Decrypting Data on the Fly – https://encipher.it/

Red Team Field Manual – http://www.amazon.com/Rtfm-Red-Team-Field-Manual/dp/1494295504/ref=pd_bxgy_14_3?ie=UTF8&refRID=19V4X7X4WW7215V446N7

Decentralized DNS 
for Blockchain Applications – https://blockstack.org/

Github Bounty Program – https://bounty.github.com/index.html#open-bounties

Send An Urgent Message to a Friend When your in Trouble (i.e. Feds are knocking at your door) – http://www.snapmailemergency.com/

Get your cheap exploits here – http://cheapbugs.net/#home

Educating Youth for Cyber Security Careers

security-icon-01This past week I attended the Northeast Ohio Cyberconsortium conference sponsored by a number of entities in the Cleveland,Oh area. The goal of the conference was to stimulate a collaborative effort around building up and sharing information around Cyber Security as it relates to the North East Ohio area. One of the main talks was about the skills shortage in Information Security and what should be done to increase the talent pool. The proposition(they loved throwing this word around) offered was to build educational programs in the school systems around Cyber Security at as early of an age as possible. I think the NSA said that they get the gifted ones as early as 3rd grade and for security we should consider preschool.

The goal is an excellent ones, but the reductionist attitude offered presents a number of challenges. The one problem is that you simply cannot teach Information Security as an isolated discipline. There are a number of prerequisites that are necessary before you can even start to teach kids security. To name a few:

  • Computer Architecture – X86/X64/ARM
  • Operating Systems – UNIX/Windows/OSX/Android/IOS
  • Programming – Powershell/Python/Perl/Bash
  • Networking – TCP/IP, OSI, Ethernet, Wifi
  • These are all complex domains by themselves and then add on to that the various security principles that need to be applied and you can see it’s not as cut and dry as you may think.

    Then there are the ethical challenges in that to really understand how to secure things is you have to understand how to break things. This will no doubt create dilemmas with existing school policy and what the kids can currently do with school equipment.

    So I think what really needs to happen to make this achievable is a complete rewrite of existing educational plans. I think a structure more like college should be implemented where kids that are interested in a given domain like Cyber Security can elect to make it their ‘major’ and by doing so a specific roadmap would be produced for their educational career.

    The other thing to keep in mind is not all kids will be interested in such a field nor have an aptitude as you need to think about problems in a very detailed and logical way and not everyone’s brain is wired this way.

    Let’s Encrypt Talk @ Debconf15

    ssl1-150x150At this years Debconf15, a nice overview of the Let’s Encrypt project was given that you can view here. It’s a nice exposition as to the current broken state of CA’s and the projects plan to solve them. Let’s Encrypt is going to be making free certificates available in the next month or so.

    Will this be a game changer for commercial CA’s that make their profit off of selling certificates? Probably not in the short term and a large part of the answer will depend upon adoption and getting the Root & Issuing CA’s added to the trusted browser stores.

    Security Implementations & Scaling

    SecureCode_product offeringI have been doing Information Security for a decade and a half and there is a disturbing pattern that still to this day has not abated. That pattern involves more of a philosophy than the actual scaling you would need to for designing a security solution for an organization. The scaling law I’m talking about is one that is usually recognized too late in the implementation process, namely the post-production phase of a project.

    What I’m referring to is the amount of output you have to deal with that is a result of implementing a security solution without considering the resources necessary to manage and the resulting business process that need to accommodate this reality.

    One of the best use cases that demonstrates this phenomena is around the implementation of a Data Loss Prevention (DLP) solution for an enterprise. A typical DLP solution usually involves three main areas:

  • Data in Motion – Data that traverses the network
  • Data at Rest – Data that is stored on disk
  • Endpoint Data – Data that typically is read and written to removable media
  • You have a number of approaches you could take. The most reasonable would be to focus on one of the three areas that consider was vital and to scale the scope of the inspections to very specific set of criteria. Is this how most DLP deployments go? No, instead usually all three are turned on at the same time and there is no scaling back of the criteria.

    The result; more incidents and false-positives than fleas at the Westminster Canine convention. Once this scenario is encountered you end up scaling back your efforts and loss at least 3 months of progress. So do yourself a favor when implementing a security solution and understand what our outputs are before they are produced.

    Python Script for Searching ExploitDB

    biblical_apologetics_degree_wide

    So I was looking to cleanup my Twitter favorites list and starting with the oldest one that was dated from 2011, it was from an article for using a Python script for searching the local ExploitDB instance on Backtrack.So of course it peaked my interest and click on the source link directed me to a parked domain. Common problem with Open Source tools. After performing some Google-Fu, I found a copy and downloaded it to my Kali instance and of course it didn’t work as the path for the ExploitDB path has changed.

     

    So after a trivial change of pointing it to the correct path, bingo, it works.I have created a ‘Kali‘ repo on my Github if you want to grab it and I’m probably going to be making some updates to it over time.