devopsy.kinsta.cloud

Tag: data breach

  • Why Was Facebook Vulnerable to an Authentication Exploit?

    Why Was Facebook Vulnerable to an Authentication Exploit?

    What Happened:

    As part of a bug bounty program, the AppSecure cybersecurity research team found a vulnerability on the authentication mechanism of Facebook. It gave them the ability to potentially gain full control of the social media giant’s more than 1 billion users. The team won a $15,000 bounty for its discovery.

    This vulnerability was found on a niche API, which reminds us that in many cases the most interesting bugs don’t exist on main APIs but on secondary ones that have fewer protection mechanisms in place.

    Anand Prakash, CEO of AppSecure and who was credited with finding the bug, explained what he found: “This gave me full access to other user accounts by setting a new password. I was able to view messages, their credit/debit cards stored under their payment section, personal photos, and other private information.”

    Even though the vulnerability was discovered in 2016, similar weaknesses have been discovered — and in many cases exploited — ever since. Here is a closer look at the Facebook case and lessons to be learned in modern application development.

    Technical Details

    The vulnerability exploited the password recovery mechanism on Facebook. The steps of the process were:

    1. The user starts the “forgot password” process by using their email address.
    2. Facebook sends a text message with a temporary 6-digit secret token to the user.
    3. The user enters the received temporary code, and the browser sends an API call to “POST facebook.com/recover/as/code/” with the secret token.

    Facebook had implemented an anti-brute force mechanism on this API that blocked the user after 10 failed attempts. However, during their research, the AppSecure team found that the same API endpoint existed on different API hosts, under “beta.facebook.com” and “mbasic.beta.facebook.com.” These API hosts didn’t implement the anti-brute force mechanism, allowing the attacker to easily iterate through the secret token and reset the victim’s password.

    Why Current Security Solutions Can’t Detect It

    Keeping track of your APIs it’s not an easy task. Modern organizations might have dozens or even hundreds of API hosts for different environments, regions, or versions. Each API host can expose multiple API endpoints that are related to authentication processes including login, forgot password, and one-time login link. Many security solutions in the market focus on protecting your main APIs and don’t have enough visibility into the less common or less used APIs (such as Facebook’s beta API in the example above). Sophisticated attackers choose to target those niche APIs.

    How Traceable Solves the Problem

    Traceable AI monitors all APIs including the different environments, versions, and regions. For each API host, we automatically and manually detect the authentication endpoints that your APIs expose (including login, forgot password, etc).

    This granular understanding of the API structure allows us to set very strict protection for your most sensitive assets.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Why Modernizing Security is Like Visiting a Fast-Food Restaurant

    Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

    Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

    According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

    As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

    Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

    A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

    To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:

    • Major cloud providers (e.g. AWS, Azure, IBM, GCE)
    • Container platforms (e.g. Kubernetes, Docker)
    • Hardware and web servers (e.g. load balancers, NGINX+)
    • Serverless options (e.g. API gateways)
    • Platform services (e.g. Heroku, language plugins)
    • Cloud-based deployment models (e.g. hosted cloud WAF)

    The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

    The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

    The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

    — Jonathan DiVincenzo

  • How to Automate an API Security Program Without Adding Staff

    How to Automate an API Security Program Without Adding Staff

    In today’s information economy, data is a primary raw material and a source of value to both providers and consumers. For many companies, entire business models are built on the exchange of information.

    Consider a ride-sharing business that owns no vehicles of its own. What the company does possess, however, is a database of private vehicle owners who are willing drivers, a roster of people who will gladly pay for a ride and an application that can instantly connect a rider with a driver via an application programming interface (API). The ride-sharing company makes its money by taking a cut of the fare.

    Another example is a company that collects and refines financial data and makes it available to investors who might want to buy stock. Companies such as E*TRADE, Merrill Lynch and Fidelity buy that investment data to make it available to their clients. APIs are at the heart of these important data exchanges.

    How Prominent are APIs?

    The information economy is synonymous with the API economy. APIs are increasingly the way business partners—internal and external—exchange and monetize data and services. APIs allow for machine-to-machine data retrieval, essentially removing barriers and accelerating access to data. There is hardly a modern application today that doesn’t provide an API to integrate with other applications and data sources. The typical mobile app today uses an average of 10 to 15 APIs to move meaningful data into and out of the app. Modern web apps called SPAs (single-page apps) do the same. APIs have proven to be so efficient and useful that many companies have begun creating new business ventures by mobilizing their data to third-party developers and the public.

    DevOps teams heartily embrace APIs to advance their ability to produce applications much more quickly. APIs, however, are largely a mystery to security teams that must ensure that this means of rapid data exchange does not create unnecessary risk and negative exposure for the company or its brand. Enterprise security teams are right to question the vulnerabilities and threats posed by APIs. Insecure APIs have led to some very serious data breaches, some of which are outlined in the Dark Reading article, “Expect API Breaches to Accelerate.”

    For example, the mobile payment app Venmo exposed sensitive details about hundreds of millions of transactions through a poorly secured API. In another case, an insecure Panera Bread API used by a mobile app exposed users’ private details through a searchable API that required no authentication to access. As a result, as many as 37 million records, which included customer personal information identifiers (PII) such as names, email addresses, physical addresses, birthdays and the last four digits of credit cards—all in plain text—were exposed. T-Mobile, McDonald’s, Symantec, Instagram and numerous other companies have suffered through significant data breaches traced back to insecure APIs. The damage is high because most APIs are designed to serve data without security in mind.

    DevOps and security teams can agree that a data breach coming from their applications is completely untenable. Thus, designing and applying a security program that spans across all APIs across all applications is an essential function in protecting data and brand. Just exactly how can this be achieved? Let’s look at the steps of automating an API security program without needing to add additional security staff.

    The Challenge of Securing APIs

    The very nature of identifying all APIs makes it a challenge to secure them. A developer can create an API in a matter of minutes and publish it on the internet with almost no resistance when using public cloud services such as Amazon, Microsoft and Google. What’s more, she can make changes to that API as often as she wants, and every change cycle presents an opportunity to introduce new risk. It’s not unusual for a developer to change her API weekly or daily.

    Let’s go back to that example of the financial services company that sells data to stock brokers. Suppose the developer makes a change to her API which unintentionally enables the brokers to see the client lists of every other broker that consumes data via the API. That would be a catastrophic breach, yet this is precisely the type of API breach suffered by the U.S. Postal Service a year ago.

    APIs today increasingly are built on serverless infrastructures such as Amazon Lambda, Azure Functions or Google Cloud Functions. Traditional firewalls, gateways and agents can’t protect this type of API built on ephemeral infrastructure. Now consider that a large enterprise might develop and/or use hundreds or even thousands of APIs. The magnitude of the challenge to secure every API becomes apparent. Manual security oversight and enforcement are simply out of the question. Automation of security assessments done on a continuous basis is the only scalable approach.

    Start With an API Security Framework

    Every organization that creates or uses APIs needs an API security framework that consists of three steps:

    1. Continuous API discovery and specification creation.
    2. Continuous API specification analysis and inspection.
    3. API policy enablement and enforcement.

    Let’s have a look at each step and its impact.

    Know What APIs Are in Use and What They Are Intended to Do

    Gathering API specifications is an important first step in defining what APIs are intended to do. However, many APIs exist without any specification. A service that creates API specs helps to deal with those APIs void of documentation. However, this spec creation service also needs to continuously monitor and discover new APIs to remedy the problem of not knowing what APIs exist and their intended function. It’s common for a developer to document what her API is designed to do initially, but updating that documentation every time she makes a change to her API is rare. To compensate, the organization needs to have an automated tool that gathers this information and notes each time an API changes, then accordingly updates the API specification.

    For example, consider an API that exists to transfer customer information between a company’s back-end server and a mobile application. The developer adds a feature or two and the API changes to support these new features, resulting in the API doing things it wasn’t originally expected to do. How would the organization know about these changes? There is a need to continuously analyze the API for such changes to understand the current state of specifications for what the API is doing.

    The organization needs to create specifications of all the APIs, especially publicly facing APIs hosted in the cloud. This service needs to operate continuously to look for changes in the APIs constantly. There are tools that can automate these various activities, including discovering new APIs and changes to existing APIs. These tools also can uncover other cloud resources and data services related to these APIs; enumerate API domains, functions and associated methods; and generate a standards-based (Swagger, OpenAPI v3) spec if one does not exist.

    Analyze the APIs for Security Threats

    The next step is to perform a security inspection on each API operation every time it changes. The security team needs to know: Does it have the right data encryption? Is proper authentication in place? What type of authorization policy is being applied? What is the API’s level of availability? What kind of data sources does it access? Knowing each API’s current security posture is critical if the organization wants to avoid a data breach.

    This API analysis needs to take place continuously and at scale since manual processes are ineffective for organizations using numerous APIs. Fortunately, there are tools and technologies that automate this process and perform tasks such as finding potential vulnerabilities within the authentication and encryption layers of the API. The tools also can generate security tasks with recommended changes for developers to remedy their respective API problems and alert security personnel when there are discrepancies between the API specification and its functional operations.

    Create and Enforce Security Policies

    No two companies have the same appetite for risk. If there’s one aspect of creating an API security program that requires a manual investment of time, it’s policy creation. Automation then can be used to enforce the policy. A security policy for APIs should start with two primary questions: Who should be able to utilize the API? And what level of sensitivity, regulatory oversight and/or privacy concerns does the API have? Based on the answers to those first two questions, you can form the basis for the security policy.

    For example, a bank has an API that provides transaction statements for a specified account. That API has access to extremely sensitive and private information for each of its customers. One customer should never be allowed to access another customer’s account statements. Therefore, the authentication, authorization, encryption and availability of that API would be set to the most restrictive security standards available to ensure data exposure is tightly controlled. Another API from this same bank may provide the current interest rates of savings and money market accounts. This is data the bank likely would share with anyone potentially interested in opening an account with them. In this case, the level of security restriction would be lowered to support a wide variety of systems, browsers, SDKs and apps to ensure this information is highly available.

    Historically, API policy enforcement for authentication, encryption and availability was often done at the network gateway layer. As applications have migrated to modern architectures such as mobile and cloud, the gateway approach has increasingly become less practical, less scalable and more restrictive. Application developers are often leveraging authentication, encryption and availability zones provided to them through SDKs and/or cloud services. In these cases, an automated service that integrates with these security services is a better approach for API policy enforcement versus traditional network gateways.

    Automation is Key

    Security teams are notoriously overworked and short-staffed. Worldwide, there’s a dire shortage of skilled security professionals available for hire, so adding additional security staff to build and execute the API security program isn’t a practical option. Bringing in consultants is expensive and can be budget-busting. Thus, automation through tools and technology is a sensible approach.

    Automation provides the benefits of saving time and money when it comes to executing the three steps outlined above. What’s more, an automated program provides consistency in the repetitive tasks necessary to discover, document and analyze the APIs in use, and enforce corporate policies to control risk.

    APIs are critically important to modern applications. DevOps people heartily embrace them, and security teams can learn their value as well once they understand how a robust and continuous API security program will benefit their organization.

    — Doug Dooley

  • How DevSecOps Can Help Avoid Catastrophic Breaches

    How DevSecOps Can Help Avoid Catastrophic Breaches

    Earlier this year, Tesla’s Cloud was hijacked and used to mine cryptocurrency, exploiting a vulnerability in the company’s Kubernetes cluster. A mountain of FedEx data was recently exposed, affecting 119,000 individuals. The Equifax breach garnered international attention after an estimated 145.5 million Americans were jeopardized. In other news, we’ve reported on how the Vine Docker registry fiasco was hacked, leaving an embarrassing PR trail in its wake.

    What is common across all these scenarios? They arguably could have been avoided with basic safeguards underpinned by a healthy dose of DecSecOps. In hindsight, let’s see what specific strategies developers can adopt to avoid such horrendous leaks.

    Basic DevSecOps Can Prevent Vulnerabilities

    DevSecOps is described as placing security at the forefront of every action. Within the world of cloud tooling, this means instilling protection at every point of the build life cycle. You would think this equates to advanced container and orchestration security, powerful access management and establishing hardened oversight for internal applications, right? Actually, many modern exploits simply involve a lack of basic password protection.

    Case Study No. 1: Tesla Cloud Cryptojacking

    In mid–2018, Tesla’s Amazon servers were hijacked by malware and used to mine cryptocurrency for rogue agents. Similar cryptojacking has transpired at Gemalto, Aviva and others. According to RedLock’s report, the hackers infiltrated the Kubernetes console, which was not password-protected. In one pod, they found access credentials to Tesla’s AWS environment. The breach exposed sensitive telemetry data, though was limited to “internally used engineering test cars only,” according to Tesla.

    How to Prevent

    Password protection for Kubernetes administrative consoles is a readily apparent lesson here. All cloud accounts, even if used internally, must be better-equipped and access credentials sequestered. Surely, instilling a “security by design” mentality can help limit the number of such consoles left accessible.

    Case Study No. 2: Vine Registry Breach

    In 2016 a white hacker by the alias avicoder was able to infiltrate Vine, the video-sharing social network. The hacker used tools to discover subdomains and behind one—https://docker.vineapp.com—found an open Docker private registry that housed the Vine source code. Such a vulnerability could have been used to collect user details or inject malware for malicious purposes. Thankfully, no users were compromised, and the Twitter Bug bounty program awarded avicoder a handsome sum for the discovery.

    How to Prevent

    In this particular incident, there was nothing at fault with Docker or Docker containers. The service (which was meant to be private) was simply left public and devoid of access controls. The lesson is that URLs on the world wide web are just that—publicly exposed to the world. It does not matter if no documentation links to them; such subdomains are easy to discover with crawlers and will be exploited if found.

    Case Study No. 3: Equifax Exploits

    In the Equifax breach, millions of customer records were stolen. The Equifax report notes that hackers exploited a “website application vulnerability.” Further reports detailed that the 2017 breach utilized flaws in Apache Struts, likely through a zero-day exploit, according to the Apache Struts Project Management Committee.

    How to Prevent

    Some note that the deserialization of untrusted data inherent in Apache Struts applications leaves some major vulnerabilities and potentially malicious code execution.

    Containers, due to their short lifespan, are not persistent, therefore making consistent hacking harder. They can also isolate functionalities so as to decrease attack vector. Regarding the Equifax breach, Aquasec speculates that container usage could have lessened the impact:

    “… it’s likely that such a breach would have been more difficult with containers, and that if successful, it would have been less persistent, not as widespread, and mitigated sooner.”

    Some view containers as a formidable force if armed with behavioral analysis and firewalls for network connections. Still, others note flaws in assuming containers are safer.

    Regardless of architecture, In DevSecOps, security for customer data isn’t drafted into the background; rather, it is imbued into the entire tooling process and holds equal footing within each build.

    Instilling a DevSecOps Culture

    Instead of a build-now, secure-later attitude, DevSecOps seeks to elevate security into every decision. With each build, security is melded with greater forethought regarding the repercussions for how data is treated.

    Admin consoles for Kubernetes clusters must be armed and password-protected, and the same goes for private GitHub repositories or Docker registries. Any traversal of data through cloud SaaS services must have authorization in place. A most obvious lesson is to password protect those “hidden” registries with discoverable URLs.

    Bounty programs for white hackers continue to lead to successful bug detection. At least for these institutions, there is less evidence of compromised user data and remediation is quickened.

    Much of this can be distilled by due diligence and through breeding a culture of security. While that’s a little fluffy for some, it apparently still requires repeating for institutions that continually de-privilege these basic safeguards.

    — Bill Doerrfeld

  • American Express Uses DevOps for Better Breach Response

    American Express Uses DevOps for Better Breach Response

    It was 6 a.m. Saturday when the phone rang and awoke the American Express CIO. When the phone rings at 6 a.m., it is never good news. Never. This instance was no different: In this case, a third-party supplier just suffered a breach, and that breach would impact American Express cardholders.

    Immediately following that call, the CIO activated the company’s Cyber Crisis Response team. The job of the Cyber Crisis Response team is to help identify impacted cardmembers and prepare to reach out and assist any who have questions or need help regarding the breach.

    The need to respond swiftly to customers and provide them with the correct information is essential today, not only to stay on the right side of regulators, but to also help customers avoid fraudulent transactions and identity theft. When it comes to such effective data breach incident response, rarely does DevOps come into play—but the experience American Express shared at the most recent DevOps Enterprise Summit revealed just how better DevOps organizations can be when it comes to effective breach response.

    Within hours of the initial call between the CIO and the Cyber Crisis Response team, the primary breach response was divvied into three teams. The first team focused on what data breach bridge teams typically focus on: how to identify impacted customers. The second team was comprised of business and product owners, as well as customer care staff, whose objective was to take the findings from the response investigation and communicate them to American Express customers.

    The third team consisted of DBAs and system specialists, who understood all the systems, as well as enterprise architects, who might be able to quickly solve any technical challenges that arose.

    Getting to the Right Breach Information

    By 3 p.m. that Saturday, the first team determined that it could pull together all of the information it needed to identify affected cardholders. That was the good news. The bad news was that there would be tens of millions of production records that would need to be evaluated to make the final determination.

    If the team was to pull those tens of millions of records in production, the demand would start to slow those production systems. “How do we pull these records out of production without impacting our availability? That was the challenge,” said Aimee Cardwell, vice president of Engineering, Consumer Product Development at American Express.

    As the day moved forward and the teams worked to find a way to access those production records without impacting availability, one of the engineers on the team pitched an idea that would have been scoffed at in most organizations: Why don’t we clone production? But the novel idea wasn’t immediately rejected. The team on the call began to weigh the pros and cons of cloning production, and concluded that it could, in fact, clone production quickly, and all of the impacted card data could be aggregated without negatively impacting American Express’s servers and associated availability.

    After the team successfully cloned the production systems, it worked all night to identify the impacted card members, which required cross-referencing the cloned production system with other data stores, Cardwell explained.

    “What was really important here was the comfort level everyone had when it came to bringing up an idea that was really off the wall. And, in the end, they came together to make it happen because together the various teams had a string understanding of the people, technologies, and processes in place necessary to succeed,” said Chad Avery, director, DevOps implementation at American Express.

    It was now 6 a.m. Sunday and the teams had worked nonstop since the CIO’s phone rang Saturday morning. The teams managed to evaluate the relevant data from various systems and collected a list of potentially impacted card members. And after a careful analysis, they were able to determine who had been affected by the breach and who hadn’t.

    What made this success possible? Both Avery and Cardwell believe that it was the integration of business, product and technical teams. “The fact that we had business, product and technical teams working together in this incident was a huge win for us,” Cardwell said.

    Avery contended the ability for an organization to successfully integrate its technical, business and product teams makes the difference. If those teams hadn’t been working together from the beginning, he said, they may not have been able to find a solution and, if they had, it would have taken much more time to do so.

    Disclosure Day, and a Final Big Win

    It’s a good thing it worked out quickly. By Monday morning, the breached third-party was ready to go public with its data breach disclosure. That announcement would immediately impact not just American Express cardmembers, but those of most other credit card providers as well. Many customers would have pressing questions about whether their accounts were impacted, and, if so, what to do.

    Customer service lines had to be ready.

    That proved to be the final challenge that needed to be solved: How would customer service representatives know which customers calling were affected? Tight team integration and collaboration proved to be a deciding factor once again.

    The engineers on the product team had spent the previous 24 hours building a tool that they shared with American Express customer care professionals. When individuals called the customer care team, the tool could alert the team whether a customer was in the impacted group.

    The tool also came equipped with a data collection feature that would enable everyone to learn from the event and even prepare better for next time. “We want everyone to get better. We want ourselves to get better,” Cardwell said. “We want to know what percentage of customers who called were impacted, and what percentage of customers that called were not impacted. We wanted to know our response time on those customers. We wanted to know any other data that would help us to do better next time.”

    And it will have been that dedication to collaboration among technical teams, business units, developers, operations and security teams that enabled them to quickly and successfully manage a third-party data breach and prepare themselves to do even better next time. “They all were able to develop a solution quickly. They were able to identify the customer impact, design a solution, build it, test it and get it deployed. And, oh by the way, the teams did it in a weekend,” Avery said.

    — George V. Hulme

  • Meeting the Need for Speed in Cyber Threat Response

    Meeting the Need for Speed in Cyber Threat Response

    In the very early days of the internet, hackers most likely were “lone wolves.” They might be an unhappy customer, a disgruntled employee or a tech-savvy youth who just wanted to see if he could breach a target’s defenses.

    Occasionally, hackers might aspire to more devious crimes including identity theft, blackmail, theft of trade secrets, exposure of personal information or monetary theft. These types of hackers were annoying, unnerving and potentially dangerous, but they seldom caused widespread damages or serious financial losses. Today, however, cybersecurity professionals face an entirely new group of hackers and an escalating number of attacks—and security strategies and tools have not been able to keep pace.

    The Modern Hackers

    The greatest source of risk comes from well-financed, sophisticated hackers who often are connected to a government that sanctions and supports their activities. These groups constantly refine their already impressive skills and they are patient as well as persistent. They know how to circumvent defenses that rely on signatures or pattern matching, and they are adept at launching attacks that may take months to achieve fruition.

    For example, sophisticated hackers may launch an upstream attack aimed at companies that make the products that others use for security, including SSL certificates and other digital credentials. These credentials are then used to steal money, intellectual data or other information from the group’s real targets. Hackers can also attack in stages, such as first going after information that will give them access to an organization’s network, allowing them to conduct whatever mayhem they want on their own schedule. They may install an encrypted “zero day” attack, for instance, or simply wait until a desirable piece of intellectual property is completed.

    Why Speedy Responses Are Essential

    The longer that a breach goes undetected, the more damage the incident will cause. It is a bit like having an undetected roof leak; the longer the leak allows water to penetrate beneath the roof, the more damage the water will do to the structure.

    Unfortunately, most organizations are not doing a very good job of detecting breaches quickly. In 2014, the Verizon Data Breach Investigations Report revealed that 43 percent of all web application attacks were not discovered for months, and 85 percent of the point-of-sale intrusions went undetected for weeks. Other breaches have gone without detection for years, such as the Excellus breach that lasted 18 months and the allegedly state-sponsored “Project Sauron” attack that was in operation for almost five years.

    When attackers have months or years to access a victim’s network, they have ample opportunity and time to inflict a substantial amount of damage. They can even expand their attack to infiltrate the networks of the original target’s customers or vendors. Interestingly, a study conducted by the Ponemon Institute found that approximately 33 percent of all attacks were not detected for two years — and two-thirds of the attacks were discovered by a third party rather than the compromised organization.

    However, a report issued in June 2016 by the Business Continuity Institute indicates that many organizations are making progress when it comes to responding to cyberattacks. BCI surveyed 369 organizations in 61 countries. Approximately 66 percent reported that they had suffered at least one attack during the previous 12 months, and 15 percent reported that they had suffered 10 or more attacks. Roughly 31 percent claimed that they responded to attacks within an hour, but 19 percent said that they took at least four hours to respond. Approximately 24 percent were hit by a denial-of-service attack, while 45 percent suffered a malware attack; both forms of attack rendered the organization’s network inoperable or contaminated.

    Responding Quickly to Attacks

    Although most cybersecurity professionals know that response time is critical, not all of them understand the best ways to ensure that the speed is there when needed.

    • A speedy response starts with an effective incident response plan. The plan should be based on a thorough assessment of threats, risks and potential failure modes, and it should be updated frequently and available to all parties.
    • “Practice makes perfect.” Response teams should have ample opportunities to practice their tasks through frequent “dry runs.” Instead of wasting time trying to determine what they should do when an attack does happen, they can react reflexively.
    • Automation can greatly reduce the amount of time required to respond to an incident. For example, without automation, if a breach occurs, staff members might have to manually check 5,000 or more endpoints. However, an automation platform can collect, analyze and report on the activity in much less time.
    • Increase visibility across the different domains and systems. A recent survey of IT remediation teams conducted by the SANS Institute revealed that almost half felt that the lack of visibility was their main impediment to an effective, speedy response. Using a security information and event management (SIEM) solution for log aggregation and correlation can increase visibility across organization.

    When the health of your organization is at risk, taking even an hour to respond to an incident can be far too long. Taking a day, a week or a month to detect and respond to a threat can do irreparable damage. With steps in place, organizations can meet their need for speed in addressing cyber threats quickly, to best protect their networks.

    About the Author / Rishi Bhargava

    Rishi Bhargava is co-founder and VP of Marketing for Demisto, a cyber security startup with the mission to make security operations “faster, leaner and smarter.” Prior to founding Demisto, he was vice president and general manager of the Software Defined Datacenter Group at Intel Security, and before Intel, he was vice president of product management for Datacenter and Server security products at McAfee, now part of Intel Security. He has more than a dozen patents in the area of computer security. He holds a BS in Computer Science from Indian Institute of Technology, New Delhi, and a Masters in Computer Science from University of Southern California, Los Angeles.