Rethinking security

6 foundational steps to make your enterprise security program effective.

six big projects that went open source 1
Thinkstock

Two very different publications on “cyber resilience” got me thinking about the definition of “information security”, which I thought I understood.  The first is Digital Resilience, a 2018 book by Ray Rothrock.   The second publication is NIST SP 800-160, draft v2 (March 2018).  In Mr. Rothrock’s book, “resilience” is defined as a business risk to be dealt with using a holistic systems approach to threats and mitigation.  In SP 800-160 v2, resilience is characterized as surviving after an APT has a foothold in your network or systems.  We still don’t have immutable definitions of the basic terms in this field!  Security practitioners are like the five blind men describing an elephant.  No wonder there is a communication gap with business leaders.  So, in this post, I decided to offer my own description of “security”, with some best practice implementation ideas.  It is a rethinking rather than reinventing.

Security 1.0 was about protecting information assets.  Think Fort Knox.  Security 2.0 is about sharing information AND protecting it at the same time.  Alex Stamos’ 2017 Black Hat talk brilliantly discussed how to do this.  In this era of ubiquitous computing imbedded in almost every business process, security must follow the data out beyond the technology silo.  I didn’t even mention IoT yet; however, consider the new, smart Tappan Zee bridge with 450 built in sensors to monitor bridge status and health.  At the same time, according to the recent Cyber Edge group report, we are spending more and getting less security protection.  Gartner estimates that worldwide spending will hit $93B this year.  This post will present some ideas and suggestions to rethink security and, hopefully, to make available dollars more effective. 

I will use Rudyard Kipling’s six wise men approach, which I first saw applied in the SABSA security framework.  That framework was developed in 1996, so in 2018 I have some different answers to the same questions.  These questions and my answers are:

  1. Who: Everyone
  2. What: CIA plus resiliency and privacy
  3. Where: In business processes; in the data
  4. When: Build in
  5. Why: Cyber “Value at Risk”
  6. How: Lean security

Who:  Everyone

Cyber security is everyone’s responsibility.  We need to go beyond posters put up during cybersecurity awareness month.  They are about as effective as “School Zone, 15 mph” signs.  Who are the key people on enterprise “team cyber”?  Three traditional linchpin roles are security operations, security architecture and security policy, all out of the CISO’s office.  Who else?  Another critical role is the project manager.  PM’s see new initiatives from day one.  They are among the best people to make sure security is built in, whether we are talking about new infrastructure or new applications or new systems.  If we wait until “day two”, security does not get built in anymore.  I recently gave a presentation on security for project managers, which you can find here.  Other critical roles include:  business analysts, developers, privacy officers, vendors and corporate leadership.  CPO’s need as be versed in information security (as CISO’s need to be versed in privacy concepts).

NIST SP 800-160 v 1 (2016) documents, in detail, the roles needed to develop secure systems.  Many of these are not effectively engaged in organizations.  These roles and associated security issues include:  purchasing; pretty much everything is connected to the internal net these days.  Has security reviewed the acquisition ahead of time?  HR; should be actively engaged to help source critical security skills when needed.  Project management; a key security enabler.  Security maintenance; with rapid development and implementation paradigms, who is going to maintain system security?  Disposal; this has long been a problem with organizations keeping data and systems beyond their useful life and thereby increasing attack surfaces.

What:  CIA plus resiliency and privacy

This is a test.  Traditionally the answer has been confidentiality, integrity and availability (CIA).  More recently, organizations have adopted the NIST CSF’s (Cyber Security Framework) five pillars of identify, protect, detect, respond and recover.  The five pillars are then divided up into 108 subcategories.   The assumption is that by implementing the subcategories we will achieve CIA.  I have never quite believed this.  Security is an emergent property.  My own security assessment starts and may end with: “does the board (or managing partners) meet regularly on information security (management buy in) and are minutes of those meetings maintained (accountability)”?  If that’s not happening, you will not be secure.  If it is happening, you may be secure; more information is needed.

Why are there more dimensions to “security” than CIA or the NIST CSF?  The same reason that there is more to the health of a business that the P&L and balance sheet.  Think of terms like “cash flow” or “Ebitda”.  The health measures of a business depend on what you want to do with it (buy it, sell it, invest, etc.).  The same is true for cybersecurity measures.

The other important security measures or dimensions tend to be emergent properties; that is, properties that are obtained through simultaneous, orchestrated attainment of individual properties.  The opposite are reductionist properties, like audit controls or the CSF subcategories.  The assumption that meeting all the individual controls will secure the enterprise is clearly not valid.  That is the compliance approach.

One important emergent property is privacy.  Regarding privacy, I thought it interesting that GDPR is the Global Data Protection Regulation, not Global Data Privacy Regulation.  “Security” is mentioned 24 times in the context of protecting data and privacy.  In addition, NIST 800-53 revision 5 (to be released in December 2018) now includes privacy controls within its main control catalog (instead of in an Appendix).  There are 60 “privacy” controls and 101 joint “privacy and security” controls in the draft.  Systems that need to meet FISMA requirements will need to be reevaluated considering the new privacy controls.

