Skip to main content

Security Brute Squad

Search This Blog

ONTAP 9.4 Security Podcast

on May 25, 2018

Get link
Facebook
X
Pinterest
Email
Other Apps

GDPR, the dark web, and the "mafia".

All this week on the TechONTAP podcast.

Get link
Facebook
X
Pinterest
Email
Other Apps

Comments

Post a Comment

Popular Posts

Blackhat 2017 Day 1 – The Keynote

Day one begins with the keynote speech. The night before there were a multitude of parties and luckily through my coworkers I was able to attend one thrown by Kaspersky (which I pronounced Kaspery and that confused them quite a bit). I’m a guy that gets “hangry” and the breakfast provided by the conference was muffins and a mixed berry parfait. Oh, what would I give for an egg, cheese, and some sort of meat biscuit. The keynote speaker is Alex Stamos, CSO for Facebook. I bet you he’s gotten as many Full House references as I have gotten Last of the Mohicans. The key note was in the Mandalay Bay Arena, which I had never been in before. The arena looks like a mid-sized college basketball stadium. At the time I wondered how this compared to the event (Insight) NetApp puts on in the Mandalay Bay conference center as well. Blackhat is bigger. The founder of Blackhat took the stage and framed the problem of “S...

FIPS 140-2: What You Need to Know

I get asked a lot whether our product is FIPS 140-2 certified. FIPS 140-2 isn't magic. And typically, an entire product isn't FIPS 140-2 certified. A component within a product is FIPS 140-2 validated. What Should I Be Asking About FIPS 140-2? The better question: what within the product is FIPS 140-2 validated and what it is used for? Make sure you’re not playing knifey spoony . Know what you’re getting. Plenty of vendors support a FIPS 140-2 validated module for SSL – but that only handles certain types in-flight encryption. What data is actually encrypted with that FIPS module? What about any data-at-rest? Is that FIPS validated? As part of FIPS 140-2, a vendor needs to define the security boundary - what's actually included as part of the validation. The smaller the boundary, the easier it is to pass the validation. Vendors typically limit the boundary to a very finite set of functions. An...

How Do Self-Encrypting Drives Work?

SEDs Self-encrypting drives perform the encryption in hardware automatically. Each drive has its own encryption key that is used to encrypt the data. This key is called a data encryption key (DEK). The DEK is not accessible. There are ways to change the DEK, but not get the DEK. A SCSI write is sent to the drive (obviously with data) . The drive encrypts that data and stores it. When data is read via a SCSI read, the DEK decrypts the data, and plaintext leaves the drive. If you leave the drive in this as-is, your data is not protected. You can take the drive out of the system and plug it in somewhere else. While it's true that your data is encrypted, anyone can power up the drive and access the data. So ... what do these drives really do? While the DEK cannot be accessed, there's another "key" that lives outside drive called an Authentication Key (AK). The AK is used to protec...

Powered by Blogger