The year 2014 has been dubbed “The Year of the Cyberattacks” before it even reached the halfway point, with aftershocks fromHeartbleed still being felt weeks later. But did you know that attacks and bugs like Heartbleed are often 100 percent preventable? Simply put, best IT practices can create red flags before damage can be done. But, when humans are involved, laziness and shortcuts can lead to missed security steps. Technology, of course, is programmed and designed by humans, so the possibility forhuman error in technology is everywhere.
And it is not just human fault here, but also the technology. This is a two-pronged fork. According to security expert Richard Kenner, programs should never read from the same place in memory where they were written. That is security safety 101, but that is exactly what happened with Heartbleed. It has already been estimated that millions of dollars are being paid out by enterprises affected by Heartbleed, but what lessons can be learned from this?
Technology: Not as cutting edge as you think
Kenner points out that the programming language involved in Heartbleed is more than 40 years old; and even though new languages have been developed (and are arguably safer), that doesn’t mean they have been adopted. In addition to keeping up with languages and improving upon them, best practices simply were not followed in order to stop Heartbleed. There is technology available that ensures programs meet key properties (like that pesky reading from memory writing issue), but most companies fail to utilize it.
“The program that contained the Heartbleed bug did exactly that and an attempt to prove that it didn’t would have quickly found the bug, as would the use of certain tools that also detect this type of error,” says Kenner.
There are also other best practices, such as ensuring that security services do not transmit private information like passwords, usernames or identifiers. That sounds like a given, but it is (unfortunately) common practice.
Moving forward
Lessons to be learned from Heartbleed include: Creating safer passwords, changing them regularly and only using one password per web site. Additionally, web sites need to make better use of one-time passwords, which can be annoying but can prevent information from being hacked.
I advise using client certificates, even if they are a bother to acquire, because they are proof that you really are who you say you are. Many of these precautions can take a little extra time, and time is notoriously what many professionals do not have.
Perhaps the biggest flaw that led to the Heartbleed outbreak is that only a small handful of executives, far from experts in technology and security, were put in charge. They had full plates, they did not understand what was at stake, and they too easily put this task on the back burner.
When a small group of people assumes someone else is taking care of things that open up a world of vulnerability. It all comes back to proper management at every level and better communication between IT and the rest of the staff to make sure everyone is on the same page.
Data breaches and cyberattacks are becoming more and more common, causing many organizations to increase their spending on cybersecurity. But even with an increased security budget, cyberattacks continue to put important business systems at risk. To help overcome this problem, US President Obama issued Executive Order (EO) 13636, Improving Critical Infrastructure Cybersecurity, calling for the creation of a voluntary, risk-based framework for improving cybersecurity. In response to the EO, the National Institute of Standards and Technology (NIST) led the development of the Cybersecurity Framework (CSF). Input from industry, such as owners and operators of critical infrastructure, was a significant part of the development. Many organizations recommended ISACA’s COBIT as a good example of a cross-sector security framework and guideline that is technology neutral and addresses cyber risks. Since its release, organizations have been able to use the CSF to help them implement security measures. The new ISACA guide on Implementing the NIST Cybersecurity Framework helps organizations in this process by describing how to use existing ISACA methods to effectively implement the CSF.
As a participant in the development of the CSF, ISACA helped incorporate key principles from the COBIT framework. Since these COBIT principles are embedded in the Cybersecurity Framework, organizations can use COBIT processes to seamlessly and effectively implement the CSF. Though the CSF does not recommend specific methods to meet the intended objectives, the ISACA guide acts as an extension to the CSF, providing recommended methods for applying CSF concepts. Specifically, the ISACA guide aligns to each CSF step, and provides organizations with COBIT activities and processes that can be used when implementing the CSF. Additionally, ISACA provides a toolkit containing templates for planning, assessing and recording CSF activities. Because the COBIT processes suggested in the ISACA guide have been proven through years of ISACA success, this approach provides organizations with an effective, measurable way to implement the CSF, and improve their cybersecurity program.
As directed by the EO, the CSF provides a prioritized, flexible and cost-effective approach to address cybersecurity. Applying that framework using proven ISACA methods will help you enable your enterprise to achieve effective governance and management, which benefits its stakeholders.
PCI DSS version 3 is an improved ballast for addressing the protection of cardholder data. Version 3 deltas from previous versions focus on providing a stronger understanding and clarity of the intent and application of PCI DSS test procedures and on driving more report consistency among PCI QSAs. They also provide flexibility to merchants and service providers in the implementation and assessment of the PCI Data Security Standard. Clearly these are noble and much needed revisions; however, a pragmatic look to PCI DSS v3.0 might help us better see its application.
PCI DSS changes in version 3 focus on five major areas:
Penetration testing
Inventory of system components
Service providers
Evolving malware threats
Physical access and point of sale
Penetration Testing
Currently, there is no universally accepted industry standard for penetration studies. Although required by PCI DSS v3.0, the quality, approach and reporting of the pen tests are subjectively reviewed by the QSA and entity being assessed. Despite this, PCI DSS v3.0 requires the development and implementation of a pen test methodology.
11.3 – Clarifies requirements for annual internal and external network penetrations tests, and application-layer penetration tests.
11.3 – New requirement to develop and implement a methodology for penetration testing. Effective July 1, 2015. PCI DSS v2.0 requirements for penetration testing must be followed until then. This means a penetration test of the CDE must include the analysis of card data flow in electronic form on any system within the CDE and any connected systems.
11.3.4 – New requirement, if segmentation is used to isolate the CDE from other networks, penetration tests are to verify that the segmentation methods are operational and effective. This is an interesting one since typically, pen testers have a modicum of knowledge of the environment pen tested. To test segmentation, they now need to know more.
Inventory Systems Components
PCI DSS has always required that entities maintain an inventory of their equipment, software, applications, databases, URL sites, input devices and PAN data storage locations. However, v3.0 is now asking for additional information.
11.1.1 – Maintain an inventory of authorized wireless access points including a documented business justification.
12.3.3 – Verify that the usage policies define a list of all devices and personnel authorized to use the devices.
Service Providers
In addition to maintaining a list and agreement from service providers to comply with PCI DSS in handling entity cardholder data, version 3 is asking that entities provide proof of compliance and a process to monitor (at least annually) compliance, such as the service provider’s Attestation of Compliance (AOC). This includes maintaining information (12.8.5) about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. Effective July 1, 2015, service providers will be required (12.9) to acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Evolving Malware Threats
Version 3 now states that entities must evaluate evolving malware threats for systems not commonly affected by malware (5.1.2). This includes mainframes (z/OS), mid-range computers (such as iSeries, Tandem, etc.) and similar systems that may not currently be commonly targeted or affected by malware. The mainframe and mid-range computing environments have long since and continue to be a critical PCI DSS cardholder environment (CDE). Unfortunately, QSAs that truly understand z\OS, virtual storage protection, RACF\ACF2\TopSecret internals are few in number. Threats to CDE and CHD in these environments are much more expansive than malware but a good start.
Physical Access and Point of Sale
Physical access controls of in-scope office locations, data centers, storage sites and retail store locations are standard in PCI DSS assessments. Version 3 is now requiring that entities protect (9.9) devices that capture payment card data via direct physical interaction with the card from tampering and substitution. This new requirement will be a challenge at retail stores, onsite merchant locations, gas stations, etc. Corporate offices will be easier to handle but where there is no badge access, changing door locks whenever an employee terminates might be an expensive proposition.
Maintaining an up-to-date list of devices (9.9.1) by make, model, location and serial number sounds reasonable. However, effective 1 July 2015, this new requirement to protect point-of-sale devices (9.9.2) will require periodic inspection of device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). Admittedly this is a great idea, but we need to understand that now retail personnel, typically hourly employees, will need to be trained on how to detect device tampering.
Summary
This past year has taught us a major lesson. Malware infections, state sponsored attacks, APT, including the not-so-talked-about internal frauds, will continue to happen with increased frequency, many of which could be avoided with prudent deployment of controls. Admittedly, PCI DSS will not prevent such occurrences, but if properly deployed is an effective mitigant that seemingly improves with every version.
Blog size limitations preclude further comment on noteworthy version 3 changes, but overall they appear to provide for better CHD protection. The five major changes listed here are to raise awareness and possibly postulate on the preparatory work needed for version 3 compliance. There are clearly some challenges that will arise, but none that would prevent us from formulating proper remediation and compliance.
Miguel (Mike) O. Villegas, CISA, CISSP, CEH, GSEC, PCI-QSA, PA-QSA, ASV
Vice President, K3DES LLC
Improvements in security education, budgets, tools, and methods will help our industry avoid more costly and dangerous attacks and data breaches in the future.
The bad guys are winning. Numerous companies have been in the news recently because they failed to rebuff information security attacks. Target lost its customers’ credit and debit card data. Adobe lost its customers’ credit card information, along with IDs and passwords. EBay lost its customers’ personal information, including email addresses and physical addresses.
These breaches have caused disquiet in the minds of consumers and cost the companies themselves millions of dollars’ worth of bad publicity and damage to their brands, not to mention the costs of mitigation and restoration. And the breaches we know about could just be a fraction of the incidents. Companies have to disclose breaches of consumer data, but not the theft of their own internal information.
As long as there is valuable personal information at risk, hackers will try to access it, whether the goal is the immediate use of stolen financial data, the long con of identity theft, or just causing pain to companies and their consumers.
Unfortunately, there is a growing skills gap between those out to do harm and the average defender. Until the information security workforce catches up, we will continue to see the increasing success of sophisticated attacks. However, there are important steps the information security industry can take to slow and even reverse this trend. Here are four key areas to get you started:
Everything starts and ends with education
Education and research need to be improved at the college and university level to improve the skills of future information security professionals and to grow the number of individuals qualified to enter the workforce. Once those security professionals — the front line against malicious attacks — have been hired, employers need to invest in their continuing education and training in order to stay ahead of ever-changing security threats. Only such educated individuals will be able to predict the next wave of vulnerabilities and attacks, and design ways to combat them before they develop into a crisis.
Be smart about spending
It is crucial to make the most of our limited security budgets. With more and more critical data touching the Internet, increasingly well-funded cyber criminals have their choice of targets. High-profile companies are always going to be attacked, but small-and medium-sized businesses are now being targeted as low-hanging fruit. Though the rewards might be smaller, there’s a high probability of success and a low probability of being caught.
As an industry, we need to focus whatever security budget is available on the most likely threats. Though all companies must be aware of common threats like APTs and DDoS attacks, one of the biggest threats to us all is the under-educated employee. Whether it’s an executive who falls prey to social engineering or an IT guru who chooses not to use the best network configuration techniques, we often open ourselves up to preventable attacks.
Involve application developers
Increased security has a reputation for hindering an application’s usability, and as time and budget constraints work against the developers, security requirements get squeezed out of software development. There is a massive difference in building a computer application and building a secure computer application, though. Despite the immediate price tag, building security into an application up front is rarely more expensive than trying to make adjustments once the application is built, or cleaning up the mess once a vulnerability is exploited.
Get management to buy in
Even when the security pros are aware of what needs to be done, they can have trouble convincing management to allocate the resources to do it. We need to improve our ability to make a business case for better tools and better training. If you can’t talk “dollars and sense” to your CFO or budget analyst and navigate office politics, you won’t get anywhere. Part of improving education is improving a security professional’s awareness of not just the theoretical importance of security, but security’s return on investment. When you can show executives specifically how security can save the business money, or even save their jobs, you are now speaking their language.
The very public breaches of the past year have caused a lot of damage to companies and individuals, but perhaps they have been a blessing in disguise. If these cyberattacks serve as a wake-up call to the security industry and the businesses we support, precipitating an improvement in our education, budgets, tools, and methods, then we may be able to avoid even costlier and more dangerous breaches down the road. Lost passwords and credit card data will be the least of our concerns if cyberattacks become the weapon of choice in nation-state attacks or ultimately damage the country’s critical infrastructure.
W. Hord Tipton, CISSP-ISSEP, CAP, CISA, CNSS, is currently the executive director for (ISC)2, the not-for-profit global leader in information security education and certification. Tipton previously served as chief information officer for the U.S. Department of the Interior for over five years. Mr. Tipton can be reached athord.tipton@isc2.org.
Researchers take advantage of cloud service providers’ free trials and lousy anti-automation controls to use cloud instances like bots.
LAS VEGAS — Black Hat USA — Thrifty attackers, are you tired of investing your dollars in a botnet that’s constantly being disrupted by new anti-virus signatures and bot downtime? A “cloudbot” might be just what you seek. As shown at Black Hat last week by Rob Ragan and Oscar Salazar, senior security associates at Bishop Fox, cloudbots are entirely free and very resilient, and they offer all the uptime of a cloud service with no need for malware. Good news for bot masters working on the cheap.
Bad news for cloud service providers that use poor anti-automation measures. As Salazar and Ragan showed in their Black Hat session, “Cloudbots: Harvesting CryptoCoins Like a Botnet Farmer,” confirming registrations with email alone is not enough to prove a registrant is a unique human. Without adding captchas, SMS verification, or other anti-automation measures, online services could find themselves powering activities like cryptocurrency mining and denial-of-service attacks.
The researchers specifically went after free cloud services — or those with free trials — that host infrastructure or development platforms.
“We were able to gather thousands of those [services’] accounts and control them just as a botnet herder would control a traditional botnet by spreading malware,” Ragan says in an interview with DarkReading. “We were basically able to register a bunch of free trials and have control over these accounts… and build a system — a framework, if you will — for targeting online services.”
How it’s done
As Salazar explains, they begin by using Google App Engine’s inbound mail handler, which transfers mail into a POST request that Google posts to a user’s web server. Using that, they were able to receive email as though it were a POST request coming from anybody’s browser and then “scrape the content” from the email.
“We look through the body of the email and look for URLs — [cloud service] activation links, essentially,” Salazar says. “And from the service itself, we request the activation link. Instead of having to go click on it ourselves, it gets automaticaly requested for us by our application.”
Then they headed to FreeDNS.afraid.org and created a wide variety of subdomains, for free, using domains donated by generous souls. Using FreeDNS, they were able to register MX records, which are used to point servers to mail.
After that, they use yet another cloud service that converts email into an adjacent object and pastes it back to the server.
“So, using that full setup, you go to a website you want to sign up for [and] type in an email address containing a random local part” and a domain registered from FreeDNS, says Salazar. “As soon as we click ‘activation’ on the submit link, an email is sent. But we’re not receiving the email; our application is receiving the email and is clicking the registration link for us. At that point, we don’t need to do anything at all.”
For the purpose of their proof-of-concept, Ragan and Salazar used this process to create 1,000 accounts at roughly 150 services — small companies, startups, and some third-party resellers of bigger cloud providers — and gathered more than a terabyte of free storage. They could have made it much bigger. According to the researchers, the script can be run as often as they like, so the size of the “cloud botnet” is limited merely by the amount of effort one wants to put into registering new instances.
“Gather enough of them,” says Ragan, “and it’s a supercomputer for free.”
Benefits for the attacker
A cloud botnet is undoubtedly economical.
“All that we really required to build this was a low-end laptop, a browser, and an Internet connection,” says Ragan. And, of course, the “bots” themselves were free.
Plus, they’re simply higher quality than your average bot. They’re powerful, energy-efficient, resilient, and nearly always available.
“All these [cloud] providers have low-latency, high-bandwidth, high-availability Internet connections,” says Ragan. “Their whole business model is that [they’re] online and available 99.999% of the time. And that’s a lot different than a botnet that works off personal home computers that may go offline at the end of the night or might have a slow DSL connection.”
“A lot [of cloud services] let you shut down the instance while you didn’t need it,” says Salazar. “So essentially it would be like a sleeper bot. It wouldn’t be using system resources when you didn’t need them, and [that would] make it a lot less likely to be identified.”
They made other efforts to avoid detection, as well. They could create accounts on one cloud service provider and use it to launch attacks on another, avoiding the need even for Tor exit nodes or VPN endpoints.
“Also, we didn’t have a central point of command and control,” says Ragan. “We leveraged a Python framework called Fabric, which is designed for system administrators to manage a datacenter or internal service management, and all that’s required is SSH access into like a Linux machine, for example — which is what we were getting from these free cloud service providers. SSH access into a Linux [virtual machine].
“And at that point, we could manage that all with our private keys, and we could launch our scripts and commands from any one of those cloud service providers we had access to. We could move around and be coming from new locations every time we launched a new command.”
Also, though they expect that they did stretch the limits of some terms of service, creating this sort of botnet is not entirely illegal, because no machines are being infected with malware.
Since the botnet does not require malware, it needn’t go through the process of updating code every time an anti-virus provider writes a new signature. Some bots will, however, die when a free trial expires, but those changes are predictable, and the bots can be easily replaced by simply registering more accounts.
However, if attackers did want to use malware in the next stage of an attack, they could simply use their cloudbots’ development environments to do all their coding in the browser, without ever storing it on their own hard drives.
What cloud providers should do
Salazar and Ragan think that bad guys may already have had the same ideas they did. Before they even had a chance to try out their registration script on some sites, they found that some services’ free trials were “temporarily disabled” entirely, and that one of them specifically said that it had been disabled because of suspected abuse by criminal hackers.
“If you have a company and you have to shut down registration,” says Ragan, “that’s money lost.”
Two-thirds of the services the researchers looked at used only email confirmation to fight automation.
“We realized that this was really an antiquated approach,” says Ragan. “That ‘one person equals one email address.’ That’s simply not the case anymore.”
The solution could be introducing more anti-automation technologies like captchas or verification by mobile devices. However, online businesses also don’t want to make it really onerous for legitimate users to complete their registration — because that could lose money, too.
Therefore, Ragan and Salazar suggest that companies might turn on those extensive anti-automation measures only when there is an anomaly. If there are usually 100 registrations per day, and suddenly 1,000 registrations arrive in 10 minutes, then there is a good chance that there is malicious activity. However, instead of shutting down the registration service entirely and closing out legitimate new customers, companies can temporarily enable further account verification measures, thereby combating malicious entities and accepting any new legitimate registrants who have the patience to complete the process.
Another option for small service providers is to use a federated identity solution — letting users register with their Facebook account, for example — and leave all the complicated identity and access management to someone else.
In the meantime, any website — not just cloud service providers — needs to have a closer look at its anti-automation tools and procedures.
“One of the things we wanted to answer is ‘Will we continue to see this as a rising trend?'” says Ragan, “and the answer is undoubtedly yes.”
Sara Peters is contributing editor to Dark Reading and editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad of other topics. She authored the 2009 CSI Computer Crime and Security Survey and founded the CSI Working Group on Web Security Research Law — a collaborative project that investigated the dichotomy between laws regulating software vulnerability disclosure and those regulating Web vulnerability disclosure.
