Analytics

8/10/2016
01:30 PM
Joshua Goldfarb
Joshua Goldfarb
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

Theory Vs Practice: Getting The Most Out Of Infosec

Why being practical and operationally minded is the only way to build a successful security program.

One of my favorite quotes states: “In theory, theory and practice are the same. In practice, they are not.” I adore this quote for many reasons, and it is one that truly speaks to me. Perhaps I am so fond of this quote because it describes how I approach the discipline of security, and perhaps even life in general.

In my experience, there are two fundamental perspectives that drive how an individual or an organization approaches security: theorist and pragmatist. I’d like to illustrate the difference between these two perspectives through four distinct and examples.

Example 1: Program of “no” 
In many organizations, security has the unfortunate reputation of being the program of “no.”  While it is true that the security organization is ultimately responsible for mitigating and minimizing risk to the organization, it is seldom the case that this is accomplished by saying no all the time.

Let’s take the move to the cloud as an example. In some organizations, the security team will fight the business every step of the way as it moves to the cloud. In other organizations, the security team will work collaboratively with the business to understand how to mitigate additional risk that may be introduced into the organization, work to maintain visibility into business functions that move to the cloud, and ensure that the ability to respond to an incident remains intact.

Why do some organizations take the first approach, while others take the second approach? The former is the theorist’s approach, while the latter is that of the pragmatist. In theory, a move to the cloud will introduce additional risk to the business that the security team may not be able to mitigate. But in practice, the move to the cloud will happen whether we like it or not, and we can either get ahead of it, or be the program of “no”. 

I’ll leave it to you to judge which approach is more likely to help you build bridges and relationships that will allow you to improve the overall security posture of the organization in the long run.

Example 2: Passwords 
As much as we all love 20-character passwords with four capital letters and three special characters, they aren’t particularly effective as a security measure. Of course passwords should not be easily guessable. They shouldn’t be names, birthdays, words, etc. But organizations often take this best practice to a draconian extreme.

What’s the result? Employees write down their passwords or otherwise find ways to work around the system. Using a less extreme password requirement with two factor authentication is usually a much better approach, and it’s one that employees don’t feel the need to work around.

Why do some organizations take the password game to the draconian extreme? You guessed it -- it’s the theorist versus the pragmatist again. In theory, an attacker could guess a password with only 10 characters, one uppercase letter, and one special character more easily than a draconian extreme password. 

But in practice, they don’t:  they compromise systems through the use of social engineering and then steal them. If you insist on being a draconian theorist, you will drive your users to work around you. If you take a pragmatist’s approach, you will find your users much more likely to adhere to your policy.

In other words, by being practical, you are much more likely to achieve your desired results.

Example 3: Anomaly Detection 
Anomaly detection is something I hear people discuss quite often. Back in 2005, I tried implementing a few different anomaly detection solutions that were “guaranteed to work” on a live, production network. What was the result? After a two-week learning period, within the first five minutes of turning on alerting, the solutions generally produced hundreds of thousands of false positive alerts, subsequently flooding and crashing the SIEM.

In theory, anomaly detection is extremely important. I need to learn what is normal, expected, and desired in order to find what is not normal, unexpected, and undesired. In practice, a live, production network is almost never like a lab network, and the flood of false positives and its destructive effect on the workflow and efficiency of the security organization vastly outweigh any potential gain in the detection of malicious or suspicious activity.

Do I think that anomaly detection ultimately has a future in the security field? Absolutely, but only if it is approached pragmatically, with an understanding of, and appreciation for, the pain of operational personnel.

Example 4: I might miss something
I’ve written many times about the need to collect fewer data sources of higher relevance to security operations. In a nutshell, collecting every source of data we can get our hands on, irrespective of its relevance to security operations actually reduces the security posture of an organization in three ways:

  • The variety of data sources creates confusion, uncertainty, and inefficiency. This makes an analyst’s first question “Where do I go to get the data I need?” rather than “What questions do I need to ask of the data?”
  • The volume and velocity of the data deluge the collection system, thereby making data irretrievable in a timely manner
  • Storage is consumed more quickly, thus shortening retention and negatively impacting visibility

In other words, a focus on data value (specifically to security operations), rather than data volume produces better results. Choose the fewest number of data sources that provides you with the required visibility. The theorist believes that he or she might miss something. The pragmatist knows that if he or she cannot leverage the data when they need it most, they will definitely miss something.

It is extremely important to be practical and operationally minded when planning, implementing, and improving a security program. It is important to understand the real-world ramifications and effects that certain decisions will have. While many ideas sound great in theory, in practice, they often turn out to disappoint or even have the opposite of their intended effect.

Related Content:

 

 

Josh (Twitter: @ananalytical) is an experienced information security leader with broad experience building and running Security Operations Centers (SOCs). Josh is currently co-founder and chief product officer at IDRRA and also serves as security advisor to ExtraHop. Prior to ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-2765
PUBLISHED: 2018-08-20
pyro before 3.15 unsafely handles pid files in temporary directory locations and opening the pid file as root. An attacker can use this flaw to overwrite arbitrary files via symlinks.
CVE-2018-15594
PUBLISHED: 2018-08-20
arch/x86/kernel/paravirt.c in the Linux kernel before 4.18.1 mishandles certain indirect calls, which makes it easier for attackers to conduct Spectre-v2 attacks against paravirtual guests.
CVE-2018-15572
PUBLISHED: 2018-08-20
The spectre_v2_select_mitigation function in arch/x86/kernel/cpu/bugs.c in the Linux kernel before 4.18.1 does not always fill RSB upon a context switch, which makes it easier for attackers to conduct userspace-userspace spectreRSB attacks.
CVE-2018-15573
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in Reprise License Manager (RLM) through 12.2BL2. Attackers can use the web interface to read and write data to any file on disk (as long as rlm.exe has access to it) via /goform/edit_lf_process with file content in the lfdata parameter and a pathname in the lf...
CVE-2018-15574
PUBLISHED: 2018-08-20
** DISPUTED ** An issue was discovered in the license editor in Reprise License Manager (RLM) through 12.2BL2. It is a cross-site scripting vulnerability in the /goform/edit_lf_get_data lf parameter via GET or POST. NOTE: the vendor has stated "We do not consider this a vulnerability."