Regarding “information security,” the last thirty years have seen an evolution of frameworks, laws, and assessment approaches which intimidate the management team with their complexity.  Even the name has changed – to cybersecurity – though if you listen hard, you can hear people like me arguing there is a difference.

Some say that information security protects information, cybersecurity protects the technology using that information.  If you notice the title of this article, you’ll see I used the term “system security.”  For the sake of this article, “system security” means the confidentiality, integrity, availability, and control of information; the devices that process and store that information; the users of that information and devices; and the assets upon which information rests, travels, or is used.  In short, system security accounts for the entire ecosystem.

For years, management has relied on highly trained people to manage technology risk methods ranging from the FFIEC’s guidelines to the SSAE-16 Standards and nowadays to the various publications on NIST.gov.  To make sense of it all, in 2003 I developed a simple method of helping the rest of us understand what needs to happen to keep information, technology, and people safe.

I call this method, the “Four Basic Truths”. These truths consist of three principles and one implementation truth: eight control systems.

There are four basic truths when it comes to system security:

1. Risk:  Technology, and the use of technology, creates risk.
2. Cause:  There is a common cause to this risk.
3. Manage:  We can manage this risk.
4. Control:  To manage the risk in a balanced, cost-effective manner, implement eight control systems.

TRUTH ONE — RISK: The use of technology creates risk.

When we founded Infotex in 2000, we had to convince people that security represented a problem worth their attention.  There just wasn’t a business case given the complexities of information security.  By 2012, management was just beginning to recognize system security as a priority.  Then, in 2013 and 2014, security boomed. (Thank you, Target, Neiman Marcus, Anthem, the United States Federal Government, and what I called “the parade of breach news”!)

Then the malicious community found their cash cow.  We could hear a large popping sound as those with their heads still in the sand became aware of ransomware.  Healthcare organizations, manufacturers, and others who believed residual risk was low because they did not process confidential information (ePHI notwithstanding) changed their minds, as we all learned that availability was the A in CIA (confidentiality, integrity, and availability—the original goals of information security).

We don’t have that problem now, as artificial intelligence scares the least technical among us. (Thank you, Arnold Schwarzenegger!) We review current top risks in our annual article, R7, in an attempt to help security professionals keep their management teams aware.

TRUTH TWO — THE CAUSE:

That a threat can exploit a vulnerability creates risk. We can measure that risk, relative to other risks, by applying metrics to likelihood and impact.  In simple terms, risk exists when something bad can happen (likelihood) and it would matter if it did (impact).

The three most likely families of threats include people, the environment, and the technology itself.  People create risk either maliciously (hackers) or accidentally (user mistakes).  The environment creates risks related to tornadoes, floods, or even where we use the technology.  And finally, the technology itself can create risk, as we all learn over and over again, when new technology fails us.

Technology failures can cost money (financial risk), cause us to be sued (legal risk), break laws and regulations (compliance risk), prevent us from doing our jobs effectively (availability or continuity risk), and embarrass us (reputational risk).

TRUTH THREE — MANAGE: We can manage this risk.

“Doing something about it” is why the frameworks referred to above are so complex, as there are thousands of things we can do about risk.  But we should focus our efforts where they would be most effective.  Risk management is about prioritization, not perfection.”

We must first measure, then respond to, then monitor risk.

Risk measurement is handled in various risk assessments as well as audits. Technology risk comes in three forms:

• Inherent risk (the risk prior to the implementation of controls),
• Residual risk (the risk remaining after existing controls), and
• Anticipated residual risk (what we believe the risk will be after planned controls are implemented).

Risk response is best prioritized by current measurement.  There are three primary methods to respond to risk: transfer, mitigate, or accept.  The tactics available to us, or controls, all fall into one of these three categories.  The fourth truth is that there are “systems of controls” that work together in a mature system.

Meanwhile, we monitor risk not only with sophisticated tools like Triguard®, (a Security Information and Event Management platform), but we also rely on the awareness of our management, employees, customers, and vendors to monitor risk.  This is why you are being asked to read this article!

We should prioritize our efforts by measuring all three forms of risk (inherent residual, anticipated residual).  Measurements can be as simple as using a relative scale (such as 1–8 for likelihood and 1–5 for impact), or as complex as quantifying tangible and intangible probabilities and costs, including ease of remediation.

Ease of remediation, of course, includes cost—but total cost of ownership should be considered. (Passwords are free, but teaching people to use strong passwords takes a lot of time.)

Another example: a firewall mitigates substantial likelihood and is relatively inexpensive. Burying our servers in the ground and not letting anybody access them mitigates almost all likelihood and impact, but the total cost of ownership—and loss of availability—precludes us from taking this approach.

“Once we understand risk, its cause, and how it can be managed, the practical question becomes: how do we do this consistently and cost-effectively?”

TRUTH FOUR — EIGHT CONTROL SYSTEMS

To manage risk in a balanced, cost-effective manner, implement eight control systems.  These systems, or business processes, work interactively and should be documented via policy and procedure.  Together, they form a governance fabric rather than a checklist.

1 – AWARENESS

I had to cancel a workshop scheduled for September 2001 because Al Qaeda attacked America.  While watching the aftermath, I noticed we were far more secure on 09/12/2001 than we were on 09/10/2001. That was when I coined the phrase, “Awareness is 9/11ths of the battle.”

Awareness is the reason we all became more secure after the 2013 Parade of Breach News. It should be applied “in all directions,” which usually includes the Board, Management, Technical Team, Users, Vendors, and Customers.

