“Reasonable security” has been a requirement set by regulations such as the California Consumer Privacy Act (CCPA) and California’s AB 1950. Failure to meet the requirement could be the basis of a common tort legal cause of action called “negligence.” A “cause of action” is a reason you can sue someone, and a tort is a wrong that allows an injured party to seek relief from a court in a civil suit.
To sue someone for negligence, you have to usually prove four elements:
- The defendant had a duty to the plaintiff
- The defendant breached the duty
- The breach of defendant’s duty was the cause of plaintiff’s harm
- The harm to the plaintiff resulted in articulable damages.
When someone gives a company sensitive data, that company has a duty to protect and handle that data responsibility. How can security management tell if their company is properly safeguarding that data from a legal and regulatory perspective?
Courts have to assess your actions against a standard to determine if those actions were “reasonable.” Reasonable actions are usually based on an objective standard of how a reasonably prudent person in the same or similar circumstances would behave.
Reasonable behavior could also be defined based on knowledge of threats to the company or industry and what is being protected. In Patco Construction Co. v. People’s United Bank, a Federal Appeals court found People’s United Bank’s security procedures commercially unreasonable because the security controls implemented were inadequate in light of the bank’s knowledge of ongoing fraud (keyloggers) and protections against that type of fraud (security questions but no activity-based monitoring).
The table below (from Federal Trade Commission v. Wyndham Worldwide Corporation, US Court of Appeals for the Third Circuit) shows examples of commercially “unreasonable” security from two noted breaches: the Card System Solutions (CSS) breach from 2005 and the Wyndham breaches that occurred between 2008 and 2010.
How “reasonable” is used as a security metric
“Reasonable” is used as a measuring stick when determining if a party’s behavior was a breach of a duty. If you did not act as a “reasonable” person, then you breached your duty. In the Patco case above, security alerts (high risk scores on transactions) were being gathered but were not being used to stop fraud. Patco had the security tools implemented, but no one was at the wheel evaluating the alerts. This failure constituted a breach of the company’s duty to the individuals whose data they were storing.
Another important distinction is that there are professional standards of care. California Civil Jury Instructions (CACI) number 600, for example, defines the professional standard of care as determined by a jury:
“[A/An] [insert type of professional] is negligent if [he/she] fails to use the skill and care that a reasonably careful [insert type of professional] would have used in similar circumstances. This level of skill, knowledge, and care is sometimes referred to as “the standard of care.”
[You must determine the level of skill and care that a reasonably careful [insert type of professional] would use in similar circumstances based only on the testimony of the expert witnesses [, including [name of defendant],] who have testiﬁed in this case.]”
These professional standards of care are still objective but require the professional to possess the knowledge and skill of a member of the profession or occupation in good standing. Usually, a job turns into a profession if the proponent holds themselves out to the world as having specialized skills related to executing a job successfully.
For example, doctors fall under this category, and courts apply a national standard of care to evaluate their conduct. Doctors have special skills above those of an ordinary reasonable person; they know how to diagnose individuals for sicknesses and provide treatment. Lawyers are the same in that they hold themselves out to understand the law and how to apply it to your situation.
Security professionals are no different than other professionals because they market their specialized skills (risk assessments, security design review, forensic examinations, pen testing, malware analysis, security code review analysis, etc.) to protect and secure the company’s enterprise systems. Therefore, it is likely for security professionals to fall under the professional standard of care.
Professional standards of care are more strict than the ordinary prudent person standard and have the potential to increase liability. Just as doctors have a national standard of care, California has created a checklist of activities that constitute “commercially reasonable security”. Following a national standard of care does not guarantee “reasonableness.” However, not following a national standard of care is usually evidence of being “unreasonable” or not meeting your standard of care.
The following is a checklist of security controls created by the Center for Internet Security (CIS). California has data security laws that require the following checklist items to establish “reasonable” security:
- Inventory of authorized and unauthorized devices
- Inventory of authorized and unauthorized software
- Security configurations for hardware and software on mobile devices, laptops, workstations and servers
- Continuous vulnerability assessment and remediation
- Controlled use of administrative privileges
- Maintenance, monitoring and analysis of audit logs
- Email and web browsing protection
- Malware defenses
- Limitation and control of network ports, protocols and services
- Data recovery capability
- Secure configurations for network devices such as firewalls, routers and switches
- Boundary defense
- Data protection
- Controlled access based on the need to know
- Wireless access control
- Account monitoring and control
- Security skills assessment and appropriate training to fill gaps
- Application software security
- Incident response and management
- Penetration tests and red team exercises
The CIS Controls document is one of many catalogs of practices. SANS publishes its own “Top 20” practices list compiled from other sources; the iconic NIST SP 800-53 Catalog of Security and Privacy Controls for Federal IT Systems in its most recent Revision 5 has over 900 individual security measures. The CIS controls list provides a comprehensive and mostly manageable list of items. However, every business is different and has different risks.
A caveat with the CIS Controls is that in large enterprises, Item 2 above may be achievable with considerable effort and significantly diminishing returns. Furthermore, the ordering of the items in the CIS Controls list may give a false impression as to the prioritization of the items.
The security team alone cannot solve all 20 CIS Controls. IT and networking teams need to make sure that the networking security requirements are met by working with security teams. Application developers need to learn how to write secure code by working with security assessment teams to mitigate risks identified in application security code reviews. Facilities management needs to work with security teams to protect physical access to the corporate work environment.
Although checklists provide an easy way to direct resources, they are usually incomplete. Unlisted defensive mechanisms may be required to implement reasonable security. Security has to be a holistic process that takes into consideration how the business functions as well as what the prized assets are to external attackers and the corporation itself. Following a checklist may not put the relative importance of different systems in perspective and as a result, controls may be overemphasized in certain areas and underemphasized in others.
To demonstrate, let’s review what a reasonable security program looks like and how it is communicated to the C-suite. Remember that under a reasonable standard of care you need to implement a security program that a reasonably prudent security professional would have implemented. You have to understand how your business operates, what systems are core to the business, what kind of sensitive data you have, how data is received, processed, used, stored and transmitted/shared, what protection mechanisms are in place, and the associated regulations under which the data is covered. You need to understand how sensitive data is protected given the resulting risk. If it is not protected appropriately, put the corresponding controls in place.
One of the first and most important things you need to do to have reasonable security is to understand what you need to protect. A threat model/assessment is one way to do this.
Perform a threat and risk assessment
A reasonable security professional will understand that there are limited resources and budget when building a reasonable security program. You must also consider vulnerabilities, threats that can take advantage of vulnerabilities, likelihood of that incident happening, potential impact (financial, reputational, etc) of that incident, and the number of times that a failure might occur to determine risk. Focus on high-value areas to the company and attackers. To understand what the high-value areas are, you will need to understand your company’s business and the systems that drive it.
Understanding your business
Knowing how the business operates, the revenue streams, and the internal systems that drive the business helps a reasonable security professional to frame security around the systems and infrastructure that are core to sustaining the company. This knowledge also allows a you to apply a limited budget in a way that prioritizes protecting core systems over less important systems.
It is not enough to understand the systems in the environment. With the advent of machine learning and data science, systems may also include decision support, machine-learning research and data mining projects. If your company has a data catalog like data.world, then you can get a better idea of where data is used. In addition, the company should be auditing access, so you should also know who has copies of the data and what it is being used for. It is important to drill down into each system and data catalog to understand what type of data is processed, how the data is processed, where the data comes from and if the data is shared with any other internal or external systems.
Understanding the data and assets
Concurrently, while you are learning about your internal systems, you need to understand the data-specific assets that these systems operate with. Each individual system, each organization and enterprise has a body of data on which it depends; this is what enterprise systems “operate” on. To manage a system properly and achieve reasonable security, it is necessary to understand the system’s architecture as well as their sources of information (upstream data flows), and data attributes/fields.
There are likely to be downstream consumers of this system’s data and protection mechanisms implemented to protect the sensitive data at rest, in transit, in use and in memory. Assets could be strategic plans, source code and other documentary intellectual property (IP). Other important data could include complex structured data such as imagery and sensor device streams from internet of things (IoT) devices.
Sensitive data can be broken into three groups: customer data; corporate, employee and partner data; and regulatory data. Sensitive consumer data is any collected data that, if stolen, would subject data originators (customers) to harm. This includes Social Security numbers, payment card numbers, passwords, health information and other personally identifiable information (PII).
Corporate data is sensitive if it can be used by competitors to gain an unfair advantage or if exposed to the public could result in reputational harm to the corporation. It could be trade secrets, undisclosed research, plans, internal memos, or any form of secret IP.
Finally, regulatory data is sensitive if it is regulated under any of the statutory or corporate governance regimes (CCPA, General Data Protection regulation [GDPR], Payment Card Industry Data Security Standard [PCI DSS] , Sarbanes-Oxley [SOX], etc.) Document the data type, all the places it is processed, stored, or transmitted, and how it is used.
Understanding regulatory data coverage
Certain types of sensitive data will fall under different regulatory requirements depending on what kind of data is stored or citizenship of the data originators (owners). For example, if you do business with persons located in the European Economic Area, then the GDPR would possibly apply. If you are covered by HIPAA and storing health data, then HIPAA would apply.
In the federal government environment, individual and corporate stewards of particular types of sensitive data are subject to extensive new security and control obligations under a new statutory and regulatory regime for Controlled Unclassified Information (CUI). Each of these regulations has different requirements on protecting data (controls), breach notification and user privileges (right to delete, right to understand, etc.).
Now that you know what data is used in the enterprise, you can see which laws and regulations apply, what requirements you need to meet, and what protections need to be put in place.
Understanding how data is protected
Next, you need to understand how sensitive data is protected given the resulting risk. Where no protections are in place, it is easy to see that appropriate protections are needed. Verifying the adequacy of current protection mechanisms will require application of threat intelligence of new attack techniques to the controls in place and their adequacy in mitigating those threats.
Other considerations include how data can be recovered with tested backups and testing recovery methods (ensuring that the backups themselves are accurate), as well as evaluating how incident response plans will perform when needed. For incident response, most will follow prescriptive measures such as SANS’s The Incident Handlers Handbook or NIST’s Computer Security Incident Handling Guide.
Reasonable security is akin to a cat-and-mouse game where adversaries learn the techniques used to stop or discover them and then find workarounds. This requires security practitioners to improve discovery or response techniques. Look at the guidance and have an attitude that most advanced attackers have already found ways around them. For example, the SANS handbook suggests looking for large files. What do you think an attacker’s response would be given that they still need to exfiltrate large amounts of data from vulnerable networks?
Once you understand what data you have to protect, what protective controls you have in place, and the regulatory requirements associated with the data, then you can identify gaps between the controls in place and those that are required by regulations. Depending on the facts, bare compliance with minimum legal requirements may or may not be enough to forestall negligence liability.
Meeting regulatory requirements
Ideally, the process to support GDPR (and now CCPA) requirements will need to be documented and communicated to the respective teams to ensure the ability to comply with requirements in regulations like GDPR’s requests to be forgotten, to understand data processing, to extract all data associated with a single user, etc. There needs to be coordination of development groups with this process so requirements are met. Ideally, this work should be done with the legal team so there are no gaps and groups are moving in the same direction.
Moving beyond a data-centric approach
All the processes discussed so far have been focused on protecting internal data sources. Reasonable security professionals understand that attackers can also compromise the enterprise by penetrating the devices on the network or the network itself using advanced persistent threats (APTs), finding unpatched servers or applications, exploiting weak passwords on remote access accounts, or accessing unprotected Amazon S3 buckets. That is where having organizational frameworks like the software development lifecycle (SDLC) and MITRE Att&ck will help.
Protecting your enterprise systems and infrastructure
The services and applications you provide to your customers on the internet are built on the systems and infrastructure of your enterprise. Most services are made up of applications. Applications are built with source code and deployed on infrastructure (usually server based for web applications). Source code will use libraries and frameworks. Libraries and frameworks are built with compilers.
Each level of the chain can introduce security vulnerabilities. A reasonable security professional will assess the risk at each of these levels to put the appropriate controls in place. Although application security is very important (as Equifax has taught us), with the advent of APTs and targeted attacks, you also have to look at the security of the organization as a whole and implement an “organizational security process.”
Developing your organizational security process
An example of an organizational security process is: