Author: Dr. Philip Cao

At 06:47 PST on May 20 Palo Alto Networks WildFire detected the start of the latest Kuluoz spam campaign. The total number of e-mails detected quickly rose to over 30,000 per hour around noon PST and had not begun to slow down as of 1:30PM PST.

 

Kuluoz is a descendant of the Asprox malware and spreads by sending copies of itself as an e-mail attachment. As the malware infects more systems, the systems begin sending more e-mails which leads to more infections. Kuluoz makes money for its owner by installing other malware, such as crimeware or fake antivirus programs.

Kuluoz e-mails often trick the reader into thinking they are delivery notifications (such as UPS or Fedex), or notices from airlines or payment processors. In this case the e-mails claim to contain a document about a court case.

Subject: Hearing of your case in Court
From: Notice of Appearance

Pretrial Notice,
Please, download the copy of the court notice attached herewith to read the details.
Note: The case may be heard by the judge in your absence if you do not come.

Truly yours,
Clerk to the Court.
Olivia Smith

Each e-mail carries one of the following attachments:

• Court_Notice_May-20_Date_IN-FN_2014.exe
• Court_Notice_May-20_Date_EN-RM_2014.exe
• DC_Court_Notice_ER_NSER[4 Random Numbers].zip

These attachments are different versions of the malware that has been packed to evade antivirus engines. Twelve of the 53 scanners on virustotal.com now detect the first variant of the malware, but only three detect the latest version.

To determine where the highest number of infected nodes are, we mapped the sending IP address for each of the attach e-mails to their rough geographic location. While there are infected systems around the world, the largest concentration is in North America, particularly the United Stats and Canada.

Geographic Distribution of Koluoz Spam Nodes in North America

Thus far we’ve detected the following command and control servers in use.

• 192.69.192. 178:443
• 59.106.185. 11:443
• 173.203.113. 94:443
• 69.60.8. 88:8080
• 205.186.156. 218:8080

The network traffic generated by each Trojan uses the HTTP protocol, and despite its use of port 443, is not encrypted with SSL.

As with most fast-spreading malware, antivirus engines will typically begin detecting the files a day or two after the spread has begun. While we haven’t seen any indication that the spam volume has begun to slow down, we do expect the campaign to wind down in the next 24 hours, but a new campaign will probably be close behind. WildFire users can rest assured that they’ll be protected from whatever Kuluoz has in-store next.

[Source: Palo Alto Networks]

Summary: After several major security breaches, is there’s another way to do things?

We do IT differently these days, with users bringing their own devices into our networks, with our apps in the cloud, and our users wirelessly connected — from anywhere at any time. But we still do security the same old ways, with firewalls the mediaeval fortresses guarding the gates around our walled city datacentres.

So how can we rethink the ways we protect our changing IT world? We’ve already started to understand that what’s most important is the data and information we use, not the software, nor even our PCs and smartphones. We’ve started to encrypt data, at rest and in motion, and we’re also ensuring our users and apps work with the least possible set of privileges.

But, as the news headlines show, it’s not enough. With millions of us having to replace credit cards and deal with the fallout from recent major data losses, the failings of current security practices have been put in sharp relief. It’s time to do something different, to move from detecting attacks and clearing up after them, to preventing those attacks in the first place.

In the shadow of those high-profile intrusions, I spent some time with Palo Alto Networks, to try to understand how the security company is going beyond the traditional firewall, and coming up with an alternate way of looking at security.

Detecting malware is a complex piece of the puzzle. It’s no longer a matter of looking for malware signatures — for one thing, malware authors have long been able to create software that changes from download to download, and the targeted malware used by state actors and sophisticated cyber criminals is often designed to penetrate a specific network.

New malware that’s never been analysed won’t be blocked by conventional tools: someone must have been infected and lost data for that malware to be found, analysed and its signature added to the daily download of signature files. And while in many cases that someone is a honeypot system on some vendor’s network, there’s still a chance that that someone is you, and that it’s your data that’s been lost.

The risk may be small, but it’s still a risk: and the higher profile you are, the higher the risk. Home PCs might well be safe with a traditional signature-based approach, but that’s an approach that’s risky for businesses running cloud services, or hosting APIs for their apps.

What’s really important is understanding just how malware works. It turns out that while malware apps differ, the attack paths and methods they use are identical. To monitoring software, a buffer overflow or a SQL injection looks the same; so instead of protecting the operating systems of modern network endpoints, we need to monitor the applications and services they’re using, looking for the signatures of attacks, and blocking those attack paths rather than the malware. That’s the approach taken by Israeli security company Cyvera, recently bought by Palo Alto.

By analysing the attack patterns of thousands of pieces of malware, Cyvera has been able to identify fewer than thirty actual attacks. It’s then able to sit between your applications and those attacks, monitor for suspicious activity, and then block and report the code that’s trying to penetrate your network.

If malware can’t attack, no matter what the underlying code might be, we’re starting to focus on prevention, rather than detection. That’s an important distinction, as it’s an approach that, if implemented at an OS-level, would mean that Microsoft wouldn’t have had to issue a patch for IE in Windows XP, as it would have been protected automatically.