Awareness is what will protect us from the risk of Artificial Intelligence.

We achieve awareness through education, motivation, and activation. We lower risk by educating people and systems in all directions about the threats, vulnerabilities, and controls in our environment, as well as the risk we have accepted and our plans to reduce that risk.

We motivate users by helping them understand why controls are in place. We activate awareness by putting users on guard, usually by testing user-related controls.

Our policies educate.  Our training motivates when we explain why.  Activation is achieved through phishing tests, pretext-calling tests, red team exercises, incident response tests, and blue team tests.

2 – RISK MANAGEMENT

Once we have the right people and systems aware, we need to inventory threats and vulnerabilities, as well as assets, and apply relative measurements to the entire inventory.  The inventory should include all information assets—any technology, information, place, device, or vendor that contains information our customers, partners, and employees trust us to protect.

Nowadays, software makes this easier. Back in 2001, we used spreadsheets.  Spreadsheets still work—the important thing is to start thinking in terms of inherent, residual, and anticipated residual risk as vendors pitch new ways to control risk or as we respond to framework assessments.  But if your team is still using spreadsheets, you might want to ask about this.  There is a solid business case for applications like TRAC or CoNetrix.

Essential deliverables from the risk management system include:

• an asset-based risk assessment, updated annually and presented to the board or ownership,
• an audit risk assessment and audit plan, and
• a threat-based risk assessment.
• Annual board and management awareness training should include summaries of these deliverables.

Finally, a risk response document should be developed annually and may be included in one of the above deliverables. This document establishes mitigation plans using one of the three response methods: transfer, mitigate, or accept.

Transfer and mitigation tactics must be part of the technology plan. Risk acceptance decisions should be monitored by the incident response team.

The primary goal of risk management is prioritization: ensuring appropriate awareness of risk, risk response (especially accepted risk), controls, and plans to introduce new controls.

All controls should be documented, for each of the eight systems, in an IT Governance Program.  (The FDIC prefers this to be named your Information Security Program, but other agencies don’t care what you call it)

3 – VENDOR MANAGEMENT

With all the work your bank does to manage risk, one click of a vendor’s employee could cause an event anyway.  One of the most commonly used risk-transference methods is outsourcing.  Banks use cloud providers for everything from core applications to email.

Each third party that receives information or has access to information should be assigned a vendor owner who works with the Information Security Officer to measure and control vendor risk.

Vendor risk should be addressed through five precepts: contract review, assurance review, insurance review, financial review, and business continuity plan review.  A vendor risk report, covering these precepts and prioritized by vendor-centric residual risk, should be presented to the board annually.

A current concern in vendor management is measuring risk exposure related to artificial intelligence.  The risk is both security  (what his happening to our data?) and stragegic (are you really using AI, are we falling behind because we’re NOT using AI?)

4 – ASSET MANAGEMENT

Not only must we identify all information assets, but each one should be assigned:

• a data classification (critical, confidential, internal use, or public),
• an asset owner, and
• metrics related to inherent risk (likelihood, impact, and—if desired—volume).

Nowadays, asset management programs (and even risk management programs referred to above) make this easier and can automatically update as new assets are added or old assets are retired.

5 – ACCESS MANAGEMENT

Speaking of retiring old assets, access to information assets should be closely controlled from the time an asset is introduced into our environment until after retirement—when it is destroyed or, in the case of information, deleted or archived.

This system includes the management of identities as well as access. Data ownership should be assigned during the data classification process.

Access management includes not only how we approve and prevent access to information but also data classification tactics and authentication into the asset.  Multifactor Authentication is now a basic control, but many banks are starting to move to “passwordless networks” leveraging a new FIDO-2 framework.

6 – TECHNICAL SECURITY STANDARDS

Speaking of authentication, there are many technical controls that must be in place and tested on a regular basis.  Documentation should be audited regularly against actual practices to ensure technical controls are current, applicable, and enforced.

Examples of documentation include access management procedures, change control procedures, threat monitoring procedures, server hardening procedures, playbooks and runbooks, and vulnerability management procedures.

Management obviously does not have the ability to know whether these standards are adequate; and thus your auditors provide a lot of value in this area.

7 – INCIDENT RESPONSE

When—not if—the above systems fail, leading to a potential breach of confidentiality, integrity, or availability, we must have a proactive, well-tested method of response.  The board or ownership should define a multidisciplinary incident response team, including representatives from the board, senior management, marketing or public relations, human resources, information security, information technology, and operations.

A plan should be developed and tested so that escalation is appropriate and management recognizes the response process as it unfolds.  Incident response tests should exercise data leakage and insurance and should therefore include senior management and the board. Technical response tactics—from detection through escalation—should be tested through blue team exercises that do not include nontechnical personnel.

8 – BUSINESS CONTINUITY

As stated above, availability risk is a core objective of system security.

Natural or man-made disasters, as well as ransomware, require teams to implement contingencies appropriate to the disaster and the business needs of information assets.

A business impact analysis should drive response priorities. Plans should be tested so that escalation is appropriate and management recognizes the response process as it unfolds.

CONCLUSION

If you are a board member from a different industry, know that every framework we may—or may not—choose to comply with, from various NIST publications to ISO to ITIL to PCI to the FFIEC, and every law—from FISMA to GLBA to HIPAA to GDPR—ultimately requires the same four basic truths of system security.

If management understands these basics, as well as the eight control systems, it becomes far easier for security and technical teams to navigate frameworks without losing sight of the objective.

Most importantly, our customers—and the information they trust us with—will be safer.