I spend a minute and look at US security specification. So, the National Institute of Standards there at nist.gov, so wealth of information. There are two sections or types of specifications that NIST publishes. One of them is called Federal Information Processing Standard or FIPS, and the other one are Special Publications, SP800s and there's a whole bunch of SP800s and we're going to go look at them here right now. Go to that page. So, this is the Cybersecurity Research Center at NIST. There's a ton of information here. But if you look over on the left side, there are these FIPS publications and these Special Publication 800s. So, if you click into FIPS, you can see the FIPS specification. Make this a little bigger. So, you want to know how to do SHA 3. Go download FIPS 202, and you want keyed hash message authentication code and HMAC function, FIPS 198-1, AES. Standard downloaded here, tell you exactly how to implement it and so forth. So, there are just a handful of these FIPS ones. So, only go look at the special publications. You'll see there's a huge number of them. So, way down here, these are, the oldest ones are at the bottom. When storage manufacturers started building in, I'll get there eventually, started building in random number generators. I talked a little bit about the challenges of building a true random number generator or random number generator that can produce a high amount of entropy per bit. They became aware that not all random number generators are created equally, and they broke these specifications 800-90A, 90B, and 90C, and these have to do with health tests that you need to build into your random number generator to ensure that the output generated by a random number generator is producing reasonable entropy. These were the last specification that I looked at. Since then, there were all of these other ones that they've published, special publications, all the way up to a recent one. I'll talk about that in a second, here at the top here, IS. So, SP 800-193 Platform Firmer Resiliency Guidelines, switch back to the presentation. The SP800-193 Platform Resiliency Guidelines protect against, this is the goal: Unauthorized changes. So, this would be loading robe firmware for instance into a device and running it or modifying the device in some way that the security is compromised. Supposed to prevent against the deter against unauthorized changes. Second, detecting unauthorized changes. The idea here that a system could detect if it was modified and take some type of corrective action. This is the real challenging when we've been scratching our heads over this outline. This notion of device, a secure device or secure system should be able to recover from attacks and I'm not sure exactly how to pull that off. Like I said, we've been scratching our heads whether that really mean in my day job. So, if you're interested, you can go out and read about that one. Microsoft has initiative as well. I'm certain other companies also do. There's a link to their cyber resilient platforms overview. Security is just a huge issue. I think you can see it now, with all the material that we've covered. There's techniques out there that we can deploy to try to make our system secure. It's important to have a response and incident response, and you don't want to have an incident. But if an incident happens, it's good to be prepared ahead of time to know what to tell your employees, customers, and the public. So, in summary, develop a security mindset, apply orthogonal thinking, always backup, coming out a problem from another angle especially during security reviews, how can the system be compromised, what are we taking for granted, what are our assumptions, and be clear about what you're trying to protect, your storage devices, disks, solid state or hard drives. In my experience, the threat vector or what we're trying to protect is data at rest. So, drive in a bay in a data center if a technician comes by and grabs that drive, yanks it out, puts it in his bag, and takes it home. When he fires it up, it's going to be locked out through a series of security means. So, that's what that term data at rest means. Are you trying to protect against information and communications? So, you want to use encryption if you're worried about authenticity and authentication and you want to use a keyed HMACs. If you're worried about integrity, you can use hashing functions and use the current algorithms that are thought to be secure at the time. So, if you're later 5-10 years from now, I'm sure someone will find a hole in something somewhere and it will be deemed no longer acceptable and they'll be some new shot hashing algorithm or there'll be a new AAS version that you're going to want to use. So, it's important to stay up with what the most current algorithms are. Again, address security at all levels in your application stack from hardware all the way up to your application code and all the interfaces into and out of the device, the board, the product, whatever it happens to be. Always authenticate your firmware, your software updates, and build this into your system from day one. Key management is the hard part but it's also where you get creative. I didn't talk a lot about being creative, but that is where you can apply some engineering thought and get creative about how you protect keys. Security's only ever good enough. It's never ever 100 percent. There's no 100 percent security. There just isn't. That's just a fact of life and it's a never ending game of cat-and-mouse between adversaries and the people that are trying to defeat adversaries and keep the adversaries out. For more in-depth learning, I strongly encourage you if you're not going to graduate in the spring, to take Eric Wustrow's course, Introduction to Computer Security. He's really good.
