Friday, August 11, 2017

On being a great "Technical Trainer"

When people ask what I do for a living I usually boil it down to this: "I help people in IT do their jobs well." It's an odd career, and not one that can be found in a catalog at University. The technical trainers I have known have all started down a different career path and stumbled into this wonderful job and realized that it was their cup of tea.

I started down the road of becoming a high school science teacher, but when I couldn't land a teaching gig my first year out of college I had to look for something else. That's when I wandered into technical training and starting learning how to teach adults.

I can't claim to be a "great" technical trainer, but I have learned from many greats along the way. Here's a hint on how to teach adults well:

Think like a cook. 

Everyone knows that there are really just some basics in the way of food and water that are needed to survive. But you don't want to think like a survivalist, you want to think like a gourmet chef. How do I make this food unforgettable? You need the core component (for example, meat), the adjacent supports (for example, potatoes), and the spices (for example, salt and pepper).

So what are these things in training?

The Core Component: Know the subject that you are teaching. I know it seems obvious, but students can tell if you are skimming over the surface of something where you have no depth of knowledge. Become a confident expert! If I'm teaching about DNS servers, I need to really understand the moving parts of DNS, how it works (when it works) and how it breaks (when it breaks). What are the different flavors of servants and clients? How has it changed since 1983? So as an instructor you need to make sure you are prepared. This includes also ensuring that if you are going to demonstrate tools, you have the tool properly setup for your presentation. Students don't want to watch their instructor searching documentation mid-class. Be prepared!

The Adjacent Supports: Know the ancillaries to your subject. For example in the world of DNS, what does the security guy worry about with regard to DNS? How about the Active Directory administrator? How does DNS interface with other protocols like DHCP?

