Security Concepts – CompTIA Network+ N10-009 – 4.1

In IT security there are a number of different topics to consider. And in this video, we’ll look at some of those security concepts. We’ll start with the categorization of data. If data is transferred across the network, we refer to that as data in transit. You’ll sometimes hear this referred to as data in-motion.

Any time you have information that’s being transferred over a wired or wireless network, you have data in transit. Most of the devices that we use in our network infrastructure are designed to get information from one place to another and not necessarily to protect that data. When you’re sending information through a switch, a router, or some other network device, its primary process is to forward that traffic to the next location.

The requirements for security would come from other devices, such as firewalls or intrusion prevention systems. These are systems that are designed to monitor the traffic, decide if traffic should be forwarded or blocked, and then look inside the traffic itself to make sure that none of that information is malicious. We might also include additional security to data in-motion through the use of encryption. Two very common encryption types are TLS, which is transport layer security, and IPsec, which is internet protocol security.

If you’re saving information to a hard drive, an SSD, or any other type of storage device, we refer to that data as data at rest. One common way of encrypting data at rest is to encrypt the information, as you write it, to the storage drive. This means that if someone gains access to that storage drive, they would have the encrypted files, but they would have no idea what that information actually is.

Some different types of data at rest encryption would include the entire disk using full disk encryption. You might encrypt just one single part of a database or an entire database of information, or you might encrypt individual files or folders in the file system of that operating system.

And in most cases, we’re applying different security policies to the data that we’re storing on these devices. For example, we might create access control lists, or ACLs, that would determine what users have access or no access to a particular type of data. This would allow the system administrator or the owner of the data to determine who has access to that information. These security controls are usually part of our operating system, and we can apply it to any data that might be at rest.

One of the challenges with security on any network is maintaining the control and management of all of the different encryption keys and certificates. We refer to the policies and the control of all of these different certificates as a public key infrastructure, or PKI. If you’re creating digital certificates, encryption keys, or any other type of digital security, then you’ll want to rely on the policies you configure as part of your PKI.

As you can imagine, a PKI is not a small part of your security infrastructure. There’s usually quite a bit of work that goes into the creation of a PKI, and there’s often changes and updates to that policy as time goes on. Many organizations will begin building out their public key infrastructure when they start adding encryption keys to web servers or signing public certificates to individual users or individual devices. The PKI then becomes a requirement for maintaining and managing all of these different security assets for the entire organization.

One challenge that many organizations have is applying a level of trust towards a user or a device. One way that they can assign this trust is through the use of a digital certificate. Digital certificates are often digitally signed by a central Certificate Authority, and that’s what adds the trust to these individual certificates that are then deployed to users or devices.

Instead of having a centralized Certificate Authority, some organizations will use a more distributed form of trust called a web of trust. With a web of trust, If A trusts B and B trusts C, then A can also trust C. This process of creating certificates, a Certificate Authority, and then providing digital signatures for those certificates is often built into central operating systems. For example, the certificate process is built into the Windows Domain services, but there are many third-party options that you can use for many different operating systems.

One of the more common ways to provide this trust in an organization is through the use of a Certificate Authority. This is a centralized authority that all certificates start from. This means that if anything is signed ultimately by this centralized authority, you can trust it anywhere in your organization.

Some organizations will build their own Certificate Authority within their organization, but other times they may use a third party as an independent authority. Whether the CA is a trusted internal resource, or it’s a trusted third-party resource, the CA is responsible for the trust that we have in all of the certificates that we create. And since the Certificate Authority is digitally signing all of these certificates, anyone can examine a certificate, see who signed the certificate, and then determine if that is a signature that they can therefore trust.

On the internet, it’s useful to have a third party provide trust. That way, anyone in the world can reference that certificate authority and know that there’s a trust associated with those digital certificates. But if all of your devices and users are within your own organization, you could create your own Certificate Authority.

This means your internal Certificate Authority will be self-signing all of the certificates that are created. This means you can get public, off-the-shelf software to build your own Certificate Authority, and then you can start signing your own certificates within your organization. And as long as all of the users in your organization can trust the CA, they can therefore trust any of the certificates created by that same CA.

When we store important data on our systems, we need to be sure that only the authorized users are able to access that data. This is something that is a common issue for all the types of data that we use across all of the different systems that we’re accessing that data from.

