From the course: CSSLP Cert Prep: 1 Secure Software Concepts

Confidentiality

From the course: CSSLP Cert Prep: 1 Secure Software Concepts

Start my 1-month free trial

Confidentiality

- [Instructor] If you want a successful career as a certified secure software lifecycle professional, then you'll want to be clear on the goals of your application's security efforts. Securing applications is an important part of the process, but application security alone isn't the ultimate goal. What you're really trying to protect is the data that's processed, stored, and transmitted by those apps. One of the most common models for securing data is the CIA triad, named after each of the three components within that model, confidentiality, integrity, and availability. Let's start by taking a closer look at confidentiality. If you poke around online, you'll find a lot of wordy definitions for the term confidentiality. I prefer to keep things simple and at it's simplest, confidentiality is all about keeping secrets secret. Ultimately, there are people who are allowed to access certain data elements, while other people are not. Take credit card data for example. You're allowed to see your full 16 digit card number as well as the four digit code you use when purchasing items online. If someone else had access to your credit card data, that person could buy things for themselves and stick you with the bill. Keeping those secrets secret within the apps you're protecting, is key in protecting the people who are using your applications. But this data doesn't just live in one place, it's scattered all about and it's your job to track it down. That expectations of confidentiality extends to three types of data, based on where the data is at any given time. Data in use is actively being accessed by users, data they currently have open in the app. Data at rest is not currently being accessed, usually in either structured data stores, like databases, or unstructured data stores, like file servers. Data in motion is traveling between two points across some type of network, either wired, wireless, or mobile. One of the most common methods for ensuring the confidentiality of the data you're protecting is the encryption of that data. When encrypting data on a file system, you may choose to encrypt the entire disk. Alternately, you can choose to encrypt that data on a file by file basis, or you could even encrypt sensitive data elements within each file. Within a structured data store, you have similar options. You could choose to encrypt the entire database, or you could restrict your encryption to either a specific column or field within that database. When encrypting data in motion, SSL and TLS certificates are far and away the most common method for achieving this goal. You might hear both terms used interchangeably, but keep in mind that SSL is quickly being replaced by TLS. Virtual private networks, or VPNs, offer another layer of network encryption, creating a tunnel between two end points and encrypting everything that travels through that tunnel. These methods of protecting data are sometimes referred to as overt encryption channels. By overt, I mean that no one's trying to hide the fact that they're encrypting that data. If you want your users to know that their passwords are protected when they log in to your web app, then you want to make it crystal clear that your TLS certificate is in place. There are other sneakier methods of protecting data though, methods we refer to as covert encrypting channels. Take steganography for example. Did you know that you can hide sensitive data in the ones and zeros that make up image files? The same holds true for video and audio files. It still takes special knowledge and tools to find and extract this data, but this type of encryption isn't nearly as obvious as the HTTPS in the URL field. To an end user, an application might appear to be just a single web page, but you and I know better. That webpage is only the entry point into a much more complex architecture that consists of network devices and web servers, application servers, database servers, even security appliances. In order to understand where you need to implement your application's confidentiality controls, it really helps if you have a data flow diagram. A data flow diagram is different from a detailed network diagram and intentionally so. The purpose of a data flow diagram is to provide a conceptual image of how the application works, focusing on how sensitive data enters the app, where it goes once it's inside, and where that data ultimately ends up, often in a backup system of some sort. By tracking the data flow through your application and putting encryption controls where they'll be most effective, you'll be well on your way to protecting the confidentiality of the data within that application.

Contents