Home > Blog > Recent Blog
What to do with Threat Intelligence (II)
Posted on 5/7/2013 by Justin Hall - CBTS Security Architect

This is the second article in a series regarding security threat intelligence.

To be sure, security intelligence isn’t easy for a new or under-resourced program to undertake - but it’s far from impossible. Let’s look at where to start.

First, decide how deep you want to be.Those looking to simply gather threat information and make informed risk management decisions could take a very simple approach, choosing to focus on, for example, high-profile data breaches against others in their industry.

Some organizations may be ready to monitor their environment for specific technical indicators; others may want to begin with more general behavior. Financial institutions might look for patterns of transactions that indicate fraud. Manufacturers might use data loss prevention (DLP) tools to monitor network traffic for theft of intellectual property. Software developers might set up search engine alerts to see if their source code has been posted online.

If looking for technical identifiers is within your capability, it might be good to start with a limited scope in mind. Do you want to examine network traffic? Are you most interested in one specific protocol or application - just email or web traffic - or more? Would you limit yourself to a certain location on your network, such as the internet perimeter or the DMZ? Maybe you want to monitor endpoint systems - but just critical servers? Eventually, you might expand to user workstations or mobile devices.

Next, choose your sources of data. How will you learn about the threats that could affect you? The low-hanging fruit in this step comes from news headlines. When a breach hits the front page of the New York Times, scour the article for technical details. How did the attackers gain access to the data? What tools and techniques did they use? When the Times doesn’t have the information you need (they probably won’t), search further, or find the company that discovered the breach. As you read about the attack, ask the question, “If this happened to us, how would we know?”

Security researchers often discuss new and interesting attack techniques, online via social media or industry publications, or at conferences like Derbycon (www.derbycon.com) and Blackhat (www.blackhat.com). A few hours at a conference will leave you with more than enough threat intelligence to worry about for the next few months! The trusted reputation of the researchers you choose to listen to is key for the credibility of this source.

Collaboration has become more common. Security and technical staff from peer businesses - even competitors - in some industries have formed casual birds-of-a-feather relationships that meet regularly to share intelligence. This might include recently seen attack techniques (“check out this phishing email we just got hit with”) or even breach details (“they raided our source code repository to find all the bugs in the application we’re working on”). Hesitation to share and mistrust of peers has begun to give way to a “united we stand” approach that has been extremely effective - especially in the financial services and defense industries.

Law enforcement may also have useful information about recent attacks they’ve investigated. While sharing specifics about the target organization is typically frowned upon, they may be willing to reveal how attacks happen and key indicators to watch for.

Internal research is probably the most effective way of obtaining threat intelligence. As attacks occur, security research teams will review the details of each tool or resource used by the attacker, and document it for future use. The documentation would include network identifiers, such as command and control hosts or protocols used; host-based identifiers, such as common storage locations for tools or registry keys left behind; or descriptors of binaries that would be obtained from reverse engineering malware, such as a common code-signing certificate or imported library.

It will be helpful to prioritize your data sources. You may consider certain sources, including peer intelligence or internal research as more trustworthy than others, such as public research.

Then, determine how you will track your intelligence.It should be stored in a secure location accessible only to the security staff that uses it; but it should also allow for easy collaboration and use by the organization’s tools. Common storage systems range from low-tech spreadsheets to password-protected wikis.

Noted security research firm Mandiant has pioneered an open standard called OpenIOC (IOC standing for Indicators of Compromise) to describe technical threat identifiers. This standard enables you to write simple or complex descriptors in a file. This file can be edited using their IOC Editor. Endpoint systems can be reviewed to see if IOCs are present with their IOC Finder tool. Both of these tools and the schema can be downloaded for free from the www.openioc.org website.

Threat intelligence does require some care and feeding. A process to decommission intelligence that is no longer useful or stale should be implemented - otherwise an organization’s database will quickly grow too large to be effective. You may consider eliminating indicators after a certain period of time, or a set number of weeks or months after its last detection in the environment.

What is Threat Intelligence - I
Posted on 2/11/2013 by Justin Hall - CBTS Security Architect

This is the first article in a series regarding security threat intelligence.

If there’s one thing in which the security community is exceedingly proficient, it’s in pushing forward new buzzwords. Security Intelligence is the latest. Spend any time reading vendor blogs or magazines targeted at CISOs and you’ll hear about this “must-have resource” that will “transform your security program”. Unfortunately few truly understand what security intelligence means and how it might be incorporated into an organization’s systems and data protection strategy.

We think of security intelligence as information that contributes to the security posture of an organization. At its core, we are talking about data. It is also necessary to consider the processes by which an organization acquires this data, uses it, and shares it. This paper focuses on the idea of threat intelligence in the broad discussion of security intelligence. Threat intelligence is information about the human and machine-based attacks, and attackers that could adversely impact an organization.

Most organizations have some form of threat intelligence employed already - they simply don’t recognize it as such. An antivirus client, for example, uses intelligence - the millions of patterns that describe malicious files. This data is typically only known to an anti-virus vendor, and isn’t made available to customers.

