Home > Blog > Categories > Information Security
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.

Fill the Gap in PCI Compliance
Posted on 10/27/2011 by Justin Hall - CBTS Security Architect

When we’ve invited guests over to our house, I usually spend the afternoon before they arrive cleaning – my wife likes the place to be immaculate. Within a few days, however, our house is just as messy as it was before. According to a recent report from Verizon Business, many organizations behave the same way with PCI compliance. The report (available here as a PDF) states, among other findings, that 79% of businesses examined in 2010 did not meet the PCI-DSS standard, and that most of those that failed the audit were compliant the year before.

The PCI Data Security Standard is a set of tools and metrics for merchants, payment processors and financial institutions to protect cardholder data. It was initially released in 2004 by a council of the major payment card industry members (Visa, Mastercard, American Express, etc.). The current version of the standard is v2.0, released in 2010, and defines twelve requirements that must be met by businesses that wish to process credit and debit cards. So why is it so uncommon for these businesses to remain compliant? It’s a relevant question because you and I want to do business with merchants that take measures to keep our financial data safe.

There are likely various causes for the gap in compliance. Organizations might feel the need to “just get the box checked” – and as a result they act like a teenager cleaning his or her room, covering up the disarray so that it’s just out of sight. It doesn’t take long for the place to get out of order after the auditors leave.

Cost and complexity are also factors. There’s nobody to watch the logs from the new firewall; there’s no money for the annual penetration test this year; the CIO got too busy and didn’t have time to finish updating the company’s security policy.

Properly securing a business can be like training for a marathon. It requires a long-term commitment, doing hard work that doesn’t have an immediate reward, and most of all, it can really hurt.  But remembering our responsibilities – to our customers and their data; to our shareholders and owners; and to our own employees – is key. All of these folks would be adversely affected if a breach were to occur!

The requirements mandated by PCI-DSS aren’t just good for businesses that process or store cardholder data. They’re solid recommendations that can improve the security posture of any organization with critical systems or data to protect. If your organization doesn’t have a formal security program, PCI can be a great place to learn about controls and defenses. Other resources, such as ISO 27002, NIST’s 800-53, or SANS’ Top 20 Critical Controls, describe the steps to start developing the people, process, and technology required to protect your business.

If you are subject to PCI-DSS, don’t stop there! PCI is the beginning of the journey, not the end. After all, organizations that are PCI compliant can still suffer breaches. Heartland Payment Systems, who reported a breach and the loss of millions of records in 2008, was PCI compliant at the time. A comprehensive information security program goes beyond boxes on an audit report – it includes maturity that’s baked into the business at a foundational level, and a culture that cares first and foremost about protecting its data and assets.

Hacker Collectives in the News Part II
Posted on 7/20/2011 by Justin Hall, CBTS Security Architect

What do hacker collectives mean for your business?

Perhaps your response to reading this material has been, “they wouldn’t ever come after us”. Are you certain that no individuals bear your organization – or maybe an employee of yours – any ill will? Some of LulzSec’s targets were chosen simply because a frustrated individual asked them to attack a perceived enemy!

It’s also possible that your organization was inadvertently exposed when an employee used their company email address as their login name when signing up for a service that’s been attacked recently. They may have even used the same password for the service that they use at work! If those credentials were stolen, they are likely in the hands of hackers who may be using them for further attacks.

What actions can you take to protect your organization, either from hacktivists, or any other malicious entities?

  • Check your public-facing systems and applications. When was the last time your Internet-facing systems were examined for vulnerabilities? Have you ever had a web application assessment, which would look at more than just the holes in the operating system or application platform? What about a penetration test, which would gauge your systems’ resiliency against hackers by simulating actual attacker techniques? Many of the recent attacks where data was stolen involved a technique called SQL injection, where an attacker exploits weaknesses in web applications to retrieve normally inaccessible data from a database. This kind of attack has become extremely common, as it’s fairly easy to execute and can typically be done without alerting the system owners.
  • Educate your users. Tell them to never use their company email address, username, or password on systems that aren’t controlled by your organization. Remind them to never reuse passwords on different sites, especially those that store personal or financial data. In the LulzSec attacks, hundreds of thousands of usernames and passwords were disclosed. This is a huge problem if one email address and password could get you into all of the websites you use, including your bank, personal email, or shopping sites like Amazon. That’s like having a single key that starts your car, opens your front door, your mailbox, and your safety deposit box!
  • Monitor your network. Would you know if you’d been targeted by hackers? What would tip you off? Collecting logs from critical systems, or those that store sensitive data, and reviewing it regularly is a must considering today’s threat landscape. It’s not just enough to watch for outages, or even to review logs a few times a month looking for “bad stuff”. Constant monitoring – and investigating suspicious activity in a timely manner – is key!

Hackers aren’t going to stop their attacks any time soon. Organizations that don’t take measures to protect their systems, and that aren’t prepared to respond to a breach, are the ones that end up on the front page. Don’t be the next headline!

CBTS > Solutions