Changing the way we think about protecting our networks from malware changes the game. It lets us focus on understanding the software engineering implications of malware, and allows us to harden the areas of our OSes and software that need hardening by using those common attack patterns as part of our software test procedures. However we shouldn’t become complacent.

Just because malware uses a set of common attack patterns doesn’t mean that they’re the only possible attack patterns: it’s just that they’re the easiest or most effective routes into someone’s network. There are always going to be other ways in; just harder and more expensive. However, by continuing to analyse attack signatures it will still always be easier to prevent attacks than to detect malware and then remediate its effects.

These are tools that can be used alongside next generation firewalls, monitoring for unusual network traffic and unknown applications. Bringing the two together turns security into a proactive, rather than reactive, technology, one that’s much more in tune with modern IT and the rapid changes in how we work. They’re also techniques that don’t need to be associated with physical hardware, and can be implemented as part of the software control plane of a software defined network, or even as virtual machines in a virtualised infrastructure — as Palo Alto Networks is doing in conjunction with VMware.

It’s a brave new world out there, and it’s good to see that the security industry is thinking about how it needs to react, taking advantage of the same new tools and techniques we’re using in our private, hybrid, and public clouds. Now it’s up to us to think about how we can move to preventing attacks on our infrastructure, and keeping that vital data right where it belongs.

Simon Bisson is a freelance technology journalist. He specialises in architecture and enterprise IT. He ran one of the UK’s first national ISPs and moved to writing around the time of the collapse of the first dotcom boom. He still writes code.

[Source: ZDNet]

The chief information officer (CIO) of a large utility provider had decided to move email, file shares, video sharing and the company’s internal web site to the cloud and needed to know the security requirements for this project within two weeks. The organization already had security requirements in place for traditional third-party vendors; however, these requirements were not a good fit for the cloud services the company was looking to adopt.

The director of security at the utility provider approached SecureState, a management consulting firm specializing in information security, with the problem.

Unlike traditional third-party solutions where the vendor is responsible for all, or most, of the security controls in the cloud, there are often cases where the client is responsible for managing and maintaining key security controls. For example, if a company was hosting a homegrown application at a Platform as a Service (PaaS) provider, the client would generally be responsible for the security of the application itself (figure 1). The cloud provider of the PaaS would be responsible for securing the platform and infrastructure supporting the application. However, if a company selected a Software as a Service (SaaS) application, the cloud provider would generally be responsible for all layers of the stack and the client would have very little responsibility or control over the security of the application (figure 2).

With that in mind when moving to the cloud, it is critical to clearly outline who is responsible for each component and have requirements that give the organization its desired level of security while being flexible enough to fit the different service models available from cloud providers.

For this utility provider, the move of these initial four services was part of a larger effort to eventually migrate all corporate IT services to the cloud, so in addition to quickly developing requirements for the applications listed previously, the director of security also needed a way to rapidly assess and categorize future cloud service providers to determine what minimum set of controls should be applied. This system also needed to be flexible enough to support new technology developments as cloud solutions mature. Further, a system would need to be put in place to track and monitor compliance of these key business partners to the required controls.

Building a Framework

To assist with this, SecureState created a program to review, approve and manage these cloud providers. The program was built around a custom cloud security framework (CSF) that the team developed. This framework was comprised of numerous components including:

• Data classification and cloud service provider categorization guidelines
• A control set
• Vendor questionnaires mapped back to the control set
• Federated identity management standards

To create this framework, the team met with stakeholders to gather business, technical and security requirements. The framework leveraged the utility company’s existing security policies, procedures and standards while adding requirements specific to cloud computing environments.

The controls in the framework were broken down by the classification of the data processed and/or stored by the provider (public, internal, confidential and regulatory). Each level added another layer of controls that needed to be present in the environment. To ensure that the controls were properly applied to various cloud models and use cases, a lookup table was created to show who is commonly responsible for managing each of the controls in the framework, depending on what type of cloud service model (e.g., SaaS, IaaS, PaaS) is being used.

Special attention was given to the regulatory requirements related to the data that would be stored and processed by the cloud providers, as the utility company needed to comply with several different regulations:

• North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) standards because the utility provides power generation and transmission
• Payment Card Industry Data Security Standard (PCI DSS) because the utility processes credit cards
• US Health Insurance Portability and Accountability Act (HIPAA) because the utility self-insures its employees for health benefits

Requiring all cloud service providers to meet these regulatory requirements would be onerous, if not impossible. Therefore, appropriate regulatory controls would be applied only in environments that required them.

For example, portions of the utility’s employee health insurance process would migrate to the cloud specifically related to the corporate file share. Because of this, additional steps needed to be taken to ensure that the provider of the file-sharing service could meet the related HIPAA requirements.

Once the framework was completed, the team met with executives at the organization to review the CSF. During this meeting, SecureState conveyed the importance of the framework to the business and outlined how the organization should align to it. Once executive management buy-in was obtained, the framework was adopted for use by all lines of business moving services to the cloud, not just IT. This provided the company with a unified approach to managing the security of cloud services, thus ensuring all corporate data moved to the cloud were appropriately secured.

