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.

CASB

• 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.

Components

• 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

Concepts

• 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