Cyber Security Basics: Protect your organization by applying the fundamentals (2016)

Section Zero: Introduction

“You can't build a great building on a weak foundation. You must have a solid foundation if you're going to have a strong superstructure.”

Gordon B. Hinckley

Introduction

One of the worst man-made disasters in history is the collapse of a coliseum in Fidenae, Italy in the year 27 A.D. This catastrophe resulted in the death of over 20,000 people. To prevent tragedies like this from ever occurring again, the Roman senate passed laws that mandated that all large stadiums be built on a “sound foundation.” This event provided the world with a valuable learning lesson that has influenced building construction ever since.[1]

A building with a solid foundation rarely falls down on its own. It can even prove itself resilient against significant attacks. The same goes for a security program that is built and reinforced using sound design principles and best practices. This book is intended as a guide for identifying and implementing solutions that support a solid information security program. This could be a program that does not yet exist, or one that is being improved (and there will always be room for improvement.) Security solutions and programs cannot be set in stone, which is one thing that separates the foundation of a security program from physical structures.

This book is not meant to be a comprehensive text on every aspect of information security. Instead, the goal is to cover the fundamentals. Organizations can establish a competent and effective information security program by focusing on best practices, which translate into specific security controls and processes to support them. The goal of this book is to help reduce the technical hurdles that sometimes prevent solutions from being implemented. This may be due to a lack of understanding or feeling overwhelmed by the myriad choices that are available. Too much complexity is a deterrent to security (a concept that is covered in more detail later in this section.) The objective is to clear some of the technical fog that often surrounds and impedes information security efforts from being successful.

For this book, an organization or entity can be defined as one of the following:

· A for-profit company

· A non-for-profit organization or foundation

· A federal or local government unit

· A library, hospital, or school

Just as the size and composition of an organization can vary, so can the makeup of the team responsible for maintaining the security of its information assets. The organization may be fortunate enough to have a dedicated InfoSec or cyber security team with an appropriate level of staffing. Or it may be just a single individual who performs these duties while juggling several other responsibilities. Regardless of the size of the team, the experience level of those on the team, or size or scope of the organization, this book will hopefully provide the fundamentals for building a new, or reinforcing an existing, information security foundation.

0.1 Building a Foundation

This book is intended to provide an InfoSec primer for those with a beginner to intermediate skill level in the field. Hopefully this book will also provide value to those who are experienced with the challenges of protecting an entity’s data, network, endpoints and employees from cyber-attacks. The goal is to demystify some of what may be considered to be the more complicated technical aspects of InfoSec, and to provide the fundamentals of a good information security program that can be executed by individuals of all skill and experience levels.

Ostensibly everyone at an organization is playing on the same team (not including the insider threat.) So there is no reason why security controls cannot be implemented in a way that is conducive and minimally disruptive to IT operations, while protecting against attacks that originate from both inside and outside of the organization.

0.2 Demystifying IT Security

By demystifying IT security, the chasm that separates security and non-security groups can be bridged so that everyone can work together to raise the security posture of the organization. Focusing on clear, easy to understand best practices can clear the fog that obscures many security concepts.

The contents of this book are broken up into the following three main sections of information security:

· Protect: Take steps to implement controls to prevent attacks and protect the organization.

· Detect: Implement sensors and monitoring solutions that alert appropriate personnel when certain security events or incidents take place.

· Respond: React to security events and incidents quickly and appropriately.

Technical details should not get in the way of practicing good security. Security does not need to be overly complicated. If best practices are followed, a majority of security weaknesses can be mitigated, and the majority of attacks we read about in the news almost every day could be prevented.

0.3 Using a Risk Based Approach

A risk-based approach may be the best way to provide some clarity. Focus first on the risks to the organization. Once you come up with a list of risks, this list can be prioritized according to severity, which helps identify what to focus on first. Some questions to ask during the risk gathering process include:

· What are the biggest threats?

· What does the organization value most?

· What kind of attack would be the most damaging to the organization?

By taking the time to answer these questions, you can focus the finite resources that are available on the highest priority items first. But remember: if everything is a priority then nothing is a priority. There is a concept called the defender’s dilemma. The gist of this term of art is that the defender has to protect all points of a system, yet an attacker only has to find one exploitable weakness to be successful. Since not all possible points of attack can be completely protected, risk management can help determine the most important points that need to be defended. Due to resource constraints, it is nearly impossible to fortify every aspect of an organization. Therefore, a more approach is to approximate and apply controls to areas where the most benefit can be gained. Another concept to be aware of is residual risk. When security controls are applied, risk is reduced. The risk that remains after applying these controls is the risk that is left over, or residual risk. You should continually work on reducing residual risk.

0.4 General Security Concepts

Each security decision that is made should address at least one of the following concepts in this section. If it doesn’t, challenge its value. Implementing a new control means making a change to the production environment, and any change runs the risk of breaking something that was working before, or of even increasing the attack surface. Changes should not be taken lightly. Any change that is made should maintain, if not improve, the security posture of an organization. Therefore, if you do decide to implement a security control, the net benefit of that change should be able to be mapped back to a core security concept.

Speaking of change for change’s sake, Security Theater is one of my favorite expressions. It basically means implementing a security control only for the sake of saying that a security control has been implemented. It’s just busy work, in other words, providing no actual improvement in security. Since changes of this type do not make the organization any safer, Security Theater is definitely something to avoid.

Changes also run the risk of increasing complexity to an organization. There is the rule that the more complex something is, the greater the chance that something will to go wrong with it. In a security context, complexity increases the chance of vulnerabilities and bugs that can be exploited. In addition to value, proposed changes should also be evaluated on the basis of the added complexity they bring. Changes that increase complexity should be considered carefully, as it can adversely impact the overall security of the organization.

