“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:

1. The defendant had a duty to the plaintiff
2. The defendant breached the duty
3. The breach of defendant’s duty was the cause of plaintiff’s harm
4. 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.

CSO / IDG

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 testified 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:

1. Inventory of authorized and unauthorized devices
2. Inventory of authorized and unauthorized software
3. Security configurations for hardware and software on mobile devices, laptops, workstations and servers
4. Continuous vulnerability assessment and remediation
5. Controlled use of administrative privileges
6. Maintenance, monitoring and analysis of audit logs
7. Email and web browsing protection
8. Malware defenses
9. Limitation and control of network ports, protocols and services
10. Data recovery capability
11. Secure configurations for network devices such as firewalls, routers and switches
12. Boundary defense
13. Data protection
14. Controlled access based on the need to know
15. Wireless access control
16. Account monitoring and control
17. Security skills assessment and appropriate training to fill gaps
18. Application software security
19. Incident response and management
20. 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:

CSO / IDG

Traditional security programs have focused only on prevention. The problem is that an attacker only needs to find one weakness to get in your network, and as a defender you have to plug every vulnerability to make sure that the bad actors don’t get in. A reasonable security practitioner will take this into consideration and balance preventative measures with resilience measures and detective controls.

Associated detection and response measures ensure that even if attackers get in, they eventually get caught. Resiliency ensures that systems can withstand attacks, gracefully fail, and are able to quickly be recovered/restored. Red teaming, threat hunting, IR and penetration testing are critical to detecting attackers in the network and responding to their threats.

To systematically provide coverage for detection and response measures, a reasonable security program will implement a framework like MITRE Att&ck to support red and blue teams, CIRT and penetration testing efforts. MITRE Att&ck is a taxonomy of tactics (why), techniques (what), and procedures (how) describing an attacker’s exfiltration chain.

You should tie the taxonomy to relevant threats to your organization and industry as well as the data sources for detections within your organization. If you are buying a tool that helps with enabling MITRE Att&ck, don’t just look at the tactics, techniques, and procedures that are covered by the tool. Make sure that the tool supports consuming data sources associated with relevant techniques within your enterprise environment.

Talking to the C-suite about security

Reasonable security requires you to communicate to executive leadership to make sure you are getting appropriate buy-in and keep executive leadership and the board of directors apprised of the current risks so they can make informed decisions. If executive management understands how security breaches can impact the bottom line and  how the damages and civil money penalties can drastically affect stock price, competitiveness and reputation, security becomes a top priority. The question is what and how do you present to the board.

You need a basic understanding about what drives the board or CEO. Put yourself in their shoes. The board is typically interested in protecting and increasing shareholder value by making sure that the correct executives and officers are executing in a direction that the board agrees with. The executives and officers are also interested in maximizing shareholder value, but their roles are more operational. They manage the operations to ensure that the company grows and shareholder value is maximized.

Most of the people on the board will not be well versed in security, so don’t throw around words like “kill chain”, “pyramid of pain”, “ATT&CK” or “threat modeling” without giving some type of explanation ahead of time. You want to show executive leadership that you understand how the business runs, what the critical assets are, and how you are protecting them.

I suggest a baseline threat model summary, followed by the status of preventative measures, noteworthy incidents (how they're being handled and incident metrics to ensure that things are getting better -- or, if things are getting worse, understanding why), the number and magnitude of unresolved security issues broken down by group and type, threat intelligence (to understand what type of relevant attacks you are seeing and if the trends affect the organization), and, finally, active detection efforts and response preparation given the threat intelligence.

From reasonable security to reasonable trustworthiness

As more products and services emerge around the industrial internet of things (IIoT) and consumer IoT, what a company can be held negligent for will expand. California has already created specific laws for connected device security in Senate Bill No. 327 (Chapter 886).

If you are in an autonomous driving vehicle, you don’t want its operating system to crash periodically due to out-of-memory errors. What happens when your home and all its appliances become smart and connected to the internet? If a connected microwave or oven is compromised and can be controlled remotely, it can be turned into a mini bomb by running it for prolonged periods of time with nothing inside.

A failure in a connected device — autonomous cars, robots, delivery drones, connected ovens, insulin pumps, pacemakers, etc. — has the potential of causing death or serious bodily harm. Due to the increased risks of injury in IIoT and connected devices, it is likely that the standard of care will be raised higher due to the increased risk of physical harm to society.

A movement is gaining traction related to ensuring trustworthiness of products and services. Security is an element of trustworthiness alongside safety, resilience, reliability and privacy, which are required when building products and services. If you are building a product that could cause serious harm, start embedding trustworthy procedures and processes into your organization. You can find a wealth of information at the Industrial Internet Consortium Journal of Innovation.

To give you a quick overview, trustworthiness is defined by how well a product or service provides assurances of safety, security, reliability, privacy and resilience. Trustworthiness can be further detailed by the following criteria, outlined in Robert Martin’s Assuring Trustworthiness in an Open Global Market of IIoT Systems via Structured Assurance Cases:

• Reliability of the components and the system.
• Availability of the components and the system
• Safety of the components and the system
• The integrity and authenticity of the components and system
• The confidentiality of the data used by the components and system
• The reputability of the data from the components and system
• The privacy of the data used by the components and system
• The maintainability of the components and system
• The ability of the components and system for easy and modifiable configuration
• The resilience of the components and system to an attack or misuse
• The usability of the components and system for its intended use

Each product or service can be broken down into smaller components to have their individual trustworthiness evaluated. These individual scores can be evaluated in aggregate where they can be combined to provide a score for the entire system.

Trustworthiness scores have to be supported by specific assurances as to how the system functions under threats to security, privacy, reliability, safety and resilience. Each assurance has to be supported by evidence. Evidence is usually in the form of assurance cases. Assurance cases document the system properties, claims and requirements that are being fulfilled with residual risks that are acceptable or known. An assurance claim usually consists of two parts:

1. The assumptions of the assurance
2. Claim of system trustworthiness as well as any of its supporting sub-claims

An inherent advantage using assurance cases is the ability to make assertions (if your top level assumptions are complete) that the assumptions of each case are being fulfilled by their encompassing top level system and its associated assurance cases. This allows you to additively compose the safety, reliability, security, resiliency and functional requirements for the assurance obligations of your subsystems.

Reasonable security is a holistic process that needs to take the current business needs of an organization into consideration. While a checklist of security controls may be helpful, it cannot encompass every organization’s needs. For an action to be reasonable, it has to be done objectively as a reasonably prudent professional in the same or similar circumstances. You have to look at your organization, its business function, assets and attacker-prized booty. Then look at how you can reasonably protect those assets based on risk. Depending on the type of your product, you may have to consider trustworthiness.

Special thanks to Kunal Manoj Patel, Hoyt Kesterson, Steven Wu (of Silicon Valley Law Group), Robert Martin and Michael Aisenberg (both from MITRE) for providing feedback and reviewing this article.

Disclaimer: This is NOT legal advice. This is an academic exercise in applying legal principles from law school to the field of information security. The hope is to spur discussion about what practices are needed to implement reasonable security measures in the enterprise by giving security practitioners an understanding of reasonable behavior from a legal standpoint.

More about ABAmazonAssuranceATTBillCACICSOEquifaxEUFederal Trade CommissionIDGIRSystem Solutions