Another emergent property is resilience.  This property assures that the business keeps operating in the face of adversity.  It includes incident response and recovery but is broader in scope.  The recent Facebook response to the Cambridge Analytical matter required resilience.  The same thing for the ChoicePoint breach of 2004-5, in which customers were stealing ChoicePoint’s data.  Let’s look at three different points that I took away from Mr. Rothrock’s book on digital resilience.  These three, I believe, will better assure an effective (risk mitigation) and efficient (cost control) security program:

  1. Business integration. How well is security collaborating with the business?  If this is not measured, then it is unlikely to improve in an orderly fashion.  Maturity models for IT-business “alignment” have been developed in the past and could be updated for security-business integration.
  2. Prioritize information protection across the organization. There is not sufficient funding to protect everything in each application.  The same is true across the organization.  Only a holistic risk analysis (the equivalent to enterprise risk analysis) can adequately allocate funds.  With thousands of security technology solutions being offered this is becoming more important.
  3. Focus on business processes, not only data or assets. This requires a systems approach, in which all the dependencies and risks are documented and managed.

Where:  In business processes; in the data

We are going to need to protect assets in the cloud and private data centers.  We can’t just rely on the cloud for security.  (Five years ago, we couldn’t rely on the cloud either).  Humans aren’t moving to the cloud soon.  Business processes can bridge the risk analysis gap.

Securing business processes means keeping the business running according to plan.  The challenge is figuring out what the key processes are and what is needed to protect them.  The only way to do this, is via a discovery process, through continuous interaction with the leaders of those processes.  Each business will be different.  The most common processes will include:  R&D or development, administration, customer service, product distribution, finance, HR, IT, marketing, sales and manufacturing (if applicable).

Protecting data has traditionally been based on defense in depth.  Newer use cases include sharing data while protecting it.  In "Protecting trade secret: technology solutions you can use," I highlighted Microsoft’s Office 365 AIP solution for protecting trade secrets and other confidential documents.  At the recent RSA show, at least five other vendors exhibited products for protecting information while sharing it:  Allure, Fasoo, Final Code, MyWorkDrive and Seclore.

When:  Build in

Answer:  Build in security.  This idea has been around for 25 years, but we are still running toward the goal line.  The acceleration of business and the sheer number of endpoint and attack vectors has kept moving the goal.  However, two new data points show that we are getting closer. 

The first is the NIST standard, SP 800-160 (volume 1 November 2016, with updates March 2018) that I mentioned earlier.  This document enables build in security by highlighting the roles and functions that must be part of the secure systems development process. 

The second unrelated data point is the recent announcement of Azure Sphere from Microsoft.  The product comprises a secure microcontroller chip, a secure OS and a secure cloud platform, all for enabling the development of secure IoT systems and products.  If it proves to be secure and if it can provide developers with an easy to use development platform, it may be the built-in security platform for IoT.  Potentially, the most broadly used secure platform since the mainframe.

Why:  Cyber “Value at Risk”

Another test; obviously the right answer is risk mitigation.  The wrong answer is compliance.  Risk mitigation should be looked at through the lens of Cyber Value at Risk (VAR).  “Value at Risk” is a term borrowed from finance, where it represents the maximum (likely) loss for a given portfolio of equities or bonds, or pork bellies.  It is measured in dollars.  At the same time, that portfolio is designed to give a positive gain over time, with the VAR at an acceptable level. 

The same concepts can be applied to information security.  First, we need more quantitative measure of risk, in dollars, not just high, medium and low.  Second, we need to account for the upside to the business, not just the downside.  If a business operation is static, there is no upside; if the business is growing, the security upside can be important in enabling that growth.  This was articulated by the SABSA creators in 1996 (Enterprise Security Architecture, Sherwood, Clark and Lynas): “...one must take care not to mitigate a specific risk whilst unintentionally increasing the overall risk to the wider range of business goals and objectives”.  Many others have highlighted it, but it does not seem to be in common practice.  Determining the upside requires knowledge of the business, not just breach statistics, and CISO’s have only recently gotten a seat at that table.

security related financial outcomes Frederick Scholl

The diagram illustrates a range of security related financial outcomes, from unacceptable loss to financial gain.  An effective security program reduces potential losses, while increasing potential gains.  For example, I have seen IAM systems implemented to make HIPAA compliance easier (reduced risk), while enabling the rapid onboarding of doctors (financial gain).

How:  Lean security

I and others have long advocated using the ideas from lean to implement a security program.  In my case, this results from my experience in manufacturing quality control.  Others are incorporating this philosophy, whether or not they use the terminology.

The basic concept is shown in this illustration.

securitiy design Frederick Scholl

In both diagrams, planning and design moves from left to right.  With traditional security approaches, we have started by securing the network, and then maybe getting to the business users’ needs at the end of the process.  In the lean approach we start with the business and the business users.  Today, as we then get to systems and networks, security is more reliant on SLA’s with cloud vendors.  For SaaS, security may be mostly reliant on the vendor.  The lean approach also emphasizes proactive use of metrics, whereas traditionally, monitoring is utilized primarily to detect breaches in insecure systems.

Lean also emphasizes fast feedback.  We are attaining this in the Agile/DevOps world, in which teams can easily evaluate customer response and provide feedback information to developers via issue tracking systems.  But what about security?  Typically, we are not testing different approaches in production.  But we still need fast feedback to the development and QA team.  Approaches being used now include bug bounties and pen testing.  I believe more automated testing will help speed the security feedback.  Vendors in the “Breach and Attack Simulation” space, recently defined by Gartner, include:  Sythe, Attack IQ, Core Security, Cymulate, SafeBreach and Verodin.

That is it on this topic.  As Kipling said in his poem: “I keep six honest serving-men; But after they have worked for me, I give them all a rest.”

This article is published as part of the IDG Contributor Network. Want to Join?

SUBSCRIBE! Get the best of CSO delivered to your email inbox.