This is complicated by the fact that this data could reside anywhere. It could be on our local computer. It could be on a central web server, or it could be stored in the Cloud. This data might also need to be accessed by many different individuals that have different rights and permissions to that data. Some of this data may need to be accessed by customers or contractors, or you may need internal users to gain access to that data. We also need to be sure that we have controls in place to prevent any unauthorized users from gaining access to that data.

The process of managing the permissions and access to that data is referred to as IAM, or identity and access management. This involves creating an access control to that data to ensure that only users access the information that they really need to perform their job. We need to be sure we have proper authentication in place so that we can verify that that’s the user accessing the data.

And we need to be sure that we provide authorization for the data once those users gain access to the network. And of course, there needs to be a way to track and monitor access to the data so that we’re able to audit and understand exactly who accessed that information at any particular time.

An important characteristic of identity and access management is the concept of least privilege. Least privilege is the concept that a user will only have the rights and permissions that are necessary to access the information they need to perform their job function, and no additional access would be granted.

This is one of the reasons that we don’t assign administrator access to every system that’s on the network. We need to be sure that we are limiting how much access a user might have to an application or to data. And we need to be sure that the applications that we’re using have just the right access for that particular job function.

If you give users too much access to data, for example, give everyone administrator access, then everyone would be able to access any type of data at any time and be able to control it in any way they would like. That would obviously be a significant security concern, and it’s one of the reasons that least privilege is an important concept in identity and access management. One way to provide this least privilege is through the process of a role-based access control.

Most organizations will separate individuals into separate roles. You might have a shipping and receiving department. There might be a manager of that shipping and receiving department, and there might be a vice president that manages not only shipping and receiving, but also the accounting department. Each one of those users has a particular role within the organization, and their rights and permissions will be different depending on their role.

With role-based access control, the administrator of the network determines what type of role an individual might have and what permissions might be associated with that individual role. The administrator would then assign users to each of those role definitions.

So there might be a shipping and receiving role for the people performing those functions. There might be a manager role for shipping and receiving. And there might be a vice president role that handles many different aspects of the data across the entire organization. In Windows, we provide this role-based access control through the use of groups. We would create a separate group for each one of those different roles, and then we would assign users to those windows groups.

Another way to limit access to data is through the use of a geographic restriction. This means that we would identify where a user happens to be, and then we can assign different rights and permissions based on where they may be located. This can sometimes be done with an IP address.

If somebody is connecting over a VPN, they might be assigned an internal IP address, and we might provide them with the rights and permissions that are expected for someone that’s connected to our local network. But if they’re connecting from a different state or different country, we might want to change the type of permissions that user might have.

IP addresses are not always the most accurate, so there might be other ways to determine a geographic location for a user. For example, we can use GPS, or the Global Positioning System, to determine where a person might be in the world. If GPS is not available, we might want to use the name of the wireless network where someone’s located. And often, we can determine the location of the access point to determine where the user might be.

Once we know a user’s location, we can then start assigning rights and permissions to where that user may be located. We refer to this as Geofencing. Geofencing takes into account where a user might be and then allows or disallows access to information based on a physical location. For example, certain data within the organization might be very sensitive, and you may only be able to view that information if you happen to be located in the corporate headquarters building itself. If you’re outside of the building, you may not have access to that data.

Many organizations will supplement their physical security through the use of cameras. Sometimes we refer to this as CCTV, for closed circuit television. This is a very common security technology and one that is implemented in nearly every organization. Some of the more modern cameras can not only provide motion detection, so you know if anyone happens to be in a particular area, but they might also be able to read license tags or be able to identify a user based on facial recognition.

Usually, there are many different cameras deployed in locations around a building or a campus, and all of those cameras are networked back to one central point where they can store this information over a long period of time. This allows the administrator to go back in time and view every video feed that may have captured information during a particular time frame.

And if we’re talking about physical security, we’re also going to talk about door locks. A conventional lock uses a physical key to be able to gain access, and it may include additional security through the use of a deadbolt. Larger environments might have electronic readers where you would put in a personal identification code to gain access to a door. Or there might be a token-based access, such as the RFID badge associated with this electronic reader.

Or we might not use the badge at all and instead focus on characteristics of a person such as a hand print, a fingerprint or a retina scan. And in some cases, we combine these together to create multiple factors of authentication. So you might use a badge to be able to badge in, but then also include a personal identification number that someone would not have if they simply found your badge lying on the ground.