Focus First on Mobile Threat Defense (MTD) or Endpoint Detection & Response (EDR)

A reality of corporate life is economics, defined as the allocation of scarce resources.  So, with finite budgets, what is an IT shop to do regarding malware protection outside of the data center?

While the prevailing opinion is that traditional anti-virus (AV) no longer works for contemporary threats, and the fact that mobile device management does not handle malware, EDR stands as the apparent silver bullet.  However, most EDR solutions do not extend to the mobile space, and due to that a MTD may be the better investment to embark on first for a distributed enterprise.

Additional decision points include: industry, allowance of local admin rights, how distributed is the enterprise, usage of local drives vs EDM / ECM (e.g., SharePoint, network file shares), and the global network topology.  

HIDS vs ATP vs Sysmon(d) vs EDR

While contemporary analysis shows that traditional anti-virus is becoming less and less useful, the question then becomes what next?

Well, for endpoints EDR makes sense, but what about server systems?

The answer to that depends on the industry & threats present to those server systems.  With that said, Sysmon(d) should be the lowest common denominator, w/ advanced threat protections (ATP) added for good measure when an organization has a (relatively) flat network.

If an organization has not invested in EDR & ATP, & realizes an enhanced level of risk, then a host-based intrusion detection system (HIDS) would be needed.

App Delivery Controller (ADC) vs Load Balancer

ADCs are load balancers on steroids (SSL offloading, enhanced compression / bandwidth utilization, WAF, reverse proxy, DDoS protections), while dedicated load balancers perform pure round robin transaction sharing.

For cloud-based apps, elastic load balancers (ELB) maybe consumed as a dedicated service (along w/ separate services: WAF, reverse proxy), while on premise Web apps should be leveraging an ADC for pure consistency & economy of scale reasons.

How Many Threat Intelligence (TI) Feeds Are Enough?

MSSPs aside (as they can more easily achieve economies of scale), how many TI feeds should an internal SOC leverage?

Well, that depends on the quality of information.  With that said, several open source & commercial / subscription feeds would not hurt for cross-reference purposes.

Here are some feeds worthy of consideration:

• US-CERT
• CTIN
• Optiv
• Facebook ThreatExchange
• Crowstrike
• AlienVault
• SSLBL
• ZeuS Tracker
• Palevo Tracker
• Malc0de
• Binary Defense Systems
• Carbon Black / Bit9
• ThreatQuotient
• Anomali / ThreatStream
• ThreatConnect

ICSA, UL, CC....oh my! Do product certs mean anything?

Many (e.g., ISC2) certified pros will know CC (Common Criteria) for U.S. federal govt systems, but ICSA Labs (Verizon) & UL (Underwriters Labs) provide CC-like ratings too.

Who cares?  Well, these certs can be a benchmark, though many products that have achieved C&A ratings have been found to have backdoors.  So, they're imperfect, but better than nothing.

RASP or No RASP

Many orgs these days, especially regulated one's (and most are regulated), use some type of (dynamic) application security scanning tool (DAST: Qualys, Acunetix, WhiteHat) for Web application security.

With that said, fewer use edge protection solutions (e.g., WAF, DDoS) to "Band-Aid" findings, and fewer use static analyzers (SAST: CheckMarx, HPE Fortify, IBM AppScan) to find problems before they go to QA or into production.

So, a while back firms like Prevoty & HPE (& others now, like Immunio) have launched runtime application self-protection (RASP) solutions to further protect Java & .NET applications.  But what about Perl, Python, MEAN, LAMP, etc.? 

That's where an argument against RASP comes in.  At the end of the day, a solid secure development lifecycle (SDL), and existing investments should help negate the need for RASP.  Though, many orgs struggle to fix legacy bugs, let alone to fix w/in an acceptable remediation window.

Therefor, RASP, or no RASP, solely depends on the technology stack & time to remediate.

IoT Architectures & Solution Providers

As IoT gains steam towards critical mass & orgs look to embrace it, mgmt. must ask how to deploy it properly (e.g., design patterns: http://www.internet-of-things-research.eu/pdf/Converging_Technologies_for_Smart_Environments_and_Integrated_Ecosystems_IERC_Book_Open_Access_2013.pdf) & whom to leverage for SME-based services.

Amazon, Microsoft, & Cisco (among others) have now rolled out IoT mgmt. svcs; so, who to use?

Well, if an org has a considerable investment in one of these providers then go ahead & continue on.  But, if not, the question begs who do we leverage for authentication?  If an org has Cisco ISE deployed already, then leverage that.  Otherwise, stay w/ a cloud solution.

Integrated Crypto (e.g., TDE, DDM) vs Enterprise Crypto / PKI

While it may be convenient to deploy integrated crypto / PKI solutions for sensitive data stores (e.g., PII, ePHI, PKI) via TDE / DDM, more and more data leaves local databases and / data stores & goes to the cloud.

This is where an enterprise PKI solution will help organizations.  With holistic solutions, a tokenized, sensitive data element can proliferate / travel through the cloud or w/in an enterprise while still protected.

While expensive, highly visible, and risky, these endeavors will truly protect an organization from data breach / loss, etc.

Why Enterprise DLP Solutions Will Go Away

Large, traditional, enterprise DLP deployments will go away as organizations look to leverage multiple, integrated DLP solutions.  The reasons for this include:

• A focus on cloud & mobile solutions, & a migration away from on premise
• Consolidation of vendor solution capabilities (e.g., CASB, DLP, DCAP, RMS, DMARC, SPF)
• Portable / interoperable policies / rules (e.g., SCAP, CTP)
• A focus on agile deployments
• Cost / economies of scale

In essence, DLP will parallel HR-based ERP modules that have recently been migrated from on premise to SaaS solutions.

With that said, the real question is what else will be migrated away from on premise?