The following can be considered the top 10 principles security professionals should follow, in no particular order.

0.4.1 Least Privilege

Objects can be protected by limiting access to them. Permissions, otherwise known as privileges or rights, can be assigned to objects. An object can be a protected resource like a document, a database, a system, etc. Restricting how a subject can interact with an object is an example ofhardening. Hardening is applying security best practices to an object to make it more resilient to attacks.

Access permissions can be enforced and managed by an access control solution. By following the principle of least privilege, permissions are explicitly defined based on the rights that a subject needs. Permissions assigned to objects do not exceed what is needed. Least privilege is also known as “need to know.”

To effectively manage access for all subjects and objects, a ticket system can be utilized so that permission changes get the appropriate approvals and are documented. Ideally, access is tied to Human Resources so that permissions are based on the role of the employee, and that those same permissions are revoked if that employee separates from the organization.

A permissions snowball is a phenomenon where the amount of access someone has directly reflects of the amount of time he or she has been with the organization. Privileges are continually granted to the user as that person changes roles, but they are never revoked. This is due to poor access management processes. Effective access management can help ensure that users only have the permissions needed to perform the job, and no more. When someone changes roles, access rights for the previous role should be revoked, and the rights needed for the new role should be granted.

0.4.2 Separation of Duties

To protect against the insider threat, permissions should be designed such that there is no single individual with access to everything. Excessive privileges can give individuals of questionable morals the opportunity to commit end-to-end fraud. The protection against this is to create logical barriers between systems and functionality in the form of a secure permissions design.

Separation of duties is similar to the principle of least privilege, except the separation of duties is more focused on distributing permissions among more than one individual. For example, let’s look at the IT systems of an insurance company. To reduce the chance of fraud being committed by an employee, separation of duties should be used to prevent the same person from being able to both create a new insurance policy, and then file a claim against that policy. If one person were able to do both of these actions, insurance fraud could be the result.

When designing a new system, or hardening an existing one, analysis should be done to determine what permissions subjects should have on objects. This analysis should include playing out different negative scenarios where insider fraud can be committed. These scenarios can then be used to identify permissions, access controls, and the roles individuals will serve. Once the controls that have been identified are implemented, the chance of insider fraud can be greatly reduced.

0.4.3 Confidentiality

Even in the world of social networks and general acceptance that “privacy is dead”, there is still some data that needs to remain confidential. This need could be driven by regulatory or legal requirements, as well as to prevent costly data breaches. Ensuring the confidentiality of sensitive data means limiting access to these data assets to only authorized individuals.

The following steps are part of a process that can be used to identify data that should be treated as confidential:

· Identify all of the data that the organization uses and retains. The result of this exercise should be a data inventory or data dictionary.

· Understand what regulations and legal requirements the organization needs to adhere to. These requirements should include how confidential data should be defined. There may also be an organizational policy regarding data and data retention. If so, these policies should also be consulted to determine how to correctly define confidential data.

· Review the organization’s data inventory (e.g. customer name, mailing address, etc.) and assign a confidentiality label to each data item. The labeling should follow the confidentiality labels recommended by relevant regulations and policies.

Take the time to identify all the data that will be transmitted and stored. All data that is used by production networks and systems should be covered. To be thorough, though, include development and test environments as well. A data classification exercise is worth the effort. By identifying the confidentiality requirements of data, the appropriate controls, processes, and architectural design can be implemented. A solution such as encryption for data in transit and at rest is one of the best ways to ensure that this security principle is followed. Encryption by itself is not a solution however; it also needs to be implemented properly.

0.4.4 Integrity

Maintaining the integrity of data, systems and software means ensuring that those objects have not been subjected to unauthorized changes. These can be changes that are done either intentionally or accidentally.

System files are an excellent example of objects whose integrity is critical to protect. Changes to these files could be the result of actions performed by an adversary in the form of malware that has infected a system. These integrity checks can be performed by an agent installed on a device, by the operating system (OS), or by the low level BIOS that underlies and supports it all. As integrity controls may be available in different areas of a device, be familiar of the options available to help make the right decision about how best to prevent unauthorized changes from being made on critical files.

Documents and databases can also have integrity requirements. There are some files that should never be changed once they are created, such as log files. Using integrity checks on log files will let the appropriate teams know if modifications have been made or attempted. Detection of a user or process making changes to a log file could lead to the discovery of a malicious actor trying to cover his or her tracks.

0.4.5 Keep it Simple

Complexity is bad for security. They say the devil is in the details, and indeed it is in the obscure, less-understood dark corners of code and networks that opportunity presents itself to attackers. The more complicated something is (such as application code, network design, or firewall rules), the greater the chance there is something wrong with it. These flaws could be security vulnerabilities.

The Keep it Simple, Sir (KISS) approach should be used whenever possible when implementing IT and security-related solutions. This principle is also known as economy of mechanism.[2] Less complexity results in software and systems that are easier to use and support. It also makes it easier to find vulnerabilities and fix them. And when problems do arise, a less-complex system will be easier to troubleshoot to find the root cause.

Information systems and security are complicated enough. When deciding which solutions to use, and how they should implemented, the KISS principle should be kept in mind. If a proposed change seems to introduce more complexity but not much value, it should be reconsidered.

0.4.6 Logging

Logging is the recording of activities performed by individuals and IT assets. For each event that is logged, the following table lists the properties that should, at a minimum, be recorded.