The foundational elements of security
Many people look at information security as a highly technical field and allow themselves to be distracted by technical jargon or complex attack tactics. Security is quite simple. Many of the concepts that apply to security have corollaries in the physical world. Throughout human history, people have been protecting assets of value. Knowing what you are trying to protect is the first step. The foundation of security is protecting people, information, and systems. While strategies, tactics, and technologies can be technical and confusing, the basic underlying principles are easy to understand. Albert Einstein once said, "If you can't explain something simply, you don't understand it well enough." I challenge all security leaders to learn to explain their strategies and tactics in simple terms. In order to do so, we need to go back to the basics.
People
There is a major misconception that information security is all about technology. Technology plays a role, but ultimately, every security breach starts with a person, and the vast majority of attackers launch their attack against an individual person as well. The real story of security is one of people attacking people and it is as old as humanity itself. From the beginning of time, as soon as one group of humans amassed something of value, it became necessary to protect it from other humans who would take it from them if they could. As we organized into tribes, societies, and ultimately nations, the concentration of wealth grew.
The internet has connected the world and changed it forever. For many centuries, access to knowledge was a source of wealth. In the modern world, anyone with an internet connection and a device can access any information they desire. This connectivity has offered great benefits to society and the global economy. However, with great power comes great responsibility. Since information can now move more freely than ever before and can be replicated across systems in microseconds, it can be stolen or otherwise exploited just as quickly. However, people don't adjust their habits as quickly as technology accelerates.
People are fallible by nature. Most exploits are delivered through the applications people are most familiar with and trusting of, such as email. Many attacks are designed to trick people into doing something they would not normally do. All these types of attacks are collectively known as social engineering. Social engineering is simply an attempt to convince someone to do something that is not in their interest for the benefit of the attacker. We will discuss social engineering types in detail in Chapter 5, Protecting against Common Attacks by Partnering with End Users.
Since people are often the weakest link and the last line of defense, educating and supporting people is the first pillar of an effective information security program. Additionally, looking for behavior patterns is an effective way to identify attacks early and mitigate their impact on a person or organization.
The unfortunate truth is not all security challenges related to people are accidental on the part of the trusted insider. There are three categories of human-based insider threats to an organization. First is the well-meaning employee, who accidentally puts information or systems at risk. This can be due to seeking the most expedient way to accomplish their job function, a failure to adhere to best practices, such as reusing passwords between personal and corporate accounts, or negligence in terms of their responsibilities in handling sensitive information. The second is the compromised account. This threat is based on an attacker gaining access to an employee's credentials in some way and using those credentials to masquerade as the employee. There are many ways accounts can be compromised, and if there is a program in place to identify signs of a compromised account early, there are effective ways to mitigate the risk. However, if an attacker can compromise an account and remain undetected, they can cause massive amounts of damage in a relatively short period of time. Finally, there are malicious insiders. These are people you have provided access to who intend to do harm to the organization. It is important to note that most insiders don't start as malicious; they become that way based on changing circumstances.
It is important to understand the categories of insider threats and respond to them appropriately. If you treat a malicious insider as a well-meaning employee, you will give them time and insight that will allow them to do more harm to the organization. If you treat a well-meaning employee like a malicious insider, you will alienate them at best. The objective should be to identify the type of insider you are dealing with and respond appropriately.
Information
The term information security indicates that the point is to protect information, but many programs inexplicably deprioritize the information-specific controls in their security programs. Many security practitioners have become enamored with technology and tactics and forget about what is most important. People is the first pillar of security because it is people who are attacking systems to steal information, and it is often people that are being exploited by attackers to get into the environment. Information is a close second, because that is the target and that is the valuable item the program should be trying to defend.
There is a well-known information security concept known as the Confidentiality, Integrity, and Availability (CIA) triad. Data breaches are attacks against the confidentiality of data. Although less common, attacks where someone is trying to modify a record, such as if you were to hack into your bank and lower your credit card balance, are an attack against integrity. Ransomware is an attack against availability. The key point to remember is what matters is the confidentiality, integrity, and availability of information. As a result, an effective program understands what information is important, where it resides, and how it should be protected.
With respect to understanding information and how it flows inside an organization, there are three aspects to consider. First is the content. What is the information we have that we should protect? How do we define it? What makes it sensitive? Second is the community. Who is authorized to interact with the information? Who should not interact with the information? Are those that are allowed to interact with the information allowed to share it with others? If so, whom? The third is the channel. When information is moving, how should it move? What are the authorized repositories for the information? Putting these three elements together allows you to understand the authorized behavior of information and the acceptable use of sensitive information by people in your organization. Once you have identified who in the organization will be handling sensitive information, you can support those people with additional training on what their responsibilities are and how that information should be handled and used. Since you have defined the authorized behavior of the information, you now can implement technologies to detect unauthorized movement of data and unauthorized interactions between information and people.
The other key element of information is understanding its life cycle. The first aspect is to understand how information comes into the environment. Is it created by our organization as is often the case with intellectual property? If so, who creates it and what is its journey from the idea stage through legal protection in the form of a patent or copyright? If it is a trade secret, protecting it becomes even more important because there are few internationally recognized legal protections for trade secrets. In other cases, such as PII, the organization does not create the information, rather it is entrusted with the information by a data subject or a customer. In that case, it is important for the organization to understand the mechanisms it uses to collect information. What are the ways a customer could provide their information to us? Do we have safeguards to ensure sensitive information isn't inadvertently provided through other channels? Once the customer provides their information to us, where do we store it? Storage is the second stage of the information life cycle.
Storage refers to where and how information is stored inside and even outside your environment. Some organizations outsource the storage and processing of information to third parties. This type of arrangement has become popular with credit card information, especially for smaller organizations that do not have the proper resources to comply with the rigors of the PCI-DSS. Other organizations use cloud storage offerings such as Software as a Service (SaaS) or Infrastructure as a Service (IaaS) platforms. While these solutions are often seen as an extension of the organization's environment, there is also a shared security model that must be understood by the organization, so it is clear what responsibilities they have and what responsibilities the service provider has in the arrangement. In every arrangement, controlling what information is stored in which location and who has access to that information is the responsibility of the organization. Those responsibilities cannot be transferred to the cloud provider. It is also likely that different security tools and controls will be necessary to secure cloud environments. Since the organization does not own the infrastructure, many of the traditional tools used to secure information on-premises will be impossible to deploy, ineffective, or both.
The third stage of the life cycle is transmission. Most information will be transmitted at some point throughout its life cycle internally, externally, or both. While sensitive information is in transit, it can be vulnerable as not all transmission methods are created equally in terms of security. It is important that individuals and organizations understand the risk posed with each transmission method against the need for efficiency of the transmission. Generally, more secure transmission methods are more onerous for the users involved in the transmission. For example, sending an email with an attachment is very expedient, but it isn't the most secure transmission method. This is likely acceptable for most email exchanges containing commodity information. If the information should be protected but the communication is still necessary, such as when my doctor's office sends me health information, a secure message is likely an acceptable solution. This requires me to log in to view the encrypted message and is more secure than a traditional email. When more sensitive information is being shared, a secure share with multifactor authentication is likely more appropriate. This method will require the recipient to take multiple steps to access the information but will be a much more secure transmission method. These are just a few examples. There are countless methods of transmission to choose from. Choosing the right transmission method requires an analysis of the sensitivity of the information, the need for expediency and a seamless end user experience, and the frequency of transmission. It is important that a thoughtful analysis is conducted and methods are selected for each sensitive information type. By being intentional about authorized transmission methods, the organization can put more meaningful controls in place to identify deviations from acceptable practices.
The final stage of the information life cycle is data destruction. At some point, retention requirements only stipulated a minimum amount of time information should be retained. As a result, most organizations simply didn't delete anything. This led to a scenario where over-retention was often the largest source of residual information risk in an organization. Europe's GDPR seeks to put maximum limits on data retention. GDPR states that data subject information must only be retained if it provides business value, consent to the information is not withdrawn by the data subject, or retention is required by law. GDPR stipulates that organizations destroy data that no longer has business value. As a result, organizations must plan when they collect PII from European citizens why they need the data, how long they need it, and how it will be destroyed when it no longer has business value. While this regulation is only required by GDPR for European citizens' PII, it is in the organization's best interest to apply this discipline throughout their information protection program.
Systems
The ability to secure systems has been impacted significantly by the rapid adoption of cloud-based technologies. Systems security falls into three major categories: securing on-premises workloads, securing cloud workloads, and securing endpoints. Each of these categories poses its own challenges based on the access and responsibility of the organization to provide security. Each category also has specific technology solutions designed to help an organization fulfill its responsibilities given the level of control it has over each environment.
Example Case: Citibank and Lennon Ray Brown
Lennon Ray Brown was a trusted Citibank employee who had privileged access to Citibank systems. In December 2013, Mr. Brown had a discussion with his supervisor about his performance. Reports vary with respect to whether the discussion was a scheduled performance review or simply a discussion about Mr. Brown's performance at Citibank. Regardless, Mr. Brown did not like the conversation. In response, "Brown caused the transmission of a program, information, code and command, causing damage without authorization to a protected computer." (Department of Justice–Northern District of Texas, 2016) Mr. Brown had knowledge of the network and completed his actions with malicious intent.
"Brown knowingly transmitted a code and command to 10 core Citibank Global Control Center routers, and by transmitting that code, erased the running configuration files in nine of the routers, resulting in a loss of connectivity to approximately 90% of all Citibank networks across North America." (Department of Justice–Northern District of Texas, 2016) After he took down most of the Citibank network, Mr. Brown went home. It is not immediately clear why the last router did not go down, taking the entire network down with it, but Mr. Brown's intention was to damage the systems he had access to.
Ultimately, Lennon Ray Brown was sentenced to 21 months in prison and ordered to pay restitution of $77,000. Mr. Brown did not make good choices, but the case highlights the fact that any trusted insider could become malicious based on circumstances that may not be foreseen. It is important to apply the concept of least privilege and the separation of duties to ensure a single rogue employee cannot cause catastrophic damage. Monitoring privileged employees is also important. Monitoring employees may not prevent them from doing something damaging but may dissuade them from doing so knowing they will be held accountable if they do. As the saying goes, good fences make good neighbors. To be clear, there is no evidence Citibank did anything wrong in this case. The fact that a case was made and justice was served indicates that Citibank had the proper monitoring of privileged users in place. However, the key lesson is you cannot always anticipate where an insider threat may come from. If Citibank thought Lennon Ray Brown was likely to do something like this, they would have never hired him. Malicious insiders don't often start out malicious, they become that way.
This case also highlights the fact that insider threats don't always leave an organization with data. Many common perceptions revolve around the theft of intellectual property, as was highlighted in the Uber versus Waymo example case. However, sometimes malicious insiders target systems and intend to cause damage to avenge a perceived slight, rather than targeting privileged information for personal or financial gain.
Protecting systems is very important. Most organizations put protections in place to prevent intrusions from outside the organization. The preceding example case highlights the additional challenges posed by insider threats. When protecting systems, there are two major categories of systems that need to be protected, on-premises workloads and cloud workloads.
Securing on-premises workloads
On-premises workloads are easier to secure than their cloud counterparts because all aspects of securing them are well understood by the security team. Also, the workloads are under the full control of the organization. From physical security to network security and through the application stack, solutions and best practices for security exist.
The traditional on-premises layered security approach starts at the perimeter and flows through the network, endpoints under the control of the organization, applications, and ultimately to critical information. This approach is antiquated for most modern organizations. For most practitioners who are familiar with the recent changes in the IT reference architecture for organizations, a major challenge is immediately apparent. Organizations no longer own their perimeter since there is no meaningful perimeter between on-premises workloads and cloud-based workloads. Organizations also no longer own their networks since remote work was beginning to be normalized before the COVID-19 pandemic in 2020 but has now become the standard mode of operation. While some companies may have staff return to the office full time after the pandemic is over, many will continue to provide flexible work arrangements, remote work arrangements, and hybrid work models to their employees.
As a result, it should be assumed that any controls dependent on a user being connected to the corporate network are partially effective at best. Also, with the rise of easily accessible SaaS solutions, most organizations allow access to workloads from employees' personal devices, either explicitly or by default because they lack the ability to stop employees from logging in from non-corporate devices. While Cloud Access Security Broker (CASB) solutions offer controls to only allow connections from corporate devices with up-to-date security software and settings that comply with the corporate endpoint security posture standards, most organizations have not deployed that level of control.
Additionally, applications are no longer exclusively on-premises and neither is information. This means that this entire model, while useful for building the on-premises portion of an information security program, is no longer a comprehensive framework for information security. In the modern world, cloud security must also be considered as part of systems security, and congruent capabilities for both should be deployed so people, information, and systems are protected comprehensively regardless of the source location or destination location of the connection.
In addition to the layers in the traditional model, much of the traditional monitoring and response capabilities have been focused on on-premises workloads. Both System Incident and Event Management (SIEM) technology solutions and Security Orchestration, Automation, and Response (SOAR) technology solutions have been built on log aggregation. Both solutions are designed to aggregate information and, in some cases, allow organizations to take action across multiple technologies. Cloud-native solutions and Managed Detection and Response (MDR) capabilities are beginning to replace legacy on-premises systems, but many similar monitoring and response capabilities for cloud workloads remain delivered by disparate systems. Due to how different securing on-premises workloads is from securing cloud workloads, many organizations keep those disciplines separate. Doing so presents both efficiency and efficacy challenges to an organization. While it is necessary for tactics and technologies to differ across on-premises workloads and cloud workloads, the overarching capabilities and objectives should be congruent.
Securing cloud workloads
Many organizations struggle to properly secure cloud workloads because they lack a fundamental understanding of the shared security model. The shared security model shows what organizations are independently responsible for and what their cloud platform vendors are responsible for with respect to security. Understanding the shared security model requires a basic understanding of the basic flavors of cloud services.
SaaS includes thousands of offerings that allow applications to be consumed as a service, rather than deployed on servers. SaaS platforms were the first to be adopted and have the largest market share of any of the cloud platforms. Microsoft Office 365, Box.com, and the Customer Relationship Management (CRM) portion of Salesforce.com are popular examples of SaaS applications. In a SaaS environment, the vendor takes on most of the responsibility for security because the consumer has limited capabilities to secure their own SaaS environment.
IaaS includes a smaller number of offerings, the most well known of which are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). IaaS offerings offer many styles of computing power that can be rented monthly or provisioned in a way where you are billed for what you use, like an electricity utility. Since you are given significant control over this environment, you are responsible for far more of the security stack than you would be for a SaaS platform.
Platform as a Service (PaaS) confuses many people because it sits somewhere in between SaaS and IaaS. To further confuse the matter, most of the popular PaaS offerings are offered on platforms that also have SaaS or IaaS elements. For example, Salesforce is a SaaS offering, but the underlying Force.com platform is a PaaS offering that offers a suite of tools and capabilities to develop custom applications that can go far beyond CRM. Also, there is a marketplace where developers who have developed applications on the Force.com platform can sell their applications to other Salesforce customers as add-ons. Popular add-ons to Salesforce include commission tracking software, Sarbanes–Oxley (SOX) compliance software, and even ticketing systems. Also, AWS has several offerings that could be considered PaaS offerings. Their generic compute workloads, such as Elastic Compute Cloud (EC2), are clearly IaaS offerings, but offerings such as Lambda and Elastic Beanstalk, also offered by AWS, are clearly PaaS offerings.
Distinguishing PaaS from IaaS has significant security implications as will be demonstrated by the shared security model. What is the difference between PaaS and IaaS? IaaS provides underlying infrastructure and operating systems only, while PaaS also provides a development environment to allow developers to focus on coding and not on deploying and managing the software necessary to create the environment. It is the middleware between the operating system and the application that is being developed that distinguishes PaaS offerings.
Due to the differences in the models, it stands to reason that the provider would be responsible for different aspects of security in each. Conversely, the consumer of the services always has some responsibility as well. While awareness is growing, there was an early misconception in the wave of cloud computing adoption that when an organization moved to the cloud, security was solely the cloud provider's responsibility. Some elements of a security program, such as physical security and network security, become the cloud provider's responsibility in all cases. Some elements of security, such as governing access to the environment and securing the data inside the environment, are always the responsibility of the consumer. Gartner and others have published statistics that state most cloud data breaches are likely to be the customer's fault. This has been proven true. There are a few cases where cloud providers failed in their responsibilities, but many where the customer failed to meet theirs. Some of the failures are due to poorly deployed and configured controls. Others are due to a lack of understanding of who was responsible for each security layer. There are many versions of a shared security model that can be found, but the following is mine. Regardless of which model you refer to, it is important to understand your responsibilities:
Figure 1.1 – Shared security model for various cloud computing environments
In response to the growing adoption of cloud computing, security solutions have been developed to help customers meet their responsibilities. Traditional on-premises tools could not be deployed in a SaaS environment, for example, so new tools had to be developed and deployed. Since SaaS solutions were the first to be widely adopted, CASBs were developed to help customers meet their specific responsibilities in SaaS models. However, as many organizations embraced IaaS solutions, they tried to apply their CASB solutions to their IaaS environments. While CASB solutions will integrate with the Application Programming Interfaces (APIs) of popular IaaS environments, they were developed to help with information protection, data classification, and access control, the customer's responsibilities in the SaaS model. They were not developed to address application security, operating system configuration and patching, host security, or network security. As a result, many organizations have significant gaps in their security posture. In Chapter 6, Information Security for a Changing World, we will explore the cloud security landscape in detail and revisit the shared security model.
Next, let's move on to securing endpoints.
Securing endpoints
Securing end computing devices or endpoints is a part of security that has received significant attention and investment over the last decade. Originally, antivirus technology, such as McAfee and Symantec, would detect malicious software based on signatures. Essentially, when a new type of malicious software was identified, the team at McAfee or Symantec would build a profile of that malicious code and look for it on machines where the endpoint was installed. There are two major problems with this approach. First, there is a period of time between when a piece of malicious software is developed and a signature is created. Malicious software in this period is called a zero-day threat. Traditional approaches offer no protection against zero-day threats. Second, and a more common problem, was over the years, the number of different types of malicious software packages has grown to the extent where matching against an increasing number of signatures becomes inefficient, and the antivirus software was consuming an increasing percentage of the host resources, which were needed to perform the intended function of the device.
Starting in 2011, next-generation endpoint protection platforms began to emerge. These platforms, such as CrowdStrike, Carbon Black, and Cylance, deployed techniques such as machine learning, advanced response capabilities, and scanning for indicators of compromise rather than simply looking for virus signatures. These more feature-rich endpoint protection platforms have significantly increased the security of corporate endpoints when compared to their predecessors.
However, an increasing amount of information and workloads that belong to an organization is being accessed by endpoints they do not own or control. Bring Your Own Device (BYOD) has become popular for mobile devices in most organizations because cloud computing makes data accessible from anywhere and most employees don't want to carry a separate phone for personal and corporate use. While Mobile Device Management (MDM) solutions exist, they are not as feature rich as endpoint protection platforms, and they are not widely deployed to employees' personally owned devices. As a result, securing endpoints in the modern world has become a more difficult challenge.
