What is "reasonable security"? And how to meet the requirement

Privacy regulations such as the GDPR and CCPA require companies to provide "reasonable security" to protect customers' personal information. Here's how you might best achieve that standard.

1 2 Page 2
Page 2 of 2

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:

reasonable security chart cso 1250px 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.

This story, "What is "reasonable security"? And how to meet the requirement" was originally published by CSO.

1 2 Page 2
Page 2 of 2
ITWorld DealPost: The best in tech deals and discounts.
  
Shop Tech Products at Amazon