An intrusion detection system uses signatures to flag a packet or stream of network traffic as harmful. A mail filter blocks specific message content or blacklists messages sent from a mis-configured MTA that freely relays spam messages.  A web content filter uses categories to prevent access to malicious websites. All of these are examples of threat intelligence.

Securing BYOD Environment
Posted on 1/9/2013 by Justin Hall - CBTS Security Architect

The BYOD (bring your own device) trend poses many security challenges to enterprises. CBTS recently helped a regional energy company serving millions of customers secure their BYOD environment.

The customer was facing a challenge of securing a host of emerging computing devices that included iPhones, iPads, and Android-based phones, mobile devices owned by the company and others by employees. Internal IT staff was tasked with ensuring that company data, including confidential customer information, as well as sensitive internal material, would not be exposed if a device was lost, stolen, or otherwise compromised.

A security assessment team from CBTS engaged with the customer’s security and technical staff, to discuss how mobile devices were being used. The team examined the various uses for each platform, the applications and data each would interact with, and the concerns of executive leadership. The team also explored the customer’s existing mobile device policies and the controls currently in place, as well as the regulatory and compliance requirements to which they were subjected.

Using a set of widely accepted industry best practices, the assessment team developed recommendations for stronger controls that would mitigate the risk of a breach from a mobile device. The team illustrated how to implement these controls using the mobile device management tools already employed by the customer. The team also recommended organizational policy changes that would foster greater awareness to mobile device users of their responsibility to protect company data.

The CBTS team deployed on the project had hands-on experience with industry-leading mobile device management solutions, as well as extensive research into mobile threats, and the controls and defenses that protect the data stored on them. This gave the team a unique perspective into this rapidly growing domain of enterprise security.

With stronger policy and more comprehensive controls, the customer was able to harden existing devices and streamline the process to secure new ones. User adoption of the additional controls was faster and more efficient, with greater visibility into the mobile threat landscape leading to buy-in at the executive level. Security staff was also far better equipped to handle a mobile device breach.

Planning Your UC Strategy
Posted on 12/21/2012 by Craig Chavis, Solution Architect, CBTS

The following is a list of questions to help get you started with the process of determining your business requirements, your current state, and your current organizational skill sets. This is not a complete list, but it is a starting point to clarify solution requirements for your particular situattion. 

  • What business needs may require a possible UC solution?
  • What are the business use cases?
  • What capabilities do my existing vendors provide to meet the use case requirements?
  • What capabilities do other vendors provide to meet my business use cases?
  • What UC application licensing have you already purchased from your current vendors but have
  • not implemented?
  • Can you leverage the existing investment to meet your business requirements?
  • What capabilities does my internal IT staff have for supporting UC?
  • What is the investment required to acquire and/or expand the applications and/or infrastructure to deploy UC?
  • What is the investment needed to build IT staff skill sets to support UC?

CBTS is a premium UC product reseller and solution provider. Our certified engineers deliver value-added UC solutions by helping our customers design, configure, deploy, and manage their communication environment. We provide complete skill sets and experience from implementing UC solutions for enterprises to help your organization achieve the potential UC benefits.

UC Solution Challenges
Posted on 11/26/2012 by Craig Chavis - CBTS Solution Architect

UC can offer great benefits; however, you must work through some challenges to realize them. Some of the current challenges with UC deployments include: interoperability between different vendors’ applications deployed in your environment, consumerization of IT, support model, and security.

Interoperability

UC has evolved just like voice applications. Vendors have picked from a variety of standards to implement their UC solutions. This results in many disparate systems and devices, making the implementation of a single solution a challenge.

Interoperability complexity is driven primarily by the following factors:

  • What standards did a vendor choose when they went to market?
  • How mature are the vendor’s offerings across the UC product and service suite?

Applications

Many businesses have deployed applications to address a specific need, such as: desktop application, telephony, or video.  In many cases those applications come from multiple vendors.  UC promises to tie these applications together to increase productivity and efficiency. When choosing applications, the following issues must be addressed:

  • What current application investments can you leverage to deliver the best UC experience in the most cost effective way across your computing devices?
  • What possible new application investment do you have to make to cover UC functionality gap requirements?
  • What is your potential application investment that you may be forced to make to meet a specific business need?

Consumerization of IT

The continuing consumerization of IT adds to the challenges of how you integrate business-provided devices and end-user-owned devices with UC applications. At the same time, your business has to ensure the security of critical business and customer information.

Support Model

UC promises to deliver increased productivity, efficiency and potentially reduced costs. What does that mean to your technology support model?  Do you have the skill sets to support it?  If not, does your existing staff have the ability to learn how to support it?  If the answer is no, what compensation is required to acquire the skill sets to support your UC solution?

Security

You have the potential of introducing two way customer communications via chat and video.  Depending on your industry, you may have a business or regulatory requirement to record all two way customer communications.  Now layer that on top of a wireless network for mobile users. It creates a confusing and challenging set of criteria, with which you develop a UC solution that works, but also protects the most critical business and customer information. 

CBTS > Solutions