The Spices: Make your instruction "taste" good! This is where we really separate experts from expert trainers. Manage your classroom with confidence and create an atmosphere that is comfortable for learning (which means both asking and answering questions on the student's part). Provide motivation so students know why they need to learn something. Change up your presentation methods from lecture to jokes to demo to stories to Q&A. Ask for feedback, ask for clarification. Used both closed and open questions depending on what you are trying to teach.  Learn multiple analogies for different situations or to help a student understand. Draw recognizable pictures and write legibly on a whiteboard (physical or in software). Modulate your voice so that students can pick up on your meaning.

A few last cooking tips: If I order a multi-course meal I expect it to start with small plates that build up to the main course and finish with a dessert. Your teaching should do the same. Learn to organize the information that you present in such a way that it makes sense and builds on previous knowledge in incremental steps. Provide distinct breakpoints for the mental palate to be refreshed. And don't be afraid to ask for feedback. A good chef knows that the feedback from the customer is critical to keeping the restaurant open. As a trainer, you need to accept criticism and find the next thing to work on to make your next presentation even better.

Thursday, August 10, 2017

Do I need a Cloud Access Security Broker (CASB)? What does it do?

When it comes to security in IT, you just aren't allowed to blink. A few years ago no one had heard of a CASB. Look at the latest Security+ exam objectives and it's only a line item in the glossary. But today businesses are waking up to the reality that a CASB is critical to their security design, and if the vendors are to be believed, it's a matter of when, not if, a CASB is rolled into the security infrastructure.

Let's break up the acronym to see why.


  • Cloud - OK, so cloud technologies are ubiquitous these days. Maybe you deal in the heavy stuff - custom content written to Amazon Web Services (AWS), Microsoft Azure, or Google Cloud platform. Maybe you consume prebuilt high profile cloud apps like Google Drive, Office 365, Rackspace, NetSuite, Meraki... the list goes on and on, right? And what was an exception may not yet be the rule, but it is business as usual.
  • Access Security - What's the concern with the cloud? Time and time again it is the consumer's question - where is my data? Is it safe? When you relinquish absolute control over the data management you then have to start trusting your provider. Which would be great if it weren't for the fact that we know there are so many black hats out there constantly looking for vulnerabilities and opportunities. It's hard enough to keep your own environment locked down correctly. Are you going to have to pay attention to every cloud proprietor you do business with as well?
  • Broker - So this is where we introduce a middle-man (not to be confused with a man-in-the-middle attack!) - the CASB.  The CASB will be a drop point to lock down the cloud services that YOU need to track. It will give you the access security means to detect and enforce policies regarding acceptable Cloud technology use. 

The job of the CASB then is to allow the IT department to say "Yes" to various cloud technologies without having to worry about sensitive data leakage into untrusted environments. This can mean protection in the form of real time monitoring of traffic to provide Data Loss Prevention (DLP) and/or encryption of sensitive files. It also means that a single sign on through the CASB to access cloud services that don't support SSO themselves. THAT in turn can grant you tools for access control based on your own internal user accounts, which can be disabled and easily audited. In other words - Booya! You're in control again.

Majorbacon's quick hitlist of the Comptia Security+ PKI Terms

Public Key Infrastructure has a lot of terms and acronyms that get thrown around. Here is a rundown on some of the most common terms to know and love.


  • PKI: A PKI can be described as a set of technologies, procedures and policies for propagating trust from where it initially exists to where it is needed for authentication in online environments. 
  • CA: A Certificate authority hands out certificates to consumers to provide a central point of trusted authenticity
  • Intermediate CA: A CA that receives its authority from a Root CA and then provides certs of authority to an issuing CA
  • CRL: Certificate Revocation List – the list of certificates that should no longer be accepted because they have been revoked before expiration, usually because a system is no longer in service or the certificate has been compromised. These lists can be published over HTTP or other protocols
  • OCSP – Online Certificate Status Protocol – an alternative to downloading the entire CRL, a protocol to validate a particular certificate from the client using HTTP (usually)
  • CSR – A Certificate Signing Request is sent to apply for a cert around a particular key
  • Certificate – A file used to provide validation of public keys. They indicate when not to use these keys because of expiration, location, and use type. They are digitally signed by the issuing CA, with signature links up to the Root CA. Clients will use the public key once they have validated the CA signature is trusted and the key is in a trusted context.
  • Public key – Freely disseminated key sent with certificates and used to Encrypt data and Validate signatures of a matching private key
  • Private key – Closely held key used to Sign and Decrypt content encrypted with a matching public key
  • Object identifiers (OID) – a value attached to a certificate at creation that can be used in conjunction with policies to determine client behavior. An organization obtains a root OID and then creates sub OIDs


  • Online vs. offline CA – Issuing CAs need to respond to requests and should be online. Root CAs in a hierarchy are rarely needed (just to create or renew subordinate CAs) and are more defensible if taken offline.
  • Stapling – OCSP Stapling – instead of having the client perform the OCSP request the Cert Presenter delivers the time stamped OCSP response signed by the CA
  • Pinning – Pre-associating a host in development or on first contact. Cert or Public Key
  • Trust model – Types of trust methodologies: PGP, Single and Multiple Hierarchic PKIs, Discressionary Direct Trust, DNSSEC
  • Key escrow – The idea of a recovery agent – that a third party could decrypt data if needed. 
  • Certificate chaining – Root-Intermediate-Issuing CA-Issued Cert. Trust the Root, trust all the certs chained from it.

Types of certificates

  • Wildcard – uses the * - can refer to many domain names –useful for vanity URL type sites like SharePoint Apps
  • SAN – Subject Alternative Name – explicit list of trusted names, IP addresses, Exchange 2007 started using it
  • Code signing – Certificate’s Private key encrypts a hash of the code data 
  • Self-signed – cert without a PKI – used for many types of software’s initial installation – not trustworthy.
  • Machine/computer – Validate the computer, allows computer services to encrypt
  • Email – used for digitally signing email – hash of email is encrypted with private key
  • User – used to validate user credentials and/or encrypt users’s data
  • Root – used to provide authenticity at the top of cert chain
  • Domain validation – DNSSEC cert used to validate IP info
  • Extended validation – Validates that the site is operated by the LEGAL Entity

Certificate formats

  • DER: Single binary unencrypted binary copy of a PEM file the x.509 cert
  • PEM –ASCII Form of an issued certificate(s)  –begin-- encrypted binary copy of the x.509 cert
  • PFX – certificate with private key (possible protected) – PKCS#12 archive, possibly with chain
  • CER / CRT – Single unencrypted binary copy of the x.509 cert
  • P12 – Binary format for holding certificate AND private stores (aka PKCS#12)
  • P7B – ASCII Text format for holding only public certificate information