Managing the Security of Cloud Services

The director of security also needed to develop processes to prioritize, review and track which cloud services were approved for use, as well as a program to manage and track what data were being stored and/or processed by these cloud services. Without a robust program in place, the security department would quickly lose control of where sensitive data were stored and which vendor had been approved or denied.

The SecureState team created an online portal where lines of business inside the utility can enter requests to have potential cloud service providers (CSPs) reviewed. Once a provider is entered for review, a questionnaire is generated based on the type of cloud service used and the data stored and/or processed by that provider. This questionnaire is then sent to the point of contact at the cloud service provider to gather information on what security controls are present in their environment. Once the questionnaire is complete, SecureState works with the CSP and client to snap the cloud service into the CSF. To ensure the lines of responsibility are clearly defined, each requirement in the CSF is assigned to either the CSP or client. Depending on the categorization of the data being stored or processed by the provider, additional testing or interviews outside of the questionnaire may be required to determine which controls are present and to verify that they are properly implemented. A similar process is also followed to ensure that the controls the organization is responsible for implementing internally are present and properly implemented for each new cloud service entering into the environment.

During this review process, risk posed by the proposed solution is enumerated and areas where the solution did not meet the CSF are outlined. Using this information, the utility’s security group can determine if the new solution poses an acceptable level of risk, if the solution would be rejected or if it requires additional controls.

This portal also provides an inventory of which approved cloud applications/providers are currently being used in the environment and any exceptions associated with each provider. Additional reminders are set up to reassess each CSP annually, at a minimum. The depth of the reassessment is determined by the type of data processed or stored by the provider and any control exceptions granted.

Lessons Learned

Since implementing the CSF, the utility has applied it to four initial cloud services and a handful of subsequent providers. While applying the framework, a number of lessons were learned:

1. Getting in front of the providers before the contract is signed to gain the full support of the providers. The utility had a large challenge applying the CSF to the initial set of vendors, as the contracts with these vendors had already been signed by the time security was brought in to review them. Because of this, the team had little leverage to get the vendors to make changes to their environments to meet the utility’s security requirements.
2. Ensuring the use and completion of the utility’s questionnaire. Many of the providers preferred to provide third-party audit reports such as Service Organization Control 2 (SOC2) reports or self-assessments such as the Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ) instead of completing the utility company’s questionnaire. In these cases, the team would map the results back to the framework manually. Unfortunately, in most cases the information provided in the SOC2 report or CAIQ did not contain enough detail and further interviews and assessments were required to fill in the gaps. These processes ended up taking longer than initially planned. As a result, it was determined that this process would go more smoothly if the questionnaire was completed first. Thus, the team focused on streamlining the questionnaire and warned the project team that if the vendor did not complete it, the time required to review the vendor would lengthen, possibly impacting the project timeline. With this concern in mind, often the line of business could pressure the prospective providers to complete the questionnaire.
3. Prioritizing provider assessments based on services provided. Follow-up interviews and assessments took longer than initially planned, and a method to prioritize service providers had to be developed to ensure high-priority service providers were assessed first. In some cases, lower-priority providers that housed only public data received minimal follow-up interviews and assessments. This was done to ensure that providers could be reviewed and approved quickly with the resources available.
4. Educating the line of business on the cloud provider review process and following that process. Large projects that went through the company’s central procurement, or project management, office were easily flagged for provider review. However, many smaller projects that were initiated by the lines of business were small enough that they did not require involvement from these groups. Therefore, the security team did not hear about some smaller projects until they were fully implemented and, in some cases, had been in operation for a few months. To address this, the security department now makes a concerted effort to reach out to all lines of business to educate them on the process while working to quickly review new providers so this review is not a bottleneck in the process.

Conclusion

By pulling together the right team, the utility was able not only to address its initial problem of providing security requirements for the first group of vendors, but also to develop a solution to manage future cloud vendors. This solution allowed the utility to quickly and easily review future providers and also provide a program to manage them, thus ensuring corporate information stored in-house or in the cloud is protected equally.

The best way to start this process in any organization is to inventory the existing cloud services already in use. Many organizations have already started to leverage cloud services, often without audit, IT or security’s knowledge. By generating an inventory of which service providers are currently being used and what data are being stored or processed there, the organization can get a handle on what corporate data may be underprotected in these environments and use this information as leverage to start its own internal project to create a CSF for the environment.

Matthew Neely is the director of strategic initiatives at SecureState (www.securestate.com). Neely uses his technical knowledge to lead the Research & Innovation team to develop threat intelligence tools and methodologies for the challenging problems of the information security industry. Previously, he served as SecureState’s vice president of consulting and manager of the Attack & Defense Team. With more than 10 years of experience in the area of penetration testing and incident response, Neely brings the ability to think like an attacker to every engagement. He uses this skill to find creative ways to bypass controls and gain access to sensitive information. Prior to working at SecureState, Neely worked in the security department at a top-10 bank where he focused on penetration testing, assessing new technology and incident response.

[Source: ISACA]