As system administrators, we have complete access to confidential and sensitive data. In this video, you’ll learn about data privacy, application licenses, and regulations regarding personal information.
An important set of policies in your organization revolves around what you do when there is a security incident. If you’re the first responder, then you’re probably the one who identified the incident. You probably have log information. You may have seen the incident with your own eyes, or you may have gathered information based on monitoring data.
The first thing you should do would be to report this incident to the proper channels. And most organizations will have a set of policies and procedures on what to do each step along the way. If you’re there first, then this is a great opportunity to begin gathering detailed documentation. You can document what you found in your logs or your monitoring data, and then document anything else associated with the incident. The documentation you create will be used by many people in this investigation, so you want to be sure that it is available to everyone.
You want to gather as much information as possible, either through written notes or by taking pictures, especially pictures of a screen, so you can capture exactly what was seen during this incident. Many people will be contributing to this documentation, so you want to be sure that it’s in a place where many people can collaborate and add additional details to the documentation. Many organizations will have a collaboration tool or a wiki, so they can always add more details to the documentation that they’ve created.
An important part of collecting evidence in one of these security incidents is to make sure that nothing changes with that evidence. You don’t want anybody to be able to tamper any of the details, or change anything relating to the evidence. One good best practice is to always hash the information that you find, so that if somebody does change something in a file, you’ll be able to recognize it immediately. It’s very common to capture information, put it on to a read only type of media, and to use digital signatures to make sure that you know nothing has been tampered with any of that data.
There’s many different types of software licensing we use in our organizations. One of the most common is called closed source. This is the type of licensing you get from commercial products. Closed source means that you don’t have access to any of the source code used to create that application. The developer gives you an executable, and that’s what you run on your system.
With free and open source software, which is FOSS, the source code is publicly available. You can read through it and see everything relating to the code. Whenever you want to use that code, you can compile it yourself, and create your own executable based on that source code. The specifics on how that software can be used is documented in the end user license agreement, or the EULA.
Sometimes organizations will use DRM, or digital rights management, which uses technology to ensure that you’re following the terms of the end user license agreement. If you’re buying software for yourself or home use, you’re often purchasing a personal license. This is usually a single license associated with a single device.
And usually it’s a single user who’s taking advantage of that license. Usually you would purchase this type of license one time, and there are no additional ongoing costs. This is called a perpetual license.
In an enterprise or business, there are often many other options available for software licensing. Two common licensing schemes are a per seat license, where you’re paying a certain amount of money for everyone in your organization. Or it may be a site license, which is a single flat fee for your entire site. This normally allows the software to be installed everywhere it’s needed. But there are commonly ongoing annual maintenance costs associated with enterprise licensing.
There have been significant breaches of PII. One of the larger ones was in July 2015 with the US office of Personnel Management, where they compromised PII for many of the people with records in the personnel management office. The information that was compromised included the name, social security number, date of birth, job assignments, and more information for clients of the personnel management office. In total, there were over 21.5 million people whose personal information was compromised.
Another important privacy and security standard is the PCI DSS. This stands for the Payment Card Industry Data Security Standard. This is a standard for protecting credit card information and the transactions associated with those credit cards. This is a comprehensive standard, and it includes how to build and maintain a secure network and systems, how to protect cardholder data, how to maintain vulnerability management program, how to implement strong access control measures, regularly monitoring and testing the network, and how to maintain an information security policy.
Another important consideration for data privacy is associated with PHI, or Protected Health Information. These are the personal health care records of an individual, which includes your health status, any payments you’ve made for health care, and anything else related to your medical history. The standards associated with PHI have to be followed across all health care providers, so you know that your information will remain safe no matter where it happens to go. The regulations and standards associated with PHI are documented in the HIPAA regulations. This is the Health Insurance Portability and Accountability Act of 1996.
Organizations of all sizes need to have a set of standard guidelines that can help them understand how technology is to be used in that organization. These are your information technology policies. And if you’re trying to make decisions about what to do with IT in the future, you need to have a set of very strong policies that you can rely on. These policies are a bit different than information technology best practices.
Best practices would be set of standards which are commonly used in the industry, regardless of what your policies might be. For example, if you’re connected to the network, you need a firewall. If you have a wireless network, that data should be encrypted with WPA2. And if people have authentication, then they should be using strong passwords. It’s not necessary to create standards which include this information, since these would be considered best practices.